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
> *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.
>