What is the difference between ThreadPool and ThreadExecutor in the Quartz framework?
You can configure it in the quartz.properties like this:
org.quartz.threadPool.class = org.quartz.simpl.SimpleThreadPool
org.quartz.threadPool.threadCount = 5
org.quartz.threadExecutor.class = org.quartz.commonj.WorkManagerThreadExecutor
I don't understand it. Looking at the org.quartz.commonj.WorkManagerThreadExecutor, it just looks for the commonj.work.WorkManager from jndi and then runs job tasks using that manager.
AFIK, you can configure thread count etc when declaring the commonj.work.WorkManager in JNDI context. Something like this
<Resource auth="Container"
factory="de.myfoo.commonj.work.FooWorkManagerFactory"
maxThreads="2"
minThreads="1"
name="wm/workManager"
type="commonj.work.WorkManager" />
The difference is that threads provided by the SimpleThreadPool (or any other thread pool implementation configured in your Quartz properties) are unmanaged threads, i.e. threads that are not managed by your container.
On the other hand, threads provided by the configured work manager are managed threads created by the container and typically configured through the container's admin console.
In J2EE world creating unmanaged threads is generally highly discouraged and if you check the J2EE spec, you will find it is explicitly mentioned there (or it used to be there).
You may want to check this SO post for further details on the topic.
Related
Is there any redis jobStore able to support a quartz cluster?
Have anybody been able to build that?
By other side, what's exactly a quartz cluster? I mean, is it able to have two services running the same quartz.properties file pointing to a redis?
EDIT
I've tried with this redis job store but it seems doesn't supprt quartz clustering:
JobStore class 'net.joelinn.quartz.jobstore.RedisJobStore' props could not be configured. [See nested exception: java.lang.NoSuchMethodException: No setter for property 'isClustered']
quartz.properties:
org.quartz.scheduler.instanceName=office-scheduler-service
org.quartz.scheduler.instanceId=AUTO
org.quartz.jobStore.isClustered=true
org.quartz.jobStore.clusterCheckinInterval=20000
# thread-pool
org.quartz.threadPool.class=org.quartz.simpl.SimpleThreadPool
org.quartz.threadPool.threadCount=2
org.quartz.threadPool.threadsInheritContextClassLoaderOfInitializingThread=true
org.quartz.jobStore.class = net.joelinn.quartz.jobstore.RedisJobStore
org.quartz.jobStore.host = redisbo
org.quartz.jobStore.misfireThreshold = 60000
you don't need to configure cluster, please check the source code, it is already clustered
Quartz JDBC documentation explains how it handles executing jobs in a cluster of application nodes. RedisJobStore extended that to utilize the Redis storage, and it will work in a cluster mode (Quartz cluster - not Redis cluster) by default without requiring you to enable that.
Basically Quartz uses a shared database to record which scheduler instance is currently working on a job, as opposed to direct node communication among application schedulers. When a scheduler instance picks up a job, it safely registers its instance id with the running job and persists it in the database. This support by the job store is evident in the schema used by RedisJobStore, indicated by the blocked_by fields.
I am trying to get a list of the queue names and jndi names in java. I have tried using pcf and have only been able to get queue names. The documentation on the IBM sight has not been too helpful.
MQ Java PCF classes can be used to do a number of tasks like inquiring list of queues, channels etc. Also Add/Update/Delete number of queue manager objects can be done. But PCF classes can not be used inquiring JNDI names. JNDI names must be retrieved from a JNDI store like File/LDAP/J2EE JNDI and not in MQ queue manager.
HTH
Since your inquiry was tagged WebSphere, I'll assume some version of WebSphere Application Server (WAS). WAS includes a utility called dumpnamespace. Run it with the -h option to list its options. Aim it at your bootstrap port and it should do as its name implies.
I am thinking about porting a Spring Quartz based application to EJB 3.1 to see if EJB has improved. I am having problems understanding how fail-over works with the Schedule Timer Service. In Quartz, there are database tables which clustered Quartz instances use. If one node in your cluster crashes, jobs will still get executed on other nodes.
I have been looking at how the Timer Service persists things and it appears to use the file system of the server the Timer was created on. Is this true? I do not see how this would be possible as it would render the Timer Service unusable since it would not support failover.
So i must be missing something. Can anyone help me out with this?
The EJB timer service is simply not as advanced as Quartz (with or without Spring).
EJB timers are persisted to an unknown location. It may happen to be the file-system, but it could also be the Windows registry if you happen to be running on Windows, or it could be an LDAP server or whatever.
There was an issue on the EJB spec JIRA for some time about this, and it was discussed on the spec mailing list, but then it was brutally dropped and closed because no one bothered to reply anyone (perhaps because a lot of people were on vacation at the time). It's one of the lamest reasons to close an issue if you'd ask me, but I guess the spec lead sometimes must resort to such measures.
Anyway, in JBoss AS persisting happens to an embedded relational datasource, that on its turn writes to the filesystem. Via propriatary configuration you can point this datasource to any remote DB. Fail-over would have to come from propriatary JBoss functionality as well. Although EJB forbids lots of things for the sake of potential clustering, there's no explicit clustering support in the spec and thus specifically EJB timers are not cluster aware.
Not sure if this was available at the time of the question but you can use the 'cluster-ha-singleton' for this, it allows you to create a singleton timer that is invoked from a single cluster node, in case of failover of the chosen node a new node is elected to run the singleton (and therefore the timers)
http://www.jboss.org/quickstarts/eap/cluster-ha-singleton/
It mentions EAP but I am running on AS 7.2.0 fine, the jars are already included in /modules/org/jboss/
Can anyone please say if quartz will allow you to add additional job types once the scheduler is up and running?
I reckon that our implementation of quarts will be an asp.net service using ram store. It is likely that new jobs will be written over time and that we will want to add these jobs into the scheduler without having to shut the service down.
Yes, so long as the classes related to the new job types make it into the classpath, and your class loader will discover them. Quartz does nothing to "preload" or "prediscover" job classes - it just loads them as they're referenced.
If I understand correctly the default JNDI service runs on my local AS, right? So if I create an EJB and in jboss.xml (running JBoss) I name it "sth" than it is registered in my AS. Correct?
In big projects EJBs might be distributed through many servers - on one server EJBs doing sth and on another sth else. When calling JNDI loopup() I search only one server, right? So it means that I need to know where the EJB is registered... Is it true?
When you cluster your app you will usually configure the cluster so that you have one shared JNDI. In JBoss you do this using HA-JNDI (High Availability - JNDI) or equivalent. This is a centralized service with fail-over. In principle you could imagine having a replicated service for better throughput, but to my knowledge that is not available in JBoss.
In short, you will have only one namespace, so you don't need to know where it is registered.