You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Jörn Nettingsmeier <ne...@apache.org> on 2007/05/18 13:24:59 UTC
caching in default publication...
hi everyone!
from pubs/default/sitemap.xmap:
<map:select type="resource-exists">
<!-- Read from cache -->
<!-- If configured within Apache then mod_lenya will nevertheless
read from cache -->
<map:when
test="context:/lenya/pubs/{page-envelope:publication-id}/{global:cache-dir}/{../../1}/{../../2}.htmlDISABLED">
<map:read
src="context:/lenya/pubs/{page-envelope:publication-id}/{global:cache-dir}/{../../1}/{../../2}.html"
mime-type="text-html"
/>
</map:when>
gives rise to a number of questions:
a) what is mod_lenya?
b) why do we code our own caching mechanism rather than relying on ehcache?
c) why is this lenya-specific caching mechanism disabled?
depending on the answers to a) through c), there's question
d) can we just chuck this out?
comments appreciated,
jörn
--
Jörn Nettingsmeier
Kurt is up in heaven now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: caching in default publication...
Posted by Joern Nettingsmeier <ne...@folkwang-hochschule.de>.
Joern Nettingsmeier wrote:
> Michael Wechner wrote:
>>> for now, i would like to comment out all cache-related stuff in the
>>> sitemap (not just doctor the match pattern) and add all the
>>> information people have provided in this thread as comments.
>>> wdyt?
>>
>> yes, it definitely makes sense to add some comments and
>> clarifications.
>
> will do.
it turns out that would do more harm than good, because it involves
commenting out control structures all over the place. which would make
the file even harder to read.
just for fun, i removed every line of code that is unused by default
from pubs/default/sitemap.xmap: an unused view, the XUL stuff and the
cache stuff.
it was 46 lines or more than ten percent of the total code...
we can safely assume that every serious lenya user will have to read and
understand the default sitemap completely before s/he can even begin to
do clever and interesting things with lenya.
why should there be ten percent false trails and red herrings in there?
we really need to move the caching stuff out of the default pub - either
it needs to go into a module (which might be hard), or it must be
handled in a global pipeline... a little loss in flexibility, but a huge
gain in conciseness - caching is really too important to be repeated as
boilerplate code for every publication.
--
jörn nettingsmeier
home://germany/45128 essen/lortzingstr. 11/
http://spunk.dnsalias.org
phone://+49/201/491621
Kurt is up in Heaven now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: caching in default publication...
Posted by Joern Nettingsmeier <ne...@folkwang-hochschule.de>.
Michael Wechner wrote:
> Jörn Nettingsmeier wrote:
>
>> i see. well, i see the point now, but at the same time, i don't
>> like to have dead or untested code in something
>
> frankly speaking it seems to me that you call code untested just
> because you don't use it and I am saying this because it seems to me
> you did quite often before.
well, there is a difference between "used to work with some local
modifications in the jolly old days of lenya 1.2" and "gets constant
testing and review during the 1.4 release process".
if anyone here is using caching in 1.4, please speak up, and do share
your experience with us.
> But I made my arguments why I think this code helps and if others
> don't feel the same, then I guess you are right to remove it, but
> please don't mix up words such as "dead" or "untested" just because
> the code might have gotten to a point where it's unncessary to modify
> it every day.
caching and cache invalidation is probably the single most hairy issue
in computing. don't tell me you honestly believe that since it used to
work way back when, it is still going to work without the need for
testing and quality assurance after all those fundamental changes in
trunk. if we care about this feature, every developer should be using it
by default.
just take the proxying problem that has surfaced only weeks ago. an
absolutely crucial feature that just stayed below our radar too long.
and it's quite an embarassing bug so close to a release.
imnsho stuff in the default publication's sitemap should be maintained.
if it is not being maintained, i'd rather remove it than to annoy users
with promises of stuff we can't really do.
in order to make sure that this stuff gets constant testing, it should
not be disabled by default in a development tree.
same goes for the XUL-based gui. who is testing that?
> There are many libs which do what they are supposed to do and that's
> it. But nevertheless they are very helpful.
libs are self-contained, with a clearly defined API.
the caching stuff is hacked into an example publication sitemap.
there are next to no comments, and it is not obvious to me how the stuff
is supposed to work.
the most glaring issue is that using the (untested) XUL interface is
mutually exclusive with using the (untested) cache. don't tell me this
makes sense and used to work in the old days. it's a fuck-up.
and it is caused by deactivated and untested code in trunk. if somebody
takes an interest in it, great, we should keep it by all means. but if
it's just rotting there, why bother?
>>>> depending on the answers to a) through c), there's question
>>>>
>>>> d) can we just chuck this out?
>>>
>>> with the current performance issues I would rather leave it as a
>>> very reliable alternative.
fine with me, if anyone can confirm it works for them and add some
documentation.
>> hmm. i would agree in general, but i haven't had any problems with
>> live site performance. anyone?
>
> I think it's rather slow compared with other systems I know.
>
>> mod_cache should be able to deal with that.
>
> Have you actually tried mod_cache within a productive environment?
> IIRC we had some difficulties re invalidation, etc, but maybe we were
> just too stupid and any pointers how to do better with mod_cache is
> very much appreciated.
hmm. i have not yet used it to cache lenya, but it worked quite well for
php-based stuff i did. but i'm about to set it up - will keep you posted.
>> for now, i would like to comment out all cache-related stuff in the
>> sitemap (not just doctor the match pattern) and add all the
>> information people have provided in this thread as comments. wdyt?
>
> yes, it definitely makes sense to add some comments and
> clarifications.
will do.
--
jörn nettingsmeier
home://germany/45128 essen/lortzingstr. 11/
http://spunk.dnsalias.org
phone://+49/201/491621
Kurt is up in Heaven now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: caching in default publication...
Posted by Michael Wechner <mi...@wyona.com>.
Jörn Nettingsmeier wrote:
>>
>>
>> because it requires invalidating the cache and IIRC correctly the
>> coupling to
>> the publishing process has not been finished, but people rather
>> coupled it
>> to some shell scripts when syncing with some other servers, but I
>> might be wrong
>> on this
>
>
> i see. well, i see the point now, but at the same time, i don't like
> to have dead or untested code in something
frankly speaking it seems to me that you call code untested just because
you don't use it and I am saying this because it seems to me you did
quite often before.
But I made my arguments why I think this code helps and if others don't
feel the same, then I guess you are right to remove it, but please don't
mix up words such as "dead" or "untested" just because the code might
have gotten to a point where it's unncessary to modify it every day.
There are many libs which do what they are supposed to do and that's it.
But nevertheless they are very helpful.
> as exposed as the default sitemap (all lenya newbies will have to read
> and understand that one, and the simpler it is, the better).
>
>>> depending on the answers to a) through c), there's question
>>>
>>> d) can we just chuck this out?
>>
>>
>> with the current performance issues I would rather leave it as a very
>> reliable alternative.
>
>
> hmm. i would agree in general, but i haven't had any problems with
> live site performance. anyone?
I think it's rather slow compared with other systems I know.
> mod_cache should be able to deal with that.
Have you actually tried mod_cache within a productive environment?
IIRC we had some difficulties re invalidation, etc, but maybe we were
just too stupid and any pointers how to do better with mod_cache is very
much appreciated.
>
> and i don't see how this could have the potential to speed up the
> authoring interface,
that's right, it's not about the authoring interface, which is a
different challenge.
> which is what most people are complaining about iiuc.
>
>
> for now, i would like to comment out all cache-related stuff in the
> sitemap (not just doctor the match pattern) and add all the
> information people have provided in this thread as comments. wdyt?
yes, it definitely makes sense to add some comments and clarifications.
Cheers
Michael
>
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
+41 44 272 91 61
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: caching in default publication...
Posted by Jörn Nettingsmeier <ne...@apache.org>.
Michael Wechner wrote:
> Jörn Nettingsmeier wrote:
>
>> hi everyone!
>>
>>
>> from pubs/default/sitemap.xmap:
>>
>> <map:select type="resource-exists">
>> <!-- Read from cache -->
>> <!-- If configured within Apache then mod_lenya will nevertheless
>> read from cache -->
>> <map:when
>> test="context:/lenya/pubs/{page-envelope:publication-id}/{global:cache-dir}/{../../1}/{../../2}.htmlDISABLED">
>>
>> <map:read
>> src="context:/lenya/pubs/{page-envelope:publication-id}/{global:cache-dir}/{../../1}/{../../2}.html"
>>
>> mime-type="text-html"
>> />
>> </map:when>
>>
>> gives rise to a number of questions:
>>
>> a) what is mod_lenya?
>
> have you read the README?
>
> http://svn.apache.org/repos/asf/lenya/sandbox/mod_lenya/README.txt
>
> especially section 3, but I guess a dedicated "About" section would help
yeah, thanks, thorsten pointed that out. i think i'll add some comments
to the sitemap...
>> b) why do we code our own caching mechanism rather than relying on
>> ehcache?
>
> static "export" is the most stable and most simple reusable cache that I
> know ;-)
:)
>> c) why is this lenya-specific caching mechanism disabled?
>
>
> because it requires invalidating the cache and IIRC correctly the
> coupling to
> the publishing process has not been finished, but people rather coupled it
> to some shell scripts when syncing with some other servers, but I might
> be wrong
> on this
i see. well, i see the point now, but at the same time, i don't like to
have dead or untested code in something as exposed as the default
sitemap (all lenya newbies will have to read and understand that one,
and the simpler it is, the better).
>> depending on the answers to a) through c), there's question
>>
>> d) can we just chuck this out?
>
> with the current performance issues I would rather leave it as a very
> reliable alternative.
hmm. i would agree in general, but i haven't had any problems with live
site performance. anyone? mod_cache should be able to deal with that.
and i don't see how this could have the potential to speed up the
authoring interface, which is what most people are complaining about iiuc.
for now, i would like to comment out all cache-related stuff in the
sitemap (not just doctor the match pattern) and add all the information
people have provided in this thread as comments. wdyt?
--
Jörn Nettingsmeier
Kurt is up in heaven now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: caching in default publication...
Posted by Michael Wechner <mi...@wyona.com>.
Jörn Nettingsmeier wrote:
> hi everyone!
>
>
> from pubs/default/sitemap.xmap:
>
> <map:select type="resource-exists">
> <!-- Read from cache -->
> <!-- If configured within Apache then mod_lenya will nevertheless
> read from cache -->
> <map:when
> test="context:/lenya/pubs/{page-envelope:publication-id}/{global:cache-dir}/{../../1}/{../../2}.htmlDISABLED">
>
> <map:read
> src="context:/lenya/pubs/{page-envelope:publication-id}/{global:cache-dir}/{../../1}/{../../2}.html"
>
> mime-type="text-html"
> />
> </map:when>
>
> gives rise to a number of questions:
>
> a) what is mod_lenya?
have you read the README?
http://svn.apache.org/repos/asf/lenya/sandbox/mod_lenya/README.txt
especially section 3, but I guess a dedicated "About" section would help
> b) why do we code our own caching mechanism rather than relying on
> ehcache?
static "export" is the most stable and most simple reusable cache that I
know ;-)
> c) why is this lenya-specific caching mechanism disabled?
because it requires invalidating the cache and IIRC correctly the
coupling to
the publishing process has not been finished, but people rather coupled it
to some shell scripts when syncing with some other servers, but I might
be wrong
on this
>
> depending on the answers to a) through c), there's question
>
> d) can we just chuck this out?
with the current performance issues I would rather leave it as a very
reliable alternative.
Cheers
Michael
>
>
> comments appreciated,
>
> jörn
>
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
+41 44 272 91 61
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: caching in default publication...
Posted by Thorsten Scherler <th...@apache.org>.
On Fri, 2007-05-18 at 13:24 +0200, Jörn Nettingsmeier wrote:
> hi everyone!
>
>
> from pubs/default/sitemap.xmap:
>
> <map:select type="resource-exists">
> <!-- Read from cache -->
> <!-- If configured within Apache then mod_lenya will nevertheless
> read from cache -->
> <map:when
> test="context:/lenya/pubs/{page-envelope:publication-id}/{global:cache-dir}/{../../1}/{../../2}.htmlDISABLED">
> <map:read
> src="context:/lenya/pubs/{page-envelope:publication-id}/{global:cache-dir}/{../../1}/{../../2}.html"
>
> mime-type="text-html"
> />
> </map:when>
>
> gives rise to a number of questions:
>
> a) what is mod_lenya?
http://svn.apache.org/viewvc/lenya/sandbox/mod_lenya/README.txt?view=markup
> b) why do we code our own caching mechanism rather than relying on ehcache?
Not sure but seeing "3) Schema of Apache2 with mod_proxy and mod_lenya"
I guess one call less (http will return insteandly the result), maybe
Michi can give more inputs.
> c) why is this lenya-specific caching mechanism disabled?
Not sure about above mentioned match myself but I do not understand it
as lenya caching is disabled.
>
> depending on the answers to a) through c), there's question
>
> d) can we just chuck this out?
I am not sure since mod_lenya is in the sandbox it does not feels right
to use it but I would rather see it mature then removed.
I reckon Michi and/or Gregor I. can enlighten us better then I could.
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org