cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: DelayedLastModified?
Date Tue, 18 Dec 2001 13:02:02 GMT
Sylvain Wallez wrote:
>
> Carsten Ziegeler a écrit :
> >
> > Hi Team,
> >
> > could someone please explain what the DelayedLastModified class should
> > be doing? Currently it is only imported in the Handler class, but not
> > really used there, right?
> > If it is experimental, we should move it to the scratchpad directory.
> >
> > Cheers,
> > Carsten
> >
>
> Hi Carsten,
>
> I wrote this class as part of the discussion about reducing filesystem
> calls to check for modification dates. This was to show how this could
> be done "passively" instead of using an active monitor.
>
> The purpose if this class (as stated by the javadoc :) is to be a
> front-end to a Source to delay actual calls to Source.getLastModified()
> which can be costly. It ensures this method isn't called more that once
> in each {delay} period, {delay} being the time in milliseconds specified
> in the second argument of the constructor.
>
> It *is* used by Handler to check the last modification date of the
> sitemap file.
Ups, yes, it's really used - sometimes I'm blind, you know?

> This is for now the only place where it is used in the
> main source tree (it's also used in the TreeProcessor I have on my PC,
> which is nearly finished), and it could be used everywhere a Source
> object is kept and its modification date checked regularly. A quick
> search shows Cocoon, AbstractComplementaryConfigurableAction,
> AbstractServerPage, and maybe others.
>
> IMO this should be considered more as an optimization helper class than
> a real experiment, since it doesn't add new features.
>
> What do you think ?
>
Ok, yes this a helper class - perhaps it should reside in another package
and get another name.

I see some (minor) problems with this approach then:
a) The default behaviour is now different to that from 2.0 as changes are
   not detected immediately but delayed - although these are only some
   seconds difference, it might disturb some people.
b) It should be possible to turn this off (or is it sufficient to have a
   delay time of 0?)
c) The setting should be configurable differently for each handler.
d) We have to be really careful where to use it. Using this in place which
   are really often called like the sitemap handler is a great performance
   improvement - although you get much better performance if you turn the
   checking completly off (with the check-reload flag...).
   But we should never use this e.g. for caching in the file generator etc.

As you see, these are only minor points. My personal opinion is that I don't
want to have this delayed behaviour for development sites as I then really
don't care about performance and I get a much better behaviour for
production
sites by turning off the sitemap change checking. But these are only my
personal
thoughts.

Carsten

> Sylvain.
>
> --
> Sylvain Wallez
> Anyware Technologies - http://www.anyware-tech.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


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


Mime
View raw message