[jira] Commented: (COCOON-2110) Evaluate expressions defined in cocooon-expression-language-api in Sitemap engine
[
https://issues.apache.org/jira/browse/COCOON-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519194
]
Jörg Heinicke commented on COCOON-2110:
---
Public vs. private API does not stand a second sight. Request.getSession() is
for sure accessed very often ...
> Evaluate expressions defined in cocooon-expression-language-api in Sitemap
> engine
> -
>
> Key: COCOON-2110
> URL: https://issues.apache.org/jira/browse/COCOON-2110
> Project: Cocoon
> Issue Type: New Feature
> Components: - Components: Sitemap, - Expression language
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Grzegorz Kossakowski
>Assignee: Grzegorz Kossakowski
> Fix For: 2.2-dev (Current SVN)
>
>
> Description of the task is relatively simple; all I want to achieve is to
> make possible following construct in sitemap:
>
>
>
> assuming that JXPath (used above) is default EL of choice. Of course one
> would be able to use following construct:
>
>value="${jexl:cocoon.request.some_param}"/>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [vote] Let our environment abtractions extend the http servlet ones
On 07.08.2007 3:46 Uhr, Daniel Fagerstrom wrote: Anyway, +1 for me to do it in 2.3. We can deprecate them now in 2.2. Unfortunately it is more complicated than that. You are right. I had deprecating our environment abstractions completely in mind. But when reading this I remembered some extensions for sitemap stuff you mentioned recently. Joerg
[jira] Commented: (COCOON-2110) Evaluate expressions defined in cocooon-expression-language-api in Sitemap engine
[
https://issues.apache.org/jira/browse/COCOON-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519193
]
Jörg Heinicke commented on COCOON-2110:
---
I neither can recall it. How this one came up, Grek? I'm in favor of it though.
Backward incompatible change itself seems not to be disqualifying, see the
discussion about the environment. One can argue with public vs. private API
here though ...
In this case it should be even possible to support the #{} expressions as well
and log some deprecation message. This would allow a change in 2.2.
Let's bring it back to dev list - even if it's only for the decision of
changing the start chars.
> Evaluate expressions defined in cocooon-expression-language-api in Sitemap
> engine
> -
>
> Key: COCOON-2110
> URL: https://issues.apache.org/jira/browse/COCOON-2110
> Project: Cocoon
> Issue Type: New Feature
> Components: - Components: Sitemap, - Expression language
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Grzegorz Kossakowski
>Assignee: Grzegorz Kossakowski
> Fix For: 2.2-dev (Current SVN)
>
>
> Description of the task is relatively simple; all I want to achieve is to
> make possible following construct in sitemap:
>
>
>
> assuming that JXPath (used above) is default EL of choice. Of course one
> would be able to use following construct:
>
>value="${jexl:cocoon.request.some_param}"/>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2110) Evaluate expressions defined in cocooon-expression-language-api in Sitemap engine
[
https://issues.apache.org/jira/browse/COCOON-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519191
]
Vadim Gritsenko commented on COCOON-2110:
-
I'm not sure I can recall this decision - to change the start char. First, it
is backward incompatible change, which means it can't be done in 2.2 - only in
2.3, if ever. And second, at this moment, in cforms samples alone, there are 56
#{foo} expressions or so. Dropping support for that would note be wise.
> Evaluate expressions defined in cocooon-expression-language-api in Sitemap
> engine
> -
>
> Key: COCOON-2110
> URL: https://issues.apache.org/jira/browse/COCOON-2110
> Project: Cocoon
> Issue Type: New Feature
> Components: - Components: Sitemap, - Expression language
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Grzegorz Kossakowski
>Assignee: Grzegorz Kossakowski
> Fix For: 2.2-dev (Current SVN)
>
>
> Description of the task is relatively simple; all I want to achieve is to
> make possible following construct in sitemap:
>
>
>
> assuming that JXPath (used above) is default EL of choice. Of course one
> would be able to use following construct:
>
>value="${jexl:cocoon.request.some_param}"/>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2110) Evaluate expressions defined in cocooon-expression-language-api in Sitemap engine
[
https://issues.apache.org/jira/browse/COCOON-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519186
]
Jörg Heinicke commented on COCOON-2110:
---
The start chars of the expression changes to ${ for all expression languages.
The expression language gets selected by the first part like "jexl" above. The
same applies to JXPath. It is only the default and therefore left out. That the
expression language itself might be different sounds reasonable. So I don't
think it's more different than before.
> Evaluate expressions defined in cocooon-expression-language-api in Sitemap
> engine
> -
>
> Key: COCOON-2110
> URL: https://issues.apache.org/jira/browse/COCOON-2110
> Project: Cocoon
> Issue Type: New Feature
> Components: - Components: Sitemap, - Expression language
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Grzegorz Kossakowski
>Assignee: Grzegorz Kossakowski
> Fix For: 2.2-dev (Current SVN)
>
>
> Description of the task is relatively simple; all I want to achieve is to
> make possible following construct in sitemap:
>
>
>
> assuming that JXPath (used above) is default EL of choice. Of course one
> would be able to use following construct:
>
>value="${jexl:cocoon.request.some_param}"/>
>
--
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-2110) Evaluate expressions defined in cocooon-expression-language-api in Sitemap engine
[
https://issues.apache.org/jira/browse/COCOON-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519186
]
[EMAIL PROTECTED] edited comment on COCOON-2110 at 8/10/07 7:24 PM:
The start chars of the expression changes to ${ for all expression languages.
The expression language gets selected by the first part like "jexl" above. The
same applies to JXPath. It is only the default and therefore left out. That the
expression language itself might be different sounds reasonable. So I don't
think it's more different than before - but yes, different than before of
course.
was (Author: [EMAIL PROTECTED]):
The start chars of the expression changes to ${ for all expression
languages. The expression language gets selected by the first part like "jexl"
above. The same applies to JXPath. It is only the default and therefore left
out. That the expression language itself might be different sounds reasonable.
So I don't think it's more different than before.
> Evaluate expressions defined in cocooon-expression-language-api in Sitemap
> engine
> -
>
> Key: COCOON-2110
> URL: https://issues.apache.org/jira/browse/COCOON-2110
> Project: Cocoon
> Issue Type: New Feature
> Components: - Components: Sitemap, - Expression language
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Grzegorz Kossakowski
>Assignee: Grzegorz Kossakowski
> Fix For: 2.2-dev (Current SVN)
>
>
> Description of the task is relatively simple; all I want to achieve is to
> make possible following construct in sitemap:
>
>
>
> assuming that JXPath (used above) is default EL of choice. Of course one
> would be able to use following construct:
>
>value="${jexl:cocoon.request.some_param}"/>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2110) Evaluate expressions defined in cocooon-expression-language-api in Sitemap engine
[
https://issues.apache.org/jira/browse/COCOON-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519184
]
Vadim Gritsenko commented on COCOON-2110:
-
Don't we have a history of using #{foo} for jxpath and ${foo} for jexl? Doing
it differently would just result in more confusion. I'd rather have it more
uniform throughout.
> Evaluate expressions defined in cocooon-expression-language-api in Sitemap
> engine
> -
>
> Key: COCOON-2110
> URL: https://issues.apache.org/jira/browse/COCOON-2110
> Project: Cocoon
> Issue Type: New Feature
> Components: - Components: Sitemap, - Expression language
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Grzegorz Kossakowski
>Assignee: Grzegorz Kossakowski
> Fix For: 2.2-dev (Current SVN)
>
>
> Description of the task is relatively simple; all I want to achieve is to
> make possible following construct in sitemap:
>
>
>
> assuming that JXPath (used above) is default EL of choice. Of course one
> would be able to use following construct:
>
>value="${jexl:cocoon.request.some_param}"/>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2108) xmodule:flow-attr Does not accept document objects
[ https://issues.apache.org/jira/browse/COCOON-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519180 ] Jörg Heinicke commented on COCOON-2108: --- Hugh, did you try text()? If JXPath has implemented the function (and I think so) it should work. I think we only pass the expression directly to JXPath. > xmodule:flow-attr Does not accept document objects > -- > > Key: COCOON-2108 > URL: https://issues.apache.org/jira/browse/COCOON-2108 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core >Affects Versions: 2.1.11-dev (Current SVN) >Reporter: Hugh Sparks >Priority: Minor > Attachments: xmodulePuzzle.txt > > > Sending document objects from flowscript back to the pipeline using > xmodule:flow-attr produces unexpected results. Also, the examples from > the documentation do not work as described: > http://cocoon.apache.org/2.1/861.daisy.html > The most common error reported is: > 'The object type: class java.lang.String could not be serialized to XML" > This issue was discussed recently on the cocoon-users mailing list. > The thread was introduced by Kazo Csaba with the subject "Sending DOM from > flowscript to pipeline." > (July 17, 2007) > He has attempted to trace this behavior in the source code and believes that a > possibly-inappropriate conversion to string occurs in some cases. > Jason Johnston suggested moving the issue to JIRA. > I've created a demonstration of this apparent bug and some related problems > in this very brief example: > http://www.csparks.com/xmodulePuzzle.txt > I hope someone can fix or explain the correct usage of xmodule:flow-attr. > Thanks to all, > -Hugh Sparks, [EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2108) xmodule:flow-attr Does not accept document objects
[ https://issues.apache.org/jira/browse/COCOON-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519156 ] Grzegorz Kossakowski commented on COCOON-2108: -- After taking quick look at[1] we can see following statement: The intepretation of XPath over DOM/JDOM structures is implemented in accordance with the XPath specification. Since XPath defines text() function it should work perfectly. I think this direction is surely worth trying. Thanks Hugh for your great research! [1] http://commons.apache.org/jxpath/users-guide.html#DOM_JDOM_Document_Access > xmodule:flow-attr Does not accept document objects > -- > > Key: COCOON-2108 > URL: https://issues.apache.org/jira/browse/COCOON-2108 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core >Affects Versions: 2.1.11-dev (Current SVN) >Reporter: Hugh Sparks >Priority: Minor > Attachments: xmodulePuzzle.txt > > > Sending document objects from flowscript back to the pipeline using > xmodule:flow-attr produces unexpected results. Also, the examples from > the documentation do not work as described: > http://cocoon.apache.org/2.1/861.daisy.html > The most common error reported is: > 'The object type: class java.lang.String could not be serialized to XML" > This issue was discussed recently on the cocoon-users mailing list. > The thread was introduced by Kazo Csaba with the subject "Sending DOM from > flowscript to pipeline." > (July 17, 2007) > He has attempted to trace this behavior in the source code and believes that a > possibly-inappropriate conversion to string occurs in some cases. > Jason Johnston suggested moving the issue to JIRA. > I've created a demonstration of this apparent bug and some related problems > in this very brief example: > http://www.csparks.com/xmodulePuzzle.txt > I hope someone can fix or explain the correct usage of xmodule:flow-attr. > Thanks to all, > -Hugh Sparks, [EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2108) xmodule:flow-attr Does not accept document objects
[ https://issues.apache.org/jira/browse/COCOON-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519151 ] Hugh Sparks commented on COCOON-2108: - I tried the fix suggested by Csaba Kazó and it made all the test cases in xmodulePuzzles.txt work as expected. Now the question becomes, "what else is broken if this fix is left in place"? (I tried to find some jxpath usage in the Samples, but without success.) One possible motive for using getValue() in the original code was to make it possible to get the actual string values of an jxpath expression. Recall the xmodule allows a path to be appended: For the xml: This is a testof xmodule The expression: xmodule:flow-attr:message#test/inside Gives this result if we use Csaba Kazó's fix: a test Because the text() function is missing from Cocoon's jxpath, there is no way to recover the text inside using an xmodule expression in the sitemap. It seems to me that a possible solution would be to use Kazó's suggested change, but add the text() function to jxpath so this expression would return the contents of the element: xmodule:flow-attr:message#test/inside/text() = "a test" Is jxpath supposed to have a text() function? > xmodule:flow-attr Does not accept document objects > -- > > Key: COCOON-2108 > URL: https://issues.apache.org/jira/browse/COCOON-2108 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core >Affects Versions: 2.1.11-dev (Current SVN) >Reporter: Hugh Sparks >Priority: Minor > Attachments: xmodulePuzzle.txt > > > Sending document objects from flowscript back to the pipeline using > xmodule:flow-attr produces unexpected results. Also, the examples from > the documentation do not work as described: > http://cocoon.apache.org/2.1/861.daisy.html > The most common error reported is: > 'The object type: class java.lang.String could not be serialized to XML" > This issue was discussed recently on the cocoon-users mailing list. > The thread was introduced by Kazo Csaba with the subject "Sending DOM from > flowscript to pipeline." > (July 17, 2007) > He has attempted to trace this behavior in the source code and believes that a > possibly-inappropriate conversion to string occurs in some cases. > Jason Johnston suggested moving the issue to JIRA. > I've created a demonstration of this apparent bug and some related problems > in this very brief example: > http://www.csparks.com/xmodulePuzzle.txt > I hope someone can fix or explain the correct usage of xmodule:flow-attr. > Thanks to all, > -Hugh Sparks, [EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2110) Evaluate expressions defined in cocooon-expression-language-api in Sitemap engine
Evaluate expressions defined in cocooon-expression-language-api in Sitemap engine - Key: COCOON-2110 URL: https://issues.apache.org/jira/browse/COCOON-2110 Project: Cocoon Issue Type: New Feature Components: - Components: Sitemap, - Expression language Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Assignee: Grzegorz Kossakowski Fix For: 2.2-dev (Current SVN) Description of the task is relatively simple; all I want to achieve is to make possible following construct in sitemap: assuming that JXPath (used above) is default EL of choice. Of course one would be able to use following construct: -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2086) Invent API for Object Model and use it in template block
[ https://issues.apache.org/jira/browse/COCOON-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-2086. Resolution: Fixed It seems that basic API for Object Model has been invented and is quite stable. Further modifications will be covered by new issues. Also, new Object Model API is fully used in template block. Closing the issue. > Invent API for Object Model and use it in template block > > > Key: COCOON-2086 > URL: https://issues.apache.org/jira/browse/COCOON-2086 > Project: Cocoon > Issue Type: Sub-task > Components: - Expression language, Blocks: Templating >Affects Versions: 2.2-dev (Current SVN) >Reporter: Grzegorz Kossakowski >Assignee: Grzegorz Kossakowski > Fix For: 2.2-dev (Current SVN) > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2103) Replace Initialization of Object Model by helper classes with more solid mechanisms
[ https://issues.apache.org/jira/browse/COCOON-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-2103. Resolution: Fixed The goals of this issue has been almost achieved. One remaining task is to put parameters in ObjectModel outside pipeline component, probably in sitemap/pipeline implementation. That was described in this message: http://article.gmane.org/gmane.text.xml.cocoon.devel/74479 This task will be covered by another issue so I can safely close this one. > Replace Initialization of Object Model by helper classes with more solid > mechanisms > --- > > Key: COCOON-2103 > URL: https://issues.apache.org/jira/browse/COCOON-2103 > Project: Cocoon > Issue Type: Sub-task > Components: * Cocoon Core, - Expression language, Blocks: Templating >Affects Versions: 2.2-dev (Current SVN) >Reporter: Grzegorz Kossakowski >Assignee: Grzegorz Kossakowski > Fix For: 2.2-dev (Current SVN) > > > Currently initialization of Object Model is spread on various helper classes > like: > * org.apache.cocoon.template.environment.FlowObjectModelHelper > * org.apache.cocoon.environment.TemplateObjectModelHelper > that use some static methods and variables. > I'm going to slim down these (and other) classes to absolute minimum or > remove them completely in the end. > Most initialization will be moved to ObjectModel providers classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[vote result] Let our environment abtractions extend the http servlet ones
Daniel Fagerstrom skrev: I would like o.a.c.environment.[Request|Response|Session] to extend javax.servlet.http.Http[ServletRequest|ServletResponse|Session] respectively. ... I don't want this to collide with releasing 2.2, so I'll wait with introducing the changes if there is any risk for that. Results: * +1 votes from Reinhard, Grzegorz, Jorg and me * +1 votes for doing it in C2.2 with a detailed proposal about how to handle deprecation (http://marc.info/?l=xml-cocoon-dev&m=118651217532624&w=2) from Alfred and Vadim * +1 votes for doing it in C2.3 from Felix and Joerg It is not completely obvious what to do from this. But given that we handle deprecation according to Alfred's proposal, 6 persons voted for my original proposal of doing the changes in 2.2 (given that it is not interfering with the release) and no one voted against it. As no one has volunteered to do the release until mid September, it will not interfere with the release. So I will implement my proposal with Alfred's deprecation scheme in the beginning of next week. /Daniel
[jira] Commented: (COCOON-2109) Incorrent cleanup of expired continuations
[
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] Commented: (COCOON-2109) Incorrent cleanup of expired continuations
[ 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] Commented: (COCOON-2109) Incorrent cleanup of expired continuations
[ 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
[ 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] Issue Comment Edited: (COCOON-2109) Incorrent cleanup of expired continuations
[ 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
[ 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] Commented: (COCOON-2109) Incorrent cleanup of expired continuations
[ 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
[ 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] Updated: (COCOON-2109) Incorrent cleanup of expired continuations
[ 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 t
[jira] Updated: (COCOON-2109) Incorrent cleanup of expired continuations
[ 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.
Re: [GT2007] Request for papers
Hi, On 8 Aug 2007, at 22:03, Gianugo Rabellino wrote: Please take a look at the below list of ideas and see if there's one or more subjects that you would like to talk about. Talks on different subjects are most definitely welcome! The list below is only there as a guideline to help you in finding a good subject, not to limit your originality. Hmm, the list of ideas somehow got eaten by the mail daemons, so here's the suggestions from last year. Anyone care to add anything? Ideas for talks --- Here's the (long!) list of subjects for sessions that we all came up with: - Success stories (why someone chose Cocoon, for what, what was great and what not?) - Comparison of Cocoon with other web frameworks - Why should I upgrade to 2.2? - A "meet the Cocoon devs" session at the hackaton for users. This session should be moderated and the topics come from the participating non-committers. - Perspectives of the portal block, relations to other Apache portal projects - Some shorter, flashier presentations of what you can achieve with Cocoon, right from the core developers - A session with "kowledge flashes", 5 to 10 minutes per subject - A "guided tour" through Cocoon where Reinhard interviewed Carsten and Sylvain about the internals - Some demos of actual Cocoon sites, with explanations of why, how, etc - Optimisation techniques, (efficient, performant Cocoon) across the whole lifecycle of an application - The secret gems of Cocoon (what do people not know about that is really cool) - Interactive apps, authentication, user tuned content - How to get involved (find out what the community needs from contributers) - Some sessions that focus on technologies that are often used together with Cocoon, with Guru's: - Maven 2 - Spring 2 - FOP 0.92 - Cocoon and Web Services/SOA - Lepido - Some howto's / best practices for - Configuration - Using Spring - Building Cocoon - 10 Reasons to use Cocoon - A "What's new in 2.2 and how to use it track" with different topics, 5 to 10min per topic. - What's up for Cocoon 3.0? - The Funky Cocoon AJAX tour (with lots of samples!) - A session like "moving from xsp and sitemap actions to flowscript and jxtemplate" to introduce existing users to the latest Cocoon techniques and guide them in upgrading their older bits of code - A short (!!) introduction to OSGi (what's all that fuzz about?!) - Best practice + case studies for cocoon based Intranet Portals - Integration of Cocoon and Open Source Workflow Servers, Cocoon based Workflow applications in general - Cocoon Forms: "meta form application" (let the users create form based applications by assembling cocoon forms with the help of CF) - Short, practical case studies: high-level architecture, integrating Cocoon, etc. - How to NOT get lost in Cocoon technologies: flow, binding, xsp, jxtemplate, cforms, authentication, portal, etc. - How does Cocoon provide login, authorization, menu, form processing, templating, integration with backends (database)? - How to create a "typical" project with cocoon, regarding sitemap hierarchy and organization, class model, deployment, artifacts, where do flows scripts must go, etc? - Case studies showing large web applications - Cocoon for 'non-java' professionals and Cocoon project management - What is the required knowledge in order to hire a professional that should work in a cocoon project? - Does separation of concerns work in a real world situation? - Reducing risk when building large projects with large teams - How to tweak Cocoon for performance - Real numbers on cocoon performance, real hardware and real deployment topology (load balancing, session replication) - A caching tour. How can I use caching effectively and what can I cache - Measuring performance. How can I know at what speed my cocoon site is running? - The Cocoon toolset: tools that can help shorten development time / tools for testing / monitoring And a final note from Bertrand: "Talking to community members, I get a feeling that we're using Cocoon in wildly different ways, and I think it's one of its major strengths - let's show this at the GT!" Thanks, Andrew. -- Sourcesense: Making sense of Open Source Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.sourcesense.com/
[jira] Updated: (COCOON-2109) Incorrent cleanup of expired continuations
[ 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 lo
[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.
