You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Miguel Cuervo (JIRA)" <ji...@apache.org> on 2007/08/10 11:53:42 UTC
[jira] Created: (COCOON-2109) Incorrent cleanup of expired
continuations
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.10, 2.1.9, 2.1.8, 2.1.7, 2.1.6, 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 using a HashSet for the continuations container and looping over all the continuations to checked 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.
[jira] Issue Comment Edited: (COCOON-2109) Incorrent cleanup of
expired continuations
Posted by "Miguel Cuervo (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519021 ]
mcuervoe edited comment on COCOON-2109 at 8/12/07 1:22 AM:
----------------------------------------------------------------
Jorg,
Just a small test to prove that the ordering is happening on insert
--------------------------
package test;
import java.util.Iterator;
import java.util.SortedSet;
import java.util.TreeSet;
public class Test implements Comparable {
public int i;
public Test(int x) {
i = x;
}
public int compareTo(Object o) {
Test obj = (Test) o;
return i - obj.i;
}
public static void main(String[] args) {
SortedSet set = new TreeSet();
Test obj1 = new Test(1);
set.add(obj1);
Test obj2 = new Test(3);
set.add(obj2);
Test obj3 = new Test(2);
set.add(obj3);
Iterator iter = set.iterator();
System.out.println("Should print 1,2,3");
while (iter.hasNext()) {
Test obj = (Test) iter.next();
System.out.println(obj.i);
}
obj3.i = 4;
System.out.println("Order modified after insetion");
System.out.println("Should print 1,3,4");
iter = set.iterator();
while (iter.hasNext()) {
Test obj = (Test) iter.next();
System.out.println(obj.i);
}
System.out.println("...but it prints 1,4,3 keeping the order in which the object was inserted");
}
}
was (Author: mcuervoe):
Jorg,
Just a small test to prove that the insertion is happening on insert
--------------------------
package test;
import java.util.Iterator;
import java.util.SortedSet;
import java.util.TreeSet;
public class Test implements Comparable {
public int i;
public Test(int x) {
i = x;
}
public int compareTo(Object o) {
Test obj = (Test) o;
return i - obj.i;
}
public static void main(String[] args) {
SortedSet set = new TreeSet();
Test obj1 = new Test(1);
set.add(obj1);
Test obj2 = new Test(3);
set.add(obj2);
Test obj3 = new Test(2);
set.add(obj3);
Iterator iter = set.iterator();
System.out.println("Should print 1,2,3");
while (iter.hasNext()) {
Test obj = (Test) iter.next();
System.out.println(obj.i);
}
obj3.i = 4;
System.out.println("Order modified after insetion");
System.out.println("Should print 1,3,4");
iter = set.iterator();
while (iter.hasNext()) {
Test obj = (Test) iter.next();
System.out.println(obj.i);
}
System.out.println("...but it prints 1,4,3 keeping the order in which the object was inserted");
}
}
> 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
> Attachments: ContinuationsManagerImpl.java.patch
>
>
> 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 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 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.
[jira] Commented: (COCOON-2109) Incorrent cleanup of expired
continuations
Posted by "Vadim Gritsenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519019 ]
Vadim Gritsenko commented on COCOON-2109:
-----------------------------------------
PS Yes I agree that re-creating the set *is not* a solution. In this case iteration over complete set is acceptable.
> 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
> Attachments: ContinuationsManagerImpl.java.patch
>
>
> 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 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 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.
[jira] Commented: (COCOON-2109) Incorrent cleanup of expired
continuations
Posted by "Jörg Heinicke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519003 ]
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: 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
> Attachments: ContinuationsManagerImpl.java.patch
>
>
> 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 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 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.
[jira] Commented: (COCOON-2109) Incorrent cleanup of expired
continuations
Posted by "Jörg Heinicke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12583507#action_12583507 ]
Jörg Heinicke commented on COCOON-2109:
---------------------------------------
The threading issues you addressed in your patch have not been addressed in my commit yet. It is not as easy as synchronizing on the sets before iterating over them because they have to be in sync.
> Incorrent cleanup of expired continuations
> ------------------------------------------
>
> Key: COCOON-2109
> URL: https://issues.apache.org/jira/browse/COCOON-2109
> Project: Cocoon
> Issue Type: Bug
> Components: * Cocoon Core
> Affects Versions: 2.1.11
> Reporter: Miguel Cuervo
> Assignee: Jörg Heinicke
> Fix For: 2.1.12-dev (Current SVN)
>
> Attachments: ContinuationsManagerImpl.java.patch
>
>
> 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 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 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.
[jira] Closed: (COCOON-2109) Incorrent cleanup of expired
continuations
Posted by "Jörg Heinicke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jörg Heinicke closed COCOON-2109.
---------------------------------
Resolution: Fixed
> Incorrent cleanup of expired continuations
> ------------------------------------------
>
> Key: COCOON-2109
> URL: https://issues.apache.org/jira/browse/COCOON-2109
> Project: Cocoon
> Issue Type: Bug
> Components: * Cocoon Core
> Affects Versions: 2.1.11
> Reporter: Miguel Cuervo
> Assignee: Jörg Heinicke
> Fix For: 2.1.12-dev (Current SVN)
>
> Attachments: ContinuationsManagerImpl.java.patch
>
>
> 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 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 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.
[jira] Commented: (COCOON-2109) Incorrent cleanup of expired
continuations
Posted by "Vadim Gritsenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519018 ]
Vadim Gritsenko commented on COCOON-2109:
-----------------------------------------
Jorg - sort is happening on insert.
Miguel - what I meant is to do
set.remove(w);
w.setLastAccessTime();
set.add(w);
Of course if somebody calls setLastAccessTime from outside, this code would have to be refactored if implementing approach above.
> 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
> Attachments: ContinuationsManagerImpl.java.patch
>
>
> 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 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 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.
[jira] Updated: (COCOON-2109) Incorrent cleanup of expired
continuations
Posted by "Miguel Cuervo (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Miguel Cuervo updated COCOON-2109:
----------------------------------
Attachment: ContinuationsManagerImpl.java.patch
> 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
> Attachments: ContinuationsManagerImpl.java.patch
>
>
> 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.
[jira] Commented: (COCOON-2109) Incorrent cleanup of expired
continuations
Posted by "Jörg Heinicke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519009 ]
Jörg Heinicke commented on COCOON-2109:
---------------------------------------
Of course the other classes are not aware of this set - and should not since 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 the set itself.
But you missed my point. Purely from the Javadoc I claim that the set is sorted 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 (Current SVN)
> Reporter: Miguel Cuervo
> Attachments: ContinuationsManagerImpl.java.patch
>
>
> 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 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 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.
[jira] Updated: (COCOON-2109) Incorrent cleanup of expired
continuations
Posted by "Jörg Heinicke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jörg Heinicke updated COCOON-2109:
----------------------------------
Affects Version/s: (was: 2.1.7)
(was: 2.1.6)
(was: 2.1.8)
> Incorrent cleanup of expired continuations
> ------------------------------------------
>
> Key: COCOON-2109
> URL: https://issues.apache.org/jira/browse/COCOON-2109
> Project: Cocoon
> Issue Type: Bug
> Components: * Cocoon Core
> Affects Versions: 2.1.11
> Reporter: Miguel Cuervo
> Assignee: Jörg Heinicke
> Fix For: 2.1.12-dev (Current SVN)
>
> Attachments: ContinuationsManagerImpl.java.patch
>
>
> 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 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 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.
[jira] Issue Comment Edited: (COCOON-2109) Incorrent cleanup of
expired continuations
Posted by "Miguel Cuervo (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519005 ]
mcuervoe edited comment on COCOON-2109 at 8/10/07 5:24 AM:
----------------------------------------------------------------
It is not that easy. The update of the lastAccessTime it is done by other classes that use the reference to the continuation and that do not know anything about this set of continuations. Therefore you can not expected to have the continuation removed and inserted back in the set every time it changes to manteain the order.
So the only solution I see it will be to recreate the sorted set every time that you want to iterate over it. And this operation will be probably slower that just iterate over all the continuations.
was (Author: mcuervoe):
It is not that easy. The update of the lastAccessTime it is done by other classes that use the reference to the continuation and that do not know anything about this set of continuations. Therefore you can not expected to have the continuation removed and inserted back in the set every time it changes to manteain the order.
So the only solution I see will be recreate the sorted set every time that you want to iterate over it. And this operation will be probably slower that just iterate over all the continuations.
> 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
> Attachments: ContinuationsManagerImpl.java.patch
>
>
> 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 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 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.
[jira] Commented: (COCOON-2109) Incorrent cleanup of expired
continuations
Posted by "Miguel Cuervo (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519005 ]
Miguel Cuervo commented on COCOON-2109:
---------------------------------------
It is not that easy. The update of the lastAccessTime it is done by other classes that use the reference to the continuation and that do not know anything about this set of continuations. Therefore you can not expected to have the continuation removed and inserted back in the set every time it changes to manteain the order.
So the only solution I see will be recreate the sorted set every time that you want to iterate over it. And this operation will be probably slower that just iterate over all the continuations.
> 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
> Attachments: ContinuationsManagerImpl.java.patch
>
>
> 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 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 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.
[jira] Updated: (COCOON-2109) Incorrent cleanup of expired
continuations
Posted by "Miguel Cuervo (JIRA)" <ji...@apache.org>.
[ 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 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 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 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 that uses a HashSet for the continuations container and loops over all the continuations to check 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
> Attachments: ContinuationsManagerImpl.java.patch
>
>
> 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 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 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.
Re: [jira] Updated: (COCOON-2109) Incorrent cleanup of expired continuations
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Joerg Heinicke pisze:
> On 30.03.2008 20:08, Jörg Heinicke (JIRA) wrote:
>> [
>> https://issues.apache.org/jira/browse/COCOON-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>> ]
>>
>> Jörg Heinicke updated COCOON-2109:
>> ----------------------------------
>>
>> Affects version (Component): Parent values: Cocoon Core(10151).
>> Component/s: (was: - Flowscript)
>> * Cocoon Core
>> Fix version (Component): Parent values: Cocoon Core(10227).
>
> I would like to add the proper Cocoon 2.2/Cocoon Core 1.0 versions, but
> the component versions are not yet available. Could somebody please add
> them or do we have to go via Infrastructure for that?
Hi Joerg,
I have all karma needed for this kind of task. I'll add new version numbers to JIRA tomorrow.
--
Grzegorz
Re: [jira] Updated: (COCOON-2109) Incorrent cleanup of expired continuations
Posted by Joerg Heinicke <jo...@gmx.de>.
On 30.03.2008 20:08, Jörg Heinicke (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/COCOON-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Jörg Heinicke updated COCOON-2109:
> ----------------------------------
>
> Affects version (Component): Parent values: Cocoon Core(10151).
> Component/s: (was: - Flowscript)
> * Cocoon Core
> Fix version (Component): Parent values: Cocoon Core(10227).
I would like to add the proper Cocoon 2.2/Cocoon Core 1.0 versions, but
the component versions are not yet available. Could somebody please add
them or do we have to go via Infrastructure for that?
Thanks,
Joerg
[jira] Updated: (COCOON-2109) Incorrent cleanup of expired
continuations
Posted by "Jörg Heinicke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jörg Heinicke updated COCOON-2109:
----------------------------------
Affects version (Component): Parent values: Cocoon Core(10151).
Component/s: (was: - Flowscript)
* Cocoon Core
Fix version (Component): Parent values: Cocoon Core(10227).
Affects Version/s: (was: 2.1.10)
(was: 2.1.9)
Fix Version/s: 2.1.12-dev (Current SVN)
Assignee: Jörg Heinicke
I committed a fix using Vadim's remove/add approach. The WebContinuation is only accessed via the ContinuationsManager, so it was easy to update the last access time whenever it is looked up. The update does no longer happen on WebContinuation.getContinuation() to not break the clean up. Assuming the WebContinuation is never hold across requests outside the ContinuationsManager this should have only the minimal downside of getting no update during request processing, but only at its very beginning. But I guess this is acceptable.
> Incorrent cleanup of expired continuations
> ------------------------------------------
>
> Key: COCOON-2109
> URL: https://issues.apache.org/jira/browse/COCOON-2109
> Project: Cocoon
> Issue Type: Bug
> Components: * Cocoon Core
> Affects Versions: 2.1.6, 2.1.7, 2.1.8, 2.1.11
> Reporter: Miguel Cuervo
> Assignee: Jörg Heinicke
> Fix For: 2.1.12-dev (Current SVN)
>
> Attachments: ContinuationsManagerImpl.java.patch
>
>
> 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 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 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.
[jira] Commented: (COCOON-2109) Incorrent cleanup of expired
continuations
Posted by "Vadim Gritsenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519002 ]
Vadim Gritsenko commented on COCOON-2109:
-----------------------------------------
It would be easier to fix tree set ordering, don't you think?
> 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
> Attachments: ContinuationsManagerImpl.java.patch
>
>
> 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 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 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.
[jira] Commented: (COCOON-2109) Incorrent cleanup of expired
continuations
Posted by "Jörg Heinicke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584384#action_12584384 ]
Jörg Heinicke commented on COCOON-2109:
---------------------------------------
The threading issues in ContinuationsManagerImpl were fixed in rev http://svn.apache.org/viewvc?view=rev&revision=643295 (with few changes from 643294 necessary (WebContinuation is now Cloneable)).
> Incorrent cleanup of expired continuations
> ------------------------------------------
>
> Key: COCOON-2109
> URL: https://issues.apache.org/jira/browse/COCOON-2109
> Project: Cocoon
> Issue Type: Bug
> Components: * Cocoon Core
> Affects Versions: 2.1.11
> Reporter: Miguel Cuervo
> Assignee: Jörg Heinicke
> Fix For: 2.1.12-dev (Current SVN)
>
> Attachments: ContinuationsManagerImpl.java.patch
>
>
> 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 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 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.
[jira] Commented: (COCOON-2109) Incorrent cleanup of expired
continuations
Posted by "Miguel Cuervo (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519021 ]
Miguel Cuervo commented on COCOON-2109:
---------------------------------------
Jorg,
Just a small test to prove that the insertion is happening on insert
--------------------------
package test;
import java.util.Iterator;
import java.util.SortedSet;
import java.util.TreeSet;
public class Test implements Comparable {
public int i;
public Test(int x) {
i = x;
}
public int compareTo(Object o) {
Test obj = (Test) o;
return i - obj.i;
}
public static void main(String[] args) {
SortedSet set = new TreeSet();
Test obj1 = new Test(1);
set.add(obj1);
Test obj2 = new Test(3);
set.add(obj2);
Test obj3 = new Test(2);
set.add(obj3);
Iterator iter = set.iterator();
System.out.println("Should print 1,2,3");
while (iter.hasNext()) {
Test obj = (Test) iter.next();
System.out.println(obj.i);
}
obj3.i = 4;
System.out.println("Order modified after insetion");
System.out.println("Should print 1,3,4");
iter = set.iterator();
while (iter.hasNext()) {
Test obj = (Test) iter.next();
System.out.println(obj.i);
}
System.out.println("...but it prints 1,4,3 keeping the order in which the object was inserted");
}
}
> 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
> Attachments: ContinuationsManagerImpl.java.patch
>
>
> 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 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 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.
[jira] Updated: (COCOON-2109) Incorrent cleanup of expired
continuations
Posted by "Miguel Cuervo (JIRA)" <ji...@apache.org>.
[ 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.