cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Added Resource Monitor in
Date Wed, 12 Dec 2001 09:09:37 GMT

Berin Loritsch a écrit :
> Sylvain Wallez wrote:
> >
> > Gerhard Froehlich a écrit :
> >
> >>All your arguments above are correct. For the the ActiveMonitor is
> >>overkill, but what do you want? The was a starting point to implement
> >>a central Resource Monitoring to reduce our huge lastModified calls. Maybe
> >> is not right Example for lastModified calls. But look into
> >>the piplines (even CachingxxxPiplines).
> >>Somebody has to start, I did. Which way shall we take? Is this an
> >>issue or not?
> >>That's my question now!
> >>If not we can stop here now. If yes then we should search for a solution
> >>which fits.
> >>
> >
> > Sorry if I offended you. I agree with your last sentence, but I was
> > afraid some important design decision would be taken too quickly just
> > because some code is in. As I seem to be the only one to have a
> > different opinion on this subject, I wanted to say it loud, because you
> > are coding so fast :)
> Keep in mind, that I am also working on an asynchronous command structure for
> Avalon, something that ActiveMonitor, Pools, etc. would all be able to take
> advantage of.  The basic gist is this:
> There are a number of maintenance/management tasks that components have to
> take at periodic times like ActiveMonitor, DataSourcePools, Cache implementations,
> etc.  The problem is that having a whole thread for control management for
> each of these items is too heavy, as is performing the maintenance synchronously.

Have you looked at java.util.Timer in JDK1.3 ? AFAIK, it is meant for
this kind of things.

> Part of the lessons learned from the Staged Event Driven Architecture is that
> many times, you only need a small number of threads (in this case, one) to
> handle _all_ of your management tasks.  The SEDA architecture goes so far as
> to apply this to all I/O as it is asynchronous in that architecture.  The
> scalability of the solution is insane.  For instance, a plain HTTP server
> built on top of the SEDA architecture was able to handle 10,000 simultaneous
> connections and outperform Apache httpd using IBM JDK 1.1.8 on a Linux box
> with 4 500 MHz processors and a Gig of RAM.  Apache only made it to about
> 512 simultaneous connections due to process per user limitations--not to
> mention several requests took much longer....

I definitely have to read this stuff...

> I am not proposing the SEDA architecture for Cocoon (although I might examine
> a simple HTTP implementation that supports Servlets later).....
> I am proposing the migration towards an infrastructure where maintenance
> commands can be performed asynchronously--and checking for source file
> changes is only one of those commands.

We have to identify what are those tasks that need to be done
periodically and those that don't need it.

I would say that checking configuration file changes doesn't need to be
done asynchronously, for several reasons :
- in a production environment, these files aren't likely to change
often, and thus periodic check is most often a waste of time,
- in a development environment, people that change these files
immediately issue a request to check the effect of the change.
Synchronous (possibly deferred) check is then IMO more adequate.

Cache management, on the contrary, can be considered the other way :
even in a production environment, periodic asynchronous check effecively
has something to do, which is purge cache entries associated to changed
resources. This isn't absolutely needed from a functional point of view
but allows to free earlier some memory/disk resources that would without
that have been freed later by the MRU policy.

> I am also going to supply a PoolResource implementation in the next version
> of Excalibur so that we can now *gasp* get the internal information of the
> Pool implementations of Cocoon's resources!  How about them apples?

Aahh, this would be really great :)

> But you have to start somewhere....
> >>If you want, I remove this stuff for now, but only for a clean reboot of this
> >>issue ;-).
> >>
> >
> > Let's keep it for now, until we decide if this is the right way to go or
> > not. I will try to spend some time for show-casing the strategy I
> > proposed, so people can look at both.
> :)
> Your solution works for the file issue, but the asyncronous maintenance issues
> are something completely different.

Agree. That's why we have to carefully identify those things that need
asynchronous management.

BTW, I added a new components.source.DelayedLastModified and updated
sitemap.Handler to showcase deferred calls to Source.getLastModified().
Please have a look at it.


Sylvain Wallez
Anyware Technologies -

To unsubscribe, e-mail:
For additional commands, email:

View raw message