JDK-8010371 : getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 6,7,8
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: generic
  • Submitted: 2013-03-20
  • Updated: 2016-09-13
  • Resolved: 2013-10-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8
7u80Fixed 8 b113Fixed
Related Reports
Relates :  
JDK-8026806 - Incomplete test of getaddrinfo() return value could lead to incorrect exception for Windows Inet 6
Description
SYNOPSIS
--------
Improve Java's handling of EAGAIN with respect to DNS lookups

OPERATING SYSTEM
----------------
Observed on Linux, but probably applicable to all platforms

FULL JDK VERSION
----------------
All

DESCRIPTION
-----------
Occasionally, the system call getaddrinfo() fails with a return value EAI_SYSTEM and errno set to EAGAIN, meaning that the resource is temporarily unavailable. Under these circumstances Java throws an UnknownHostException, which can cause confusion for application users. We believe that Java's handing of this error needs to be improved.

We experimented with a standalone C program and found that the failure is highly transient - calling getaddrinfo() again after 50ms almost always succeeds.

The JRE's handling of this scenario could therefore be improved. Here are two suggestions:

1. Implement a retry when confronted with an EAGAIN error from the
   system call.

OR

2. Redesign the Java API to distinguish between true lookup failures and
   EAGAIN failures, via the introduction of a new Exception class, to
   allow applications to handle the different error scenarios.

WORKAROUND
----------
The application could catch all UnknownHostExceptions and retry just in case the error was an EAGAIN, but this is obviously far from ideal.
Comments
No issues related to the InetAddress related fixes in the latest nightly. SQE OK to take all 5 fixes to CPU15_02: JDK-8071499, JDK-8027961, JDK-7180557, JDK-8010371, JDK-8026245
26-01-2015
7u80-critical-request-justification: 7180557 dependency - see that bug for full justification
20-01-2015
Link to review thread is here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-October/thread.htm
17-10-2013
Restoring fields, we do not re-open bugs.
17-10-2013
Problem with the original fix was reported here http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-October/022215.html so reopening.
16-10-2013
It would be useful if the original submitter could tell us a bit more about the environment. I ask because the submitter says the platform is "Linux" and we already handle it when IPv6 is enabled. If the submitter is running on Linux with IPv6 disabled then it would explain the bug report, or if the submitter is really on Windows.
14-10-2013
It could be quite difficult to identify all of the possible transient conditions that could occur (across all platforms) and actually handle them internally with suitable retry logic. There are some references to EAGAIN errors requiring higher level service restart before the problem goes away also. It seems to me the optimum solution could be to sub-class UnknownHostException to distinguish this error code (ie option 2 above)
10-09-2013