| Author |
Message
|
| HarishDeshpande |
 Posted: Fri Sep 26, 2003 10:47 am Post subject: MQ Client Connection Problem |
 |
|
Newbie
Joined: 26 Sep 2003
Posts: 3
|
Hi,
I have written a web application using MQ classes for Java(TM) Version 5.3. The application maintains the connection for a minute and tears it down if there is no activity. Once in a while(about once or twice a day) the application looses connectivity in the middle of a conversation with the MQ Server. The client application receives an error when trying to put a message in a Q(Reason Code = 2009). MQ Server error log does show a TCP/IP communication error at around the same time.
The application has been written to re-initiate a connection to the server in such a case. This fails and the only recourse is to cycle the application.
Has anybody encountered similar problems.
Greately appreciate any help/suggestions.
Thanks in advance
Harish |
|
| Back to top |
|
 |
| mrlinux |
| Posted: Fri Sep 26, 2003 9:03 pm Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
This happens when there are network glitchs, we had this happen when we moved an application from HQ to another bldg, we had to install MQSeries Server in the other bldg which then had server-server connection. This solved the issue
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| HarishDeshpande |
| Posted: Mon Sep 29, 2003 5:02 am Post subject: |
|
|
Newbie
Joined: 26 Sep 2003
Posts: 3
|
Jeff,
I think what you say is true. We have the same application(running in-core i.e., non-DMZ) connecting to the MQ server and it works fine. In fact it has not been cycled at all. Unfortunaltely that is a development environment. When this application is deployed in the DMZ it looses connection because of TCP/IP problem. I thought the protocol was resilient. What we don't understand is why it is not possible for the application to reconnect to the server. The Q Manager object initialization is fine. But when the first attempt to put a message in Q is tried that application gets the same error. It is as if something is cached in the API.
Thanks in advance.
Harish |
|
| Back to top |
|
|
| mrlinux |
| Posted: Mon Sep 29, 2003 7:33 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Well the server to server communication is resilent but client to server is not.
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| ArvindC |
| Posted: Tue Sep 30, 2003 3:51 am Post subject: |
|
|
Novice
Joined: 25 Dec 2002
Posts: 14
Location: India
|
Hummm... If the QMGR initialization is fine, that means you are connected to the QMGR (and that's why you can open the queue).
What you can try is backout the message and then re-put it (don't disconnect or close the queue). I am pretty hopeful that it will work.
Don't ask me why.  |
|
| Back to top |
|
|
| HarishDeshpande |
| Posted: Wed Oct 01, 2003 7:40 am Post subject: |
|
|
Newbie
Joined: 26 Sep 2003
Posts: 3
|
Jeff,
If it is of any help here is the MQ server error.log entry:
09/30/03 13:02:20
AMQ9208: Error on receive from host dmzsun06 (168.97.134.32).
EXPLANATION:
An error occurred receiving data from dmzsun06 (168.97.134.32) over TCP/IP.
This may be due to a communications failure.
ACTION:
The return code from the TCP/IP (recv) call was 10054 (X'2746'). Record these
values and tell the systems administrator.
Any idea why trying to reestablish the connection fails?
Arvind,
When the error is encountered(while attempting to put a message) there is nothing to backout. An attempt to put the message back on the Q(ignoring the initial error as you suggested) generated the same error. |
|
| Back to top |
|
|
| mqonnet |
| Posted: Wed Oct 01, 2003 8:17 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
I cant get it on top of my head what the error code means, but i think it is TIMEOUT.
Did you change or was there a change to the IP of either of the two systems in question. Can you do a regular PING, not PING CHANNEL, from both systems both ways.
The tcp/ip reason codes is described with the detailed explanation in the system header files corresponding to the platform.
Cheers
Kumar |
|
| Back to top |
|
|
| mrlinux |
| Posted: Wed Oct 01, 2003 8:40 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
This is a TCP communication's issue 10054 is a Connection reset by peer.
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| manuneedhi |
| Posted: Sat Feb 28, 2004 2:38 am Post subject: TCP/IP error 10054 |
|
|
Newbie
Joined: 28 Feb 2004
Posts: 1
Location: Chennai
|
The Java application which is running on the Windows 2000 machine picks up message from a queue and does the processing (and sends the response to Mainframe )which has MQ 5.2.But at times the application fails to pick up the messages and the application log shows the TCP/IP error which i have pasted below.
Many users reported this kinda problem and IBM has released a patch(CSD05) for this problem in Websphere MQSeries 5.3 .The IBM people here claim that they have applied the patch. But this problem is still there.
.
In the application log the following error is found whenever this problem comes.
Event Type: Error
Event Source: WebSphere MQ
Event Category: None
Event ID: 9208
Date: 06/02/2004
Time: 11:05:36
User: N/A
Computer: SRV2
Description:
Error on receive from host srv2 (172.16.40.57).
An error occurred receiving data from srv2 (172.16.40.57) over TCP/IP. This may be due to a communications failure.
The return code from the TCP/IP (recv) call was 10054 (X'2746'). Record these values and tell the systems administrator. |
|
| Back to top |
|
|
| j8mes |
| Posted: Fri Apr 23, 2004 2:02 am Post subject: |
|
|
Novice
Joined: 22 Jan 2004
Posts: 12
|
The answer why you are not able to reconnect immediately is contained in the MD0C.pdf support back document:
"AdoptMCA - Notes
If a channel fails, for example a communications error, there is no guarantee that both ends of the channel will
detect the failure at the same time. Often the sending end of the channel detects the failure first since it is the
end trying to send messages down the socket. What will happen therefore is that the sender will try to
reconnect to the target Queue Manager. When the connection comes into the target machine the Queue
Manager sees that it already has a channel running with that name and from that location. Consequently the
new connection is rejected.
By configuring AdoptNewMCA you can tell the Queue Manager that if a new connection arrives and there is
already a channel with that name running from the same network address and from the same Queue Manager
then the existing channel should be ended and replaced with this new instance. In other words, the channel
instance should be 'adopted' by the new connection." |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Apr 23, 2004 4:20 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
AdoptNewMCA does not apply to SVRCONN channels, so it would not help this application with its connection errors.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
