Re: [jira] Updated: (COCOON-2109) Incorrent cleanup of expired continuations

2008-04-10 Thread Grzegorz Kossakowski

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


[jira] Updated: (COCOON-2109) Incorrent cleanup of expired continuations

2008-03-30 Thread JIRA

 [ 
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] Updated: (COCOON-2109) Incorrent cleanup of expired continuations

2008-03-30 Thread JIRA

 [ 
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.



Re: [jira] Updated: (COCOON-2109) Incorrent cleanup of expired continuations

2008-03-30 Thread Joerg Heinicke

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

2007-08-10 Thread Miguel Cuervo (JIRA)

 [ 
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 

[jira] Updated: (COCOON-2109) Incorrent cleanup of expired continuations

2007-08-10 Thread Miguel Cuervo (JIRA)

 [ 
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, 

[jira] Updated: (COCOON-2109) Incorrent cleanup of expired continuations

2007-08-10 Thread Miguel Cuervo (JIRA)

 [ 
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.