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.
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?
We are using grizzly 2.2.x
Best regards,
Marc