| Author |
Message
|
| hopsala |
 Posted: Wed Jul 28, 2010 2:08 am Post subject: dotnet client & heartbeat interval |
 |
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
Ok, so I have a dot net client that connects to a qm and GET_WAITs. In our DRP experiments, we restarted the machine and saw that it takes 5 minutes for the client to get CONNECTION_BROKEN. This is understandable, as the SVRCONN has a HBEAT value set to a default 300 secs, meaning 5 mins.
So I'm trying to get the client to recognize the disconnect in 30 secs. I changed the heartbeat value on the SVRCONN side to 30 secs, but still got a 5 min delay, so I'm assuming the client and the SVRCONN negotiate for the higher value. I also tried changing the SharingConversations parm from 10 to 0, but to no avail.
What I can't seem to be able to do is set heartbeat interval on the client side (in dotnet; I know how to do this in other languages). Hopefully I'm even on the right track here. I've scoured the internet, but no dice. I'd give my right kidney for a code sample.
Oh, and while we're at it, does anyone have an estimate of the performance degradation between HBEAT=300 and HBEAT=30 ? I'm guessing it's negligible, but it's just a guess.
Thanks |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed Jul 28, 2010 2:39 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Are you using a CCDT? Are you using an MQCONNX equivalent from DotNet?
Or are you using the default clntconn created when you do not use any method of specifying the definition of the clntconn half of the connection? |
|
| Back to top |
|
|
| hopsala |
| Posted: Wed Jul 28, 2010 4:20 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
Default method:
| Code: |
| MQQueueManager qm = new MQQueueManager("QM1" , "SYSTEM.DEF.SVRCONN", "hostdnsname:1414"); |
Had I been using the CCDT this would've been easily accomplished, but using a CCDT is not an option at this stage of the project.
Last edited by hopsala on Wed Jul 28, 2010 4:28 am; edited 1 time in total |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jul 28, 2010 4:28 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I don't think you can adjust the properties of the default CLNTCONN without using MQCONNX or a CCDT.
That is, I believe it is not possible to change the properties of the default CLNTCONN, including what it thinks is HBINT.
You will need to use MQCONNX or a CCDT to accomplish this.
You can see if you can adjust the properties of the MQQueueManager object in some way to change what the HBINT is, but I doubt this will work...
You might be able to do something with the mqclient.ini if you're using v7 - but I'm not positive on that either. |
|
| Back to top |
|
|
| hopsala |
| Posted: Wed Jul 28, 2010 4:48 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| mqjeff wrote: |
| You might be able to do something with the mqclient.ini if you're using v7 - but I'm not positive on that either. |
I'm not familiar with mqclient.ini. I'll read about it.
| mqjeff wrote: |
| I don't think you can adjust the properties of the default CLNTCONN without using MQCONNX or a CCDT... You will need to use MQCONNX or a CCDT to accomplish this. |
I agree. From what I gather, barring CCDT I have two options - use MQEnvironment or an options hashtable. MQEnvironment doesn't seem to have a heartbeat method or member (or I can't find it), so I've got just the hashtable option left, in this manner, adapted from the MQ7 lit:
| Code: |
Hashtable connectionProperties = new Hashtable();
connectionProperties.Add(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_CLIENT);
connectionProperties.Add(MQC.HOST_NAME_PROPERTY, hostName);
connectionProperties.Add(MQC.CHANNEL_PROPERTY, channel);
MQQueueManager qMgr = new MQQueueManager(qManager, connectionProperties); |
...But I can't for the life of me find a parameter in MQC to set heartbeat interval. Granted, MQC is supposedly deprecated (although it appears in the code samp in the lit) and I should be using MQConstants, but I can't find a heartbeat parm in MQConstants either.
I did find MQConstants.MQCHSSTATE_HEARTBEATING, which the lit eloquently explains is "Channel substate - HEARTBEATING", but I'm not sure if that's it or how to use it.
Lastly, There's MQConstants.MQIACH_KEEP_ALIVE_INTERVAL, which again I'm not sure whether I should be using and how. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jul 28, 2010 6:12 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I don't think you can tweak this with the Hashtable. 
That is, I don't think there's an MQC property that matches MQIACH_HB_INTERVAL, and I'm almost twice as sure that you can't just add a manual key of 1563 and the value you want and have it populated.
The hashtable is not a direct map to the MQCD structure. |
|
| Back to top |
|
|
| hopsala |
| Posted: Wed Jul 28, 2010 6:27 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
Well, you did say something about using the MQCONNX equiv in dotnet, but I'm not sure what you meant...?
Do you reckon I'm pointing in the right direction? Do you know if it is indeed the case that the client and svrconn negotiate an hbint value and choose the higher one? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jul 28, 2010 7:06 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I wasn't thinking of the hashtable when I mentioned an MQCONNX equivalent. I don't really write .NET code... so I can't say that there really is an MQCONNX equivalent unless there is a direct exposure of MQCONNX through a non-OO interface. I know VB used to expose a procedural interface. Maybe .NET doesn't?
The HBINT parameter is valid on CLNTCONN channels, and there is discussion of use with server-conn/client-conn pairs in the description of the field. http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=/com.ibm.mq.csqzaj.doc/sc11040_.htm
As to how any negotiation between differing values on both sides is handled, I'm sure that's in the Intercomm or Clients manual somewhere. |
|
| Back to top |
|
|
| hopsala |
| Posted: Wed Jul 28, 2010 8:48 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| mqjeff wrote: |
| I don't really write .NET code... |
Me neither..
| mqjeff wrote: |
| so I can't say that there really is an MQCONNX equivalent unless there is a direct exposure of MQCONNX through a non-OO interface. I know VB used to expose a procedural interface. Maybe .NET doesn't? |
The only mention of MQCONNX in the "using .net" lit is about the constructor:
| Code: |
| public MQQueueManager(String queueManagerName, int options) |
but options can only be used to determine binding type (fast/standard).
There is also mention that KAINT (keep alive interval) is inoperational in a distributed-to-distributed scenario, so that doesn't solve it either.
| mqjeff wrote: |
| As to how any negotiation between differing values on both sides is handled, I'm sure that's in the Intercomm or Clients manual somewhere. |
I'll look it up.
So, bottom line is that the only way to control HBINT in dotnet is CCDT? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jul 28, 2010 8:50 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| hopsala wrote: |
| So, bottom line is that it seems like the only way to do it in dotnet is CCDT? |
unless there's something in .NET that's not obvious. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed Jul 28, 2010 5:11 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
Heartbeat from the client side is only available in MQ v7.0 and above, as the client protocol because fully asynchronous in this version.
_________________
Glenn |
|
| Back to top |
|
|
| hopsala |
| Posted: Thu Jul 29, 2010 1:09 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
From the MQ explorer reference:
"The (heartbeat interval) value that is used is the larger of the values specified at the sending side and the receiving side. "
So in dotnet HBINT is always 300secs if you don't use a CCDT. That's a pretty major limitation, and I gotta say, I don't really see why there's no HBINT in MQConstants..
Concerning KAINT, in http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=/com.ibm.mq.csqzaj.doc/sc11040_.htm it says this:
| Quote: |
| Although this parameter is available on all platforms, its setting is implemented only on z/OS. On platforms other than z/OS, you can access and modify the parameter, but it is only stored and forwarded; there is no functional implementation of the parameter. This is useful in a clustered environment where a value set in a cluster-receiver channel definition on Solaris, for example, flows to (and is implemented by) z/OS queue managers that are in, or join, the cluster. |
I'm not sure what is meant here by "stored and forwarded". Do they mean that the parm value is forwarded to the TCPIP service in windows/unix, but the service itself has to do the actual heartbeating? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jul 29, 2010 2:04 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
From the part of the docu you copied it seems that stored and forwarded really only applies to clusters where there is a zOS member that can take advantage of it. So you set the parameter on the cluster receiver in distributed and it gets implemented by the zOS cluster sender...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jul 29, 2010 2:23 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| But otherwise, yes, the KAINT value is not implemented by MQ on distributed platforms. It's implemented by the OS/tcpip stack, and has to be enabled at the OS/tcpip stack. The value you set in MQ is provided to the OS/tcpip stack. Whether or not it honors that is a separate question. |
|
| Back to top |
|
|
| hopsala |
| Posted: Thu Jul 29, 2010 4:22 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| fjb_saper wrote: |
| From the part of the docu you copied it seems that stored and forwarded really only applies to clusters where there is a zOS member that can take advantage of it. So you set the parameter on the cluster receiver in distributed and it gets implemented by the zOS cluster sender... |
I'm not sure that's what it means. I think clustering is just an example, and that in any scenario in which one side is zOS and the other is distributed, the KAINT flows to and activates the zOS keepalive. I may be wrong, though; it's a pretty vague paragraph..
| mqjeff wrote: |
| The value you set in MQ is provided to the OS/tcpip stack. Whether or not it honors that is a separate question. |
And from your, or others, experience, does WinXP honor KAINT? Any gotchas I should be aware of? |
|
| Back to top |
|
|
|
|
