camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject Re: Question about Dynamic Router
Date Thu, 28 Apr 2011 05:36:25 GMT
On Thu, Apr 28, 2011 at 12:58 AM, Alexandre DUTRA <alexdut@gmail.com> wrote:
> I deeply thank you for the interest you manifested for my question.
>
> Unfortunately, your test case does not really correspond to the
> scenario I had in mind. I have attached a new test case that describes
> what I've been trying to achieve with a dynamic router - without
> success so far.

I dont see the new test case.

>
> As you will see, the tests will fail. To fix them, I suggest you apply
> the attached patch to org.apache.camel.processor.DynamicRouter.
>
> The patch describes the behaviour I was initially expecting (and that
> I feel some other users were expecting as well), and which differs
> from the current implementation. Think of it as a state machine that,
> given a message in a given state, predicts what is the next "step" the
> message should go through.
>
> Please tell me if it is worth opening a JIRA issue to go further in
> the discussion.

Yes we should open JIRA ticket if we discover a bug etc. Thats allow
us to keep track of the changes and why we do these.
So if you see a bug open a JIRA and attach your unit test and patch.
And remember to grant access to Apache when attaching the files,
otherwise we can't accept your patches (its a copyright thing)


>
> Alexandre Dutra
>
> On Wed, Apr 27, 2011 at 11:22 PM, Claus Ibsen <claus.ibsen@gmail.com> wrote:
>> Hi
>>
>> I just created an unit test
>> http://svn.apache.org/viewvc?rev=1097245&view=rev
>>
>> And it works fine. It resembles the situation with the 3 calls
>> - 1st call = 2 endpoints
>> - 2nd call = 1 endpoint
>> - 3rd call = null
>>
>> If you look in the code Camel wraps the result of the invocation in an
>> iterator. That iterator knows to handle if there are multiple
>> endpoints separated by comma
>>
>> current = ObjectHelper.createIterator(routingSlip, uriDelimiter);
>>
>>
>>
>> On Wed, Apr 27, 2011 at 10:32 PM, Claus Ibsen <claus.ibsen@gmail.com> wrote:
>>> The intent is that it should stop when a null is retuned.
>>>
>>> And if it doesn't then its a bug. Please create a JIRA, and if
>>> possible attach an unit test which demonstrates the issue.
>>>
>>>
>>>
>>> On Wed, Apr 27, 2011 at 8:40 PM, Alexandre DUTRA <alexdut@gmail.com> wrote:
>>>> Thank you for your reply. All I was saying is that returning null
>>>> immediately after returning a list of endpoints is redundant; the list
>>>> of endpoints is self-sufficient and null should only be used in cases
>>>> where a message arrives, and has absolutely nowhere to go.
>>>>
>>>> But let me illustrate the point with a small scenario based on your own example:
>>>>
>>>> Instant T1: A message is presented for the first time to the router
>>>> which decides to send it to A and B.
>>>> Instant T2: After some time, the same message comes back to the router
>>>> for further processing, and given the routing slip etc. the router
>>>> decides to send it to C.
>>>> Instant T3: After some more time, the message comes back again to the
>>>> router and it decides the message has gone through all steps and
>>>> should not be processed anymore.
>>>>
>>>> To implement such a scenario with the current dynamic router, the
>>>> router's rule engine would be called 5 times in total with the
>>>> following answers:
>>>>
>>>> [T1] go to A and B
>>>> [T1] null
>>>> [T2] go to C
>>>> [T2] null
>>>> [T3] null (=don't go anywhere else, it's finished for good)
>>>>
>>>> Although I understand that this way of doing things might be useful in
>>>> some situations, I was just pointing out that it is rather
>>>> counter-intuitive, not to mention that it is not fully compliant with
>>>> the original definition of a dynamic router.
>>>>
>>>> People (maybe naively) expect only 3 invocations:
>>>>
>>>> [T1] go to A and B
>>>> [T2] go to C
>>>> [T3] null
>>>>
>>>> My suggestion for the DynamicRoutingSlipIterator class achieves this goal.
>>>>
>>>> Alexandre Dutra
>>>>
>>>>
>>>> On Wed, Apr 27, 2011 at 8:01 PM, Claus Ibsen <claus.ibsen@gmail.com>
wrote:
>>>>> It keep going back until it gets a null.
>>>>>
>>>>> Regardless if you return a single endpoint or multiple endpoints
>>>>> separated by comma.
>>>>>
>>>>> eg 1st return is "a,b"
>>>>> eg 2nd return is "c"
>>>>> eg 3rd return is null
>>>>>
>>>>> To stop you must return null.
>>>>>
>>>>>
>>>>> On Wed, Apr 27, 2011 at 7:25 PM, adutra <alexdut@gmail.com> wrote:
>>>>>> According to the documentation, the Dynamic Router should return
null to
>>>>>> indicate no more routings for a given message. But also according
to the
>>>>>> docs, it can alternatively return a comma-separated list of endpoints,
in
>>>>>> which case the router should iterate over them and send a copy of
the
>>>>>> message to each one.
>>>>>>
>>>>>> In fact, I was wondering whether those two different situations (no
more
>>>>>> endpoints vs. multiple endpoints) could have been erroneously mixed
together
>>>>>> in the code:
>>>>>>
>>>>>> The DynamicRoutingSlipIterator class is used to iterate over the
>>>>>> comma-separated list of endpoints returned by the dynamic router
invocation.
>>>>>> But in this class, we have this piece of code:
>>>>>>
>>>>>> public boolean hasNext(Exchange exchange) {
>>>>>>    if (current != null && current.hasNext()) {
>>>>>>        return true;
>>>>>>    }
>>>>>>    // evaluate next slip
>>>>>>    Object routingSlip = slip.evaluate(exchange, Object.class);
>>>>>>    if (routingSlip == null) {
>>>>>>        return false;
>>>>>>    }
>>>>>>    current = ObjectHelper.createIterator(routingSlip, uriDelimiter);
>>>>>>    return current != null && current.hasNext();
>>>>>> }
>>>>>>
>>>>>> This behavior does not seem natural. This iterator actually keeps
"renewing"
>>>>>> itself by reinvoking the same condition on the same exchange, instead
of
>>>>>> iterating over the comma-separated list of endpoints returned by
one single
>>>>>> evaluation of the condition. It can only stop if the condition suddenly
>>>>>> changes and returns null, which in most common situations won't necessarily
>>>>>> happen. I was rather expecting this:
>>>>>>
>>>>>> public boolean hasNext(Exchange exchange) {
>>>>>>    if (current == null) {
>>>>>>        // evaluate next slip
>>>>>>        Object routingSlip = slip.evaluate(exchange, Object.class);
>>>>>>        if (routingSlip == null) {
>>>>>>            return false;
>>>>>>        }
>>>>>>        current = ObjectHelper.createIterator(routingSlip, uriDelimiter);
>>>>>>    }
>>>>>>    return current.hasNext();
>>>>>> }
>>>>>>
>>>>>> Here, the condition is evaluated only once and we have only two possible
>>>>>> situations:
>>>>>>
>>>>>> -it returns null, and it's over;
>>>>>> -it returns a list of endpoints, and then we iterate over the endpoints
>>>>>> returned; but once these endpoints have been processed (i.e. a copy
of the
>>>>>> message has been sent to them), everything is over.
>>>>>>
>>>>>> Moreover, this would explain why some people have expressed concerns
about
>>>>>> the way the dynamic router treats null values; see for instance this
thread:
>>>>>>
>>>>>> http://camel.465427.n5.nabble.com/Custom-Router-td3212534.html
>>>>>>
>>>>>> I would love to have some opinions on this matter.
>>>>>>
>>>>>> Thanks in advance.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> View this message in context: http://camel.465427.n5.nabble.com/Question-about-Dynamic-Router-tp4344271p4344271.html
>>>>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Claus Ibsen
>>>>> -----------------
>>>>> FuseSource
>>>>> Email: cibsen@fusesource.com
>>>>> Web: http://fusesource.com
>>>>> CamelOne 2011: http://fusesource.com/camelone2011/
>>>>> Twitter: davsclaus
>>>>> Blog: http://davsclaus.blogspot.com/
>>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> FuseSource
>>> Email: cibsen@fusesource.com
>>> Web: http://fusesource.com
>>> CamelOne 2011: http://fusesource.com/camelone2011/
>>> Twitter: davsclaus
>>> Blog: http://davsclaus.blogspot.com/
>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> FuseSource
>> Email: cibsen@fusesource.com
>> Web: http://fusesource.com
>> CamelOne 2011: http://fusesource.com/camelone2011/
>> Twitter: davsclaus
>> Blog: http://davsclaus.blogspot.com/
>> Author of Camel in Action: http://www.manning.com/ibsen/
>>
>



-- 
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
CamelOne 2011: http://fusesource.com/camelone2011/
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Mime
View raw message