[
https://issues.apache.org/jira/browse/SOLR-17305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17848337#comment-17848337
]
David Smiley commented on SOLR-17305:
-------------------------------------
Stack trace of the blocked thread:
{noformat}
at [email protected]/jdk.internal.misc.Unsafe.park(Native Method)
2> at
[email protected]/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
2> at
[email protected]/java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:885)
2> at
[email protected]/java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1039)
2> at
[email protected]/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1345)
2> at
[email protected]/java.util.concurrent.CountDownLatch.await(CountDownLatch.java:232)
2> at
app//org.apache.solr.servlet.CoreContainerProvider$ContextInitializationKey.waitForReadyService(CoreContainerProvider.java:525)
2> at
app//org.apache.solr.servlet.CoreContainerProvider$ServiceHolder.getService(CoreContainerProvider.java:564)
2> at
app//org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:144)
2> at
app//org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:133)
2> at
app//org.eclipse.jetty.servlet.ServletHandler.initializeHolders(ServletHandler.java:774)
2> at
app//org.eclipse.jetty.servlet.ServletHandler.setFilters(ServletHandler.java:1472)
2> at
app//org.eclipse.jetty.servlet.ServletHandler.addFilterWithMapping(ServletHandler.java:992)
2> at
app//org.eclipse.jetty.servlet.ServletContextHandler.addFilter(ServletContextHandler.java:480)
2> at
app//org.apache.solr.embedded.JettySolrRunner$1.lifeCycleStarted(JettySolrRunner.java:427)
2> at
app//org.eclipse.jetty.util.component.AbstractLifeCycle.setStarted(AbstractLifeCycle.java:253)
2> at
app//org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:94)
2> at
app//org.apache.solr.embedded.JettySolrRunner.retryOnPortBindFailure(JettySolrRunner.java:616)
2> at
app//org.apache.solr.embedded.JettySolrRunner.start(JettySolrRunner.java:554)
2> at
app//org.apache.solr.embedded.JettySolrRunner.start(JettySolrRunner.java:525)
2> at
app//org.apache.solr.util.SolrJettyTestRule.startSolr(SolrJettyTestRule.java:91)
2> at
app//org.apache.solr.SolrJettyTestBase.createAndStartJetty(SolrJettyTestBase.java:95)
2> at
app//org.apache.solr.SolrJettyTestBase.createAndStartJetty(SolrJettyTestBase.java:60)
2> at
app//org.apache.solr.util.RestTestBase.createJettyAndHarness(RestTestBase.java:57)
2> at
app//org.apache.solr.ltr.TestRerankBase.setuptest(TestRerankBase.java:181)
2> at
app//org.apache.solr.ltr.TestRerankBase.setuptest(TestRerankBase.java:113)
2> at
app//org.apache.solr.ltr.response.transform.TestInterleavingTransformer.before(TestInterleavingTransformer.java:32)
{noformat}
> 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
>
> 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]
