SSLSessionContextImpl Error (null pointer) in JAX-WS generated code?

Can anyone tell me if this is related to the SSL session, or if this is indicative of a certificate issue?

I'm using some code created from JAX wsimport and have run into an occassional issue. The error thrown seems to be related to SSL session invalidation. However, this code was working fine previously and I am at a loss as to where to look.

Exception:

 [ java.lang.NullPointerException ] java.lang.NullPointerException
    at com.sun.net.ssl.internal.ssl.SSLSessionContextImpl.remove(SSLSessionContextImpl.java:199)
    at com.sun开发者_如何学Go.net.ssl.internal.ssl.SSLSessionImpl.invalidate(SSLSessionImpl.java:558)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1559)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1547)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1511)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1456)
    at com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:64)
    at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
    at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
    at java.io.PrintStream.flush(PrintStream.java:286)
    at sun.net.www.MessageHeader.print(MessageHeader.java:228)
    at sun.net.www.http.HttpClient.writeRequests(HttpClient.java:602)
    at sun.net.www.protocol.http.HttpURLConnection.writeRequests(HttpURLConnection.java:430)
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:970)
    at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:234)
    at java.net.URL.openStream(URL.java:1007)
    at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.createReader(RuntimeWSDLParser.java:837)
    at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.resolveWSDL(RuntimeWSDLParser.java:294)
    at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:151)
    at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:131)
    at com.sun.xml.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:267)
    at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:230)
    at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:178)
    at com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:106)
    at javax.xml.ws.Service.<init>(Service.java:57)
... (truncated)

EDIT:

I traced the exception up through the stacktrace and found myself at the line com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:64). This appears to be writing bytes to the output stream, and catches any exceptions thrown during this process. Within the catch block, it sends the exception into the SSLSocketImpl class which eventually tries to invalidate the session. During the session invalidation is where the null pointer occurs (a secondary exception).

AppOutputStream.write():

public synchronized void write(byte[] paramArrayOfByte, int paramInt1, int paramInt2)
throws IOException
{
    this.c.checkWrite();
    try
    {
      do
      {
        int i = Math.min(paramInt2, this.r.availableDataBytes());

        if (i > 0) {
          this.r.write(paramArrayOfByte, paramInt1, i);
          paramInt1 += i;
          paramInt2 -= i;
        }
        this.c.writeRecord(this.r);
        this.c.checkWrite();
      }while (paramInt2 > 0);
    }
    catch (Exception localException) {
      this.c.handleException(localException);
    }
}

The details of the initial exception are not printed by default. You must use the jvm switch -Djavax.net.debug=SSL,session to get this information to print to your localhost/console log. I have enabled this in my test environment, but have never seen the error there so it may not prove useful. Because of the volume of logging information this produces, I am wary of enabling this option in production.

It seems that the literal question I asked may be answered with these findings. However, the source of the exception (the output stream writes occasionally failing) is still unanswered.

Request suggestions about closing/answering this question and opening another, or continuing to solicit responses here.