[jira] [Commented] (SOLR-14254) Index backcompat break between 8.3.1 and 8.4.1
[ https://issues.apache.org/jira/browse/SOLR-14254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17056306#comment-17056306 ] Jason Gerlowski commented on SOLR-14254: I agree: short of doing something to handle the old index format in Solr itself the best we can do here is a doc fix. Thanks for proposing docs, they look good to me. > Index backcompat break between 8.3.1 and 8.4.1 > -- > > Key: SOLR-14254 > URL: https://issues.apache.org/jira/browse/SOLR-14254 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Jason Gerlowski >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > I believe I found a backcompat break between 8.4.1 and 8.3.1. > I encountered this when a Solr 8.3.1 cluster was upgraded to 8.4.1. On 8.4. > nodes, several collections had cores fail to come up with > {{CorruptIndexException}}: > {code} > 2020-02-10 20:58:26.136 ERROR > (coreContainerWorkExecutor-2-thread-1-processing-n:192.168.1.194:8983_solr) [ > ] o.a.s.c.CoreContainer Error waiting for SolrCore to be loaded on startup > => org.apache.sol > r.common.SolrException: Unable to create core > [testbackcompat_shard1_replica_n1] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1313) > org.apache.solr.common.SolrException: Unable to create core > [testbackcompat_shard1_replica_n1] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1313) > ~[?:?] > at > org.apache.solr.core.CoreContainer.lambda$load$13(CoreContainer.java:788) > ~[?:?] > at > com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:202) > ~[metrics-core-4.0.5.jar:4.0.5] > at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?] > at > org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:210) > ~[?:?] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > ~[?:?] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > ~[?:?] > at java.lang.Thread.run(Thread.java:834) [?:?] > Caused by: org.apache.solr.common.SolrException: Error opening new searcher > at org.apache.solr.core.SolrCore.(SolrCore.java:1072) ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:901) ~[?:?] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1292) > ~[?:?] > ... 7 more > Caused by: org.apache.solr.common.SolrException: Error opening new searcher > at org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:2182) > ~[?:?] > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:2302) > ~[?:?] > at org.apache.solr.core.SolrCore.initSearcher(SolrCore.java:1132) > ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:1013) ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:901) ~[?:?] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1292) > ~[?:?] > ... 7 more > Caused by: org.apache.lucene.index.CorruptIndexException: codec mismatch: > actual codec=Lucene50PostingsWriterDoc vs expected > codec=Lucene84PostingsWriterDoc > (resource=MMapIndexInput(path="/Users/jasongerlowski/run/solrdata/data/testbackcompat_shard1_replica_n1/data/index/_0_FST50_0.doc")) > at > org.apache.lucene.codecs.CodecUtil.checkHeaderNoMagic(CodecUtil.java:208) > ~[?:?] > at org.apache.lucene.codecs.CodecUtil.checkHeader(CodecUtil.java:198) > ~[?:?] > at > org.apache.lucene.codecs.CodecUtil.checkIndexHeader(CodecUtil.java:255) ~[?:?] > at > org.apache.lucene.codecs.lucene84.Lucene84PostingsReader.(Lucene84PostingsReader.java:82) > ~[?:?] > at > org.apache.lucene.codecs.memory.FSTPostingsFormat.fieldsProducer(FSTPostingsFormat.java:66) > ~[?:?] > at > org.apache.lucene.codecs.perfield.PerFieldPostingsFormat$FieldsReader.(PerFieldPostingsFormat.java:315) > ~[?:?] > at > org.apache.lucene.codecs.perfield.PerFieldPostingsFormat.fieldsProducer(PerFieldPostingsFormat.java:395) > ~[?:?] > at > org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:114) > ~[?:?] > at > org.apache.lucene.index.SegmentReader.(SegmentReader.java:84) ~[?:?] > at > org.apache.lucene.index.ReadersAndUpdates.getReader(ReadersAndUpdates.java:177) > ~[?:?] > at > org.apache.lucene.index.ReadersAndUpdates.getReadOnlyClone(ReadersAndUpdates.java:219) > ~[?:?] > at > org.apache.lucene.index.StandardDirectoryReader.open(Standa
[jira] [Commented] (SOLR-14254) Index backcompat break between 8.3.1 and 8.4.1
[ https://issues.apache.org/jira/browse/SOLR-14254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17051532#comment-17051532 ] David Smiley commented on SOLR-14254: - I'll add a PR here to improve the ref guide guidance on tagger to show the FST50 as a performance trade-off tip and not a must-have. I'm not sure if that "resolves" this issue or not; there is a back-compat break and the best course of action is documentation here. > Index backcompat break between 8.3.1 and 8.4.1 > -- > > Key: SOLR-14254 > URL: https://issues.apache.org/jira/browse/SOLR-14254 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Jason Gerlowski >Priority: Major > > I believe I found a backcompat break between 8.4.1 and 8.3.1. > I encountered this when a Solr 8.3.1 cluster was upgraded to 8.4.1. On 8.4. > nodes, several collections had cores fail to come up with > {{CorruptIndexException}}: > {code} > 2020-02-10 20:58:26.136 ERROR > (coreContainerWorkExecutor-2-thread-1-processing-n:192.168.1.194:8983_solr) [ > ] o.a.s.c.CoreContainer Error waiting for SolrCore to be loaded on startup > => org.apache.sol > r.common.SolrException: Unable to create core > [testbackcompat_shard1_replica_n1] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1313) > org.apache.solr.common.SolrException: Unable to create core > [testbackcompat_shard1_replica_n1] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1313) > ~[?:?] > at > org.apache.solr.core.CoreContainer.lambda$load$13(CoreContainer.java:788) > ~[?:?] > at > com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:202) > ~[metrics-core-4.0.5.jar:4.0.5] > at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?] > at > org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:210) > ~[?:?] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > ~[?:?] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > ~[?:?] > at java.lang.Thread.run(Thread.java:834) [?:?] > Caused by: org.apache.solr.common.SolrException: Error opening new searcher > at org.apache.solr.core.SolrCore.(SolrCore.java:1072) ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:901) ~[?:?] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1292) > ~[?:?] > ... 7 more > Caused by: org.apache.solr.common.SolrException: Error opening new searcher > at org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:2182) > ~[?:?] > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:2302) > ~[?:?] > at org.apache.solr.core.SolrCore.initSearcher(SolrCore.java:1132) > ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:1013) ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:901) ~[?:?] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1292) > ~[?:?] > ... 7 more > Caused by: org.apache.lucene.index.CorruptIndexException: codec mismatch: > actual codec=Lucene50PostingsWriterDoc vs expected > codec=Lucene84PostingsWriterDoc > (resource=MMapIndexInput(path="/Users/jasongerlowski/run/solrdata/data/testbackcompat_shard1_replica_n1/data/index/_0_FST50_0.doc")) > at > org.apache.lucene.codecs.CodecUtil.checkHeaderNoMagic(CodecUtil.java:208) > ~[?:?] > at org.apache.lucene.codecs.CodecUtil.checkHeader(CodecUtil.java:198) > ~[?:?] > at > org.apache.lucene.codecs.CodecUtil.checkIndexHeader(CodecUtil.java:255) ~[?:?] > at > org.apache.lucene.codecs.lucene84.Lucene84PostingsReader.(Lucene84PostingsReader.java:82) > ~[?:?] > at > org.apache.lucene.codecs.memory.FSTPostingsFormat.fieldsProducer(FSTPostingsFormat.java:66) > ~[?:?] > at > org.apache.lucene.codecs.perfield.PerFieldPostingsFormat$FieldsReader.(PerFieldPostingsFormat.java:315) > ~[?:?] > at > org.apache.lucene.codecs.perfield.PerFieldPostingsFormat.fieldsProducer(PerFieldPostingsFormat.java:395) > ~[?:?] > at > org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:114) > ~[?:?] > at > org.apache.lucene.index.SegmentReader.(SegmentReader.java:84) ~[?:?] > at > org.apache.lucene.index.ReadersAndUpdates.getReader(ReadersAndUpdates.java:177) > ~[?:?] > at > org.apache.lucene.index.ReadersAndUpdates.getReadOnlyClone(ReadersAndUpdates.java:219) > ~[?:?] > at > org.apache.lucene
[jira] [Commented] (SOLR-14254) Index backcompat break between 8.3.1 and 8.4.1
[ https://issues.apache.org/jira/browse/SOLR-14254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17035630#comment-17035630 ] Adrien Grand commented on SOLR-14254: - I started a discussion on LUCENE-9222. bq. If I understand you then wouldn't this mean introducing backwards incompatibilities that don't actually exist? Yes this is correct. This might actually be a feature, as it makes all Lucene versions look the same, instead of some versions being compatible with the previous one and others not. And it also avoids silent corruptions from sneaking in, ie. when a change is made that would cause API calls to return wrong results without triggering a CorruptIndexException? > Index backcompat break between 8.3.1 and 8.4.1 > -- > > Key: SOLR-14254 > URL: https://issues.apache.org/jira/browse/SOLR-14254 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Jason Gerlowski >Priority: Major > > I believe I found a backcompat break between 8.4.1 and 8.3.1. > I encountered this when a Solr 8.3.1 cluster was upgraded to 8.4.1. On 8.4. > nodes, several collections had cores fail to come up with > {{CorruptIndexException}}: > {code} > 2020-02-10 20:58:26.136 ERROR > (coreContainerWorkExecutor-2-thread-1-processing-n:192.168.1.194:8983_solr) [ > ] o.a.s.c.CoreContainer Error waiting for SolrCore to be loaded on startup > => org.apache.sol > r.common.SolrException: Unable to create core > [testbackcompat_shard1_replica_n1] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1313) > org.apache.solr.common.SolrException: Unable to create core > [testbackcompat_shard1_replica_n1] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1313) > ~[?:?] > at > org.apache.solr.core.CoreContainer.lambda$load$13(CoreContainer.java:788) > ~[?:?] > at > com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:202) > ~[metrics-core-4.0.5.jar:4.0.5] > at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?] > at > org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:210) > ~[?:?] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > ~[?:?] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > ~[?:?] > at java.lang.Thread.run(Thread.java:834) [?:?] > Caused by: org.apache.solr.common.SolrException: Error opening new searcher > at org.apache.solr.core.SolrCore.(SolrCore.java:1072) ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:901) ~[?:?] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1292) > ~[?:?] > ... 7 more > Caused by: org.apache.solr.common.SolrException: Error opening new searcher > at org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:2182) > ~[?:?] > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:2302) > ~[?:?] > at org.apache.solr.core.SolrCore.initSearcher(SolrCore.java:1132) > ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:1013) ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:901) ~[?:?] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1292) > ~[?:?] > ... 7 more > Caused by: org.apache.lucene.index.CorruptIndexException: codec mismatch: > actual codec=Lucene50PostingsWriterDoc vs expected > codec=Lucene84PostingsWriterDoc > (resource=MMapIndexInput(path="/Users/jasongerlowski/run/solrdata/data/testbackcompat_shard1_replica_n1/data/index/_0_FST50_0.doc")) > at > org.apache.lucene.codecs.CodecUtil.checkHeaderNoMagic(CodecUtil.java:208) > ~[?:?] > at org.apache.lucene.codecs.CodecUtil.checkHeader(CodecUtil.java:198) > ~[?:?] > at > org.apache.lucene.codecs.CodecUtil.checkIndexHeader(CodecUtil.java:255) ~[?:?] > at > org.apache.lucene.codecs.lucene84.Lucene84PostingsReader.(Lucene84PostingsReader.java:82) > ~[?:?] > at > org.apache.lucene.codecs.memory.FSTPostingsFormat.fieldsProducer(FSTPostingsFormat.java:66) > ~[?:?] > at > org.apache.lucene.codecs.perfield.PerFieldPostingsFormat$FieldsReader.(PerFieldPostingsFormat.java:315) > ~[?:?] > at > org.apache.lucene.codecs.perfield.PerFieldPostingsFormat.fieldsProducer(PerFieldPostingsFormat.java:395) > ~[?:?] > at > org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:114) > ~[?:?] > at > org.apache.lucene.index.SegmentReader.(SegmentReader.java:84) ~[?:?] >
[jira] [Commented] (SOLR-14254) Index backcompat break between 8.3.1 and 8.4.1
[ https://issues.apache.org/jira/browse/SOLR-14254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17035619#comment-17035619 ] David Smiley commented on SOLR-14254: - > rejecting upgrading indices that have non-default formats in Solr How might that work? My limited understanding is that "upgrading indices" happen transparently via merging, typically due to adding data. But for the special postings format case, Lucene can't even properly read the data any more. > changing non-default formats to use a version number that is computed using > the current Lucene version. If I understand you then wouldn't this mean introducing backwards incompatibilities that don't actually exist? Maybe I don't get the idea. Even if some format names haven't changes despite actual format changes, maybe for the non-default formats this is what we should do; it's the simplest course of action that would be helpful IMO. > Index backcompat break between 8.3.1 and 8.4.1 > -- > > Key: SOLR-14254 > URL: https://issues.apache.org/jira/browse/SOLR-14254 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Jason Gerlowski >Priority: Major > > I believe I found a backcompat break between 8.4.1 and 8.3.1. > I encountered this when a Solr 8.3.1 cluster was upgraded to 8.4.1. On 8.4. > nodes, several collections had cores fail to come up with > {{CorruptIndexException}}: > {code} > 2020-02-10 20:58:26.136 ERROR > (coreContainerWorkExecutor-2-thread-1-processing-n:192.168.1.194:8983_solr) [ > ] o.a.s.c.CoreContainer Error waiting for SolrCore to be loaded on startup > => org.apache.sol > r.common.SolrException: Unable to create core > [testbackcompat_shard1_replica_n1] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1313) > org.apache.solr.common.SolrException: Unable to create core > [testbackcompat_shard1_replica_n1] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1313) > ~[?:?] > at > org.apache.solr.core.CoreContainer.lambda$load$13(CoreContainer.java:788) > ~[?:?] > at > com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:202) > ~[metrics-core-4.0.5.jar:4.0.5] > at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?] > at > org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:210) > ~[?:?] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > ~[?:?] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > ~[?:?] > at java.lang.Thread.run(Thread.java:834) [?:?] > Caused by: org.apache.solr.common.SolrException: Error opening new searcher > at org.apache.solr.core.SolrCore.(SolrCore.java:1072) ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:901) ~[?:?] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1292) > ~[?:?] > ... 7 more > Caused by: org.apache.solr.common.SolrException: Error opening new searcher > at org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:2182) > ~[?:?] > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:2302) > ~[?:?] > at org.apache.solr.core.SolrCore.initSearcher(SolrCore.java:1132) > ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:1013) ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:901) ~[?:?] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1292) > ~[?:?] > ... 7 more > Caused by: org.apache.lucene.index.CorruptIndexException: codec mismatch: > actual codec=Lucene50PostingsWriterDoc vs expected > codec=Lucene84PostingsWriterDoc > (resource=MMapIndexInput(path="/Users/jasongerlowski/run/solrdata/data/testbackcompat_shard1_replica_n1/data/index/_0_FST50_0.doc")) > at > org.apache.lucene.codecs.CodecUtil.checkHeaderNoMagic(CodecUtil.java:208) > ~[?:?] > at org.apache.lucene.codecs.CodecUtil.checkHeader(CodecUtil.java:198) > ~[?:?] > at > org.apache.lucene.codecs.CodecUtil.checkIndexHeader(CodecUtil.java:255) ~[?:?] > at > org.apache.lucene.codecs.lucene84.Lucene84PostingsReader.(Lucene84PostingsReader.java:82) > ~[?:?] > at > org.apache.lucene.codecs.memory.FSTPostingsFormat.fieldsProducer(FSTPostingsFormat.java:66) > ~[?:?] > at > org.apache.lucene.codecs.perfield.PerFieldPostingsFormat$FieldsReader.(PerFieldPostingsFormat.java:315) > ~[?:?] > at > org.apache.lucene.codecs.perfield.PerFieldPostingsFormat.fieldsP
[jira] [Commented] (SOLR-14254) Index backcompat break between 8.3.1 and 8.4.1
[ https://issues.apache.org/jira/browse/SOLR-14254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17035577#comment-17035577 ] Adrien Grand commented on SOLR-14254: - I don't have any objections to changing the name but I don't think FST50 is inappropriate. We don't always rename index formats when we change them, for instance we kept the name Lucene60PointsFormat when we added selective indexing. Maybe we could make the situation less trappy by rejecting upgrading indices that have non-default formats in Solr, or changing non-default formats to use a version number that is computed using the current Lucene version. > Index backcompat break between 8.3.1 and 8.4.1 > -- > > Key: SOLR-14254 > URL: https://issues.apache.org/jira/browse/SOLR-14254 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Jason Gerlowski >Priority: Major > > I believe I found a backcompat break between 8.4.1 and 8.3.1. > I encountered this when a Solr 8.3.1 cluster was upgraded to 8.4.1. On 8.4. > nodes, several collections had cores fail to come up with > {{CorruptIndexException}}: > {code} > 2020-02-10 20:58:26.136 ERROR > (coreContainerWorkExecutor-2-thread-1-processing-n:192.168.1.194:8983_solr) [ > ] o.a.s.c.CoreContainer Error waiting for SolrCore to be loaded on startup > => org.apache.sol > r.common.SolrException: Unable to create core > [testbackcompat_shard1_replica_n1] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1313) > org.apache.solr.common.SolrException: Unable to create core > [testbackcompat_shard1_replica_n1] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1313) > ~[?:?] > at > org.apache.solr.core.CoreContainer.lambda$load$13(CoreContainer.java:788) > ~[?:?] > at > com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:202) > ~[metrics-core-4.0.5.jar:4.0.5] > at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?] > at > org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:210) > ~[?:?] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > ~[?:?] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > ~[?:?] > at java.lang.Thread.run(Thread.java:834) [?:?] > Caused by: org.apache.solr.common.SolrException: Error opening new searcher > at org.apache.solr.core.SolrCore.(SolrCore.java:1072) ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:901) ~[?:?] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1292) > ~[?:?] > ... 7 more > Caused by: org.apache.solr.common.SolrException: Error opening new searcher > at org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:2182) > ~[?:?] > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:2302) > ~[?:?] > at org.apache.solr.core.SolrCore.initSearcher(SolrCore.java:1132) > ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:1013) ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:901) ~[?:?] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1292) > ~[?:?] > ... 7 more > Caused by: org.apache.lucene.index.CorruptIndexException: codec mismatch: > actual codec=Lucene50PostingsWriterDoc vs expected > codec=Lucene84PostingsWriterDoc > (resource=MMapIndexInput(path="/Users/jasongerlowski/run/solrdata/data/testbackcompat_shard1_replica_n1/data/index/_0_FST50_0.doc")) > at > org.apache.lucene.codecs.CodecUtil.checkHeaderNoMagic(CodecUtil.java:208) > ~[?:?] > at org.apache.lucene.codecs.CodecUtil.checkHeader(CodecUtil.java:198) > ~[?:?] > at > org.apache.lucene.codecs.CodecUtil.checkIndexHeader(CodecUtil.java:255) ~[?:?] > at > org.apache.lucene.codecs.lucene84.Lucene84PostingsReader.(Lucene84PostingsReader.java:82) > ~[?:?] > at > org.apache.lucene.codecs.memory.FSTPostingsFormat.fieldsProducer(FSTPostingsFormat.java:66) > ~[?:?] > at > org.apache.lucene.codecs.perfield.PerFieldPostingsFormat$FieldsReader.(PerFieldPostingsFormat.java:315) > ~[?:?] > at > org.apache.lucene.codecs.perfield.PerFieldPostingsFormat.fieldsProducer(PerFieldPostingsFormat.java:395) > ~[?:?] > at > org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:114) > ~[?:?] > at > org.apache.lucene.index.SegmentReader.(SegmentReader.java:84) ~[?:?] > at > org.apache.lucene.index.ReadersAndUpdates.g
[jira] [Commented] (SOLR-14254) Index backcompat break between 8.3.1 and 8.4.1
[ https://issues.apache.org/jira/browse/SOLR-14254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17035554#comment-17035554 ] David Smiley commented on SOLR-14254: - Surely "FST50" is not appropriate anymore; no? If it changed to FST84 or whatever then the user would get a message about the postingsFormat FST50 not being found or something like that. That's helpful! > Index backcompat break between 8.3.1 and 8.4.1 > -- > > Key: SOLR-14254 > URL: https://issues.apache.org/jira/browse/SOLR-14254 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Jason Gerlowski >Priority: Major > > I believe I found a backcompat break between 8.4.1 and 8.3.1. > I encountered this when a Solr 8.3.1 cluster was upgraded to 8.4.1. On 8.4. > nodes, several collections had cores fail to come up with > {{CorruptIndexException}}: > {code} > 2020-02-10 20:58:26.136 ERROR > (coreContainerWorkExecutor-2-thread-1-processing-n:192.168.1.194:8983_solr) [ > ] o.a.s.c.CoreContainer Error waiting for SolrCore to be loaded on startup > => org.apache.sol > r.common.SolrException: Unable to create core > [testbackcompat_shard1_replica_n1] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1313) > org.apache.solr.common.SolrException: Unable to create core > [testbackcompat_shard1_replica_n1] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1313) > ~[?:?] > at > org.apache.solr.core.CoreContainer.lambda$load$13(CoreContainer.java:788) > ~[?:?] > at > com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:202) > ~[metrics-core-4.0.5.jar:4.0.5] > at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?] > at > org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:210) > ~[?:?] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > ~[?:?] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > ~[?:?] > at java.lang.Thread.run(Thread.java:834) [?:?] > Caused by: org.apache.solr.common.SolrException: Error opening new searcher > at org.apache.solr.core.SolrCore.(SolrCore.java:1072) ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:901) ~[?:?] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1292) > ~[?:?] > ... 7 more > Caused by: org.apache.solr.common.SolrException: Error opening new searcher > at org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:2182) > ~[?:?] > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:2302) > ~[?:?] > at org.apache.solr.core.SolrCore.initSearcher(SolrCore.java:1132) > ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:1013) ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:901) ~[?:?] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1292) > ~[?:?] > ... 7 more > Caused by: org.apache.lucene.index.CorruptIndexException: codec mismatch: > actual codec=Lucene50PostingsWriterDoc vs expected > codec=Lucene84PostingsWriterDoc > (resource=MMapIndexInput(path="/Users/jasongerlowski/run/solrdata/data/testbackcompat_shard1_replica_n1/data/index/_0_FST50_0.doc")) > at > org.apache.lucene.codecs.CodecUtil.checkHeaderNoMagic(CodecUtil.java:208) > ~[?:?] > at org.apache.lucene.codecs.CodecUtil.checkHeader(CodecUtil.java:198) > ~[?:?] > at > org.apache.lucene.codecs.CodecUtil.checkIndexHeader(CodecUtil.java:255) ~[?:?] > at > org.apache.lucene.codecs.lucene84.Lucene84PostingsReader.(Lucene84PostingsReader.java:82) > ~[?:?] > at > org.apache.lucene.codecs.memory.FSTPostingsFormat.fieldsProducer(FSTPostingsFormat.java:66) > ~[?:?] > at > org.apache.lucene.codecs.perfield.PerFieldPostingsFormat$FieldsReader.(PerFieldPostingsFormat.java:315) > ~[?:?] > at > org.apache.lucene.codecs.perfield.PerFieldPostingsFormat.fieldsProducer(PerFieldPostingsFormat.java:395) > ~[?:?] > at > org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:114) > ~[?:?] > at > org.apache.lucene.index.SegmentReader.(SegmentReader.java:84) ~[?:?] > at > org.apache.lucene.index.ReadersAndUpdates.getReader(ReadersAndUpdates.java:177) > ~[?:?] > at > org.apache.lucene.index.ReadersAndUpdates.getReadOnlyClone(ReadersAndUpdates.java:219) > ~[?:?] > at > org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.ja
[jira] [Commented] (SOLR-14254) Index backcompat break between 8.3.1 and 8.4.1
[ https://issues.apache.org/jira/browse/SOLR-14254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17034418#comment-17034418 ] Adrien Grand commented on SOLR-14254: - I didn't change the name because this format is more about the terms dictionary than postings, so changing the attached postings format didn't feel like it warranted a rename. I'm not sure changing the name will help much, users will get an error that is not much more user friendly? If we want to make this problem easier to understand, maybe the least intrusive change would be to bump both VERSION_START and VERSION_CURRENT in the FST postings format so that opening a 8.3 index with 8.5 would instead raise an IndexFormatTooOldException. > Index backcompat break between 8.3.1 and 8.4.1 > -- > > Key: SOLR-14254 > URL: https://issues.apache.org/jira/browse/SOLR-14254 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Jason Gerlowski >Priority: Major > > I believe I found a backcompat break between 8.4.1 and 8.3.1. > I encountered this when a Solr 8.3.1 cluster was upgraded to 8.4.1. On 8.4. > nodes, several collections had cores fail to come up with > {{CorruptIndexException}}: > {code} > 2020-02-10 20:58:26.136 ERROR > (coreContainerWorkExecutor-2-thread-1-processing-n:192.168.1.194:8983_solr) [ > ] o.a.s.c.CoreContainer Error waiting for SolrCore to be loaded on startup > => org.apache.sol > r.common.SolrException: Unable to create core > [testbackcompat_shard1_replica_n1] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1313) > org.apache.solr.common.SolrException: Unable to create core > [testbackcompat_shard1_replica_n1] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1313) > ~[?:?] > at > org.apache.solr.core.CoreContainer.lambda$load$13(CoreContainer.java:788) > ~[?:?] > at > com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:202) > ~[metrics-core-4.0.5.jar:4.0.5] > at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?] > at > org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:210) > ~[?:?] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > ~[?:?] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > ~[?:?] > at java.lang.Thread.run(Thread.java:834) [?:?] > Caused by: org.apache.solr.common.SolrException: Error opening new searcher > at org.apache.solr.core.SolrCore.(SolrCore.java:1072) ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:901) ~[?:?] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1292) > ~[?:?] > ... 7 more > Caused by: org.apache.solr.common.SolrException: Error opening new searcher > at org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:2182) > ~[?:?] > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:2302) > ~[?:?] > at org.apache.solr.core.SolrCore.initSearcher(SolrCore.java:1132) > ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:1013) ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:901) ~[?:?] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1292) > ~[?:?] > ... 7 more > Caused by: org.apache.lucene.index.CorruptIndexException: codec mismatch: > actual codec=Lucene50PostingsWriterDoc vs expected > codec=Lucene84PostingsWriterDoc > (resource=MMapIndexInput(path="/Users/jasongerlowski/run/solrdata/data/testbackcompat_shard1_replica_n1/data/index/_0_FST50_0.doc")) > at > org.apache.lucene.codecs.CodecUtil.checkHeaderNoMagic(CodecUtil.java:208) > ~[?:?] > at org.apache.lucene.codecs.CodecUtil.checkHeader(CodecUtil.java:198) > ~[?:?] > at > org.apache.lucene.codecs.CodecUtil.checkIndexHeader(CodecUtil.java:255) ~[?:?] > at > org.apache.lucene.codecs.lucene84.Lucene84PostingsReader.(Lucene84PostingsReader.java:82) > ~[?:?] > at > org.apache.lucene.codecs.memory.FSTPostingsFormat.fieldsProducer(FSTPostingsFormat.java:66) > ~[?:?] > at > org.apache.lucene.codecs.perfield.PerFieldPostingsFormat$FieldsReader.(PerFieldPostingsFormat.java:315) > ~[?:?] > at > org.apache.lucene.codecs.perfield.PerFieldPostingsFormat.fieldsProducer(PerFieldPostingsFormat.java:395) > ~[?:?] > at > org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:114) > ~[?:?] > at > org.apache.lucene.index.SegmentReader.(Segm
[jira] [Commented] (SOLR-14254) Index backcompat break between 8.3.1 and 8.4.1
[ https://issues.apache.org/jira/browse/SOLR-14254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17034015#comment-17034015 ] David Smiley commented on SOLR-14254: - CC [~jpountz] I think Hossman has a point that the "FST50" name should have changed when the index version changed to like FST84 if 8.4 has a different version than prior. It'd be cool if a user could say postingsFormat="FST"; clearly out of scope I know. Anyway... Cassandra, to answer your question: upgrade advise is re-index if that's easiest. Another option is for a user to stay at the previous version and change the postingsFormat to be non-existent to be the default and then trigger an optimize which will rewrite it to something that will survive to the next version. Then upgrade the software, then change the version back (optionally). Wether or not users should use postingsFormat=FST50 or let it default is a trade-off in performance vs compatibility. FST kicks but but perhaps you won't notice if you send small amounts of text (e.g. queries). If someone is desperate, the old code can be moved into Solr and packaged up as a plugin. > Index backcompat break between 8.3.1 and 8.4.1 > -- > > Key: SOLR-14254 > URL: https://issues.apache.org/jira/browse/SOLR-14254 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Jason Gerlowski >Priority: Major > > I believe I found a backcompat break between 8.4.1 and 8.3.1. > I encountered this when a Solr 8.3.1 cluster was upgraded to 8.4.1. On 8.4. > nodes, several collections had cores fail to come up with > {{CorruptIndexException}}: > {code} > 2020-02-10 20:58:26.136 ERROR > (coreContainerWorkExecutor-2-thread-1-processing-n:192.168.1.194:8983_solr) [ > ] o.a.s.c.CoreContainer Error waiting for SolrCore to be loaded on startup > => org.apache.sol > r.common.SolrException: Unable to create core > [testbackcompat_shard1_replica_n1] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1313) > org.apache.solr.common.SolrException: Unable to create core > [testbackcompat_shard1_replica_n1] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1313) > ~[?:?] > at > org.apache.solr.core.CoreContainer.lambda$load$13(CoreContainer.java:788) > ~[?:?] > at > com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:202) > ~[metrics-core-4.0.5.jar:4.0.5] > at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?] > at > org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:210) > ~[?:?] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > ~[?:?] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > ~[?:?] > at java.lang.Thread.run(Thread.java:834) [?:?] > Caused by: org.apache.solr.common.SolrException: Error opening new searcher > at org.apache.solr.core.SolrCore.(SolrCore.java:1072) ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:901) ~[?:?] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1292) > ~[?:?] > ... 7 more > Caused by: org.apache.solr.common.SolrException: Error opening new searcher > at org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:2182) > ~[?:?] > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:2302) > ~[?:?] > at org.apache.solr.core.SolrCore.initSearcher(SolrCore.java:1132) > ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:1013) ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:901) ~[?:?] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1292) > ~[?:?] > ... 7 more > Caused by: org.apache.lucene.index.CorruptIndexException: codec mismatch: > actual codec=Lucene50PostingsWriterDoc vs expected > codec=Lucene84PostingsWriterDoc > (resource=MMapIndexInput(path="/Users/jasongerlowski/run/solrdata/data/testbackcompat_shard1_replica_n1/data/index/_0_FST50_0.doc")) > at > org.apache.lucene.codecs.CodecUtil.checkHeaderNoMagic(CodecUtil.java:208) > ~[?:?] > at org.apache.lucene.codecs.CodecUtil.checkHeader(CodecUtil.java:198) > ~[?:?] > at > org.apache.lucene.codecs.CodecUtil.checkIndexHeader(CodecUtil.java:255) ~[?:?] > at > org.apache.lucene.codecs.lucene84.Lucene84PostingsReader.(Lucene84PostingsReader.java:82) > ~[?:?] > at > org.apache.lucene.codecs.memory.FSTPostingsFormat.fieldsProducer(FSTPostingsFormat.java:66) > ~
[jira] [Commented] (SOLR-14254) Index backcompat break between 8.3.1 and 8.4.1
[ https://issues.apache.org/jira/browse/SOLR-14254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17033998#comment-17033998 ] Chris M. Hostetter commented on SOLR-14254: --- {quote}LUCENE-9116 is for 8.5, so it was a bit confusing to find the break in 8.4.1, but my reading of the comments there is that something was worked out ... {quote} IIUC: LUCENE-9027 actually broke backcompat on the {{FST50}} postings format (in 8.4) ... but that's not considered a "back compat break" for lucene/solr because it was not the default postings format at the time it was changed. (and this policy is mentioned in {{field-type-definitions-and-properties.adoc:112}}) David's points/references to LUCENE-9116 are about the fact that in _that_ issue the {{FST50}} posting format was (initially) removed entirely from branch_8x, and the later decision was to re-add it – but it's still not fully back compatible with how it worked in 8.3.1 {quote}Also, {{tagger-handler.adoc}} for 8.4 and 8.5 still says the {{postingsFormat=FST50}} is the official recommendation. That would obviously fail {quote} I believe that usage will still _work_ in 8.4 and higher ... it just creates different bytes on disk then it did in 8.3, and it hypothetically may not be readable in 8.5, 8.6, etc... if additional changes are made > Index backcompat break between 8.3.1 and 8.4.1 > -- > > Key: SOLR-14254 > URL: https://issues.apache.org/jira/browse/SOLR-14254 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Jason Gerlowski >Priority: Major > > I believe I found a backcompat break between 8.4.1 and 8.3.1. > I encountered this when a Solr 8.3.1 cluster was upgraded to 8.4.1. On 8.4. > nodes, several collections had cores fail to come up with > {{CorruptIndexException}}: > {code} > 2020-02-10 20:58:26.136 ERROR > (coreContainerWorkExecutor-2-thread-1-processing-n:192.168.1.194:8983_solr) [ > ] o.a.s.c.CoreContainer Error waiting for SolrCore to be loaded on startup > => org.apache.sol > r.common.SolrException: Unable to create core > [testbackcompat_shard1_replica_n1] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1313) > org.apache.solr.common.SolrException: Unable to create core > [testbackcompat_shard1_replica_n1] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1313) > ~[?:?] > at > org.apache.solr.core.CoreContainer.lambda$load$13(CoreContainer.java:788) > ~[?:?] > at > com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:202) > ~[metrics-core-4.0.5.jar:4.0.5] > at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?] > at > org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:210) > ~[?:?] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > ~[?:?] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > ~[?:?] > at java.lang.Thread.run(Thread.java:834) [?:?] > Caused by: org.apache.solr.common.SolrException: Error opening new searcher > at org.apache.solr.core.SolrCore.(SolrCore.java:1072) ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:901) ~[?:?] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1292) > ~[?:?] > ... 7 more > Caused by: org.apache.solr.common.SolrException: Error opening new searcher > at org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:2182) > ~[?:?] > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:2302) > ~[?:?] > at org.apache.solr.core.SolrCore.initSearcher(SolrCore.java:1132) > ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:1013) ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:901) ~[?:?] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1292) > ~[?:?] > ... 7 more > Caused by: org.apache.lucene.index.CorruptIndexException: codec mismatch: > actual codec=Lucene50PostingsWriterDoc vs expected > codec=Lucene84PostingsWriterDoc > (resource=MMapIndexInput(path="/Users/jasongerlowski/run/solrdata/data/testbackcompat_shard1_replica_n1/data/index/_0_FST50_0.doc")) > at > org.apache.lucene.codecs.CodecUtil.checkHeaderNoMagic(CodecUtil.java:208) > ~[?:?] > at org.apache.lucene.codecs.CodecUtil.checkHeader(CodecUtil.java:198) > ~[?:?] > at > org.apache.lucene.codecs.CodecUtil.checkIndexHeader(CodecUtil.java:255) ~[?:?] > at > org.apache.lucene.codecs.lucene84.Luc
[jira] [Commented] (SOLR-14254) Index backcompat break between 8.3.1 and 8.4.1
[ https://issues.apache.org/jira/browse/SOLR-14254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17033993#comment-17033993 ] Cassandra Targett commented on SOLR-14254: -- [~dsmiley], do you have a recommendation for people who use the Tagger handler in 8.x and who upgrade to 8.4? Is the only option to reindex? LUCENE-9116 is for 8.5, so it was a bit confusing to find the break in 8.4.1, but my reading of the comments there is that something was worked out - did I misunderstand that discussion (very possible since I didn't look at the code)? Also, {{tagger-handler.adoc}} for 8.4 and 8.5 still says the {{postingsFormat=FST50}} is the official recommendation. That would obviously fail - should the {{postingsFormat}} param now be omitted? > Index backcompat break between 8.3.1 and 8.4.1 > -- > > Key: SOLR-14254 > URL: https://issues.apache.org/jira/browse/SOLR-14254 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Jason Gerlowski >Priority: Major > > I believe I found a backcompat break between 8.4.1 and 8.3.1. > I encountered this when a Solr 8.3.1 cluster was upgraded to 8.4.1. On 8.4. > nodes, several collections had cores fail to come up with > {{CorruptIndexException}}: > {code} > 2020-02-10 20:58:26.136 ERROR > (coreContainerWorkExecutor-2-thread-1-processing-n:192.168.1.194:8983_solr) [ > ] o.a.s.c.CoreContainer Error waiting for SolrCore to be loaded on startup > => org.apache.sol > r.common.SolrException: Unable to create core > [testbackcompat_shard1_replica_n1] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1313) > org.apache.solr.common.SolrException: Unable to create core > [testbackcompat_shard1_replica_n1] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1313) > ~[?:?] > at > org.apache.solr.core.CoreContainer.lambda$load$13(CoreContainer.java:788) > ~[?:?] > at > com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:202) > ~[metrics-core-4.0.5.jar:4.0.5] > at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?] > at > org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:210) > ~[?:?] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > ~[?:?] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > ~[?:?] > at java.lang.Thread.run(Thread.java:834) [?:?] > Caused by: org.apache.solr.common.SolrException: Error opening new searcher > at org.apache.solr.core.SolrCore.(SolrCore.java:1072) ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:901) ~[?:?] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1292) > ~[?:?] > ... 7 more > Caused by: org.apache.solr.common.SolrException: Error opening new searcher > at org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:2182) > ~[?:?] > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:2302) > ~[?:?] > at org.apache.solr.core.SolrCore.initSearcher(SolrCore.java:1132) > ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:1013) ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:901) ~[?:?] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1292) > ~[?:?] > ... 7 more > Caused by: org.apache.lucene.index.CorruptIndexException: codec mismatch: > actual codec=Lucene50PostingsWriterDoc vs expected > codec=Lucene84PostingsWriterDoc > (resource=MMapIndexInput(path="/Users/jasongerlowski/run/solrdata/data/testbackcompat_shard1_replica_n1/data/index/_0_FST50_0.doc")) > at > org.apache.lucene.codecs.CodecUtil.checkHeaderNoMagic(CodecUtil.java:208) > ~[?:?] > at org.apache.lucene.codecs.CodecUtil.checkHeader(CodecUtil.java:198) > ~[?:?] > at > org.apache.lucene.codecs.CodecUtil.checkIndexHeader(CodecUtil.java:255) ~[?:?] > at > org.apache.lucene.codecs.lucene84.Lucene84PostingsReader.(Lucene84PostingsReader.java:82) > ~[?:?] > at > org.apache.lucene.codecs.memory.FSTPostingsFormat.fieldsProducer(FSTPostingsFormat.java:66) > ~[?:?] > at > org.apache.lucene.codecs.perfield.PerFieldPostingsFormat$FieldsReader.(PerFieldPostingsFormat.java:315) > ~[?:?] > at > org.apache.lucene.codecs.perfield.PerFieldPostingsFormat.fieldsProducer(PerFieldPostingsFormat.java:395) > ~[?:?] > at > org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:114) > ~[?:?] > at >
[jira] [Commented] (SOLR-14254) Index backcompat break between 8.3.1 and 8.4.1
[ https://issues.apache.org/jira/browse/SOLR-14254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17033989#comment-17033989 ] David Smiley commented on SOLR-14254: - FST50 has a back-compat break but there is no back-compat guarantees for the non-default codec -- see LUCENE-9116. This is documented in {{field-type-definitions-and-properties.adoc}} but perhaps this should have been called out explicitly in the upgrade notes. > Index backcompat break between 8.3.1 and 8.4.1 > -- > > Key: SOLR-14254 > URL: https://issues.apache.org/jira/browse/SOLR-14254 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Jason Gerlowski >Priority: Major > > I believe I found a backcompat break between 8.4.1 and 8.3.1. > I encountered this when a Solr 8.3.1 cluster was upgraded to 8.4.1. On 8.4. > nodes, several collections had cores fail to come up with > {{CorruptIndexException}}: > {code} > 2020-02-10 20:58:26.136 ERROR > (coreContainerWorkExecutor-2-thread-1-processing-n:192.168.1.194:8983_solr) [ > ] o.a.s.c.CoreContainer Error waiting for SolrCore to be loaded on startup > => org.apache.sol > r.common.SolrException: Unable to create core > [testbackcompat_shard1_replica_n1] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1313) > org.apache.solr.common.SolrException: Unable to create core > [testbackcompat_shard1_replica_n1] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1313) > ~[?:?] > at > org.apache.solr.core.CoreContainer.lambda$load$13(CoreContainer.java:788) > ~[?:?] > at > com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:202) > ~[metrics-core-4.0.5.jar:4.0.5] > at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?] > at > org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:210) > ~[?:?] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > ~[?:?] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > ~[?:?] > at java.lang.Thread.run(Thread.java:834) [?:?] > Caused by: org.apache.solr.common.SolrException: Error opening new searcher > at org.apache.solr.core.SolrCore.(SolrCore.java:1072) ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:901) ~[?:?] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1292) > ~[?:?] > ... 7 more > Caused by: org.apache.solr.common.SolrException: Error opening new searcher > at org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:2182) > ~[?:?] > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:2302) > ~[?:?] > at org.apache.solr.core.SolrCore.initSearcher(SolrCore.java:1132) > ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:1013) ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:901) ~[?:?] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1292) > ~[?:?] > ... 7 more > Caused by: org.apache.lucene.index.CorruptIndexException: codec mismatch: > actual codec=Lucene50PostingsWriterDoc vs expected > codec=Lucene84PostingsWriterDoc > (resource=MMapIndexInput(path="/Users/jasongerlowski/run/solrdata/data/testbackcompat_shard1_replica_n1/data/index/_0_FST50_0.doc")) > at > org.apache.lucene.codecs.CodecUtil.checkHeaderNoMagic(CodecUtil.java:208) > ~[?:?] > at org.apache.lucene.codecs.CodecUtil.checkHeader(CodecUtil.java:198) > ~[?:?] > at > org.apache.lucene.codecs.CodecUtil.checkIndexHeader(CodecUtil.java:255) ~[?:?] > at > org.apache.lucene.codecs.lucene84.Lucene84PostingsReader.(Lucene84PostingsReader.java:82) > ~[?:?] > at > org.apache.lucene.codecs.memory.FSTPostingsFormat.fieldsProducer(FSTPostingsFormat.java:66) > ~[?:?] > at > org.apache.lucene.codecs.perfield.PerFieldPostingsFormat$FieldsReader.(PerFieldPostingsFormat.java:315) > ~[?:?] > at > org.apache.lucene.codecs.perfield.PerFieldPostingsFormat.fieldsProducer(PerFieldPostingsFormat.java:395) > ~[?:?] > at > org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:114) > ~[?:?] > at > org.apache.lucene.index.SegmentReader.(SegmentReader.java:84) ~[?:?] > at > org.apache.lucene.index.ReadersAndUpdates.getReader(ReadersAndUpdates.java:177) > ~[?:?] > at > org.apache.lucene.index.ReadersAndUpdates.getReadOnlyClone(ReadersAndUpdates.java:219) > ~[?:?] > at > org.apache.lucene.ind
[jira] [Commented] (SOLR-14254) Index backcompat break between 8.3.1 and 8.4.1
[ https://issues.apache.org/jira/browse/SOLR-14254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17033973#comment-17033973 ] Chris M. Hostetter commented on SOLR-14254: --- I think the problem here is that {{FSTPostingsFormat}} has always (and still) identifies itself with the name "FST50" -- and LUCENE-9027 changed the underlying writer/reader of {{FSTPostingsFormat}} from {{Lucene50PostingsWriter}} + {{Lucene50PostingsReader}} to {{Lucene84PostingsWriter}} + {{Lucene84PostingsReader}} ... w/o changing the "FST50" name passed to the {{PostingsFormat}} super constructor (or adding a new "FST50PostingsFormat" to the backcompat codecs) Which means -- IIUC -- when the "FST50" postings format is read from an 8.3.1 index, {{FSTPostingsFormat}} is used, but it tries to use {{Lucene84PostingsReader}} instead of {{Lucene50PostingsWriter}} ? (It looks like {{FSTOrdPostingsFormat}} might also have hte same bug?) > Index backcompat break between 8.3.1 and 8.4.1 > -- > > Key: SOLR-14254 > URL: https://issues.apache.org/jira/browse/SOLR-14254 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Jason Gerlowski >Priority: Major > > I believe I found a backcompat break between 8.4.1 and 8.3.1. > I encountered this when a Solr 8.3.1 cluster was upgraded to 8.4.1. On 8.4. > nodes, several collections had cores fail to come up with > {{CorruptIndexException}}: > {code} > 2020-02-10 20:58:26.136 ERROR > (coreContainerWorkExecutor-2-thread-1-processing-n:192.168.1.194:8983_solr) [ > ] o.a.s.c.CoreContainer Error waiting for SolrCore to be loaded on startup > => org.apache.sol > r.common.SolrException: Unable to create core > [testbackcompat_shard1_replica_n1] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1313) > org.apache.solr.common.SolrException: Unable to create core > [testbackcompat_shard1_replica_n1] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1313) > ~[?:?] > at > org.apache.solr.core.CoreContainer.lambda$load$13(CoreContainer.java:788) > ~[?:?] > at > com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:202) > ~[metrics-core-4.0.5.jar:4.0.5] > at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?] > at > org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:210) > ~[?:?] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > ~[?:?] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > ~[?:?] > at java.lang.Thread.run(Thread.java:834) [?:?] > Caused by: org.apache.solr.common.SolrException: Error opening new searcher > at org.apache.solr.core.SolrCore.(SolrCore.java:1072) ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:901) ~[?:?] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1292) > ~[?:?] > ... 7 more > Caused by: org.apache.solr.common.SolrException: Error opening new searcher > at org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:2182) > ~[?:?] > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:2302) > ~[?:?] > at org.apache.solr.core.SolrCore.initSearcher(SolrCore.java:1132) > ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:1013) ~[?:?] > at org.apache.solr.core.SolrCore.(SolrCore.java:901) ~[?:?] > at > org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1292) > ~[?:?] > ... 7 more > Caused by: org.apache.lucene.index.CorruptIndexException: codec mismatch: > actual codec=Lucene50PostingsWriterDoc vs expected > codec=Lucene84PostingsWriterDoc > (resource=MMapIndexInput(path="/Users/jasongerlowski/run/solrdata/data/testbackcompat_shard1_replica_n1/data/index/_0_FST50_0.doc")) > at > org.apache.lucene.codecs.CodecUtil.checkHeaderNoMagic(CodecUtil.java:208) > ~[?:?] > at org.apache.lucene.codecs.CodecUtil.checkHeader(CodecUtil.java:198) > ~[?:?] > at > org.apache.lucene.codecs.CodecUtil.checkIndexHeader(CodecUtil.java:255) ~[?:?] > at > org.apache.lucene.codecs.lucene84.Lucene84PostingsReader.(Lucene84PostingsReader.java:82) > ~[?:?] > at > org.apache.lucene.codecs.memory.FSTPostingsFormat.fieldsProducer(FSTPostingsFormat.java:66) > ~[?:?] > at > org.apache.lucene.codecs.perfield.PerFieldPostingsFormat$FieldsReader.(PerFieldPostingsFormat.java:315) > ~[?:?] > at > org.apache.lucene.codecs.perfield.PerFieldPostingsFo