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!
