Skip to main content

B1P&D hourly Schedules fail to fire at prescribed times following service restart/reboot

Completed

Comments

11 comments

  • SSP Automation
    Thank you for your request.
    The development team have now added it to our internal planning-system for evaluation.
    [Internal Id: 13981]
  • Rasmus Jensen

    This is by design: Described here: https://support.boyum-it.com/hc/en-us/articles/360001389807-How-start-time-affect-hourly-and-minutly-schedules . Windows Scheduled tasks would do the same with their scheduled task. 

     

    But would love to hear other peoples comments on this.

  • Geoff Booth

    I agree with SSP Support UK on this.

    I don't have any minutely schedules but I do have several hourly events and definitely prefer them spaced out as originally set up. This is especially important when other have follow on routines.

  • Rasmus Jensen

    Ok, But let's say you have something running first time at 10:30 and every hour.

    I then restart the service at 12:00 on Monday... Would you then expect it to first run again Tuesday at 10:30?

    If not could you show me a setup of a Windows Scheduled task that would fit you desired scenario so we can get inspiration (btw: if critical you can already today let Scheduled tasks run the B1UP schedules instead of our schedule: https://support.boyum-it.com/hc/en-us/articles/115015716248-Running-server-component-tasks-manually)

  • Fernando Pescuma Aleixo

    Hi,

    I suppose we can handle the scenario by adding a [delay] field. So, in case of service restart, although all schedules will be set to the same time interval, the additional delay time will make them run independently.

    Of course, every schedule should have a different delay time.

  • SSP Support UK

    Hi Rasmus

    Here is an example of a Windows Scheduled Task that would fit the scenario.  I created the event at 11:10am.  Even though the event is set to fire at 9:15, it still fires at 11:15

    Alternatively, I believe Fernando's suggestion (above) would also fit the bill.

    Thanks

    Greig

  • Fernando Pescuma Aleixo

    Hi everyone, 

    Please vote for the idea, otherwise, it won't be prioritized. 

    Learn how to vote here:

    https://support.boyum-it.com/hc/en-us/articles/360001564487-How-to-join-our-Product-Community

    Many thanks,

    Fernando

  • Rasmus Jensen

    We have been talking about this internally. A few questions:

    - If we are to change it would you say it is an option in the schedule or just new behavior? (aka is there any scenario where the current way is desired?)

    Below is 3 scenarios. Would you say this is the correct expected behavior (Actual is how it works today and Expected is the suggested new way)?

    Setup 10:23 + 60 min schedule - Start time 12:00

    Run 12:00

    Run 13:00

    Run 14:00

    Run 15:00

    Restart 15:12

    Actual 15:12 Expected 16:00

    Actual 16:12 Expected 17:00

    Actual 17:12 Expected 18:00

     

    ****

    Setup 10:23 + 5 min schedule - Start time 12:00

    12:00 + every 5 min on the hour

    13:00 + every 5 min on the hour

    14:00 + every 5 min on the hour

    15:00

    15:05 

    Restart 15:12

    Actual 15:12 Expected 15:15

    Actual 15:17 Expected 15:20

    Actual 15:22 Expected 15:25

     

    ****

    Setup 10:23 + 180 min schedule - Start time 12:00

    12:00

    15:00

    Restart 17:45

    Actual 17:45 Expected 18:00

    Actual 20:45 Expected 21:00

    Actual 23:45 Expected 00:00

     

     

     

  • SSP Support UK

    Hi Rasmus

    I cannot think of a scenario where the current way is preferable (to keeping a gap between runs)

    Personally speaking, I think scenario 1 matches my 'expectations'

    Thanks

     

  • Fernando Pescuma Aleixo

    Hi Rasmus,

    The 1st scenario may have the same effect as my suggestion.

    It seems the only difference it's to properly set the start time @ different times.

    I would go for it as well.

  • SSP Automation
    The development team has now completed this request. Expect it to be in the next release of the product. Thank you again for helping us make the product better :-)

Please sign in to leave a comment.