[
https://issues.apache.org/jira/browse/SOLR-12611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566467#comment-16566467
]
Dawid Weiss commented on SOLR-12611:
------------------------------------
If it's just going to stay dormant, then I'd say object wait is a fine
solution. Or a Thread.sleep() with a large constant (why 100 millis if it can
be 24 hours...). I'd also make this thread a daemon thread so that the JVM can
terminate without even looking at it (and the test framework doesn't consider
it a live thread escaping the test?).
Also, I was just pointing out the fact, I'm not saying this is the right
solution to the problem. I understand your rationale, but if somebody can dump
a stack trace of all threads they can as well inspect the classpath (even that
of a running process) and get Solr's version from there? On the other hand, if
it helps with diagnostics, a dormant thread doesn't seem to hurt anybody much.
> 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: [email protected]
For additional commands, e-mail: [email protected]
