Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Message-ID: <38B520C4.5A3FFF69@apache.org>
Date: Thu, 24 Feb 2000 13:15:01 +0100
From: Stefano Mazzocchi <stefano@apache.org>
Organization: Apache Software Foundation
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: cache thoughts
References: <85CDFD92C550D311A1A40008C7DFA81A01D66D@firewall.altacast.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Timm, Sean" wrote:
> 
> The following is a quick overview of the MemoryStore situation from my
> perspective:
> 
> The MemoryStore class is currently hard-coded to ensure that at least
> 500,000 bytes of memory are available to the JVM at all times.  The cache
> will be very ineffective, and you probably wouldn't see any performance
> improvements if you don't have enough memory available for the JVM beyond
> this.

Of course not. Anyway, memory management in java is a pain. They sure
hide the details to you so you don't make mistakes, and this is great,
but when I _know_ what I'm doing, then again, the details are hidden...
and you're left _guessing_ what will happen.

The MemoryStore is a dirty hack against the garbage collector. Is sort
of a garbage collector on his own... mind you, a _very_ limited and
inefficient one (read the code to find out why) but does its job.

If you don't set anything on your JVM from the command line, it will
normally start with some 800k and then try to clean them up the more
OutOfMemory it gets during new() instances (you don't see this, it's
internal stuff).

If the heap is full, it gets increased. Note: the heap _never_
decreases! It's a known bug in Sun JVMs in all flavors (IBM's,
BlackDown's, etc...)

The memory store used to complain if you didn't have enough memory, but
this was unpredicable and too hard for people to get, so I removed it.
It simply doesn't do any serious caching until your heap grows.

Don't worry: it will! A couple of DOM objects in memory and your heap
goes straight to 4Mb!

Cocoon is _very_ inefficient at memory footprint. We know this. Cocoon2
will fix it. By now, you have to live with that.
 
> Everything using the MemoryStore for object storage that is URL or
> file-based is currently using the Monitor class to determine when a
> timestamp has changed (at least what I've found so far).  The problem is
> that each object is keyed off of the HttpServletRequest object (munged by
> Utils.encode).  I'm hitting the same URL with a different stylesheet...hence
> my problem.

Try again. It should be fixed now.
 
> All hasChanged() calls expect the HttpServletRequest to be passed in (even
> though the parameter is declared as type Object, the CocoonCache class
> passes in a request object to everything that implements the Changeable
> interface, so hasChanged() currently has to handle receiving an
> HttpServletRequest object). 

I know, that sucks. In Cocoon2 we have the Modificable interface which
is much better.

> In effect, hasChanged() calls are passed off to
> each processor or producer, but the only thing passed to them is the request
> object.  For those using the Monitor, this request object is munged and
> passed to the Monitor as a lookup key to see if the object has changed from
> the last recorded timestamp.  This is where the real problem is.  The
> Monitor cannot just base the key off of the request object...it has to
> include the resource name being stored as well (the XSL stylesheet location
> and name, for instance).
> 
> So...thoughts? (Hopefully I wasn't too unclear...)

I admit the cache system is utterly complex and its design wasn't
planned on the whiteboard and you can tell :)

Suggestions are welcome, but not for 1.7, I'm doing it today.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------