Hi Alexey,
I've just finishing my tests right now, and it seems to work perfectly.
We will push further to continue to validate in real world case.
Anyway, big thanks for providing this patch. You're awesome !
You Make My Day
Regards
David
De : Oleksiy Stashok [mailto:oleksiy.stashok_at_oracle.com]
Envoyé : mardi 3 mai 2011 10:56
À : users_at_grizzly.java.net
Objet : Re: Problem with SSL and Grizzly 1.9
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<mailto: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.