[jira] Resolved: (SMXCOMP-768) Invalid asynchronous behavior with EIP filter

["Jean-Baptiste Onofré (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SMXCOMP-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Baptiste Onofré resolved SMXCOMP-768.
------------------------------------------

    Resolution: Fixed

Revision 1065506.

> Invalid asynchronous behavior with EIP filter
> ---------------------------------------------
>
>                 Key: SMXCOMP-768
>                 URL: https://issues.apache.org/jira/browse/SMXCOMP-768
>             Project: ServiceMix Components
>          Issue Type: Bug
>          Components: servicemix-eip
>    Affects Versions: servicemix-eip-2010.01
>         Environment: Fuse ESB - 3.3.1.8
>            Reporter: Trevor Pounds
>            Assignee: Jean-Baptiste Onofré
>             Fix For: 2011.01
>
>         Attachments: MessageFilter-3.3.1.8-fuse.diff
>
>
> Using the EIP message filter with Fuse ESB 3.3.1.8 we noticed incorrect acking when data is sent asynchronously with a large data pipeline.  If the filter is used as an intermediate point within the pipeline it will incorrectly ack the downstream service engines before an upstream exchange has sent back its response.  This becomes troublesome in the case where transactions may be used and an upstream exchange returns an error after the downstream component has completed its exchange.  Consider the following case where a JMS consumer sends to an HTTP provider through an EIP filter. 
> | JMS | -> | FILTER | -> | HTTP |
> When the JMS consumer sends a message to the filter asynchronously the EIP filter acks the JMS consumer immediately regardless of whether the HTTP component has handled it properly. As a result the JMS component has no way to recover from an HTTP fault or error. I've attached a patch that changes the current asynchronous fire and forget behavior to be consistent to how it is done with the EIP static recipient list and pipeline by maintaining a store of exchanges and acking downstream exchanges in an ordered fashion.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira