I have figured out that if the 07/05 and RFC EPP classes in EPP-RTK will
throw a NullPointerException if the connection to the server is
unexpectedly lost. I figured this out while testing pooling classes I
wrote to pool EPP connections.
What I did to test this was to create a single EPPClient, and have it do
a DomainInfo request repeatedly, sleeping between requests, against a
sandbox EPP server that we use locally. Then I killed off the sandbox
server, which abruptly terminates the connection to the EPP server.
On the *next* EPPDomainInfo request, EPP-RTK generates a
NullPointerException (details below on why). The biggest problem with
this is that EPPClient.isValid() still returns TRUE after this. This
goes away on the *following* EPPDomainInfo request when a proper
epp_Exception is thrown (java.net.SocketException: Connection closed by
remote host). I assume we do not get this exception the first time
because we have not yet read the EOF from the socket.
The problem is basically in
(epp0705,epprtk)/rtk/transport/EPPTransportTCP.java, in the
in readFromServer(), this happens:
len = readBufferSize(reader_from_server_);
But, if the server dropped the connection unexpectedly, len will be -1.
Further down in readFromServer(), it handles that this way:
if (len <= 0)
debug(DEBUG_LEVEL_THREE,method_name,"Invalid length of EPP
XML instance." + len);
So, it returns "null".
The problem is that EPPClient passes this "null" on blindly to whatever
fromXML() is appropriate, but none of the fromXML() methods check if the
string that was passed in was "null" or not. The result is that a
NullPointerException is thrown. It would be nice if EPPClient would
detect if readFromServer() returned null, and would set this.isValid =
false in this case, and throw an epp_Exception.
This problem appears to be present in both the 0705 and 1.0 EPP classes.