cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Known concurrency issues in 2.1.4/JISP bugs....possible workaround?
Date Sat, 03 Apr 2004 20:33:13 GMT
Andrzej Jan Taramina wrote:

>Antonio suggested (and Bertrand/Unico also elaborated on this):
>>>We're getting some sporadic strange errors that might be due to
>>>issues between different users, and I was wondering if there are any known
>>>bugs outstanding in 2.1.4 for this kind of thing?
>>The problem can be the cache system:
>Just a thought....if I have the following specified in my cocoon.xconf 
><transient-store logger="">
>	<parameter name="maxobjects" value="@transient_object_cache_size@"/>
>	<parameter name="use-persistent-cache" value="false"/>
><store logger="">
>	<parameter name="maxobjects" value="@generic_object_cache_size@"/>
>	<parameter name="use-persistent-cache" value="false"/>
>Note: @xxx@ values are substituted using an Ant deploy script, so ignore that 
>With both having use-persistent-cache set to false, does that mean that JISP 
>(the default persistent caching mechanism in 2.1.4) will never be called, and 
>thus the concurrency errors should never manifest?

Yes. Setting use-persistent-cache on <store> disables the use of 

However, setting it to false on transient-cache is useless as the 
default class implementing that role explicitely forbids setting it to 
true (which was allowed before 2.1.4), in order for the transient cache 
to really be transient.

>Or do I need to also do something to my persistent store config settings, 
>which currently look like:
><persistent-store logger="">
>	<parameter name="use-cache-directory" value="true"/>
>	<parameter name="order" value="2701"/>
>An aside...what the heck is the "order" value anyway?

No idea :-/

>Much appreciate any insight on this, since we don't need persistent caching 
>for our production application, and this might be a "quick fix" for a very 
>vexing and difficult to reproduce problem.

I understand that! If you have a reasonable amount of RAM, you may also 
increase the <store>'s "maxobjects" so that it keeps some of the data 
that would have been otherwise swaped on disk.

You may also monitor a test run with the instrumentation client, as it 
can display the various stores size, hits and misses, which is very 
useful to determine correct values for "maxobjects".


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message