Hi Emmanuel, >I was wondering from a high availability perspective when the >controllers are distributed, who is going to own the queue? >Can it be replicated or will the JMS server hosting the queue be a >single point of failure?
Some JMS implementations (like SwiftMQ and I think ActiveMQ) allow to build a network of JMS servers. Under SwiftMQ, when a topic is declared on one node, then it is accessible for publish and subscribe operations on every node of the JMS server network. I conducted some tests on a configuration with a network of two SwiftMQ JMS servers and two hedera nodes (each client connected on a distinct JMS server). The results are that all messages sent are effectively received by all nodes but total ordering is not respected :-( So, I fear this configuration cannot be used for Sequoia. The only remaining solution to get some high-availability (no single point of failure) is to enforce that all hedera nodes connect to the same JMS server (to get required total ordering) and to enable auto-client reconnects on a spare JMS server in case the other one fails. I have some production applications using this auto-reconnect scheme and it works fine so I think it could be used for hedera too. The only problem is that the auto-reconnect feature is not covered by the JMS spec so its activation is dependent on the JMS implementation used. Sometimes it's completely transparent for the application, sometimes it needs a little contribution from the client application to work. >Looks extremely promising. Don't hesitate to keep us posted. >We can create a CVS module in Hedera to host the code if you wish. I would be glad to see this code hosted on continuent. Thanks for your proposition and I'll keep you posted. Karl Cassaigne _______________________________________________ Hedera mailing list [email protected] https://forge.continuent.org/mailman/listinfo/hedera
