I currently have a route that take a message sent to a JMS queue, multicasts
to some sub-queues, and then aggregates the resulting responses to return an
overall status of processing to the client.
This is working well using request-reply over JMS, but I would like to make
the JMS queues transactional. Some of the routes implement multi-step
processes, and if the server is restarted while processing a request, I'd
like it to be able to pick up where it left off.
Through some searching, it seems like the consensus is to split the request
portion and reply portion into separate transacted routes. To me, this
means that I will need to create several new transacted routes that are
responsible for aggregating responses using some correlation ID. I can
generate UUIDs when a request is received from a client and propagate that
to the response messages, so there shouldn't be any issue with correlating
which response messages get aggregated together.
The piece that I seem to be missing is how to get that response payload back
to the client.
The best thing I can think of doing is sharing a ConsumerTemplate in the
rest service that receives the requests. A
ProducerTemplate.sendMessage("jms:queue:requests") followed immediately by
something like
consumerTemplate.receiveBody("jms:topic:responses?selector=requestId=someuuid");
Does this sound like the right way to refactor things?
--
View this message in context:
http://camel.465427.n5.nabble.com/Is-there-an-alternative-to-request-reply-when-you-want-to-use-JMS-transactions-tp5747691.html
Sent from the Camel - Users mailing list archive at Nabble.com.
