dev@grizzly.java.net

Re: [Proposal] SelectionKey Management

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

Jeanfrancois Arcand wrote:
> charlie hunt wrote:
>> Jeanfrancois Arcand wrote:
>>> Hi Charlie,
>>>
>>> charlie hunt wrote:
>>>> 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?
>>>
>>> I see. I agree with your point. I will make the appropriate changes
>>> :-) :-)
>> I considered making the changes while you on vacation, (catching
>> [big] trout, etc) ;-)
>>
>> But, I was fearful it might break existing Grizzly based applications.
>>
>> Thought it made sense til you got back and we (Grizzly community) had
>> a discussion about it first. :-)
> Done :-) Now you need to review :-)

As you know ;-)

As long as we don't break existing Grizzly based applications by making
the changes I've proposed, (i.e. moving the expiring keys logic out of
the Controller.doSelect() to the default tcp
SelectorHandler.postSelect()), then the proposal has my vote :-)

charlie ...

>
> Thanks
>
> -- Jeanfrancois
>
>
>>
>> charlie ....
>>
>>>
>>> Thanks!
>>>
>>> -- Jeanfrancois
>>>
>>>
>>>
>>>>
>>>> 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
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>


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