net.corda.node.services.events

## Class NodeSchedulerService

- SingletonSerializeAsToken
- - net.corda.node.services.events.NodeSchedulerService

- All Implemented Interfaces:
    SchedulerService, SerializeAsToken

      public class NodeSchedulerService
      extends SingletonSerializeAsToken
      implements SchedulerService

  A first pass of a simple `interface SchedulerService` that works with `class MutableClock`s for testing, demonstrations and simulations that also encompasses the Vault observer for processing transactions.

  This will observe transactions as they are stored and schedule and unschedule activities based on the States consumed or produced.

  Currently does not provide any system state other than the ContractState so the expectation is that a transaction is the outcome of the activity in order to schedule another activity. Once we have implemented more persistence in the nodes, maybe we can consider multiple activities and whether the activities have been completed or not, but that starts to sound a lot like off-ledger state.

  See Also:
    `interface SchedulerService`, `class MutableClock`, Vault

- - ### Nested Class Summary

    Nested Classes
    Modifier and Type | Class and Description
    --- | ---
    `static class` | `NodeSchedulerService.RunScheduled`

  - ### Constructor Summary

    Constructors
    Constructor and Description
    `NodeSchedulerService(org.jetbrains.exposed.sql.Database database, ServiceHubInternal services, FlowLogicRefFactory flowLogicRefFactory, java.util.concurrent.Executor schedulerTimerExecutor, org.apache.activemq.artemis.utils.ReusableLatch unfinishedSchedules)` A first pass of a simple `interface SchedulerService` that works with `class MutableClock`s for testing, demonstrations and simulations that also encompasses the Vault observer for processing transactions.

  - ### Method Summary

    All Methods Instance Methods Concrete Methods
    Modifier and Type | Method and Description
    --- | ---
    `void` | `scheduleStateActivity(ScheduledStateRef action)` Schedule a new activity for a TX output, probably because it was just produced.
    `void` | `start()`
    `void` | `unscheduleStateActivity(StateRef ref)` Unschedule all activity for a TX output, probably because it was consumed.

    - ### Methods inherited from class net.corda.core.serialization.SingletonSerializeAsToken

      `toToken`

    - ### Methods inherited from interface net.corda.core.node.services.SchedulerService

      `scheduleStateActivity, unscheduleStateActivity`

    - ### Methods inherited from interface net.corda.core.serialization.SerializeAsToken

      `toToken`

- - ### Constructor Detail

    - #### NodeSchedulerService

          public NodeSchedulerService(org.jetbrains.exposed.sql.Database database,
                                      ServiceHubInternal services,
                                      FlowLogicRefFactory flowLogicRefFactory,
                                      java.util.concurrent.Executor schedulerTimerExecutor,
                                      org.apache.activemq.artemis.utils.ReusableLatch unfinishedSchedules)

      A first pass of a simple `interface SchedulerService` that works with `class MutableClock`s for testing, demonstrations and simulations that also encompasses the Vault observer for processing transactions.

      This will observe transactions as they are stored and schedule and unschedule activities based on the States consumed or produced.

      Currently does not provide any system state other than the ContractState so the expectation is that a transaction is the outcome of the activity in order to schedule another activity. Once we have implemented more persistence in the nodes, maybe we can consider multiple activities and whether the activities have been completed or not, but that starts to sound a lot like off-ledger state.

      Parameters:
        `services` - Core node services.
        `flowLogicRefFactory` - Factory for restoring `class FlowLogic` instances from references.
        `schedulerTimerExecutor` - The executor the scheduler blocks on waiting for the clock to advance to the next activity. Only replace this for unit testing purposes. This is not the executor the `class FlowLogic` is launched on.
      See Also:
        `interface SchedulerService`, `class MutableClock`, Vault

  - ### Method Detail

    - #### start

          public void start()

    - #### scheduleStateActivity

          public void scheduleStateActivity(ScheduledStateRef action)

      Schedule a new activity for a TX output, probably because it was just produced.

      Only one activity can be scheduled for a particular `class StateRef` at any one time. Scheduling a `class ScheduledStateRef` replaces any previously scheduled `class ScheduledStateRef` for any one `class StateRef`.

      See Also:
        `class StateRef`, `class ScheduledStateRef`, `class ScheduledStateRef`, `class StateRef`

    - #### unscheduleStateActivity

          public void unscheduleStateActivity(StateRef ref)

      Unschedule all activity for a TX output, probably because it was consumed.