What is better for a JMS request/response pattern?

[theoverlord]

What is better for a JMS request/response pattern?

* Temporary queue
* Topic with message selector

I've used both and I haven't actually measured performance with both but I've read that the topic/selector approach is superior.

[clebert.suconic]

I don't know your complete use case, but Temporary Queue is better.

Topic -> your message would probably be sent to other internal queues that don't need to know about your message. And besides selector has some performance implications.


So... temporaryQueue is your choice.

[timfox]

How long is a piece of string?

[theoverlord]

The request is an object (not string) but it's not a huge object.

The reply on the hand can be pretty big with other embedded objects.

[timfox]

I don't know your complete use case, but Temporary Queue is better.

Topic -> your message would probably be sent to other internal queues that don't need to know about your message. And besides selector has some performance implications.


So... temporaryQueue is your choice.

Topic subscription selectors are evaluated before the message gets to the subscription so they never go to any queues that don't need to know about your message.

Selector really only has performance problems on a queue, not a topic.

[theoverlord]

So which one is better for high volume traffic ?

I've heard numerous discussions on this subject and some people believe that a topic with a message selector is better.

Here's what I think.

There's a performance penalty for creating/destroying temporary queues and each one created consumed resources.

With the topic approach, you just create it one (statically) and you're done.

There might be some performance hit because of the message selector but as Tim said, it's negligible.

So it appears on paper, that Topics with message selector is better.

[bodrin]

http://extentech.sys-con.com/node/49089