[ 
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 java.base@11.0.23/jdk.internal.misc.Unsafe.park(Native Method)
  2>         at 
java.base@11.0.23/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
  2>         at 
java.base@11.0.23/java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:885)
  2>         at 
java.base@11.0.23/java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1039)
  2>         at 
java.base@11.0.23/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1345)
  2>         at 
java.base@11.0.23/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: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org

Reply via email to