JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown

[Chris Hegarty]

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.
>>>
>>>
>
>