| Author |
Message
|
| LouML |
 Posted: Mon Jan 14, 2008 8:04 am Post subject: AMQ9213: A communications error for TCP/IP occurred |
 |
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
I'm receiving the following message every 30 seconds in the AMQERR1.LOG
| Code: |
01/14/08 10:49:03
AMQ9213: A communications error for TCP/IP occurred.
EXPLANATION:
An unexpected error occurred in communications.
ACTION:
The return code from the TCP/IP(select) [TIMEOUT] 14460 seconds call was 11
(X'B'). Record these values and tell the systems administrator. |
I've looked on MQSeries.net and in the MQ documentation (Sys Admin guide, Inter-Process Communication, Messages, etc...) for a detailed description of the following message but am unable to fine one. Specifically this part:
The return code from the TCP/IP(select) [TIMEOUT] 14460 seconds call was 11
I've seen on MQSeries.net where people are getting this kind of message with a Return Code of 0.
Where can I find out what the Return Code 11 is? |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Mon Jan 14, 2008 8:19 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Look at the IP stack information for your platform... i.e. what platform are you on?
11 is usually a remote-terminated exception, I think.
I'd bet that some robot is trying to ping or telnet to your MQ listener every 30 seconds, to decide that MQ is "running".
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| LouML |
| Posted: Mon Jan 14, 2008 8:35 am Post subject: |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
Just did a Google search and found ths IBM page:
http://www-1.ibm.com/support/docview.wss?uid=swg21197924
We did add ClientIdle to the qm.ini file with a value of 14400 awhile back. We did this because some apps were keeping connections up all day (but not doing anything). We would eventually hit MaxChannels. So this is obviously what is causing the messages.
I guess my next question is - why would they continue to come out? As stated in the URL, once they get disconnected they immediately reconnect without a problem. Seems odd that we would continue to get these messages so often.
This server gets rebooted every Sunday morning so I know we're starting the week with no client connections.
Anyway, I guess I need to track down who's doing what.
Thanks. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Jan 14, 2008 9:00 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Suppose you have an MQ app that issues a GET with a short (or no) wait, and then sleeps for 1 minute before re-issuing the GET.
The conn will still be open, for a full minute. There will be no heartbeats on the conn, either.
If your ClientIdle is shorter than 1 minute, then you will see this happen at least every minute.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Jan 14, 2008 9:08 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| LouML wrote: |
| We did add ClientIdle to the qm.ini file with a value of 14400 awhile back. We did this because some apps were keeping connections up all day (but not doing anything). We would eventually hit MaxChannels. |
Aren't those apps great? We toyed around with ClientIdle but determined its a no go because its at the QM level (one value was never going to be correct for dozens of different apps). Plus it made debugging a real pain because if a client connection was dropped due to Client Idle there wasn't a Client Idle specific error code on either side.
What we ended up doing is giving each client app its own SVRCONN channel, and then capping the # of instances that could be started up using Capitalware's MQAUSX exit. Now when the app wants to grab too many connections only that one specific app is blocked and my MQ error logs have a very specific entry saying what happened and why. And the Java MQ Client app gets a 2063 error on their side on the next MQCONN they try that pushes them over the limit I set.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| LouML |
| Posted: Mon Jan 14, 2008 9:27 am Post subject: |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
| jefflowrey wrote: |
Suppose you have an MQ app that issues a GET with a short (or no) wait, and then sleeps for 1 minute before re-issuing the GET.
The conn will still be open, for a full minute. There will be no heartbeats on the conn, either.
If your ClientIdle is shorter than 1 minute, then you will see this happen at least every minute. |
Our ClientIdle is 4 hours. It was initially 90 minutes, but I received too many complaints about apps disconnecting.
Still, with a 4 hour time, I would think I wouldn't be getting these messages every 30 seconds. Because of this frequency, the errors logs only go back to early this morning, so I can't see how long after the queue manager was restarted the errors start to appear. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Jan 14, 2008 9:46 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| LouML wrote: |
| Still, with a 4 hour time, I would think I wouldn't be getting these messages every 30 seconds. |
I agree, that's why, particularly with a 30 second time interval, I think it's something polling the listener port incorrectly.
Run a script to dump "dis conn(*) all" out to a file every 30 seconds.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Jan 14, 2008 9:53 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| LouML wrote: |
| Because of this frequency, the errors logs only go back to early this morning, so I can't see how long after the queue manager was restarted the errors start to appear. |
In MQ 6.0 you can bump up the size of the QM's error logs thru qm.ini (or MQExplorer on Windows).
You might want to go to your security / network team and ask them if they have someting checking every port on your server every 30 seconds. A port scanner as Jeff mentioned, or maybe a network load balancer.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
