[ https://issues.apache.org/jira/browse/SOLR-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633615#comment-13633615 ]
Hoss Man commented on SOLR-4709: -------------------------------- Mark: do you have any specific ideas about whether the SolrCore.reload logic that sets "prev = null" is a bug, or do we need to deal with this in some other way in SnapPuller? ie: is there a bug here to fix in SolrCore; or should SnapPuller include retry logic if the core reload fails; or both? > 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