camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Quoc Le <>
Subject RE: Bi-directional comms on TCP connection
Date Wed, 15 Apr 2015 23:30:31 GMT
Hi Willem,

I look at the code and your unit test NettyConsumerClientModeTest but still don't quite follow
why clientMode can help with the case that Carl described. How can the consumer-server connects
to the "client-device" in the first place? Can you explain the magic there?


-----Original Message-----
From: Willem Jiang [] 
Sent: Wednesday, April 15, 2015 3:00 AM
Subject: Re: Bi-directional comms on TCP connection

We implement CAMEL-1077[1] in camel-2.15.x recently, so the ESB can talk to the device as
a client to receive the events. But now the miss part is how can we share the channel between
netty consumer and the netty producer. 


Willem Jiang

Red Hat, Inc.
Blog: (English) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem

On April 14, 2015 at 11:33:13 PM, Carl Nygard ( wrote:
> I have a question about the Mina/Netty TCP connector in Camel. Can 
> Mina/Netty handle bi-directional comms through Camel, or do we need to 
> handle this type of interface externally? We have embedded devices 
> (button/light combo) that will consume TCP messages to light a device 
> and initiate messages to indicate button press events. In other words, 
> the device is the server, but will also spontaneously generate event 
> messages back to the client/ESB. Both sides (server/device,client/ESB) 
> expect ACKs for messages. So in essence, it is a 2-way communication 
> using 1 TCP connection, initiated by ESB.
> Unfortunately, Camel Netty and Mina doesn’t have the capability to 
> support 2-way asynchronous 
> ( - It’s still open 
> ticket rom 2010, 2012 + this is the duplicated ticket with some more 
> context: )
> What we have tried so far:
> 1. synchronous channel (before realize the limitation above): This 
> will always require our ESB-EndPoint to initiate the conversation, 
> good to receive ACK, but not allowing device to send Event message at will.
> 2. asynchronous channel: ( ) With 
> async model, we can send request, do something else and let the async 
> callback to process the reply. However, we still have a 1-1 
> relationship between request and reply, and so in order to allow 
> device to “initiate” the Event message, ESB-Endpoint will need to send 
> more “no-op requests” to device-Endpoint, to catch for ACK and Event message.
> This solution is not beautiful (quite hacking), and will not work if 
> there’s no “no-op operation” (e.g. device will ACK on all messages sent).
> 3. Look at examples in these 2 books: “Camel in Actions” ( 
> ) 
> and “Apache Camel Developer’s Cookbook” ( 
> %20Cookbook.pdf
> )
> but not much light on the issue we are facing.
> Any help?
> --carl

View raw message