| Author |
Message
|
| rickwatsonb |
 Posted: Tue Jul 28, 2009 6:06 am Post subject: Atypical MQ Implementation |
 |
|
Voyager
Joined: 15 Aug 2006
Posts: 87
Location: USA: Mid-West
|
Hi,
I am a novice at MQ, and would appreciate hearing from experienced users/admins concerning the implementation of MQ described below. Also, any general advice as to what to propose to management would be appreciated.
We have a contractor’s implementation of MQ running in production; they still have control over the project and code. I am analyzing their implementation and have found, after weeks of digging and reading the MQ forum and MQ documentation, that the contractor’s implementation of MQ is atypical (does not follow current MQ documentation).
The application was written with JMS in 2002, I believe relative to MQ 5.3. We are currently on Solaris 10 with MQ V6.0.2.0.
Per JVM instance (application instance per server), there is one singleton (one call to a constructor at app startup) which holds one connection. The connection is never closed; it is reused. The only usage of “close” that I see in their code is for the sender and receiver; the session and connection are never closed. There is no channel pooling.
The KeepAlive parameter in the qm.ini file is not set, thus it appears that there is no channel cleanup, and the closing of inactive channels is only accomplished with a recycle of the queue manager. For example, recently, in production, there were twenty channels started two months ago, and were last used two months ago. These persisted until the queue manager was recycled.
Because the app was written to reuse the channel, my guess is that using KeepAlive in the qm.ini file would alter their implementation, and possibly alter it in a detrimental way. Do you agree?
Is the implementation of channel reuse in this way actually atypical, or is this common for apps that were written pre-channel pooling?
I am currently contemplating what to propose to management, and what to do once the project is under our control. A re-write of the code to upgrade it to current technical methods will most likely not occur.
Thanks for your time and insight. |
|
| Back to top |
|
 |
| zpat |
| Posted: Tue Jul 28, 2009 7:27 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Keepalive does not close inactive channels - it releases ones where the other end has gone away and does not respond.
In my experience this value can and should be applied in all cases, as it does not terminate connections which are actually valid. |
|
| Back to top |
|
|
| rickwatsonb |
| Posted: Tue Jul 28, 2009 7:47 am Post subject: |
|
|
Voyager
Joined: 15 Aug 2006
Posts: 87
Location: USA: Mid-West
|
Thank you for your response zpat.
Is it accurate to say then that TCP KeepAlive will close orphaned channels?
Thanks |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Jul 28, 2009 7:57 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Depends how you define "orphaned", but I would assume so.
It's another of those features that should be on as default in my view along with TRIGINT and so on. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jul 28, 2009 8:13 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| It's perfectly reasonable for a long running application to open one connection to a queue manager and keep it open. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jul 28, 2009 12:29 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| rickwatsonb wrote: |
Thank you for your response zpat.
Is it accurate to say then that TCP KeepAlive will close orphaned channels?
Thanks |
TCP Keep Alive will not shutdown valid client channels, regardless of how long it has been since the last MQ API call was issued over them.
An environmental variable called ClientIdle will close inactive but otherwise valid client channels. However it does so without any special message in the logs or unique error code returned to the app, so it makes debugging client connection problems especially tough.
ClientIdle should rarely be used. TCP Keep Alive should always be used. Don't forget that the qm.ini parm only tell the the QM to use the system's TCP Keep Alive value. So make sure the system has it set, and probably knock it down from the default of 2 hours.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Jul 28, 2009 10:24 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Like I said - Keepalive does not close inactive channels.
Why do people not read the earlier posts? |
|
| Back to top |
|
|
| rickwatsonb |
| Posted: Wed Jul 29, 2009 5:28 am Post subject: |
|
|
Voyager
Joined: 15 Aug 2006
Posts: 87
Location: USA: Mid-West
|
Hi,
Thank you all for your replies; they have been very enlightening.
Is there a specific state/substate that will be displayed in MQ Explorer for channels where TCP KeepAlive is applicable? Specifically, in reference to figure 29 of the Websphere MQ V6 Intercommunication manual, is there a state/substate that applies to channels that should be closed by TCP KeepAlive?
Thank you |
|
| Back to top |
|
|
|
|
