willem.jiang wrote:
>
> Yes ,the multicast do not as you want.
> Here is the MulticastProcessor's process code.
>
Yes, I had figured that out. I tried different combinations of route to get
this to work without any luck. Chirnio's suggestion to use the following
also did not work.
from("cxf:bean:soapMessageEndpoint").process(myProc).thread(5).to("direct:a");
from("direct:a").aggregator(header("txid"),
aggregationStratergy).to("bean:testBean?methodName=processSOAP") ;
The aggregator's cosumer is EventDrivenPollingConsumer and causes the route
to return immediately, as it just transfers the message to the queue which
aggregator is listening to. So basically not much of use in CXF two way MEP
case.
willem.jiang wrote:
>
> Maybe we could define a new ParallelizedMulticastProcessor for calling
> the to endpoint in different thread, and a barrier class could help us
> to get the calling threads aggregated.
>
I was thinking on the same lines. But wanted to make sure that I was not
missing anything already present that I was not aware of. May be I should
get working on this, I think this would also need new DSL methods or
probably an argument to multicast() to indicate that Parallelism is
intended.
willem.jiang wrote:
>
> BTW, you can find ThreadProcessor for Thread syntax implementation.
>
Went through this also many times. We could make MultiCast, if set in
parallel processing mode, invoke the processors asynchronously (using
process(Exchange, callback)) and blocking until all the callbacks from all
the parallel routes are received. This would be a pretty simple change I
guess.
What do you think of this approach?
Aswin
--
View this message in context:
http://www.nabble.com/Parallel-processing-route-tp15642110s22882p16055798.html
Sent from the Camel - Users mailing list archive at Nabble.com.
