On 10/02/2013 11:18 PM, Dmitry Samersoff wrote:
Chris,
I'm not sure immediate native retry make sence here because tipically
EAGAIN of getaddrinfo caused by network failure, like unreachable
nameserver. (see my previous letter)
OK, while not ideal ( please don't shoot! ) what do others think of
Thread.yield() before retry. It is an attempt to allow other threads on
the system do some work before us, therefore potentially swapping out
our failed lookup thread until rescheduled. I'm just trying to avoid
baking in a hardcoded sleep/wait value ( since we don't know what that
should be ).
The use of Thread.yield(), if acceptable, would of course most likely
make sense to push the retry logic back up into the Java level.
-Chris.
-Dmitry
On 2013-10-02 23:53, Chris Hegarty wrote:
On 10/02/2013 08:40 PM, Brian Burkhalter wrote:
....
So, how about this approach:
1) If the error is EAI_AGAIN / EIA_SYSTEM+EAGAIN / WSATRY_AGAIN then
do one immediate native retry.
2) If the retry fails with the same error, then throw a UHE with a
specific message or cause.
Sounds good to me.
Questions:
A) Would it be better to do the retry in the Java layer, perhaps with
a very short wait?
native, without any wait, should be sufficient.
B) Should the message or cause in #2 be explicitly document in the
javadoc?
I don't think it is necessary for this to be documented. It is more
informational.
-Chris.
