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. >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the source code.
