| Author |
Message
|
| OzgurAydin |
 Posted: Wed Apr 08, 2009 4:32 am Post subject: 10054 Sender Channel Connection reset by peer. |
 |
|
Apprentice
Joined: 08 Sep 2008
Posts: 27
|
Hi,
We have a problem regarding the Sender Channel going into the retry state from time to time... Our Platform is Windows2003 the counterparty is AIX. The connection between the two parties is said to be normal but I can see that there is a connection drop on the remote side.
Event Type: Error
Event Source: WebSphere MQ
Event Category: None
Event ID: 9202
Date: 08.04.2009
Time: 14:57:55
User: N/A
Computer: KWPUBMQS01
Description:
Remote host '10.0.16.20 (1414)' not available, retry later.
The attempt to allocate a conversation using TCP/IP to host '10.0.16.20 (1414)' was not successful. However the error may be a transitory one and it may be possible to successfully allocate a TCP/IP conversation later.
Try the connection again later. If the failure persists, record the error values and contact your systems administrator. The return code from TCP/IP is 10060 (X'274C'). The reason for the failure may be that this host cannot reach the destination host. It may also be possible that the listening program at host '10.0.16.20 (1414)' was not running. If this is the case, perform the relevant operations to start the TCP/IP listening program, and try again.
After haven spoken to the people on the other side they see the connection still running. I have stopped the sender channel and wited for some time but still they see our connection established and the receiver channel is running. I guess that they have a problem with AIX not understanding the connection went down. If it is a problem with my version of MQ I would be very grateful if you can give me some advice on it.
Thank you.
 |
|
| Back to top |
|
 |
| Sam Uppu |
| Posted: Wed Apr 08, 2009 5:08 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
Please check your connname parameters in your sender channel and also check whether the destination QMgr's listener is in running state.
Are you providing the DSN or the ip address of the destination in your sender channel's conname?. If you are providing IP, plz check wthether they changed the ip.
Is the sender channel ever in 'Running' state?.
Thanks. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Wed Apr 08, 2009 5:23 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
@sam -
| Quote: |
| Is the sender channel ever in 'Running' state?. |
yes, as he said "from time to time"
we sometimes see that "connection reset by peer" when "somebody" does network maintenance "somewhere" between our sender and the receiver. Looks like there is some kind of network maintenance (e.g. loading firewall, change routing or similiar, i do not know exactly) that makes the connection drop. in our case it is reconnected during first retry interval.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| OzgurAydin |
| Posted: Wed Apr 08, 2009 5:27 am Post subject: |
|
|
Apprentice
Joined: 08 Sep 2008
Posts: 27
|
Yes,
Thats what I expect as well but the remote Queue Manager assumes the receiver channel is still running even if I completly drop the connection. After they have restarted their AIX machine the connection goes up again and the sender channel is in running state. I was woundering if I have to change anything on the Sender Channel properties ?
Thank you. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Wed Apr 08, 2009 5:43 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| Mr Butcher wrote: |
@sam -
| Quote: |
| Is the sender channel ever in 'Running' state?. |
yes, as he said "from time to time"
we sometimes see that "connection reset by peer" when "somebody" does network maintenance "somewhere" between our sender and the receiver. Looks like there is some kind of network maintenance (e.g. loading firewall, change routing or similiar, i do not know exactly) that makes the connection drop. in our case it is reconnected during first retry interval. |
If somebody changes something(network or route statements etc), then that something is causing the issue and not MQ I believe. At that "something" change, MQ team will also be in loop and make sure everything is working as expected. Otherwise that routing is not working.
In our case if there are multiple network interfaces exists for the same port, when you try a telnet on that particular port, it will show in retrying state and not in "connected" state.
Then there should be a proper network route statement to open that port properly.
Let me know your thoughts.
Thanks. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Apr 08, 2009 7:55 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| OzgurAydin wrote: |
Yes,
Thats what I expect as well but the remote Queue Manager assumes the receiver channel is still running even if I completly drop the connection. |
Study this:
http://www-01.ibm.com/support/docview.wss?rs=171&uid=swg24006699&loc=en_US&cs=utf-8&lang=en
| Quote: |
| This SupportPac provides recommendations to improve the availability of WebSphere MQ/MQSeries Channels. |
Focus on TCP Keep Alive, Heartbeats and AdoptNewMCA, all on the receiving QM.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| sumit |
| Posted: Thu Apr 09, 2009 12:20 am Post subject: |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
It seems to be for MQ 5.3.
OzgurAydin, what's your mq version? Do you have a firewall between sending and receving side? If yes, then you need to contact your network guys to sense the network. They can tell you the information passing through firewall.
We have seen a similar scenario earlier where MQ channel connection was giving problem. We had to set DISCINT as 0 as we were not able to do much on firewall end.
_________________
Regards
Sumit |
|
| Back to top |
|
|
| zhanghz |
| Posted: Thu Apr 09, 2009 1:36 am Post subject: |
|
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
i'll look into the following 2 first:
HBINT, network... |
|
| Back to top |
|
|
| nageshshiv |
| Posted: Thu Apr 09, 2009 1:49 am Post subject: |
|
|
Apprentice
Joined: 09 May 2008
Posts: 30
|
Hi OzgurAydin,
Check that your interface server '10.0.16.20' is under Firewall ..If they are under the firewall ..Ask your interface to open a port..
If not under the firewall , Check the listener at the interface '10.0.16.20' is running ? |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Apr 09, 2009 2:24 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| nageshshiv wrote: |
| ...Check that your interface server '10.0.16.20' is under Firewall ..If they are under the firewall ..Ask your interface to open a port... |
As OzgurAydin wrote:
| Quote: |
| ...the Sender Channel going into the retry state from time to time... |
It's unlikely that the firewall has a bearing on this as I would expect it to block, or not block - not intermittently allow/disallow.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Apr 09, 2009 2:28 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| sumit wrote: |
It seems to be for MQ 5.3.
|
The MQ version is irrelevant. All the concepts apply to any recent version of MQSeries.
| sumit wrote: |
We have seen a similar scenario earlier where MQ channel connection was giving problem. We had to set DISCINT as 0 as we were not able to do much on firewall end. |
If a firewall is involved, possibly shutting down quiet connections, setting DISCINT to 0 is the exact opposite of what you should do.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Apr 09, 2009 3:20 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| exerk wrote: |
It's unlikely that the firewall has a bearing on this as I would expect it to block, or not block - not intermittently allow/disallow. |
You can get that type of behavior if the firewall times out your idle connection. The receiver still thinks you're connected. The sender finds out the connection is no longer usable on the next try. Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Apr 09, 2009 3:36 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| fjb_saper wrote: |
| You can get that type of behavior if the firewall times out your idle connection. The receiver still thinks you're connected. The sender finds out the connection is no longer usable on the next try. Have fun |
Thank you for that information, which is now added to my growing knowledge-base 
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| sumit |
| Posted: Thu Apr 09, 2009 6:31 am Post subject: |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
| PeterPotkay wrote: |
| sumit wrote: |
We have seen a similar scenario earlier where MQ channel connection was giving problem. We had to set DISCINT as 0 as we were not able to do much on firewall end. |
If a firewall is involved, possibly shutting down quiet connections, setting DISCINT to 0 is the exact opposite of what you should do. |
With DISCINT as some value, when the channel is triggered to start as a message came to xmitq it hits the firewall with the receiver port number. Somehow the port number mentioned in incoming connection to firewall got changed (or something, as it was long time back) and hence firewall was not allowing this port number to go in.
The only way out then was to start the receiver channel (which had host name and port of sender qmgr) so that it can hit the firewall with sender channel name and can start it finding the same name (indeed, from the same ip address as expected as it was properly maintained system) waiting to go in through firewall. This helped to start the channel.
Setting DISCINT to 0 will never allow it to go to inactive state and hence the sender don't have to search again for port number at firewall to initiate a connection.
_________________
Regards
Sumit |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Apr 09, 2009 6:40 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sumit wrote: |
| Setting DISCINT to 0 will never allow it to go to inactive state and hence the sender don't have to search again for port number at firewall to initiate a connection. |
Unless the firewall is configured to close the connection, because with DISCINT at 0 the channel won't trigger.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
