[
https://issues.apache.org/jira/browse/SOLR-17305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley resolved SOLR-17305.
---------------------------------
Fix Version/s: SOLR-15590
Resolution: Duplicate
> SolrDispatchFilter CoreContainerProvider can hang on startup
> ------------------------------------------------------------
>
> Key: SOLR-17305
> URL: https://issues.apache.org/jira/browse/SOLR-17305
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Major
> Fix For: SOLR-15590
>
>
> I've been stumped a number of times over the years looking at an
> unreproducible test failure that shows SolrDispatchFilter.init calling
> CoreContainerProvider.waitForReadyService and waiting on a CoundDownLatch
> indefinitely. Meanwhile, no other trace or problems in the logs. Eventually
> the test will timeout and we see a thread dump.
> I suspect a timing bug of exactly when GC happens interplaying with the use
> of WeakHashMap. In particular I see ContextInitializationKey's constructor
> publishing "this" to the ServletContext which seems like a bad place to put
> such logic (constructors publishing themselves is suspicious in general;
> avoid it). But the point is that it'll overwrite an existing entry in the
> context that may very well be there, thus suddenly making an existing entry
> in a WeakHashMap weakly reachable and it may be removed. There is too much
> complexity there; I think it should be overhauled a bit. I'm working on a PR.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
