You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Peter Flynn <pf...@ucc.ie> on 2004/06/03 14:55:08 UTC
Caching ancillary file content
In my XSLT I extract values from some ancillary files using
the document('foo.xml') function. This works fine, but when
the foo.xml file is changed (eg by some external agency like a timed
script), its old content continues to be served by
Cocoon. Eventually it starts to serve the new content (but
I haven't been able to time it so I don't know what the lag
is).
The archives have many comments on caching, but they appear
to refer mostly to custom apps, JSP routines, etc, none of
which seem apply to this situation, which is an XML document
being transformed to HTML by an XSLT script. I've trawled
the docs for caching, but it only mentions the caching of
the primary content (the src value of map:generate), not any
additional files opened from within the XSLT.
Ideally I'd like all caching of secondary content to be
turned off permanently, so that Cocoon would physically open every file
that the XSLT expects to use, every time the primary content is
served, and not cache anything from
previous hits. This is a low-volume app, so I am prepared
to suffer any I/O penalty in doing so.
Is this possible? I'm running jakarta-tomcat-4.1.18 with
cocoon 2.0.4 under j2sdk1.4.1_01 on RH9. I'll upgrade if
necessary, but the machine will eventually be wiped and
reinstalled with RHE, which will mean a new version of
everything, so if this caching is a bug, I'm interested in
a short-term fix :-)
///Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Caching ancillary file content
Posted by Joerg Heinicke <jo...@gmx.de>.
On 04.06.2004 18:06, Peter Flynn wrote:
>>http://issues.apache.org/bugzilla/show_bug.cgi?id=10203
>
> That's actually the reverse of this problem: the OP seems
> to be complaining that ancillary data retrieved from a call
> to the document() function is *not* being cached, whereas
> in fact it *is* (and shouldn't be) -- and the waters were
> muddied by the problem being confused with the behaviour of
> xsl:include.
No, it matches exactly your problem. The summary is "Docs referenced by
XSLT's document() are not included in cache validity". This means the
cache validity calculation of the transformation is not based on
external documents, so changes in a document accessed via document() are
not recognized and the cache is seen as valid.
> Not important now: I coded around it. But it would be a big
> benefit to the behaviour of Cocoon if this was fixed: it is
> *not*, as Carsten suggests, a "feature request": it's a bug.
You are free to add your comment to the bug and maybe also vote for it.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Caching ancillary file content
Posted by Peter Flynn <pf...@ucc.ie>.
On Fri, 2004-06-04 at 12:02, Joerg Heinicke wrote:
> On 03.06.2004 14:55, Peter Flynn wrote:
[caching]
> http://issues.apache.org/bugzilla/show_bug.cgi?id=10203
>
> From the bug date you will also see, that there will probably be no
> short-term fix.
That's actually the reverse of this problem: the OP seems
to be complaining that ancillary data retrieved from a call
to the document() function is *not* being cached, whereas
in fact it *is* (and shouldn't be) -- and the waters were
muddied by the problem being confused with the behaviour of
xsl:include.
Not important now: I coded around it. But it would be a big
benefit to the behaviour of Cocoon if this was fixed: it is
*not*, as Carsten suggests, a "feature request": it's a bug.
If I write
<xsl:value-of select="document('foo.xml')/bar/@blort"/>
and it emits the string "xyz" because foo.xml contains
<bar blort="xyz"/>
and then an external system changes foo.xml so that it now
contains
<bar blort="abc"/>
and I reload the URI of the pipeline in my browser, I still
get "xyz" because the content of the file was cached.
Whatever code in Cocoon that is performing this caching
simply needs to be removed.
///Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Caching ancillary file content
Posted by Joerg Heinicke <jo...@gmx.de>.
On 03.06.2004 14:55, Peter Flynn wrote:
> In my XSLT I extract values from some ancillary files using
> the document('foo.xml') function. This works fine, but when
> the foo.xml file is changed (eg by some external agency like a timed
> script), its old content continues to be served by
> Cocoon. Eventually it starts to serve the new content (but
> I haven't been able to time it so I don't know what the lag
> is).
>
> The archives have many comments on caching, but they appear
> to refer mostly to custom apps, JSP routines, etc, none of
> which seem apply to this situation, which is an XML document
> being transformed to HTML by an XSLT script. I've trawled
> the docs for caching, but it only mentions the caching of
> the primary content (the src value of map:generate), not any
> additional files opened from within the XSLT.
>
> Ideally I'd like all caching of secondary content to be
> turned off permanently, so that Cocoon would physically open every file
> that the XSLT expects to use, every time the primary content is
> served, and not cache anything from
> previous hits. This is a low-volume app, so I am prepared
> to suffer any I/O penalty in doing so.
>
> Is this possible? I'm running jakarta-tomcat-4.1.18 with
> cocoon 2.0.4 under j2sdk1.4.1_01 on RH9. I'll upgrade if
> necessary, but the machine will eventually be wiped and
> reinstalled with RHE, which will mean a new version of
> everything, so if this caching is a bug, I'm interested in
> a short-term fix :-)
http://issues.apache.org/bugzilla/show_bug.cgi?id=10203
From the bug date you will also see, that there will probably be no
short-term fix.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org