dev@grizzly.java.net

Re: SelectorThreadKeyHandler.resetExpiration() ?

From: Oleksiy Stashok <Oleksiy.Stashok_at_Sun.COM>
Date: Tue, 27 Jan 2009 19:23:19 +0100

Hi,

>
> I want to understand the purpose of the reset call:
>
> + ((SelectorThreadKeyHandler) selectorHandler.
> getSelectionKeyHandler()).resetExpiration();
> key.attach(response.getResponseAttachment());
>
> in trunk that resetExpiration() permanently disables the use of
> expiration check interval,
> so the check is performed on every select.
>
> in branch i changed it to reset the nextexpirationchecktime to 0,
> hence the next select will perform idle check, and after that
> its back to the interval delay per check.
Actually it wasn't me, who made changes to your code. If you'll take a
look at diff
-
selectorThread.getSelectorThreadKeyHandler().resetExpiration();
+ ((SelectorThreadKeyHandler)
selectorHandler.getSelectionKeyHandler()).resetExpiration();

you see, that I just changed the code, which tooks
SelectorThreadKeyHandler from SelectorThread to take it from
ProcessorTask instead.

I have no idea, why your code was changed :(

WBR,
Alexey.

>
>
> btw. comet is using the main grizzly selector logic now,
> hence i had to enforce idlecheck once per second to keep the
> precision that comet allows for.
>
> --
> regards
> gustav trede
>
>