EB Schedules comment gives wrong time format
Carol Wapshere 11 years ago • updated by anonymous 7 years ago • 7
When setting a schedule in EB it tels me to enter the frequency as "hh:mm:ss". So I tried entering "24:00:00" for 1 day, and instead that was 24 days/ Seems to comment should probably say "dd:hh:mm".
Customer support service by UserEcho
Actually it looks like the problem is somewhere else.
I changed the frequency to 1:00:00 and on the Operations page it said "10 hours until next run" which looked correct - but then it actually ran the job every hour.
So now I've gone back to 24:00:00 and it's telling me "3 weeks until next run".
Tony is looking in to this right now. Currently it appears that the problem only applies to our documentation; the behaviour of TimeSpan is to treat anything with an hours value of 24 or higher as days, so '23:00:00 would' be 23 hours, but '24:00:00' would be 24 days. 1 day can be represented by '1.00:00:00'.
I believe this would explain everything except for the second sentence in your most recent comment - '1:00:00' should be 1 hour, not 10, so it may warrant further investigation.
The reason it said 10 hours to go was because I had the start time set to 1am, so setting it to "1:00:00" appeared to be giving the correct once per day behaviour - and then went ahead and ran it hourly anyway. So either way there is a disagreement between the "x hours to go" statement and the actual schedule.
The second issue sounds quite similar to a problem encountered recently; namely, a number of schedules would execute completely incongruously to their displayed values. In all these circumstances the display value was correct, but the operation list would begin execution too early/late.
This was traced back to an operational issue with how the schedules were being persisted in EB, specifically after being updated.
On update, the schedule configuration would be updated and the timing would be registered to run - but the existing conflicting timing was not removed and as such the operation list would be run separate to the displayed schedule on a separate older schedule.
Does this sound similar to the behaviour you've been seeing?
These orphaned timings are only persisted in memory, not in the configuration, so restarting the service should fix this issue if its pressing. Either way, if this is the problem you've hit then it's been resolved and will be fixed in the next version of EB (3.0.1) which is the current release candidate.
Assigned for confirmation.
That was it! I restarted the service and then left it set to 1:00:00 overnight, and the job only ran once.
Also I've now set it to "Run at this time every number of days" which I probably should have chose in the first instance, but I wanted to provide you with feedback about this service reset thing.
Workaround is restarting the service