You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by Guillaume Nodet <gn...@gmail.com> on 2006/12/01 08:26:59 UTC
Re: redelivery after rollback
On 11/30/06, Steve Kondik <sh...@chemlab.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Thanks for ServiceMix btw, it's great to be able to write complex
> messaging/XML processing apps without a whole lot of pain. SM + MINA is a
> pretty powerful combination.
>
Can you explain a bit how you use MINA ?
> I have a question about autoEnlistInTransaction.. Is this actually needed with
> JCAFlow, or does it cause problems? What's the best practice here? I noticed
> that even if I turn it off, a transaction is created because if I call
> tm.begin() I'll get an exception about nested transactions not being
> supported. What I want is for everything that happens in the component to
> happen under the same transaction scope.. If an uncaught exception occurs, the
> whole thing rolls back including JDBC.
The autoEnlistInTransaction just says that if a transaction is active
in a thread
and a JBI exchange is sent, the exchange will be enlisted or will
convey the current
transaction (depending if you use send or sendSync).
>
> I'm wondering if it's Oracle's XA implementation that's causing a problem (I'm
> using oracle.jdbc.xa.client.OracleXADataSource for JDBC). I'll try something
> like Tranql and see if that helps.
Or try another database like Derby to check if it also fail.
>
>
> Guillaume Nodet wrote:
> > I found a bug in ActiveMQ yesterday which has been fixed.
> > See https://issues.apache.org/activemq/browse/AMQ-1078
> > You need a fresh version of ActiveMQ using trunk or 4.1 branch.
> >
> > I have also seen the "the transaction context set in the
> > messageExchange is not bound to the current thread"
> > exception but have not been able to reproduce it.
> >
> >
> > On 11/28/06, Steve Kondik <sh...@chemlab.org> wrote:
> > I just grabbed the latest Jencks SVN and I'm still getting some weird
> > behavior. Sometimes components will start, but they won't consume any
> > messages. If I send a bunch of messages at the component, eventually
> > it will
> > start consuming them.. Really strange. Sometimes messages get to
> > their final
> > destination, sometimes I get exceptions from the EIP component. Rollback
> > looks to be working though.
> >
> > Here's the exception I'm getting from the EIP component.. The
> > component that
> > is feeding it is using Spring-JDBC, but I still get the exception if I
> > feed it
> > with any other standard component.
> >
> > javax.jbi.messaging.MessagingException:
> > java.lang.IllegalStateException: the
> > transaction context set in the messageExchange is not bound to the
> > current thread
> > at
> > org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.autoEnlistInTx(DeliveryChannelImpl.java:788)
> >
> > at
> > org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.doSend(DeliveryChannelImpl.java:337)
> >
> > at
> > org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.send(DeliveryChannelImpl.java:397)
> >
> > at
> > org.apache.servicemix.eip.EIPEndpoint.send(EIPEndpoint.java:207)
> > at
> > org.apache.servicemix.eip.EIPEndpoint.done(EIPEndpoint.java:219)
> > at
> > org.apache.servicemix.eip.support.AbstractContentBasedRouter.processAsync(AbstractContentBasedRouter.java:131)
> >
> > at
> > org.apache.servicemix.eip.EIPEndpoint.process(EIPEndpoint.java:241)
> > at
> > org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:490)
> >
> > at
> > org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:464)
> >
> > at
> > org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:46)
> >
> > at
> > org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:610)
> >
> > at
> > org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:174)
> >
> > at
> > org.apache.servicemix.jbi.nmr.flow.jca.JCAFlow.onMessage(JCAFlow.java:515)
> >
> > at org.jencks.XAEndpoint.onMessage(XAEndpoint.java:129)
> > at
> > org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.onMessage(MessageEndpointProxy.java:121)
> >
> > at
> > org.apache.activemq.ra.MessageEndpointProxy.onMessage(MessageEndpointProxy.java:61)
> >
> > at
> > org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:695)
> > at
> > org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java:165)
> > at
> > edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
> >
> >
> > Followed by:
> >
> > 20:19:57,403 ERROR
> > [pool-flow.jca.org.apache.servicemix.jca.ServiceMix-thread-3]
> > org.apache.servicemix.eip.EIPComponent: Error setting exchange status
> > to ERROR
> > javax.jbi.messaging.MessagingException: illegal call to send / sendSync
> > at
> > org.apache.servicemix.jbi.messaging.MessageExchangeImpl.handleSend(MessageExchangeImpl.java:571)
> >
> > at
> > org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.doSend(DeliveryChannelImpl.java:350)
> >
> > at
> > org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.send(DeliveryChannelImpl.java:397)
> >
> > at
> > org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:58)
> >
> > at
> > org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:610)
> >
> > at
> > org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:174)
> >
> > at
> > org.apache.servicemix.jbi.nmr.flow.jca.JCAFlow.onMessage(JCAFlow.java:515)
> >
> > at org.jencks.XAEndpoint.onMessage(XAEndpoint.java:129)
> > at
> > org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.onMessage(MessageEndpointProxy.java:121)
> >
> > at
> > org.apache.activemq.ra.MessageEndpointProxy.onMessage(MessageEndpointProxy.java:61)
> >
> > at
> > org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:695)
> > at
> > org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java:165)
> > at
> > edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
> >
> >
> >
> > Guillaume Nodet wrote:
> >> I have fixed several problems in jencks recently.
> >> What patch did you apply ?
> >
> >> On 11/28/06, Steve Kondik <sh...@chemlab.org> wrote:
> >> I found that I could get redelivery to work by patching Jencks, but
> >> it's very
> >> unreliable. Sometimes endpoints will fail to start, messages will get
> >> dropped, and the EIP component throws exceptions (pipeline in
> > particular)
> >> about the transaction not being bound to the current thread. I'm also
> >> using
> >> Spring-JDBC inside a couple of custom components (using the same
> >> transaction
> >> manager). I haven't been able to track down the cause of these
> > problems
> >> though, but I'm not very familiar with Geronimo's transaction stuff.
> >
> >> I'm sure the devs are aware of it (tickets for failing tests), and the
> >> supporting libraries are also still in flux. I disabled JCAFlow for
> >> now until
> >> I'm closer to release (I'm using SM embedded).
> >
> >
> >> cnicolai wrote:
> >>> Has anyone found a solution for this problem?
> >
> >>> I'm having the same problem (XA error code: -6), even with the 3.1
> >> snapshot
> >>> build.
> >
> >>> I tried many kinds of configuration to integrate Spring/Hibernate
> >> with the
> >>> servicemix transaction (JCA Flow), but when an exception occurs (i
> >> mark the
> >>> transaction by the setRollbackonly) i get this error and the
> >> modifications
> >>> are commited in the database.
> >
> >
> >>> Thanks.
> >
> >
> >
> >
> >
> >
> >>> Steve Kondik wrote:
> >>> I dug into this further, and it turns out to be a problem with Jencks.
> >>> Jencks
> >>> tries to commit() in afterDelivery and catches RollbackException,
> >> which it
> >>> then rethrows as a ResourceException. The ResourceException gets
> >> caught
> >>> by
> >>> the RA and rethrown again as a RuntimeException, which invalidates the
> >>> endpoint.
> >
> >>> I removed the rethrow of ResourceException from Jencks, and
> >> redeliveries
> >>> work
> >>> perfectly now.
> >
> >>> I will file a bug/patches against Jencks. I think Jencks 2.0 is
> >> falling
> >>> behind the supporting Geronimo code, as it needs other fixes to work
> >>> correctly
> >>> (HowlLogFactoryBean no longer works).
> >
> >
> >>> Steve Kondik wrote:
> >>>>>> I'm also seeing this exception on rollback:
> >>>>>>
> >>>>>> WARN
> >>>>>>
> >
> > [pool-flow.jca.org.apache.servicemix.jca.{http://services.hmsinc.com/}LLPConnector:endpoint-thread-1]
> >
> >
> >>>>>> Transaction: Error ending association for XAResource
> >>>>>>
> >
> > org.apache.geronimo.transaction.manager.WrapperNamedXAResource@490eb6ae;
> >>>>>> transaction will roll back. XA error code: -6
> >>>>>> javax.transaction.xa.XAException
> >>>>>> at
> >>>>>>
> >> org.apache.activemq.TransactionContext.end(TransactionContext.java:319)
> >>>>>> at
> >>>>>>
> >
> > org.apache.activemq.ra.LocalAndXATransaction.end(LocalAndXATransaction.java:90)
> >
> >
> >>>>>> at
> >>>>>>
> >
> > org.apache.geronimo.transaction.manager.WrapperNamedXAResource.end(WrapperNamedXAResource.java:51)
> >
> >
> >>>>>> at
> >>>>>>
> >
> > org.apache.geronimo.transaction.manager.TransactionImpl.endResources(TransactionImpl.java:572)
> >
> >
> >>>>>> at
> >>>>>>
> >
> > org.apache.geronimo.transaction.manager.TransactionImpl.endResources(TransactionImpl.java:552)
> >
> >
> >>>>>> at
> >>>>>>
> >
> > org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare(TransactionImpl.java:401)
> >
> >
> >>>>>> at
> >>>>>>
> >
> > org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:257)
> >
> >
> >>>>>> at org.jencks.XAEndpoint.afterDelivery(XAEndpoint.java:103)
> >>>>>> at
> >>>>>>
> >
> > org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.afterDelivery(MessageEndpointProxy.java:126)
> >
> >
> >>>>>> at
> >>>>>>
> >
> > org.apache.activemq.ra.MessageEndpointProxy.afterDelivery(MessageEndpointProxy.java:65)
> >
> >
> >>>>>> at
> >>>>>>
> >
> > org.apache.activemq.ra.ServerSessionImpl.afterDelivery(ServerSessionImpl.java:216)
> >
> >
> >>>>>> at
> >> org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:749)
> >>>>>> at
> >>>>>>
> >
> > org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java:165)
> >>>>>> at
> >>>>>>
> >
> > edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
> >
> >
> >>>>>> at
> >>>>>>
> >
> > edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
> >
> >
> >>>>>> at java.lang.Thread.run(Thread.java:595)
> >>>>>> INFO
> >>>>>>
> >
> > [pool-flow.jca.org.apache.servicemix.jca.{http://services.hmsinc.com/}LLPConnector:endpoint-thread-1]
> >
> >
> >>>>>> org.apache.activemq.ra.ServerSessionImpl:8: Endpoint failed to
> >> process
> >>>>>> message. Reason: java.lang.RuntimeException: Endpoint after
> > delivery
> >>>>>> notification failure
> >>>>>>
> >>>>>> I'm not sure where this problem is.. My component, Jencks,
> >> Geronimo TM,
> >>>>>> ....
> >>>>>> -6 is XAER_PROTO, so I am a bit lost here.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Guillaume Nodet wrote:
> >>>>>>>> Weird.
> >>>>>>>> There are some test cases that check that redelivery works
> >>>>>>>> on JCA flow ...
> >>>>>>>> This behavior occurs mainly when using client ack
> >>>>>>>> (messages are only redelivered when the connection
> >>>>>>>> which has consumed the messages but not returned any
> >>>>>>>> acks close).
> >>>>>>>>
> >>>>>>>> On 11/15/06, Steve Kondik <sh...@chemlab.org> wrote:
> >>>>>>>> I've written a few custom components with 3.1-SNAPSHOT. If an
> >>>>>>>> exception is
> >>>>>>>> thrown, the transaction does indeed rollback (I'm using
> >> JCAFlow), but
> >>>>>>>> no
> >>>>>>>> redelivery ever occurs.
> >>>>>>>>
> >>>>>>>> I've tried configuring a redeliveryPolicy on the connection
> >> factory,
> >>>>>>>> but it
> >>>>>>>> does not seem to help.
> >>>>>>>>
> >>>>>>>> I can see that the failed messages are put back on the queue.
> >> If I
> >>>>>>>> restart
> >>>>>>>> ServiceMix, the failed messages get redelivered, but otherwise
> >> they
> >>>>>>>> just sit
> >>>>>>>> on the queue forever.
> >>>>>>>>
> >>>>>>>> Is there some bit of magic that I am missing to make redelivery
> >> work?
> >>>>>>>> My
> >>>>>>>> component is a TCP connector for HL7 messages, and I need to be
> >>>>>>>> absolutely
> >>>>>>>> sure that nothing is lost due to a remote server being down.
> >>>>>>>>
> >
> >
> >
> >
> >
> >>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFFbvyvMrBfzfMVwMcRAhY9AJ9+chxYp/FkvsuoARBxeymaSxSuiQCgoAt8
> oPfUWP4US6v0MNJ4eaRHOv0=
> =dPUI
> -----END PGP SIGNATURE-----
>
--
Cheers,
Guillaume Nodet
Re: redelivery after rollback
Posted by Steve Kondik <sh...@chemlab.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Guillaume Nodet wrote:
> On 11/30/06, Steve Kondik <sh...@chemlab.org> wrote:
> Thanks for ServiceMix btw, it's great to be able to write complex
> messaging/XML processing apps without a whole lot of pain. SM + MINA
> is a
> pretty powerful combination.
>
>
>> Can you explain a bit how you use MINA ?
The software my company is developing is an HL7 messaging system that is
designed for high throughput. We use MINA in a JBI component for
sending/receiving HL7 messages over TCP because we needed to be able to handle
thousands of concurrent inbound connections (without having thousands of
threads). We also needed to do data transformation/scripting as well as
integrate with various biosurveillance systems so ServiceMix was an obvious
choice. The software will be released under an open source license in a few weeks.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFcB8cMrBfzfMVwMcRAqhtAKCE7lNF970iaYuOPF2NolZx0d3LlQCgmayf
2aO6VSFxWA0edws3zQcz0dg=
=YXPw
-----END PGP SIGNATURE-----