cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: Added Resource Monitor in
Date Tue, 11 Dec 2001 17:26:56 GMT
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.

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 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.

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?

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.


"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

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

View raw message