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 <bcanh...@googlemail.com>

> The suggested workaround by Jon really does the trick.
>
> instead of using the recipientlist inside the spring route:
>
>                        <camel:recipientList parallelProcessing="true">
>
>
> <camel:simple>cxf:bean:productionServer?address=${header.address}</camel:simple>
>                        </camel:recipientList>
>
> 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 <jans...@gmail.com>:
> > 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&amp;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
> >
>
>
>
> --
> --
> *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/>

Reply via email to