> uh oh... I just followed an example I got from Jeanfrancois.
> Shouldn't the workerthread's ssl api be deprecated or removed to
> avoid confusion?
WorkerThreads work for regular Grizzly com.sun.grizzly.ProtocolFilter,
but async web filters are executed differently directly by http
module, so some operations, like attaching ThreadAttachment to
WorkerThread, are skipped.
> thanks for putting me back on the track.
No problem :)
Please let us know if you'll have other issues :)
WBR,
Alexey.
>
> /i
>
>
> On Aug 28, 2009, at 6:08 AM, Oleksiy Stashok wrote:
>
>> Hi Igor,
>>
>> as for (1), please use following code:
>>
>> public boolean doFilter(AsyncExecutor asyncExecutor) {
>> SelectionKey key =
>> asyncExecutor.getProcessorTask().getSelectionKey();
>> ThreadAttachment attachment = (ThreadAttachment)
>> key.attachment();
>> SSLEngine sslEngine = attachment.getSSLEngine();
>> // SSLEngine sslEngine = ((WorkerThread)
>> Thread.currentThread()).getSSLEngine();
>>
>> WBR,
>> Alexey.
>>
>>
>> On Aug 27, 2009, at 17:31 , Igor Minar wrote:
>>
>>> Were you able to reproduce the issues?
>>>
>>> /i
>>>
>>> On Aug 25, 2009, at 3:36 PM, Igor Minar wrote:
>>>
>>>> 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
>>>> <TestSslServer.java><test.jks>
>>>>
>>>> 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
>>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>