Berin Loritsch a écrit :
>
> 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.
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.
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
