[esb-issues] [JBoss JIRA] (JBESB-3752) ServiceInvoker behaviour is inconsistent when used with transactions

[Tom Cunningham (JIRA)]

     [ https://issues.jboss.org/browse/JBESB-3752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Cunningham closed JBESB-3752.
---------------------------------


    
> ServiceInvoker behaviour is inconsistent when used with transactions
> --------------------------------------------------------------------
>
>                 Key: JBESB-3752
>                 URL: https://issues.jboss.org/browse/JBESB-3752
>             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
>            Assignee: Tom Cunningham
>             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