[
https://issues.apache.org/jira/browse/SOLR-7419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14502760#comment-14502760
]
Steve Rowe commented on SOLR-7419:
----------------------------------
bq. Yes, on overflow the JVM circles back to MIN_VALUE so even though it works
fine, I don't see a reason for the initialValue to be assigned this way.
The idea is to put {{timeoutAt}} as far in the future as possible, so that it
effectively never happens.
bq. In this case, we should just set the initial value to Long.MAX_VALUE
I don't think that will work, since nanoTime() values can be anything from
Long.MIN_VALUE to Long.MAX_VALUE - that's my interpretation anyway of this from
[the {{nanoTime()}}
javadocs|https://docs.oracle.com/javase/8/docs/api/java/lang/System.html#nanoTime--]:
{quote}
This method can only be used to measure elapsed time and is not related to any
other notion of system or wall-clock time. The value returned represents
nanoseconds since some fixed but arbitrary origin time (perhaps in the future,
so values may be negative).
{quote}
> Initial value of thread local in SolrQueryTimeoutImpl overflows a long
> ----------------------------------------------------------------------
>
> Key: SOLR-7419
> URL: https://issues.apache.org/jira/browse/SOLR-7419
> Project: Solr
> Issue Type: Bug
> Components: search
> Affects Versions: 4.10.4, 5.1
> Reporter: Shalin Shekhar Mangar
> Priority: Trivial
> Fix For: Trunk, 5.2
>
>
> Same as the title.
> {code}
> /**
> * The ThreadLocal variable to store the time beyond which, the processing
> should exit.
> */
> public static ThreadLocal<Long> timeoutAt = new ThreadLocal<Long>() {
> @Override
> protected Long initialValue() {
> return nanoTime() + Long.MAX_VALUE;
> }
> };
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
