[ https://issues.jboss.org/browse/DROOLS-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814525#comment-12814525 ]
Mario Fusco edited comment on DROOLS-300 at 10/16/13 4:33 AM:
--------------------------------------------------------------
We are adding 3 optional parameters named "start", "end" and "repeat-limit" to interval and expression timers.
When one or more of these parameters are used the first part of the timer definition must be followed by a semicolon ';' and the parameters have to be separated by a comma ',' as in the following example:
{code}
timer (int: 30s 10s; start=3-JAN-2010, end=5-JAN-2010)
{code}
The value for start and end parameters can be a Date, a String representing a Date or a long or more in general any Number that will be transformed in a date with the following conversion:
{code}
new Date( ((Number) n).longValue() )
{code}
The value for those parameters can also be any expression that can be resolved in any of the before mentioned type so for instance the following DRL will be valid:
{code}
declare Bean
delay : String = "30s"
period : long = 60000
start : String = "3-JAN-2010"
end
rule R
timer( expr: $d, $p; start=$s )
when
Bean( $d : delay, $p : period, $s : start )
then
end
{code}
The date eventually defined by the end parameter represents the moment when the timer will stop triggering. In the same way the repeat-limit one defines the maximum number of repetitions allowed by the timer. If both are set the timer will stop when the first of the two will be matched.
For backward compatibility when none of these optional parameters is used the timers will behave as before. However when the start parameter is set it defines a phase for the timer, where the start of the phase is given by the start itself plus the eventual delay. In other words the timed rule will then be scheduled at times:
{code}
start + delay + n*period
{code}
for up to max repetitions and no later than the end timestamp (whichever first). It means that the rule defined in the former DRL will be scheduled at 30th second of every minute after the midnight of the 3-JAN-2010. So if you turn the system on at midnight of the 3-FEB-2010 it won't be scheduled immediately but will preserve the phase defined by the timer and so it will be scheduled for the first time 30 seconds after the midnight. If for some reason the system is paused (e.g. the session is serialized and then deserialized after a while) the rule will be scheduled only once to recover from missing activations (regardless of how many activations we missed) and subsequently it will be scheduled again in phase with the timer.
Those parameters are not available on the cron timers because they already allow you to define a phase without them, so the start value could be potentially in contrast with it.
was (Author: mfusco):
We are adding 3 optional parameters named "start", "end" and "repeat-limit" to interval and expression timers.
When one or more of these parameters are used the first part of the timer definition must be followed by a semicolon ';' and the parameters have to be separated by a comma ',' as in the following example:
timer (int: 30s 10s; start=3-JAN-2010, end=5-JAN-2010)
The value for start and end parameters can be a Date, a String representing a Date or a long or more in general any Number that will be transformed in a date with the following conversion:
{{new Date( ((Number) n).longValue() )}}
The value for those parameters can also be any expression that can be resolved in any of the before mentioned type so for instance the following DRL will be valid:
{{declare Bean
delay : String = "30s"
period : long = 60000
start : String = "3-JAN-2010"
end
rule R
timer( expr: $d, $p; start=$s )
when
Bean( $d : delay, $p : period, $s : start )
then
end}}
The date eventually defined by the end parameter represents the moment when the timer will stop triggering. In the same way the repeat-limit one defines the maximum number of repetitions allowed by the timer. If both are set the timer will stop when the first of the two will be matched.
For backward compatibility when none of these optional parameters is used the timers will behave as before. However when the start parameter is set it defines a phase for the timer, where the start of the phase is given by the start itself plus the eventual delay. In other words the timed rule will then be scheduled at times:
{{start + delay + n*period }}
for up to max repetitions and no later than the end timestamp (whichever first). It means that the rule defined in the former DRL will be scheduled at 30th second of every minute after the midnight of the 3-JAN-2010. So if you turn the system on at midnight of the 3-FEB-2010 it won't be scheduled immediately but will preserve the phase defined by the timer and so it will be scheduled for the first time 30 seconds after the midnight. If for some reason the system is paused (e.g. the session is serialized and then deserialized after a while) the rule will be scheduled only once to recover from missing activations (regardless of how many activations we missed) and subsequently it will be scheduled again in phase with the timer.
Those parameters are not available on the cron timers because they already allow you to define a phase without them, so the start value could be potentially in contrast with it.
> Add optional start and end arguments to timers
> ----------------------------------------------
>
> Key: DROOLS-300
> URL: https://issues.jboss.org/browse/DROOLS-300
> Project: Drools
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.CR4
> Reporter: Mario Fusco
> Assignee: Mario Fusco
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira