>>> The fundamental issue here is that we do not have the flexibility to
>>> configure a
>>> Grizzly transport in a manner that does not do "expiring of keys".
>>> This
>>> includes (and not necessarily an exhaustive list):
>>> 1.) Controller.doSelect() should only do "expiring of keys" for those
>>> applications that need it, (which should be the default).
>>> Applications that do
>>> not need "expiring of keys" should be able to disable this
>>> functionality.
>>>
>> Right now it's possible by extending DefaultSelectionKeyHandler's
>> expire(Set<SelectionKey>) method. May be we can rename it, because
>> now possible "expire" sounds to strong... but something like
>> "postProcessKeys" or similar.
>> DefaultSelectionKeyHandler will work with "expiring of keys" enabled,
>> but developer could provide his own SelectionKeyHandler, which will
>> disable it.
>
> Yes, that can be done.
>
> But, there's quite a bit of unnecessary overhead. In particular, you
> will always iterate of a set of keys in the Controller.doSelect().
I moved this code from Controller - so this logic is up to
SelectionKeyHandler.
WBR,
Alexey.
>
> I think the "expiring of keys" should be moved to the default
> SelectorHandler.postSelect() method. I think this is what we really
> intend to do with expiring keys. Isn't it really a "post select"
> activity?
>
> For those applications which do not need to expire keys, its
> SelectorHandler.postSelect() method should be empty.
>
> And, there is also the attachment stuff which some applications do not
> need also.
>
>>
>>> 2.) The attaching of a Long (System.currentTimeMillis()) to a
>>> SelectionKey's
>>> attachment should not be mandatory. Again, this should be the
>>> default since
>>> "expiring keys" is the default configuration. But, when it is not
>>> desired, then
>>> any attaching of a Long (System.currentTimeMillis()) should not be
>>> done at
>>> "accept time", or in any other location.
>>>
>> Right now think we have a mess with attachments: Long, Attachment ...
>> etc. We have to come to some consistent/extensible attachment type,
>> which will be universal for all/most usecases. May be it could be
>> some Map, which can be attached to SelectionKey and will be able to
>> hold custom attachments? Because right now in one place we expect
>> Long, on other Attachment, and if developer will need his own type...
>
> I think we would be wise to make it difficult for a user of Grizzly to
> attach something to a SelectionKey. Attaching things to a
> SelectionKey usually leads to poor performance.
>
> This is definitely a topic we should discuss at a Project Grizzly
> meeting.
>
> Unfortunately Jeanfrancois is on vacation / holidays this week and I
> have an urgent "one time" meeting scheduled at the same time for
> August 14th's meeting.
>
> charlie ...
>>
>>> In other words, we need to be able to have the default configuration
>>> for a
>>> Grizzly transport that enables "expiring keys" *and* we need to be
>>> able to
>>> configure a Grizzly transport that disables the "expiring keys"
>>> features and any
>>> of its artifacts.
>>>
>> Agree.
>>
>> WBR,
>> Alexey.
>>> Perhaps this is justification for integrating a
>>> TransportConfiguration interface
>>> / object that allows one to configure a Grizzly transport more easily.
>>>
>>> ---------------------------------------------------------------------
>>> 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: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>