curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: RetryLoop bug?
Date Fri, 13 Jun 2014 22:18:48 GMT
Though, I could see an argument against it.

-JZ


From: Jordan Zimmerman jordan@jordanzimmerman.com
Reply: Jordan Zimmerman jordan@jordanzimmerman.com
Date: June 13, 2014 at 9:07:26 AM
To: Cameron McKenzie mckenzie.cam@gmail.com, user@curator.apache.org user@curator.apache.org
Subject:  Re: RetryLoop bug?  

Retrying is correct. Failure to connect is in the class of recoverable exceptions so it’s
appropriate to retry based on the configured policy. 

-Jordan


From: Cameron McKenzie mckenzie.cam@gmail.com
Reply: user@curator.apache.org user@curator.apache.org
Date: June 12, 2014 at 11:27:22 PM
To: user@curator.apache.org user@curator.apache.org
Subject:  RetryLoop bug?

Guys,
I was poking through the RetryLoop code while looking at an unrelated bug and noticed that
before doing a retry it calls internalBlockUntilConnectedOrTimedOut(). This makes sense. There's
no point in doing a retry if you're not connected. The thing is that it doesn't really achieve
anything because the retry still occurs even if a connection is not established.

Is this intentional? Doesn't seem to make a lot of sense to me. It would make more sense to
call the blockUntilConnectedOrTimedOut() method, and if that returns false, then just treat
this as a failed retry.

Thoughts?
cheers
Cam



Mime
View raw message