Nope, we only have 1 Timer. I suppose that using a Timer per task would
probably work, but the other part of the problem is that our tasks do
not "complete quickly", so even on an independent Timer a task could get
backed up.
I think the preferable solution is to have a system that does once per
interval as you suggested, and *if* it happens that a task takes longer
than its interval then the extra run does nothing and just bails rather
than staying queued up like what happens now.
-- Allen
Anil Gangolli wrote:
OK. I've done that before for "once-per-time-range" execution, but
aren't we scheduling them on independent Timers currently? Would that
be sufficient here?
----- Original Message ----- From: "Allen Gilliland"
<[EMAIL PROTECTED]>
To: <roller-dev@incubator.apache.org>
Sent: Monday, December 04, 2006 8:35 AM
Subject: Re: 3.1 RC1 - Taskmanagement - ResetHitcoutTask
Just as a side note, I am actually planning to basically redo the
current ThreadManagerImpl as well because the way it works now is
inconsistent. The big problem is our use of the java.util.Timer class
for scheduling tasks which states ...
"Corresponding to each Timer object is a single background thread that
is used to execute all of the timer's tasks, sequentially. Timer tasks
should complete quickly. If a timer task takes excessive time to
complete, it "hogs" the timer's task execution thread. This can, in
turn, delay the execution of subsequent tasks, which may "bunch up"
and execute in rapid succession when (and if) the offending task
finally completes."
So, this implementation does not work for what we need. We often have
numerous tasks which need to run at exactly the same time, and in the
case of tasks which can run for a while (ping task, refresh entries
task, sync websites task) then the scheduler can get all messed up and
yield inconsistent results. What we really need is more of a cron
type system.
-- Allen
Anil Gangolli wrote:
OK. I have opened
http://opensource.atlassian.com/projects/roller/browse/ROL-1306
regarding this issue. If you have further comments, as below, please
do add comments there. Thanks.
--a.
----- Original Message ----- From: "Thomas-W Hofmann"
<[EMAIL PROTECTED]>
To: <roller-dev@incubator.apache.org>
Sent: Monday, December 04, 2006 2:13 AM
Subject: Fw: 3.1 RC1 - Taskmanagement - ResetHitcoutTask
Hi,
You might consider the following to get this solved :
(We solved the problem with our infrastructur in the following way)
-Instead (or in addition to the ID key) use the servers IP-Address.
-The server which first aquires the handle locks the whole task
until its
tomcat engine shuts down.
-On startup or shutdown of the Tomcat engine release all aquired
handles
(using servers IP address).
-Add parameters to roller.properties to specify allowed IP adresses
to run
background jobs !
This way you have full external control of whats going on (you
always can
tell which server is running the jobs and which logfile to look at. In
addition we do not want any jobs running on the staging server.
Further
on server crash you have a cleaned up table after the server restarts.
Feel free to ask further questions about our setup.
Thomas
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Thomas
Hofmann
--
Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den
Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren
sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail
in error) please notify the sender immediately and destroy this
e-mail. Any unauthorized copying, disclosure or distribution of the
material in this e-mail is strictly forbidden.
