[
https://issues.apache.org/jira/browse/COCOON-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Miguel Cuervo updated COCOON-2109:
----------------------------------
Description:
The class ContinuationsManagerImpl is in charge of cleaning up expired
continuations. It does so in the method expireContinuations. In this method
there is a loop using an iterator over a SortedSet of continuations
(WebContinuation). The loop is expecting that the continuations are ordered
from oldest to newest. The loop stops in the first continuation that is not
expired. The logic is correct since all the newer continuations could not be
expired.
However, the problem comes from the ordering of the continuations. To have the
continuations ordered by lastAccessTime the program uses a TreeSet as a
container of the continuations. The continuations correctly implement the
compareTo interface using the lastAccessTime and when a continuation is
inserted in the container, it gets correctly ordered. But once the continuation
is inserted in the container, the continuation can change its lastAccessTime
using the method WebContinuation.updateLastAccessTime() called from
WebContinuation.getContinuation(). The ordering of the TreeSet is not updated
with the change and when the program iterates over it, it does not get the
continuations in the order expected.
The result of this bug is that under hevy load may expired continuations may be
around before the loop actually clean them up, eating memory resources and
causing OutOfMemory.
To fix it, a patch is provided that uses a HashSet for the continuations
container and loops over all the continuations to check if they have expired.
was:
The class ContinuationsManagerImpl is in charge of cleaning up expired
continuations. It does so in the method expireContinuations. In this method
there is a loop using an iterator over a SortedSet of continuations
(WebContinuation). The loop is expecting that the continuations are ordered
from oldest to newest. The loop stops in the first continuation that is not
expired. The logic is correct since all the newer continuations could not be
expired.
However, the problem comes from the ordering of the continuations. To have the
continuations ordered by lastAccessTime the program uses a TreeSet as a
container of the continuations. The continuations correctly implement the
compareTo interface using the lastAccessTime and when a continuation is
inserted in the container, it gets correctly ordered. But once the continuation
is inserted in the container, the continuation can change its lastAccessTime
using the method WebContinuation.updateLastAccessTime() called from
WebContinuation.getContinuation(). The ordering of the TreeSet is not updated
with the change and when the program iterates over it, it does not get the
continuations in the order expected.
The result of this bug is that under hevy load may expired continuations may be
around before the loop actually clean them up, eating memory resources and
causing OutOfMemory.
To fix it, a patch is provided using a HashSet for the continuations container
and looping over all the continuations to checked if they have expired.
> Incorrent cleanup of expired continuations
> ------------------------------------------
>
> Key: COCOON-2109
> URL: https://issues.apache.org/jira/browse/COCOON-2109
> Project: Cocoon
> Issue Type: Bug
> Components: - Flowscript
> Affects Versions: 2.1.6, 2.1.7, 2.1.8, 2.1.9, 2.1.10, 2.1.11-dev (Current
> SVN)
> Reporter: Miguel Cuervo
>
> The class ContinuationsManagerImpl is in charge of cleaning up expired
> continuations. It does so in the method expireContinuations. In this method
> there is a loop using an iterator over a SortedSet of continuations
> (WebContinuation). The loop is expecting that the continuations are ordered
> from oldest to newest. The loop stops in the first continuation that is not
> expired. The logic is correct since all the newer continuations could not be
> expired.
> However, the problem comes from the ordering of the continuations. To have
> the continuations ordered by lastAccessTime the program uses a TreeSet as a
> container of the continuations. The continuations correctly implement the
> compareTo interface using the lastAccessTime and when a continuation is
> inserted in the container, it gets correctly ordered. But once the
> continuation is inserted in the container, the continuation can change its
> lastAccessTime using the method WebContinuation.updateLastAccessTime() called
> from WebContinuation.getContinuation(). The ordering of the TreeSet is not
> updated with the change and when the program iterates over it, it does not
> get the continuations in the order expected.
> The result of this bug is that under hevy load may expired continuations may
> be around before the loop actually clean them up, eating memory resources and
> causing OutOfMemory.
> To fix it, a patch is provided that uses a HashSet for the continuations
> container and loops over all the continuations to check if they have expired.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
