Hi Charlie,
charlie hunt wrote:
> Hi Jeanfrancois,
>
> Do you remember how we were looking at doing the expiring of keys in
> Grizzly V2 about a year ago? (I know not everyone on this list has
> knowledge of Grizzly V2)
I can't hardly remember anything I did 3 weeks ago :-) Seriously I need
to take a look at the v2 code.
>
> We were gonna put the expiring of keys as a plug-able element of the
> doSelect()'s postSelect() method. And, it would be the default Grizzly
> transport configuration. But, there would be a way to disable it /
> override it.
>
> We also had a plug-able preSelect() / postSelect() elements for the
> class of applications that wanted to do connection caching.
>
> Are we gonna be able to support both of these with the Alexy's change?
Yes. I think the SelectionKeyHandler is exactly the same concept as we
have discussed during the v2 timeframe. Hence if you need to customize
the process, you just need to implement the SelectionKeyHandler
Interface (or overload the expire() method). As an example, the SIP
protocol doesn't need to expire SelectionKey and the way we did
implement it was to:
> 103 DefaultSelectionKeyHandler keyHandler =
> 104 new DefaultSelectionKeyHandler(){
> 105 public void expire(SelectionKey key){
> 106 } // The connections are never going to be closed
> 107 };
Thanks
-- Jeanfrancois
>
> Btw, this something we should talk about tomorrow at the Project Grizzly
> meeting.
>
> charlie ...
>
> jfarcand_at_dev.java.net wrote:
>> https://grizzly.dev.java.net/issues/show_bug.cgi?id=21
>>
>>
>>
>>
>>
>>
>> ------- Additional comments from jfarcand_at_dev.java.net Tue Aug 21
>> 15:49:58 +0000 2007 -------
>> I agree with both of you :-) The goal of the SelectionKeyHandler is to
>> give
>> control, for an application, of the SelectionKey life cycle (and a
>> plus when you
>> compare to other framework). Looking at Alexey's changes, I would
>> think we
>> should deprecate the expire(SelectionKey), and leave the new interface
>> there.
>> That way the initial contract for the interface still meet the goal I
>> was having
>> when designing it.
>> We should send a warning on the dev/user list to describe the
>> interface changes.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: issues-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: issues-help_at_grizzly.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: issues-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: issues-help_at_grizzly.dev.java.net