MulticastingRouter needs a new feature to support the execution of multiple endpoints in order

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 2.0.1
  • Fix Version/s: 2.1.1
  • Component/s: Core: Routing / Filters
  • Labels:
    None
  • Environment:

    Mule 1.6 EE on any platforms

  • User impact:
    High
  • Effort points:
    1
  • Affects Docs:
    Yes
  • Migration Impact:
    I'll add a section in the Migration guide and the Router guide
  • Similar Issues:
    None

Description

During POC for one of Mule big customer, one of the requirements is to use MulticastingRouter to feed the same payload to multiple endpoints. The execution of these endpoints must be in order. The sample config is the following:
<mule-descriptor name="updateBatchID" implementation="org.mule.components.simple.BridgeComponent">
<inbound-router>
<endpoint address="jms://yourqueue_name" connector="mqConnector" />
</inbound-router>
<outbound-router>
<router className="org.mule.routing.outbound.MulticastingRouter">
<endpoint address="jdbc://setTransmitted" connector="jdbcConnector" />
<endpoint address="jdbc://setLineStatus" connector="jdbcConnector"/>
</router>
</outbound-router>
</mule-descriptor>
the requirement is endpoint of "jdbc://setTransmitted" must be finished before "jdbc://setLineStatus" is triggered.
The solution is to add "synchronous=true" to "<endpoint address="jdbc://setTransmitted" connector="jdbcConnector" />". So the final config will be like:
<mule-descriptor name="updateBatchID" implementation="org.mule.components.simple.BridgeComponent">
<inbound-router>
<endpoint address="jms://yourqueue_name" connector="mqConnector" />
</inbound-router>
<outbound-router>
<router className="org.mule.routing.outbound.MulticastingRouter">
<endpoint address="jdbc://setTransmitted" connector="jdbcConnector" synchronous="true"/>
<endpoint address="jdbc://setLineStatus" connector="jdbcConnector"/>
</router>
</outbound-router>
</mule-descriptor>

Activity

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

We can only order sync endpoint invocations, async invocations can be ordered and we shouldn't try to do so.

Show
Daniel Feist added a comment - We can only order sync endpoint invocations, async invocations can be ordered and we shouldn't try to do so.
Hide
Permalink
Weiwei Hsieh added a comment -

The current behavior is MulticastingRouter doesn't honor "synchronouns" setting in outbound endpoint. It makes either all sync or all async calls based on inbound endpoint configuration.

The new requirement is

1. reserves the current behavior when inbound endpoint is "sync"
2. however, if inbound endpoint is "async", MulticastingRouter will check the outbound endpoint config. When a specific outbound endpoint is configured as "sync", MulticastingRouter should honor it to make "sync" call for this endpoint. Otherwise, "async" call will be triggered.

In this case, we can control the order of outbound endpoint execution. When we want the order, we configure it as "sync". When we don't care, "async" call shall be the default behavior.

Show
Weiwei Hsieh added a comment - The current behavior is MulticastingRouter doesn't honor "synchronouns" setting in outbound endpoint. It makes either all sync or all async calls based on inbound endpoint configuration. The new requirement is 1. reserves the current behavior when inbound endpoint is "sync" 2. however, if inbound endpoint is "async", MulticastingRouter will check the outbound endpoint config. When a specific outbound endpoint is configured as "sync", MulticastingRouter should honor it to make "sync" call for this endpoint. Otherwise, "async" call will be triggered. In this case, we can control the order of outbound endpoint execution. When we want the order, we configure it as "sync". When we don't care, "async" call shall be the default behavior.
Hide
Permalink
Nicholas Heitz added a comment -

I am adding this comment on the advice of Andrew Perepelytsya following a nabble discussion...

I have been able to get the mutlicasting router to dispatch to the endpoints in order and synchronously because I have a synchronous inbound router. However, I have noticed the following:

1) the endpoint dispatches are not properly isolated from each other with respect to transformations on the message.

Eg.
<multicasting-router>
<outbound-endpoint address="vm://vmout" transformer-refs="eventTransformer"/>
<outbound-endpoint address="jms://jmsout" transformer-refs="eventTransformer ObjectToJms" />
</multicasting-router>

The result of the transform "eventTransformer" is set as the payload of the message, which is correct for the first outbound endpoint, but unfortunately, the transformed message is what gets passed to the "transformer-ref" of the second endpoint.

i.e.
endpoint 1: message A, transform A -> A'
endpoint 2: message A', transform ??
should be
endpoint 2: message A, transform A -> A' -> B

I believe the solution might entail cloning the MuleMessage in MulticastingRouter to avoid sending the side effects to subsequent endpoints when operating in synchronous mode.

Asynchronous mode does not have this problem.

Show
Nicholas Heitz added a comment - I am adding this comment on the advice of Andrew Perepelytsya following a nabble discussion... I have been able to get the mutlicasting router to dispatch to the endpoints in order and synchronously because I have a synchronous inbound router. However, I have noticed the following: 1) the endpoint dispatches are not properly isolated from each other with respect to transformations on the message. Eg. <multicasting-router> <outbound-endpoint address="vm://vmout" transformer-refs="eventTransformer"/> <outbound-endpoint address="jms://jmsout" transformer-refs="eventTransformer ObjectToJms" /> </multicasting-router> The result of the transform "eventTransformer" is set as the payload of the message, which is correct for the first outbound endpoint, but unfortunately, the transformed message is what gets passed to the "transformer-ref" of the second endpoint. i.e. endpoint 1: message A, transform A -> A' endpoint 2: message A', transform ?? should be endpoint 2: message A, transform A -> A' -> B I believe the solution might entail cloning the MuleMessage in MulticastingRouter to avoid sending the side effects to subsequent endpoints when operating in synchronous mode. Asynchronous mode does not have this problem.
Hide
Permalink
Ross Mason added a comment -

This can be closed since the issue was fixed in EE-598.

Show
Ross Mason added a comment - This can be closed since the issue was fixed in EE-598.

People

Vote (1)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: