Re: Known concurrency issues in 2.1.4/JISP bugs....possible workaround?

[Sylvain Wallez]

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
concurrency
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 
settings:

<transient-store logger="core.store.transient">
        <parameter name="maxobjects" value="@transient_object_cache_size@"/>
        <parameter name="use-persistent-cache" value="false"/>
</transient-store>
        
<store logger="core.store">
        <parameter name="maxobjects" value="@generic_object_cache_size@"/>
        <parameter name="use-persistent-cache" value="false"/>
</store>
Note: @xxx@ values are substituted using an Ant deploy script, so ignore that 
stuff.

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 
<persistent-store>.

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="core.store.persistent">
        <parameter name="use-cache-directory" value="true"/>
        <parameter name="order" value="2701"/>
</persistent-store>
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

--
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }