Hi Willem,
some minor tests passed today so it looks quite good. I'm probably ready for
a "full" test tomorrow.
But right now this looks really promising.
Regards, Achim
2011/10/10 Willem Jiang <willem.ji...@gmail.com>
> Hi Achim,
>
> Did you have a chance to try to set the request context header of address ?
> You can override the endpoint address by using it.
>
>
> On Fri Oct 7 21:07:14 2011, Achim Nierbeck wrote:
>
>> 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<bcanhome@googlemail.**com<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<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<bcanhome@googlemail.**com<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<bcanhome@googlemail.**com<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<http://schemas.microsoft.com/2003/10/Serialization/Arrays>
>>>>> "
>>>>>
>>>>>>
>>>>>> xmlns:i="http://www.w3.org/**2001/XMLSchema-instance<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/<http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>>>>> >
>>>>>>> Committer& Project Lead
>>>>>>> blog<http://notizblog.**nierbeck.de/ <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/<http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>>>> >
>>>>>> Committer& Project Lead
>>>>>> blog<http://notizblog.**nierbeck.de/ <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/<http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>>> >
>>>>> Committer& Project Lead
>>>>> blog<http://notizblog.**nierbeck.de/ <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/<http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>> >
>>> Committer& Project Lead
>>> blog<http://notizblog.**nierbeck.de/ <http://notizblog.nierbeck.de/>>
>>>
>>>
>>
>>
>>
>
> --
> Willem
> ------------------------------**----
> FuseSource
> Web: http://www.fusesource.com
> Blog:
> http://willemjiang.blogspot.**com<http://willemjiang.blogspot.com>(English)
> http://jnn.javaeye.com (Chinese)
> Twitter: willemjiang
> Weibo: willemjiang
>
--
--
*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/>
