[ 
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to