Tom Cunningham created JBESB-3779: ------------------------------------- Summary: ServiceInvoker behaviour is inconsistent when used with transactions Key: JBESB-3779 URL: https://issues.jboss.org/browse/JBESB-3779 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Transports Affects Versions: 4.10 Environment: JBoss SOA 5.2.0 Platform Reporter: Michael Burman Fix For: 4.10 CP2 The ServiceInvoker behaviour is inconsistent when it comes to XA transactions. If the delivery fails with ServiceInvoker (there's a network timeout or something), the transaction is still committed, because it does not throw a RuntimeException. So instead of rolling back everything you just did in your actions, the staticRouter or such would commit the process and then throw this to DLQ. So when you run it from DLQ, you would again write to the database and so on. With SmooksSplitter this might cause some messages to go through and some not and other weird behaviour. One fix would be to patch ServiceInvoker deliverAsync (as an example, deliverSync should be fixed also): ### Eclipse Workspace Patch 1.0 #P JBossESB Index: rosetta/src/org/jboss/soa/esb/client/ServiceInvoker.java =================================================================== --- rosetta/src/org/jboss/soa/esb/client/ServiceInvoker.java (revision 37896) +++ rosetta/src/org/jboss/soa/esb/client/ServiceInvoker.java (working copy) @@ -46,9 +46,9 @@ import org.jboss.soa.esb.couriers.Courier; import org.jboss.soa.esb.couriers.CourierException; import org.jboss.soa.esb.couriers.CourierFactory; -import org.jboss.soa.esb.couriers.CourierTimeoutException; import org.jboss.soa.esb.couriers.CourierMarshalUnmarshalException; import org.jboss.soa.esb.couriers.CourierServiceBindException; +import org.jboss.soa.esb.couriers.CourierTimeoutException; import org.jboss.soa.esb.couriers.CourierTransportException; import org.jboss.soa.esb.couriers.CourierUtil; import org.jboss.soa.esb.couriers.FaultMessageException; @@ -57,6 +57,7 @@ import org.jboss.soa.esb.listeners.ha.LoadBalancePolicy; import org.jboss.soa.esb.listeners.ha.ServiceClusterInfo; import org.jboss.soa.esb.listeners.ha.ServiceClusterInfoImpl; +import org.jboss.soa.esb.listeners.jca.JcaGatewayException; import org.jboss.soa.esb.listeners.message.IncompatibleTransactionScopeException; import org.jboss.soa.esb.listeners.message.MessageDeliverException; import org.jboss.soa.esb.listeners.message.MissingServiceException; @@ -253,6 +254,12 @@ try { post(message, new EPRInvoker()); } catch (MessageDeliverException mde) { + + // We want to trigger JCA rollback in case of messagedeliver exception + if(isTransactional()) { + throw new JcaGatewayException(mde); + } + if (message.getProperties().getProperty(RedeliverStore.IS_REDELIVERY)==null && asyncRedelivery(message) && !service.equals(dlqService)) { Here's a quickstart that provides a small example (replace correctBehaviour="true" to get JMS rollbacks), it just tries to call some nonexistant gateway to throw MessageDeliveryException (if there's a proper way to cause timeout in the code, then let me know, but the exception is never the less the same). https://s3-eu-west-1.amazonaws.com/yak/jboss/jms_transacted_fail.zip Once you run it with original settings and it fails, you still end up with lines in the database. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira