You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Carl Nygard <cj...@gmail.com> on 2015/04/14 17:32:45 UTC
Bi-directional comms on TCP connection
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 (https://issues.apache.org/jira/browse/CAMEL-2624 - It’s
still open ticket rom 2010, 2012 + this is the duplicated ticket with some
more context: https://issues.apache.org/jira/browse/CAMEL-1075 )
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: (http://camel.apache.org/async.html ) 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” (
https://dl.dropboxusercontent.com/u/3786274/Camel%20In%20Action.pdf ) and
“Apache Camel Developer’s Cookbook” (
https://dl.dropboxusercontent.com/u/3786274/Apache%20Camel%20Developer%20Cookbook.pdf
)
but not much light on the issue we are facing.
Any help?
--carl
RE: Bi-directional comms on TCP connection
Posted by Willem Jiang <wi...@gmail.com>.
First the Netty or Mina Consumer works in clientMode just connect the address of the device as a client when the route is started, then it can keep receiving the event from the device.
If the consumer doesn’t work in clientMode, it just start a server which listen to address and wait for the client to connect.
--
Willem Jiang
Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.iteye.com (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On April 16, 2015 at 7:30:45 AM, Quoc Le (quocle@fortna.com) wrote:
> 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?
>
> Thanks,
> -Quoc
>
>
>
> -----Original Message-----
> From: Willem Jiang [mailto:willem.jiang@gmail.com]
> Sent: Wednesday, April 15, 2015 3:00 AM
> To: users@camel.apache.org
> 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.
>
> [1]https://issues.apache.org/jira/browse/CAMEL-1077
>
> --
> Willem Jiang
>
> Red Hat, Inc.
> Web: http://www.redhat.com
> Blog: http://willemjiang.blogspot.com (English) http://jnn.iteye.com (Chinese)
> Twitter: willemjiang
> Weibo: 姜宁willem
>
>
>
> On April 14, 2015 at 11:33:13 PM, Carl Nygard (cjnygard@gmail.com) 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
> > (https://issues.apache.org/jira/browse/CAMEL-2624 - It’s still open
> > ticket rom 2010, 2012 + this is the duplicated ticket with some more
> > context: https://issues.apache.org/jira/browse/CAMEL-1075 )
> >
> >
> >
> > 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: (http://camel.apache.org/async.html ) 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” (
> > https://dl.dropboxusercontent.com/u/3786274/Camel%20In%20Action.pdf )
> > and “Apache Camel Developer’s Cookbook” (
> > https://dl.dropboxusercontent.com/u/3786274/Apache%20Camel%20Developer
> > %20Cookbook.pdf
> > )
> > but not much light on the issue we are facing.
> >
> >
> > Any help?
> >
> >
> > --carl
> >
>
>
RE: Bi-directional comms on TCP connection
Posted by Quoc Le <qu...@fortna.com>.
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?
Thanks,
-Quoc
-----Original Message-----
From: Willem Jiang [mailto:willem.jiang@gmail.com]
Sent: Wednesday, April 15, 2015 3:00 AM
To: users@camel.apache.org
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.
[1]https://issues.apache.org/jira/browse/CAMEL-1077
--
Willem Jiang
Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (English) http://jnn.iteye.com (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On April 14, 2015 at 11:33:13 PM, Carl Nygard (cjnygard@gmail.com) 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
> (https://issues.apache.org/jira/browse/CAMEL-2624 - It’s still open
> ticket rom 2010, 2012 + this is the duplicated ticket with some more
> context: https://issues.apache.org/jira/browse/CAMEL-1075 )
>
>
>
> 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: (http://camel.apache.org/async.html ) 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” (
> https://dl.dropboxusercontent.com/u/3786274/Camel%20In%20Action.pdf )
> and “Apache Camel Developer’s Cookbook” (
> https://dl.dropboxusercontent.com/u/3786274/Apache%20Camel%20Developer
> %20Cookbook.pdf
> )
> but not much light on the issue we are facing.
>
>
> Any help?
>
>
> --carl
>
Re: Bi-directional comms on TCP connection
Posted by Willem Jiang <wi...@gmail.com>.
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.
[1]https://issues.apache.org/jira/browse/CAMEL-1077
--
Willem Jiang
Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.iteye.com (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On April 14, 2015 at 11:33:13 PM, Carl Nygard (cjnygard@gmail.com) 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 (https://issues.apache.org/jira/browse/CAMEL-2624 - It’s
> still open ticket rom 2010, 2012 + this is the duplicated ticket with some
> more context: https://issues.apache.org/jira/browse/CAMEL-1075 )
>
>
>
> 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: (http://camel.apache.org/async.html ) 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” (
> https://dl.dropboxusercontent.com/u/3786274/Camel%20In%20Action.pdf ) and
> “Apache Camel Developer’s Cookbook” (
> https://dl.dropboxusercontent.com/u/3786274/Apache%20Camel%20Developer%20Cookbook.pdf
> )
> but not much light on the issue we are facing.
>
>
> Any help?
>
>
> --carl
>