+1. I've wanted a scheduler component for some time - up until now everything I've seen has been integrated into larger frameworks or has been payware. Maybe a combination of a general ThreadPool that asynchronous tasks can be dispatched to (probably using the Runnable interface to represent the tasks) with a Scheduler capable of dispatching tasks at fixed or repeated intervals.
The Timer and TimerTask in JDK1.3 are a pretty good start for a Scheduler if used with ThreadPools for the heavy-lifting. Though Timer/TimerTask is only available on 1.3. Its a real shame we're not allowed to redistribute classes from the newer JDKs so we can use them on older JDKs like 1.2. (Ditto for other stuff in 1.4). James ----- Original Message ----- From: "Craig R. McClanahan" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, November 30, 2001 2:32 AM Subject: RE: Workflow & Turbine design questions > 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 <[EMAIL PROTECTED]> > > Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]>, > > [EMAIL PROTECTED] > > To: 'Jakarta Commons Developers List' <[EMAIL PROTECTED]> > > 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 > > [EMAIL PROTECTED] > > > > > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
