Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <2947441.1186748983164.JavaMail.jira@brutus>
Date: Fri, 10 Aug 2007 05:29:43 -0700 (PDT)
From: =?utf-8?Q?J=C3=B6rg_Heinicke_=28JIRA=29?= <jira@apache.org>
To: dev@cocoon.apache.org
Subject: [jira] Commented: (COCOON-2109) Incorrent cleanup of expired
 continuations
In-Reply-To: <24012905.1186739622828.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/COCOON-2109?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519009 ]=20

J=C3=B6rg Heinicke commented on COCOON-2109:
---------------------------------------

Of course the other classes are not aware of this set - and should not sinc=
e it is internal state of the ContinuationsManagerImpl. That's what I meant=
 when I wrote you can not prevent updates on the lastAccessTime, only on th=
e set itself.

But you missed my point. Purely from the Javadoc I claim that the set is so=
rted on iterator() not on adding the continuations to the set. So there is =
no need to recreate the set on every iteration.

> 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 (Curr=
ent SVN)
>            Reporter: Miguel Cuervo
>         Attachments: ContinuationsManagerImpl.java.patch
>
>
> The class ContinuationsManagerImpl is in charge of cleaning up expired co=
ntinuations. It does so in the method expireContinuations. In this method t=
here is a loop using an iterator over a SortedSet of continuations (WebCont=
inuation). The loop is expecting that the continuations are ordered from ol=
dest to newest.  The loop stops in the first continuation that is not expir=
ed. The logic is correct since all the newer continuations could not be exp=
ired.
> However, the problem comes from the ordering of the continuations. To hav=
e the continuations ordered by lastAccessTime the program uses a TreeSet as=
 a container of the continuations. The continuations implement the compareT=
o interface using the lastAccessTime and when a continuation is inserted in=
 the container, it gets correctly ordered. But after the insertion, the con=
tinuation can change its lastAccessTime using the method WebContinuation.up=
dateLastAccessTime() called from WebContinuation.getContinuation(). The ord=
ering of the TreeSet is not updated with the change and when the program it=
erates over it, it does not get the continuations in the order expected.
> 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 resour=
ces 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 expire=
d.

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.