camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Willem Jiang <willem.ji...@gmail.com>
Subject Re: recipientList inside SEDA route with CXF
Date Mon, 10 Oct 2011 09:47:56 GMT
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>
>
>> 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<janstey@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<
>> 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<bcanhome@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>:
>>>>>> 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: 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<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/>
>>
>
>
>


-- 
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog:    http://willemjiang.blogspot.com (English)
          http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang

Mime
View raw message