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.
OK...
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.
Whew.
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 the second store.get() does.
Huh?
- 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.
Geoff*
