From 0bc9c7821dfbbb537d2e4b53294a10b2bef4327c Mon Sep 17 00:00:00 2001
From: Steven Rowe <sarowe@apache.org>
Date: Mon, 20 Apr 2015 14:25:52 +0000
Subject: [PATCH] SOLR-7419: document intentional overflow in
 SolrQueryTimeoutImpl thread local

git-svn-id: https://svn.apache.org/repos/asf/lucene/dev/trunk@1674866 13f79535-47bb-0310-9956-ffa450edef68
---
 .../solr/search/SolrQueryTimeoutImpl.java       | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/solr/core/src/java/org/apache/solr/search/SolrQueryTimeoutImpl.java b/solr/core/src/java/org/apache/solr/search/SolrQueryTimeoutImpl.java
index 232685bda47..2ff09900cf7 100644
--- a/solr/core/src/java/org/apache/solr/search/SolrQueryTimeoutImpl.java
+++ b/solr/core/src/java/org/apache/solr/search/SolrQueryTimeoutImpl.java
@@ -33,6 +33,23 @@ public class SolrQueryTimeoutImpl implements QueryTimeout {
    * The ThreadLocal variable to store the time beyond which, the processing should exit.
    */
   public static ThreadLocal<Long> timeoutAt = new ThreadLocal<Long>() {
+    /**
+     * {@inheritDoc}
+     * <p>
+     * By default, timeoutAt is set as far in the future as possible, 
+     * so that it effectively never happens.
+     * <p>
+     * Since nanoTime() values can be anything from Long.MIN_VALUE to
+     * Long.MAX_VALUE, adding Long.MAX_VALUE can cause overflow.  That's
+     * expected and works fine, since in that case the subtraction of a
+     * future nanoTime() value from timeoutAt (in 
+     * {@link SolrQueryTimeoutImpl#shouldExit}) will result in underflow,
+     * and checking the sign of the result of that subtraction (via
+     * comparison to zero) will correctly indicate whether the future
+     * nanoTime() value has exceeded the timeoutAt value.
+     * <p> 
+     * See {@link System#nanoTime}
+     */
     @Override
     protected Long initialValue() {
       return nanoTime() + Long.MAX_VALUE;