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)
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?
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
>
>
--
Charlie Hunt
Java Performance Engineer
630.285.7708 x47708 (Internal)
<http://java.sun.com/docs/performance/>