[
https://issues.apache.org/jira/browse/SOLR-12611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16565935#comment-16565935
]
Shawn Heisey commented on SOLR-12611:
-------------------------------------
Thanks for looking, [~dweiss]!
I'm not well-versed in how to properly handle this kind of code. Your change
would be easy.
I did have a different idea that I considered, which might be even more
bulletproof, but it's probably less efficient. It would involve an
AtomicBoolean object and this code in the thread:
{code:java}
while (versionThreadRun.get()) {
try {
Thread.sleep(100);
} catch (InterruptedException e) {
}
}
{code}
I figure there are two criteria to satisfy with the "do nothing"
implementation, and I'm not sure what the best options are: 1) Code must be
bulletproof. 2) Code must use as little CPU and memory as possible.
> Add version information to thread dump
> --------------------------------------
>
> Key: SOLR-12611
> URL: https://issues.apache.org/jira/browse/SOLR-12611
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 7.4
> Reporter: Shawn Heisey
> Priority: Trivial
> Attachments: SOLR-12611.patch
>
>
> Thread dumps contain stacktrace info. Without knowing the Solr version, it
> can be difficult to compare stacktraces to source code.
> If exact version information is available in the thread dump, it will be
> possible to look at source code to understand stacktrace information. If
> *full* version information is present, then it would even be possible to
> learn whether the user is running an official binary build or if they have
> built Solr themselves.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
