| Author |
Message
|
| umaphani |
 Posted: Tue Jan 22, 2008 3:28 am Post subject: How long connection will be active |
 |
|
Newbie
Joined: 18 Jan 2008
Posts: 4
|
| How much time the connection will be active if the MQ Queue was not closed programmatically? |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Jan 22, 2008 3:31 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
AFAIK until the queue manager is restarted. I'm not certain you can set a disconnect interval on a client channel.
And connections are to the queue manager, not to the queue.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| umaphani |
| Posted: Tue Jan 22, 2008 3:53 am Post subject: |
|
|
Newbie
Joined: 18 Jan 2008
Posts: 4
|
i have written a sample code like this
| Code: |
int openOptions = MQC.MQOO_OUTPUT;
Hashtable env = new Hashtable();
env.put(MQC.HOST_NAME_PROPERTY, "localHost");
env.put(MQC.PORT_PROPERTY, new Integer(1414));
env.put(MQC.CHANNEL_PROPERTY, "testChannel");
qMgr = new MQQueueManager("test", env);
MQQueueManager qMgr = null;
MQQueue q1 =null;
qMgr = new MQQueueManager("test", env);
q1 = qMgr.accessQueue("testQueue", openOptions, null, null, null);
|
after this i am posting message to queue.
but not calling the qmgr.disconnect() method.
since i am not calling qmgr.disconnect(), does this connection will be unavailable for next message or after some time the qmgr will automatically gets disconnected. if so after how much time, it will be available |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jan 22, 2008 3:57 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| umaphani wrote: |
| since i am not calling qmgr.disconnect(), does this connection will be unavailable for next message or after some time the qmgr will automatically gets disconnected. if so after how much time, it will be available |
I stand by my previous post until someone corrects me. AFAIK you can't set a disconnect interval on a client channel.
I think an important question is why are you not calling qmgr.disconnect()?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jan 22, 2008 3:58 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It will be available until the time when you try to use it and it throws an exception that tells you it's not available, or when you call disconnect.
There are timeouts that can be configured on client channels, at the MQ server side or in the network layer (this one is usually frowned on). HeartBeat intervals, Disconnect Intervals, etc.
But generally speaking, it's not your program's concern about that. Assume the connection is open until you decide to close it or it throws an exception that says it's been closed. Then either quit or reconnect, based on what you need to do.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jan 22, 2008 4:09 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jefflowrey wrote: |
| But generally speaking, it's not your program's concern about that. Assume the connection is open until you decide to close it or it throws an exception that says it's been closed. Then either quit or reconnect, based on what you need to do. |
I'd still say it's better to disconnect at the end of the application and explicitly free up the connection than wait for it to time out.
But if you've opened a connection and you're getting/putting as part of your process I agree with my most learned associate that you should assume it's open until you actually close it or get an exception indicating it's been closed.
Experience indicates you're likely to get a 2009 or 2019 long before any timeout interval expires... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jan 22, 2008 4:35 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| Vitor wrote: |
| jefflowrey wrote: |
| But generally speaking, it's not your program's concern about that. Assume the connection is open until you decide to close it or it throws an exception that says it's been closed. Then either quit or reconnect, based on what you need to do. |
I'd still say it's better to disconnect at the end of the application and explicitly free up the connection than wait for it to time out. |
It's not only better, it's the Right Thing to do. Wearing my MQ admin hat, failing to disconnect is #1 on the Trout List for app developers.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Jan 22, 2008 4:46 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| MQ V6 has a client channel inactive disconnect interval. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Jan 22, 2008 5:06 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I'd even go as far as to try a disconnect on a qmgr connection that throws an exception (i.e.) tcp has cut the connection but it is still open on the qmgr...
This on the odd chance that you can close the connection on the qmgr.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jan 22, 2008 1:31 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| zpat wrote: |
| MQ V6 has a client channel inactive disconnect interval. |
The KAINT parm?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jan 22, 2008 1:33 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Vitor wrote: |
| AFAIK you can't set a disconnect interval on a client channel. |
The ClientIdle environmental variable will accomplish this. Distributed platforms only though. And all SVRCONNs on that server get the same value whether you like it or not.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Nigelg |
| Posted: Tue Jan 22, 2008 11:15 pm Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
ClientIdle is a qm.ini parameter in the Channels stanza, not an env var.
If you use CientIdle be aware that is not an officially supported parameter.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| JLRowe |
| Posted: Wed Jan 23, 2008 2:58 am Post subject: |
|
|
Yatiri
Joined: 25 May 2002
Posts: 664
Location: South East London
|
| umaphani wrote: |
i have written a sample code like this
| Code: |
int openOptions = MQC.MQOO_OUTPUT;
Hashtable env = new Hashtable();
env.put(MQC.HOST_NAME_PROPERTY, "localHost");
env.put(MQC.PORT_PROPERTY, new Integer(1414));
env.put(MQC.CHANNEL_PROPERTY, "testChannel");
qMgr = new MQQueueManager("test", env);
MQQueueManager qMgr = null;
MQQueue q1 =null;
qMgr = new MQQueueManager("test", env);
q1 = qMgr.accessQueue("testQueue", openOptions, null, null, null);
|
after this i am posting message to queue.
but not calling the qmgr.disconnect() method.
since i am not calling qmgr.disconnect(), does this connection will be unavailable for next message or after some time the qmgr will automatically gets disconnected. if so after how much time, it will be available |
From a java perspective:
The QueueManager class has a finalize() method that closes itself down, this will be called by the garbage collector after the object goes out of scope, but before it is garbage collected.
It is however bad practice to rely on finalization. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jan 23, 2008 8:59 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Nigelg wrote: |
| ClientIdle is a qm.ini parameter in the Channels stanza, not an env var. |
Oh yeah. 
So it effects all the SVRCONN channels on a Queue Manager equally. Other QMs that might be on the same server would not be effected.
Personally I would not use it. Its not official like Nigel said (although a lot of official features nowadays probably started out like that). More importantly you don't get a "ClientIdle" specific reason code when your connection is dropped.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| MucheIsMyHero |
| Posted: Wed Jan 23, 2008 11:56 am Post subject: |
|
|
Novice
Joined: 29 Jun 2005
Posts: 14
|
| jefflowrey wrote: |
It's not only better, it's the Right Thing to do. Wearing my MQ admin hat, failing to disconnect is #1 on the Trout List for app developers. |
THANK YOU. |
|
| Back to top |
|
|
|
|
