Hi Marc,
On 13.01.14 08:37, Marc Arens wrote:
> Hello,
>
> we're currently seeing a problem for a single customer with
> org.glassfish.grizzly.utils.IdleTimeoutFilter.queue leaking/not getting cleaned
> properly so the server runs out of memory within ~48 hours. As far as i
> understand Connections aren't removed from the queue until
> org.glassfish.grizzly.utils.DelayedExecutor.DelayedRunnable instructs
> org.glassfish.grizzly.utils.IdleTimeoutFilter.DefaultWorker.doWork(Connection)
> to close the connection via closeSilently() which results in
> org.glassfish.grizzly.utils.IdleTimeoutFilter.handleClose(FilterChainContext)
> being called.
>
> Are/were there known bugs i missed or is there an easy explanation for the
> behaviour we're seeing? We don't see this on other installations and i could
> reproduce a similar behaviour by making a Servlet's service hangs endlessly.
> While the connections from the apache in front of grizzly were closed after a
> apache timeout of 100 seconds, the queue didn't shrink at all.
IdleTimeoutFilter keeps track of all FilterChainContext associated with
a Connection and allows to close the Connection only when it doesn't
have any active FilterChainContext associated with the Connection.
In your case, when you have endless Servlet.service() method - you keep
FilterChainContext active, so IdleTimeoutFilter doesn't treat the
Connection as idle.
I'm not aware of any bugs related to IdleTimeoutFilter, but if you have
a testcase - we'll definitely take a look and fix the problem.
>
> I found the org.glassfish.grizzly.utils.ActivityCheckFilter which sound useful
> for this kind of situation but how does it work in combination with suspended
> requests e.g. Comet?
ActivityCheckFilter is more lax, it doesn't track live
FilterChainContexts, but monitors Connection activity (read, write,
other events), and if there was no activity registered for a given
period of time - it closes the Connection.
Both Filters could work with Comet, both of them meant to detect idle
Connections, but use different approaches for that. So it's up to you to
decide which one is better for a specific usecase.
Thanks.
WBR,
Alexey.