| Author |
Message
|
| urbank |
 Posted: Thu May 10, 2007 4:42 am Post subject: MQJMS2009 'MQQueueManager.commit' failed problem |
 |
|
Novice
Joined: 14 Feb 2007
Posts: 16
Location: St. Gallen / Switzerland
|
Environment:
jdk1.5.0_11
MQ Websphere 6.0
solaris 10
Generally, we can send messages without problems, but when sending a certain message, we get the following errors:
==========================================================================
We get the following error in the client java program:
javax.jms.JMSException: MQJMS2009: MQQueueManager.commit() failed
at com.ibm.mq.jms.services.ConfigEnvironment.newException(ConfigEnvironment.java:567)
at com.ibm.mq.jms.MQSession.commitT(MQSession.java:4079)
at com.ibm.mq.jms.MQTopicSession.commit(MQTopicSession.java:142)
at ch.agi.intra.module.replication.messaging.Publisher.sendMessage(Publisher.java:101)
at ch.agi.intra.module.replication.messaging.enet.MessageSender.main(MessageSender.java:121)
==========================================================================
Here is the error in AMQERR01.LOG (serverside):
----- amqccita.c : 3094 -------------------------------------------------------
05/10/07 13:47:52 - Process(16771.218) User(mqm) Program(amqrmppa)
AMQ9209: Connection to host 'xxx (xxx.xxx.xx.x)' closed.
EXPLANATION:
An error occurred receiving data from 'xxx (xxx.xxx.xx.x)' over TCP/IP. The
connection to the remote host has unexpectedly terminated.
ACTION:
Tell the systems administrator.
----- amqccita.c : 3094 -------------------------------------------------------
05/10/07 13:47:52 - Process(16771.220) User(mqm) Program(amqrmppa)
AMQ9209: Connection to host 'xxx (xxx.xxx.xx.x)' closed.
EXPLANATION:
An error occurred receiving data from 'xxx (xxx.xxx.xx.x)' over TCP/IP. The
connection to the remote host has unexpectedly terminated.
ACTION:
Tell the systems administrator.
==========================================================================
We tried to send the same message on our testplatform (same environment) and this is possible without a problem.
Does anyone know, when exactly these errors occur?
How can I display messages in the queue on unix?
Thanks a lot for any help!
A possible problem:
there are lots of connections open on the MQ Server, which we can not see on the client.
Server (197 is a connected client and 7 is a connected client):
bash-3.00$ netstat -a | grep 1414
mqServerName.1414 xxx.xxx.xx.197.63083 49640 0 49640 0 ESTABLISHED
mqServerName.1414 xxx.xxx.xx.197.64230 49640 0 49640 0 ESTABLISHED
mqServerName.1414 xxx.xxx.xx.7.55246 49640 0 49640 0 ESTABLISHED
mqServerName.1414 xxx.xxx.xx.7.57625 49640 0 49640 0 ESTABLISHED
mqServerName.1414 xxx.xxx.xx.7.49218 49640 0 49640 0 ESTABLISHED
mqServerName.1414 xxx.xxx.xx.7.43384 49640 0 49640 0 ESTABLISHED
mqServerName.1414 xxx.xxx.xx.197.64779 49640 0 49640 0 ESTABLISHED
mqServerName.1414 xxx.xxx.xx.7.64154 49640 0 49640 0 ESTABLISHED
*.1414 *.* 0 0 49152 0 LISTEN
mqServerName.1414 xxx.xxx.xx.197.62925 49640 0 49640 0 ESTABLISHED
mqServerName.1414 xxx.xxx.xx.197.62926 49640 0 49640 0 ESTABLISHED
mqServerName.1414 xxx.xxx.xx.197.62927 49640 0 49640 0 ESTABLISHED
mqServerName.1414 xxx.xxx.xx.7.64915 49640 0 49640 0 ESTABLISHED
mqServerName.1414 xxx.xxx.xx.7.64916 49640 0 49640 0 ESTABLISHED
mqServerName.1414 xxx.xxx.xx.7.64919 49640 0 49640 0 ESTABLISHED
mqServerName.1414 xxx.xxx.xx.7.51633 49640 0 49640 0 ESTABLISHED
mqServerName.1414 xxx.xxx.xx.7.48867 49640 0 49640 0 ESTABLISHED
mqServerName.1414 xxx.xxx.xx.197.63714 49640 0 49640 0 ESTABLISHED
mqServerName.1414 xxx.xxx.xx.197.63825 49640 0 49640 0 ESTABLISHED
mqServerName.1414 xxx.xxx.xx.7.32997 49640 0 49640 0 ESTABLISHED
mqServerName.1414 xxx.xxx.xx.7.57497 49640 0 49640 0 ESTABLISHED
mqServerName.1414 xxx.xxx.xx.7.48430 49640 0 49640 0 ESTABLISHED
mqServerName.1414 xxx.xxx.xx.197.63536 49640 0 49640 0 ESTABLISHED
mqServerName.1414 xxx.xxx.xx.7.39347 49640 0 49640 0 ESTABLISHED
*.1414 *.* 0 0 49152 0 LISTEN
On client 7:
bash-3.00$ netstat -a | grep 1414
xxx.xxx.xx.7.64915 mqServerName.1414 49640 0 49640 0 ESTABLISHED
xxx.xxx.xx.7.64916 mqServerName.1414 49640 0 49640 0 ESTABLISHED
xxx.xxx.xx.7.64919 mqServerName.1414 49640 0 49640 0 ESTABLISHED |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu May 10, 2007 5:14 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
You really need to obtain the linked exception which contains the MQ reason code, but it sounds a lot like you're reaching the max connections on the queue manager.
Displaying messages on the queue in Unix can be achieved using any of the normal means.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu May 10, 2007 12:27 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You may need to add a MAXChannels / MAXActiveChannels stanza to your qmgr. (qm.ini)
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| urbank |
| Posted: Tue Jun 05, 2007 10:30 pm Post subject: |
|
|
Novice
Joined: 14 Feb 2007
Posts: 16
Location: St. Gallen / Switzerland
|
Sorry for the short break....
After restarting our application:
state on mq server:
we see 31 channels (status: running) with
'DISPLAY CHSTATUS(SYSTEM.DEF.SVRCONN)'
we see 31 TCP connections to our mq client with
'netstat -a | grep 1414'
state on mq client (our JMS application):
there are just 3 TCP connections to the mq server
So it might help, if we set a MAXChannels number. What happens, if this number of channel is reached?
How can we remove unused channels?
THANKS A LOT FOR YOUR HELP! |
|
| Back to top |
|
|
| marcin.kasinski |
| Posted: Tue Jun 05, 2007 11:07 pm Post subject: |
|
|
Sentinel
Joined: 21 Dec 2004
Posts: 850
Location: Poland / Warsaw
|
How many connection do you open with your code ?
Do you have any pooling implemented ?
Do you close connections when it is not needed anymore ?
_________________
Marcin |
|
| Back to top |
|
|
| marcin.kasinski |
| Posted: Tue Jun 05, 2007 11:12 pm Post subject: |
|
|
Sentinel
Joined: 21 Dec 2004
Posts: 850
Location: Poland / Warsaw
|
| urbank wrote: |
So it might help, if we set a MAXChannels number.
|
This attribute is supported on z/OS(R) only.
_________________
Marcin |
|
| Back to top |
|
|
| urbank |
| Posted: Wed Jun 06, 2007 12:11 am Post subject: |
|
|
Novice
Joined: 14 Feb 2007
Posts: 16
Location: St. Gallen / Switzerland
|
We open one TopicConnection for sending and one for receiving, totally 2 connections.
We do not have pooling implemented.
We do close the connections, when we detect a problem. We open the connections with an exception listener, so we should be informed about any problems concerning the connection.
Our close procedure (what JMS Objects are concerned):
Subscribers:
topicSubscriber.close();
topicConnection.close();
Publishers:
topicPublisher.close();
topicConnection.close(); |
|
| Back to top |
|
|
| marcin.kasinski |
| Posted: Wed Jun 06, 2007 12:25 am Post subject: |
|
|
Sentinel
Joined: 21 Dec 2004
Posts: 850
Location: Poland / Warsaw
|
| urbank wrote: |
We open one TopicConnection for sending and one for receiving, totally 2 connections.
We do not have pooling implemented.
We do close the connections, when we detect a problem. We open the connections with an exception listener, so we should be informed about any problems concerning the connection.
Our close procedure (what JMS Objects are concerned):
Subscribers:
topicSubscriber.close();
topicConnection.close();
Publishers:
topicPublisher.close();
topicConnection.close(); |
OK, but you have 31 open connections.
Are sure that both of this close statements are reached ?
Are you clossing session also ?
Place all close statements in finally block.
What will happened when first close will throw exception ?
Check it .
_________________
Marcin |
|
| Back to top |
|
|
| urbank |
| Posted: Wed Jun 06, 2007 12:57 am Post subject: |
|
|
Novice
Joined: 14 Feb 2007
Posts: 16
Location: St. Gallen / Switzerland
|
Thank you for your help, marcin.
We open 2 connections from each client to the server and reuse them, so usually we do not have to close any connections.
If we remove the network cable for example, we get an exception and the connections are closed and built up perfectly.
From time to time we get an error, when we try to send:
javax.jms.JMSException: MQJMS3011: Failed to publish message to MQ queue
MQJE001: Completion Code 2, Reason 2009
Then we ..... I found a problem: when we reconnect the connection for publication, we do not close the existing one.
The question remains: why to we not get informed by the Exception listener? And what happens to our subscribers, if they are using a broken connection and are not informed, our application will not get any messages any more?
Thanks a lot |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Jun 06, 2007 3:12 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Well you say very little about your environment. I suspect it to be J2EE.
Remember you should have a connection pool. The whole pool might get invalidated when a connection broken (rc 2009) happens... and you might not get the exception on the exception listener because the ServerSession (J2EE) has already intercepted it for you....??
Anyway this is one of the reason to use J2EE MDB/EJB and have a qmgr on the EJB server so that you don't need a client connection....
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| urbank |
| Posted: Wed Jun 06, 2007 3:45 am Post subject: |
|
|
Novice
Joined: 14 Feb 2007
Posts: 16
Location: St. Gallen / Switzerland
|
Thanks, for your reply.
No, unfortunately, it is not J2EE. It is a pure java jms mq websphere environment. We use durable publish / subscribe.
Is there a reference implementation for using pools for this envrionment?
Is there a possibility to check (with java in the application), if a topicConnection is still up and running?
(just because we do not get all failures from the exception listener). |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Jun 06, 2007 4:04 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The reference implementation for using connection pools with JMS is a J2EE application server.
There are a lot of potential causes for why you aren't seeing the exceptions you're expecting to see in the exception listener.
I'm sure that, if it's possible from within your application to check if the topicConnection is still active, that it's exposed as a method or property on the TopicConnection object. I'd be surprised if that method or property is not documented in the javadoc for JMS.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| urbank |
| Posted: Wed Jun 06, 2007 4:28 am Post subject: |
|
|
Novice
Joined: 14 Feb 2007
Posts: 16
Location: St. Gallen / Switzerland
|
Thank you, jefflowrey.
Neither the TopicConnection object nor the Connection object (super class of TopicConnection in the jms interface) define such kind of method or attribute.
Am I lost between JMS and MQ Websphere 
Here is something, that I found at java.sun.com in the JMS FAQ:
Q: I used the Connection.setExceptionListener(ExceptionListener) method to try to handle connection problems, but when I stop the server, no JMSException seems to be triggered; the onException method is not called. Is this a bug?
A: The JMS specification does not specify exactly what exceptions are delivered to an ExceptionListener or when they are delivered, so providers vary in how they handle connection problems. Check with your JMS provider if you have questions.
The question is:
When exactly does the JMS websphere implementation throw the Exception?
Is it a good idea, to periodically restart the subscriber? |
|
| Back to top |
|
|
|
|
