Wanted to resurrect this since it is time to set the clocks back this
weekend to see if any one knows if this issue was ever resolved/fixed
with remedy?
I am having my server rebooted this weekend just in case so it
recalculates the escalations.
Thanks,
Joelie Dudley
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of O'Hara, Jim
Sent: Thursday, November 03, 2005 12:44 PM
To: arslist@ARSLIST.ORG
Subject: Re: Time Change - Processes Running Twice
I tried doing this manually (disable escalations) in the admin tool
server settings, but it didn't reset the clock. I didn't keep retrying
to make sure, though. I just went for the bulk edit to toggle
escalations off and back on.
Jim O'Hara
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Axton
Sent: Thursday, November 03, 2005 9:36 AM
To: arslist@ARSLIST.ORG
Subject: Re: Time Change - Processes Running Twice
How about ARSetServerInfo for AR_SERVER_INFO_DISABLE_ESCALATIONS.
This is a server setting that disables all escalations.
#define AR_SERVER_INFO_DISABLE_ESCALATIONS 143
/* int - 0 - enabled */
/*1 - not enabled */
And I was starting to think that only the java documentation was missing
the constant listings provided in the c header files ;)
Axton
On 11/3/05, Thomas Bean [EMAIL PROTECTED] wrote:
**
The enable column in the escalation table stores the
enabled/disabled flag, but I doubt that resetting this value at the db
level outside of the Admin tool would have any effect until ARS has
been restarted. The arsignal -g command is supposed to force a
reload of the data dictionary, but I'm not sure if this would work
without testing it.
--Thomas
- Original Message -
From: Rick Cook
Newsgroups: gmane.comp.crm.arsystem.general
Sent: Thursday, November 03, 2005 09:50
Subject: Re: Time Change - Processes Running Twice
**
I haven't investigated the API call, either, but I was envisioning the
script being directed by the O/S, not by the ARS. How about a stored
procedure? Is that setting stored in metadata somewhere? I don't
recall seeing it.
Rick
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of Thomas Bean
Sent: Thursday, November 03, 2005 7:27 AM
To: arslist@ARSLIST.ORG
Subject: Re: Time Change - Processes Running Twice
**
Disabling/re-enabling an escalation resets the offset calculation, so
that should work. However, I'm unfamiliar with the API that would be
needed to accomplish this. Also, assuming the script itself would not
be run via an escalation, how should the script be scheduled?
--Thomas
- Original Message -
From: Rick Cook
Newsgroups: gmane.comp.crm.arsystem.general
Sent: Wednesday, November 02, 2005 17:26
Subject: Re: Time Change - Processes Running Twice
I see your point, Thomas. How about a solution that included a script
sending an API call to turn off and back on the Escalations? Wouldn't
that be a simpler and less obtrusive call than bouncing the AR System
processes, and simpler than recalculating the time criteria, since the
reset would reload the time cache?
Rick
From: Action Request System discussion list(ARSList) on behalf of
Thomas Bean
Sent: Wed 11/2/2005 2:47 PM
To: arslist@ARSLIST.ORG
Subject: Re: Time Change - Processes Running Twice
**
Rick,
It doesn't really matter whether the escalations are scheduled between
2:00 AM and 3:00 AM. Example:
Escalation is scheduled to run at 7:00 AM daily.
1. Escalation fires at 7:00 AM (Daylight Saving Time) on
Saturday,
October 29, 2005.
2. Escalation queue (incorrectly) determines next occurrence of
7:00 AM
is 86400 seconds (24 hours) in the future and schedules the next
execution of the escalation for this interval, which will be one hour
earlier than it should be due to pending time change. Correct
interval is 25 hours (9 seconds).
3. Local time reverts to standard time at 1:59:59 AM on Sunday,
October
30, 2005 (clock is set back to 1:00:00 AM).
4. Escalation fires at 6:00 AM (Standard Time) on Sunday,
October, 30,
2005. This is 24 hours since the last execution, but it is an hour
early per the standard time clock.
5. Escalation queue determines next occurrence of 7:00 AM is 3600
seconds (1 hour) in the future and schedules the next execution of the
escalation for this interval.
6. Escalation fires a second time at 7:00 AM (Standard Time).
So, this design flaw in the escalation queue causes all time-based
escalations to fire twice the first time they run following a time
change from Daylight Saving/Summer Time to standard time (once an hour
early, and again at the scheduled time). This same flaw causes all
time-based escalations to fire an hour
