cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <>
Subject Re: Continuation Time-To-Live Config Not Being Honored
Date Sat, 08 Oct 2005 22:31:42 GMT
Leszek Gawron wrote:
> Kris Schneider wrote:
>> I work with Dan and here's the rest of the story:
>> We ran into severe enough problems using flowscript on WebLogic 8.1
>> (Rhino issues, really), that we had to switch to Java flow. As we've
>> gone down that road, we've come to the realization that all of our
>> continuations seem to have a time to live of ten minutes, regardless
>> of how we configure the <continuations-manager> element in
>> cocoon.xconf. As it turns out, JavaInterpreter uses a hard-coded,
>> non-configurable value of 600000 for continuation time to live. Have
>> we missed anything with regard to being able to configure that aspect
>> of JavaInterpreter?
> One thing: time-to-live in ContinuationsManagerImpl is ONLY used when 
> the WebContinuation does not provide it's own one (but that's probably 
> something you figured already). So this is an issue with 
> JavaInterpreter. Torsten could you comment?
>> During our investigation of the time to live issue, we also came
>> across some concurrency issues with ContinuationsManagerImpl. This
>> class uses the following to store/manage continuations:
>> protected SortedSet expirations =
>> Collections.synchronizedSortedSet(new TreeSet());
>> There are a couple of places where that collection is iterated by doing:
>> Iterator i = expirations.iterator();
>> while (...) {
>>   // use i
>> }
>> This really should be changed to something like this:
>> synchronized(expirations) {
>>   Iterator i = expirations.iterator();
>>   while (...) {
>>     // use i
>>   }
>> }
>> This advice is contained within the Javadoc for
>> Collections.synchronizedSortedSet.

>> Some other references worth reading:

>> Having said that, it seems like someone would have been screaming by
>> now about continuation management being horribly broken. So, is Java
>> flow just not being used, or used under such low levels of concurrency
>> that the problem hasn't surfaced yet? Or is our analysis of the code
>> just incorrect?
> Strange. I have already made a mistake once - a 
> ConcurrentModificationException popped on the user list only few days 
> later :). I'm not ruling out the code might be wrong though.
> Java flow does not matter here. Any flow implementation uses the same 
> continuations manager.
hmmm... javadocs leave no room for interpretation:

public static SortedSet synchronizedSortedSet(SortedSet s)

     Returns a synchronized (thread-safe) sorted set backed by the 
specified sorted set. In order to guarantee serial access, it is 
critical that all access to the backing sorted set is accomplished 
through the returned sorted set (or its views).

     It is imperative that the user manually synchronize on the returned 
sorted set when iterating over it or any of its subSet, headSet, or 
tailSet views.</quote>

I remember a discussion long time ago though that stated we should not 
wrap code in expireContinuations with synchronized( expiration ) {} as 
it would have a massive impact on system performance (think garbage 
collector that does not allow you to create any new objects till its 
finished removing old ones - or maybe this is just the way it works?).

Maybe we should just synchronize the access to expirations but make 
continuationsmanager check for expired continuations more often. This 
way a single expireContinuations() won't last that long.

Leszek Gawron                            
IT Manager                                         MobileBox sp. z o.o.
+48 (61) 855 06 67                    
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65

View raw message