Concurrent Synchronous Request-Reply with JMS/ActiveMQ - Patterns/Libraries? Concurrent Synchronous Request-Reply with JMS/ActiveMQ - Patterns/Libraries? multithreading multithreading

Concurrent Synchronous Request-Reply with JMS/ActiveMQ - Patterns/Libraries?


In a past project we had a similar situation, where a sync WS request was handled with a pair of Async req/res JMS Messages. We were using the Jboss JMS impl at that time and temporary destinations where a big overhead.

We ended up writing a thread-safe dispatcher, leaving the WS waiting until the JMS response came in. We used the CorrelationID to map the response back to the request.

That solution was all home grown, but I've come across a nice blocking map impl that solves the problem of matching a response to a request.

BlockingMap

If your solution is clustered, you need to take care that response messages are dispatched to the right node in the cluster. I don't know ActiveMQ, but I remember JBoss messaging to have some glitches under the hood for their clusterable destinations.


I would still think about using Camel and let it handle the threading, perhaps without spring-remoting but just raw ProducerTemplates.

Camel has some nice documentation about the topic and works very well with ActiveMQ.http://camel.apache.org/jms#JMS-RequestreplyoverJMS

For your question about spinning up a selector based consumer and the overhead, what the ActiveMQ docs actually states is that it requires a roundtrip to the ActiveMQ broker, which might be on the other side of the globe or on a high delay network. The overhead in this case is the TCP/IP round trip time to the AMQ broker. I would consider this as an option. Have used it muliple times with success.


A colleague suggested a potential solution-- one response queue/consumer per webapp thread, and we can set the return-address to the response queue owned by that particular thread. Since these threads are typically long-lived (and are re-used for subsequent web requests), we only have to suffer the overhead at the time the thread is spawned by the pool.

That said, this whole exercise is making me rethink JMS vs HTTP... :)