| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQJE001: Completion Code 2, Reason 2009 |
« View previous topic :: View next topic » |
| Author |
Message
|
| pshan81 |
 Posted: Mon Sep 29, 2008 10:43 pm Post subject: MQJE001: Completion Code 2, Reason 2009 |
 |
|
Acolyte
Joined: 24 May 2005
Posts: 72
|
Hi,
We are periodically getting the below error in the application error log.The application is written in java and it fetches message from a queue in client mode(using SYSTEM.DEF.SVRCONN).The application is issuing queue.close() and qmgr.disconnect() after every call.The requests pass through firewall.
com.ibm.mq.MQException: MQJE001: Completion Code 2, Reason 2009
at com.ibm.mq.MQQueue.get(MQQueue.java:913)
com.ibm.mq.MQException: MQJE001: Completion Code 2, Reason 2019
at com.ibm.mq.StoredManagedConnection.connectionClosed(StoredManagedConnection.java:258)
at com.ibm.mq.MQManagedConnectionJ11.fireConnectionClosedEvent(MQManagedConnectionJ11.java:713)
at com.ibm.mq.MQQueueManager.disconnect(MQQueueManager.java:1009)
As the connection can be broken for various reasons,to narrow down whether the issue is with firewall/port,we wrote a PERL script which tries to connect to the IP/Port of the queue manager for every 10 seconds.Within 3 hours for five times the PERL script throw timeout error(It was not able to connect to the port may be due to network traffic).MaxChannels and MaxActiveChannels are set to default.Is there any configuration/setting in MQ that restricts the number of connections to the port where queue manager is listening?
If not does the application needs to be build up with the intelligence to reconnect incase 2009 error?
MQ version : 5.3 CSD10 / AIX
Thanks |
|
| Back to top |
|
 |
| Gaya3 |
| Posted: Mon Sep 29, 2008 11:23 pm Post subject: |
|
|
Jedi
Joined: 12 Sep 2006
Posts: 2493
Location: Boston, US
|
First of all: Please upgrade to MQ V6
MQRC 2019
Reason Code 2019 x'7E3'
MQRC_HOBJ_ERROR
The object handle Hobj is not valid. If the handle is a shareable handle, the handle may have been made invalid by another thread issuing the MQCLOSE call using that handle. If the handle is a nonshareable handle, the call may have been issued by a thread that did not create the handle. This reason also occurs if the parameter pointer is not valid, or (for the MQOPEN call) points to read-only storage. (It is not always possible to detect parameter pointers that are not valid; if not detected, unpredictable results occur.)
Corrective action: Ensure that a successful MQOPEN call is performed for this object, and that an MQCLOSE call has not already been performed for it. For MQGET and MQPUT calls, also ensure that the handle represents a queue object. Ensure that the handle is being used within its valid scope.
MQRC 2009 (search in the forum) there are lot options to get rid of this
Reason Code 2009 x'7D9'
MQRC_CONNECTION_BROKEN
Connection to the queue manager has been lost. This can occur because the queue manager has ended. If the call is an MQGET call with the MQGMO_WAIT option, the wait has been canceled. All connection and object handles are now invalid. For WebSphere MQ client applications, it is possible that the call did complete successfully, even though this reason code is returned with a CompCode of MQCC_FAILED.
Corrective action: Applications can attempt to reconnect to the queue manager by issuing the MQCONN or MQCONNX call. It may be necessary to poll until a successful response is received. On z/OS for CICS applications, it is not necessary to issue the MQCONN or MQCONNX call, because CICS applications are connected automatically. Any uncommitted changes in a unit of work should be backed out. A unit of work that is coordinated by the queue manager is backed out automatically.
_________________
Regards
Gayathri
-----------------------------------------------
Do Something Before you Die |
|
| Back to top |
|
|
| David.Partridge |
| Posted: Tue Sep 30, 2008 12:14 am Post subject: |
|
|
Master
Joined: 28 Jun 2001
Posts: 249
|
>The application is issuing queue.close() and qmgr.disconnect() after every call
Please don't do that - the overhead of making a connection/open/put or get/close/disc is very large. Correct MQ application design would indicate connect/open/process all messages on queue with timeout on get/close/disconnect.
The connection broken problem is almost certainly a network issue with the firewalls or routers along the way dropping the connection, it's this that you should address.
_________________
Cheers,
David C. Partridge |
|
| Back to top |
|
|
| pshan81 |
| Posted: Tue Sep 30, 2008 2:26 am Post subject: |
|
|
Acolyte
Joined: 24 May 2005
Posts: 72
|
Thanks for your suggestions.As the java application is working in a synchronous mode (put a msg in queue/wait for response/get the msg for a particular group id/show it to user),I am closing the connection after every call.
I hope I have to change the application to reconnect to the queue manager if it throws 2009. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Sep 30, 2008 2:52 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| pshan81 wrote: |
| ...I hope I have to change the application to reconnect to the queue manager if it throws 2009. |
In general, all client-based applications should be coded to attempt reconnection if communication fails, and as David.Partridge has already stated:
| Quote: |
| ...Please don't do that - the overhead of making a connection/open/put or get/close/disc is very large. Correct MQ application design would indicate connect/open/process all messages on queue with timeout on get/close/disconnect... |
_________________
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 |
|
|
|
|
|
| |
|
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
|
|
|
|
