| Author |
Message
|
| issac |
 Posted: Mon Mar 14, 2011 6:59 pm Post subject: MQ 7 does not close dynamic queue by closing MessageProducer |
 |
|
Disciple
Joined: 02 Oct 2008
Posts: 158
Location: Shanghai
|
Hello, guys
I've verified the following on WMQ 7.0.1.3 for AIX:
After running the following method, I call Thread.sleep(100000) before calling session.close() and connection.close().
According to what I have observed, OPPROCS value is 1 for the temporary queue created bellow, EVEN THOUGH the producer is already closed.
| Code: |
private void repeatedlySendMessage(MQQueueConnection connection, MQQueue requestQ, MQQueueSession session) throws JMSException {
MessageProducer msgProducer = session.createProducer(requestQ);
//connection.start();
// 设定动态队列作为反馈队列
TemporaryQueue responseQ = session.createTemporaryQueue();
DevLog.debug("DynamicQ created.");
//Pauser.pauseThread(1000);
// 发送一条请求消息
Message requestMsg = session.createMessage();
//requestMsg.setJMSReplyTo(responseQ);
msgProducer.send(requestMsg);
// 关闭资源
//responseQ.delete();
msgProducer.close();
DevLog.debug("resource closed.");
}
|
So why? isn't the queue meant to be closed after closing the producer? If not how could I close the temporary queue?
_________________
Bazinga! |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon Mar 14, 2011 8:11 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Check it in the documentation but I believe that the lifetime of the temporary queue is the lifetime of the session that created it as long as you do not explicitly delete it.
Note that your responseQ.delete() is commented out.
So the lifetime of that queue is the rest of the lifetime of the session that created it. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| issac |
| Posted: Tue Mar 15, 2011 9:51 pm Post subject: The Q is not meant to be deleted. Closing the Q is all. |
|
|
Disciple
Joined: 02 Oct 2008
Posts: 158
Location: Shanghai
|
Hi,! Thanks for the reply.
But closing the queue is not what I desire. The Q is meant for another application to put some msg inside, thus not suitable for deletion.
You may question then why I wish to close the Q; it's because I wish to decrease the number of handles to the QMGR by eliminating unecessary ones.
Regardless of the reason why I wish to close it, shouldn't I be able to close the temporary Q anyway? Isn't this what MQ shall be capable of?
_________________
Bazinga! |
|
| Back to top |
|
|
| issac |
| Posted: Tue Mar 15, 2011 9:54 pm Post subject: More to the spiderman... |
|
|
Disciple
Joined: 02 Oct 2008
Posts: 158
Location: Shanghai
|
Hi again, spiderman,
You're right that lifetime of the temporary Q is as long as its deletion or termination of the process, depending which one is shorter. BUT, I don't think lifetime of the Q is identical to how long my APP shall open the Q, right?
I desire the state: when the temporaryQ still exists, but without a handle, neither output nor input, from my app. I'm trying to achieve this by closing the Q.
_________________
Bazinga! |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Mar 16, 2011 12:05 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
So don't create a temporary dynamic queue, create a permanent dynamic queue? I'm not a developer so this question is by way of trying to understand the mechanics of it.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Mar 16, 2011 3:16 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If you want a queue to exist independently of whether or not an app is writing messages to it or reading messages from it, then you should strongly determine why you are using a DYNAMIC queue at all.
If it is only to avoid using PCF messages inside your app to create the queue, then ask why you are creating the queue inside your app instead.
Why do you want to use a dynamic queue instead of a qlocal? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Mar 16, 2011 1:04 pm Post subject: Re: More to the spiderman... |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| issac wrote: |
Hi again, spiderman,
You're right that lifetime of the temporary Q is as long as its deletion or termination of the process, depending which one is shorter. BUT, I don't think lifetime of the Q is identical to how long my APP shall open the Q, right?
I desire the state: when the temporaryQ still exists, but without a handle, neither output nor input, from my app. I'm trying to achieve this by closing the Q. |
To close the queue you correctly close the producer. There is nothing else to do.
If you can prove that YOUR producer is still holding the queue open, open a PMR (trouble ticket) with IBM. Remember however to account for any uncommitted transaction before you do that.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Thu Mar 17, 2011 5:17 am Post subject: Re: MQ 7 does not close dynamic queue by closing MessageProd |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| issac wrote: |
| isn't the queue meant to be closed after closing the producer? |
No. The msgProducer never opened the response queue; how could it close it?
| issac wrote: |
| I desire the state: when the temporaryQ still exists, but without a handle, neither output nor input, from my app. |
Temporary dynamic queues with no open handles get deleted. That's what "temporary" means. More precisely, the handle returned when creating a temporary dynamic queue must remain open for the lifetime of the queue; closing it will automatically delete the queue.
Even if the underlying queue were a permanent dynamic queue, the only methods that JMS provides for closing this handle are TemporaryQueue.delete() and Connection.close(), both of which will also delete the queue. (Note that the lifetime of a TemporaryQueue is that of the Connection, not the Session, unless the TemporaryQueue is deleted earlier.)
A typical sequence of events within a session are:- create producer for request queue
- create temporary response queue
- create consumer for response queue
- create request (with replyto response queue)
- send request
- close producer
- receive response
- close consumer
- delete temporary response queue
- close session
|
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Mar 17, 2011 7:05 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Thanks for the precision. I take it that this means you can share the temporary queue across sessions as long as the connection is alive.
Can you also share it across connections as long as the connection that created it is alive and in a "good" state?
What issac seems to be doing is creating the dynamic queue and never using the reference again... I guess this is just wrong (as a waste of resources)...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Thu Mar 17, 2011 3:04 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| fjb_saper wrote: |
| I take it that this means you can share the temporary queue across sessions as long as the connection is alive. |
Yes. A connection that creates a temporary queue can share it across all of the sessions it creates, for as long as the queue exists. If the connection is no longer alive, then neither are its sessions, or temporary queues.
| fjb_saper wrote: |
| Can you also share it across connections as long as the connection that created it is alive and in a "good" state? |
Not exactly. Only the connection that creates a temporary queue can create consumers for it, but other connections can create producers for it, for as long as the queue exists.
| fjb_saper wrote: |
| What issac seems to be doing is creating the dynamic queue and never using the reference again ... |
Either that, or he just didn't post the code that uses the queue. |
|
| Back to top |
|
|
|
|
