dev@grizzly.java.net

Re: [Proposal] SelectionKey Management

From: charlie hunt <charlie.hunt_at_sun.com>
Date: Tue, 21 Aug 2007 12:30:09 -0500

One of the major problems I have in the current implementation of the
Controller.doSelect() is the following set of code:

            readyKeys = selectorHandler.keys();
            if (readyKeys.isEmpty()){
                return;
            }

            if (selectorHandler.isOpen()) {
                selectionKeyHandler.expire(readyKeys.iterator());
            }


IMO, we are assuming with the above logic that every application that
uses a Grizzly Controller will be doing the expiring of SelectionKeys.
I don't think we should make that assumption in the Controller. Granted
if the readKeys is empty or the SelectionKeyHandler.expire() method is
empty, no expiring of keys happens. But, you have some unnecessary
logic executing here that from a design standpoint for applications that
do not need to expire keys will execute.

I think the above logic needs to get moved to the default tcp
SelectorHandler.postSelect() since what I think what we really want is
to make the expiring of SelectionKeys a plug-able component.

Isn't expiring of SelectionKeys really a "post select" activity as
opposed to a "do select" activity? And, shouldn't it be the
SelectorHandler that decides what the "post select" activity should be,
if any?

charlie ....

Jeanfrancois Arcand wrote:
> Hi,
>
> reading Charlie and Alexey discussion on how the SelectionKey
> management code, I came with the following API changes in order to fix
> the issues Charlie as pointed out. I've deprecated both
> SelectionKeyHandler register/expire and added two new method. Those
> two methods will allow the complete removal of the expiring code that
> was by default added to the TCPSelectorHandler.
>
> See my last commit for the details. Please let me know what you think.
> I can can revert the changes in case we are in disagreement :-)
>
> Thanks
>
> -- Jeanfrancois
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>

-- 
Charlie Hunt
Java Performance Engineer
630.285.7708 x47708 (Internal)
<http://java.sun.com/docs/performance/>