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.
http://java.sun.com/j2se/1.3/docs/api/java/util/Collections.html#synchronizedSortedSet(java.util.SortedSet)
Some other references worth reading:
http://java.sun.com/j2se/1.3/docs/api/java/util/Iterator.html#remove()
http://java.sun.com/j2se/1.3/docs/api/java/util/ConcurrentModificationException.html
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:
<quote>
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 [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
