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 68D2898BF for ; Fri, 7 Oct 2011 13:07:44 +0000 (UTC) Received: (qmail 86198 invoked by uid 500); 7 Oct 2011 13:07:44 -0000 Delivered-To: apmail-camel-users-archive@camel.apache.org Received: (qmail 86135 invoked by uid 500); 7 Oct 2011 13:07:44 -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 86127 invoked by uid 99); 7 Oct 2011 13:07:44 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Oct 2011 13:07:43 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of bcanhome@googlemail.com designates 209.85.210.173 as permitted sender) Received: from [209.85.210.173] (HELO mail-iy0-f173.google.com) (209.85.210.173) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Oct 2011 13:07:36 +0000 Received: by iakl21 with SMTP id l21so1276207iak.32 for ; Fri, 07 Oct 2011 06:07:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ELtPvpPGk0rgXBKo/e29P2cYPht3krGIuM9kQYsEYzw=; b=KrOtrz5ijPXgN2A9qbRxbC6mtwCbpxfk3rR7voKFDMOVAIfIxr90qYAxeccitZLyHS gFc/24v2OawvNDbemD1k64DaNCiphsGc2NU1RyB1fzMU/mX/SyyWcCYqTazLxqP4jzhP h/8d5i4crHWnG73vRUWM66bKaKMwAZaVHrSIg= MIME-Version: 1.0 Received: by 10.42.189.6 with SMTP id dc6mr12713435icb.16.1317992834946; Fri, 07 Oct 2011 06:07:14 -0700 (PDT) Received: by 10.231.12.74 with HTTP; Fri, 7 Oct 2011 06:07:14 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Oct 2011 15:07:14 +0200 Message-ID: Subject: Re: recipientList inside SEDA route with CXF From: Achim Nierbeck To: users@camel.apache.org Content-Type: multipart/alternative; boundary=20cf303ea6a4be557204aeb51ec3 X-Virus-Checked: Checked by ClamAV on apache.org --20cf303ea6a4be557204aeb51ec3 Content-Type: text/plain; charset=ISO-8859-1 Ok, this only solved half of my problem or better it postponed it. Now I do have the following scenario: Call for Service on Host A works as expected, the Endpoint is stored in the cache. Call for Service on Host B does create a new Endpoint and this one is also stored in the cache. Now a third call to a service on Host A ends up on endpoint B somehow the Cache returns endpoint B for requesting EndpointKey made up of URI for Host A. Any help is welcome since this now is turning into a Major bug for me :( Thanx, Achim 2011/9/30 Achim Nierbeck > The suggested workaround by Jon really does the trick. > > instead of using the recipientlist inside the spring route: > > > > > cxf:bean:productionServer?address=${header.address} > > > I used a std. bean which looks like the following: > > public class WebServiceRecipientListBean { > > @RecipientList(parallelProcessing=true) > public String route(@Header("address") String address) { > if (address == null) > return null; > > return "cxf:bean:productionServer?address="+address; > } > > } > > This pretty much did the trick. > > Thanks a lot for the fast help and regards, Achim > > 2011/9/29 Jon Anstey : > > FYI created https://issues.apache.org/jira/browse/CAMEL-4503 for the > > recipient list bug and Achim is trying out another approach to workaround > > this issue. > > > > On Thu, Sep 29, 2011 at 11:46 AM, Achim Nierbeck < > bcanhome@googlemail.com>wrote: > > > >> I did take a look at the sources and I think I found the > >> root of my problem, though I'm not sure how to get around it: > >> > >> RecipientList class contains a producer cache, > >> in this cache the RecipientListProcessor class does store the > >> endpoints depending on the uri as key. > >> Now since only my header changes I don't know how to get around this. > >> Any ideas? > >> > >> Thanks in advance, Achim > >> > >> 2011/9/29 Achim Nierbeck : > >> > Ok, > >> > > >> > some more worrying details. > >> > > >> > Right now I have two Remote Hosts > >> > After a successful run on Host A a second run is done (not parallel > >> > but sequential) on Host B. > >> > And I'm able to see that the header.address is set to host B still I > >> > see that the request is made on Host A. > >> > > >> > Is this intentional, are there any ways of not "remembering" which > >> > call did go to which Host? > >> > > >> > Thanks again, Achim > >> > > >> > 2011/9/29 Achim Nierbeck : > >> >> Hi > >> >> > >> >> using Camel 2.8.0 I'm having the following scenario. > >> >> I'm using the CXF for connecting to a couple .NET Webservices. > >> >> > >> >> > >> >> >> >> > >> serviceClass="net.testservices.productionservice._2011_07.IService" > >> >> endpointName="s:basicHttpProductionService" > >> serviceName="s:ProductionService" > >> >> wsdlURL="classpath:/wsdl/_1.wsdl" xmlns:s=" > >> http://tempuri.org/" > >> >> xmlns:a=" > >> http://schemas.microsoft.com/2003/10/Serialization/Arrays" > >> >> xmlns:i="http://www.w3.org/2001/XMLSchema-instance"> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> Now I have a route for looking up some data in the DB for example > also > >> >> looking for a free > >> >> WebService to call: > >> >> > >> >> > >> >> >> uri="timer://pollQueueTimer?fixedRate=true&period=30000" /> > >> >> > >> >> ... do preparation .... > >> >> ... also set the address of the remote host into the header of the > >> exchange ... > >> >> ... call the "production" route ... > >> >> > >> >> uri="seda:production" > >> /> > >> >> > >> >> > >> >> the production route does call the Webservice on the available remote > >> >> host as follows > >> >> > >> >> ... again a couple of preparations beforehand .... > >> >> > >> >> > >> >> > >> >> [ ] > >> >> > >> >> > >> >> > >> >> > >> >> > >> ProduceData > >> >> > >> >> > >> >> ... the address of the remote webservice was previously added to the > >> >> header in the starting route ... > >> >> > >> >> > >> >> ... I needed to set the parallelProcessing to true, if not everything > >> >> fails because the Timer Route tries to start another recipientList > ... > >> >> > >> >> parallelProcessing="true"> > >> >> > >> > cxf:bean:productionServer?address=${header.address} > >> >> > >> >> > >> >> ... some more calls checking data, errorhandling and so forth .... > >> >> > >> >> > >> >> Now the following happened to me when I had more than one Remote Host > >> >> available: > >> >> > >> >> Calls to Host A did run on Host B > >> >> Results expecting to be retrieved from Host A where polled from Host > B. > >> >> Now I wonder if the calls to certain Methods are cached or if the > >> >> "re-running" timmer route does > >> >> interfere somehow with the already running route. > >> >> > >> >> A Complete run of a route can take up to about 30 Minutes after that > >> >> the "Production"-Route is done. > >> >> Since there are multiple hosts available we want to do parallel > >> processing. > >> >> > >> >> Any hints are welcome, > >> >> > >> >> Achim > >> >> > >> >> > >> >> -- > >> >> -- > >> >> *Achim Nierbeck* > >> >> > >> >> > >> >> Apache Karaf Committer & PMC > >> >> OPS4J Pax Web > >> >> Committer & Project Lead > >> >> blog > >> >> > >> > > >> > > >> > > >> > -- > >> > -- > >> > *Achim Nierbeck* > >> > > >> > > >> > Apache Karaf Committer & PMC > >> > OPS4J Pax Web > >> > Committer & Project Lead > >> > blog > >> > > >> > >> > >> > >> -- > >> -- > >> *Achim Nierbeck* > >> > >> > >> Apache Karaf Committer & PMC > >> OPS4J Pax Web > >> Committer & Project Lead > >> blog > >> > > > > > > > > -- > > Cheers, > > Jon > > --------------- > > FuseSource > > Email: jon@fusesource.com > > Web: fusesource.com > > Twitter: jon_anstey > > Blog: http://janstey.blogspot.com > > Author of Camel in Action: http://manning.com/ibsen > > > > > > -- > -- > *Achim Nierbeck* > > > Apache Karaf Committer & PMC > OPS4J Pax Web > Committer & Project Lead > blog > -- -- *Achim Nierbeck* Apache Karaf Committer & PMC OPS4J Pax Web Committer & Project Lead blog --20cf303ea6a4be557204aeb51ec3--