cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <br...@outerthought.org>
Subject RE: CommandManager issues [was Re: Releasing 2.1.1?]
Date Tue, 02 Sep 2003 19:56:09 GMT
On Tue, 2003-09-02 at 12:48, Giacomo Pati wrote:
> On Mon, 1 Sep 2003, Bruno Dumon wrote:
> 
> > On Mon, 2003-09-01 at 16:29, Giacomo Pati wrote:
> > > On Mon, 1 Sep 2003, Bruno Dumon wrote:
> > >
> > > > On Mon, 2003-09-01 at 11:37, Giacomo Pati wrote:
> > > > > On Mon, 1 Sep 2003, Reinhard Poetz wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > > On Behalf Of Giacomo Pati
> > > > > >
> > > > > > > On Mon, 1 Sep 2003, Andreas Hochsteger wrote:
> > > > > > >
> > > > > > > > Hi!
> > > > > > > >
> > > > > > > > Just in case you didn't know:
> > > > > > > > Did you have a look at the Quartz Scheduler?
> > > > > > > > http://www.part.net/quartz.html
> > > > > > > > http://www.part.net/quartz_features.html
> > > > > > > > Perhaps it already does what you need.
> > > > > > > > It's licensed under a BSD and Apache-Style license.
> > > > > > >
> > > > > > > I've seen it some time ago but thought it is quite too
much
> > > > > > > for a simple cron mechanism we are discussing here.
> > > > > > >
> > > > > > > Any other thoughts?
> > > > > >
> > > > > > Do you think it is difficult to use/to integrate? From the features
list
> > > > > > it is exactly what we need, isn't it?
> > > > >
> > > > > IMHO, from the feature list it is way too much we need, isn't it?
> > > >
> > > > I think many of it are optional features, and those extra features might
> > > > come in handy some day. If it does everything we need and if it's solid,
> > > > why not use it?
> > >
> > > Hmm, the cocurrency util from Doug Lea does alot Quartz offers.
> >
> > Hmm, as far as I know, only the threadpool? (which is of course an
> > important part). Quartz has either a very simple thread pool of its own
> > or otherwise uses something from jakarta commons. I think it would be
> > easy to put PooledExecutor behind it.
> 
> Ok, I've rewritten the Scheduler using Quartz as scheduling engine (and
> using its CronTrigger class) but put an PooledExecutor underneath as the
> ThreadPool.
> 
> > >  So my
> > > oppinion was not to add another dependency.
> >
> > Sometimes it sounds more compelling to add another dependency maintained
> > by another community than to add more code to Cocoon.
> 
> Ok, convinced :-)
> 
> > >  Quartz (if I've read the
> > > feature list correctly) doesn't offer Cron spec parsing,
> >
> > Hope you look a bit further than the first web page to judge a piece of
> > software (imagine if people would do that for cocoon...)
> 
> Sorry, yes now I've seen it and it has quite more feature as my
> implementation.
> 
> > See this:
> > http://quartz.sourceforge.net/javadoc/org/quartz/CronTrigger.html
> >
> > Furthermore, from having a quick look, quartz is quite modular, with
> > different implementations available, in its simplest form without any
> > third party jars requirements.
> 
> Yup. I've seen.
> 
> >
> > It also seems to be able to calculate the time to perform to the next
> > task to be performed.
> >
> > >  so we have to
> > > do it anyway. And because I've alread done this for another project some
> > > times ago I thought to but it into a Scheduler by it own (mean in the
> > > org.apache.cocoon package space).
> > >
> > > So, the scheduler I've proposed is already done. I just have to
> > > repackage it and add some more javadocs etc. It's about to be ready to
> > > be committed tomorrow.
> > >
> > > If there are still objection I hold on the commits until we reached
> > > consensus.
> >
> > I have two more questions:
> >
> > * what do we need a scheduler for in Cocoon in the first place?
> >
> > * would your scheduler be able to handle the ContinuationsManager
> > cleanup task? The specific requirement I'm thinking of is that it
> > shouldn't be launched concurrently, so if the previous cleanup is still
> > running it shouldn't be launched a second time.
> 
> The interface for a Scheduler so far isn't complete but, yes, The
> ContinuationsManager could launch it's own jobs as the Scheduler is
> implemented as a regular Avalon component.
> 
> I've also implemented configurable en-/disable parallel runs.

ok. Sounds all nice and good.

One open point now is what the scheduler is needed for. I mean, the
ContinuationsManager cleanup task doesn't have any fancy cron scheduling
needs, and could be run as well by the CommandManager (which I think is
present anyway in fortress to manage component pool sizes
assynchronously, so might as well be used).

This would remove the requirement to put the scheduler into the core, so
that it could be put in a block.

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org


Mime
View raw message