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<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&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/>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
