Quartz, timer unification, message inflow RAR

[starksm64]

Some ideas floating around about cleaning up, unfiying timers in jboss projects have come back to looking at

* Unification of timers into a Quartz based implementation. Timer uses to unify include:
** jPBM timers
** EJB/EJB3 timers
** jmx timers
** jmx timer service
** org.jboss.util.* custom timers
* Have a Quartz rar providing a message inflow adaptor that delivers a Quartz event.
* Have a Quartz MC pojo with dependencies broken out
* Expose the Quartz APIs as Seam components

[gavin.king]

A couple more ideas:

* JBoss-specific extensions to the EJB timer API to expose all Quartz functionality
* Merge jBPM business calendar stuff back into our Quartz service so that all clients of the service can use this (or do you think a business calendar is too much of a vertical construct to belong in a horizontal service?)

[starksm64]

I threw together a diagram of what appear to be the core interfaces of Quartz-1.4.5
http://wiki.jboss.org/wiki/Wiki.jsp?page=QuartzClasses

This seems to be a rather fat interface for a base timer service.

[gavin.king]

Specifically which bits of the API don't belong in a base timer service?

[adrian.brock]

My qualms would be that reading some of the FAQ and an OnJava
it seems to be doing its own threading and have it's own db pool.

I didn't look to deeply at the J2EE integration section, but I would
prefer a RAR that does
1) Inflow that targets an MDB (could be message driven pojo) using
JCA WorkManager (native thread pool) threads
2) Using the native environment's database pooling

For an example of (1) working in a POJO environment see the
jboss-jca prototype. When this prototype is finished we will be
able to provide jca1.5 to any environment that doesn't have it.

[adrian.brock]

And JCA1.5 is about 0 zero lines of code :-)

ejort@ejort:~/jboss-head/jca$ ls -lh output/lib/
total 40K
-rw-r--r-- 1 ejort ejort 38K 2006-03-10 10:05 jboss-jca.jar
ejort@ejort:~/jboss-head/jca$

[gavin.king]

I really don't see what's wrong with a *timer service* having its own threads.... :-)

[adrian.brock]

Because that is why people use application servers.

It's a managed environment. I control the threads.
I also want to share threads. If the timer isn't using them, I want
to use them for something else.

Until everybody is running on 64 bit, the address space exhaustion
problem is something we have to worry about.

Additionally, if it uses my thread pool, I can fix it when it breaks.

If it is thirdparty's thread pool it is a pain. I don't want to support
16 thread pools from 16 thirdparties because they use the
"Not invented here" principle.

[adrian.brock]

Maybe when Java5 is more prevelant people will allow
injection of a java.util.concurrent.Executor
rather than rolling their own?

[starksm64]

Specifically which bits of the API don't belong in a base timer service?

The base timer service should only define what the base usecase of timers is defined to be. None of the scheduler state info should be exposed. The calendar also seems suspect as this should have been injected in the definition. Global operations like xxxAll() need to be layered into seperate interfaces as in general an instance of a component has no business trying to stop/pause all timers.

[bill.burke]

My qualms would be that reading some of the FAQ and an OnJava
it seems to be doing its own threading and have it's own db pool.

I didn't look to deeply at the J2EE integration section, but I would
prefer a RAR that does
1) Inflow that targets an MDB (could be message driven pojo) using
JCA WorkManager (native thread pool) threads
2) Using the native environment's database pooling

For an example of (1) working in a POJO environment see the
jboss-jca prototype. When this prototype is finished we will be
able to provide jca1.5 to any environment that doesn't have it.

IIRC, Quartz can plug in a threading model as well as use any datasource.

Listen guys...I'm sick of hearing how XXX is not perfect so let's write it ourselves. A lot of people use quartz, so let's use it. It has a good API and its something we don't have to maintain.

Bill

[weston.price]

Added to JIRA as

http://jira.jboss.com/jira/browse/JBAS-3207

[starksm64]

Then integrate it correctly.

[bill.burke]

Per the private email.

An SPI is a distraction not an abstraction. JAR JAR is not an option either as we want users to be able to extend EJB Timers (or whatever) with quartz APIs. We also want users to be able to use the Message Infow RAR in their applications as well.

So, we (Gavin and I) don't see Quartz as just an implementation, but also an extension to any timer service out there.

[starksm64]

There has been zero proof that quartz does adequately address the layering of other server aspects such as security, transactions, persistence as well as other candidate javaee specs to be able to make this statement.