[
https://issues.apache.org/jira/browse/LUCENE-9661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17263514#comment-17263514
]
Namgyu Kim commented on LUCENE-9661:
------------------------------------
Thanks for your response [~mikemccand] and [~uschindler] :D
*To Mike*
{quote}Do you know if this corresponds to a recent change? It looks like
BaseTermsEnum was factored out in Feb 2019.
{quote}
This issue has occurred since the LUCENE-8292 you mentioned.
(commit id : a3a4ecd80b062d7567f4092fd43feb3e3f521333, commit link : [github
link|https://github.com/apache/lucene-solr/commit/4a513fa99f638cb65e0cae59bfdf7af410c0327a#diff-fb2691b9ff2d7f948692f45792a7ab6c7e730a2511e6289c3758b8888b49e84dL211-L219])
{quote}Hmm, I'm confused – it looks like your attached patch already has a
testDeadlock test case?
Is it difficult to make that real test (move it to a separate TestFooBar
source)?
Or, would that break the test, since it relies specifically on when
classloader inits TermsEnum and BaseTermsEnum?
{quote}
There wasn't enough explanation..
As Uwe said, my TC is meaningful only when the test is run the first time or
alone.
(Already initialized by other TCs)
*To Uwe*
{quote}To trigger the bug, the test must ran on its own as first one and should
at best not use test framework at all,
to not accidentally load any classes.
A test could spawn a new JVM and run the code in a standalone static main()
class.
I don't remember anymore, but for the codec initialization issue a few years
ago, I did something like this.
{quote}
Oh, that's what I was looking for!
After checking, I found {{TestCodecLoadingDeadlock}} from LUCENE-6482.
It seems applicable to this issue.
I'll check how to apply it beautifully.
{quote}Another fix for this is to place the TermsEnum.EMPTY in another class.
See the codec deadlock. There it uses a static inner class named Holder which
has the EMPTY constant.
In the TermsEnum class remove the static constant and provide a getter that
returns the final constant from the holder.
By this the inner holder class is initialized only when the first user calls
the getter.
{quote}
Regarding this, what do you think of reverting only that part from the [github
link|https://github.com/apache/lucene-solr/commit/4a513fa99f638cb65e0cae59bfdf7af410c0327a#diff-fb2691b9ff2d7f948692f45792a7ab6c7e730a2511e6289c3758b8888b49e84dL211-L219]?
From my point of view, there seem to be no big difference in functionality
between the singleton pattern using the holder and static initialization.
Please let me know what you think.
> Another classloader deadlock?
> -----------------------------
>
> Key: LUCENE-9661
> URL: https://issues.apache.org/jira/browse/LUCENE-9661
> Project: Lucene - Core
> Issue Type: Bug
> Affects Versions: master (9.0)
> Reporter: Michael McCandless
> Priority: Major
> Attachments: deadlock_test.patch
>
>
> The {{java}} processes spawned by our Lucene nightly benchmarks sometimes
> randomly hang, apparently while loading classes across threads, under
> contention.
> I've opened [this {{luceneutil}} issue with some
> details|https://github.com/mikemccand/luceneutil/issues/89], but
> [~uschindler] suggested I open an issue here too since he has been seeing
> this in CI builds too.
> It is rare, maybe once a week in the nightly benchmarks (which spawn many
> {{java}} processes with many threads across 128 CPU cores). It is clearly a
> deadlock – when it strikes, the process hangs forever until I notice and
> {{kill -9}} it. I posted a coupled {{jstacks}} in the issue above.
> [~rcmuir] suggested using {{classcycle}} to maybe statically dig into
> possible deadlocks ... I have not tried that yet.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
