| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| The method 'xa_end' has failed with errorCode '100'. |
« View previous topic :: View next topic » |
| Author |
Message
|
| krosan |
 Posted: Mon Dec 06, 2010 8:21 am Post subject: The method 'xa_end' has failed with errorCode '100'. |
 |
|
Newbie
Joined: 06 Dec 2010
Posts: 3
Location: Ghent, Belgium
|
Hey everyone,
After endless hours of google'ing and debugging I just can't figure out the solution to a problem I'm having and I was wondering if you could take a look at my situation. Sadly enough I'm not an expert in MQ and JTA, and figuring out this problem has become quite a struggle.
I've got a Spring (with EJB3) + Hibernate + MQ V7.0.1.3 application framework running on a Glassfish 2.1.1 server.
The point where it goes wrong is when one of my handlers is dealing with a message from a queue in a big transaction in order to send it along to another queue. The normal workflow is not a problem, but when the output queue is full, an exception is thrown and the big transaction is rolled back. That's also successful.
However, when that exception is thrown, the application first has to catch the exception, wrap it in another message and send that message to another queue. That while the big transaction is in suspended mode and the wrapping and sending of the new message is done in a new transaction with propagation: Required_New.
The problem occurs in trying to commit the latter transaction. For some reason MQ gives me an error on the call to commit the new transaction.
Here are some logs to illustrate what's happening:
http://pastebin.com/3sdKNSpp
The SessionException (Session was already closed) is in my opinion not really an important exception as it just lets you know the commit() already closed the connection. However, it could have something to do with the 'xa_end' exception later on?
And that exception - JTS5064: Unexpected exception occurred while delisting the resource javax.transaction.xa.XAException: The method 'xa_end' has failed with errorCode '100'. - is exactly the problem. I've enabled JTA debug logging, but it seems pretty solid.
Do you notice anything strange or anything I can test out to resolve this issue?
Any help would be greatly appreciated!
Kind regards,
Andreas Evers 
Last edited by krosan on Mon Dec 06, 2010 8:29 am; edited 1 time in total |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Dec 06, 2010 8:24 am Post subject: Re: The method 'xa_end' has failed with errorCode '100'. |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| krosan wrote: |
| The problem occurs in trying to commit the latter transaction. For some reason MQ gives me an error on the call to commit the new transaction. |
Are you entirely sure that the new transaction really is in a different unit of work to the first one?
Also what is the reason code of the MQ error you get?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| krosan |
| Posted: Mon Dec 06, 2010 8:35 am Post subject: Re: The method 'xa_end' has failed with errorCode '100'. |
|
|
Newbie
Joined: 06 Dec 2010
Posts: 3
Location: Ghent, Belgium
|
| Vitor wrote: |
| krosan wrote: |
| The problem occurs in trying to commit the latter transaction. For some reason MQ gives me an error on the call to commit the new transaction. |
Are you entirely sure that the new transaction really is in a different unit of work to the first one?
Also what is the reason code of the MQ error you get? |
Everything MQ and the application tells me is in the logs: http://pastebin.com/3sdKNSpp
I'm pretty sure it's a new unit of work, since I annotated the method with this:
| Code: |
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void sendUserEventForException(MessageContext mc, LException e) throws OutboundChannelResolverException { |
Which should make a new transaction. And I'm pretty sure it does considering the logs:
| Quote: |
FINE: TM: suspend
FINE: --Created new J2EETransaction, txId = 3283
INFO: Sending User Event for exception.
INFO: ==== Start building message ====
[...]
FINE: TM: enlistComponentResources
FINE: --In J2EETransaction.registerSynchronization, jtsTx=null nonXAResource=null
FINE: --In J2EETransaction.registerSynchronization, jtsTx=null nonXAResource=null
FINE: In J2EETransactionManagerOpt.enlistResource, h=17 h.xares=com.sun.gjc.spi.XAResourceImpl@7cfbb8 h.alloc=com.sun.enterprise.resource.ConnectorAllocator@506e1d tx=J2EETransaction: txId=3283 nonXAResource=null jtsTx=null localTxStatus=0 syncs=[org.hibernate.transaction.CacheSynchronization, org.hibernate.ejb.AbstractEntityManagerImpl$1@1317d60]
FINE: TM: begin
FINE: TM: enlistResource
FINE: --In J2EETransaction.enlistResource, jtsTx=com.sun.jts.jta.TransactionImpl@7d456ae5 nonXAResource=null
FINE: --In J2EETransaction.registerSynchronization, jtsTx=com.sun.jts.jta.TransactionImpl@7d456ae5 nonXAResource=null
INFO: Hibernate: select [...]
FINE: TM: delistResource
INFO: Sending outbound messages
FINE: --In J2EETransaction.enlistResource, jtsTx=com.sun.jts.jta.TransactionImpl@7d456ae5 nonXAResource=null
INFO: Sending outbound messages SUCCESSFUL
FINE: TM: commit
WARNING: JTS5064: Unexpected exception occurred while delisting the resource
javax.transaction.xa.XAException: The method 'xa_end' has failed with errorCode '100'. |
I think it shows the TransactionManager first suspends the current transaction, then creates a new one (id=3283), enlists the resources and delists them, and then commits the new transaction.
However, it does show
| Quote: |
| FINE: --In J2EETransaction.enlistResource, jtsTx=com.sun.jts.jta.TransactionImpl@7d456ae5 nonXAResource=null |
an enlist of a resource *after* the "delistResource" and right before the commit. Don't know if this is bad in any way, but thought I'd mention this observation. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Dec 06, 2010 8:45 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Ok, I'm somewhat out of my comfort zone with this Java stuff so I'll take your word.
There's nothing in the log segment you provided with a WMQ error in it. It all appears to be errors from the XA transaction manager and other Java stuff (which I feel sure others will be able to make sense of).
I don't see any WMQ error. How are you determining that this is a WMQ problem rather than a problem with the XA framework?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Dec 06, 2010 9:02 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I had a quick look and you might want to investigate your session exception --- session is already closed. Although I would have expected an InvalidStateException...
Beyond that open a PMR. There are some JMS fixes targeted for 7.0.1.4 and even 7.0.1.5 I believe. The PMR should allow you to get an advanced fix if you hit one of those categories. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| krosan |
| Posted: Wed Dec 08, 2010 2:14 am Post subject: |
|
|
Newbie
Joined: 06 Dec 2010
Posts: 3
Location: Ghent, Belgium
|
I investigated the Session Closed exception but the whole architecture behind it seems kind of verbose. Hard to figure out what exactly is going on that causes that error. Needless to say that didn't really got me anywhere further.
@Vitor: The exception that's causing my commit to fail resides from an MQ library. See the logs below.
| Quote: |
WARNING: JTS5064: Unexpected exception occurred while delisting the resource
javax.transaction.xa.XAException: The method 'xa_end' has failed with errorCode '100'.
at com.ibm.mq.jmqi.JmqiXAResource.end(JmqiXAResource.java:457) |
I don't have the sources of that library so I can't debug into it to see what's actually going on. Also, when applying the fixpack V7.0.1.3, the exception changed from The method 'xa_end' has failed with errorCode '-6' to The method 'xa_end' has failed with errorCode '100'. This led me to believe the library has a significant effect on the problem at hand as the exception is in fact influenced by the upgrade of that library.
Perhaps this is a problem in the XA framework that Java (Spring and Hibernate) uses though. Can't rule that out.
@Saper: I'll submit a PMR, however I'm not allowed to send over my project for their reference nor am I able to create a sample application that demonstrates the problem. I hope they'll be able to help me but I'm not completely sure of that. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Dec 08, 2010 3:05 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If your session is closed, that would mean that you need a new session for any MQ commands. Transactionality in MQ JMS is governed by the session.
Have fun
_________________
MQ & Broker admin |
|
| 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
|
|
|
|
