fulcrum-quartz configuration

[Scott Eade <se...@backstagetech.com.au>]

While debugging an unrelated issue I was forcing stack traces from 
tomcat via kill -3 (very useful).

This revealed a couple of issues with fulcrum-quartz.

1. By default there are 10 worker threads being initiated for 
DefaultQuartzScheduler - this is way more than are likely to be 
required.  The documentation 
(http://www.opensymphony.com/quartz/wikidocs/ConfigThreadPool.html) says 
"If you only have a few jobs that fire a few times a day, then 1 thread 
is plenty!".  Tuning this should be a simple matter of configuring 
org.quartz.threadPool.threadCount = 1

2. The quartz threads are currently prefixed with 
"DefaultQuartzScheduler" - I have four webapps and I cannot tell which 
of the threads relates to which instance (44 threads in all due to issue 
1 described above).  Altering this should be a simple matter of 
configuring org.quartz.scheduler.threadName to be something environment 
specific rather than the default of: instanceName + 
'_QuartzSchedulerThread' (see: 
http://www.opensymphony.com/quartz/wikidocs/ConfigMain.html)  I am 
trusting that this will change the prefix of the worker threads also (4 
scheduler threads and 40 workers).

I haven't looked into the fulcrum end of this yet - I assume it that 
adding these will be a simple matter of updating the config in 
componentConfiguration.mxl - IOC and all that I imagine it it should be 
a piece of cake.

Scott

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

Re: fulcrum-quartz configuration

[Scott Eade <se...@backstagetech.com.au>]

Scott Eade wrote:
> While debugging an unrelated issue I was forcing stack traces from 
> tomcat via kill -3 (very useful).
Ctrl-Break on Windows.
> This revealed a couple of issues with fulcrum-quartz.
>
> 1. By default there are 10 worker threads being initiated for 
> DefaultQuartzScheduler - this is way more than are likely to be 
> required.  The documentation 
> (http://www.opensymphony.com/quartz/wikidocs/ConfigThreadPool.html) 
> says "If you only have a few jobs that fire a few times a day, then 1 
> thread is plenty!".  Tuning this should be a simple matter of 
> configuring org.quartz.threadPool.threadCount = 1
>
> 2. The quartz threads are currently prefixed with 
> "DefaultQuartzScheduler" - I have four webapps and I cannot tell which 
> of the threads relates to which instance (44 threads in all due to 
> issue 1 described above).  Altering this should be a simple matter of 
> configuring org.quartz.scheduler.threadName to be something 
> environment specific rather than the default of: instanceName + 
> '_QuartzSchedulerThread' (see: 
> http://www.opensymphony.com/quartz/wikidocs/ConfigMain.html)  I am 
> trusting that this will change the prefix of the worker threads also 
> (4 scheduler threads and 40 workers).
Setting org.quartz.scheduler.instanceName rather than threadName has the 
advantage that the scheduler thread is also distinguishable in the stack 
trace.
>
> I haven't looked into the fulcrum end of this yet - I assume it that 
> adding these will be a simple matter of updating the config in 
> componentConfiguration.mxl - IOC and all that I imagine it it should 
> be a piece of cake.
Okay, simple enough, but there are a at least a couple of ways to 
achieve this now:

    * Using system properties via Yaafi's SystemPropertyService thus:

    <SystemPropertyService>
        <property name="org.quartz.threadPool.threadCount">1</property>
        <property 
name="org.quartz.scheduler.instanceName">${myapp.servlet.name}_Quartz</property>
    </SystemPropertyService>

    * Using quartz.properties, note however that if Quartz finds a
      quartz.properties it does not load it's own and hence it is also
      necessary to define the other properties required to bootstrap
      quartz (just copy them across from the quartz.properties included
      in the quartz jar file).

One further option would be to update DefaultQuartzScheduler to read in 
a bunch of additional properties directly from the 
componentConfiguration file - these would be read in configure() and 
then applied via SchedulerFactory.initialize() after moving the 
instantiation of the scheduler there also (it is currently instantiated 
in service() which would be before the new properties would be 
available).  I think there would be a down side to this - you would 
again need to define all of the properties (the defaults would not be 
loaded) and you would lose the ability to override properties using 
system properties.

So the first two options work fine for now.  Does anyone feel that the 
third options should be implemented?

Scott

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org