Hi David,
pls. check the 1.9.35-SNAPSHOT.
Thanks.
WBR,
Alexey.
On 05/02/2011 02:29 PM, Gay David (Annecy) wrote:
>
> Hi,
>
> I fill an issue here : http://java.net/jira/browse/GRIZZLY-1006
>
> About Grizzly 2.0, I would really love to use it, and this is of
> course, in our future plan.
>
> But, unfortunately, we are currently very near the release date of our
> product and updating to G2.x will be too costly in term of dev. and
> validation at this point.
>
> I have to admit that I search for an alternative solution by keeping
> 1.9 right now.
>
> That's why I fill the issue as you suggest.
>
> Thanks for your help
>
> David.
>
> *De :*Oleksiy Stashok [mailto:oleksiy.stashok_at_oracle.com]
> *Envoyé :* lundi 2 mai 2011 12:31
> *À :* users_at_grizzly.java.net
> *Objet :* Re: Problem with SSL and Grizzly 1.9
>
> 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 <mailto: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.
>