Sylvain Wallez wrote:
>
> Gerhard Froehlich a écrit :
>
>>All your arguments above are correct. For the Cocoon.java the ActiveMonitor is
>>overkill, but what do you want? The Cocoon.java was a starting point to implement
>>a central Resource Monitoring to reduce our huge lastModified calls. Maybe
>>Cocoon.java 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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
