Clarify javadocs related to ProgressTracker

Change-Id: Ie208037ec2759d15c4eff86315389968e76c07bc
Signed-off-by: Vratko Polak <vrpolak@cisco.com>

diff --git a/opendaylight/md-sal/cds-access-client/src/main/java/org/opendaylight/controller/cluster/access/client/AveragingProgressTracker.java b/opendaylight/md-sal/cds-access-client/src/main/java/org/opendaylight/controller/cluster/access/client/AveragingProgressTracker.java
index 1c6210a9208e5645ce806e8294d63eb123601bba..fe7b91f9ddad311f8cec794a5251f379049e6ac8 100644 (file)
--- a/opendaylight/md-sal/cds-access-client/src/main/java/org/opendaylight/controller/cluster/access/client/AveragingProgressTracker.java
+++ b/opendaylight/md-sal/cds-access-client/src/main/java/org/opendaylight/controller/cluster/access/client/AveragingProgressTracker.java
@@ -17,8 +17,9 @@ import javax.annotation.concurrent.NotThreadSafe;
  * <p>This class has {@code tasksOpenLimit} used as a (weak) limit,
  * as number of open tasks approaches that value, delays computed are increasing.
  *
- * <p>In order to keep delays from raising to unreasonably high values,
- * a maximal delay (per task) value is never exceeded.
+ * <p>In order to keep {@code estimateIsolatedDelay} values from raising unreasonably high,
+ * {@code defaultTicksPerTask} acts as a maximal value. {@code openTask} may return
+ * higher value if there are tasks above the limit.
  *
  * <p>On the other hand, there is no delay when number of open tasks is half the limit or less,
  * in order to prevent backend from running out of tasks while there may be waiting frontend threads.

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..25b7d7edc94f5b97cf22c61536db872850461b8b 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
@@ -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
  */