Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
Sender: jcarman@carmanconsulting.com
In-Reply-To: <E7FCCE26-DE32-40B3-915B-3B68607FEE20@gmail.com>
References: 
 <CALznzY7D_tDNzDTOHgqJzNK9Fyp75hNW23yZREUOkk+yguF32g@mail.gmail.com>
 <2338A988-ACD0-493A-A68F-CA1BB772A6D2@gmail.com>
 <CALznzY5Wp5W7ieRoqeSmR_gG8y5pu==JexbgapACv7PqYP_wFQ@mail.gmail.com>
 <4E3F35F0.3080108@gmail.com>
 <CALznzY7oC4m7w9xG9kRWuUcsQ6oSNVppY6zH-DraASeSiqyifg@mail.gmail.com>
 <E7FCCE26-DE32-40B3-915B-3B68607FEE20@gmail.com>
From: James Carman <james@carmanconsulting.com>
Date: Tue, 16 Aug 2011 15:30:09 -0400
Message-ID: 
 <CALznzY6K7r2u2k+CAO7aD5iHn0_NQvUXUNEruvFvXLyJXsYaVg@mail.gmail.com>
Subject: Re: Socket-based Asynchronous Calls...
To: users@camel.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Care to share an example?  I'm not picturing it.

On Tue, Aug 16, 2011 at 3:23 PM, Taariq Levack <taariql@gmail.com> wrote:
> Hi James
>
> I did that too for what it's worth.
> I send the message to a route that forwards to both the aggregator and to=
 the socket.
> When the response comes in I use an enricher to add the ID to the headers=
 and then forward to the aggregator.
>
> Taariq
>
> On 16 Aug 2011, at 8:55 PM, James Carman <james@carmanconsulting.com> wro=
te:
>
>> Willem,
>>
>> Thank you for your help. =A0I don't think this is doing exactly what I
>> need, though. =A0The real trick here is the asynchronous nature of the
>> "server" on the other end of this situation. =A0I thought about using an
>> aggregator to make sure the response gets matched up with the request
>> using a correlation id. =A0The aggregator wouldn't aggregate multiple
>> responses together into one, it would just make sure it matches the
>> correct response with its request. =A0Does this sound like a valid
>> approach? =A0If so, how the heck do I go about it? :)
>>
>> Thanks,
>>
>> James
>>
>> On Sun, Aug 7, 2011 at 9:03 PM, Willem Jiang <willem.jiang@gmail.com> wr=
ote:
>>> 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/ma=
in/java/org/apache/camel/component/cxf/CxfConsumer.java?view=3Dmarkup
>>> [2]http://svn.apache.org/viewvc/camel/trunk/components/camel-cxf/src/ma=
in/java/org/apache/camel/component/cxf/CxfProducer.java?view=3Dmarkup
>>>
>>> On 8/7/11 1:29 AM, James Carman wrote:
>>>>
>>>> On Sat, Aug 6, 2011 at 10:33 AM, Zbarcea Hadrian<hzbarcea@gmail.com>
>>>> =A0wrote:
>>>>>
>>>>> 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 conve=
rting a
>>>>> 2x in-only to a 1x in-out async mep. You should then treat your excha=
nge as
>>>>> an async in-out and let your framework (Camel) decompose it and compo=
se it
>>>>> back again. I would not keep threads blocked so I believe your best b=
et 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 somethin=
g 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 repl=
yTo
>>>>> queue.
>>>>>
>>>>> from("jms:request-queue").to("netty:output?=3DcorrelationId");
>>>>> from("netty:input).to("jms:replyTo-queue")
>>>>>
>>>>
>>>> Perhaps a bit more information might be appropriate here. =A0Eventuall=
y,
>>>> I'd like to "expose" this route via web services (using CXF of
>>>> course). =A0So, I would need to either block the request thread, waiti=
ng
>>>> 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. =A0The "protocol" requires one and t=
he
>>>> server process just echos it back in the response message.
>>>>
>>>>> You may have to play a bit with the correlationId and if you cannot u=
se
>>>>> 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. =A0I don't want to guarantee
>>>> the ordering. =A0I'm mostly interested in throughput here. =A0So, 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, b=
ut I
>>>>> hope this helps.
>>>>> Hadrian
>>>>>
>>>>
>>>> You have been very helpful. =A0Thank you for taking the time!
>>>>
>>>
>>>
>>> --
>>> Willem
>>> ----------------------------------
>>> FuseSource
>>> Web: http://www.fusesource.com
>>> Blog: =A0 =A0http://willemjiang.blogspot.com (English)
>>> =A0 =A0 =A0 =A0 http://jnn.javaeye.com (Chinese)
>>> Twitter: willemjiang
>>> Weibo: willemjiang
>>>
>