Which combination of EIPs for this scenario?

[Taariq Levack <ta...@gmail.com>]

Hi

I'm doing some socket integration, there's an agreed handshake etc,
then both parties can send and receive on 2 different ports.
I have to keep track of the outbound messages so I can retry if I
don't receive a response within
the timeout limit.

Now of course I can't use normal Camel retry DSL, because we send to
the socket and receive on another port.
So what I've started with, which isn't working really well hence the
post, is a multicast to both the socket and an
aggregator.
The aggregator will maybe timeout and then send a message right back
to the route that does the
multicast to both socket and aggregator.
In happy days it will correlate the socket's response and then be able
to send this new exchange to another endpoint.

Any better ideas while I panelbeat that some more, because I think it
should work, it's simulating some async delays and whatnot in the test
setup that I think is responsibly for me going a little bit grey here,
but anyway.

Thanks,
Taariq

Re: Which combination of EIPs for this scenario?

[Taariq Levack <ta...@gmail.com>]

Sorry I wasn't clearer, and it's properly sorted out with the Aggregator.
I was just struggling to simulate the scenario in my test case so
started considering other implementations but the code itself was
working great afterall.

Thanks anyway, appreciated.

On Mon, Jul 25, 2011 at 9:37 AM, Willem Jiang <wi...@gmail.com> wrote:
> Hi,
>
> I don't know if you implement a new component for your socket integration
> instead of use the netty or mina component directly.
>
> For the Camel producer, you can implement AsyncProcessor and let the
> callback.done be called when your producer got the response.
>
> I think you should let the camel route do retry control instead of implement
> it in your component.
>
> Willem
>
> On 7/22/11 2:36 PM, Taariq Levack wrote:
>>
>> Hi
>>
>> I'm doing some socket integration, there's an agreed handshake etc,
>> then both parties can send and receive on 2 different ports.
>> I have to keep track of the outbound messages so I can retry if I
>> don't receive a response within
>> the timeout limit.
>>
>> Now of course I can't use normal Camel retry DSL, because we send to
>> the socket and receive on another port.
>> So what I've started with, which isn't working really well hence the
>> post, is a multicast to both the socket and an
>> aggregator.
>> The aggregator will maybe timeout and then send a message right back
>> to the route that does the
>> multicast to both socket and aggregator.
>> In happy days it will correlate the socket's response and then be able
>> to send this new exchange to another endpoint.
>>
>> Any better ideas while I panelbeat that some more, because I think it
>> should work, it's simulating some async delays and whatnot in the test
>> setup that I think is responsibly for me going a little bit grey here,
>> but anyway.
>>
>> Thanks,
>> Taariq
>>
>
>
> --
> Willem
> ----------------------------------
> FuseSource
> Web: http://www.fusesource.com
> Blog:    http://willemjiang.blogspot.com (English)
>         http://jnn.javaeye.com (Chinese)
> Twitter: willemjiang
> Weibo: willemjiang
>

Re: Which combination of EIPs for this scenario?

[Willem Jiang <wi...@gmail.com>]

Hi,

I don't know if you implement a new component for your socket 
integration instead of use the netty or mina component directly.

For the Camel producer, you can implement AsyncProcessor and let the 
callback.done be called when your producer got the response.

I think you should let the camel route do retry control instead of 
implement it in your component.

Willem

On 7/22/11 2:36 PM, Taariq Levack wrote:
> Hi
>
> I'm doing some socket integration, there's an agreed handshake etc,
> then both parties can send and receive on 2 different ports.
> I have to keep track of the outbound messages so I can retry if I
> don't receive a response within
> the timeout limit.
>
> Now of course I can't use normal Camel retry DSL, because we send to
> the socket and receive on another port.
> So what I've started with, which isn't working really well hence the
> post, is a multicast to both the socket and an
> aggregator.
> The aggregator will maybe timeout and then send a message right back
> to the route that does the
> multicast to both socket and aggregator.
> In happy days it will correlate the socket's response and then be able
> to send this new exchange to another endpoint.
>
> Any better ideas while I panelbeat that some more, because I think it
> should work, it's simulating some async delays and whatnot in the test
> setup that I think is responsibly for me going a little bit grey here,
> but anyway.
>
> Thanks,
> Taariq
>


-- 
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog:    http://willemjiang.blogspot.com (English)
          http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang