Hi David,
>
> Just testing right now and it works with snapshot version
> 2.1.3-20110921.125807-2
>
> Very good news, thanks a lot.
>
Glad to hear that :)
> And yes I'm testing with the use case I send you in the previous mail.
>
> What is your fix ? Is it related to SSL ?
>
Yes, but I fixed SSL *encoder* and the failure you posted was related to
decoder. May be it was a side-effect of the encoder failure.
http://java.net/jira/browse/GRIZZLY-1079
Thanks.
WBR,
Alexey.
> Thanks and regards
>
> David
>
> *From:*Oleksiy Stashok [mailto:oleksiy.stashok_at_oracle.com]
> *Sent:* mercredi 21 septembre 2011 15:17
> *To:* users_at_grizzly.java.net
> *Subject:* Re: Grizzly 2 and SSL
>
> Hi David,
>
> * On IExplorer 8, it fail most of the time (I know it's not a real
> browser :-)
>
> * On Firefox 6.0.2, not always, but if you click on the refresh button
> often, you can see this problem :
>
> org.glassfish.grizzly.TransformationException:
> javax.net.ssl.SSLException: Received fatal alert: unexpected_message
>
> ...
>
> Caused by: javax.net.ssl.SSLException: Received fatal alert:
> unexpected_message
>
> I tried Windows 7 and IE, but never seen the "Received fatal alert:
> unexpected_message" exception.
> Though I did found and fixed one more issue.
> Can you pls. check the latest 2.1.3-SNAPSHOT one more time?
> Are you doing the test with the app you attached in one of the prev.
> emails?
>
> Thanks.
>
> WBR,
> Alexey.
>
>
>
>
> Thanks
>
> Regards, David
>
> *From:*Oleksiy Stashok [mailto:oleksiy.stashok_at_oracle.com]
> *Sent:* mardi 20 septembre 2011 09:51
> *To:* users_at_grizzly.java.net <mailto:users_at_grizzly.java.net>
> *Subject:* Re: Grizzly 2 and SSL
>
> Hi David,
>
> I wasn't able to reproduce the issue, but recently we've fixed another
> issue, which could be related [1].
> Can you pls. check the latest 2.1.3-SNAPSHOT from maven repo [2]?
>
> Thanks.
>
> WBR,
> Alexey.
>
>
> [1] http://java.net/jira/browse/GRIZZLY-1077
> [2] https://maven.java.net/content/groups/public/
>
> On 09/14/2011 09:22 PM, Gay David (Annecy) wrote:
>
> Hi,
>
> I re-made some tests. Sometimes it works, but I have to say that most
> of the time it fails.
>
> By looking at the exchange between the browser and the server with
> Charles Proxy, I have the feel that it's the client (so the browser)
> that close the connection. But I'm not sure. I say that because I see
> that only a few byte are exchange when it fails :
>
> URL
>
>
>
> https://localhost:35000/www/afile.pdf
>
> Status
>
>
>
> Receiving response body...
>
> Response Code
>
>
>
> 200 OK
>
> Protocol
>
>
>
> HTTP/1.1
>
> Method
>
>
>
> GET
>
> Content-Type
>
>
>
> application/pdf
>
> Client Address
>
>
>
> /127.0.0.1
>
> Remote Address
>
>
>
> -
>
> Timing
>
>
>
> Request Start Time
>
>
>
> 14/09/11 21:06:31
>
> Request End Time
>
>
>
> 14/09/11 21:06:31
>
> Response Start Time
>
>
>
> 14/09/11 21:06:31
>
> Response End Time
>
>
>
> -
>
> Duration
>
>
>
> -
>
> Request Duration
>
>
>
> 16 ms
>
> Response Duration
>
>
>
> -
>
> Latency
>
>
>
> 0 ms
>
> Speed
>
>
>
> 0,02 KB/s
>
> Response Speed
>
>
>
> 0,02 KB/s
>
> Size
>
>
>
> Request Header Size
>
>
>
> 402 bytes
>
> Response Header Size
>
>
>
> 112 bytes
>
> Request Size
>
>
>
> -
>
> Response Size
>
>
>
> 15,89 KB (16272 bytes)
>
> Total Size
>
>
>
> 16,39 KB (16786 bytes)
>
> Request Compression
>
>
>
> -
>
> Response Compression
>
>
>
> -
>
> When it fails, the response size is only 16272 bytes (it should be 256175)
>
> But I'm sure that with getOutputStream( true ) it always works on my
> laptop.
>
> Thanks and regards
>
> David
>
> *From:*Oleksiy Stashok [mailto:oleksiy.stashok_at_oracle.com]
> *Sent:* mercredi 14 septembre 2011 10:51
> *To:* users_at_grizzly.java.net <mailto:users_at_grizzly.java.net>
> *Subject:* Re: Grizzly 2 and SSL
>
> Hi David,
>
> on my laptop your sample works fine in all cases :(
> I'll try Windows 7 later on.
>
> Regarding the failure, wanted to ask more details.
> The failure is *always* reproducible, the download never succeeds with
> enabled SSL + non blocking streams?
>
> According to the stack trace you sent the failure happens when we try
> to read and unwrap secured data, so as I understand, it should happen
> before our HttpHandler takes over control. So currently I'm not sure
> how output stream mode may affect the SSL read.
>
> Thanks.
>
> WBR,
> Alexey.
>
>
>