Return-Path: X-Original-To: apmail-camel-users-archive@www.apache.org Delivered-To: apmail-camel-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A59E63259 for ; Thu, 28 Apr 2011 05:37:16 +0000 (UTC) Received: (qmail 74847 invoked by uid 500); 28 Apr 2011 05:37:16 -0000 Delivered-To: apmail-camel-users-archive@camel.apache.org Received: (qmail 74702 invoked by uid 500); 28 Apr 2011 05:37:16 -0000 Mailing-List: contact users-help@camel.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@camel.apache.org Delivered-To: mailing list users@camel.apache.org Received: (qmail 74694 invoked by uid 99); 28 Apr 2011 05:37:13 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 28 Apr 2011 05:37:13 +0000 X-ASF-Spam-Status: No, hits=0.6 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL,URI_HEX X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of claus.ibsen@gmail.com designates 74.125.83.173 as permitted sender) Received: from [74.125.83.173] (HELO mail-pv0-f173.google.com) (74.125.83.173) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 28 Apr 2011 05:37:07 +0000 Received: by pvg3 with SMTP id 3so1973026pvg.32 for ; Wed, 27 Apr 2011 22:36:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type:content-transfer-encoding; bh=G05WpjnXhBoW+dyDRjtG7Ql+gNmf+Y3kdDXgSzD0jLA=; b=eYEOgwGywq/eZ9xYMuhkDi+KXkC4gTf3Eb5y6pIVJKsxE4RhGAMTrfG84cVtM7yjnq ij9iBLZzPFqc4S3i6PdFJrsPWxKJIdjKbh2KpnYU5odP+LJ0nt976NaEjfwCJ1aNFI5Y cy05Go43RtKJusmPk36yXb3TC8y1ly/VAcDGo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=nCnyrJM+c9Gz7Mr+nuGC+KncLZh9TBYxguZ9CN9+B67hUGBajFpQ9/HsCmD2GVpYxx dmQVFU6gfdXMcsgWbyCo/vomDrSOIJlk87LrrVxvjfJwgm/AKhPiX3afP9nHW6IU1nqT aPW0JLVsuvvfh6LqgpK8xdECkwqKoOG2BL/oY= Received: by 10.68.7.66 with SMTP id h2mr3359551pba.513.1303969005244; Wed, 27 Apr 2011 22:36:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.40.35 with HTTP; Wed, 27 Apr 2011 22:36:25 -0700 (PDT) In-Reply-To: References: <1303925127418-4344271.post@n5.nabble.com> From: Claus Ibsen Date: Thu, 28 Apr 2011 07:36:25 +0200 Message-ID: Subject: Re: Question about Dynamic Router To: users@camel.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Thu, Apr 28, 2011 at 12:58 AM, Alexandre DUTRA 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 wro= te: >> Hi >> >> I just created an unit test >> http://svn.apache.org/viewvc?rev=3D1097245&view=3Drev >> >> And it works fine. It resembles the situation with the 3 calls >> - 1st call =3D 2 endpoints >> - 2nd call =3D 1 endpoint >> - 3rd call =3D 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 =3D ObjectHelper.createIterator(routingSlip, uriDelimiter); >> >> >> >> On Wed, Apr 27, 2011 at 10:32 PM, Claus Ibsen wr= ote: >>> 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 wr= ote: >>>> 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 ow= n 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 (=3Ddon'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 g= oal. >>>> >>>> Alexandre Dutra >>>> >>>> >>>> On Wed, Apr 27, 2011 at 8:01 PM, Claus Ibsen w= rote: >>>>> 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 wrote: >>>>>> According to the documentation, the Dynamic Router should return nul= l to >>>>>> indicate no more routings for a given message. But also according to= the >>>>>> docs, it can alternatively return a comma-separated list of endpoint= s, in >>>>>> which case the router should iterate over them and send a copy of th= e >>>>>> 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 inv= ocation. >>>>>> But in this class, we have this piece of code: >>>>>> >>>>>> public boolean hasNext(Exchange exchange) { >>>>>> =A0 =A0if (current !=3D null && current.hasNext()) { >>>>>> =A0 =A0 =A0 =A0return true; >>>>>> =A0 =A0} >>>>>> =A0 =A0// evaluate next slip >>>>>> =A0 =A0Object routingSlip =3D slip.evaluate(exchange, Object.class); >>>>>> =A0 =A0if (routingSlip =3D=3D null) { >>>>>> =A0 =A0 =A0 =A0return false; >>>>>> =A0 =A0} >>>>>> =A0 =A0current =3D ObjectHelper.createIterator(routingSlip, uriDelim= iter); >>>>>> =A0 =A0return current !=3D null && current.hasNext(); >>>>>> } >>>>>> >>>>>> This behavior does not seem natural. This iterator actually keeps "r= enewing" >>>>>> itself by reinvoking the same condition on the same exchange, instea= d of >>>>>> iterating over the comma-separated list of endpoints returned by one= single >>>>>> evaluation of the condition. It can only stop if the condition sudde= nly >>>>>> changes and returns null, which in most common situations won't nece= ssarily >>>>>> happen. I was rather expecting this: >>>>>> >>>>>> public boolean hasNext(Exchange exchange) { >>>>>> =A0 =A0if (current =3D=3D null) { >>>>>> =A0 =A0 =A0 =A0// evaluate next slip >>>>>> =A0 =A0 =A0 =A0Object routingSlip =3D slip.evaluate(exchange, Object= .class); >>>>>> =A0 =A0 =A0 =A0if (routingSlip =3D=3D null) { >>>>>> =A0 =A0 =A0 =A0 =A0 =A0return false; >>>>>> =A0 =A0 =A0 =A0} >>>>>> =A0 =A0 =A0 =A0current =3D ObjectHelper.createIterator(routingSlip, = uriDelimiter); >>>>>> =A0 =A0} >>>>>> =A0 =A0return current.hasNext(); >>>>>> } >>>>>> >>>>>> Here, the condition is evaluated only once and we have only two poss= ible >>>>>> situations: >>>>>> >>>>>> -it returns null, and it's over; >>>>>> -it returns a list of endpoints, and then we iterate over the endpoi= nts >>>>>> 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/Ques= tion-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/ >> > --=20 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/