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 <bcanh...@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 <bcanh...@googlemail.com>: > > 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 <bcanh...@googlemail.com>: > >> Hi > >> > >> using Camel 2.8.0 I'm having the following scenario. > >> I'm using the CXF for connecting to a couple .NET Webservices. > >> > >> <!-- CXF config --> > >> <cxf:cxfEndpoint id="productionServer" > >> > 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";> > >> <cxf:properties> > >> <entry key="dataFormat" value="POJO" /> > >> </cxf:properties> > >> <cxf:outInterceptors> > >> <ref bean="loggingOutInterceptor" /> > >> </cxf:outInterceptors> > >> </cxf:cxfEndpoint> > >> > >> > >> Now I have a route for looking up some data in the DB for example also > >> looking for a free > >> WebService to call: > >> > >> <camel:route id="pollQueue"> > >> <camel:from > 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 ... > >> > >> <camel:to uri="seda:production" > /> > >> </camel:route> > >> > >> the production route does call the Webservice on the available remote > >> host as follows > >> > >> ... again a couple of preparations beforehand .... > >> > >> <!-- Altering Body to contain no data --> > >> <camel:setBody> > >> <camel:mvel>[ ]</camel:mvel> > >> </camel:setBody> > >> > >> <!-- service call --> > >> <camel:setHeader headerName="operationName"> > >> > <camel:constant>ProduceData</camel:constant> > >> </camel:setHeader> > >> > >> ... 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 ... > >> > >> <camel:recipientList parallelProcessing="true"> > >> > > <camel:simple>cxf:bean:productionServer?address=${header.address}</camel:simple> > >> </camel:recipientList> > >> > >> ... 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 <http://karaf.apache.org/> Committer & PMC > >> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> > >> Committer & Project Lead > >> blog <http://notizblog.nierbeck.de/> > >> > > > > > > > > -- > > -- > > *Achim Nierbeck* > > > > > > Apache Karaf <http://karaf.apache.org/> Committer & PMC > > OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> > > Committer & Project Lead > > blog <http://notizblog.nierbeck.de/> > > > > > > -- > -- > *Achim Nierbeck* > > > Apache Karaf <http://karaf.apache.org/> Committer & PMC > OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> > Committer & Project Lead > blog <http://notizblog.nierbeck.de/> > -- Cheers, Jon --------------- FuseSource Email: j...@fusesource.com Web: fusesource.com Twitter: jon_anstey Blog: http://janstey.blogspot.com Author of Camel in Action: http://manning.com/ibsen
