Hi James,
Camel async process engine already provides the way that you want.
You can take a look at the camel-cxf code[1][2] for some example.
[1]http://svn.apache.org/viewvc/camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfConsumer.java?view=markup
[2]http://svn.apache.org/viewvc/camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfProducer.java?view=markup
On 8/7/11 1:29 AM, James Carman wrote:
On Sat, Aug 6, 2011 at 10:33 AM, Zbarcea Hadrian<hzbar...@gmail.com> wrote:
Hi James,
I hope I understand your scenario correctly. Here are a few thoughts. I assume
want to use camel-netty [1] to send messages to your sever (if you have your
own code that does that, you can use it too, but you'd have to write your own
Processor or Component). Iiuic, your scenario is converting a 2x in-only to a
1x in-out async mep. You should then treat your exchange as an async in-out and
let your framework (Camel) decompose it and compose it back again. I would not
keep threads blocked so I believe your best bet is using the Camel async
messaging [2] and Futures (look at the examples using asyncSend* and
asyncCallback*). The issue is that Camel is stateless so you'll need a
correlationId, which you must have already and something to keep your state. A
good bet would be jms [3], or you could write your own. If you used jms you
would need to use both a correlationId and a replyTo queue.
from("jms:request-queue").to("netty:output?=correlationId");
from("netty:input).to("jms:replyTo-queue")
Perhaps a bit more information might be appropriate here. Eventually,
I'd like to "expose" this route via web services (using CXF of
course). So, I would need to either block the request thread, waiting
for a reply or perhaps check out the new Servlet 3.0 asynchronous
processing stuff (I'm thinking this might help us get more done with
less http request threads) to do more of a continuation thing.
We already have a correlation id. The "protocol" requires one and the
server process just echos it back in the response message.
You may have to play a bit with the correlationId and if you cannot use the
same you can do a second transformation/correlation using a claim-check sort of
pattern. If you don't want to use jms you can implement your own (in memory)
persistence and correlation. You can also use a resequencer [4] if you want to
enforce the order. If you use asyncCallback, you get the replies when they
become available, and you can control that.
I don't think a resequencer is necessary. I don't want to guarantee
the ordering. I'm mostly interested in throughput here. So, if a
message comes in after another, but it can be processed faster, so be
it.
It's an interesting scenario, I'll definitely give it more thought, but I hope
this helps.
Hadrian
You have been very helpful. Thank you for taking the time!
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
