>From: Berin Loritsch [mailto:[EMAIL PROTECTED]] > >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:
Yeah, right _asynchronous_ that's the magic word here. I think that's the main difference to the Sylvains more synchronous idea -in honor-! >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. Totaly agree. >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 totaly agree with you in the points above. I can identify just for the Store Management different events, like JVM Memory controls, Store size, Filesystem clean up, Hastable optimization, etc.... With the normal Thread based approach this would be covered with different threads, like now! This costs performance and resources! Buuuut don't underestimate the effort to manage the result of your events back to the action (through queues, either). But that's a part of the Asynchron I/O issue in the SEDA design (damn I've to re-read this stuff). >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.... :-) I know where. >>>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. Gerhard "Confucius say too much. (Recent Chinese Proverb)" --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
