Interface TimerScheduler<T>
- All Known Subinterfaces:
TimerSchedulerCrossDslSupport<T>
self messages in an actor.
It is used with Behaviors.withTimers.
Timers are bound to the lifecycle of the actor that owns it,
and thus are cancelled automatically when it is restarted or stopped.
TimerScheduler is not thread-safe, i.e. it must only be used within
the actor that owns it.
Not for user extension.
-
Method Summary
Modifier and TypeMethodDescriptionvoidCancel a timer with a givenkey.voidCancel all timers.booleanisTimerActive(Object key) Check if a timer with a givenkeyis active.voidstartSingleTimer(Object key, T msg, scala.concurrent.duration.FiniteDuration delay) Start a timer that will sendmsgonce to theselfactor after the givendelay.voidstartSingleTimer(T msg, scala.concurrent.duration.FiniteDuration delay) Start a timer that will sendmsgonce to theselfactor after the givendelay.voidstartTimerAtFixedRate(Object key, T msg, scala.concurrent.duration.FiniteDuration interval) Schedules a message to be sent repeatedly to theselfactor with a given frequency.voidstartTimerAtFixedRate(Object key, T msg, scala.concurrent.duration.FiniteDuration initialDelay, scala.concurrent.duration.FiniteDuration interval) Schedules a message to be sent repeatedly to theselfactor with a given frequency.voidstartTimerAtFixedRate(T msg, scala.concurrent.duration.FiniteDuration interval) Schedules a message to be sent repeatedly to theselfactor with a given frequency.voidstartTimerAtFixedRate(T msg, scala.concurrent.duration.FiniteDuration initialDelay, scala.concurrent.duration.FiniteDuration interval) Schedules a message to be sent repeatedly to theselfactor with a given frequency.voidstartTimerWithFixedDelay(Object key, T msg, scala.concurrent.duration.FiniteDuration delay) Schedules a message to be sent repeatedly to theselfactor with a fixeddelaybetween messages.voidstartTimerWithFixedDelay(Object key, T msg, scala.concurrent.duration.FiniteDuration initialDelay, scala.concurrent.duration.FiniteDuration delay) Schedules a message to be sent repeatedly to theselfactor with a fixeddelaybetween messages after theinitialDelay.voidstartTimerWithFixedDelay(T msg, scala.concurrent.duration.FiniteDuration delay) Schedules a message to be sent repeatedly to theselfactor with a fixeddelaybetween messages.voidstartTimerWithFixedDelay(T msg, scala.concurrent.duration.FiniteDuration initialDelay, scala.concurrent.duration.FiniteDuration delay) Schedules a message to be sent repeatedly to theselfactor with a fixeddelaybetween messages after theinitialDelay.
-
Method Details
-
cancel
Cancel a timer with a givenkey. If canceling a timer that was already canceled, or key never was used to start a timer this operation will do nothing.It is guaranteed that a message from a canceled timer, including its previous incarnation for the same key, will not be received by the actor, even though the message might already be enqueued in the mailbox when cancel is called.
-
cancelAll
void cancelAll()Cancel all timers. -
isTimerActive
Check if a timer with a givenkeyis active. -
startSingleTimer
Start a timer that will sendmsgonce to theselfactor after the givendelay.Each timer has a key and if a new timer with same key is started the previous is cancelled. It is guaranteed that a message from the previous timer is not received, even if it was already enqueued in the mailbox when the new timer was started.
-
startSingleTimer
Start a timer that will sendmsgonce to theselfactor after the givendelay.If a new timer is started with the same message the previous is cancelled. It is guaranteed that a message from the previous timer is not received, even if it was already enqueued in the mailbox when the new timer was started. If you do not want this, you can start start them as individual timers by specifying distinct keys.
-
startTimerAtFixedRate
Schedules a message to be sent repeatedly to theselfactor with a given frequency.It will compensate the delay for a subsequent message if the sending of previous message was delayed more than specified. In such cases, the actual message interval will differ from the interval passed to the method.
If the execution is delayed longer than the
interval, the subsequent message will be sent immediately after the prior one. This also has the consequence that after long garbage collection pauses or other reasons when the JVM was suspended all "missed" messages will be sent when the process wakes up again.In the long run, the frequency of messages will be exactly the reciprocal of the specified
interval.Warning:
startTimerAtFixedRatecan result in bursts of scheduled messages after long garbage collection pauses, which may in worst case cause undesired load on the system. ThereforestartTimerWithFixedDelayis often preferred.Each timer has a key and if a new timer with same key is started the previous is cancelled. It is guaranteed that a message from the previous timer is not received, even if it was already enqueued in the mailbox when the new timer was started.
-
startTimerAtFixedRate
void startTimerAtFixedRate(Object key, T msg, scala.concurrent.duration.FiniteDuration initialDelay, scala.concurrent.duration.FiniteDuration interval) Schedules a message to be sent repeatedly to theselfactor with a given frequency.It will compensate the delay for a subsequent message if the sending of previous message was delayed more than specified. In such cases, the actual message interval will differ from the interval passed to the method.
If the execution is delayed longer than the
interval, the subsequent message will be sent immediately after the prior one. This also has the consequence that after long garbage collection pauses or other reasons when the JVM was suspended all "missed" messages will be sent when the process wakes up again.In the long run, the frequency of messages will be exactly the reciprocal of the specified
intervalafterinitialDelay.Warning:
startTimerAtFixedRatecan result in bursts of scheduled messages after long garbage collection pauses, which may in worst case cause undesired load on the system. ThereforestartTimerWithFixedDelayis often preferred.Each timer has a key and if a new timer with same key is started the previous is cancelled. It is guaranteed that a message from the previous timer is not received, even if it was already enqueued in the mailbox when the new timer was started.
-
startTimerAtFixedRate
Schedules a message to be sent repeatedly to theselfactor with a given frequency.It will compensate the delay for a subsequent message if the sending of previous message was delayed more than specified. In such cases, the actual message interval will differ from the interval passed to the method.
If the execution is delayed longer than the
interval, the subsequent message will be sent immediately after the prior one. This also has the consequence that after long garbage collection pauses or other reasons when the JVM was suspended all "missed" messages will be sent when the process wakes up again.In the long run, the frequency of messages will be exactly the reciprocal of the specified
interval.Warning:
startTimerAtFixedRatecan result in bursts of scheduled messages after long garbage collection pauses, which may in worst case cause undesired load on the system. ThereforestartTimerWithFixedDelayis often preferred.When a new timer is started with the same message the previous is cancelled. It is guaranteed that a message from the previous timer is not received, even if it was already enqueued in the mailbox when the new timer was started. If you do not want this, you can start start them as individual timers by specifying distinct keys.
-
startTimerAtFixedRate
void startTimerAtFixedRate(T msg, scala.concurrent.duration.FiniteDuration initialDelay, scala.concurrent.duration.FiniteDuration interval) Schedules a message to be sent repeatedly to theselfactor with a given frequency.It will compensate the delay for a subsequent message if the sending of previous message was delayed more than specified. In such cases, the actual message interval will differ from the interval passed to the method.
If the execution is delayed longer than the
interval, the subsequent message will be sent immediately after the prior one. This also has the consequence that after long garbage collection pauses or other reasons when the JVM was suspended all "missed" messages will be sent when the process wakes up again.In the long run, the frequency of messages will be exactly the reciprocal of the specified
intervalafterinitialDelay.Warning:
startTimerAtFixedRatecan result in bursts of scheduled messages after long garbage collection pauses, which may in worst case cause undesired load on the system. ThereforestartTimerWithFixedDelayis often preferred.When a new timer is started with the same message the previous is cancelled. It is guaranteed that a message from the previous timer is not received, even if it was already enqueued in the mailbox when the new timer was started. If you do not want this, you can start start them as individual timers by specifying distinct keys.
-
startTimerWithFixedDelay
Schedules a message to be sent repeatedly to theselfactor with a fixeddelaybetween messages.It will not compensate the delay between messages if scheduling is delayed longer than specified for some reason. The delay between sending of subsequent messages will always be (at least) the given
delay.In the long run, the frequency of messages will generally be slightly lower than the reciprocal of the specified
delay.Each timer has a key and if a new timer with same key is started the previous is cancelled. It is guaranteed that a message from the previous timer is not received, even if it was already be enqueued in the mailbox before the new timer was started.
-
startTimerWithFixedDelay
void startTimerWithFixedDelay(Object key, T msg, scala.concurrent.duration.FiniteDuration initialDelay, scala.concurrent.duration.FiniteDuration delay) Schedules a message to be sent repeatedly to theselfactor with a fixeddelaybetween messages after theinitialDelay.It will not compensate the delay between messages if scheduling is delayed longer than specified for some reason. The delay between sending of subsequent messages will always be (at least) the given
delay.In the long run, the frequency of messages will generally be slightly lower than the reciprocal of the specified
delay.Each timer has a key and if a new timer with same key is started the previous is cancelled. It is guaranteed that a message from the previous timer is not received, even if it was already be enqueued in the mailbox before the new timer was started.
-
startTimerWithFixedDelay
Schedules a message to be sent repeatedly to theselfactor with a fixeddelaybetween messages.It will not compensate the delay between messages if scheduling is delayed longer than specified for some reason. The delay between sending of subsequent messages will always be (at least) the given
delay.In the long run, the frequency of messages will generally be slightly lower than the reciprocal of the specified
delay.When a new timer is started with the same message, the previous is cancelled. It is guaranteed that a message from the previous timer is not received, even if it was already enqueued in the mailbox when the new timer was started. If you do not want this, you can start start them as individual timers by specifying distinct keys.
-
startTimerWithFixedDelay
void startTimerWithFixedDelay(T msg, scala.concurrent.duration.FiniteDuration initialDelay, scala.concurrent.duration.FiniteDuration delay) Schedules a message to be sent repeatedly to theselfactor with a fixeddelaybetween messages after theinitialDelay.It will not compensate the delay between messages if scheduling is delayed longer than specified for some reason. The delay between sending of subsequent messages will always be (at least) the given
delay.In the long run, the frequency of messages will generally be slightly lower than the reciprocal of the specified
delay.When a new timer is started with the same message, the previous is cancelled. It is guaranteed that a message from the previous timer is not received, even if it was already enqueued in the mailbox when the new timer was started. If you do not want this, you can start start them as individual timers by specifying distinct keys.
-