Re: [Spacewalk-devel] [PATCH] Quartz SimpleTrigger mis-fire situations

2012-11-13 Thread Tomas Lestach
On Monday 12 of November 2012 14:20:50 Johannes Renner wrote:
> Hello,
> 
> When scheduling many repo syncs at a time (as 'mgr-ncc-sync' does it), we
> experienced that not all of the channels were actually getting a refresh,
> try it with e.g. ~ 30. After some research we found that this is due to the
> 'repeat count' parameter given to the SimpleTrigger constructor in
> TaskoQuartzHelper. This parameter seems to control the so-called 'mis-fire'
> behavior in case there is e.g. no threads available at the actual schedule
> time. There is usually not many threads available in this use case, since
> repo sync tasks trigger the generation of new repository metadata as well.
> 
> Please see [1] or [2] for more details about handling of mis-fire situations
> in quartz. The proposal is to use default values for repeat count and
> repeat interval, which will lead to a more reasonable behavior
> (MISFIRE_INSTRUCTION_FIRE_NOW).
> 
> See the attached patch for a fix.
> 
> Regards,
> Johannes
> 
> [1]
> http://quartz-scheduler.org/api/1.8.5/org/quartz/SimpleTrigger.html#updateAf
> terMisfire%28org.quartz.Calendar%29 [2]

Interesting. Hope it helps.
Applied as: a5a21df90c598de7929d739738d18fef771dd871

Thank you,
-- 
Tomas Lestach
RHN Satellite Engineering


> http://java.dzone.com/articles/quartz-scheduler-misfire

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel


[Spacewalk-devel] [PATCH] Quartz SimpleTrigger mis-fire situations

2012-11-12 Thread Johannes Renner
Hello,

When scheduling many repo syncs at a time (as 'mgr-ncc-sync' does it), we 
experienced
that not all of the channels were actually getting a refresh, try it with e.g. 
~ 30.
After some research we found that this is due to the 'repeat count' parameter 
given to
the SimpleTrigger constructor in TaskoQuartzHelper. This parameter seems to 
control the
so-called 'mis-fire' behavior in case there is e.g. no threads available at the 
actual
schedule time. There is usually not many threads available in this use case, 
since repo
sync tasks trigger the generation of new repository metadata as well.

Please see [1] or [2] for more details about handling of mis-fire situations in 
quartz.
The proposal is to use default values for repeat count and repeat interval, 
which will
lead to a more reasonable behavior (MISFIRE_INSTRUCTION_FIRE_NOW).

See the attached patch for a fix.

Regards,
Johannes

[1]
http://quartz-scheduler.org/api/1.8.5/org/quartz/SimpleTrigger.html#updateAfterMisfire%28org.quartz.Calendar%29
[2] http://java.dzone.com/articles/quartz-scheduler-misfire

-- 
SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg)
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
>From e6172072966a2a7824770a48a033b064c787ac8b Mon Sep 17 00:00:00 2001
From: Johannes Renner 
Date: Fri, 9 Nov 2012 11:22:50 +0100
Subject: [PATCH] Fix quartz trigger initialization repeat count

---
 java/code/src/com/redhat/rhn/taskomatic/TaskoQuartzHelper.java |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/java/code/src/com/redhat/rhn/taskomatic/TaskoQuartzHelper.java b/java/code/src/com/redhat/rhn/taskomatic/TaskoQuartzHelper.java
index 191a5a9..864a7b8 100644
--- a/java/code/src/com/redhat/rhn/taskomatic/TaskoQuartzHelper.java
+++ b/java/code/src/com/redhat/rhn/taskomatic/TaskoQuartzHelper.java
@@ -67,7 +67,7 @@ public class TaskoQuartzHelper {
 Trigger trigger = null;
 if (isCronExpressionEmpty(schedule.getCronExpr())) {
 trigger = new SimpleTrigger(schedule.getJobLabel(),
-getGroupName(schedule.getOrgId()), 1, 1);
+getGroupName(schedule.getOrgId()));
 }
 else {
 try {
-- 
1.7.10.4

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel