camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexandre DUTRA <alex...@gmail.com>
Subject Re: Question about Dynamic Router
Date Thu, 28 Apr 2011 07:54:28 GMT
Sorry, I guess attachments aren't allowed here. Please follow the link
below to see the test case and the patch:

https://github.com/adutra/camel-dynamic-router


On Thu, Apr 28, 2011 at 7:36 AM, Claus Ibsen <claus.ibsen@gmail.com> wrote:
> 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