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: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
