Re: Camel Netty4 component tcp client reconnect limit

[Willem Jiang]

I just checked the code, camel just calls the openChannel method recursively 
until the connection is established when starting the NettyConsumer in client 
mode.
It could be good idea to fail fast by throwing the exception out after a couple 
of retries.


--  
Willem Jiang


Blog: http://willemjiang.blogspot.com (English)  
http://jnn.iteye.com (Chinese)
Twitter: willemjiang  
Weibo: 姜宁willem



On January 8, 2016 at 5:01:12 PM, Jojo Paderes (jojo.pade...@gmail.com) wrote:
> On Fri, Jan 8, 2016 at 4:50 PM, Claus Ibsen wrote:
>  
> >
> > I do not think so. But if there was such an option what should happen
> > after the exception? Should it just never try again? Or is the idea to
> > have an error being logged every 20th failed attempt or something?
> >
> >
> What I have in mind is that the tcp client will reconnect for a certain
> number of attempts (can be set as an option in the endpoint url), and if
> the connection still fails after x attempts an exception is thrown (which
> is then handled in Camel error handling).
>  

Re: Camel Netty4 component tcp client reconnect limit

[Claus Ibsen]

On Fri, Jan 8, 2016 at 9:43 AM, Jojo Paderes  wrote:
> I have an application that uses Camel Netty4 component as a consumer
> endpoint which is configured as a TCP client (clientMode set to true) with
> the reconnect option enabled. The reconnect feature works well, the TCP
> connection automatically reconnects to the remote server after a network
> outage. Unfortunately it seems that this reconnect behavior runs
> indefinitely until the connection is established. Is there some way to set
> a limit to this reconnect feature, i.e. put a limit on how many reconnect
> attempts can be made before throwing a connection error?
>

I do not think so. But if there was such an option what should happen
after the exception? Should it just never try again? Or is the idea to
have an error being logged every 20th failed attempt or something?


> Another question but this one is for the Netty4 component implemented as a
> producer that sends a payload to a remote server. Is there a way to
> configure the endpoint to enable the reconnect feature which would allow
> the TCP client to try establish a connection for a number of attempts
> before throwing a connection error?
>

Use the general Camel error handling

> Thanks in advance!



-- 
Claus Ibsen
-
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Camel Netty4 component tcp client reconnect limit

[Jojo Paderes]

I have an application that uses Camel Netty4 component as a consumer
endpoint which is configured as a TCP client (clientMode set to true) with
the reconnect option enabled. The reconnect feature works well, the TCP
connection automatically reconnects to the remote server after a network
outage. Unfortunately it seems that this reconnect behavior runs
indefinitely until the connection is established. Is there some way to set
a limit to this reconnect feature, i.e. put a limit on how many reconnect
attempts can be made before throwing a connection error?

Another question but this one is for the Netty4 component implemented as a
producer that sends a payload to a remote server. Is there a way to
configure the endpoint to enable the reconnect feature which would allow
the TCP client to try establish a connection for a number of attempts
before throwing a connection error?

Thanks in advance!

Re: Camel Netty4 component tcp client reconnect limit

[Jojo Paderes]

On Fri, Jan 8, 2016 at 4:50 PM, Claus Ibsen  wrote:

>
> I do not think so. But if there was such an option what should happen
> after the exception? Should it just never try again? Or is the idea to
> have an error being logged every 20th failed attempt or something?
>
>
What I have in mind is that the tcp client will reconnect for a certain
number of attempts (can be set as an option in the endpoint url), and if
the connection still fails after x attempts an exception is thrown (which
is then handled in Camel error handling).