cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Heinicke (JIRA) <>
Subject [jira] Commented: (COCOON-2109) Incorrent cleanup of expired continuations
Date Fri, 10 Aug 2007 12:17:42 GMT


Jörg Heinicke commented on COCOON-2109:

Are you sure that modifying the value of the sort criteria does not change the order of the
elements? At the end it's the question when the elements are sorted - on inserting them or
on iterating over them. I'm pretty sure it's the latter and then there would be no problem.
The Javadoc for SortedSet says: "A set that further guarantees that its iterator will traverse
the set in ascending element order".

A potential problem I can see is the modification of the lastAccessTime WHILE actually iterating
over the set. The iterating itself is for sure synchronized to avoid ConcurrentModificationExceptions
or something like this. But at that time you still can change the lastAccessTime. As soon
as the ContinuationsManagerImpl gets to the first continuation with a modified lastAccessTime
it would stop iterating and the expired continuations with a later lastAccessTime than the
updated one had before would survive the cleanup.

Does it make sense? (I did not look into the code.)

> Incorrent cleanup of expired continuations
> ------------------------------------------
>                 Key: COCOON-2109
>                 URL:
>             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
>         Attachments:
> 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 implement the compareTo interface using the lastAccessTime and when a continuation
is inserted in the container, it gets correctly ordered. But after the insertion, 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
> The result of this bug is that under hevy load many 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.

View raw message