From: Gay David (Annecy) <"Gay>
Date: Wed, 27 Apr 2011 09:26:17 +0000

Hi all,

I've a problem with Grizzly 1.9 and SSL.
What we done in our server, is delegating all incoming requests to a thread pool executor.
Of course, we take care of suspend/resume.
(Please see this message : http://java.net/projects/grizzly/lists/users/archive/2011-01/message/21)

This works very well for http.

But, for https, this design doesn't seems to works. The issue only pops up with SSL for one reason: while normal requests do not require a context, SSL ones do (they require access to their SSL context). This context is not part of the request in Grizzly, but is part of the Thread. When we run in asynchronous mode, we're running in our own thread pool instead of Grizzly's, and thus the thread do not carry this information. The first read operation to be executed within the asynchronous thread will trigger a ClassCastException, which Grizzly mistakenly change into a "InvalidChunkHeader" error.

The offending code is in com.sun.grizzly.util.InputReader.doSecureRead():

    protected int doSecureRead() throws IOException{
        final WorkerThread workerThread =
                (WorkerThread)Thread.currentThread();

        Utils.Result r = SSLUtils.doSecureRead((SocketChannel) key.channel(),
                workerThread.getSSLEngine(), byteBuffer,
                workerThread.getInputBB());

        byteBuffer.flip();
        isClosed = r.isClosed;
        return r.bytesRead;
    }

Do you think that our design is wrong in this case ?

Thanks and Regards
David G.