Class Dispatcher.RequestTime

  • Enclosing class:
    Dispatcher

    public static class Dispatcher.RequestTime
    extends java.lang.Object
    • Constructor Summary

      Constructors 
      Constructor Description
      RequestTime​(long createdAtNanos)  
      RequestTime​(long enqueuedAtNanos, long startedAtNanos)  
    • Method Summary

      All Methods Static Methods Instance Methods Concrete Methods 
      Modifier and Type Method Description
      long baseTimeNanos()
      Base time is used by timeouts, and can be set to either when the request was added to the queue, or when the processing has started, which is controlled by DatabaseDescriptor.getCQLStartTime() Since client read/write timeouts are usually aligned with server-side timeouts, it is desireable to use enqueue time as a base.
      long clientDeadline()  
      long computeDeadline​(long verbExpiresAfterNanos)
      Given the current time and a base timeout for the verb return a request's expiration deadline, the time at which it becomes eligible for load shedding.
      long computeTimeout​(long now, long verbExpiresAfterNanos)  
      long enqueuedAtNanos()  
      static Dispatcher.RequestTime forImmediateExecution()  
      boolean shouldSendHints()
      No request should survive native request deadline, but in order to err on the side of caution, we have this swtich that allows hints to be submitted to mutation stage when cluster is potentially overloaded.
      long startedAtNanos()  
      long timeSpentInQueueNanos()  
      • Methods inherited from class java.lang.Object

        clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
    • Constructor Detail

      • RequestTime

        public RequestTime​(long createdAtNanos)
      • RequestTime

        public RequestTime​(long enqueuedAtNanos,
                           long startedAtNanos)
    • Method Detail

      • startedAtNanos

        public long startedAtNanos()
      • enqueuedAtNanos

        public long enqueuedAtNanos()
      • baseTimeNanos

        public long baseTimeNanos()
        Base time is used by timeouts, and can be set to either when the request was added to the queue, or when the processing has started, which is controlled by DatabaseDescriptor.getCQLStartTime() Since client read/write timeouts are usually aligned with server-side timeouts, it is desireable to use enqueue time as a base. However, since client removes the handler `readTimeoutMillis` (which is 12 seconds by default), the upper bound for any execution on the coordinator is 12 seconds (thanks to CASSANDRA-7392, any replica-side query is capped by the verb timeout), if REQUEST option is used. But even simply allowing such long timeouts also implicitly allows queues to grow large, since our queues are currently unbounded. Latency, however, is _always_ based on request processing time, since the amount of time that request spends in the queue is not a representative metric of replica performance.
      • computeDeadline

        public long computeDeadline​(long verbExpiresAfterNanos)
        Given the current time and a base timeout for the verb return a request's expiration deadline, the time at which it becomes eligible for load shedding. The two factors to consider are the per-verb and client timeouts. Both are calculated by subtracting the time already elapsed during the lifetime of the request from some base value. When deriving verb timeout, two alternative semantics are available. This timeout may represent either: * the total time available for a coordinator to process a client request and return its response * a time bound for a coordinator to send internode requests and gather responses from replicas The point from which elapsed time is measured here is configurable to accommodate these two different options. For the former, the clock starts when a client request is received and enqueued by the coordinator. For the latter, it starts when the request is dequeued by the coordinator and processing is started. See baseTimeNanos() for details. The client timeout represents how long the sender of a request is prepared to wait for a response. By implication, after this window has passed any further work done on the server side is wasted effort. Ideally, the base for this timeout would be set on a per-request basis but as this not currently supported in the protocol, it is configured uniformly for all requests. See DatabaseDescriptor.getNativeTransportTimeout(java.util.concurrent.TimeUnit). For this calculation, elapsed time is always measured from the point when a request is received and enqueued. Where verb timeout is based on queue admission, deadline computation is straightforward. The expiration deadline is simply the current time plus the smaller of the verb and client timeouts. However, if verb timeout is based on when the request is dequeued, the implications are more nuanced. In this scenario, while there may still be "headroom" available within the verb timeout, using it could exceed the client timeout (which is always based on admission time). For example: * Client timeout base is 10 (cb), verb timeout base is 5 (vb) * Request is enqueued at t1 (e) * Request is dequeued at t8 (d) * computeDeadline is called at t9 (n) If verb timeout is based on dequeuing, there would still some time remaining before a verb-based deadline. elapsed = (n - d) ; 1 timeout = (vb - elapsed) ; 4 deadline = (n + timeout) ; t13 ostensibly, the coordinator has until t13 to complete processing But as client timeout is measured from admission time, the request may exceeded the maximum wait period for the client sooner. elapsed = (n - e) ; 8 timeout = (cb - elapsed) ; 2 deadline = (n + timeout) ; t11 So the coordinator actually only has until t11 to complete processing, beyond then the client will not accept any response.
        Parameters:
        verbExpiresAfterNanos - the base timeout value for the verb being executed
        Returns:
        the point in time after which no further processing should occur
      • computeTimeout

        public long computeTimeout​(long now,
                                   long verbExpiresAfterNanos)
      • shouldSendHints

        public boolean shouldSendHints()
        No request should survive native request deadline, but in order to err on the side of caution, we have this swtich that allows hints to be submitted to mutation stage when cluster is potentially overloaded. Allowing hints to be not bound by deadline can exacerbate overload, but since there are also correctness implications, this seemed like a reasonable configuration option.
      • clientDeadline

        public long clientDeadline()
      • timeSpentInQueueNanos

        public long timeSpentInQueueNanos()