Hi there,
attached is a very simple program demonstrating the problem with 1.9.17
There are three odd thing is with the behavior of this program:
1) ssl engine is null when it shouldn't be
2) the output as well as debugger show that the filter was hit twice,
when only one request was made
3) when the exception in the filter is thrown, grizzly doesn't close
the request with 500, but rather waits for the connection to time out
cheers,
Igor
On Aug 25, 2009, at 10:03 AM, Jeanfrancois Arcand wrote:
> Salut,
>
> Igor Minar wrote:
>> Hi there,
>> In the last week or so I finally had time to get some work done on
>> grizzly-sendfile. I now have everything but one feature
>> implemented. The last missing piece is SSL support.
>> JFA pointed me to some code within grizzly that deals with SSL.
>> After having a look at this code, I'm having two issues:
>> #1 - when I try to obtain SSLEngine in my async filter via
>> "((WorkerThread)Thread.currentThread()).getSSLEngine();" it returns
>> null even for SSL requests. Is this expected? Should I be
>> retrieving the SSLEngine in some other way?
>
> Do you think you can share a test case?
>
>> #2 - since grizzly-sendfile deregisters the request from the main
>> selector, I'm concerned that the ssl engine will be closed/recycled
>> by grizzly. This might turn out not to be true, but I can't verify
>> it due to #1
>> I have to say that I'm quite surprised about the complexities
>> involved in implementing SSL with NIO. Oh well :-).
>
> Don't tell me!
>
> -- Jeanfrancois
>
>> thanks for your help.
>> cheers,
>> Igor
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
- application/octet-stream attachment: test.jks