[C1] Caching problem in XSLTProcessor AGAIN!!!

[Robin Green <gr...@hotmail.com>]

I don't believe it. I'm changing my mind for a FOURTH time about how caching 
should be done in XSLTProcessor (and other places).

The original way (the way it was done in 1.8 and for quite some time before, 
not the way it is done in 1.8.2) was half-correct: it always cached 
correctly, but if the number of possible query strings was very large, it 
would eventually in theory cause an OutOfMemoryError. The 1.8.2 way would 
not run out of memory, but it is wrong because it can associate a URL to the 
wrong stylesheet and regenerate a page when it shouldn't, or not regenerate 
a page when it should. The reason is very simple! - http://foo.com/blah may 
require a different stylesheet depending on the user agent or the query 
string, but if we ignore the query string then the wrong stylesheet may be 
checked to see if it has changed. So neither are satisfactory. But the 
original way is the lesser of the two evils, in my view.

But I'm going to offer people the choice, with a time-honoured cop-out - 
configure it in cocoon.properties. The default will be the 1.8 way - use the 
query string in the monitor key. You will be able to tell it to stop using 
the query string in the monitor key. The latter makes sense if you NEVER 
dynamically generate an XSLT processing instruction and NEVER generate 
different content for different user agents, anywhere in the site that is 
managed by this copy of cocoon. For these people - and there are probably 
quite a few of you - it will not cause any problems to stop using the query 
string.

Otherwise, it will cause the above-mentioned caching problems - which may or 
may not be acceptable, you can just touch the xml file(s) and/or restart 
cocoon to tell cocoon to regenerate. I don't think it is acceptable because 
on a production site you might forget to do that when updating some 
stylesheets, and you might therefore end up with half the pages having an 
old look and feel and half having a new look and feel! Also, if any of your 
stylesheets are dynamically generated (unusual and probably not 
recommended), and the query string affects them, you MUST use the default 
option!

The same goes for XIncludeProcessor. Ironically, the only case in which 
ignoring the query string unequivocally _always_ makes sense is in 
ProducerFromFile, because the query string does not affect which file is 
read - but neither 1.8 nor 1.8.2 ignore it as they should, resulting in a 
needless waste of memory!

Until I have time to work on my Cocoon 1-Next-Generation project to 
rearchitect the caching system (Cocoon 1.9 maybe?) this is the best I can 
do.

This underscores two things:

1) Well-thought-out design will save a lot of headaches in the long run. The 
C1 caching system is badly-thought-out because it does not tie monitors to 
cached pages by reference, thus resulting in monitors which can (for some 
sites) grow without bounds and use up all available memory. As I just 
stated, I _have_ redesigned it, but the new version still needs work (and 
after that needs voting on to decide whether to accept it into the cocoon 
codebase - there are some controversial - but configurable - bits in the new 
code.)

2) When you think you've fixed a problem, make sure you understand it!! 
That's been my mistake (3 times!)

--
Robin Green
Official Cocoon 1 Tergiversator


_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Cache O cache... will you work one day ?

[Tony <to...@employer.com.br>]

Hi,

Cocoon 1.8.2
Tomcat 3.2.1

I though I solved my cocoon caching problem adding those two fonctions in my
XSP pages.
 public boolean isCacheable (HttpServletRequest request) {return true;}
 public boolean hasChanged (Object context) {return false;}

It did work for the first called XSP/XML page since the TomeCat starting...
but not for the others.

In other worlds: I've got a.xml , b.xml , c.xml  ALL identical!

I start tomcat --> http://localhost/a.xml  --> cache will work ok for a.xml,
but nerver for b.xml or c.xml.
I start tomcat --> http://localhost/b.xml  --> cache will work ok for b.xml,
but nerver for a.xml or c.xml.
etc...

Can someone tell me why is that ?

It seems that the XSP cache changed for the 1.8.2 version... is
http://xml.apache.org/cocoon/caching.html up to date ?

Thanks,

Tony.


---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>