| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Completion Code 2, Reason 2058 (QM connection refused) |
« View previous topic :: View next topic » |
| Author |
Message
|
| Guava72 |
 Posted: Fri Jun 06, 2003 4:16 pm Post subject: Completion Code 2, Reason 2058 (QM connection refused) |
 |
|
Apprentice
Joined: 06 Jun 2003
Posts: 46
Location: Champaign, IL
|
Hi, I am running Websphere MQ 5.3 on SunOS 5.8. I am using a Java client to pick up XML files from a directory and put them to a queue of a queue manager on the same machine (local). But in the error log of the client, I am seeing
| Code: |
MQJE036: Queue manager rejected connection attempt
MQJE001: Completion Code 2, Reason 2058
|
and then the Java client process is killed. The QM is up, its command server is up, the listener is up, I have run the setmqaut command to grant access to the qmgr and the response and request queues. I've shut things down and restarted them, but still keep getting this error. I've seen somewhat similar posts about server mode/client mode, but I am fairly new to MQSeries and I don't understand this. Any help would be appreciated--been banging my head against the wall for a few days now. Thanks in advance. --Ryan |
|
| Back to top |
|
 |
| clindsey |
| Posted: Fri Jun 06, 2003 7:03 pm Post subject: |
|
|
Knight
Joined: 12 Jul 2002
Posts: 586
Location: Dallas, Tx
|
Ryan,
The rc 2058 is MQRC_Q_MGR_NAME_ERROR. Is this an intermittent error or does it fail every time. You might get this if you instantiate the queue manager with a null name, e.g.
qMgr = new MQQueueManager("");
and there is no default queue manager defined or you gave it a queue manager name and it is mispelled due to case or something like that.
If that doesn't help, let me know and we will go into more detail.
Charlie |
|
| Back to top |
|
|
| Guava72 |
| Posted: Sun Jun 08, 2003 3:05 pm Post subject: |
|
|
Apprentice
Joined: 06 Jun 2003
Posts: 46
Location: Champaign, IL
|
Hi Charlie--thanks for your reply. It pretty much echoes what I've seen/read/heard from other people and other posts. I didn't write this Java client (I am an Infrastructure/environments person), but I took a look at the source of the Java client and saw that its constructor has null for the Queue Manager name, so it probably is trying to use the default Queue Manager, which is NOT the correct one! Also, to make matters worse, the createMQCon constructor seems to be from when this setup was on an entirely different machine, OS, port, etc...
So, I'm going to speak with a Java developer at my company who knows about this client and work with them to edit the source for the current machine, QM, etc., recompile it, and try again. If it still doesn't work, I'll post an update, but if it does work, I'll close this thread. Thanks again, Charlie.
---Ryan aka Guava72 |
|
| Back to top |
|
|
| mqonnet |
| Posted: Mon Jun 09, 2003 5:08 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
I would bet your app is trying to use Bindings mode rather than Client/Tcpip mode. When you are connecting to a qm as a client you MUST use tcpip mode only. You CANNOT use Binding mode to connect to a qm that is not available locally to that system where you are running your java app.
Add the following if not already present.
MQEnvironment.properties.put( MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_CLIENT);
Hope this helps.
Cheers
Kumar |
|
| Back to top |
|
|
| Guava72 |
| Posted: Tue Jun 10, 2003 1:07 pm Post subject: |
|
|
Apprentice
Joined: 06 Jun 2003
Posts: 46
Location: Champaign, IL
|
It turns out that the problem was with the listeners on the machine...I'm running SunOS 5.8, and in the /etc/inet/inetd.conf file, I had the line:
CMIXMLEUAT13 stream tcp nowait mqm /opt/mqm/bin/amqcrsta -m CMIXMLEUAT13
when what I should have had (and doing this worked) was:
CMIXMLEUAT13 stream tcp nowait mqm /opt/mqm/bin/amqcrsta amqcrsta -m CMIXMLEUAT13
It doesn't make sense to me, since it seems you are giving the amqcrsta utility itself as an argument, but a coworker showed me a similar setup that is working in Production, and this is how they have the listener set up, so I guess I can't question it too much. After making the change above, I had the UNIX Systems people restart the INETD daemon, ran my Java Client, and did not get this error anymore!
In this case, the client and the QM are on the same machine, so I don't know if using binding/tcpip mode matters, but in the future when using a client to connect to a remote QM, I will definitely check that out. Thanks to everyone who replied. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
