Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3C171ED1.10E62EAF@anyware-tech.com>
Date: Wed, 12 Dec 2001 10:09:37 +0100
From: Sylvain Wallez <sylvain.wallez@anyware-tech.com>
Organization: Anyware Technologies
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: Added Resource Monitor in Cocoon.java
References: <LDEKKGCNJLEPFDOEIHFDKEFBCKAA.g-froehlich@gmx.de>
 <3C163D0F.CCE4DAF3@anyware-tech.com> <3C1641E0.8040404@apache.org>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit


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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org