| Author |
Message
|
| George Carey |
 Posted: Tue Feb 21, 2012 2:30 pm Post subject: client channel time outs for inactivity |
 |
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Ok, refreshing my memory (which apparently was never clear on this)
Dealing with Linux platform using client (mqi) channels.
What can be used to timeout/disconnect idle/stale client channels:
KAINT --- is attribute used in z/OS only according to old/and new documentation. As KAINT is meaningless for client channels on Linux, therefore AUTO or any other value is meaningless as well (why is that and active field in the MQExplorer for distributed platforms?)
TCP: stanza in qm.ini for KeepAlive=Yes does what then in Linux land?
This is what doco says:
| Quote: |
KeepAlive=NO|YES
Switch the KeepAlive function on or off. KeepAlive=YES causes TCP/IP to check periodically that the other end of the connection is still available. If it is not, the channel is closed. |
So what is check periodically time ? The Linux OS TCP/IP keepalive time??
Is the HBINT the only thing for client channel setting on Linux?
It is stated to be best set to be much less than disconnect interval!
The infocenter v7.1 on DISCINT states it is an attribute that can be set on sever-connection channels ---???? where ???
Disconnect interval (DISCINT) ...
This attribute is valid for channel types of:
•Sender
•Server
•Server connection
•Cluster sender
•Cluster receiver
I do not see it in MQExplorer(v7) or properties of a SRVCONN channel???
Is the undocumented Channel stanza parameter for ClientIdle the only thing that can give granular MQ only control of client channel disconnection on Linux(distributed) platforms?
Trying to finally understand this BS.
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue Feb 21, 2012 2:51 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
DISCINT certainly shows up in the Extended pane on SVRCONN properties in MQExplorer for MQ 7.1 - not, mind you, for MQ7.0 explorer.
So it's reasonably safe to assume, probably backed up by documentation, that DISCINT is new to SVRCONNs in MQ 7.1.
KeepAlive always defers the configuration of the KeepAlive timeout to the OS level network handling, not to the queue manager. Well, at least on all distributed platforms. So, yes, the Linux OS TCP/IP Keepalive time is the one in effect. |
|
| Back to top |
|
|
| George Carey |
| Posted: Tue Feb 21, 2012 3:19 pm Post subject: Prior to 7.1 |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
OK, prior to MQ v 7.1 for Linux(distributed) platforms using client(mqi) channels is the only way for MQ admin to control disconnection of stale/idle client channels via the ClientIdle parameter of Channel stanza in qm.ini?
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Feb 21, 2012 6:16 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Define what a 'stale' or 'idle' client channel is to you.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| George Carey |
| Posted: Wed Feb 22, 2012 5:52 am Post subject: definition of idle |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
One that the last message time has not changed in a designated window of time and that time is agreed upon by the application architect, the network architect and the MQ architect . This is just what the ClientIdle parameter keys off.
Don't care if application has connection open or not ... if it does it is an application bug(forgot to close it or took an error path that did not close it, etc.) and needs to renew its connection.
Period the end.
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| George Carey |
| Posted: Fri Feb 24, 2012 10:23 am Post subject: Are we done? |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
OK, trying one more time.
No more takers on this question?
| Quote: |
| OK, prior to MQ v 7.1 for Linux(distributed) platforms using client(mqi) channels, is the only way for MQ admin to control disconnection of stale/idle client channels via the ClientIdle parameter of Channel stanza in qm.ini? |
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Feb 24, 2012 10:35 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
That was the only way I know of inside base MQ for that version of MQ given your definition of stale / idle connections.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| George Carey |
| Posted: Fri Feb 24, 2012 10:52 am Post subject: Got another? |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Ok, playing the devils advocate, here.
Given, that you are on a Linux platform and use prior to MQv7.1 client (mqi) connections, give another definition for stale or orphaned connections and the configuratoin settings other than ClientIdle that an MQ admin can use to control the termination of those connections with those configuration settings.
(And KeepAlive = yes doesn't count ... since it just defers control to the Linux admin)
GTC
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Feb 24, 2012 10:58 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
The Java client app goes away ungracefully, leaving behind an MQ Client channel instance running on the QM side. Another definition of a stale or idle channel. In this case, TCP Keep Alive saved the day, if you told the QM to use the O/S's Keep Alive, and the O/S had it turned on.
I know of no other way built into the product to handle that situation.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| George Carey |
| Posted: Fri Feb 24, 2012 11:26 am Post subject: Agreement |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Ok, thank you ... that was/is my contention.
That complete smoke screen of options and settings that exist, such as HBINT, disconnect interval, KAINT, ya da, ya da, ya da, are all so much BS for client (mqi) channels on distributed platforms prior to MQv7.1.
Only to allow the TCP/IP keepalive setting to have effect on your channels or not ... that was it.
All the KAINT values even though actively setable in any MQ Explorer have no use whatsoever on distributed platforms. One might see why I call all these a smoke screen.
Why are so many features in the z/OS MQ and not in distributed MQ? Never mind all the shared queue sysplex stuff, how about all the non-hardware related differences in the feature benefits. Does IBM just have smarter/better z/OS coders than distributed platform coders?
A rhetorical question!
GTC
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Feb 24, 2012 11:30 am Post subject: Re: Agreement |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| George Carey wrote: |
| Why are so many features in the z/OS MQ and not in distributed MQ? |
Why so many features in z/OS and not in distributed? Because it's inherently better, smarter, faster, more robust, more secure and just plain better! I remember this time in 1984.....
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| George Carey |
| Posted: Fri Feb 24, 2012 11:35 am Post subject: Unbiased! |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
| Quote: |
| Because it's inherently better, smarter, faster, more robust, more secure and just plain better! |
A dispassionate unbiased assessment if ever I heard one! 
GTC
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Feb 24, 2012 11:37 am Post subject: Re: Agreement |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| George Carey wrote: |
| Why are so many features in the z/OS MQ and not in distributed MQ? |
Much more hardware and o/s availability on z/OS and zArchitecture.
| George Carey wrote: |
| Does IBM just have smarter/better z/OS coders than distributed platform coders? |
Far more business transactions (dollare, Euros, etc.) traverse z/OS than traverse Win/UNIX, surveys show.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Feb 24, 2012 11:41 am Post subject: Re: Unbiased! |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| George Carey wrote: |
| A dispassionate unbiased assessment if ever I heard one! |
Absolutely; far above the tyranny of mere "fact". 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| George Carey |
| Posted: Fri Feb 24, 2012 11:45 am Post subject: Bingo! |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
| Quote: |
| Far more business transactions (dollare, Euros, etc.) traverse z/OS than traverse Win/UNIX, surveys show. |
Aha! Bingo! There you go! Follow the money, that indeed sounds like the most likely reason. It would be nice to see the feature set where possible pushed to all the code bases!
But again that may be a contra(money)intuitive thing to do!
GTC
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
|
|
