TIBCO EMS notification to Publisher in case of Subscriber failure

I am trying to find an answer on of how to notify an EMS Publisher in case of a Subscriber failure. In a case of Publisher->EMS server->Subscriber, if a Subscriber fails, I need to inform Publisher to take a corrective action.I am not bothered about durabilty/PERSIETENCE, my significance is of time. In Trading systems, If I send an market order to a Subscriber who in turn sends it开发者_Python百科 to an exchange, if it fails, I need to make my Publisher publish the messages on a different topic to another Sunscriber(another exchange). Any ideas is appreciated.

The tibjmsadmin.jar library contains methods to detect when subscribers disconnect. Easier than writing code, you can:

• if you have Hawk, use the tibjmsadmin.hma to write a Hawk rule in the event a subscriber disconnects, or
• listen on the monitor topic $sys.monitor.connection.disconnect - the body of the message tells you which subscriber disconnected.

However these "monitoring" approaches to failing over the publisher have a significant problem - in the time it takes for you to detect the subscriber failure and redirect the publisher, some messages may get through and get stuck in the defunct queue. You don't wat this happening to any $10M trades!

EMS knows when subscribers are connected or not and you should take advantage of this.

Use a "distributed queue" and there shouldn't be any need to code logic into your application to switch to a new subscriber when it fails. This happens without message loss and maintains the order of messages. It is also good architectural practice to keep load balancing and failover logic out of your code and in the administration setup of your JMS provider.

Basically you setup multiple subscribers to a queue (each exchange represented by a subscriber). The default action will be for EMS to load-balance messages across your subscribers in a round-robin fashion. But you can set the queue to "exclusive" so that messages go to only one subscriber at a time. Then if that active subscriber fails, the messages are forwarded to another subscriber.

See the EMS manual for more details on all these topics.

Not sure if you have access, you could try looking at the ReceiverCount or ConsumerCount in either QueueInfo or TopicInfo - I believe you need the tibjms.admin package. May be you can query this before you publish and then selectively publish? Not sure what the overhead is.

Because of the nature of JMS, AFAIK no transaction states (unless you use a XA transaction - with all of that overhead) or acknowledgements will propagate through the EMS broker. I.e.acks are always between publisher and broker and consumer and broker.

Failing the above, you could try a separate ack topic for which the roles are reversed, but then the failure case is a timeout - I'm not sure this is sensible.

If you don't really care which exchange the order goes to - why not make the topic/queue exclusive and make both consumers attempt to consume - the first one to succeed will process all of the messages - if it dies, then the second one (which could be periodically retrying - may successfully connect).. Alternatively allow both to process orders off the queue - remember a message will only be ever processed by a single consumer...

I really cannot see the advantage of a decoupled messaging bus in your order flow... makes no sense to me..