0
votes

below i explain my thoughts with one article about temporary queue.i just want to know whether i am right or wrong about this.

Ref Link : How should I implement request response with JMS

"Creating temporary destinations, consumers, producers and connections are all synchronous request-response operations with the broker and so should be avoided for processing each request as it results in lots of chat with the JMS broker."

i.e consumer and producer ,temporary queue are in same session or connection. if we close the connection or session the temporary queue will disappear.we can't get the temporary queue in different session.it will make lots of chat with activemq.

"The best way to implement request-response over JMS is to create a temporary queue and consumer per client on startup, set JMSReplyTo property on each message to the temporary queue and then use a correlationID on each message to correlate request messages to response messages. This avoids the overhead of creating and closing a consumer for each request (which is expensive)"

i.e create consumer and temporary queue in starup. set jmsreplyto and correlationid for that message.using that correlationid we can get the message easily.

"It also means you can share the same producer & consumer across many threads if you want (or pool them maybe)".

i don't get it what this line is explaing ? in different thread we can access temporary queue ? it doesn't make any sense ? can anyone explain this

1

1 Answers

0
votes

To send out message to the queue we need producer. and read out the message we need consumer.

Lets go with the idea for each thread(not java thread but a sequence of request-response) we setup a separate temporary JMSQueue. This would mean to generate a producer object to the Queue. so the statement means you are creating only one producer object as well as consumer. This would mean for every communication thread you will have multiple producer and consumer and JMSQeueus.

Change the logic and have a unique key assigned to each communication thread. You setup one single JMSQueue, which loads at the startup. Producer object will always have the connection session open to the JMSQueue. We simply call the method of the same producer object and push message to the Queue. Each message will have a correlate/unique id to refer to the communication thread

On the listener end you simply have one listener set for the Queue. The listener only takes the object, parse the particular correlation/unique ID and pass it on to the corresponding thread.