| Author |
Message
|
| dwitherspoon |
 Posted: Tue Jul 27, 2004 9:18 am Post subject: Can I create a permanent dynamic queue from JMS? |
 |
|
Acolyte
Joined: 09 Dec 2003
Posts: 59
|
Hi Folks,
Can I create a permanent dynamic queue from JMS? I saw in the "Using Java" guide (here) that I can call QueueSession.createTemporaryQueue. And then when I go to create the QueueSender, I can, through the MQQueueConnectionFactory, make a call to setTemporaryModel. But there is a line in the doc for this method that warns
| Quote: |
| We recommend that this is the name of a temporary dynamic queue, rather than a permanent dynamic queue. |
Does this just not work? Why do they suggest not using permanent dynamic queues?
If that doesn't work, can I just go through MQI directly to create the perm dyn queue, and then let JMS do the open on it as a normal queue once the name is known?
Any input would be helpful...I think this feature is going to solve a pretty major issue for me.
_________________
Good...Fast...Cheap. Choose any two. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Jul 27, 2004 9:30 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
DWitherspoon wrote
| Quote: |
| We recommend that this is the name of a temporary dynamic queue, rather than a permanent dynamic queue. |
The reason for such a recommendation are pretty obvious.
The purpose of a dynamic queue is to get created by the client application for its own purposes. It usually is not a shared queue.
Creating a dynamic permanent queue means that your application needs to remember the queue name possibly beyond a reboot of the box. If that is the case, why not create a permanent queue for the application. There is no point then of having a dynamic permanent queue.
The dynamic temporary queue however does not live beyond the lifetime of the client application that created it. It is popular in the request response model.
Enjoy |
|
| Back to top |
|
|
| dwitherspoon |
| Posted: Tue Jul 27, 2004 10:23 am Post subject: How's that work? |
|
|
Acolyte
Joined: 09 Dec 2003
Posts: 59
|
Thanks for the feedback...you make some good points.
I have not been interested in temporary dynamic queues because of concern than they will not survive an MQ reboot. Here's the scenario I'm concerned about:
1. I want to send a message to some application, so I create a temporary queue for the response.
2. I build up my message to send, and include as reply-to information the name of the temporary queue I created.
3. I send the message.
4. My MQ box explodes, requiring a reboot. The temp queue is gone.
5. The other application has replied to the temp queue I initially created.
So, my thought was to create a permanent dynamic queue instead. Why not just create a regular permanent queue? We'll probably have 200 of these, so that's 200 things our MQ admin doesn't have to do. In our hosting center, the admins are understaffed and overworked. If I can have them create a model queue one time and get it right, then I can create hundreds of permanent dynamic queues correctly from my code, and therefore get less calls in the middle of the night.
That said, will permanent dynamic queues work with JMS?
_________________
Good...Fast...Cheap. Choose any two. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jul 27, 2004 10:28 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Why do you need 200 separate queues?
Why do you need a response message after a catastrophic failure that likely significantly impacted your requesting application?
All MQ Administrators are over worked. If you really want to help, write a program that will use the PCF Classes for Java to create the queues you need, and make them "right the first time".
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| dwitherspoon |
| Posted: Tue Jul 27, 2004 10:50 am Post subject: |
|
|
Acolyte
Joined: 09 Dec 2003
Posts: 59
|
Why do we need 200 queues? Because we will have 200 client installations in a hosted environment. Each of those systems belongs to a paying client, and each of those systems is going to share resources on an MQ server.
Our first approach was to have all 200 share an inbound queue and use a message selector to pull out the messages that each client system cares about. That performs like a dog. So now we're thinking that it would be better to create a separate reply queue for each of the 200 client systems. That would get rid of selectors. But then that would have the admins managing 200 queues...which took us to permanent dynamic queues.
Why would I need a response after a failure? Because this is a stateful system. The client database records that the request has gone out, and remembers the correlation ID. He's going to be expecting a response with that same correlation ID. The fact that MQ fell over and came back up is immaterial. The response is coming from a remote site, and they will respond on the queue that I told them to reply on.
I'd like to use temporary dynamic queues, but if it's not going to be there across restarts, then they don't fit our architectural model. In the end, what's the difference between a permanent dynamic queue and a regular permanent queue, apart from how they are created?
So, back to the original question...is there some technical reason why permanent dynmaic queues won't work with JMS?
_________________
Good...Fast...Cheap. Choose any two. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jul 27, 2004 11:04 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Quote: |
Our first approach was to have all 200 share an inbound queue and use a message selector to pull out the messages that each client system cares about. That performs like a dog.
|
Suprising. 200 clients on one queue is not THAT huge a #. If the queue is not filled with orphaned messages, the selection proces should be quick.
Anyway, what about 5 queues, with 40 clients each? Not good enough, what about 10 queues, with 20 clients each?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jul 27, 2004 11:17 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
JMS Selectors, when the selection critieria is NOT the message or correlation ID, are slow, slow, slow. The JMS subsystem has to read each message for each selector.
And lack of orphaned messages doesn't improve this, necessarily. If all 200 requesting applications put out requests at the same time, that means that all 200 selectors are each going to have to process all 200 response messages in order to determine if they should process any of the messages.
Getting back to the original question, there doesn't seem to be any methods in the JMS classes or in the configuration for WebSphere MQ JMS Provider for specifying that a queue is a permanent dynamic queue. So I'd say, no, you can't.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jul 27, 2004 11:24 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I wonder what the selection criteria is? It should be fast enough if the design calls for selecting on the Correl ID, no?
Anyway, if need be, any MQ admin can create 200 local reply queues in about 5 minutes if the shared queue design, regardless of #s, still is not fast enough.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| dwitherspoon |
| Posted: Tue Jul 27, 2004 11:25 am Post subject: |
|
|
Acolyte
Joined: 09 Dec 2003
Posts: 59
|
It looks like through the code I can do it, but I'm not sure if I should do it.
I guess I'm thrown off by the fact that the guide "recommends" that the model queue name given not be a permanent dynamic queue, but it doesn't go so far as to say why. Heck, it could be left over from MQ 5.1 or something.
I may try it just to see what happens...
_________________
Good...Fast...Cheap. Choose any two. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue Jul 27, 2004 1:11 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
And here's my two cents.
200 queues is really not that many. I have worked with queue managers that had thousands of queues. I understand 'MQ Admins' being overworked and I have been on both ends but if 200 queues will give you the performance you need then built the application that way.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| dwitherspoon |
| Posted: Wed Jul 28, 2004 9:21 am Post subject: Permanent dynamic queues are doable |
|
|
Acolyte
Joined: 09 Dec 2003
Posts: 59
|
I've been able to get some information about this through the grapevine. Permanent dynamic queues are supported. The only difference is that if it's a permanent queue, then the MQTemportaryQueue.delete method should be called to destroy the queue after use.
_________________
Good...Fast...Cheap. Choose any two. |
|
| Back to top |
|
|
|
|
