-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
> [EMAIL PROTECTED];
> 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 <[EMAIL PROTECTED]> 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
iD8DBQFFW3cRMrBfzfMVwMcRAtfSAJ0YNlrJZSHMrB+s98tPxyhhUXO4HgCgiUx5
dI0WTpquIOT49YmZ0lUdFnI=
=7GaV
-----END PGP SIGNATURE-----
