package time
- Alphabetic
- Public
- Protected
Type Members
- final case class AwaitTimeRequest(domainIdO: Option[DomainId], timestamp: CantonTimestamp) extends Product with Serializable
- abstract class Clock extends TimeProvider with AutoCloseable with NamedLogging
A clock returning the current time, but with a twist: it always returns unique timestamps.
A clock returning the current time, but with a twist: it always returns unique timestamps. If two calls are made to the same clock instance at the same time (according to the resolution of this clock), one of the calls will block, until it can return a unique value.
All public functions are thread-safe.
- class DelegatingSimClock extends SimClock
This implementation allows us to control many independent sim clocks at the same time.
This implementation allows us to control many independent sim clocks at the same time. Possible race conditions that might happen with concurrent start/stop of clocks are not being addressed but are currently unlikely to happen.
- class DomainTimeTracker extends NamedLogging with FlagCloseable with HasFlushFuture
Provides a variety of methods for tracking time on the domain.
Provides a variety of methods for tracking time on the domain.
- fetchTime and fetchTimeProof allows for proactively asking for a recent time or time proof.
- requestTick asks the tracker to ensure that an event is witnessed for the given time or greater (useful for timeouts).
- awaitTick will return a future to wait for the given time being reached on the target domain.
We currently assume that the domain and our host are roughly synchronized and typically won't expect to see a time on a domain until we have passed that point on our local clock. We then wait for
observationLatency
past the timestamp we are expecting to elapse on our local clock as transmission of an event with that timestamp will still take some time to arrive at our host. This avoids frequently asking for times before we've reached the timestamps we're looking for locally.We also take into account a
patienceDuration
that will cause us to defer asking for a time if we have recently seen events for the domain. This is particularly useful if we are significantly behind and reading many old events from the domain.If no activity is happening on the domain we will try to ensure that we have observed an event at least once during the
minObservationDuration
. - final case class FetchTimeRequest(domainIdO: Option[DomainId], freshnessBound: NonNegativeFiniteDuration) extends Product with Serializable
- final case class FetchTimeResponse(timestamp: CantonTimestamp) extends Product with Serializable
- trait HasUptime extends AnyRef
- final case class NonNegativeFiniteDuration extends RefinedDuration with PrettyPrinting with Product with Serializable
- final case class NonNegativeSeconds extends RefinedDuration with PrettyPrinting with Product with Serializable
- class PeriodicAction extends NamedLogging with FlagCloseable
- final case class PositiveFiniteDuration extends RefinedDuration with PrettyPrinting with Product with Serializable
- final case class PositiveSeconds extends RefinedDuration with PrettyPrinting with Product with Serializable
- sealed trait RefinedDuration extends Ordered[RefinedDuration]
- trait RefinedDurationCompanion[RD <: RefinedDuration] extends AnyRef
- class RemoteClock extends Clock with NamedLogging
- class SimClock extends Clock with NamedLogging
- class TestingTimeService extends AnyRef
- trait TickTock extends AnyRef
- trait TimeAwaiter extends AnyRef
Utility to implement a time awaiter
Utility to implement a time awaiter
Note, you need to invoke expireOnShutdown onClosed
- trait TimeProofRequestSubmitter extends AutoCloseable
Use fetchTimeProof to fetch a time proof we observe from the sequencer via handleTimeProof.
Use fetchTimeProof to fetch a time proof we observe from the sequencer via handleTimeProof. Will batch fetch calls so there is only a single request occurring at any point.
The submission of this request to the sequencer is slightly more involved than usual as we do not rely at all on domain time as this component is primarily used when the domain time is likely unknown or stale. Instead we use the the local node clock for retries.
Future optimizations:
- Most scenarios don't need a time event specifically and instead just need any event to cause a "tick". In these cases we could short circuit and cancel a pending request when receiving any event with a timestamp. However this would only optimize our retry loop so the distinction doesn't currently feel anywhere near worthwhile.
- trait TimeProvider extends AnyRef
- class WallClock extends Clock with NamedLogging
Value Members
- object AwaitTimeRequest extends Serializable
- object Clock extends ClockErrorGroup
- object DomainTimeTracker
- object FetchTimeRequest extends Serializable
- object FetchTimeResponse extends Serializable
- object GrpcDomainTimeService
- object NonNegativeFiniteDuration extends RefinedDurationCompanion[NonNegativeFiniteDuration] with Serializable
- object NonNegativeSeconds extends RefinedDurationCompanion[NonNegativeSeconds] with Serializable
- object PositiveFiniteDuration extends RefinedDurationCompanion[PositiveFiniteDuration] with Serializable
- object PositiveSeconds extends RefinedDurationCompanion[PositiveSeconds] with Serializable
- object TickTock
- object TimeProofRequestSubmitter
- object TimeProofRequestSubmitterImpl