On Sep 23, 2009, at 3:20 AM, Oleksiy Stashok wrote:
> Hi Igor,
>
>> I had a brief look at integrating grizzly-sendfile with grizzly 2.0-
>> m3 (via an AsyncFilter) and noticed these issues:
>>
>> - ProcessorTask doesn't have getSelectionKey() method. Is there a
>> way to get hold of the selection key?
> It should have getConnection(), which is abstraction which
> represents current connection.
ahhh.. I see.
>
>> - no key == no ThreadAttachment == no SSLEngine for SSL. Is there a
>> different way to get hold of the SSLEngine?
> Yes :)
> You can store everything using Connections and Attributes.
> SSLResourcesAccessor.getInstance().getSSLEngine(connection);
that looks more complicated that it really needs to be, but I
understand that getting the SSLEngine from the connection is not a
common operation.
>
>> - no key == no way to cancel it
> Hmm, that's true. We'll need to think about good way to do that.
> (can you pls. file an issue)?
I will, in fact all three operations could be exposed just as one -
connection handoff - an api that would let grizzly know that the
filter is taking over responsibility for this particular connection.
That would then mean that:
- grizzly's key would be canceled immediately
- grizzly would know that the connection should be treated as
deregistered and wouldn't close it
- and that it shouldn't be closed regardless it's keepalive status
The way grizzly-sendfile integration works with grizzly 1.0 and 1.9 is
a black magic in a way because I get my hands on all the raw resources
(the key, channel, etc) controlled by grizzly and cancel or flag them
in a way that grizzly just "forgets" about them and that allows
grizzly-sendfile to take over and do it's things at the lowest level
possible in pure java.
I created an RFE for this:
https://grizzly.dev.java.net/issues/show_bug.cgi?id=740
>
>> - support for connection deregistration which was added to 1.9.x
>> seems to be missing (SelectionKeyAttachment.DEREGISTERED)
> Can you pls. elaborate? :)
it's just a piece of black magic that was introduced with:
https://grizzly.dev.java.net/issues/show_bug.cgi?id=548
>
>> - ProcessorTask#setForceKeepAlive available in 1.9.x is missing in
>> 2.0. This api might not be necessary any more if the connection
>> deregistration was implemented properly.
> Probably this was added after forking http 2.0 module.
yeah and it really is just a hack. As I said I don't really need it if
the connection hand-off is implemented correctly.
One more issue I have is that I can't get access to the raw channel.
That's a show-stopper for grizzly-sendfile. I added it to the ticket
as a return value for the proposed api.
/i
>
>> Other than that everything seems to be the same as 1.9.x (when it
>> comes to source compatibility of the api), which is a bit
>> surprising. I expected many more api changes. Are more breaking
>> changes coming? I kind of hope they are :)
> As for http module - not. framework module - yes.
>
> WBR,
> Alexey.
>>
>> /i
>>
>> ---------------------------------------------------------------------
>> 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
>