servicemix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré (JIRA) <>
Subject [jira] Updated: (SMXCOMP-768) Invalid asynchronous behavior with EIP filter
Date Sun, 06 Feb 2011 09:51:33 GMT


Jean-Baptiste Onofré updated SMXCOMP-768:

    Fix Version/s:     (was: 2011.01)

> Invalid asynchronous behavior with EIP filter
> ---------------------------------------------
>                 Key: SMXCOMP-768
>                 URL:
>             Project: ServiceMix Components
>          Issue Type: Bug
>          Components: servicemix-eip
>    Affects Versions: servicemix-eip-2010.01
>         Environment: Fuse ESB -
>            Reporter: Trevor Pounds
>            Assignee: Jean-Baptiste Onofré
>             Fix For: 2011.02
>         Attachments: MessageFilter-
> Using the EIP message filter with Fuse ESB 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:


View raw message