commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Gaspar" <>
Subject RE: Workflow & Turbine design questions
Date Sat, 01 Dec 2001 16:22:03 GMT
There is a CRON like scheduler at jakarta-avalon-cornerstone package:

It even includes a CRON service and it was quite easy to make it
independent from Avalon and adapt it to something like what you are
describing - including having it executing a Runnable or some similar

My implementation executes jobs using a thread pool as the one you
can find at the scratchpad of jakarta-avalon-excalibur at
(so, package org.apache.avalon.excalibur.thread.impl).

I do not use Avalon's pool. I use an evolution of the Commons pool
instead, and it was not hard to adapt.

I made the all thing work in a weekend and I was still learning a lot
about multithreading in the process.

Another very interesting mechanism is the asynchronous notifications
in the threading project of commons-sandbox... but I am sure you know
that one. =:o)  This could be used for the already suggested JMS
alternative. Its notification mechanism queue could be a nice message

Now, my implementation, although still a bit simplistic, works. Maybe
I can contribute it if someone wants to pick it but I am not in the
mood to go trough the politics of it. I only go trough the politics
of things that I can not implement this fast on my own - which is a
simple time efficiency oriented criteria.

So, I can post it and let you decide what to do with it IF you have
any interest on it.

I am adding the "IF you have interest" clause instead of just posting
it because it still involves the work of cleaning possible dependencies
to my framework and making sure it still works afterwards and this will
still take me some hours.

If you do not have interest on my code, you can always use the above
mentioned packages as I did to achieve the same thing. At least it is
a path that worked for me.

Have fun,
Paulo Gaspar

P.S.: Being a bit more aware of Avalon could save you a lot of work.

There is a lot of interesting common use code there.

I also think that create too many dependencies between some of their
common stuff and their framework structure, but it is still worth the

I just hope they will follow the trend to cut on that kind of
dependencies as they did with the LogKit.

> -----Original Message-----
> From: Craig R. McClanahan
> Sent: Friday, November 30, 2001 3:33 AM
> One way to approach these issues (and would even fit into the Commons
> charter :-) would be to conceive of a Commons package to do background job
> scheduling and execution (what legacy OSs called "batch job queues")
> within a JVM.  Executing a particular workflow script would be only one of
> the interesting things you could do -- ideally the definition of a "job"
> would be something like "call method X on object Y" so it could be fully
> generalized.
> The "jobs" package could be configured with limits on how many background
> threads it could run, support ways to schedule jobs repeatedly, and all
> the other stuff you can do with "cron" type utilities, if we wanted.  It
> could be embedded in any sort of long-running JVM (such as in a webapp on
> a servlet container), as well as stand-alone background jobs.
> This is a bigger task than just something that can run Workflow scripts in
> background threads (which isn't terribly difficult to hard code in your
> application by starting a new thread and executing the Activity there),
> but it would be a generally useful package.  What do you think?
> Craig
> On Thu, 29 Nov 2001, Brett Gullan wrote:
> > Date: Thu, 29 Nov 2001 09:24:55 +0800
> > From: Brett Gullan <>
> > Reply-To: Jakarta Commons Developers List
> <>,
> >
> > To: 'Jakarta Commons Developers List' <>
> > Subject: RE: Workflow & Turbine design questions
> >
> > Almost...
> >
> > > #1. User starts workflow process by performing action.
> > Let's say User A starts workflow process, by for instance, copying a
> > file from his/her desktop to a directory on a local/remote server (this
> > can/will be achieved by a variety of methods/protocols).
> >
> > > #2. Workflow performs tasks that may take time.
> > Yes
> >
> > > #3. User should not be held up waiting for a response from the server
> > by
> > background workflow tasks.
> > Yes. However, User A may never even use the Web UI. User B on the other
> > hand may be watching the queue/progress monitor for regular updates.
> >
> > The web UI is intended to be a monitoring and configuration tool for the
> > underlying workflow engine. For the most part, general users would
> > submit files (by desktop drag-n-drop, FTP, web-form, etc...) then use
> > the web UI to monitor progress or change the queue priority (if
> > authorised).
> > Administrative users would have access to web forms that configure the
> > workflow processing activity steps and the 'hot' folders that feed the
> > processing queue.
> > The application is intended to support deployment on a 'headless' server
> > where all interaction is via a web UI.
> > I hope that makes more sense?
> > Regards,
> > Brett
> > --
> > Brett Gullan
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message