lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erick Erickson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-4196) Untangle XML-specific nature of Config and Container classes
Date Sun, 17 Feb 2013 20:59:13 GMT

    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message