5

I have a TIBCO BusinessWorks process that is publishing to a JMS topic -- lets call it TOPIC.A -- there is one process that is subscribing to that topic with a name SUBSCRIBE.A.

The problem I have is that the first server that starts listening to SUBSCRIBE.A hooks in fine. The other 3 servers, running the exact same process get an error of "WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2429' ('MQRC_SUBSCRIPTION_IN_USE')"

This can't be reasonable behavior for enterprise software, and I know WebsphereMQ, JMS and TIBCO Businessworks all scale well, so I must be missing something. I only want each event processed once, but a single box just isn't going to do it, both for fail-over reasons and shear volume reasons.

What do I have to do to let all 4 servers in the cluster to service the subscription SUBSCRIBE.A?

T.Rob
  • 31,522
  • 9
  • 59
  • 103
Joe Zitzelberger
  • 4,238
  • 2
  • 28
  • 42
  • And I'll offer a bounty of +100 to anyone that can give me a working answer. I just can't do that until two days have passed. – Joe Zitzelberger Sep 17 '13 at 15:09
  • Chris can use the 100 points, and his response should be easily testable and provide the behavior you want. :-) – T.Rob Sep 19 '13 at 19:03

2 Answers2

5

I agree it does not seem like reasonable behavior for enterprise software - but this restriction is imposed by the JMS specification. The JMS 1.1 spec, section 6.66.1 says "Only one session at a time can have a TopicSubscriber for a particular durable subscription".

That said, WebSphere MQ does provide a vendor-specific option that allows you to do what you want: see the CLONESUPP Connection Factory property. This is documented in the Infocenter at the CLONESUPP properties page.

While it's specific to MQ, if you specify this using administered objects you code will not need to use any vendor-specific methods.

T.Rob
  • 31,522
  • 9
  • 59
  • 103
Chris Frank - IBM
  • 166
  • 1
2

The reason for MQRC 2429 is because all of your 4 subscribers are using the same client ID and all are trying to use the same durable subscription. When a subscriber is already actively listening on a durable subscription, no other subscribers can listen on the same. If you want all subscribers to listen concurrently, then have separate client ids for each of your subscribers.

But you must note that all subscribers will get a copy of the same message published by a publisher (TIBCO BusinessWorks in your case). So if all subscribers are active, all will process the event.

For fail-over you can look at using WebSphere MQ Multi-instance queue manager feature or any other HA solutions. For load sharing you can look at WebSphere MQ clustering feature.

Shashi
  • 14,980
  • 2
  • 33
  • 52
  • You are indeed correct...but I want a cluster of processes to be able to handle a single subscription. If I wanted every little beige box to get every event, it would be no problem, but that doesn't scale at all. Surely, there is a way that I can let the same subscription name be serviced by multiple processes, otherwise, how can TIBCO or IBM claim to support enterprise level volumes? – Joe Zitzelberger Sep 18 '13 at 05:54
  • 2
    The way they make that claim in this situation is to provide a queuing API. *By definition* what you are asking for is queuing behavior. In this case there's a subscription feeding messages to a queue and the app has the option of accessing them by topic or by accessing the queue. If it accesses the topic, the JMS Spec defines the behavior you are seeing. But if the app accesses the queue as a queue, all instances can compete for the same messages. So create an admin subscription and use the queuing API against the subscription queue. Or use `CLONESUPP` as Chris suggests. – T.Rob Sep 19 '13 at 18:58