[
https://issues.apache.org/jira/browse/SMXCOMP-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré updated SMXCOMP-768:
-----------------------------------------
Fix Version/s: (was: 2011.01)
2011.02
> 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.02
>
> 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
