| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| JMS Architecture Question |
« View previous topic :: View next topic » |
| Author |
Message
|
| bergc |
 Posted: Wed Feb 01, 2006 9:18 am Post subject: JMS Architecture Question |
 |
|
Newbie
Joined: 01 Feb 2006
Posts: 3
Location: TEXAS
|
Hi,
I have an synchrounous JMS application connectiing to MQ queues(WMQ5.3 Linux), putting the request and doing a timed receive on the response queue using corr ID.I am planning to implement this a java bean as there could be multiple reveivers on the response queue.
My question is is it possible to acheive the same functionality using the JSM pub/sub feature like making the application subscribe to the response queue after putting the request, of course each subscriber with a unique selector.
And if possible, would this give any performance advantages( apart from the message selection occuring at the provider rather than the client).And would we see any improvements in resource consumption like number of connections help up etc.
PS.I am aware synchronous design is mot ideal for MQ, But it cant be helped. 
Thanks.
Berg |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Feb 01, 2006 9:48 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
um.
Pub/Sub is one-to-many, or many-to-many. Request/reply is one-to-one, or many-to-one.
Trying to make Pub/Sub act in a -to-one mode is not worth it, in my opinion.
But you might look at the logical nature of your requests, and the logical nature of the replies. Are the replies, in particular, some kind of notification of an event that occured, rather than some kind of transformation of the request message?
There may be some ways to reconfigure your thinking about the data, such that the data makes sense as an event rather than a reply.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| bergc |
| Posted: Wed Feb 01, 2006 11:49 am Post subject: |
|
|
Newbie
Joined: 01 Feb 2006
Posts: 3
Location: TEXAS
|
Thanks for the response Jeff.
As to your question about the nature of the replies, each message carries the result of a query on a DB.
I do understand what you saying about the one-to many and one-to-one.But changing the serving application is out of the scope of the current architecture review.It queues all the responses into a single queue( may be into multiple but only for load balancing).Even if I had the choice of revamping the servicing app, considering the nature of the replies,I dont think it lends itself too well into pub/sub paradigm(?).
The decision I have to make is how the receives going to happen.The concern I had about the timed receivers is that with multiple receivers on a single queue there seems be substantial performance degradation.For that reason I was thinking about making the receivers subscribe to the queue. My hope was that since the broker was invloved it would be a better option in terms of scalability and performance.
Berg. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Feb 01, 2006 12:09 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You couldn't switch the client app to pub/sub without switching the server to pub/sub.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Feb 01, 2006 1:25 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Quote: |
| The decision I have to make is how the receives going to happen.The concern I had about the timed receivers is that with multiple receivers on a single queue there seems be substantial performance degradation |
I believe you must first look into why you are getting the performance degradation. Maybe you are using JMS for the Correlation ID selection.
Read the manuals. Depending on how you do the CorrelationID selection in JMS there is significant performance changes to be observed.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
