Re: recipientList inside SEDA route with CXF
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
> 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
>> >
>>
>> 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-4503for
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
> >:
>
>> 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=**3" />
>
>>
>>> ... 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
>>>
>>>
Re: recipientList inside SEDA route with CXF
Hi Willem,
I just was able to test this today, and it looks ok so far, but I wasn't
able to test "multiple" hosts yet :)
Will give feedback if that succeeds, so this looks also as
a promising solution.
Never the less I think the behavior I experienced seems to be a bug in the
endpoint cache.
Thanx for you help, Achim
2011/10/10 Willem Jiang
> 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
>> >
>>
>> 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-4503for
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
> >:
>
>> 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=**3" />
>
>>
>>> ... do preparation
>>> ... also set the address of the remote host into the header of the
>>>
>> exchange ...
>
>> ... call the "production" route ...
>>>
>>>>>
>> uri="seda:production"
>>>
/>
>
Re: recipientList inside SEDA route with CXF
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
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<
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:
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=3" />
... 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 Nierb
Re: recipientList inside SEDA route with CXF
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 <
> 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 :
> >> > 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=3" />
> >> >>
> >> >> ... 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
Re: recipientList inside SEDA route with CXF
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
> 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=3" />
>> >>
>> >> ... do preparation
>> >> ... also set the address of the remote host into the header of the
>> exchange ...
>> >> ... call the "production" route ...
>> >>
>> >> > />
>> >>
>> >>
>> >> 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 ...
>> >>
>> >>
>> >>
>> 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
Re: recipientList inside SEDA route with CXF
Hi,
You can set the request context on the message to workaround this issue.
Here is an example from camel-cxf unit test[1] that you can take a look.
[1]https://svn.apache.org/repos/asf/camel/trunk/components/camel-cxf/src/test/java/org/apache/camel/component/cxf/CxfProducerContextTest.java
On 9/29/11 10:16 PM, Achim Nierbeck 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.
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:
... do preparation
... also set the address of the remote host into the header of the exchange ...
... call the "production" route ...
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 ...
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
Re: recipientList inside SEDA route with CXF
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 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=3" />
> >>
> >> ... do preparation
> >> ... also set the address of the remote host into the header of the
> exchange ...
> >> ... call the "production" route ...
> >>
> >> />
> >>
> >>
> >> 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 ...
> >>
> >>
> >>
>
> 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
Re: recipientList inside SEDA route with CXF
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=3" />
>>
>> ... do preparation
>> ... also set the address of the remote host into the header of the exchange
>> ...
>> ... call the "production" route ...
>>
>>
>>
>>
>> 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 ...
>>
>>
>>
>> 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
Re: recipientList inside SEDA route with CXF
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=3" />
>
> ... do preparation
> ... also set the address of the remote host into the header of the exchange
> ...
> ... call the "production" route ...
>
>
>
>
> 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 ...
>
>
>
> 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
recipientList inside SEDA route with CXF
Hi
using Camel 2.8.0 I'm having the following scenario.
I'm using the CXF for connecting to a couple .NET Webservices.
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:
... do preparation
... also set the address of the remote host into the header of the exchange ...
... call the "production" route ...
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 ...
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
