Other reason to use JMSMessageDispatcher?

[siegersallee]

In the documentation, it is recommended to use JMSMessageDispatcher for production for Real-Time Messaging, instead of the LocalMessageDispatcher, which is recommended for development and (some) testing. It states that JMSMessageDispatcher is able to synchronize messages for multiple JVMs, and also to restore message queues after a JVM restart.

In our application, for almost all installations, we will have a single JVM, and will not care if the message queues are cleared every time the JVM is re-started. If we do not need those 2 capabilities, is there any other reason to use JMSMessageDispatcher for production, or will it be just as reliable to use LocalMessageDispatcher?

The reason I ask is because we would have to significantly change our system configuration to use JMS, and we would rather not, if it's not actually going to be helpful.

Thanks for your insight.

[Isomorphic]

LocalMessageDispatcher will not actually work in a multi-server deployment. It's not that it works less reliably or efficiently, it just will not function, since there is no provision for passing messages back and forth between servers in a cluster. That's what JMS is for.

So, you will need JMS for any multi-server deployment. If you prefer to use LocalMessageDispatcher to keep things simple for single-server deployments, it should be straightforward to write your server-side application code to use one or the other Dispatcher class based on configuration.