0

I have a situation where I want to store messages that can't be delivered to the JMS server when the client becomes disconnected from the JMS server. I've read about store and forward feature of JMS providers, but I haven't seen any discussion about this feature at the client level. Are there any providers that provide this feature in the client implementations?

I've considered adding an in process JMS provider that could store and forward the messages up to the JMS server. What are the most light weight implementations available? HornetMQ, ActiveMQ? Seems like this is a very niche use case and there could be an optimized implementation for this scenario that wraps another provider and is lighter weight than a full embedded JMS provider.

Charles
  • 50,943
  • 13
  • 104
  • 142
chubbsondubs
  • 37,646
  • 24
  • 106
  • 138

1 Answers1

1

Storing messages at client side is not a JMS standard feature, you should add some handling on client-side for cases where the JMS server is not available. To reduce the chance for this to occur you can run the JMS server on the same machine, or even in the same JVM as your client. However there is still a little chance that a connection is lost, so you do still need some client-side handling code.

You do also need some thing, that forwards the messages from your local JMS server to the one that should receive the messages. Some messaging systems do have special features to care about this forewarding (e.g. SonicMQ' dynamic routing architecture) - maybe you can reach the same behaviour with a broker network in ActiveMQ(http://activemq.apache.org/networks-of-brokers.html) - otherwise you could implement this behaviour with an ESB implementation like Apache Camel.

Concerning the messaging implementation i would not stick to HornetQ as it will be replaced by ActiveMQ as JBoss standard messaging provider.

roundrobin
  • 399
  • 1
  • 6
  • Can you provide a reference for your statement that HornetQ will be replaced by ActiveMQ as the JBoss standard messaging provider? Thanks! – Matt Apr 08 '14 at 20:59
  • that was some information we received from RedHat colleagues 3 years ago -- looking at the actual product i would assume that this replacement did not take place, and maybe never will... – roundrobin Apr 22 '14 at 05:19