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 Thu, 20 Dec 2001 08:05:19 GMT
Sylvain Wallez wrote:
>
> 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
> :)
You got me...
>
> > 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.
Hm, you mean "check-delay" here, right? Ok, I agree with this, but the
syntax
for the configuration should/could reflect this, for example:
<sitemap file="sitemap.xmap" reload-method="asynchron" check-reload="yes">
    <parameter name="check-delay">10</parameter>
</sitemap>

The intention here is to show the difference to the map:mount, so people
don't get the intention to use check-delay on map:mount as well.

>
> > 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.
Yes, this is something I'm thinking of since months, but actually never
had the time to really finish. The problem here is that the isValid method
of the validity object needs another validity object. So in order to make
the check you need a new validity object. To get a new validity object
you ask the Source object for it and this performs then the "get last
modification date" operation.
I'm currently designing the "new" source and validity checking in the
avalon excalibur scratchpad. There is a slightly better solution (which
I currently don't like). So a little investigation could be added
there.

>
> > 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 ?
>
Yes, turning off checks is intended, because it's a deployed site and
we assume that deployed sites never change (until redeployed). This also
avoids the problem when someone accidently changes a deployed sitemap
in a way that the sitemap is not working anymore.
But I agree, that having a high delayed check value might be a good
thing for deployed sites as well.

>
> 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 ?
>
Not sure about this. We should not add it to the source directly, but
the handlers could perhaps be configured this way.

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