[jira] [Commented] (OOZIE-3214) Allow configurable timezone for coordinators
[
https://issues.apache.org/jira/browse/OOZIE-3214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16463142#comment-16463142
]
Peter Cseh commented on OOZIE-3214:
---
We shouldn't be too clever about this and outsource as much as possible to
Quartz:
[http://www.quartz-scheduler.org/documentation/faq.html#FAQ-daylightSavings]
{quote}
There is one additional point users must understand about CronTrigger with
respect to daylight savings. This is that you should take careful thought about
creating schedules that fire between midnight and 3:00 am (the critical window
of time depends on your trigger's locale, as explained above). The reason is
that depending on your trigger's schedule, and the particular daylight event,
the trigger may be skipped or may appear to not fire for an hour or two. As
examples, say you are in the United States, where daylight savings events occur
at 2:00 am. If you have a CronTrrigger that fires every day at 2:15 am, then on
the day of the beginning of daylight savings time the trigger will be skipped,
since, 2:15 am never occurs that day. If you have a CronTrigger that fires
every 15 minutes of every hour of every day, then on the day daylight savings
time ends you will have an hour of time for which no triggerings occur, because
when 2:00 am arrives, it will become 1:00 am again, however all of the firings
during the one o'clock hour have already occurred, and the trigger's next fire
time was set to 2:00 am - hence for the next hour no triggerings will occur.
{quote}
We can say that if the customer changes the processing time to one with DST,
they have to manage issues like this. The alternative is to use a non-DST
processing time and have a different can of worms to deal with.
Anyhow, before deciding, let's come up with a couple of examples in a table so
we can compare our options better. I always get headache after thinking about
Daylight saving for too long :)
> Allow configurable timezone for coordinators
>
>
> Key: OOZIE-3214
> URL: https://issues.apache.org/jira/browse/OOZIE-3214
> Project: Oozie
> Issue Type: New Feature
> Components: coordinator
>Affects Versions: trunk
>Reporter: Julia Kinga Marton
>Assignee: Julia Kinga Marton
>Priority: Major
>
> Right now in case of coordinators only daylight saving time corrections are
> applied, the processing timezone for the coordinators is always the Oozie
> processing timezone.
> It would be more transparent to have an option for changing the {{timezone}}
> attribute itself, such as an additional attribute in the {{coordinator.xml}}
> (meaning a new version of {{coordinator.xsd}}). I would make this option
> switched off by default(to have the actual behavior).
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OOZIE-3214) Allow configurable timezone for coordinators
[
https://issues.apache.org/jira/browse/OOZIE-3214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16462742#comment-16462742
]
Andras Piros commented on OOZIE-3214:
-
Thanks [~jphelps] and [~pbacsko] on your insights! [~orova] [~gezapeti] what
are your two cents regarding how Cron expressions should behave at daylight
changing borders?
> Allow configurable timezone for coordinators
>
>
> Key: OOZIE-3214
> URL: https://issues.apache.org/jira/browse/OOZIE-3214
> Project: Oozie
> Issue Type: New Feature
> Components: coordinator
>Affects Versions: trunk
>Reporter: Julia Kinga Marton
>Assignee: Julia Kinga Marton
>Priority: Major
>
> Right now in case of coordinators only daylight saving time corrections are
> applied, the processing timezone for the coordinators is always the Oozie
> processing timezone.
> It would be more transparent to have an option for changing the {{timezone}}
> attribute itself, such as an additional attribute in the {{coordinator.xml}}
> (meaning a new version of {{coordinator.xsd}}). I would make this option
> switched off by default(to have the actual behavior).
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OOZIE-3214) Allow configurable timezone for coordinators
[
https://issues.apache.org/jira/browse/OOZIE-3214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16462421#comment-16462421
]
Peter Bacsko commented on OOZIE-3214:
-
OK, I found it. I'm linking this here as a reference, because it's important:
http://www.quartz-scheduler.org/documentation/best-practices#daylight-savings-time
This writes about {{CronTrigger}}, but it internally uses {{CronExpression}}:
https://github.com/quartz-scheduler/quartz/blob/master/quartz-core/src/main/java/org/quartz/impl/triggers/CronTriggerImpl.java#L76
> Allow configurable timezone for coordinators
>
>
> Key: OOZIE-3214
> URL: https://issues.apache.org/jira/browse/OOZIE-3214
> Project: Oozie
> Issue Type: New Feature
> Components: coordinator
>Affects Versions: trunk
>Reporter: Julia Kinga Marton
>Assignee: Julia Kinga Marton
>Priority: Major
>
> Right now in case of coordinators only daylight saving time corrections are
> applied, the processing timezone for the coordinators is always the Oozie
> processing timezone.
> It would be more transparent to have an option for changing the {{timezone}}
> attribute itself, such as an additional attribute in the {{coordinator.xml}}
> (meaning a new version of {{coordinator.xsd}}). I would make this option
> switched off by default(to have the actual behavior).
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OOZIE-3214) Allow configurable timezone for coordinators
[
https://issues.apache.org/jira/browse/OOZIE-3214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16462304#comment-16462304
]
Peter Bacsko commented on OOZIE-3214:
-
[~jphelps] then we need extra logic if we want to follow the approach of cron.
I have to double-check, but IIRC {{CronExpression}} does exactly the opposite,
ie. actions at 2am will be skipped in one direction and will be run twice 6
months later. If we want to correct this, we need extra calculations.
Also, we have to consider the case when we explicitly define execution times at
2am and 3am. When there is a change from 1:59:59 to 3:00:00, shall we start the
action twice?
> Allow configurable timezone for coordinators
>
>
> Key: OOZIE-3214
> URL: https://issues.apache.org/jira/browse/OOZIE-3214
> Project: Oozie
> Issue Type: New Feature
> Components: coordinator
>Affects Versions: trunk
>Reporter: Julia Kinga Marton
>Assignee: Julia Kinga Marton
>Priority: Major
>
> Right now in case of coordinators only daylight saving time corrections are
> applied, the processing timezone for the coordinators is always the Oozie
> processing timezone.
> It would be more transparent to have an option for changing the {{timezone}}
> attribute itself, such as an additional attribute in the {{coordinator.xml}}
> (meaning a new version of {{coordinator.xsd}}). I would make this option
> switched off by default(to have the actual behavior).
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OOZIE-3214) Allow configurable timezone for coordinators
[
https://issues.apache.org/jira/browse/OOZIE-3214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16462299#comment-16462299
]
Jason Phelps commented on OOZIE-3214:
-
[~orova], for consistency's sake, I believe that it should follow the same
behavior that the cron daemon does. See the [manpage for crond
|[https://linux.die.net/man/8/crond]]
{quote}If time has moved forward, those jobs that would have run in the
interval that has been skipped will be run immediately. Conversely, if time has
moved backward, care is taken to avoid running jobs twice.
{quote}
This means that in the winter to summer example, all of the jobs configured
during the skipped hour of 2:00 AM to 3:00 AM should run immediately at 3:00 AM.
In the summer to winter example, I think there is already [some error
checks|https://github.com/apache/oozie/blob/35451d50529634c9ce8730abe782bd4cf182b9a1/core/src/main/java/org/apache/oozie/command/coord/CoordMaterializeTransitionXCommand.java#L318]
that will stop the first instance of the job from running, so it may be easier
to keep as-is and have only the second execution to run, it will just need to
be documented
> Allow configurable timezone for coordinators
>
>
> Key: OOZIE-3214
> URL: https://issues.apache.org/jira/browse/OOZIE-3214
> Project: Oozie
> Issue Type: New Feature
> Components: coordinator
>Affects Versions: trunk
>Reporter: Julia Kinga Marton
>Assignee: Julia Kinga Marton
>Priority: Major
>
> Right now in case of coordinators only daylight saving time corrections are
> applied, the processing timezone for the coordinators is always the Oozie
> processing timezone.
> It would be more transparent to have an option for changing the {{timezone}}
> attribute itself, such as an additional attribute in the {{coordinator.xml}}
> (meaning a new version of {{coordinator.xsd}}). I would make this option
> switched off by default(to have the actual behavior).
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OOZIE-3214) Allow configurable timezone for coordinators
[
https://issues.apache.org/jira/browse/OOZIE-3214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16456586#comment-16456586
]
Peter Orova commented on OOZIE-3214:
+1 for the idea [~kmarton]. Changing the semantics of the timezone tag this way
in the coordinator.xml would definitely result a more natural interpretation of
the tag and thereby a better user experience.
Having said that, there is an area where a design decision needs to be made:
what happens to the workflows that are triggered in the time interval, omitted
or doubled by the DST change?
h2. Example from winter to summer:
Let us consider the US winter to summer change in 2018. The transition is the
following:
Sunday, 11 March 2018, *02:00:00* clocks were turned *forward* 1 hour to
Sunday, 11 March 2018, *03:00:00* local daylight time.
Question 1:
* What happens to a workflow that should be triggered at 2:30 on March 11?
Should it be 'forgotten'? Should it be compensated for by launching an instance
at 3:00 local daylight time?
h2. Example from summer to winter:
Let us consider the US summer to winter change in 2018. The transition is the
following:
Sunday, 4 November 2018, *02:00:00* clocks are turned *backward* 1 hour to
Sunday, 4 November 2018, *01:00:00* local standard time instead.
Question 2:
* What happens to a the workflow that is triggered at 1:30? Should it run
twice? Should the "second" execution be omitted?
> Allow configurable timezone for coordinators
>
>
> Key: OOZIE-3214
> URL: https://issues.apache.org/jira/browse/OOZIE-3214
> Project: Oozie
> Issue Type: New Feature
> Components: coordinator
>Affects Versions: trunk
>Reporter: Julia Kinga Marton
>Assignee: Julia Kinga Marton
>Priority: Major
>
> Right now in case of coordinators only daylight saving time corrections are
> applied, the processing timezone for the coordinators is always the Oozie
> processing timezone.
> It would be more transparent to have an option for changing the {{timezone}}
> attribute itself, such as an additional attribute in the {{coordinator.xml}}
> (meaning a new version of {{coordinator.xsd}}). I would make this option
> switched off by default(to have the actual behavior).
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
