Troubleshooting
Problem
Your JMS application runs on IBM® WebSphere® Application Server to connect to a WebSphere MQ messaging system receives an MQJMS2005 error with reason code 2059.
Cause
Reason code 2059 means that the queue manager is not available.
The most likely cause of the problem is that the queue manager is not running or that the queue manager listener is not running. Another possible cause is that the queue manager name that is specified on the JMS connection factory is incorrect.
Resolving The Problem
These are some steps to take to try to resolve the cause of the 2059 error.
Confirm that the queue manager is up and running and that the listener is running
- Ensure that the queue manager is running. You can use the dspmq command to verify this. The status of the queue manager should be Running.
- Check the MQ FDC files in the MQ_install_root/errors and MQ_install_root/qmgrs/queue_manager_name/errors directories to see what relevant error messages may be logged there.
- Check that the queue manager is the default queue manager. If there is no default queue manager, then define one. This can be set in the mqs.ini file. See the WebSphere MQ System Administration Guide for more information.
- Ensure that the queue manager has a listener running and is listening on the right port.
Start the listener program using the following command:
runmqlsr -t tcp -p <port_number> -m <qmgr_name>
Other possible causes for the reason code 2059
If you are using the
CLIENT
transport type to connect to the queue manager on an IPv4/IPv6 dual stack machine — for example, SLES 9 and Redhat Enterprise Linux® 4 — and you use «localhost» as the queue manager name. Either use the machine name or ip address instead of «localhost» or set:
-Djava.net.preferIPv4Stack=true
If you set the
CCSID
, then check this technote.
[{«Product»:{«code»:»SSEQTP»,»label»:»WebSphere Application Server»},»Business Unit»:{«code»:»BU053″,»label»:»Cloud & Data Platform»},»Component»:»Java Message Service (JMS)»,»Platform»:[{«code»:»PF002″,»label»:»AIX»},{«code»:»PF010″,»label»:»HP-UX»},{«code»:»PF012″,»label»:»IBM i»},{«code»:»PF016″,»label»:»Linux»},{«code»:»PF027″,»label»:»Solaris»},{«code»:»PF033″,»label»:»Windows»},{«code»:»PF035″,»label»:»z/OS»}],»Version»:»8.5.5;8.5;8.0;7.0″,»Edition»:»Base;Express;Network Deployment»,»Line of Business»:{«code»:»LOB45″,»label»:»Automation»}},{«Product»:{«code»:»SSNVBF»,»label»:»Runtimes for Java Technology»},»Business Unit»:{«code»:»BU059″,»label»:»IBM Software w/o TPS»},»Component»:»Java SDK»,»Platform»:[{«code»:»»,»label»:»»}],»Version»:»»,»Edition»:»»,»Line of Business»:{«code»:»LOB36″,»label»:»IBM Automation»}}]
I can’t reconnect to MQQueueManager after a while as an exception (reason code 2059 — MQRC_Q_MGR_NOT_AVAILABLE) is thrown when I’m constructing new object of MQQueueManager. My client app is written in .NET/C# and I’m running it on Win2003.
However I can connect to QM after I have restarted my client app. This would indicate that some state is incorrect in QM libraries? How can I reset the state in code so that I could reconnect to QM? Is there a way to reset/disconnect all active TCP connections to QM from client app code?
My connection code:
Hashtable properties = new Hashtable();
properties.Add( MQC.HOST_NAME_PROPERTY, Host );
properties.Add( MQC.PORT_PROPERTY, Port );
properties.Add( MQC.USER_ID_PROPERTY, UserId );
properties.Add( MQC.PASSWORD_PROPERTY, Password );
properties.Add( MQC.CHANNEL_PROPERTY, ChannelName );
properties.Add( MQC.TRANSPORT_PROPERTY, TransportType );
// Following line throws an exception randomly
MQQueueManager queueManager = new MQQueueManager( qmName, properties );
Stack trace:
Source: amqmdnet
CompletionCode: 2
ReasonCode: 2059
Reason: 2059
Stack Trace:
at IBM.WMQ.MQBase.throwNewMQException()
at IBM.WMQ.MQQueueManager.Connect(String queueManagerName)
at IBM.WMQ.MQQueueManager..ctor(String qmName, Hashtable properties)
at WebSphereMQOutboundAdapter.WebSphereMQOutbound.ConnectToWebSphereMQ()
asked Jun 4, 2010 at 10:31
Connections are per-thread so if you are attempting to create a new connection while the previous QMgr object is still instantiated, you would get this. If you close the previous connection and destroy the object before creating a new object you should be OK. Since queues and other WMQ objects depend on a connection handle these will also need to be destroyed and then reinstantiated after the new connection is made.
There are of course a few other explanations for this behavior but these are much less likely. For example, it is possible that a channel exit or (in WMQ v7) configuration could be limiting the number of simultaneous connections from a given IP address. When a connection is severed rather than closed, the channel agent holding the connection on the QMgr side has to time out before the QMgr sees the connection as closed. If connection limiting is in place, these «ghost» connections reduce the available pool. But as I said, this is far less common than programs not cleaning up old objects prior to a reconnect attempt.
There is also the possibility that this is a bug. To reduce that possibility, and for a variety of other reasons such as WMQ v6 going end of life next year, I’d recommend use of WMQ v7.0.1.2 for this project, at both the client and server side. In general, you can use v7.0.1.2 client with a v6.0.x server as long as you stick to v6 functionality. Among other things, .Net code is better integrated in v7 and the Cat-3 SupportPacs are now included in the base install media rather than a separate download.
answered Jun 4, 2010 at 11:28
T.RobT.Rob
31.3k9 gold badges59 silver badges101 bronze badges
After some months fighting with this issue and IBM support, the best solution I found is to change the connect/disconnect code in IBM MQ Driver.
Instead of calling manager.Disconnect() and manager.Close() for each GET/PUT, connect once and then reconnect only if you have some exception (like loosing connection).
What I’ve figure out is that some bug exists in IBM MQ Driver that caches some information for each connect/disconnect. When this buffer is full, the application stops reconnecting.
The driver version (client DLL’s) I have this issue is: 7.0.1.6
answered Jul 14, 2014 at 11:57
Eric LemesEric Lemes
5513 silver badges10 bronze badges
2
Posted Jul 28, 2016 07:50 PM
Thanks for quick reply..
Yes this queue manager and channel is being used by legacy MQ stubs which are maintained in database
flow..
webservice — MQ — mqstubs (database)
what we are trying now is
webservice — mq — lisa
that means we have got just new queues created on existing queue manager and channel but only queue names are different, so that we can use those queues to talk to lisa without impacting existing mqstubs connectivity.
also as I said.. this is not first time we are establishing mq connectivity.. we already have existing mq model running on different queue manager and different channel..
that time we have used ibmwebsphere.crt which was given by mq admin. we have created keystore and truststore in lisa server and imported ibmwebshere.crt into truststore..after done with this we have also configured local.properties with below parameter and this works fine.
javax.net.ssl.keyStore=/opt/lisa/CA/DevTest801/Projects/Certificates/keystores/keystore.jks
javax.net.ssl.keyStorePassword= <YourCertificatePwd>
javax.net.ssl.trustStore=/opt/lisa/CA/DevTest801/Projects/Certificates/keystores/truststore.jks
javax.net.ssl.trustStorePassword= <YourCertificatePwd>
now, similar way our mq admin shared new .crt for new queue manager and that should go into truststore..
because no reason why it should not work while all mq set up is same and certificate also configured…
as per the below link, it says problem with certificate :
https://www.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.tro.doc/q123400_.htm
[search for content ‘ Channel negotiation failed']
the complete logs from devtest consoled failure is :
============================================================================
| Exception:
============================================================================
| Message: MQ LISA6.INQUIRE subscribe
—————————————————————————-
| Trapped Exception: MQJE001: Completion Code ‘2’, Reason ‘2059’.
| Trapped Message: com.ibm.mq.MQException: MQJE001: Completion Code ‘2’, Reason ‘2059’.
—————————————————————————-
STACK TRACE
com.ibm.mq.MQException: MQJE001: Completion Code ‘2’, Reason ‘2059’.
at com.ibm.mq.MQManagedConnectionJ11.<init>(MQManagedConnectionJ11.java:230)
at com.ibm.mq.MQClientManagedConnectionFactoryJ11._createManagedConnection(MQClientManagedConnectionFactoryJ11.java:553)
at com.ibm.mq.MQClientManagedConnectionFactoryJ11.createManagedConnection(MQClientManagedConnectionFactoryJ11.java:593)
at com.ibm.mq.StoredManagedConnection.<init>(StoredManagedConnection.java:95)
at com.ibm.mq.MQSimpleConnectionManager.allocateConnection(MQSimpleConnectionManager.java:198)
at com.ibm.mq.MQQueueManagerFactory.obtainBaseMQQueueManager(MQQueueManagerFactory.java:893)
at com.ibm.mq.MQQueueManagerFactory.procure(MQQueueManagerFactory.java:780)
at com.ibm.mq.MQQueueManagerFactory.constructQueueManager(MQQueueManagerFactory.java:729)
at com.ibm.mq.MQQueueManagerFactory.createQueueManager(MQQueueManagerFactory.java:177)
at com.ibm.mq.MQQueueManager.<init>(MQQueueManager.java:745)
at com.itko.lisa.jms.mq.MQJavaEngine.commonPrepare(MQJavaEngine.java:191)
at com.itko.lisa.jms.mq.MQJavaEngine.prepare(MQJavaEngine.java:155)
at com.itko.lisa.jms.JMSNode.openExec(JMSNode.java:1652)
at com.itko.lisa.jms.JMSNode.execute(JMSNode.java:1897)
at com.itko.lisa.test.TestNode.executeNode(TestNode.java:981)
at com.itko.lisa.test.TestCase.execute(TestCase.java:1280)
at com.itko.lisa.test.TestCase.execute(TestCase.java:1195)
at com.itko.lisa.test.TestCase.executeNextNode(TestCase.java:1180)
at com.itko.lisa.test.TestCase.executeTest(TestCase.java:1124)
at com.itko.lisa.coordinator.Instance.run(Instance.java:204)
Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2059;AMQ9204: Connection to host ‘SVV.UK.COM(60200)’ rejected. [1=com.ibm.mq.jmqi.JmqiException[CC=2;RC=2059;AMQ9503: Channel negotiation failed. [3=RTM.CLIENT.01.01]],3=SVV.UK.COM(60200),5=RemoteConnection.analyseErrorSegment]
at com.ibm.mq.jmqi.remote.api.RemoteFAP.jmqiConnect(RemoteFAP.java:2059)
at com.ibm.mq.jmqi.remote.api.RemoteFAP.jmqiConnect(RemoteFAP.java:1334)
at com.ibm.mq.MQSESSION.MQCONNX_j(MQSESSION.java:924)
at com.ibm.mq.MQManagedConnectionJ11.<init>(MQManagedConnectionJ11.java:219)
… 19 more
Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2059;AMQ9503: Channel negotiation failed. [3=RTM.CLIENT.01.01]
at com.ibm.mq.jmqi.remote.impl.RemoteConnection.analyseErrorSegment(RemoteConnection.java:3836)
at com.ibm.mq.jmqi.remote.impl.RemoteConnection.receiveTSH(RemoteConnection.java:2741)
at com.ibm.mq.jmqi.remote.impl.RemoteConnection.initSess(RemoteConnection.java:1021)
at com.ibm.mq.jmqi.remote.impl.RemoteConnection.connect(RemoteConnection.java:714)
at com.ibm.mq.jmqi.remote.impl.RemoteConnectionSpecification.getSessionFromNewConnection(RemoteConnectionSpecification.java:355)
at com.ibm.mq.jmqi.remote.impl.RemoteConnectionSpecification.getSession(RemoteConnectionSpecification.java:264)
at com.ibm.mq.jmqi.remote.impl.RemoteConnectionPool.getSession(RemoteConnectionPool.java:144)
at com.ibm.mq.jmqi.remote.api.RemoteFAP.jmqiConnect(RemoteFAP.java:1681)
… 22 more
Подключения являются потоками, поэтому, если вы пытаетесь создать новое соединение, в то время как предыдущий объект QMgr все еще создается, вы получите это. Если вы закрываете предыдущее соединение и уничтожаете объект перед созданием нового объекта, вы должны быть в порядке. Поскольку очереди и другие объекты WMQ зависят от дескриптора соединения, они также должны быть уничтожены, а затем повторно восстановлены после создания нового соединения.
Есть, конечно, несколько других объяснений этого поведения, но они гораздо менее вероятны. Например, возможно, что выход канала или (в WMQ v7) может ограничивать количество одновременных соединений с данного IP-адреса. Когда соединение прерывается, а не закрывается, агент канала, поддерживающий соединение на стороне QMgr, должен отключиться до того, как QMgr увидит соединение как закрытое. Если ограничение соединения установлено, эти «призрачные» соединения уменьшают доступный пул. Но, как я уже сказал, это гораздо менее распространено, чем программы, не очищающие старые объекты до попытки повторного подключения.
Существует также вероятность того, что это ошибка. Чтобы уменьшить эту возможность, и по ряду других причин, таких как WMQ v6, конец жизни в следующем году, я бы рекомендовал использовать WMQ v7.0.1.2 для этого проекта как на стороне клиента, так и на стороне сервера. В общем, вы можете использовать клиент v7.0.1.2 с сервером v6.0.x, если вы придерживаетесь функциональности v6. Помимо прочего, код .Net лучше интегрирован в v7, а CatPort 3 поддерживаются в базовом установочном носителе, а не в отдельной загрузке.
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS
Contact US
Thanks. We have received your request and will respond promptly.
Log In
Come Join Us!
Are you a
Computer / IT professional?
Join Tek-Tips Forums!
- Talk With Other Members
- Be Notified Of Responses
To Your Posts - Keyword Search
- One-Click Access To Your
Favorite Forums - Automated Signatures
On Your Posts - Best Of All, It’s Free!
*Tek-Tips’s functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.
Posting Guidelines
Promoting, selling, recruiting, coursework and thesis posting is forbidden.
Students Click Here
MQ Reason code 2059MQ Reason code 2059(OP) 1 Mar 04 21:51 I have a server box housing my app server and MQ server. All the MQ resources defined and able to put message using the sample programs (and receive it in destination queue). MQ listener at port 51414. However, from my application, I always get reason code 2059 (cannot connect to qmgr). Need help. A side question — when making connection to qmgr in app, how does it know which port to direct the connection to? Thanks. Red Flag SubmittedThank you for helping keep Tek-Tips Forums free from inappropriate posts. |
Join Tek-Tips® Today!
Join your peers on the Internet’s largest technical computer professional community.
It’s easy to join and it’s free.
Here’s Why Members Love Tek-Tips Forums:
Talk To Other Members- Notification Of Responses To Questions
- Favorite Forums One Click Access
- Keyword Search Of All Posts, And More…
Register now while it’s still free!
Already a member? Close this window and log in.
Join Us Close