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?


On Tue, Oct 18, 2016 at 4:44 PM, Claus Ibsen <> 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 <> 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
> -----------------
> @davsclaus
> Camel in Action 2:

Reply via email to