JDK-6774170 : LocalRMIServerSocketFactory should protect against ServerSocket.accept().getInetAddress() being null
  • Type: Bug
  • Component: core-svc
  • Sub-Component: java.lang.management
  • Affected Version: 6u12
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris
  • CPU: x86
  • Submitted: 2008-11-20
  • Updated: 2010-07-29
  • Resolved: 2008-12-04
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 6 JDK 7 Other
6u12 b02Fixed 7Fixed OpenJDK6Fixed
Related Reports
Relates :  
Description
Using Netbeans 6.5rc2 for Java EE, with GlassFish ur2v2, in which petstore is deployed.
While pointing jvisualvm to the local GlassFish process (local attach) - I could sometimes see an exception in GlassFish log file.
When running glassfish on 6u12 - I could see an NullPointerException in the glassfish log file - and  jvisualvm was not able to display GlassFish threads (thread information are obtained through JMX)
The problem occurs intermitently, and prevents jvisualvm to connect to the target application server using the attach API.

The root cause of the problem seems to be that sometime, for some reason, 
the Socket created on the server (glassfish) side to handle incomminng
JMX RMI connections has a null remote InetAddress:

RMI TCP Accept-0: accept loop for ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=53246] throws
java.lang.NullPointerException
        at sun.management.jmxremote.LocalRMIServerSocketFactory$1.accept(LocalRMIServerSocketFactory.java:40)
        at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:369)
        at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:341)
        at java.lang.Thread.run(Thread.java:619)

In the LocalRMIServerSocketFactory the remoteAddr variable returned by the forelast
line in the code snippet below is null:

    public ServerSocket createServerSocket(int port)
       throws IOException {
        return new ServerSocket(port) {
            @Override
            public Socket accept() throws IOException {
                Socket socket = super.accept();
                InetAddress remoteAddr = socket.getInetAddress();
                if (remoteAddr.isAnyLocalAddress()) {

This problem occurred several times - but not always. If you restart the glassfish appserver it may go away - or remain. 
It looks as if the socket returned by accept() is not always fully initialized?

Note: the code of the LocalRMIServerSocketFactory changed between 6u11 and 6u12.
On 6u11 you get an IOException instead - saying that the remoteAddr is not a local address. It is difficult to assert that this happens because the remoteAddr is null, but I suspect as much,  so this problem (ServerSocket.accept().getInetAddress()=null) 
is probably older.

LocalRMIServerSocketFactory should give a better diagnostic and throw an IOException when this happens, rather than a NullPointerException. 
There's still the (unlikely) possibilty that the just accepted socket has already 
been closed - and in that case the exception should probably say so. Also LocalRMIServerSocketFactory should call isLoopbackAddress() rather than isAnyLocalAddress().

Comments
EVALUATION The NullPointerException is caused by 6774166. 6774166 is a spurious bug that only shows up from time to time. However, throwing NPE is bad, because it delays the time at which the accepted socket is closed by the server (the accepted socket is closed when it is eventually gc'ed). During all this time, the client waits for the server to respond - and may also retry the connection. Working around 6774166 and cleanly closing the accepted socket right away when getInetAddress() returns null is much better for client performance.
20-11-2008