[ 
https://issues.apache.org/jira/browse/SOLR-7803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14631321#comment-14631321
 ] 

Uwe Schindler commented on SOLR-7803:
-------------------------------------

OK thanks. I think we can look into this, but the easiest implementation to 
work around such problems is to do it in a similar way like LUCENE-6482: define 
a static inner (hidden) class that just have one static field: See the "Holder" 
class in the patch there. Then replace all references to this static field by 
"Holder.staticField". This delays the initialization. This is much easier than 
your patch.

Although, I don't think that this is the reason for the problem. A superclass 
is always allowed to load and instantiate a subclass, this is specified in the 
JVM. It only gets worse if you have this type of stuff around three classes. In 
any case, such Holder instances always prevent such problems.

In my opinion, the correct fix for the "bad" design we have here is (unrelated 
to the class loading deadlock): Refactor the date parsing stuff to a separate 
Utility class with solely static methods and don't use a TrieDateField instance 
from the superclass. Both TrieField and TrieDateField use the same set of 
static methods. The current design is broken, I agree!

Do you have a testcase to reproduce?

> Classloading deadlock in TrieField
> ----------------------------------
>
>                 Key: SOLR-7803
>                 URL: https://issues.apache.org/jira/browse/SOLR-7803
>             Project: Solr
>          Issue Type: Bug
>    Affects Versions: 5.2.1
>         Environment: OSX, JDK8u45
>            Reporter: Markus Heiden
>            Priority: Critical
>              Labels: patch
>         Attachments: TrieField.patch
>
>
> When starting a test Sol instance, it locks up sometimes. We took a thread 
> dump and all threads are trying to load classes via Class.forName() and are 
> stuck in that method. One of these threads got one step further into the 
> <clinit> of TrieField where it creates an internal static instance of 
> TrieDateField (circular dependency). I don't know why this locks up exactly, 
> but this code smells anyway. So I removed that instance and made the used 
> methods static in TrieDateField.
> This does not completely remove the circular dependency, but at least it is 
> no more in <clinit>. For the future someone may extract a util class to 
> remove the circular dependency.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to