Oleksiy Stashok wrote:
> Hello Charlie,
>
>> ------- Additional comments from huntch_at_dev.java.net Tue Aug 14
>> 14:51:54 +0000 2007 -------
>> The potential problem with modifying or removing an existing
>> interface is that
>> we may break existing applications that may be using it. Hence, I do
>> not think
>> we can remove SelectionKeyHandler.expire(SelectionKey, long) from the
>> SelectionKeyHandler interface.
>>
> Agree, however once we will be able to remove this method from
> interface (for example for Grizzly 1.6) - think it makes sense to do it.
Agree, for a future release it should be deprecated or removed. I don't
recall the release number scheme off the top of my head. :-(
But, I think it would be either Grizzly 1.6 or Grizzly 2.0.
>
>> 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 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
>>
>>
--
Charlie Hunt
Java Performance Engineer
630.285.7708 x47708 (Internal)
<http://java.sun.com/docs/performance/>