RE: Bi-directional comms on TCP connection
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.ji...@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 (cjnyg...@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
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 (quo...@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.ji...@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 (cjnyg...@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
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 (cjnyg...@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
