Thanks Dmitry,
I think we have agreement that the cause of the UHE should contain an
Exception containing the gai_strerror string message. I can live without
adding retry logic.
-Chris.
On 10/03/2013 10:44 AM, Dmitry Samersoff wrote:
Chris,
On my opinion, it's better to just return meaningful exception to
customer and let them deal with network issue (as current webrev does).
Typical network failure requires at least couple of milliseconds to
recover so immediate retry most probably fails with the same error.
From the other side - cu has lots of possibility to defend against such
failures on application level. E.g. popup a message box "please check
your wiring and try again"
In a future,
it might be possible to add a timeout parameter to corresponding
Java-level functions and keep trying on Java level until we get result
or timeout, but it requires much more work and probably out of scope of
this CR.
-Dmitry
On 2013-10-03 13:11, Chris Hegarty wrote:
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.
