Thanks, Claus. One Camel message mapping to one netty message is quite fine, but it needs to keep a persistent TCP connection for our purposes. We have to send something akin to a "hello" packet that lets the server at the TCP destination know what kind of data it will be receiving, and other "meta" information about the data. As long as the connection persists, the server will know what to do with the data. But, once the connection drops and, I assume, Camel transparently makes the connection again, the server won't know enough about the data that we are sending to it in order to know what to do with the data. We need to know that a connection has been dropped and re-established so that we can send our "hello" packet again, and then the server will know what to do with our data. Do I need a custom ChannelHandler to get notification about dropped connections? Or is there another approach that we should take?
Thanks, Steve On Tue, Oct 18, 2016 at 4:44 PM, Claus Ibsen <claus.ib...@gmail.com> wrote: > I think you would need to implement some custom codec or something to > deal with this kind of requirements. > > The out of the box behavior is to use netty for messaging like where > each Camel message maps to one netty message being sent over the wire. > > > > On Tue, Oct 18, 2016 at 7:29 PM, Steve973 <steve...@gmail.com> wrote: > > Hello. Our Camel route is sending messages to a netty4 tcp endpoint, but > > we need to make sure to send a particular type of message as the first > > message. If a disconnection happens during processing, we have to send > > this special message upon reconnection. Is this possible to achieve? > Will > > we need to write a custom handler for netty to do this? Any suggestions > > are quite welcome! > > > > Thanks, > > Steve > > > > -- > Claus Ibsen > ----------------- > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 >
