Carsten Ziegeler a écrit :
>
> 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.
Right. The delay is set by a new - yet undocumented now - "check-delay"
attribute on the <sitemap> element, which defaults to 10 seconds. This
can be reduced (see below).
> b) It should be possible to turn this off (or is it sufficient to have a
> delay time of 0?)
A delay of zero will be OK, but won't be of great help as far as
reducing the calls to getLastModified() is concerned. What about a
default value of 1 sec ? This can be a good approximation of the time
needed to move the mouse from the editor to the browser and click reload
:)
> c) The setting should be configurable differently for each handler.
Do you mean _sitemap_ handler ? Then the "check-delay" attibute should
also be added on <map:mount>.
But I'm not sure this level of configuration is needed at each mount
point as "check-reload" is : "check-reload" can be used to have an
unchangeable root sitemap and some reloadable subsitmaps (useful in
situations like the "mount/*/**" example), but "check-reload" is rather
a global perfomance setting.
> 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.
About caching, I thought of having a special kind of CacheValidity that
would implement a similar mechanism : if isValid() was successful, any
further call to isValid() within a given time period will be successful
without actually performing the check. This would greatly reduce some
redundants checks on frequently requested content, while still allowing
a good reactivity of the website to changing content.
> 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.
Turning off checks means that you have to restart the webapp when
changing the sitemap. Is this the way you do ? What if the delayed check
allowed you to have a good performance _and_ hot-reload of sitemap
changes ?
BTW, the initial thought of DelayedLastModified was to add this
behaviour directly in source implementations (I didn't made it this way
because this would have been a too big change just for showcasing). What
about that ? This delay can be considered as an auto-refresh frequency
for ModifiableSources instead of having to manually call refresh(),
which can be bug-prone if it is forgotten.
Default refresh delays could be configured in the SourceFactory
configurations in cocoon.xconf, and the configuration of URLSource could
allow different default delays depending on the protocol used (e.g. 1
sec for file, and 10 sec for http)
Thoughts ? Can this be usefull ?
Sylvain.
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
