Hi David,
> * From what I understand, does it means that, for Grizzly 1.9, we
> can't use the suspend/resume response feature with SSL ?
>
Currently there is a bug, which makes problems.
BTW, can I ask you to file an issue, will try to come with the patch asap.
> * You suggest to "read off all the request bytes before suspending".
> Could you suggest any hints on how to do that ?
>
Considering next "*" - IMO it's not the case.
> * In our particular case, we do files uploads. So we may post big
> chunk of data, don't you think it could be memory consuming to do what
> you suggest ?
>
Either memory consuming problem or blocking when reading from the socket.
Wanted to suggest you one more time take a look at Grizzly 2.1 ;)
Due to java.net problems I can not reference you to the documentation
section to take a look at, but here is the sample [1] (check the
NonBlockingEchoHandler implementation).
Unlike Grizzly 1.9, Grizzly 2.0 has support for non-blocking
InputStream, which might help you implement *real* non-blocking file
uploading, so will never block the thread waiting for more data from
client. And it should work fine with SSL as well.
Thanks.
WBR,
Alexey.
[1]
http://java.net/projects/grizzly/sources/git/content/samples/http-server-samples/src/main/java/org/glassfish/grizzly/samples/httpserver/nonblockinghandler/NonBlockingHttpHandlerSample.java
>
> Thanks again for your help.
>
> David G.
>
> *De :*Oleksiy Stashok [mailto:oleksiy.stashok_at_oracle.com]
> *Envoyé :* mercredi 27 avril 2011 13:54
> *À :* users_at_grizzly.java.net
> *Objet :* Re: Problem with SSL and Grizzly 1.9
>
> Hi David,
>
> 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.
>
> I see.
>
>
> Do you think that our design is wrong in this case ?
>
> I don't think the problem is on your side.
> To make this work on 1.9 - you need to read off all the request bytes
> before suspending the execution.
> On Grizzly 2.0, 2.1 it should work fine as it is.
>
> Thanks.
>
> WBR,
> Alexey.
>
>
> Thanks and Regards
>
> David G.
>