Make AbstractClientConnection timeouts configurable

[controller.git] / opendaylight / md-sal / cds-access-client / src / main / java / org / opendaylight / controller / cluster / access / client / ProgressTracker.java

diff --git a/opendaylight/md-sal/cds-access-client/src/main/java/org/opendaylight/controller/cluster/access/client/ProgressTracker.java b/opendaylight/md-sal/cds-access-client/src/main/java/org/opendaylight/controller/cluster/access/client/ProgressTracker.java
index 024141a040e0af27b25cb7e77b62c1fafaed914d..699c102297373bd11397efcb095c406730076c00 100644 (file)
--- a/opendaylight/md-sal/cds-access-client/src/main/java/org/opendaylight/controller/cluster/access/client/ProgressTracker.java
+++ b/opendaylight/md-sal/cds-access-client/src/main/java/org/opendaylight/controller/cluster/access/client/ProgressTracker.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2016 Cisco Systems, Inc. and others.  All rights reserved.
+ * Copyright (c) 2016, 2017 Cisco Systems, Inc. and others.  All rights reserved.
  *
  * This program and the accompanying materials are made available under the
  * terms of the Eclipse Public License v1.0 which accompanies this distribution,
@@ -23,12 +23,12 @@ import org.slf4j.LoggerFactory;
  * In terms of taks processing, frontend is "opening" tasks and backend is "closing" them.
  * Latency of the backend may fluctuate wildly. To avoid backend running out of open tasks,
  * there should be a queue of requests frontend can add to.
- * In order to avoid excessive memore consumption, there should be a back-pressure mechanism
+ * In order to avoid excessive memory consumption, there should be a back-pressure mechanism
  * which blocks the frontend threads for appropriate durations.
  * Frontend can tolerate moderately delayed responses, but it only tolerates small block times.
  *
  * <p>An ideal back-pressure algorithm would keep the queue reasonably full,
- * while fairly delaying frontend threads. In other words, backend idle time should be low,
+ * while fairly delaying the frontend threads. In other words, backend idle time should be low,
  * as well as frontend block time dispersion
  * (as opposed to block time average, which is dictated by overall performance).
  *
@@ -40,7 +40,9 @@ import org.slf4j.LoggerFactory;
  *
  * <p>This class is not thread safe, the callers are responsible for guarding against conflicting access.
  * Time is measured in ticks (nanos), methods never look at current time, relying on {@code now} argument instead.
- * Input data used for tracking is tightly coupled with TransitQueue#recordCompletion arguments.
+ * This means the sequence of {$code now} argument values is expected to be non-decreasing.
+ *
+ * <p>Input data used for tracking is tightly coupled with TransitQueue#recordCompletion arguments.
  *
  * @author Vratko Polak
  */
@@ -270,9 +272,9 @@ abstract class ProgressTracker {
      * This call can empty the collection of open tasks, that special case should be handled.
      *
      * @param now tick number corresponding to caller's present
-     * @param enqueuedTicks see TransitQueue#recordCompletion
-     * @param transmitTicks see TransitQueue#recordCompletion
-     * @param execNanos see TransitQueue#recordCompletion
+     * @param enqueuedTicks see TransmitQueue#recordCompletion
+     * @param transmitTicks see TransmitQueue#recordCompletion
+     * @param execNanos see TransmitQueue#recordCompletion
      */
     protected void protectedCloseTask(final long now, final long enqueuedTicks, final long transmitTicks,
                 final long execNanos) {
@@ -304,5 +306,5 @@ abstract class ProgressTracker {
      * @param now tick number corresponding to caller's present
      * @return delay (in ticks) after which another openTask() would be fair to be called by the same thread again
      */
-    abstract long estimateIsolatedDelay(final long now);
+    abstract long estimateIsolatedDelay(long now);
 }