You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by "Trevor Pounds (JIRA)" <ji...@apache.org> on 2010/06/25 20:35:51 UTC

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

Invalid asynchronous behavior with EIP filter
---------------------------------------------

                 Key: SMXCOMP-768
                 URL: https://issues.apache.org/activemq/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
             Fix For: servicemix-eip-2010.02


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.
-
You can reply to this email to add a comment to the issue online.


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

Posted by "Trevor Pounds (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/activemq/browse/SMXCOMP-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trevor Pounds updated SMXCOMP-768:
----------------------------------

    Attachment: MessageFilter-3.3.1.8-fuse.diff

> Invalid asynchronous behavior with EIP filter
> ---------------------------------------------
>
>                 Key: SMXCOMP-768
>                 URL: https://issues.apache.org/activemq/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
>             Fix For: servicemix-eip-2010.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.
-
You can reply to this email to add a comment to the issue online.