commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Bories-Azeau (JIRA)" <>
Subject [jira] [Created] (NET-596) NullPointerException when disconnecting TelnetClient twice with JDK 7
Date Tue, 05 Jul 2016 13:56:10 GMT
Vincent Bories-Azeau created NET-596:

             Summary: NullPointerException when disconnecting TelnetClient twice with JDK
                 Key: NET-596
             Project: Commons Net
          Issue Type: Bug
          Components: Telnet
    Affects Versions: 3.5
         Environment: Both telnet client & server with JDK 7.
Bug not reproduced with JDK 8 (there's another bug with this JDK though, as mentioned in the
            Reporter: Vincent Bories-Azeau

When using the TelnetClient class, a {{NullPointerException}} may occur when calling the {{disconnect}}
method twice, in the {{_closeOutputStream}} method called under the hood, if the Telnet connection
is lost (for instance, server is hardly shut down).

1. The first call to {{disconnect}} resets completely the TelnetClient instance.
2. The second call to {{disconnect}} leads to the NPE exception, because the {_output_} property
is {{null}}, in the {{_closeOutputStream}} method.

*NOTE: the NPE does not occur with JDK 8, because, the first call to {{disconnect}} throws
an I/O exception (socket is closed), leaving the TelnetClient instance with a non-null {{\_output\_}}
property. Then a second call to disconnect does not throw a NPE. It seems the JDK 8 behaves
differently when a client socket loses a connection. So there is also a bug with JDK 8, as
disconnection shall close quietly resources without an I/O exception, and without leaving
non-null resources, and then disconnect the client socket. The {{SocketClient.disconnect}}
is a good implementation to start with.*

The problem is that the TelnetOutputStream class closes the Socket output stream under the
hood, but doesn't check if it is null and doesn't reset it to null once done. _The implementation
of the TelnetOutputStream is quite strange, as there is a cycling dependency between this
class and the TelnetClient class. The {{TelnetClient}} class shall handle itself the close
of its internal resources, and disconnect the client socket. But this responsibility is delegates
to the TelnetOutputStream._

Here's the stack trace of the NPE exception:

This message was sent by Atlassian JIRA

View raw message