[
https://issues.apache.org/jira/browse/SOLR-4196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13580285#comment-13580285
]
Erick Erickson commented on SOLR-4196:
--------------------------------------
I'm still having the same problem with updates as of this morning. I spent some
time trying to make sense of the stack traces and output, but no luck yet. I
hacked in some code to in sure that all of the locking in CoreContainer is
paired with a release, and they apparently are. I don't see any suspicious
blocking in the stack traces.
I did uncomment a zk state dump in ElectionContext.waitForReplicasToComeUp and
see a bunch of statements that indicate that multiunload* has failed to
recover. There's also the message:
[junit4:junit4] 2> 148785 T324 oasc.SolrException.log SEVERE
org.apache.solr.common.SolrException: core not found:multiunload1
[junit4:junit4] 2> at
org.apache.solr.handler.admin.CoreAdminHandler.handleWaitForStateAction(CoreAdminHandler.java:905)
[junit4:junit4] 2> at
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:190)
Whether this is all related, or whether it's even germane...well...I'm getting
lost in the data.
Curiously, we don't see to be stuck in the loop in
ElectionContext.waitForReplicasToComeUp. In my entire log output, there are
only 3 statements like:
ShardLeaderElectionContext.waitForReplicasToComeUp Waiting until we see more
replicas up: total=2 found=1 timeoutin=179999
and the timeoutin number never does the countdown it used to do.
I added a log statement in RcoveryStrategy, line 451 (retries = INTERRUPTED;)
and that clause is definitely getting hit.
Anyway, enough for a Sunday afternoon, I'll probably look at this a bit more
tonight...
> Untangle XML-specific nature of Config and Container classes
> ------------------------------------------------------------
>
> Key: SOLR-4196
> URL: https://issues.apache.org/jira/browse/SOLR-4196
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Priority: Minor
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4196.patch, SOLR-4196.patch, SOLR-4196.patch,
> SOLR-4196.patch, SOLR-4196.patch, SOLR-4196.patch, SOLR-4196.patch,
> SOLR-4196.patch, SOLR-4196.patch, SOLR-4196.patch, SOLR-4196.patch,
> StressTest.zip, StressTest.zip, StressTest.zip
>
>
> sub-task for SOLR-4083. If we're going to try to obsolete solr.xml, we need
> to pull all of the specific XML processing out of Config and Container.
> Currently, we refer to xpaths all over the place. This JIRA is about
> providing a thunking layer to isolate the XML-esque nature of solr.xml and
> allow a simple properties file to be used instead which will lead,
> eventually, to solr.xml going away.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
