Jms 为单个订阅提供服务的多个进程导致MQRC_subscription_在使用

我有一个TIBCO BusinessWorks进程，它发布到一个JMS主题——我们称之为topic.a——有一个进程以SUBSCRIBE.a的名称订阅该主题

我遇到的问题是，第一个开始侦听SUBSCRIBE.A的服务器很好地钩住了。运行完全相同进程的其他3台服务器收到一个错误“WebSphere MQ调用失败，代码为'2'（'MQCC_失败'）原因为'2429'（'MQRC_SUBSCRIPTION_IN_USE'）”

这对于企业软件来说是不合理的行为，而且我知道WebsphereMQ、JMS和TIBCO Businessworks都可以很好地扩展，所以我肯定遗漏了一些东西。我只希望每个事件处理一次，但一个单独的框无法处理，这既有故障转移的原因，也有剪切量的原因

---

要让群集中的所有4台服务器为订阅服务，我必须做些什么

之所以使用MQRC 2429，是因为您的4个订阅服务器都使用相同的客户端ID，并且都试图使用相同的持久订阅。当订阅者已在持续订阅上积极侦听时，其他订阅者不能在同一订阅上侦听。如果希望所有订阅服务器同时侦听，则为每个订阅服务器提供单独的客户端ID

但您必须注意，所有订阅者都将获得由发布者发布的同一消息的副本（在您的案例中为TIBCO BusinessWorks）。因此，如果所有订阅服务器都处于活动状态，则所有订阅服务器都将处理该事件

---

对于故障转移，您可以查看如何使用WebSphere MQ多实例队列管理器功能或任何其他HA解决方案。对于负载共享，您可以查看WebSphereMQ集群特性

我同意对于企业软件来说，这似乎不是一种合理的行为，但这种限制是由JMS规范强加的。JMS 1.1规范第6.66.1节说，“对于特定的持久订阅，一次只有一个会话可以有TopicSubscriber”

也就是说，webspheremq确实提供了一个特定于供应商的选项，允许您做您想做的事情：请参阅

CLONESUPP

connectionfactory属性。这将记录在页面的信息中心中

---

虽然它是特定于MQ的，但如果您使用受管对象指定它，那么您的代码将不需要使用任何特定于供应商的方法。

并且我将向任何能给我工作答案的人提供+100的奖金。直到两天过去，我才可以这么做。克里斯可以使用100分，他的回答应该很容易测试，并提供你想要的行为。：-）你确实是对的……但我希望一个进程集群能够处理单个订阅。如果我想让每一个米色的小盒子都能容纳每一个活动，那就没问题了，但这根本无法扩展。当然，有一种方法可以让同一订阅名称由多个进程提供服务，否则，TIBCO或IBM如何声称支持企业级卷？在这种情况下，他们声称的方法是提供队列API。根据定义，您要求的是排队行为。在这种情况下，有一个订阅将消息传送到队列，应用程序可以选择按主题或通过访问队列来访问消息。如果它访问主题，JMS规范将定义您看到的行为。但是，如果应用程序作为队列访问队列，那么所有实例都可以竞争相同的消息。因此，创建一个管理订阅并对订阅队列使用队列API。或者按照克里斯的建议使用

CLONESUPP

。