[ https://issues.apache.org/jira/browse/SOLR-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633765#comment-13633765 ]
Mark Miller commented on SOLR-4709: ----------------------------------- {code} if (!getNewIndexDir().equals(getIndexDir())) { // the directory is changing, don't pass on state prev = null; } {code} This means that if we reopen and the index directory has changed, don't pass on previous core state - open the core as if it was first starting up. There should not be a problem getting a lock in that case - this should only happen when reopening on a *new* index. I'll spend some time investigating soon. > dir lock error if reopening cores to fast? > ------------------------------------------ > > Key: SOLR-4709 > URL: https://issues.apache.org/jira/browse/SOLR-4709 > Project: Solr > Issue Type: Bug > Reporter: Hoss Man > Assignee: Mark Miller > Fix For: 4.3, 5.0 > > > While testing my patch for SOLR-4629, i noticed a really random error that i > traced back to the core reload (do to config file replication) failed because > the directory was locked. > From what i can tell, the lock checking code in the SolrCore constructor > isn't even suppose to be used in the reload situation where there is a "prev" > core, except that in SolrCore.reload there is this check... > {noformat} > if (!getNewIndexDir().equals(getIndexDir())) { > // the directory is changing, don't pass on state > prev = null; > } > {noformat} > ..i'm not really sure i understand this logic, or what exactly the source of > the problem is, or if the lock checking code should just be changed to work a > differnet way completley, but it seemed worthy of tracking in it's own jira. > log details to follow -- 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