date:20080330


On 20.02.2008 01:42, [EMAIL PROTECTED] wrote:


Author: antonio
Date: Tue Feb 19 22:42:45 2008
New Revision: 629374

URL: http://svn.apache.org/viewvc?rev=629374view=rev
Log:
Faster implementation.


Saw this one only now ... I'm a bit concerned about the approach.

First, do you really think this implementation is significantly faster? 
Your implementation only caches the parser instance, you replace the 
instantiation with ThreadLocal handling. Parsing itself should still be 
the slowest part. How many Strings do you convert to SAX per thread? 
Second, who cleans up the thread before it goes back to the thread pool?


At the end is it really worth the ugly implementation?

IMO it's a much better approach to make it a real Cocoon component 
(Serializeable) instead and look up the SAXParser.


Joerg


Modified:

cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/xml/StringXMLizable.java

Modified: 
cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/xml/StringXMLizable.java
URL: 
http://svn.apache.org/viewvc/cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/xml/StringXMLizable.java?rev=629374r1=629373r2=629374view=diff
==
--- 
cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/xml/StringXMLizable.java
 (original)
+++ 
cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/xml/StringXMLizable.java
 Tue Feb 19 22:42:45 2008
@@ -5,9 +5,9 @@
  * The ASF licenses this file to You under the Apache License, Version 2.0
  * (the License); you may not use this file except in compliance with
  * the License.  You may obtain a copy of the License at
- * 
+ *

  *  http://www.apache.org/licenses/LICENSE-2.0
- * 
+ *

  * Unless required by applicable law or agreed to in writing, software
  * distributed under the License is distributed on an AS IS BASIS,
  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
@@ -29,25 +29,40 @@
 
 /**

  * XMLizable a String
- * 
+ *

  * @since 2.1.7
  */
 public class StringXMLizable implements XMLizable {
+private static class Context {
+SAXParser parser;
+Context() throws SAXException {
+SAXParserFactory parserFactory = SAXParserFactory.newInstance();
+parserFactory.setNamespaceAware(true);
+parser = null;
+try {
+parser = parserFactory.newSAXParser();
+} catch (ParserConfigurationException e) {
+throw new SAXException(Error creating SAX parser., e);
+}
+}
+}
+
+private static final ThreadLocal context = new ThreadLocal();
 private String data;
 
-public StringXMLizable(String data) {

+public StringXMLizable(final String data) {
 this.data = data;
 }
 
-public void toSAX(ContentHandler contentHandler) throws SAXException {

-SAXParserFactory parserFactory = SAXParserFactory.newInstance();
-parserFactory.setNamespaceAware(true);
-SAXParser parser = null;
-try {
-parser = parserFactory.newSAXParser();
-} catch (ParserConfigurationException e) {
-throw new SAXException(Error creating SAX parser., e);
+private Context getContext() throws SAXException {
+if (context.get() == null) {
+context.set(new Context());
 }
+return (Context) context.get();
+}
+
+public void toSAX(ContentHandler contentHandler) throws SAXException {
+final SAXParser parser = getContext().parser;
 parser.getXMLReader().setContentHandler(contentHandler);
 InputSource is = new InputSource(new StringReader(data));
 try {

Re: Javaflow - major memory issue


On 28.03.2008 04:55, Torsten Curdt wrote:

The output I showed pointed to 
org.apache.cocoon.components.flow.java.Continuation which only seems 
to exist in Cocoon 2.1. Nothing unsets the context there.


Hah - well spotted!

Having a look into the code continuations are only handled by 
JavaInterpreter. There are two methods callFunction(..) and 
handleContinuation(..) calling Continuation.registerThread() and 
deregisterThread() in a finally block. From a brief look I have no 
idea if I can just unset the ContinuationContext there as well. You 
might know more about it.


We should add a try/finally block in Continuation.suspend() that clears 
the context after a suspend. That should fix it.


Unfortunately, it is not possible to unset the ContinuationContext 
completely. It's needed in JavaInterpreter.handleContinuation(..) when a 
child continuation is created:


  Continuation parentContinuation =
  (Continuation) parentwk.getContinuation();
  ContinuationContext parentContext =
  (ContinuationContext) parentContinuation.getContext();
  ContinuationContext context = new ContinuationContext();
  context.setObject(parentContext.getObject());
  context.setMethod(parentContext.getMethod());

Without completely rewriting it the only thing I did was to remove the 
data in the ContinuationContext that is not necessary. I do this by an 
extra call to ContinuationContext.onSuspend() in AbstractContinuable 
since Continuation is not aware of the implementation of its context 
(it's just an Object).


Please review my changes [1] because I'm not really sure about them. 
They work for the normal case, but what happens in an error case? I 
can't see what's really going on except that the method is left on 
Continuation.suspend() ... It was very interesting to debug it when 
AbstractContinuable.sendPageAndWait(..) was actually hit twice.


I guess this handling is different in 2.2. There a clean 
ContinuationContext is created on both callFunction(..) and 
handleContinuation(..).


Joerg

[1] http://svn.apache.org/viewvc?rev=642694view=rev

GSoC Proposal review

2008-03-30 Thread Lukas Lang


hey,

my proposal is based on the ideas some of you had (thanks to everybody!).

i would be glad if someone kindly would review my proposal available at:

http://wiki.apache.org/general/SummerOfCode2008/CocoonBlockSpringificationCaseExamples

regards,
lukas

Re: Javaflow - major memory issue

2008-03-30 Thread Torsten Curdt



On Mar 30, 2008, at 09:43, Joerg Heinicke wrote:

On 28.03.2008 04:55, Torsten Curdt wrote:

The output I showed pointed to  
org.apache.cocoon.components.flow.java.Continuation which only  
seems to exist in Cocoon 2.1. Nothing unsets the context there.

Hah - well spotted!
Having a look into the code continuations are only handled by  
JavaInterpreter. There are two methods callFunction(..) and  
handleContinuation(..) calling Continuation.registerThread() and  
deregisterThread() in a finally block. From a brief look I have no  
idea if I can just unset the ContinuationContext there as well.  
You might know more about it.
We should add a try/finally block in Continuation.suspend() that  
clears the context after a suspend. That should fix it.


Unfortunately, it is not possible to unset the ContinuationContext  
completely. It's needed in JavaInterpreter.handleContinuation(..)  
when a child continuation is created:


 Continuation parentContinuation =
 (Continuation) parentwk.getContinuation();
 ContinuationContext parentContext =
 (ContinuationContext) parentContinuation.getContext();
 ContinuationContext context = new ContinuationContext();
 context.setObject(parentContext.getObject());
 context.setMethod(parentContext.getMethod());


There is no need to really obtain that value from the parent. If  
handleContinuation would have also the function parameter it could use  
the same initialization as in callFuntion. Actually a way of fixing  
this would be to add two Strings to the Continuation class. One  
holding the classname, the other holding the method name. And then do


context.setObject(userScopes.get(parentContinuation.getScopeName()));
context.setMethod(methods.get(parentContinuation.getFunctionName()));

in handleContinuation. Then the cleaning of the context should be fine.

Without completely rewriting it the only thing I did was to remove  
the data in the ContinuationContext that is not necessary. I do this  
by an extra call to ContinuationContext.onSuspend() in  
AbstractContinuable since Continuation is not aware of the  
implementation of its context (it's just an Object).


Please review my changes [1] because I'm not really sure about them.


Not a fan of the Collections.synchronizedMap(new HashMap()) change -  
but other than that they look OK on the first glance :)


They work for the normal case, but what happens in an error case? I  
can't see what's really going on except that the method is left on  
Continuation.suspend() ... It was very interesting to debug it when  
AbstractContinuable.sendPageAndWait(..) was actually hit twice.


:) ...what error case do you mean?

I guess this handling is different in 2.2. There a clean  
ContinuationContext is created on both callFunction(..) and  
handleContinuation(..).


Indeed ...that would be another fix ...porting it from 2.2 :)

Thanks for looking into that.

cheers
--
Torsten

Re: Meeting in Amsterdam

2008-03-30 Thread Reinhard Poetz


Grzegorz Kossakowski wrote:

Reinhard Poetz pisze:


Is there anybody who is going to attend the ApacheCon in Amsterdam? 
I'll be there at the two Hackathon days (Mon full day, Tue till 3pm) 
and would love to have some discussions about Corona.


What about a meeting on Monday 2pm at the official Hackathon room? 
(Though I don't know if this conflicts with other community events 
Sling/Jackrabbit/Wicket/... Could people involved with these 
communities clearify?)


Standard question: Is there any chance to set up some audio/video 
recording? I would be very, very interested in hearing/watching such a 
record.


Don't think of some formalized event. It will rather be some folks discussing 
Cocoon related issues in a relaxed environment.


Anyway, I will report to this list, what we have been discussing.

--
Reinhard PötzManaging Director, {Indoqa} GmbH
  http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_

Re: [jira] Updated: (COCOON-2188) mvn install -P allblocks fails

2008-03-30 Thread Reinhard Poetz

Argh, any chance to make Continuum find this problems instead of Andreas? Wasn't 
there some way to delete all org.apache.cocoon:* artifacts from the local 
Continuum repository as part of integration build?


Andreas Kuckartz (JIRA) wrote:

 [ 
https://issues.apache.org/jira/browse/COCOON-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Kuckartz updated COCOON-2188:
-

Component/s: Blocks: Ajax


mvn install -P allblocks fails


Key: COCOON-2188
URL: https://issues.apache.org/jira/browse/COCOON-2188
Project: Cocoon
 Issue Type: Bug
 Components: - Build System: Maven, Blocks: Ajax
   Affects Versions: 2.2-dev (Current SVN)
   Reporter: Andreas Kuckartz
   Priority: Blocker
Fix For: 2.2-dev (Current SVN)


[INFO] Building Cocoon Ajax Block Implementation
[INFO]task-segment: [install]
[INFO] 
[INFO] [enforcer:enforce-once {execution: enforce-maven}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] snapshot 
org.apache.cocoon:cocoon-servlet-service-components:1.0.0-RC2-SNAPSHOT: 
checking for updates from apache.snapshots
Downloading: 
http://people.apache.org/repo/m2-snapshot-repository/org/apache/cocoon/cocoon-servlet-service-components/1.0.0-RC2-SNAPSHOT/cocoon-servlet-service-components-1.0.0-RC2-SNAPSHOT.pom
Downloading: 
http://people.apache.org/repo/m2-snapshot-repository/org/apache/cocoon/cocoon-servlet-service-components/1.0.0-RC2-SNAPSHOT/cocoon-servlet-service-components-1.0.0-RC2-SNAPSHOT.jar
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Failed to resolve artifact.
Missing:
--
1) org.apache.cocoon:cocoon-servlet-service-components:jar:1.0.0-RC2-SNAPSHOT
  Try downloading the file manually from the project website.
  Then, install it using the command: 
  mvn install:install-file -DgroupId=org.apache.cocoon -DartifactId=cocoon-servlet-service-components -Dversion=1.0.0-RC2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file
  Alternatively, if you host your own repository you can deploy the file there: 
  mvn deploy:deploy-file -DgroupId=org.apache.cocoon -DartifactId=cocoon-servlet-service-components -Dversion=1.0.0-RC2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
  Path to dependency: 
  	1) org.apache.cocoon:cocoon-ajax-impl:jar:1.1.0-SNAPSHOT

2) 
org.apache.cocoon:cocoon-servlet-service-components:jar:1.0.0-RC2-SNAPSHOT
--
1 required artifact is missing.
for artifact: 
  org.apache.cocoon:cocoon-ajax-impl:jar:1.1.0-SNAPSHOT

from the specified remote repositories:
  apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository),
  central (http://repo1.maven.org/maven2)





--
Reinhard PötzManaging Director, {Indoqa} GmbH
  http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_

Re: [GSoC_2008] Project ideas

2008-03-30 Thread Reinhard Poetz


Grzegorz Kossakowski wrote:

Vadim Gritsenko pisze:

On Mar 17, 2008, at 11:30 AM, Grzegorz Kossakowski wrote:


Reinhard Poetz pisze:
My statement was meant to be more general (SSF + Spring migration + 
Schema support).
For an SSF project only, I don't see enough work (I only know about 
SAX buffering and support for redirects as missing features) ... but 
maybe I'm wrong here.


There is not that much work left in pure SSF 
(cocoon-servlet-service-impl module) but there is still a room for 
improvement in module containing components integrating SSF and 
Cocoon (cocoon-servlet-service-components). Mentioned SAX buffer 
support involves modifications in impl and components modules.


I would add to the list of nice-to-have-in-SSF servlet discovery 
feature based on some conditions (e.g. returning 200 status code as 
response to certain request path). This way one could discover blocks 
providing certain services (e.g. skinning).


Nothing more comes to my mind right now.


  $ find 
cocoon/core/cocoon-servlet-service/cocoon-servlet-service-impl -name 
*.java | xargs grep TODO | wc -l

  18

I'm not so sure that this is not much :)


Vadim, you forgot about FIXME marks ;)

find core/cocoon-servlet-service/cocoon-servlet-service-impl -name 
*.java | xargs grep -E TODO|FIXME | wc -l

27


I've been considering participation in GSoC for some time due to my 
tottering planes for summer.



Now I'm pretty sure I'll be able to do some Cocoon-related work again 
this year. I would like to focus on fixing bugs, implementing lacking 
features and general polishing SSF.


My goals would be:
  * get rid of most FIXME/TODO marks in SSF code
  * implement SAX buffering for service calls
  * fix COCOON-1964:  Redirects inside a block called via the servlet 
protocol fail

  * fix COCOON-2096:  Servlet source's exists() method always returns true
  * provide samples of SSF usage for both situations:
- servlets managed by SSF are pure servlets that have nothing to do 
with Cocoon itself

- servlets are both pure servlets or SitemapServlets


For samples I would like to prepare examples how to connect, call 
servlets. How to make service calls, make use of polymorphism, etc.


I'm not sure, but isn't there some open issue with multi-part mimes handling? 
Apart from this, the list seems to be complete.




  --- o0o ---


Apart from that I have an idea of making Cocoon blocks/servlets 
distributed and enabling SSF to transparently handle such set up. I 
think it would be very interesting to have a possibility to deploy 
different servlets to different physical machines and let them talk to 
eacher other using HTTP.


Actually, current implementation of servlet-to-servlet connections 
exploits only standard HTTP API so this should be quite easy to 
implement. That would enable completely new-brand SSF usage patterns like:


  * setting up load balancer between blocks (servlets) provided there 
are few machines with the same block deployed
  * setting up fail-over handling (if one of machines goes down, rest 
takes the processing)
  * exceptional scalability: if one of blocks is being used extensively, 
you can add another machine with this block deployed and make load 
balancer aware of it

  * even block (servlets) calls through the Internet! :-)


This should be considered as an optional deliverable for my GSoC 
activity as it would demand lots of discussing, researching and 
implementing in the end. Nevertheless, if time permits I would like to 
start experiment with this idea during the summer.


Definitly and interesting topic and making it an optional deliveralbe is a good 
idea.


--
Reinhard PötzManaging Director, {Indoqa} GmbH
  http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_

[jira] Created: (COCOON-2190) Add caching to corona

Add caching  to corona
--

 Key: COCOON-2190
 URL: https://issues.apache.org/jira/browse/COCOON-2190
 Project: Cocoon
  Issue Type: New Feature
  Components: * Cocoon Core
Reporter: Steven Dolg




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

[jira] Updated: (COCOON-2190) Add caching to corona


 [ 
https://issues.apache.org/jira/browse/COCOON-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steven Dolg updated COCOON-2190:


Attachment: caching.txt

A patch adding very simple caching to the CachingPipeline.
Caching of complete pipeline results, if and only if all components of the 
pipeline support caching.

Integration of a real cache provider (e.g. ehcache) is still missing.


 Add caching  to corona
 --

 Key: COCOON-2190
 URL: https://issues.apache.org/jira/browse/COCOON-2190
 Project: Cocoon
  Issue Type: New Feature
  Components: * Cocoon Core
Reporter: Steven Dolg
 Attachments: caching.txt




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

Re: Javaflow - major memory issue


On 30.03.2008 07:35, Torsten Curdt wrote:

There is no need to really obtain that value from the parent. If 
handleContinuation would have also the function parameter it could use 
the same initialization as in callFuntion.


Yes, if the function name would have been available ... This was beyond 
what I wanted to do. But since you confirmed it now I risked this change.


Actually a way of fixing this 
would be to add two Strings to the Continuation class. One holding the 
classname, the other holding the method name. And then do


context.setObject(userScopes.get(parentContinuation.getScopeName()));
context.setMethod(methods.get(parentContinuation.getFunctionName()));


The scopes are by Class. Therefore I only stored the function name and 
retrieved the method.



in handleContinuation. Then the cleaning of the context should be fine.


Yes, it's better now.

Without completely rewriting it the only thing I did was to remove the 
data in the ContinuationContext that is not necessary. I do this by an 
extra call to ContinuationContext.onSuspend() in AbstractContinuable 
since Continuation is not aware of the implementation of its context 
(it's just an Object).


Please review my changes [1] because I'm not really sure about them.


Not a fan of the Collections.synchronizedMap(new HashMap()) change - but 


Just curious, any reason for this? Is it not as optimized?


other than that they look OK on the first glance :)

They work for the normal case, but what happens in an error case? I 
can't see what's really going on except that the method is left on 
Continuation.suspend() ... It was very interesting to debug it when 
AbstractContinuable.sendPageAndWait(..) was actually hit twice.


:) ...what error case do you mean?


Not sure, originally you proposed to put it into a try finally block.

I guess this handling is different in 2.2. There a clean 
ContinuationContext is created on both callFunction(..) and 
handleContinuation(..).


Indeed ...that would be another fix ...porting it from 2.2 :)


That's really beyond what I want to do ;-) Let's leave the good stuff 
for 2.2.



Thanks for looking into that.


It was really interesting to see how a Java method is cut into two 
pieces. Suddenly the debugger stops stepping, but just leaves the 
methods. And on the next call it just jumps to the appropriate places in 
the code. Once you get used to it it's easy to debug. I have never tried 
it before but now I like it better than flowscript.


Joerg

Re: Javaflow - major memory issue

2008-03-30 Thread Torsten Curdt

Without completely rewriting it the only thing I did was to remove  
the data in the ContinuationContext that is not necessary. I do  
this by an extra call to ContinuationContext.onSuspend() in  
AbstractContinuable since Continuation is not aware of the  
implementation of its context (it's just an Object).


Please review my changes [1] because I'm not really sure about them.
Not a fan of the Collections.synchronizedMap(new HashMap()) change  
- but


Just curious, any reason for this? Is it not as optimized?


Well, of course you pay a runtime penalty for another method  
invocation unless the hotspots is able to optimize that away. Not  
sure.


But it's less about optimization - more about keeping the  
synchronization more visible. But as long as the access to the hashmap  
is simple like it is right now I would not argue about it :)



other than that they look OK on the first glance :)
They work for the normal case, but what happens in an error case?  
I can't see what's really going on except that the method is left  
on Continuation.suspend() ... It was very interesting to debug it  
when AbstractContinuable.sendPageAndWait(..) was actually hit twice.

:) ...what error case do you mean?


Not sure, originally you proposed to put it into a try finally block.


Just to have it as post condition. You never know.

I guess this handling is different in 2.2. There a clean  
ContinuationContext is created on both callFunction(..) and  
handleContinuation(..).

Indeed ...that would be another fix ...porting it from 2.2 :)


That's really beyond what I want to do ;-) Let's leave the good  
stuff for 2.2.


+1


Thanks for looking into that.


It was really interesting to see how a Java method is cut into two  
pieces. Suddenly the debugger stops stepping, but just leaves the  
methods. And on the next call it just jumps to the appropriate  
places in the code. Once you get used to it it's easy to debug. I  
have never tried it before but now I like it better than flowscript.


Yeah, it's interesting isn't it? :)

cheers
--
Torsten

[jira] Updated: (COCOON-2190) Add caching to corona


 [ 
https://issues.apache.org/jira/browse/COCOON-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steven Dolg updated COCOON-2190:


Attachment: caching.txt

Just realized I uploaded an incomplete patch...

 Add caching  to corona
 --

 Key: COCOON-2190
 URL: https://issues.apache.org/jira/browse/COCOON-2190
 Project: Cocoon
  Issue Type: New Feature
  Components: * Cocoon Core
Reporter: Steven Dolg
 Attachments: caching.txt




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

[jira] Updated: (COCOON-2190) Add caching to corona


 [ 
https://issues.apache.org/jira/browse/COCOON-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steven Dolg updated COCOON-2190:


Attachment: (was: caching.txt)

 Add caching  to corona
 --

 Key: COCOON-2190
 URL: https://issues.apache.org/jira/browse/COCOON-2190
 Project: Cocoon
  Issue Type: New Feature
  Components: * Cocoon Core
Reporter: Steven Dolg
 Attachments: caching.txt




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

Re: GSoC Proposal review

2008-03-30 Thread Grzegorz Kossakowski


Lukas Lang pisze:

hey,

my proposal is based on the ideas some of you had (thanks to everybody!).

i would be glad if someone kindly would review my proposal available at:

http://wiki.apache.org/general/SummerOfCode2008/CocoonBlockSpringificationCaseExamples 


All I can say: looks good. Nothing obvious to improve. I think it's fine to 
apply it in this form.


--
Grzegorz Kossakowski

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

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

[
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

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

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

Attachments: ContinuationsManagerImpl.java.patch

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


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

[
https://issues.apache.org/jira/browse/COCOON-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
--

Attachments: ContinuationsManagerImpl.java.patch

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

Re: svn commit: r642855 - /cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/components/flow/ContinuationsManagerImpl.java


On 30.03.2008 22:19, [EMAIL PROTECTED] wrote:


Author: joerg
Date: Sun Mar 30 19:19:41 2008
New Revision: 642855

URL: http://svn.apache.org/viewvc?rev=642855view=rev
Log:
fix synchronization


Can you please review this [1]? It's too easy to mess this up ... I hope 
I did not introduce any deadlock.


One thing I came across and did not like is the maintenance of the Set 
forest which is according to Javadoc only done for debugging reason, 
on the other hand exposed even via the interface. I would rather clean 
up the interface and remove the following 2 methods:


/**
 * Prints debug information about all web continuations into the log file.
 * @see WebContinuation#display()
 */
public void displayAllContinuations();

/**
 * Get a list of all continuations as 
codeWebContinuationDataBean/code objects.

 */
public List getWebContinuationsDataBeanList();

At the moment it's only needed for StatusGenerator. We can therefore add 
another method getContinuations() which only returns a clone of the 
continuations. Also we should not maintain forest, but just reuse the 
Set expirations. We should be able to reconstruct everything else on 
demand.


The current interface makes the implementation overly complex. In 2.1 it 
is even worse due to maintenance of Instrumentable variables.


WDYT? If we don't want to remove the 2 methods for compatibility reasons 
we can deprecate them and change the implementation to just print a 
deprecation warning.


Joerg

[1] http://marc.info/?l=xml-cocoon-cvsm=120693001028779w=4

[jira] Assigned: (COCOON-2178) Array-based constructors of TreeSelectionEvent used.


 [ 
https://issues.apache.org/jira/browse/COCOON-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jörg Heinicke reassigned COCOON-2178:
-

Assignee: Jörg Heinicke

 Array-based constructors of TreeSelectionEvent used.
 

 Key: COCOON-2178
 URL: https://issues.apache.org/jira/browse/COCOON-2178
 Project: Cocoon
  Issue Type: Improvement
  Components: Blocks: Forms
Affects Versions: 2.1.11, 2.2-dev (Current SVN)
Reporter: Harald Entner
Assignee: Jörg Heinicke
Priority: Minor
 Fix For: 2.1.11, 2.2-dev (Current SVN)

 Attachments: Tree.diff


 I'm facing a serious problem using the cforms tree. 
 We added a new functionality: when a user doubleclicks an item, all subitems 
 are selected as well. The result is that for every selected subitem an event 
 is thrown. The problem, as mentioned in the source code, is that the array 
 based constructor of the TreeSelectionEvent is not used. (Besides some other 
 minor changes). 
 I have adapted the org.apache.cocoon.forms.formmodel.tree.Tree class and it 
 works fine. But we'll face a problem after updating, so please tell me how i 
 could contribute my code.

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

[jira] Updated: (COCOON-2178) Array-based constructors of TreeSelectionEvent used.


 [ 
https://issues.apache.org/jira/browse/COCOON-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jörg Heinicke updated COCOON-2178:
--

  Fix Version/s: (was: 2.1.11)
 (was: 2.2-dev (Current SVN))
Affects version (Component): Parent values: Blocks: Forms(10167). Level 1 
values: 1.0.0-RC3-SNAPSHOT(10331).   (was: Parent values: Blocks: Forms(10167). 
Level 1 values: 1.1.0-SNAPSHOT(10323). )
Fix version (Component): Parent values: Blocks: Forms(10239).   (was: 
Parent values: Blocks: Forms(10239). Level 1 values: 1.1.0-SNAPSHOT(10324). )
  Affects Version/s: (was: 2.2-dev (Current SVN))

 Array-based constructors of TreeSelectionEvent used.
 

 Key: COCOON-2178
 URL: https://issues.apache.org/jira/browse/COCOON-2178
 Project: Cocoon
  Issue Type: Improvement
  Components: Blocks: Forms
Affects Versions: 2.1.11
Reporter: Harald Entner
Assignee: Jörg Heinicke
Priority: Minor
 Fix For: 2.1.12-dev (Current SVN)

 Attachments: Tree.diff


 I'm facing a serious problem using the cforms tree. 
 We added a new functionality: when a user doubleclicks an item, all subitems 
 are selected as well. The result is that for every selected subitem an event 
 is thrown. The problem, as mentioned in the source code, is that the array 
 based constructor of the TreeSelectionEvent is not used. (Besides some other 
 minor changes). 
 I have adapted the org.apache.cocoon.forms.formmodel.tree.Tree class and it 
 works fine. But we'll face a problem after updating, so please tell me how i 
 could contribute my code.

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

[jira] Closed: (COCOON-2178) Array-based constructors of TreeSelectionEvent used.