Chris, On 2013-10-03 14:10, Chris Hegarty wrote: > 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.
I'm ok with that. -Dmitry > > -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. >>>> >>>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.
