setStopFurtherProcessing(true) is not working with flows

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 3.2.x
  • Fix Version/s: None
  • Component/s: Core: API
  • Labels:
    None
  • User impact:
    Medium
  • Similar Issues:
    None

Description

eventContext.setStopFurtherProcessing(true) does not seem to be working with flows. As it is in the attachment, pattern_In-Optional-Out_Out-Only-Async-Router-flow.xml doesn't work when tested with InOptionalOutOutOnlyAsyncRouterTestCase.java because processing continues. A filter can be used to pass the test case:

<mule:message-filter>
<mule:not-filter>
<mule:payload-type-filter expectedType="org.mule.transport.NullPayload"></mule:payload-type-filter>
</mule:not-filter>
</mule:message-filter>

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Daniel Feist added a comment -

I thought we no longer supported this for flows, but maybe we never documented this. Of course the recommended approach is to use filters.

Show
Daniel Feist added a comment - I thought we no longer supported this for flows, but maybe we never documented this. Of course the recommended approach is to use filters.
Hide
Permalink
Pablo Kraan added a comment -

Dan, what is the status of this? Can you confirm that is working as designed and just needs documentation?

Show
Pablo Kraan added a comment - Dan, what is the status of this? Can you confirm that is working as designed and just needs documentation?
Hide
Permalink
Daniel Feist added a comment -

This is still in the API and is not deprecated. It is supported for Services still, but does not work for flows.

In flows if you need to stop processing you should use a filter. We could make this work though, we'd check for this in the MessageProcessorChain, this would allow non-intercepting processors (e.g. components) to stop processing.

Show
Daniel Feist added a comment - This is still in the API and is not deprecated. It is supported for Services still, but does not work for flows. In flows if you need to stop processing you should use a filter. We could make this work though, we'd check for this in the MessageProcessorChain, this would allow non-intercepting processors (e.g. components) to stop processing.
Hide
Permalink
Mike Schilling added a comment - - edited

In a service, the stopFurtherMessageProcessing flag is checked at two points only:

1. After the inbound section
2. Before the outbound section

Flows aren't delimited so nicely. If we had the ability to check after every MP,that might make sense, but we don't (as Dan points out, we'd treat intercepting MPs differently from non-intercepting MPs). I think we should disallow this for non-services, and issue a warning if it's called on an event associated with a non-service.

Show
Mike Schilling added a comment - - edited In a service, the stopFurtherMessageProcessing flag is checked at two points only: 1. After the inbound section 2. Before the outbound section Flows aren't delimited so nicely. If we had the ability to check after every MP,that might make sense, but we don't (as Dan points out, we'd treat intercepting MPs differently from non-intercepting MPs). I think we should disallow this for non-services, and issue a warning if it's called on an event associated with a non-service.
Hide
Permalink
Mike Schilling added a comment -

It's also unclear to me what the desired behavior is. In a one-way flow, for instance, should

1. All message processors be skipped
2. All message processors other than outbound endpoints be skipped
3. All message processors other than the final outbound endpoint (if any) be skipped

Show
Mike Schilling added a comment - It's also unclear to me what the desired behavior is. In a one-way flow, for instance, should 1. All message processors be skipped 2. All message processors other than outbound endpoints be skipped 3. All message processors other than the final outbound endpoint (if any) be skipped
Hide
Permalink
Daniel Feist added a comment -

Reducing priority to major. Filters not work correctly anywhere after fix for MULE-6146.

Show
Daniel Feist added a comment - Reducing priority to major. Filters not work correctly anywhere after fix for MULE-6146.

People

  • Assignee:
    Daniel Feist
    Reporter:
    Justin Calleja
Vote (0)
Watch (0)

Dates

  • Created:
    Updated: