CODEWITHSUNDEEP
javaperformancejmsactivemq-classicmessaging
weston
weston

Reputation: 2908

Will issuing a temporary queue per request vs per session affect performance?

I've been looking at some server-side Java which uses JMS to interface with the ApolloMQ message broker. Clients make synchronous requests with this server by doing the following:

  1. Create a temporary queue used to receive the response
  2. Send request to the standard request queue with 'reply-to' pointing to the new temporary queue
  3. Wait for the response on the temporary queue
  4. Delete the temporary queue and repeat

It seems like issuing a new temporary queue for each request may be expensive for the message broker, and likely introduces an additional round trip for each request in order to first create the temporary destination. I don't want to spend a bunch of time verifying this myself and I was kinda hoping someone in the know could confirm this intuition. Would it be better to instead create a single temporary queue per client session and use the message/correlation id to match responses to requests?

Upvotes: 0

Views: 866

Answers (2)

Beryllium
Beryllium

Reputation: 12988

Look at it from the performance perspective: Is a message broker optimized for sending/receiving messages or to create/remove queues?

Likewise databases are not optimized to create and drop tables on the fly; it's insert/update/delete.

So I would go the "correlation ID" way.

Update

This does not necessarily mean to put the responses in the same queue as the requests. You could have one queue for each client/session.

Upvotes: 2

Jakub Korab
Jakub Korab

Reputation: 5024

Using correlationIDs involves using selectors on message queues - this is slower than creating a temporary queue for the purposes of request response (see "Request-reply over JMS" at http://camel.apache.org/jms.html for a comparison of the various options).

Upvotes: 1

Related Questions