| Author |
Message
|
| scobiej |
 Posted: Wed Oct 22, 2003 1:08 am Post subject: Client timeouts on MQPUT |
 |
|
Newbie
Joined: 22 Oct 2003
Posts: 1
Location: London
|
Is there any way of getting an MQPUT call to timeout before what seems a two minute default if there is a 2009 (MQRC_CONNECTION_BROKEN) error?
I can't believe there is no way of doing this (as IBM are implying). This is also causing grief on the CLOSE.
I am using 5.3 client on AIX talking to a 5.3 server also on AIX. |
|
| Back to top |
|
 |
| chanduy9 |
| Posted: Fri Nov 21, 2003 2:28 pm Post subject: |
|
|
Disciple
Joined: 28 Nov 2001
Posts: 177
Location: USA
|
Hi,
Make sure that you have enough channel handlers. You can update this in the ini file, after that you need re-cycle the queue manager.
Thanks,
Chandra. |
|
| Back to top |
|
|
| JasonE |
| Posted: Mon Nov 24, 2003 2:03 pm Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
Out of interest, have you disabled reverse DNS lookups? Depends on where the hangup is when the problem occurs (and without looking at trace, which IBM might have done, I cant tell) but generally a PUT is effectively a TCP send followed by a TCP recv.
Assuming the send detects the failure (which is usually true), I thought that was normally fairly immediate (may depend on o/s), but I have seen cases where MQ then tries to issue an error message, DNS looks up the ip addr and hangs there for 2 mins (default DNS lookup timeout, I think). |
|
| Back to top |
|
|
| j8mes |
| Posted: Wed Apr 28, 2004 6:22 am Post subject: |
|
|
Novice
Joined: 22 Jan 2004
Posts: 12
|
However I managed to get a reply from IBM on this. It appears the only way to reduce the time you have to wait is reduce the heartbeat inverval. Beware reducing it too low, could mean that the timeout could trigger just because the network was slow. This was IBM's reply:
My apologies James. I did miss your exact point in the original PMR.
Further investigation of the issue revealed that the timeout value for the
MQPUT T is based on a) the heartbeat interval (HBINT) of the SVRCONN
channel, which has a default of 300 seconds, and b) the timeout of the
TCP/IP(select), which is 60 seconds. Adjusting the HBINT for the channel
will impact the timeout. In addition, you are right about the network
considerations for lowering it. Determining the optimum value for the
timeout will be based on judgement of what is best for the situation, all
things considered.
IBM support |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Apr 28, 2004 10:46 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Heartbeats for MQClients only apply for an MQGET issued with a Wait Interval. They do not flow at any other time for an MQClient. I don't see how this setting can help you if your problem is on the MQCLOSE and MQPUT.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| JasonE |
| Posted: Thu Apr 29, 2004 8:12 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
That was my initial reaction as well, and you are correct in that heartbeats only flow during a GET, but that is because it is an operation expected to take some time.
It would certainly appear that the time we allow for a receive of a response to any MQAPI is related to the HBINT value - Very, very unexpected but you learn something new every day!
FYI there is an unsupported way of overriding it, documented in article 3 from http://www-1.ibm.com/support/search.wss?q=MQRCVBLKTO&tc=SW900&rs=172
| Quote: |
2) Set the environment variable (system wide) on the client as
follows;
MQRCVBLKTO=420
This tells mq to abort any recv() calls which take longer than 420
seconds (7 mins). |
You may or may not have success with this option - I make no guarantees as it is unsupported. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Apr 29, 2004 10:20 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
So the INTERVAL of HB is maybe used as a value of when something, anything, should flow across a channel during all calls. On a blocking MQGET, when nothing is otherwised expected to flow, MQ pumps Heartbeats to give activity? But on every other call, the RESULT of the call is the "Heartbeat"?
And if the HB or the result of the call does not come back during the Interval (and not until the Interval expires) is the connection considred broken?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| JasonE |
| Posted: Fri Apr 30, 2004 1:06 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
Thats my understanding from some quick and simple testing I was doing yesterday, although a slight proviso is that it is not the hbint value which is the timeout, but more a value calculated from it (ie to give it time to flow down a slow network).
I havent investigated too far into the code to confirm this occurs for all api calls for example, but it seemed true for the MQPUT api call and I dont see why it wouldnt apply.
So you could view the hbint as a value which relates to the maximum time you would allow for no network traffic on a connection, if this is correct.
And yes, connection broken is returned if this value is hit. My testing held up the PUT request in the network, and waited to see what happened... |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Apr 30, 2004 3:44 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Jason, I found some documentation on this.
From Morag's and Paul's doc on channels:
http://www-1.ibm.com/support/docview.wss?rs=203&uid=swg24006699&loc=en_US&cs=utf-8&lang=en
| Quote: |
Receive Wait Time Out - Notes
A we have already mentioned, the heartbeat interval used by the sending end of the channel to periodically send this heartbeat message, is a negotiated value, so both ends know what the value is. Without a heartbeat the receiver end of the channel can not predict when the next piece of data should arrive down the channel since the arrival of messages is non-deterministic. However, with a heartbeat the receiver 'knows' that within the heartbeat interval either a message or a heartbeat should arrive. If it doesn't then the communications session must have broken. This is used as the basis for TCP/IP network failure recognition. For CLNTCONN channels, this time-out is also used while waiting for a response to an MQI command (except when the SVRCONN is on z/OS which does not support the client variant of heartbeats).
The receiver will actually time-out if no data is received within twice the Heartbeat interval if the negotiated Heartbeat Interval is less than 60 seconds, or 60 seconds beyond the negotiated heartbeat interval if it is greater than or equal to 60 seconds, by default, before assuming there has been a communications failure. This qualifier can actually be tuned to reflect your network latency, on the distributed platforms, by changing the environment variable MQRCVBLKTO. There is also another
environment variable MQRCVBLKMIN which allows you to set a minimum value to be used when calculating the timeout based on the heartbeats. The behaviour can be set on z/OS in V5.3.1 by the use of XPARM attributes RCVTIME to qualify the timeout and RCVTMIN to set the minimum value.
So.. a small value will detect failures more quickly but may also be more expensive in terms of network traffic and CPU resource if your channel is lightly loaded.
|
By the way, if anyone has any inclination on understanding a big part of MQ, memorize this entire doc.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| j8mes |
| Posted: Fri Nov 19, 2004 2:29 am Post subject: When do heartbeats flow ? |
|
|
Novice
Joined: 22 Jan 2004
Posts: 12
|
Can you confirm my understanding here. The heart beats on the channel only flow while the client application makes a MQ call.
So If I have an application where a message is sent only when the user does an order posting say. If the user does nothing for an hour, e.g. the application waits for user input, no heart beat messages will be sent, as no MQ calls are made during this time. Therefore if you have your tcp/ip connection through a firewall, if the firewall had a timeout of say 1 hour, the connection will be lost.
So on the next MQ call the application will get a connection broken. So the heart beat isn't something that can be used to keep the connection up here, it is more for MQ to detect that the connection has broken during a call. |
|
| Back to top |
|
|
| j8mes |
| Posted: Fri Nov 19, 2004 2:31 am Post subject: When do heartbeats flow ? |
|
|
Novice
Joined: 22 Jan 2004
Posts: 12
|
Can you confirm my understanding here. The heart beats on the channel only flow while the client application makes a MQ call.
So If I have an application where a message is sent only when the user does an order posting say. If the user does nothing for an hour, e.g. the application waits for user input, no heart beat messages will be sent, as no MQ calls are made during this time. Therefore if you have your tcp/ip connection through a firewall, if the firewall had a timeout of say 1 hour, the connection will be lost.
So on the next MQ call the application will get a connection broken. So the heart beat isn't something that can be used to keep the connection up here, it is more for MQ to detect that the connection has broken during a call. |
|
| Back to top |
|
|
| JasonE |
| Posted: Fri Nov 19, 2004 2:45 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
| Yes... MQ Heartbeats on a client connection only flow during an MQGET (ie not any api call). If you want connection healthchecking when you are not making calls, then use keepalive, and ensure the keepavlie value is suitable for your network |
|
| Back to top |
|
|
| j8mes |
| Posted: Fri Nov 19, 2004 3:05 am Post subject: KEEPALIVE |
|
|
Novice
Joined: 22 Jan 2004
Posts: 12
|
Yes your right keepalive is the answer here, thanks.
BTW did we not decide that heatbeats on a client connection also flow during a MQPUT, see your earlier posting on the subject. Though I admit I shouldn't have said any MQ api call. |
|
| Back to top |
|
|
| j8mes |
| Posted: Fri Nov 19, 2004 3:12 am Post subject: I've got it now |
|
|
Novice
Joined: 22 Jan 2004
Posts: 12
|
I have re-read this thread and now see that the heatbeat interval is used by the MQPUT to decide how long it will wait for an answer. That doesn't mean that actual heat beats actually occur during the call. So that is why the manual says heartbeats only flow during a MQGET.
Got it ! |
|
| Back to top |
|
|
|
|
