cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <>
Subject Re: Switching cache to Persistent Store
Date Mon, 11 Aug 2003 16:25:39 GMT
Upayavira wrote:
> On 11 Aug 2003 at 10:43, Geoff Howard wrote:
>>Upayavira wrote:
>>>On 11 Aug 2003 at 16:22, Sylvain Wallez wrote:
>>>>Joerg Heinicke wrote:
>>>>>IIRC it's a Jetty /feature/. Tomcat does not do this.
>>>>Yes, because Jetty creates a different temporary directory at each
>>>>run, while Tomcat always uses the same.
>>>So the solution, for Jetty at least then, is to make the path to the
>>>work directory absolute (in cocoon.xconf), rather than relative to
>>>the context temp dir, which can change.
>>>But unfortunately that doesn't explain my CLI problem :-(
>>Ah, yes.  I was being dense - you mentioned Jetty (well, :8888) in
>>your example and we went from there.
>>Can you explain again what you're seeing in the CLI - how have you
>>configured the cache/work dir in cli.xconf? (sorry, I'm totally
>>ignorant of CLI workings)  Does this problem go away if you
>>un-configure my event cache?  EventCacheImpl will clear the cache if
>>it is unable to retrieve its serialized state (rare).  Perhaps there
>>is a bug related to CLI with that process?
> I'm seeing the first request taking 4 seconds, and the second for the same page 
> taking 0.4 seconds. Debugging the code, the first store.get() doesn't return anything,

> but the second does. Restart Cocoon (i.e. rerun the CLI), and you get the same 
> behaviour, store.get() returns nothing first time and returns something second time.


> It seems to work this way all of the time, regardless of what I do!
> The work dir is configured in the cli.xconf, and is simply created with new 
> File(workDir). The cache directory is made from the work dir with cache-dir 
> appended.

Sorry for my ignorance - I don't see any caching set up in cli.xconf, so 
I assume that means you are inheriting the definitions from 
cocoon.xconf?  That eliminates one class of problems (unless you're not 
using the default cocoon.xconf - if that's the case, send your transient 
and peristent store decl. declaration here

I noticed you have <work-dir>../temp/docs</work-dir>
After a run of the cli is that dir (really the cache dir under it) empty?

> Once I worked out what was going on with your EventCache, I removed it, and it 
> made no difference. 


> Removing it enabled me to get it to switch to using a persistent store by putting a 
> <cache> element into cocoon.xconf, but the is persistent store (DefaultStore) doesn't

> survive a restart of the CLI, either, i.e. the first store.get() returns nothing and
> second store.get() does.

- No cache element is needed in cocoon.xconf because it's defined in 
cocoon.roles (and if you just removed the event-cache by deleting the 
xconf entry you probably didn't really remove it)
- The cache role is a wrapper around transient-store and 
persistent-store which come predifined in cocoon.xconf

These components work together like this:

Cache wraps transient-store which uses persistent-store (if and only if 
*<parameter name="use-persistent-cache" value="true"/> is set on 
transient-store in cocoon.xconf which it is by default)

All new items go into the transient-store, and if configured, older 
items are moved into persistent-store when they are bumped off the 
bottom of the stack, or on container shutdown.  All this happens by 
default out of the box and is working correctly (unless you delete/fail 
to reuse the cache-dir as Jetty does) for the servlet mode.

Sorry if that is all obvious to you but that last paragraph makes me 
think you've got some things turned around in your head - probably 
because of the Jetty behavior.


View raw message