[jira] [Updated] (SOLR-2654) lockType/ not used consistently in all places Directory objects are instantiated
[ https://issues.apache.org/jira/browse/SOLR-2654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-2654: -- Fix Version/s: (was: 3.6) lockType/ not used consistently in all places Directory objects are instantiated -- Key: SOLR-2654 URL: https://issues.apache.org/jira/browse/SOLR-2654 Project: Solr Issue Type: Bug Reporter: Hoss Man Assignee: Mark Miller Fix For: 4.0 Attachments: SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch, SOLR-2698.patch nipunb noted on the mailing list then when configuring solr to use an alternate lockType/ (ie: simple) the stats for the SolrIndexSearcher list NativeFSLockFactory being used by the Directory. The problem seems to be that SolrIndexConfig is not consulted when constructing Directory objects used for IndexReader (it's only used by SolrIndexWriter) I don't _think_ this is a problem in most cases since the IndexReaders should all be readOnly in the core solr code) but plugins could attempt to use them in other ways. In general it seems like a really bad bug waiting to happen. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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
[jira] [Updated] (SOLR-2654) lockType/ not used consistently in all places Directory objects are instantiated
[ https://issues.apache.org/jira/browse/SOLR-2654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-2654: -- Attachment: SOLR-2654.patch Another, more cleaned up, patch. lockType/ not used consistently in all places Directory objects are instantiated -- Key: SOLR-2654 URL: https://issues.apache.org/jira/browse/SOLR-2654 Project: Solr Issue Type: Bug Reporter: Hoss Man Assignee: Mark Miller Fix For: 3.4, 4.0 Attachments: SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch, SOLR-2698.patch nipunb noted on the mailing list then when configuring solr to use an alternate lockType/ (ie: simple) the stats for the SolrIndexSearcher list NativeFSLockFactory being used by the Directory. The problem seems to be that SolrIndexConfig is not consulted when constructing Directory objects used for IndexReader (it's only used by SolrIndexWriter) I don't _think_ this is a problem in most cases since the IndexReaders should all be readOnly in the core solr code) but plugins could attempt to use them in other ways. In general it seems like a really bad bug waiting to happen. -- This message is automatically generated by JIRA. 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
[jira] [Updated] (SOLR-2654) lockType/ not used consistently in all places Directory objects are instantiated
[ https://issues.apache.org/jira/browse/SOLR-2654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-2654: -- Attachment: SOLR-2654.patch I've cleaned up this patch quite a bit. lockType/ not used consistently in all places Directory objects are instantiated -- Key: SOLR-2654 URL: https://issues.apache.org/jira/browse/SOLR-2654 Project: Solr Issue Type: Bug Reporter: Hoss Man Assignee: Mark Miller Fix For: 3.4, 4.0 Attachments: SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch, SOLR-2698.patch nipunb noted on the mailing list then when configuring solr to use an alternate lockType/ (ie: simple) the stats for the SolrIndexSearcher list NativeFSLockFactory being used by the Directory. The problem seems to be that SolrIndexConfig is not consulted when constructing Directory objects used for IndexReader (it's only used by SolrIndexWriter) I don't _think_ this is a problem in most cases since the IndexReaders should all be readOnly in the core solr code) but plugins could attempt to use them in other ways. In general it seems like a really bad bug waiting to happen. -- This message is automatically generated by JIRA. 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
[jira] [Updated] (SOLR-2654) lockType/ not used consistently in all places Directory objects are instantiated
[ https://issues.apache.org/jira/browse/SOLR-2654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-2654: -- Attachment: SOLR-2654.patch Another slightly better patch - we don't need to also track the set of all dirs anymore. lockType/ not used consistently in all places Directory objects are instantiated -- Key: SOLR-2654 URL: https://issues.apache.org/jira/browse/SOLR-2654 Project: Solr Issue Type: Bug Reporter: Hoss Man Assignee: Mark Miller Fix For: 3.4, 4.0 Attachments: SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch, SOLR-2698.patch nipunb noted on the mailing list then when configuring solr to use an alternate lockType/ (ie: simple) the stats for the SolrIndexSearcher list NativeFSLockFactory being used by the Directory. The problem seems to be that SolrIndexConfig is not consulted when constructing Directory objects used for IndexReader (it's only used by SolrIndexWriter) I don't _think_ this is a problem in most cases since the IndexReaders should all be readOnly in the core solr code) but plugins could attempt to use them in other ways. In general it seems like a really bad bug waiting to happen. -- This message is automatically generated by JIRA. 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
[jira] [Updated] (SOLR-2654) lockType/ not used consistently in all places Directory objects are instantiated
[ https://issues.apache.org/jira/browse/SOLR-2654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-2654: -- Attachment: SOLR-2654.patch new patch - the problem with pure ref counting is that sometimes you might hit a point where you don't need the directory for a moment - and then you do - if its a ram based dir that means you lose your dir data. So this is something of a hybrid - it still ref counts, but only when a new index writer is forced open does it allow a directory to actually be closed. So when the indexwriter jumps to a new index, that should allow the old one to be removed once all the refs are released. The current working directory will always be kept around. All created directories are are tracked so that any that are not closed can be closed when the SolrCore is actually closed (not reloaded). All tests currently passing. lockType/ not used consistently in all places Directory objects are instantiated -- Key: SOLR-2654 URL: https://issues.apache.org/jira/browse/SOLR-2654 Project: Solr Issue Type: Bug Reporter: Hoss Man Assignee: Mark Miller Fix For: 3.4, 4.0 Attachments: SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch, SOLR-2698.patch nipunb noted on the mailing list then when configuring solr to use an alternate lockType/ (ie: simple) the stats for the SolrIndexSearcher list NativeFSLockFactory being used by the Directory. The problem seems to be that SolrIndexConfig is not consulted when constructing Directory objects used for IndexReader (it's only used by SolrIndexWriter) I don't _think_ this is a problem in most cases since the IndexReaders should all be readOnly in the core solr code) but plugins could attempt to use them in other ways. In general it seems like a really bad bug waiting to happen. -- This message is automatically generated by JIRA. 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
[jira] [Updated] (SOLR-2654) lockType/ not used consistently in all places Directory objects are instantiated
[ https://issues.apache.org/jira/browse/SOLR-2654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-2654: -- Attachment: SOLR-2698.patch Latest rough patch lockType/ not used consistently in all places Directory objects are instantiated -- Key: SOLR-2654 URL: https://issues.apache.org/jira/browse/SOLR-2654 Project: Solr Issue Type: Bug Reporter: Hoss Man Assignee: Mark Miller Fix For: 3.4, 4.0 Attachments: SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch, SOLR-2698.patch nipunb noted on the mailing list then when configuring solr to use an alternate lockType/ (ie: simple) the stats for the SolrIndexSearcher list NativeFSLockFactory being used by the Directory. The problem seems to be that SolrIndexConfig is not consulted when constructing Directory objects used for IndexReader (it's only used by SolrIndexWriter) I don't _think_ this is a problem in most cases since the IndexReaders should all be readOnly in the core solr code) but plugins could attempt to use them in other ways. In general it seems like a really bad bug waiting to happen. -- This message is automatically generated by JIRA. 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
[jira] [Updated] (SOLR-2654) lockType/ not used consistently in all places Directory objects are instantiated
[ https://issues.apache.org/jira/browse/SOLR-2654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-2654: -- Attachment: SOLR-2654.patch Okay, so first a step backwards - back to keeping the dirs around till the core is really closed, and no ref cnt dirs. Tests now pass without the test close directory hack. I have not given up on something better, but I probably will take a break on this madness. Eclipse has been doing weird stuff creating my patches on my Ubuntu machine - hopefully this one is legit, but I'll check it on my mac eventually to be sure. lockType/ not used consistently in all places Directory objects are instantiated -- Key: SOLR-2654 URL: https://issues.apache.org/jira/browse/SOLR-2654 Project: Solr Issue Type: Bug Reporter: Hoss Man Assignee: Mark Miller Fix For: 3.4, 4.0 Attachments: SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch nipunb noted on the mailing list then when configuring solr to use an alternate lockType/ (ie: simple) the stats for the SolrIndexSearcher list NativeFSLockFactory being used by the Directory. The problem seems to be that SolrIndexConfig is not consulted when constructing Directory objects used for IndexReader (it's only used by SolrIndexWriter) I don't _think_ this is a problem in most cases since the IndexReaders should all be readOnly in the core solr code) but plugins could attempt to use them in other ways. In general it seems like a really bad bug waiting to happen. -- This message is automatically generated by JIRA. 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
[jira] [Updated] (SOLR-2654) lockType/ not used consistently in all places Directory objects are instantiated
[ https://issues.apache.org/jira/browse/SOLR-2654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-2654: -- Attachment: SOLR-2654.patch new patch: *removes the refcnt dir wrappers *cleans up a bunch of other nocommits / cleanup work *adds a new NRTCachingDirectoryFactory - completely untested, but half the reason I'm working on improving this area ;) Uses hack ram / merge settings of 64. Needs to be set to reasonable defaults, plus be easily configurable eventually. Tests pass for me. lockType/ not used consistently in all places Directory objects are instantiated -- Key: SOLR-2654 URL: https://issues.apache.org/jira/browse/SOLR-2654 Project: Solr Issue Type: Bug Reporter: Hoss Man Assignee: Mark Miller Priority: Critical Fix For: 3.4, 4.0 Attachments: SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch nipunb noted on the mailing list then when configuring solr to use an alternate lockType/ (ie: simple) the stats for the SolrIndexSearcher list NativeFSLockFactory being used by the Directory. The problem seems to be that SolrIndexConfig is not consulted when constructing Directory objects used for IndexReader (it's only used by SolrIndexWriter) I don't _think_ this is a problem in most cases since the IndexReaders should all be readOnly in the core solr code) but plugins could attempt to use them in other ways. In general it seems like a really bad bug waiting to happen. -- This message is automatically generated by JIRA. 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
[jira] [Updated] (SOLR-2654) lockType/ not used consistently in all places Directory objects are instantiated
[ https://issues.apache.org/jira/browse/SOLR-2654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-2654: -- Priority: Major (was: Critical) lockType/ not used consistently in all places Directory objects are instantiated -- Key: SOLR-2654 URL: https://issues.apache.org/jira/browse/SOLR-2654 Project: Solr Issue Type: Bug Reporter: Hoss Man Assignee: Mark Miller Fix For: 3.4, 4.0 Attachments: SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch nipunb noted on the mailing list then when configuring solr to use an alternate lockType/ (ie: simple) the stats for the SolrIndexSearcher list NativeFSLockFactory being used by the Directory. The problem seems to be that SolrIndexConfig is not consulted when constructing Directory objects used for IndexReader (it's only used by SolrIndexWriter) I don't _think_ this is a problem in most cases since the IndexReaders should all be readOnly in the core solr code) but plugins could attempt to use them in other ways. In general it seems like a really bad bug waiting to happen. -- This message is automatically generated by JIRA. 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
[jira] [Updated] (SOLR-2654) lockType/ not used consistently in all places Directory objects are instantiated
[ https://issues.apache.org/jira/browse/SOLR-2654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-2654: -- Fix Version/s: 4.0 lockType/ not used consistently in all places Directory objects are instantiated -- Key: SOLR-2654 URL: https://issues.apache.org/jira/browse/SOLR-2654 Project: Solr Issue Type: Bug Reporter: Hoss Man Assignee: Mark Miller Priority: Critical Fix For: 3.4, 4.0 Attachments: SOLR-2654.patch, SOLR-2654.patch nipunb noted on the mailing list then when configuring solr to use an alternate lockType/ (ie: simple) the stats for the SolrIndexSearcher list NativeFSLockFactory being used by the Directory. The problem seems to be that SolrIndexConfig is not consulted when constructing Directory objects used for IndexReader (it's only used by SolrIndexWriter) I don't _think_ this is a problem in most cases since the IndexReaders should all be readOnly in the core solr code) but plugins could attempt to use them in other ways. In general it seems like a really bad bug waiting to happen. -- This message is automatically generated by JIRA. 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
[jira] [Updated] (SOLR-2654) lockType/ not used consistently in all places Directory objects are instantiated
[ https://issues.apache.org/jira/browse/SOLR-2654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-2654: -- Attachment: SOLR-2654.patch first rough patch - TestReplicationHandler does not pass - doTestReplicateAfterWrite2Slave causes any of the other replication tests run after it to fail. Commenting it out, all tests pass. This allows us to use the same dir instance everywhere (kind of important - we hacked around this for ram dir specifically by using a static cache - mainly for tests). It does kind of make it so you must use the new approved SolrCore reload method rather than just starting a new clore and closing the old one. But you really should do that anyhow, so...and it's better than using a static cache IMO. lockType/ not used consistently in all places Directory objects are instantiated -- Key: SOLR-2654 URL: https://issues.apache.org/jira/browse/SOLR-2654 Project: Solr Issue Type: Bug Reporter: Hoss Man Assignee: Mark Miller Priority: Critical Fix For: 3.4 Attachments: SOLR-2654.patch nipunb noted on the mailing list then when configuring solr to use an alternate lockType/ (ie: simple) the stats for the SolrIndexSearcher list NativeFSLockFactory being used by the Directory. The problem seems to be that SolrIndexConfig is not consulted when constructing Directory objects used for IndexReader (it's only used by SolrIndexWriter) I don't _think_ this is a problem in most cases since the IndexReaders should all be readOnly in the core solr code) but plugins could attempt to use them in other ways. In general it seems like a really bad bug waiting to happen. -- This message is automatically generated by JIRA. 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
