| Author |
Message
|
| skibodido |
 Posted: Wed Mar 05, 2014 3:39 am Post subject: ExceptionListener not called on transactions log rolled back |
 |
|
Newbie
Joined: 05 Mar 2014
Posts: 5
|
Summary:
-I open a connection and register an ExceptionListener for connection drops
-Then create a non transacted session and register a long running MessageListener
-Another unlrelated process causes the MQ transaction logs to roll back
-My message listener stops receiving messages, but the ExceptionListener.onException is never called to notify there is an issue
-No exceptions are thrown apart from when I shut down my java application and the connection tries to close
Details:
Version:
WebSphere MQ V7.1.0.1
Java code:
| Code: |
connection = qcf.createConnection();
final Session receiverSession = connection.createSession(false, Session.DUPS_OK_ACKNOWLEDGE);
final MessageConsumer messageConsumer = receiverSession.createConsumer(inboundQ);
connection.setExceptionListener(new ExceptionListener() {
@Override
public void onException(JMSException exception) {
// do something about broken connection
}
}); |
MQ Log when transaction log rolled back:
| Code: |
| AMQ7469: Transactions rolled back to release log space. |
When I later manually shutdown java connection:
| Code: |
Exception:
com.ibm.msg.client.jms.DetailedTransactionRolledBackException: JMSCMQ0002: The method 'MQCMIT' failed. A WebSphere MQ call failed. Please see the linked exception for more information.
com.ibm.msg.client.wmq.common.internal.Reason.reasonToException:576
com.ibm.msg.client.wmq.common.internal.Reason.createException:216
com.ibm.msg.client.wmq.common.internal.Reason.createException:254
com.ibm.msg.client.wmq.internal.WMQSession.syncpoint:1534
com.ibm.msg.client.wmq.internal.WMQSession.commit:726
com.ibm.msg.client.jms.internal.JmsSessionImpl.commitTransaction:2231
com.ibm.msg.client.jms.internal.JmsSessionImpl.close:388
com.ibm.msg.client.jms.internal.JmsConnectionImpl.close:293
Exception:
com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed with compcode '1' ('MQCC_WARNING') reason '2003' ('MQRC_BACKED_OUT').
com.ibm.msg.client.wmq.common.internal.Reason.createException:204
com.ibm.msg.client.wmq.common.internal.Reason.createException:254
com.ibm.msg.client.wmq.internal.WMQSession.syncpoint:1534
com.ibm.msg.client.wmq.internal.WMQSession.commit:726
com.ibm.msg.client.jms.internal.JmsSessionImpl.commitTransaction:2231
com.ibm.msg.client.jms.internal.JmsSessionImpl.close:388
com.ibm.msg.client.jms.internal.JmsConnectionImpl.close:293
com.ibm.mq.jms.MQConnection.close:93 |
|
|
| Back to top |
|
 |
| JosephGramig |
| Posted: Wed Mar 05, 2014 5:38 am Post subject: Re: ExceptionListener not called on transactions log rolled |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
| skibodido wrote: |
Details:
Version:
WebSphere MQ V7.1.0.1
|
Really? To begin with "why doesn't this work?", start with "is my mainteance up to date?"
Your way off. Apply maintenance and retest. Remember, never copy MQ JAR files around. Always use a valid install and point to the JAR files from the CLASSPATH. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Mar 05, 2014 6:18 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
From the description I'd say working as designed.
The ExceptionListener is not a convenient way to let you know of problems in your code or environment, like not being setup to deal with a poison message.
It is there to warn you about structural problems, like your MQ connection dropped (problems in the network) etc...
In your case the connection is fine. The problem you have is that you are not dealing with a poison message, and this failure to cope with the poison message is shutting down your MessageListener / MDB.... Why would you expect the ExceptionListener to even know about this?
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Mar 05, 2014 6:20 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| fjb_saper wrote: |
| The problem you have is that you are not dealing with a poison message, and this failure to cope with the poison message is shutting down your MessageListener / MDB.... |
No.
That's not remotely the problem as described. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Mar 05, 2014 6:26 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Sorry I just read transaction log and missed MQ Transactionlog.
However would you expect that to generate a behavior like a poison message or would you expect an Exception to be generated by the Exception listener?
I'd say as long as the connection is not affected there is no Exception being propagated through the ExceptionListener...
If an unrelated problem, like no log space causes a roll back of transactions and the MessageListener is unable to complete the transaction beyond the number of retries specified, it will stop listening... (standard behavior).
The application needs to find a different way to alert the user about the problem. Monitoring comes to mind.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| skibodido |
| Posted: Wed Mar 05, 2014 11:11 am Post subject: |
|
|
Newbie
Joined: 05 Mar 2014
Posts: 5
|
First of all, thanks for the updates...much appriciated.
I accept that the connection is not breaking, so expecting the ExceptionListener to be called was a poor expectation on my part.
However my session/listener is non-transacted, so I don't understand why the transaction rollback caused by another application should affect my messageListener?
I am looking for a pure java based solution to detect this severed messageListener scenario.
I could just periodically recycle my connection or messageListener, but that just seems like a poor hack.
I was wondering if switching my session to transacted might magically fix my issue (with a session.commit() after each message I consume) |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Mar 05, 2014 2:40 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
How do you know that your session was not transacted? In the J2EE environment the global UOW will override the JMS session settings, unless you have defined the transactionality at the method level in the deployment descriptor of your MDB.
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| skibodido |
| Posted: Wed Mar 05, 2014 11:30 pm Post subject: |
|
|
Newbie
Joined: 05 Mar 2014
Posts: 5
|
I'm not in j2ee container. This is a standalone application where I all of my jms objects are created manually (well configured manually)
Just to double check I tried calling session.commit() after consuming a message and it blew up saying 'you can't commit in non-transacted session' |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Mar 06, 2014 3:24 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Well switching to a transacted session might not magically fix your issue. It might however force a JMSException on the commit letting you know that there is something wrong going on...
And of course to make it work you will be forced to fix the root cause ...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| skibodido |
| Posted: Tue Mar 25, 2014 1:53 am Post subject: |
|
|
Newbie
Joined: 05 Mar 2014
Posts: 5
|
Unfortunately I am still having this issue where my MessageListener dissappears without a trace. I only see that it was broken when I shut down our application.
Does anyone know a way (ideally using an MQ connection setting or pure jms spec) of finding out when my MessageListener stops listening?
Are there any settings regarding how many time a MessageListener retries before giving up etc...
When I shutdown the application, the connection.close() seems to identify there was an issue, so I find it hard to believe that I can't find out the same thing whilst it is running and supposidly listening.
From searching through this forum I can see others having issues with same problem...but no solutions yet  |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Mar 25, 2014 3:26 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Did you check if there was an APAR for this issue, or if using the latest version would fix it?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
