| Author |
Message
|
| tegelert |
 Posted: Fri May 03, 2013 1:59 pm Post subject: Windows 7 MQ 7.0.1.9 AMQ9204 error: cannot connect to QM |
 |
|
Newbie
Joined: 03 May 2013
Posts: 9
|
Running a java application as a MQ client attempting to connect to 7.0.1.9 queue manager. The connection fails. From the Windows event log, am seeing the exception below.
The TCP/IP responder program encountered an error.
The responder program was started but detected an error.
Look at previous error messages in the error files to determine the error encountered by the responder program.
1:29:55 PM
A communications error for TCP/IP occurred.
An unexpected error occurred in communications.
The return code from the TCP/IP (ioctlsocket) call was 10038 (X'2736'). Record these values and tell the systems administrator
2:03:08 PM
04:01:56 Handshake Listener > HSK00021S: Error occurred during MQ server restart. Error setting up Handshake receiving queue. com.ibm.icpc
s.utilities.jms.JMSException: Could not create connection. JMSWMQ0018: Failed to connect to queue manager 'ftm21qm' with connection mode 'Client' and host name 'localhost(1415)'.; JMS Error code=JMSWMQ0018; JMS Explanation: null
JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2
009' ('MQRC_CONNECTION_BROKEN').; WMQ Completion code=2; WMQ Reason code=2009 CC=2;RC=2009;AMQ9204: Connection to host 'localhost(1415)' rejected. [1=com.ibm.mq.jmqi.JmqiException[CC=2;RC=2009;AMQ9213: A communications error for 'TCP' occurred. [1=java.net.SocketException[Software caused connection abort: recv failed],4=TCP,5=sockInStream.read]],3=localhost(1415),5=RemoteTCPConnection.receive];
WMQ Log Message: 5/2/13 4:01:56 PM - User(shwetam) Program(java)
AMQ9204: Connection to host 'localhost(1415)' rejected.
EXPLANATION:
Connection to host 'localhost(1415)' over '?' was rejected.
ACTION:
The remote system may not be configured to allow connections from this host.
Check the '?' listener program has been started on host 'localhost(1415)'.
If the conversation uses LU 6.2, it is possible that either the User ID or
Password supplied to the remote host is incorrect.
If the conversation uses TCP/IP, it is possible that the remote host does not recognize the local host as a valid host.
The return code from the '?''RemoteTCPConnection.receive' call was
'com.ibm.mq.jmqi.JmqiException[CC=2;RC=2009;AMQ9213: A communications error for 'TCP' occurred. [1=java.net.SocketException[Software caused connection abort:
recv failed],4=TCP,5=sockInStream.read]]' X('?'). |
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri May 03, 2013 4:24 pm Post subject: Re: Windows 7 MQ 7.0.1.9 AMQ9204 error: cannot connect to QM |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| tegelert wrote: |
| The return code from the TCP/IP (ioctlsocket) call was 10038 (X'2736'). Record these values and tell the systems administrator |
What does Mr Google say a 10038 error code means? What did the systems administrator say when you told him?
Have you proved your WMQ client configuration on that queue manager with one of the sample client applications?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| tegelert |
| Posted: Sat May 04, 2013 7:26 am Post subject: MQ test client connects to the queue... |
|
|
Newbie
Joined: 03 May 2013
Posts: 9
|
The 10038 return code from ioctlsocket is a WSAENOTSOCK error. Several possible causes are documented, but I'd say the most likely cause in this case is that the socket was closed prior to the call to ioctlsocket.
There is text in the exceptions which states "Software caused connection abort". It seems something (in Windows most likely) is intentionally closing that socket and that is causing the call to ioctlsocket to fail.
Testing with an MQ test client using the failing client's parameters seems to work fine. I can connect to the queue manager in question and send messages.
For this error, I see similar posts on the web, but seem to be limited to MQ V5.3. In those cases the suggested fix is to set an environment variable, MQNOREMPOOL=1.
For this environment I am the system administrator. There's nobody else to turn to. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sat May 04, 2013 8:02 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Is there a firewall in between?
Is there a firewall on the machine with the client?
Did you give the client application permission to access the network in the first place?
Did you actually start the listener on the queue manager?
Is the queue manager running MQ 7.1 or later, and are you attempting to connect using a channel or userid that is blocked by the default chlauth rules? |
|
| Back to top |
|
|
| tegelert |
| Posted: Sat May 04, 2013 11:09 am Post subject: Windows 7 - MQ 7.0.1.9: client & server on the same box |
|
|
Newbie
Joined: 03 May 2013
Posts: 9
|
We disabled the firewall. Both client and MQ server are on the same machine. MQ version is 7.0.1.9
Both queue manager and listener are running and we can connect from a rfhutil.exe client. Not to mention the MQ Explorer.
Since we are on MQ 7.0.1.9, chlauth is not available. I think it was added in 7.1.
It looks like 7.0 has facilities for configuring security and privilege. I'm not familiar with it so it looks like a good place to research. |
|
| Back to top |
|
|
| mvic |
| Posted: Sat May 04, 2013 1:39 pm Post subject: Re: Windows 7 - MQ 7.0.1.9: client & server on the same |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| Were errors written in the qmgr error logs? I am not not clear from your original post where all that error text came from. Some clearly came from the Java client process, but not sure about all of it. Please clear that up for us. If there were errors on the qmgr side, what were they, and do they help? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat May 04, 2013 2:36 pm Post subject: Re: Windows 7 - MQ 7.0.1.9: client & server on the same |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| tegelert wrote: |
| Both client and MQ server are on the same machine. |
"same machine" is not specific. Are both client and MQ server in the same o/s image? The same LPAR? Or on the same machine, but different o/s images? Is one a VMware guest image on a host image.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| tegelert |
| Posted: Sat May 04, 2013 2:58 pm Post subject: Both client and MQ server are on the same machine. |
|
|
Newbie
Joined: 03 May 2013
Posts: 9
|
Same OS image and same physical machine.
We're talking plain and simple native Windows 7. No VMWare or LPARS involved. |
|
| Back to top |
|
|
| tegelert |
| Posted: Sat May 04, 2013 5:22 pm Post subject: Origin of error text... |
|
|
Newbie
Joined: 03 May 2013
Posts: 9
|
Reply to mvic,
origin of the error messages I posted are from the Windows application event log. |
|
| Back to top |
|
|
| mvic |
| Posted: Sat May 04, 2013 5:27 pm Post subject: Re: Origin of error text... |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| tegelert wrote: |
Reply to mvic,
origin of the error messages I posted are from the Windows application event log. |
Is that the only source of error info? Probably not. Look in your local Windows equivalents of /var/mqm/errors, /var/mqm/qmgrs/QMNAME/errors, at least. Search the manuals for help in troubleshooting. |
|
| Back to top |
|
|
| tegelert |
| Posted: Sun May 05, 2013 9:49 am Post subject: MQ error trace |
|
|
Newbie
Joined: 03 May 2013
Posts: 9
|
Yes, MQ has some trace output. Not finding much useful there. Here's a snippit. It's just repeating information I already got from the event log.
+-----------------------------------------------------------------------------+
| |
| WebSphere MQ First Failure Symptom Report |
| ========================================= |
| |
| Date/Time :- Thu May 02 2013 13:10:11 Eastern Daylight Time |
| UTC Time :- 1367514611.245000 |
| UTC Time Offset :- 60 (Eastern Daylight Time) |
| Host Name :- ADMINIB-RLHL9OI |
| Operating System :- Windows 7 Professional x64 Edition, Build 7601: SP1 |
| PIDS :- 5724H7220 |
| LVLS :- 7.0.1.9 |
| Product Long Name :- WebSphere MQ for Windows |
| Vendor :- IBM |
| Probe Id :- CO000001 |
| Application Name :- MQM |
| Component :- ccxAllocMem |
| SCCS Info :- lib/client/amqccmxa.c, 1.65.1.2 |
| Line Number :- 549 |
| Build Date :- Jul 18 2012 |
| CMVC level :- p701-109-120718 |
| Build Type :- IKAP - (Production) |
| UserID :- MUSR_MQADMIN |
| Process Name :- C:\Program Files (x86)\IBM\WebSphere MQ\bin\amqrmp |
| pa.exe |
| Addressing mode :- 32-bit |
| Process :- 00009456 |
| Thread :- 00000003 |
| UserApp :- FALSE |
| Last HQC :- 0.0.0-0 |
| Last HSHMEMB :- 0.0.0-0 |
| Major Errorcode :- rrcE_BAD_PARAMETER |
| Minor Errorcode :- OK |
| Probe Type :- INCORROUT |
| Probe Severity :- 2 |
| Probe Description :- AMQ6125: An internal WebSphere MQ error has occurred. |
| FDCSequenceNumber :- 0 |
| Arith1 :- 10038 2736 |
| Arith2 :- 10038 2736 |
| Comment1 :- |
| |
| Comment2 :- TCP/IP |
| |
| Comment3 :- (ioctlsocket) |
| |
| |
+-----------------------------------------------------------------------------+
--} cciLoadLibrary rc=OK
--{ xcsRequestThreadMutexSem
--} xcsRequestThreadMutexSem rc=OK
--{ xcsReleaseThreadMutexSem
--} xcsReleaseThreadMutexSem rc=OK
-} ccxNetWorkInit rc=OK
-{ ccxAcceptConv
--{ cciTcpAcceptConv
---{ ioctl
---} ioctl rc=Unknown(FFFF)
---{ rrxError
---} rrxError rc=rrcE_COMMUNICATIONS_ERROR
--} cciTcpAcceptConv rc=rrcE_COMMUNICATIONS_ERROR
-} ccxAcceptConv rc=rrcE_COMMUNICATIONS_ERROR
-{ rrxResponder |
|
| Back to top |
|
|
| Vitor |
| Posted: Sun May 05, 2013 10:11 am Post subject: Re: MQ error trace |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| tegelert wrote: |
| Yes, MQ has some trace output. Not finding much useful there. Here's a snippit. |
Not strictly trace but an FDC file.
| tegelert wrote: |
| It's just repeating information I already got from the event log. |
Did you get the Probe Id in the log? Looking that up offers this potentially useful nugget (if you're on Solaris):
http://www-01.ibm.com/support/docview.wss?uid=swg1IV29260
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| tegelert |
| Posted: Sun May 05, 2013 10:30 am Post subject: Probe Id = CO000001 |
|
|
Newbie
Joined: 03 May 2013
Posts: 9
|
| Yes, you can see the probe ID there, it's CO000001. |
|
| Back to top |
|
|
| Vitor |
| Posted: Sun May 05, 2013 10:32 am Post subject: Re: Probe Id = CO000001 |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| tegelert wrote: |
| Yes, you can see the probe ID there, it's CO000001. |
And you're not on Solaris either. Oh Well.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| tegelert |
| Posted: Sun May 05, 2013 10:44 am Post subject: probe ID CO000001 |
|
|
Newbie
Joined: 03 May 2013
Posts: 9
|
| But the probe IDs match. This looks very similar to what we see. The APAR says it's only been seen on Solaris, but that doesn't seem to be a strong enough statement to say it could absolutely never occur on Windows. Maybe we should upgrade anyway. |
|
| Back to top |
|
|
|
|
