[JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+140) - Build # 2160 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2160/ Java: 32bit/jdk-9-ea+140 -server -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.cloud.PeerSyncReplicationTest.test Error Message: PeerSync failed. Had to fail back to replication expected:<0> but was:<141> Stack Trace: java.lang.AssertionError: PeerSync failed. Had to fail back to replication expected:<0> but was:<141> at __randomizedtesting.SeedInfo.seed([B688C7EA28CE6CBB:3EDCF83086320143]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.apache.solr.cloud.PeerSyncReplicationTest.bringUpDeadNodeAndEnsureNoReplication(PeerSyncReplicationTest.java:290) at org.apache.solr.cloud.PeerSyncReplicationTest.forceNodeFailureAndDoPeerSync(PeerSyncReplicationTest.java:244) at org.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:130) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at
[jira] [Commented] (SOLR-9477) UpdateRequestProcessors ignore child documents
[
https://issues.apache.org/jira/browse/SOLR-9477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15658468#comment-15658468
]
David Smiley commented on SOLR-9477:
[~razen] DIH nested entities doesn't translate to sub-documents unless you were
to set {{child="true"}}, and I don't see why you would do that in your use-case.
> UpdateRequestProcessors ignore child documents
> --
>
> Key: SOLR-9477
> URL: https://issues.apache.org/jira/browse/SOLR-9477
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.2, master (7.0)
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
> Labels: UpdateProcessor
>
> UpdateRequestProcessors completely ignore child documents. The only exception
> is AddSchemaFieldsUpdateProcessorFactory. The rest seem to be completely
> unaware that SolrInputDocument has getChildDocuments() or related methods.
> Easy test (on Solr 6.2):
> This works (with IDs auto-assigned and field names generated):
> {code}
> bin/solr create -c childtest
> bin/post -c childtest -type application/json -format solr -d '[{"a":1,"b":2}]'
> {code}
> This fails as the second/third command, with "missing ID field":
> {code}
> bin/post -c childtest -type application/json -format solr -d
> '[{"a":1,"b":2,"_childDocuments_":[{"c":3,"d":4}]}]'
> {code}
> The message:
> {noformat}
> SimplePostTool version 5.0.0
> POSTing args to http://localhost:8983/solr/childtest/update...
> SimplePostTool: WARNING: Solr returned an error #400 (Bad Request) for url:
> http://localhost:8983/solr/childtest/update
> SimplePostTool: WARNING: Response:
> {"responseHeader":{"status":400,"QTime":4},"error":{"metadata":["error-class","org.apache.solr.common.SolrException","root-error-class","org.apache.solr.common.SolrException"],"msg":"[doc=null]
> missing required field: id","code":400}}
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/childtest/update
> COMMITting Solr index changes to
> http://localhost:8983/solr/childtest/update...
> Time spent: 0:00:00.042
> {noformat}
> I also verified it with BlankRemoving URP. I think this is a global problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Tests-MMAP-master - Build # 194 - Failure
Build: https://builds.apache.org/job/Lucene-Tests-MMAP-master/194/ 1 tests failed. FAILED: org.apache.lucene.search.grouping.TestGrouping.testBasic Error Message: expected:<[61 75 74 68 6f 72 33]> but was:<[61 75 74 68 6f 72 31]> Stack Trace: java.lang.AssertionError: expected:<[61 75 74 68 6f 72 33]> but was:<[61 75 74 68 6f 72 31]> at __randomizedtesting.SeedInfo.seed([F8923EE8245C91CE:536823FDFB8017E0]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:147) at org.apache.lucene.search.grouping.TestGrouping.compareGroupValue(TestGrouping.java:298) at org.apache.lucene.search.grouping.TestGrouping.testBasic(TestGrouping.java:165) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 6895 lines...] [junit4] Suite: org.apache.lucene.search.grouping.TestGrouping [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestGrouping -Dtests.method=testBasic -Dtests.seed=F8923EE8245C91CE -Dtests.multiplier=2 -Dtests.slow=true -Dtests.directory=MMapDirectory -Dtests.locale=ms -Dtests.timezone=Iceland -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [junit4] FAILURE 0.06s J0 |
[jira] [Comment Edited] (SOLR-9751) PreanalyzedField can cause schema corruption
[ https://issues.apache.org/jira/browse/SOLR-9751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15658385#comment-15658385 ] Steve Rowe edited comment on SOLR-9751 at 11/11/16 10:59 PM: - Patch with failing test, no fix yet. In a 2-node cluster with a 2-shard, rf=1 collection, the cluster enters a failure loop where it can't read the schema - my IDE ran out of memory trying to store the log output. In this test, the schema for which includes three types of PreAnalyzedField config, only 1 field has to be added before this condition occurs. was (Author: steve_rowe): Patch with failing test, no fix yet. In a 2-node cluster with a 2-shard, rf=1 collection, the cluster enters a failure loop where it can't read the schema - my IDE ran out of memory trying to store the log output. In this test, only 1 field has to be added before this condition occurs. > PreanalyzedField can cause schema corruption > > > Key: SOLR-9751 > URL: https://issues.apache.org/jira/browse/SOLR-9751 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Schema and Analysis >Affects Versions: 6.2, 6.3 >Reporter: liuyang >Assignee: Steve Rowe >Priority: Minor > Attachments: SOLR-9751.patch > > > The exception as follows: > Caused by: org.apache.solr.common.SolrException: Could not load conf for core > test_shard1_replica1: Can't load schema managed-schema: Plugin init failure > for [schema.xml] fieldType "preanalyzed": Cannot load analyzer: > org.apache.solr.schema.PreAnalyzedField$PreAnalyzedAnalyzer > at > org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:85) > at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1031) > ... 6 more > Caused by: org.apache.solr.common.SolrException: Can't load schema > managed-schema: Plugin init failure for [schema.xml] fieldType "preanalyzed": > Cannot load analyzer: > org.apache.solr.schema.PreAnalyzedField$PreAnalyzedAnalyzer > at org.apache.solr.schema.IndexSchema.readSchema(IndexSchema.java:600) > at org.apache.solr.schema.IndexSchema.(IndexSchema.java:183) > at > org.apache.solr.schema.ManagedIndexSchema.(ManagedIndexSchema.java:104) > at > org.apache.solr.schema.ManagedIndexSchemaFactory.create(ManagedIndexSchemaFactory.java:172) > at > org.apache.solr.schema.ManagedIndexSchemaFactory.create(ManagedIndexSchemaFactory.java:45) > at > org.apache.solr.schema.IndexSchemaFactory.buildIndexSchema(IndexSchemaFactory.java:75) > at > org.apache.solr.core.ConfigSetService.createIndexSchema(ConfigSetService.java:107) > at > org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:78) > ... 7 more > Test procedure: > 1.create collection using sample_techproducts_configs; > 2.add field in Solr web view; > 3.add field again in Solr web view. > manage-schema is modifyed as follows: > > > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-9477) UpdateRequestProcessors ignore child documents
[
https://issues.apache.org/jira/browse/SOLR-9477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15658432#comment-15658432
]
Manoj Lawrence edited comment on SOLR-9477 at 11/11/16 10:57 PM:
-
[~arafalov] This is my first involvement in the JIRA board here. If this is not
where we add use cases for the above bug, let me know I will move it to the
appropriate location.
We use dataimporthandler to fetch data from DB2. The tablespace is limited in
our organisation (not under my control), so if I join couple of large tables it
can't handle more than 1 million records.
So, we wanted to split the queries based on certain column values. And to avoid
repeating the query in mutiple entities, with different where clauses, I
decided to use DIH's ability to have nested entities. This way I am able to
split the query into some 20 parts for 12 million records.
That's where this issue with URP not supporting child entity fields is proving
to be roadblock for my solution.
was (Author: razen):
[~arafalov] This is my first involvement in the JIRA board here. If this not
where we add use cases for the above bug, let me know I will move it to the
appropriate location.
We use dataimporthandler to fetch data from DB2. The tablespace is limited in
our organisation (not under my control), so if I join couple of large tables it
can't handle more than 1 million records.
So, we wanted to split the queries based on certain column values. And to avoid
repeating the query in mutiple entities, with different where clauses, I
decided to use DIH's ability to have nested entities. This way I am able to
split the query into some 20 parts for 12 million records.
That's where this issue with URP not supporting child entity fields is proving
to be roadblock for my solution.
> UpdateRequestProcessors ignore child documents
> --
>
> Key: SOLR-9477
> URL: https://issues.apache.org/jira/browse/SOLR-9477
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.2, master (7.0)
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
> Labels: UpdateProcessor
>
> UpdateRequestProcessors completely ignore child documents. The only exception
> is AddSchemaFieldsUpdateProcessorFactory. The rest seem to be completely
> unaware that SolrInputDocument has getChildDocuments() or related methods.
> Easy test (on Solr 6.2):
> This works (with IDs auto-assigned and field names generated):
> {code}
> bin/solr create -c childtest
> bin/post -c childtest -type application/json -format solr -d '[{"a":1,"b":2}]'
> {code}
> This fails as the second/third command, with "missing ID field":
> {code}
> bin/post -c childtest -type application/json -format solr -d
> '[{"a":1,"b":2,"_childDocuments_":[{"c":3,"d":4}]}]'
> {code}
> The message:
> {noformat}
> SimplePostTool version 5.0.0
> POSTing args to http://localhost:8983/solr/childtest/update...
> SimplePostTool: WARNING: Solr returned an error #400 (Bad Request) for url:
> http://localhost:8983/solr/childtest/update
> SimplePostTool: WARNING: Response:
> {"responseHeader":{"status":400,"QTime":4},"error":{"metadata":["error-class","org.apache.solr.common.SolrException","root-error-class","org.apache.solr.common.SolrException"],"msg":"[doc=null]
> missing required field: id","code":400}}
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/childtest/update
> COMMITting Solr index changes to
> http://localhost:8983/solr/childtest/update...
> Time spent: 0:00:00.042
> {noformat}
> I also verified it with BlankRemoving URP. I think this is a global problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9477) UpdateRequestProcessors ignore child documents
[
https://issues.apache.org/jira/browse/SOLR-9477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15658432#comment-15658432
]
Manoj Lawrence commented on SOLR-9477:
--
[~arafalov] This is my first involvement in the JIRA board here. If this not
where we add use cases for the above bug, let me know I will move it to the
appropriate location.
We use dataimporthandler to fetch data from DB2. The tablespace is limited in
our organisation (not under my control), so if I join couple of large tables it
can't handle more than 1 million records.
So, we wanted to split the queries based on certain column values. And to avoid
repeating the query in mutiple entities, with different where clauses, I
decided to use DIH's ability to have nested entities. This way I am able to
split the query into some 20 parts for 12 million records.
That's where this issue with URP not supporting child entity fields is proving
to be roadblock for my solution.
> UpdateRequestProcessors ignore child documents
> --
>
> Key: SOLR-9477
> URL: https://issues.apache.org/jira/browse/SOLR-9477
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.2, master (7.0)
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
> Labels: UpdateProcessor
>
> UpdateRequestProcessors completely ignore child documents. The only exception
> is AddSchemaFieldsUpdateProcessorFactory. The rest seem to be completely
> unaware that SolrInputDocument has getChildDocuments() or related methods.
> Easy test (on Solr 6.2):
> This works (with IDs auto-assigned and field names generated):
> {code}
> bin/solr create -c childtest
> bin/post -c childtest -type application/json -format solr -d '[{"a":1,"b":2}]'
> {code}
> This fails as the second/third command, with "missing ID field":
> {code}
> bin/post -c childtest -type application/json -format solr -d
> '[{"a":1,"b":2,"_childDocuments_":[{"c":3,"d":4}]}]'
> {code}
> The message:
> {noformat}
> SimplePostTool version 5.0.0
> POSTing args to http://localhost:8983/solr/childtest/update...
> SimplePostTool: WARNING: Solr returned an error #400 (Bad Request) for url:
> http://localhost:8983/solr/childtest/update
> SimplePostTool: WARNING: Response:
> {"responseHeader":{"status":400,"QTime":4},"error":{"metadata":["error-class","org.apache.solr.common.SolrException","root-error-class","org.apache.solr.common.SolrException"],"msg":"[doc=null]
> missing required field: id","code":400}}
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/childtest/update
> COMMITting Solr index changes to
> http://localhost:8983/solr/childtest/update...
> Time spent: 0:00:00.042
> {noformat}
> I also verified it with BlankRemoving URP. I think this is a global problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9751) PreanalyzedField can cause schema corruption
[ https://issues.apache.org/jira/browse/SOLR-9751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Rowe updated SOLR-9751: - Attachment: SOLR-9751.patch Patch with failing test, no fix yet. In a 2-node cluster with a 2-shard, rf=1 collection, the cluster enters a failure loop where it can't read the schema - my IDE ran out of memory trying to store the log output. In this test, only 1 field has to be added before this condition occurs. > PreanalyzedField can cause schema corruption > > > Key: SOLR-9751 > URL: https://issues.apache.org/jira/browse/SOLR-9751 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Schema and Analysis >Affects Versions: 6.2, 6.3 >Reporter: liuyang >Assignee: Steve Rowe >Priority: Minor > Attachments: SOLR-9751.patch > > > The exception as follows: > Caused by: org.apache.solr.common.SolrException: Could not load conf for core > test_shard1_replica1: Can't load schema managed-schema: Plugin init failure > for [schema.xml] fieldType "preanalyzed": Cannot load analyzer: > org.apache.solr.schema.PreAnalyzedField$PreAnalyzedAnalyzer > at > org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:85) > at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1031) > ... 6 more > Caused by: org.apache.solr.common.SolrException: Can't load schema > managed-schema: Plugin init failure for [schema.xml] fieldType "preanalyzed": > Cannot load analyzer: > org.apache.solr.schema.PreAnalyzedField$PreAnalyzedAnalyzer > at org.apache.solr.schema.IndexSchema.readSchema(IndexSchema.java:600) > at org.apache.solr.schema.IndexSchema.(IndexSchema.java:183) > at > org.apache.solr.schema.ManagedIndexSchema.(ManagedIndexSchema.java:104) > at > org.apache.solr.schema.ManagedIndexSchemaFactory.create(ManagedIndexSchemaFactory.java:172) > at > org.apache.solr.schema.ManagedIndexSchemaFactory.create(ManagedIndexSchemaFactory.java:45) > at > org.apache.solr.schema.IndexSchemaFactory.buildIndexSchema(IndexSchemaFactory.java:75) > at > org.apache.solr.core.ConfigSetService.createIndexSchema(ConfigSetService.java:107) > at > org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:78) > ... 7 more > Test procedure: > 1.create collection using sample_techproducts_configs; > 2.add field in Solr web view; > 3.add field again in Solr web view. > manage-schema is modifyed as follows: > > > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 196 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.x/196/ 4 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationDistributedZkTest.testReplicationStartStop Error Message: Timeout while trying to assert number of documents @ target_collection Stack Trace: java.lang.AssertionError: Timeout while trying to assert number of documents @ target_collection at __randomizedtesting.SeedInfo.seed([B8961A865EFDEDDF:3B55C4154A256656]:0) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.assertNumDocs(BaseCdcrDistributedZkTest.java:271) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.testReplicationStartStop(CdcrReplicationDistributedZkTest.java:173) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[jira] [Commented] (SOLR-9746) Eclipse project broken due to duplicate package-info.java in LTR contrib
[
https://issues.apache.org/jira/browse/SOLR-9746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15658266#comment-15658266
]
Uwe Schindler commented on SOLR-9746:
-
Hi,
as said before, I would not share packages between JAR files. This is a problem
when we make the Lucene/Solr packages real Java 9 modules using
module-info.java. Currently it is not a problem because the legacy JAR files
use the legacy Java 9 classloader (all in one). But once they get modules every
JAR files has its own classloader and the module system disallows to *export*
same package (private packages are fine).
So in short: We should avoid sharing packages and not add *new* ones! So the
fix used here is fine.
> Eclipse project broken due to duplicate package-info.java in LTR contrib
>
>
> Key: SOLR-9746
> URL: https://issues.apache.org/jira/browse/SOLR-9746
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Christine Poerschke
>Priority: Minor
>
> The eclipse project generated through {{ant eclipse}} seems to be broken,
> since there are errors complaining duplicate resources. The problem is that
> the following files have the same package and class names:
> {code}
> ./solr/core/src/java/org/apache/solr/response/transform/package-info.java
> ./solr/contrib/ltr/src/java/org/apache/solr/response/transform/package-info.java
> ./solr/core/src/java/org/apache/solr/search/package-info.java
> ./solr/contrib/ltr/src/java/org/apache/solr/search/package-info.java
> {code}
> Not sure if the idea project is affected.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-9746) Eclipse project broken due to duplicate package-info.java in LTR contrib
[
https://issues.apache.org/jira/browse/SOLR-9746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15658266#comment-15658266
]
Uwe Schindler edited comment on SOLR-9746 at 11/11/16 9:46 PM:
---
Hi,
as said before, I would not share packages between JAR files. This is a problem
when we make the Lucene/Solr packages real Java 9 modules using
module-info.java. Currently it is not a problem because the legacy JAR files
use the legacy Java 9 classloader (all in one). But once they get modules every
JAR files has its own classloader and the module system disallows to *export*
same package (private packages are fine).
So in short: We should avoid sharing packages and not add *new* shared ones! So
the fix used here is fine.
was (Author: thetaphi):
Hi,
as said before, I would not share packages between JAR files. This is a problem
when we make the Lucene/Solr packages real Java 9 modules using
module-info.java. Currently it is not a problem because the legacy JAR files
use the legacy Java 9 classloader (all in one). But once they get modules every
JAR files has its own classloader and the module system disallows to *export*
same package (private packages are fine).
So in short: We should avoid sharing packages and not add *new* ones! So the
fix used here is fine.
> Eclipse project broken due to duplicate package-info.java in LTR contrib
>
>
> Key: SOLR-9746
> URL: https://issues.apache.org/jira/browse/SOLR-9746
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Christine Poerschke
>Priority: Minor
>
> The eclipse project generated through {{ant eclipse}} seems to be broken,
> since there are errors complaining duplicate resources. The problem is that
> the following files have the same package and class names:
> {code}
> ./solr/core/src/java/org/apache/solr/response/transform/package-info.java
> ./solr/contrib/ltr/src/java/org/apache/solr/response/transform/package-info.java
> ./solr/core/src/java/org/apache/solr/search/package-info.java
> ./solr/contrib/ltr/src/java/org/apache/solr/search/package-info.java
> {code}
> Not sure if the idea project is affected.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-9746) Eclipse project broken due to duplicate package-info.java in LTR contrib
[
https://issues.apache.org/jira/browse/SOLR-9746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15658256#comment-15658256
]
Ishan Chattopadhyaya edited comment on SOLR-9746 at 11/11/16 9:45 PM:
--
Indeed, Alexandre. It seems that the difference between these cases and the LTR
case was that the package-info.java file was duplicated in the LTR contrib.
-Perhaps just removing it from the contrib may have done the needful as well?-
Edit: Re-read Uwe's comment, and the committed fix seems the best long term.
was (Author: ichattopadhyaya):
Indeed, Alexandre. It seems that the difference between these cases and the LTR
case was that the package-info.java file was duplicated in the LTR contrib.
Perhaps just removing it from the contrib may have done the needful as well?
> Eclipse project broken due to duplicate package-info.java in LTR contrib
>
>
> Key: SOLR-9746
> URL: https://issues.apache.org/jira/browse/SOLR-9746
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Christine Poerschke
>Priority: Minor
>
> The eclipse project generated through {{ant eclipse}} seems to be broken,
> since there are errors complaining duplicate resources. The problem is that
> the following files have the same package and class names:
> {code}
> ./solr/core/src/java/org/apache/solr/response/transform/package-info.java
> ./solr/contrib/ltr/src/java/org/apache/solr/response/transform/package-info.java
> ./solr/core/src/java/org/apache/solr/search/package-info.java
> ./solr/contrib/ltr/src/java/org/apache/solr/search/package-info.java
> {code}
> Not sure if the idea project is affected.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9746) Eclipse project broken due to duplicate package-info.java in LTR contrib
[
https://issues.apache.org/jira/browse/SOLR-9746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15658256#comment-15658256
]
Ishan Chattopadhyaya commented on SOLR-9746:
Indeed, Alexandre. It seems that the difference between these cases and the LTR
case was that the package-info.java file was duplicated in the LTR contrib.
Perhaps just removing it from the contrib may have done the needful as well?
> Eclipse project broken due to duplicate package-info.java in LTR contrib
>
>
> Key: SOLR-9746
> URL: https://issues.apache.org/jira/browse/SOLR-9746
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Christine Poerschke
>Priority: Minor
>
> The eclipse project generated through {{ant eclipse}} seems to be broken,
> since there are errors complaining duplicate resources. The problem is that
> the following files have the same package and class names:
> {code}
> ./solr/core/src/java/org/apache/solr/response/transform/package-info.java
> ./solr/contrib/ltr/src/java/org/apache/solr/response/transform/package-info.java
> ./solr/core/src/java/org/apache/solr/search/package-info.java
> ./solr/contrib/ltr/src/java/org/apache/solr/search/package-info.java
> {code}
> Not sure if the idea project is affected.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9746) Eclipse project broken due to duplicate package-info.java in LTR contrib
[
https://issues.apache.org/jira/browse/SOLR-9746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15658231#comment-15658231
]
Alexandre Rafalovitch commented on SOLR-9746:
-
If I understood the question correctly, then the following is the list of
(non-test) java packages that appear in different directory roots. Package name
first, root second. Alternatively, I could do a similar test against the
shipped jars, if that's too much noise. I know I definitely have seen some
duplication at that point as well.
org/apache/lucene/analysis/icu - ./lucene/analysis/icu/src/java/
org/apache/lucene/analysis/icu - ./lucene/analysis/icu/src/tools/java/
org/apache/lucene/analysis/ja/util - ./lucene/analysis/kuromoji/src/java/
org/apache/lucene/analysis/ja/util - ./lucene/analysis/kuromoji/src/tools/java/
org/apache/lucene/analysis/standard - ./lucene/analysis/common/src/java/
org/apache/lucene/analysis/standard - ./lucene/analysis/common/src/tools/java/
org/apache/lucene/analysis/standard - ./lucene/core/src/java/
org/apache/lucene/codecs - ./lucene/backward-codecs/src/java/
org/apache/lucene/codecs - ./lucene/core/src/java/
org/apache/lucene/codecs/lucene50 - ./lucene/backward-codecs/src/java/
org/apache/lucene/codecs/lucene50 - ./lucene/core/src/java/
org/apache/lucene/codecs/lucene60 - ./lucene/backward-codecs/src/java/
org/apache/lucene/codecs/lucene60 - ./lucene/core/src/java/
org/apache/lucene/codecs/lucene62 - ./lucene/backward-codecs/src/java/
org/apache/lucene/codecs/lucene62 - ./lucene/core/src/java/
org/apache/lucene/collation - ./lucene/analysis/common/src/java/
org/apache/lucene/collation - ./lucene/analysis/icu/src/java/
org/apache/lucene/collation/tokenattributes - ./lucene/analysis/common/src/java/
org/apache/lucene/collation/tokenattributes - ./lucene/analysis/icu/src/java/
org/apache/lucene/document - ./lucene/core/src/java/
org/apache/lucene/document - ./lucene/misc/src/java/
org/apache/lucene/document - ./lucene/sandbox/src/java/
org/apache/lucene/index - ./lucene/core/src/java/
org/apache/lucene/index - ./lucene/misc/src/java/
org/apache/lucene/search - ./lucene/core/src/java/
org/apache/lucene/search - ./lucene/misc/src/java/
org/apache/lucene/search - ./lucene/sandbox/src/java/
org/apache/lucene/spatial - ./lucene/spatial-extras/src/java/
org/apache/lucene/spatial - ./lucene/spatial/src/java/
org/apache/lucene/spatial/util - ./lucene/spatial-extras/src/java/
org/apache/lucene/spatial/util - ./lucene/spatial/src/java/
org/apache/lucene/store - ./lucene/core/src/java/
org/apache/lucene/store - ./lucene/misc/src/java/
org/apache/lucene/util/fst - ./lucene/core/src/java/
org/apache/lucene/util/fst - ./lucene/misc/src/java/
org/apache/solr/handler/component - ./solr/contrib/analytics/src/java/
org/apache/solr/handler/component - ./solr/core/src/java/
org/apache/solr/handler/dataimport -
./solr/contrib/dataimporthandler-extras/src/java/
org/apache/solr/handler/dataimport - ./solr/contrib/dataimporthandler/src/java/
org/apache/solr/response - ./solr/contrib/velocity/src/java/
org/apache/solr/response - ./solr/core/src/java/
org/apache/solr/schema - ./solr/contrib/analysis-extras/src/java/
org/apache/solr/schema - ./solr/core/src/java/
org/apache/solr/update/processor - ./solr/contrib/langid/src/java/
org/apache/solr/update/processor - ./solr/core/src/java/
> Eclipse project broken due to duplicate package-info.java in LTR contrib
>
>
> Key: SOLR-9746
> URL: https://issues.apache.org/jira/browse/SOLR-9746
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Christine Poerschke
>Priority: Minor
>
> The eclipse project generated through {{ant eclipse}} seems to be broken,
> since there are errors complaining duplicate resources. The problem is that
> the following files have the same package and class names:
> {code}
> ./solr/core/src/java/org/apache/solr/response/transform/package-info.java
> ./solr/contrib/ltr/src/java/org/apache/solr/response/transform/package-info.java
> ./solr/core/src/java/org/apache/solr/search/package-info.java
> ./solr/contrib/ltr/src/java/org/apache/solr/search/package-info.java
> {code}
> Not sure if the idea project is affected.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7534) smokeTestRelease.py on cygwin [Errno 2] No such file or directory:
[
https://issues.apache.org/jira/browse/LUCENE-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15658211#comment-15658211
]
ASF subversion and git services commented on LUCENE-7534:
-
Commit fb4abd605de93b4e7283ad5a172e87a67c15f223 in lucene-solr's branch
refs/heads/branch_6x from [~mkhludnev]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=fb4abd6 ]
LUCENE-7534: fix smokeTestRelease.py to work on Cygwin
> smokeTestRelease.py on cygwin [Errno 2] No such file or directory:
> ---
>
> Key: LUCENE-7534
> URL: https://issues.apache.org/jira/browse/LUCENE-7534
> Project: Lucene - Core
> Issue Type: Bug
> Environment: Windows, Cygwin, Python
>Reporter: Mikhail Khludnev
> Attachments: 6.3.0 RC3 smoke passed on cygwin.txt, LUCENE-7534.patch,
> LUCENE-7534.patch, LUCENE-7534.patch, LUCENE-7534.patch, LUCENE-7534.patch,
> LUCENE-7534.patch, LUCENE-7534.patch, LUCENE-7534.patch, cloud test fail on
> smoke test.log, fail due to long classpath test.log
>
>
> {quote}
> $ python3 -u dev-tools/scripts/smokeTestRelease.py
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC2-rev1fe1a54db32b8c27bfae81887cd4d75242090613/
> Revision: 1fe1a54db32b8c27bfae81887cd4d75242090613
> Java 1.8 JAVA_HOME=C:\Program Files\Java\jdk1.8.0_102
> Traceback (most recent call last):
> File "dev-tools/scripts/smokeTestRelease.py", line 1440, in
> main()
> File "dev-tools/scripts/smokeTestRelease.py", line 1377, in main
> c = parse_config()
> File "dev-tools/scripts/smokeTestRelease.py", line 1239, in parse_config
> c.java = make_java_config(parser, c.test_java8)
> File "dev-tools/scripts/smokeTestRelease.py", line 1193, in make_java_config
> run_java8 = _make_runner(java8_home, '1.8')
> File "dev-tools/scripts/smokeTestRelease.py", line 1179, in _make_runner
> java_home = subprocess.check_output('cygpath -u "%s"' %
> java_home).read().decode('utf-8').strip()
> File "/usr/lib/python3.4/subprocess.py", line 607, in check_output
> with Popen(*popenargs, stdout=PIPE, **kwargs) as process:
> File "/usr/lib/python3.4/subprocess.py", line 859, in __init__
> restore_signals, start_new_session)
> File "/usr/lib/python3.4/subprocess.py", line 1457, in _execute_child
> raise child_exception_type(errno_num, err_msg)
> FileNotFoundError: [Errno 2] No such file or directory: 'cygpath -u
> "C:\\Program Files\\Java\\jdk1.8.0_102"'
> {quote}
> giving [the doc|https://docs.python.org/3.4/library/subprocess.html] path and
> args should be either supplied as array of terms or supplied as {{shell=True}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7534) smokeTestRelease.py on cygwin [Errno 2] No such file or directory:
[
https://issues.apache.org/jira/browse/LUCENE-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15658204#comment-15658204
]
ASF subversion and git services commented on LUCENE-7534:
-
Commit a209c4e8c259c66b8748656207d36db623d50856 in lucene-solr's branch
refs/heads/master from [~mkhludnev]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a209c4e ]
LUCENE-7534: fix smokeTestRelease.py to work on Cygwin
> smokeTestRelease.py on cygwin [Errno 2] No such file or directory:
> ---
>
> Key: LUCENE-7534
> URL: https://issues.apache.org/jira/browse/LUCENE-7534
> Project: Lucene - Core
> Issue Type: Bug
> Environment: Windows, Cygwin, Python
>Reporter: Mikhail Khludnev
> Attachments: 6.3.0 RC3 smoke passed on cygwin.txt, LUCENE-7534.patch,
> LUCENE-7534.patch, LUCENE-7534.patch, LUCENE-7534.patch, LUCENE-7534.patch,
> LUCENE-7534.patch, LUCENE-7534.patch, LUCENE-7534.patch, cloud test fail on
> smoke test.log, fail due to long classpath test.log
>
>
> {quote}
> $ python3 -u dev-tools/scripts/smokeTestRelease.py
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC2-rev1fe1a54db32b8c27bfae81887cd4d75242090613/
> Revision: 1fe1a54db32b8c27bfae81887cd4d75242090613
> Java 1.8 JAVA_HOME=C:\Program Files\Java\jdk1.8.0_102
> Traceback (most recent call last):
> File "dev-tools/scripts/smokeTestRelease.py", line 1440, in
> main()
> File "dev-tools/scripts/smokeTestRelease.py", line 1377, in main
> c = parse_config()
> File "dev-tools/scripts/smokeTestRelease.py", line 1239, in parse_config
> c.java = make_java_config(parser, c.test_java8)
> File "dev-tools/scripts/smokeTestRelease.py", line 1193, in make_java_config
> run_java8 = _make_runner(java8_home, '1.8')
> File "dev-tools/scripts/smokeTestRelease.py", line 1179, in _make_runner
> java_home = subprocess.check_output('cygpath -u "%s"' %
> java_home).read().decode('utf-8').strip()
> File "/usr/lib/python3.4/subprocess.py", line 607, in check_output
> with Popen(*popenargs, stdout=PIPE, **kwargs) as process:
> File "/usr/lib/python3.4/subprocess.py", line 859, in __init__
> restore_signals, start_new_session)
> File "/usr/lib/python3.4/subprocess.py", line 1457, in _execute_child
> raise child_exception_type(errno_num, err_msg)
> FileNotFoundError: [Errno 2] No such file or directory: 'cygpath -u
> "C:\\Program Files\\Java\\jdk1.8.0_102"'
> {quote}
> giving [the doc|https://docs.python.org/3.4/library/subprocess.html] path and
> args should be either supplied as array of terms or supplied as {{shell=True}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-9753) Admin UI - Memory Graph on Dashboard shows NaN for unused Swap
[
https://issues.apache.org/jira/browse/SOLR-9753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandre Rafalovitch reassigned SOLR-9753:
---
Assignee: Alexandre Rafalovitch
> Admin UI - Memory Graph on Dashboard shows NaN for unused Swap
> --
>
> Key: SOLR-9753
> URL: https://issues.apache.org/jira/browse/SOLR-9753
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: JSON Request API, web gui
>Affects Versions: 5.1
>Reporter: adeppa
>Assignee: Alexandre Rafalovitch
>
> If the System doesn't use Swap, the displayed memory graph on the dashboard
> shows NaN (not a number) because it tries to divide by zero.
> admin url : solr/collection/admin/system?wt=json&=true
> "system":{
> "name":"Linux",
> "version":"3.13.0-48-generic",
> "arch":"amd64",
> "systemLoadAverage":0.0,
> "committedVirtualMemorySize":27111653376,
> "freePhysicalMemorySize":48219590656,
> "freeSwapSpaceSize":0,
> "processCpuTime":6793865000,
> "totalPhysicalMemorySize":67548606464,
> "totalSwapSpaceSize":0,
> "openFileDescriptorCount":213,
> "maxFileDescriptorCount":4096,
> "uname":"Linux ip-172-22-65-57 3.13.0-48-generic #80-Ubuntu SMP Thu Mar
> 12 11:16:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux\n",
> "uptime":" 06:33:04 up 57 days, 20:20, 0 users, load average: 0.00,
> 0.01, 0.05\n"}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9753) Admin UI - Memory Graph on Dashboard shows NaN for unused Swap
[
https://issues.apache.org/jira/browse/SOLR-9753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15658164#comment-15658164
]
Alexandre Rafalovitch commented on SOLR-9753:
-
Can this be reproduced for latest Solr (6.3 or master)? Because, 5.x is no
longer updated and we already had SOLR-5178 closed for similar report.
> Admin UI - Memory Graph on Dashboard shows NaN for unused Swap
> --
>
> Key: SOLR-9753
> URL: https://issues.apache.org/jira/browse/SOLR-9753
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: JSON Request API, web gui
>Affects Versions: 5.1
>Reporter: adeppa
>
> If the System doesn't use Swap, the displayed memory graph on the dashboard
> shows NaN (not a number) because it tries to divide by zero.
> admin url : solr/collection/admin/system?wt=json&=true
> "system":{
> "name":"Linux",
> "version":"3.13.0-48-generic",
> "arch":"amd64",
> "systemLoadAverage":0.0,
> "committedVirtualMemorySize":27111653376,
> "freePhysicalMemorySize":48219590656,
> "freeSwapSpaceSize":0,
> "processCpuTime":6793865000,
> "totalPhysicalMemorySize":67548606464,
> "totalSwapSpaceSize":0,
> "openFileDescriptorCount":213,
> "maxFileDescriptorCount":4096,
> "uname":"Linux ip-172-22-65-57 3.13.0-48-generic #80-Ubuntu SMP Thu Mar
> 12 11:16:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux\n",
> "uptime":" 06:33:04 up 57 days, 20:20, 0 users, load average: 0.00,
> 0.01, 0.05\n"}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7534) smokeTestRelease.py on cygwin [Errno 2] No such file or directory:
[
https://issues.apache.org/jira/browse/LUCENE-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated LUCENE-7534:
-
Attachment: LUCENE-7534.patch
> smokeTestRelease.py on cygwin [Errno 2] No such file or directory:
> ---
>
> Key: LUCENE-7534
> URL: https://issues.apache.org/jira/browse/LUCENE-7534
> Project: Lucene - Core
> Issue Type: Bug
> Environment: Windows, Cygwin, Python
>Reporter: Mikhail Khludnev
> Attachments: 6.3.0 RC3 smoke passed on cygwin.txt, LUCENE-7534.patch,
> LUCENE-7534.patch, LUCENE-7534.patch, LUCENE-7534.patch, LUCENE-7534.patch,
> LUCENE-7534.patch, LUCENE-7534.patch, LUCENE-7534.patch, cloud test fail on
> smoke test.log, fail due to long classpath test.log
>
>
> {quote}
> $ python3 -u dev-tools/scripts/smokeTestRelease.py
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC2-rev1fe1a54db32b8c27bfae81887cd4d75242090613/
> Revision: 1fe1a54db32b8c27bfae81887cd4d75242090613
> Java 1.8 JAVA_HOME=C:\Program Files\Java\jdk1.8.0_102
> Traceback (most recent call last):
> File "dev-tools/scripts/smokeTestRelease.py", line 1440, in
> main()
> File "dev-tools/scripts/smokeTestRelease.py", line 1377, in main
> c = parse_config()
> File "dev-tools/scripts/smokeTestRelease.py", line 1239, in parse_config
> c.java = make_java_config(parser, c.test_java8)
> File "dev-tools/scripts/smokeTestRelease.py", line 1193, in make_java_config
> run_java8 = _make_runner(java8_home, '1.8')
> File "dev-tools/scripts/smokeTestRelease.py", line 1179, in _make_runner
> java_home = subprocess.check_output('cygpath -u "%s"' %
> java_home).read().decode('utf-8').strip()
> File "/usr/lib/python3.4/subprocess.py", line 607, in check_output
> with Popen(*popenargs, stdout=PIPE, **kwargs) as process:
> File "/usr/lib/python3.4/subprocess.py", line 859, in __init__
> restore_signals, start_new_session)
> File "/usr/lib/python3.4/subprocess.py", line 1457, in _execute_child
> raise child_exception_type(errno_num, err_msg)
> FileNotFoundError: [Errno 2] No such file or directory: 'cygpath -u
> "C:\\Program Files\\Java\\jdk1.8.0_102"'
> {quote}
> giving [the doc|https://docs.python.org/3.4/library/subprocess.html] path and
> args should be either supplied as array of terms or supplied as {{shell=True}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_102) - Build # 18259 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18259/ Java: 64bit/jdk1.8.0_102 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 2 tests failed. FAILED: org.apache.lucene.search.grouping.GroupingSearchTest.testBasic Error Message: expected:<[61 75 74 68 6f 72 33]> but was:<[61 75 74 68 6f 72 31]> Stack Trace: java.lang.AssertionError: expected:<[61 75 74 68 6f 72 33]> but was:<[61 75 74 68 6f 72 31]> at __randomizedtesting.SeedInfo.seed([26E177E5E4FC0BCB:8D1B6AF03B208DE5]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:147) at org.apache.lucene.search.grouping.GroupingSearchTest.compareGroupValue(GroupingSearchTest.java:192) at org.apache.lucene.search.grouping.GroupingSearchTest.testBasic(GroupingSearchTest.java:134) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) FAILED: org.apache.lucene.search.grouping.TestGrouping.testBasic Error Message: expected:<[61 75 74 68 6f 72 33]> but was:<[61 75 74 68 6f 72 31]> Stack Trace: java.lang.AssertionError: expected:<[61 75 74 68 6f 72 33]> but was:<[61 75 74 68 6f 72 31]> at
[jira] [Comment Edited] (SOLR-8593) Integrate Apache Calcite into the SQLHandler
[ https://issues.apache.org/jira/browse/SOLR-8593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15658025#comment-15658025 ] Julian Hyde edited comment on SOLR-8593 at 11/11/16 8:01 PM: - By the way, when you're ready, add please Solr to the [powered by Calcite|https://calcite.apache.org/docs/powered_by.html] page; see CALCITE-1112 for details. was (Author: julianhyde): By the way, when you're ready, add please Solr to the [powered by|https://calcite.apache.org/docs/powered_by.html] page; see CALCITE-1112 for details. > Integrate Apache Calcite into the SQLHandler > > > Key: SOLR-8593 > URL: https://issues.apache.org/jira/browse/SOLR-8593 > Project: Solr > Issue Type: Improvement >Reporter: Joel Bernstein >Assignee: Joel Bernstein > >The Presto SQL Parser was perfect for phase one of the SQLHandler. It was > nicely split off from the larger Presto project and it did everything that > was needed for the initial implementation. > Phase two of the SQL work though will require an optimizer. Here is where > Apache Calcite comes into play. It has a battle tested cost based optimizer > and has been integrated into Apache Drill and Hive. > This work can begin in trunk following the 6.0 release. The final query plans > will continue to be translated to Streaming API objects (TupleStreams), so > continued work on the JDBC driver should plug in nicely with the Calcite work. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8593) Integrate Apache Calcite into the SQLHandler
[ https://issues.apache.org/jira/browse/SOLR-8593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15658025#comment-15658025 ] Julian Hyde commented on SOLR-8593: --- By the way, when you're ready, add please Solr to the [powered by|https://calcite.apache.org/docs/powered_by.html] page; see CALCITE-1112 for details. > Integrate Apache Calcite into the SQLHandler > > > Key: SOLR-8593 > URL: https://issues.apache.org/jira/browse/SOLR-8593 > Project: Solr > Issue Type: Improvement >Reporter: Joel Bernstein >Assignee: Joel Bernstein > >The Presto SQL Parser was perfect for phase one of the SQLHandler. It was > nicely split off from the larger Presto project and it did everything that > was needed for the initial implementation. > Phase two of the SQL work though will require an optimizer. Here is where > Apache Calcite comes into play. It has a battle tested cost based optimizer > and has been integrated into Apache Drill and Hive. > This work can begin in trunk following the 6.0 release. The final query plans > will continue to be translated to Streaming API objects (TupleStreams), so > continued work on the JDBC driver should plug in nicely with the Calcite work. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9751) PreanalyzedField can cause schema corruption
[
https://issues.apache.org/jira/browse/SOLR-9751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15657957#comment-15657957
]
Steve Rowe commented on SOLR-9751:
--
Seems to only reproduce in cloud setups - I can repro with {{bin/solr -e
cloud}} but not {{bin/solr -e techproducts}}.
> PreanalyzedField can cause schema corruption
>
>
> Key: SOLR-9751
> URL: https://issues.apache.org/jira/browse/SOLR-9751
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Schema and Analysis
>Affects Versions: 6.2, 6.3
>Reporter: liuyang
>Assignee: Steve Rowe
>Priority: Minor
>
> The exception as follows:
> Caused by: org.apache.solr.common.SolrException: Could not load conf for core
> test_shard1_replica1: Can't load schema managed-schema: Plugin init failure
> for [schema.xml] fieldType "preanalyzed": Cannot load analyzer:
> org.apache.solr.schema.PreAnalyzedField$PreAnalyzedAnalyzer
> at
> org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:85)
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1031)
> ... 6 more
> Caused by: org.apache.solr.common.SolrException: Can't load schema
> managed-schema: Plugin init failure for [schema.xml] fieldType "preanalyzed":
> Cannot load analyzer:
> org.apache.solr.schema.PreAnalyzedField$PreAnalyzedAnalyzer
> at org.apache.solr.schema.IndexSchema.readSchema(IndexSchema.java:600)
> at org.apache.solr.schema.IndexSchema.(IndexSchema.java:183)
> at
> org.apache.solr.schema.ManagedIndexSchema.(ManagedIndexSchema.java:104)
> at
> org.apache.solr.schema.ManagedIndexSchemaFactory.create(ManagedIndexSchemaFactory.java:172)
> at
> org.apache.solr.schema.ManagedIndexSchemaFactory.create(ManagedIndexSchemaFactory.java:45)
> at
> org.apache.solr.schema.IndexSchemaFactory.buildIndexSchema(IndexSchemaFactory.java:75)
> at
> org.apache.solr.core.ConfigSetService.createIndexSchema(ConfigSetService.java:107)
> at
> org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:78)
> ... 7 more
> Test procedure:
> 1.create collection using sample_techproducts_configs;
> 2.add field in Solr web view;
> 3.add field again in Solr web view.
> manage-schema is modifyed as follows:
>
>
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-8332) factor HttpShardHandler[Factory]'s url shuffling out into a ReplicaListTransformer class
[ https://issues.apache.org/jira/browse/SOLR-8332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke resolved SOLR-8332. --- Resolution: Fixed Fix Version/s: master (7.0) 6.x Thanks [~noble.paul] for your input. > factor HttpShardHandler[Factory]'s url shuffling out into a > ReplicaListTransformer class > > > Key: SOLR-8332 > URL: https://issues.apache.org/jira/browse/SOLR-8332 > Project: Solr > Issue Type: Wish >Reporter: Christine Poerschke >Assignee: Christine Poerschke >Priority: Minor > Fix For: 6.x, master (7.0) > > Attachments: SOLR-8332.patch, SOLR-8332.patch, SOLR-8332.patch, > SOLR-8332.patch > > > Proposed patch against trunk to follow. No change in behaviour intended. This > would be as a step towards SOLR-6730. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-9746) Eclipse project broken due to duplicate package-info.java in LTR contrib
[
https://issues.apache.org/jira/browse/SOLR-9746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke resolved SOLR-9746.
---
Resolution: Fixed
Thanks [~ichattopadhyaya] for reporting this.
> Eclipse project broken due to duplicate package-info.java in LTR contrib
>
>
> Key: SOLR-9746
> URL: https://issues.apache.org/jira/browse/SOLR-9746
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Christine Poerschke
>Priority: Minor
>
> The eclipse project generated through {{ant eclipse}} seems to be broken,
> since there are errors complaining duplicate resources. The problem is that
> the following files have the same package and class names:
> {code}
> ./solr/core/src/java/org/apache/solr/response/transform/package-info.java
> ./solr/contrib/ltr/src/java/org/apache/solr/response/transform/package-info.java
> ./solr/core/src/java/org/apache/solr/search/package-info.java
> ./solr/contrib/ltr/src/java/org/apache/solr/search/package-info.java
> {code}
> Not sure if the idea project is affected.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9746) Eclipse project broken due to duplicate package-info.java in LTR contrib
[
https://issues.apache.org/jira/browse/SOLR-9746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15657885#comment-15657885
]
Christine Poerschke commented on SOLR-9746:
---
bq. ... I'd suggest to rename the packages in ltr to have "ltr" in its name. ...
>> Done.
bq. ... If the package names are the same to work around package-protected
access ...
>> The package names were made the same only with the intention that then no
>> solrconfig.xml changes would be required if ltr graduates from solr/contrib
>> to solr/core. However, the same effect should similarly so be achievable and
>> more clearly so via something like this as part of graduation
{code}
# solr/contrib/.../LTRQParserPlugin.java
package org.apache.solr.ltr.search;
- public class LTRQParserPlugin extends QParserPlugin implements ... {
- ...
- }
+ @Deprecated // use {@link org.apache.solr.search.LTRQParserPlugin} instead
+ public class LTRQParserPlugin extends org.apache.solr.search.LTRQParserPlugin
{
+ }
+ #solr/core/.../LTRQParserPlugin.java
+ package org.apache.solr.search;
+ public class LTRQParserPlugin extends QParserPlugin implements ... {
+ ...
+ }
{code}
bq. ... I know we have some modules in Lucene that also share packages, but we
should work on fixing them. ...
>> Interesting. I had a quick look around but couldn't find obvious examples,
>> assuming {{.../abc/util}} and {{.../xyz/util}} would be considered to not
>> share? If it doesn't exist already, shall we create a list of modules that
>> would need attention then?
> Eclipse project broken due to duplicate package-info.java in LTR contrib
>
>
> Key: SOLR-9746
> URL: https://issues.apache.org/jira/browse/SOLR-9746
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Christine Poerschke
>Priority: Minor
>
> The eclipse project generated through {{ant eclipse}} seems to be broken,
> since there are errors complaining duplicate resources. The problem is that
> the following files have the same package and class names:
> {code}
> ./solr/core/src/java/org/apache/solr/response/transform/package-info.java
> ./solr/contrib/ltr/src/java/org/apache/solr/response/transform/package-info.java
> ./solr/core/src/java/org/apache/solr/search/package-info.java
> ./solr/contrib/ltr/src/java/org/apache/solr/search/package-info.java
> {code}
> Not sure if the idea project is affected.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9752) Reliable test failure in TestFieldCacheSort (Solr copy)
[
https://issues.apache.org/jira/browse/SOLR-9752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15657882#comment-15657882
]
Erick Erickson commented on SOLR-9752:
--
I confess I was at the end of my endurance yesterday when I filed this, I
didn't explore it at all so I'll believe you ;)
> Reliable test failure in TestFieldCacheSort (Solr copy)
> ---
>
> Key: SOLR-9752
> URL: https://issues.apache.org/jira/browse/SOLR-9752
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Environment: OS X, Sierra
>Reporter: Erick Erickson
>
> I found this to reliably fail on 6x, see the whole dump below. At
> least the 4 times I tried it. I hit this running the full test suite
> for SOLR-9166, but then reproduced it on a fresh 6x checkout.
> It did NOT repro on trunk the one time I tried it there.
> OS X, Sierra
> Here's the test that failed, I didn't try other variants.
> ant test -Dtestcase=TestFieldCacheSort
> -Dtests.method=testFieldScoreReverse -Dtests.seed=8A982858396AE681
> -Dtests.slow=true -Dtests.locale=es-VE -Dtests.timezone=Asia/Baku
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
> [junit4:pickseed] Seed property 'tests.seed' already defined: 8A982858396AE681
>[junit4] says ciao! Master seed: 8A982858396AE681
>[junit4] Executing 1 suite with 1 JVM.
>[junit4]
>[junit4] Started J0 PID(19306@Ericks-MacBook-Pro.local).
>[junit4] Suite: org.apache.solr.uninverting.TestFieldCacheSort
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=TestFieldCacheSort -Dtests.method=testFieldScoreReverse
> -Dtests.seed=8A982858396AE681 -Dtests.slow=true -Dtests.locale=es-VE
> -Dtests.timezone=Asia/Baku -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 3.18s | TestFieldCacheSort.testFieldScoreReverse <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<0>
> but was:<1>
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([8A982858396AE681:F15FD36FC8A76C02]:0)
>[junit4]> at
> org.apache.solr.uninverting.TestFieldCacheSort.testFieldScoreReverse(TestFieldCacheSort.java:445)
>[junit4]> at java.lang.Thread.run(Thread.java:745)
>[junit4] 2> NOTE: test params are: codec=Asserting(Lucene62):
> {value=FSTOrd50}, docValues:{}, maxPointsInLeafNode=1095,
> maxMBSortInHeap=5.032597879580006,
> sim=RandomSimilarity(queryNorm=false,coord=crazy):
> {value=org.apache.lucene.search.similarities.BooleanSimilarity@5077995e},
> locale=es-VE, timezone=Asia/Baku
>[junit4] 2> NOTE: Mac OS X 10.12 x86_64/Oracle Corporation
> 1.8.0_45 (64-bit)/cpus=8,threads=1,free=243860576,total=257425408
>[junit4] 2> NOTE: All tests run in this JVM: [TestFieldCacheSort]
>[junit4] Completed [1/1 (1!)] in 6.14s, 1 test, 1 failure <<< FAILURES!
>[junit4] Tests with failures [seed: 8A982858396AE681]:
>[junit4] -
> org.apache.solr.uninverting.TestFieldCacheSort.testFieldScoreReverse
>[junit4] JVM J0: 0.57 .. 8.10 = 7.53s
>[junit4] Execution time total: 8.10 sec.
>[junit4] Tests summary: 1 suite, 1 test, 1 failure
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-9725) Allow Variables for All Data Import Handler Data Source Configuration Values
[
https://issues.apache.org/jira/browse/SOLR-9725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev reassigned SOLR-9725:
--
Assignee: Mikhail Khludnev
> Allow Variables for All Data Import Handler Data Source Configuration Values
>
>
> Key: SOLR-9725
> URL: https://issues.apache.org/jira/browse/SOLR-9725
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - DataImportHandler
>Affects Versions: 5.5.3
>Reporter: Jamie Jackson
>Assignee: Mikhail Khludnev
>Priority: Minor
> Labels: patch
>
> I need to be able to use a variable for a password when also using
> {{encryptKeyFile}}.
> For instance:
> {code:xml}
> driver="${custom.dataimporter.datasource.driver}"
> url="${custom.dataimporter.datasource.url}"
> user="${custom.dataimporter.datasource.user}"
> password="${custom.dataimporter.datasource.password}"
> encryptKeyFile="/opt/solr/credentials/encrypt.key"
> />
> {code}
> Because I need to change certain variables based on the environment. I'd
> start like this:
> {code}
> -a
> -Dcustom.dataimporter.datasource.driver=org.mariadb.jdbc.Driver
>
> -Dcustom.dataimporter.datasource.url=jdbc:mysql://local.mysite.com:3306/mysite
> -Dcustom.dataimporter.datasource.user=root
>
> -Dcustom.dataimporter.datasource.password=U2FsdGVkX1/dqwTb8RBfFq82SM37DkDRGeWMOndftHY=
> {code}
> If I hardcode the password, it works; if I use a variable reference, it
> doesn't.
> As far as I know [this pull
> request|https://github.com/apache/lucene-solr/pull/46] was submitted to
> address this issue, but it didn't come with a Jira ticket or a full
> explanation.
> Also, note that I'm not using a variable for the value of {{encryptKeyFile}},
> because [it's not possible in 5.x, though it seems to be fixed in
> 6.1|https://issues.apache.org/jira/browse/SOLR-8610]. Presumably, the above
> patch would encompass {{encryptKeyFile}}'s value, as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8542) Integrate Learning to Rank into Solr
[ https://issues.apache.org/jira/browse/SOLR-8542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15657874#comment-15657874 ] ASF subversion and git services commented on SOLR-8542: --- Commit 2c752b04cb63c0b6638f14959839b15fa1fa3e5a in lucene-solr's branch refs/heads/master from [~Michael Nilsson] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2c752b0 ] SOLR-8542: disallow reRankDocs<1 i.e. must rerank at least 1 document (Michael Nilsson via Christine Poerschke) > Integrate Learning to Rank into Solr > > > Key: SOLR-8542 > URL: https://issues.apache.org/jira/browse/SOLR-8542 > Project: Solr > Issue Type: New Feature >Reporter: Joshua Pantony >Assignee: Christine Poerschke >Priority: Minor > Attachments: SOLR-8542-branch_5x.patch, SOLR-8542-trunk.patch, > SOLR-8542.patch > > > This is a ticket to integrate learning to rank machine learning models into > Solr. Solr Learning to Rank (LTR) provides a way for you to extract features > directly inside Solr for use in training a machine learned model. You can > then deploy that model to Solr and use it to rerank your top X search > results. This concept was previously [presented by the authors at Lucene/Solr > Revolution > 2015|http://www.slideshare.net/lucidworks/learning-to-rank-in-solr-presented-by-michael-nilsson-diego-ceccarelli-bloomberg-lp]. > [Read through the > README|https://github.com/bloomberg/lucene-solr/tree/master-ltr-plugin-release/solr/contrib/ltr] > for a tutorial on using the plugin, in addition to how to train your own > external model. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9746) Eclipse project broken due to duplicate package-info.java in LTR contrib
[
https://issues.apache.org/jira/browse/SOLR-9746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15657876#comment-15657876
]
ASF subversion and git services commented on SOLR-9746:
---
Commit 86a515789f6e4626d71480c7fdf38c33b71ded93 in lucene-solr's branch
refs/heads/master from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=86a5157 ]
SOLR-8542, SOLR-9746: prefix solr/contrib/ltr's search and response.transform
packages with ltr
> Eclipse project broken due to duplicate package-info.java in LTR contrib
>
>
> Key: SOLR-9746
> URL: https://issues.apache.org/jira/browse/SOLR-9746
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Christine Poerschke
>Priority: Minor
>
> The eclipse project generated through {{ant eclipse}} seems to be broken,
> since there are errors complaining duplicate resources. The problem is that
> the following files have the same package and class names:
> {code}
> ./solr/core/src/java/org/apache/solr/response/transform/package-info.java
> ./solr/contrib/ltr/src/java/org/apache/solr/response/transform/package-info.java
> ./solr/core/src/java/org/apache/solr/search/package-info.java
> ./solr/contrib/ltr/src/java/org/apache/solr/search/package-info.java
> {code}
> Not sure if the idea project is affected.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8542) Integrate Learning to Rank into Solr
[ https://issues.apache.org/jira/browse/SOLR-8542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15657875#comment-15657875 ] ASF subversion and git services commented on SOLR-8542: --- Commit 86a515789f6e4626d71480c7fdf38c33b71ded93 in lucene-solr's branch refs/heads/master from [~cpoerschke] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=86a5157 ] SOLR-8542, SOLR-9746: prefix solr/contrib/ltr's search and response.transform packages with ltr > Integrate Learning to Rank into Solr > > > Key: SOLR-8542 > URL: https://issues.apache.org/jira/browse/SOLR-8542 > Project: Solr > Issue Type: New Feature >Reporter: Joshua Pantony >Assignee: Christine Poerschke >Priority: Minor > Attachments: SOLR-8542-branch_5x.patch, SOLR-8542-trunk.patch, > SOLR-8542.patch > > > This is a ticket to integrate learning to rank machine learning models into > Solr. Solr Learning to Rank (LTR) provides a way for you to extract features > directly inside Solr for use in training a machine learned model. You can > then deploy that model to Solr and use it to rerank your top X search > results. This concept was previously [presented by the authors at Lucene/Solr > Revolution > 2015|http://www.slideshare.net/lucidworks/learning-to-rank-in-solr-presented-by-michael-nilsson-diego-ceccarelli-bloomberg-lp]. > [Read through the > README|https://github.com/bloomberg/lucene-solr/tree/master-ltr-plugin-release/solr/contrib/ltr] > for a tutorial on using the plugin, in addition to how to train your own > external model. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-7547) JapaneseTokenizerFactory opens dictionary file but never closes it again
[ https://issues.apache.org/jira/browse/LUCENE-7547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-7547. Resolution: Fixed Fix Version/s: 6.4 master (7.0) Thanks [~nabucko], I pushed a fix. > JapaneseTokenizerFactory opens dictionary file but never closes it again > > > Key: LUCENE-7547 > URL: https://issues.apache.org/jira/browse/LUCENE-7547 > Project: Lucene - Core > Issue Type: Bug > Components: modules/analysis >Reporter: Markus > Fix For: master (7.0), 6.4 > > > JapaneseTokenizerFactory opens dictionary file in line 130 > InputStream stream = loader.openResource(userDictionaryPath); > but never closes it again. > This leads to too many open files after after a couple of query executions. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7547) JapaneseTokenizerFactory opens dictionary file but never closes it again
[ https://issues.apache.org/jira/browse/LUCENE-7547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15657780#comment-15657780 ] ASF subversion and git services commented on LUCENE-7547: - Commit ecff2519b830e2436df835635e2395efe86dff1e in lucene-solr's branch refs/heads/branch_6x from Mike McCandless [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ecff251 ] LUCENE-7547: close the dictionary file so we don't leak file handles > JapaneseTokenizerFactory opens dictionary file but never closes it again > > > Key: LUCENE-7547 > URL: https://issues.apache.org/jira/browse/LUCENE-7547 > Project: Lucene - Core > Issue Type: Bug > Components: modules/analysis >Reporter: Markus > > JapaneseTokenizerFactory opens dictionary file in line 130 > InputStream stream = loader.openResource(userDictionaryPath); > but never closes it again. > This leads to too many open files after after a couple of query executions. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7547) JapaneseTokenizerFactory opens dictionary file but never closes it again
[ https://issues.apache.org/jira/browse/LUCENE-7547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15657776#comment-15657776 ] ASF subversion and git services commented on LUCENE-7547: - Commit bd6c0523c2de09250ff07db6e4a21227bd143ea2 in lucene-solr's branch refs/heads/master from Mike McCandless [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=bd6c052 ] LUCENE-7547: close the dictionary file so we don't leak file handles > JapaneseTokenizerFactory opens dictionary file but never closes it again > > > Key: LUCENE-7547 > URL: https://issues.apache.org/jira/browse/LUCENE-7547 > Project: Lucene - Core > Issue Type: Bug > Components: modules/analysis >Reporter: Markus > > JapaneseTokenizerFactory opens dictionary file in line 130 > InputStream stream = loader.openResource(userDictionaryPath); > but never closes it again. > This leads to too many open files after after a couple of query executions. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9751) PreanalyzedField can cause schema corruption
[
https://issues.apache.org/jira/browse/SOLR-9751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15657761#comment-15657761
]
Steve Rowe commented on SOLR-9751:
--
More complete stack trace:
{noformat}
Caused by: org.apache.solr.common.SolrException: Plugin init failure for
[schema.xml] fieldType "preanalyzed": Cannot load analyzer:
org.apache.solr.schema.PreAnalyzedField$PreAnalyzedAnalyzer
at
org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:182)
at org.apache.solr.schema.IndexSchema.readSchema(IndexSchema.java:491)
... 36 more
Caused by: org.apache.solr.common.SolrException: Cannot load analyzer:
org.apache.solr.schema.PreAnalyzedField$PreAnalyzedAnalyzer
at
org.apache.solr.schema.FieldTypePluginLoader.readAnalyzer(FieldTypePluginLoader.java:287)
at
org.apache.solr.schema.FieldTypePluginLoader.create(FieldTypePluginLoader.java:104)
at
org.apache.solr.schema.FieldTypePluginLoader.create(FieldTypePluginLoader.java:53)
at
org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:152)
... 37 more
Caused by: java.lang.InstantiationException:
org.apache.solr.schema.PreAnalyzedField$PreAnalyzedAnalyzer
at java.lang.Class.newInstance(Class.java:427)
at
org.apache.solr.schema.FieldTypePluginLoader.readAnalyzer(FieldTypePluginLoader.java:271)
... 40 more
Caused by: java.lang.NoSuchMethodException:
org.apache.solr.schema.PreAnalyzedField$PreAnalyzedAnalyzer.()
at java.lang.Class.getConstructor0(Class.java:3082)
at java.lang.Class.newInstance(Class.java:412)
... 41 more
{noformat}
The (private) PreAnalyzedAnalyzer doesn't have a default ctor - its only ctor
requires a parser param.
Note that this ^^ is not really the problem - the problem is that serialization
is losing information (the query-time analysis chain) and instead including a
built-in non-substitutable analyzer: PreAnalyzedField doesn't allow
re-configuration of its index-time analysis chain.
> PreanalyzedField can cause schema corruption
>
>
> Key: SOLR-9751
> URL: https://issues.apache.org/jira/browse/SOLR-9751
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Schema and Analysis
>Affects Versions: 6.2, 6.3
>Reporter: liuyang
>Assignee: Steve Rowe
>Priority: Minor
>
> The exception as follows:
> Caused by: org.apache.solr.common.SolrException: Could not load conf for core
> test_shard1_replica1: Can't load schema managed-schema: Plugin init failure
> for [schema.xml] fieldType "preanalyzed": Cannot load analyzer:
> org.apache.solr.schema.PreAnalyzedField$PreAnalyzedAnalyzer
> at
> org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:85)
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1031)
> ... 6 more
> Caused by: org.apache.solr.common.SolrException: Can't load schema
> managed-schema: Plugin init failure for [schema.xml] fieldType "preanalyzed":
> Cannot load analyzer:
> org.apache.solr.schema.PreAnalyzedField$PreAnalyzedAnalyzer
> at org.apache.solr.schema.IndexSchema.readSchema(IndexSchema.java:600)
> at org.apache.solr.schema.IndexSchema.(IndexSchema.java:183)
> at
> org.apache.solr.schema.ManagedIndexSchema.(ManagedIndexSchema.java:104)
> at
> org.apache.solr.schema.ManagedIndexSchemaFactory.create(ManagedIndexSchemaFactory.java:172)
> at
> org.apache.solr.schema.ManagedIndexSchemaFactory.create(ManagedIndexSchemaFactory.java:45)
> at
> org.apache.solr.schema.IndexSchemaFactory.buildIndexSchema(IndexSchemaFactory.java:75)
> at
> org.apache.solr.core.ConfigSetService.createIndexSchema(ConfigSetService.java:107)
> at
> org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:78)
> ... 7 more
> Test procedure:
> 1.create collection using sample_techproducts_configs;
> 2.add field in Solr web view;
> 3.add field again in Solr web view.
> manage-schema is modifyed as follows:
>
>
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7537) Add multi valued field support to index sorting
[
https://issues.apache.org/jira/browse/LUCENE-7537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15657742#comment-15657742
]
Michael McCandless commented on LUCENE-7537:
Thanks [~jim.ferenczi] this looks cleaner!
In {{Lucene62SegmentInfoFormat.java}}, when we throw
{{IllegalArgumentException}}, can we change it to include the sortField,
not just its .getType()?
I think you need to fix {{SimpleTextCodec}} too? I hit this failure:
{noformat}
[junit4] Suite:
org.apache.lucene.codecs.simpletext.TestSimpleTextSegmentInfoFormat
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=TestSimpleTextSegmentInfoFormat -Dtests.method=testSort
-Dtests.seed=61D2298FBC9DEB3E -Dtests.locale=el-CY
-Dtests.timezone=America/Indiana/Petersburg -Dtests.asserts=true
-Dtests.file.encoding=UTF-8
[junit4] ERROR 0.01s J0 | TestSimpleTextSegmentInfoFormat.testSort <<<
[junit4]> Throwable #1: java.lang.IllegalStateException: Unexpected sort
type: CUSTOM
[junit4]>at
__randomizedtesting.SeedInfo.seed([61D2298FBC9DEB3E:303701A677D0F12E]:0)
[junit4]>at
org.apache.lucene.codecs.simpletext.SimpleTextSegmentInfoFormat.write(SimpleTextSegmentInfoFormat.java:373)
[junit4]>at
org.apache.lucene.index.BaseSegmentInfoFormatTestCase.testSort(BaseSegmentInfoFormatTestCase.java:268)
[junit4]>at java.lang.Thread.run(Thread.java:745)
[junit4] 2> NOTE: leaving temporary files on disk at:
/l/jim/lucene/build/codecs/test/J0/temp/lucene.codecs.simpletext.TestSimpleTextSegmentInfoFormat_61D22
{noformat}
The new {{CorruptIndexException}} s thrown in
{{Lucene62SegmentInfoFormat.java}} have the wrong message I think?
Shouldn't it be something like {{"invalid SortedSetSelector type: " + type}} ?
Can you bump the version value in {{Lucene62SegmentInfoFormat.java}},
and set {{VERSION_CURRENT}} to the new version? We need to do this
when we make any index format change so that if e.g. and old Lucene
version tries to read a newer index (written with this change) they
see an {{IndexFormatTooNewException}} and not
{{CorruptIndexException}}.
> Add multi valued field support to index sorting
> ---
>
> Key: LUCENE-7537
> URL: https://issues.apache.org/jira/browse/LUCENE-7537
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/index
>Reporter: Ferenczi Jim
> Attachments: LUCENE-7537.patch, LUCENE-7537.patch
>
>
> Today index sorting can be done on single valued field through the
> NumericDocValues (for numerics) and SortedDocValues (for strings).
> I'd like to add the ability to sort on multi valued fields. Since index
> sorting does not accept custom comparator we could just take the minimum
> value of each document for an ascending sort and the maximum value for a
> descending sort.
> This way we could handle all cases instead of throwing an exception during a
> merge when we encounter a multi valued DVs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9751) PreanalyzedField can cause schema corruption
[ https://issues.apache.org/jira/browse/SOLR-9751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Rowe updated SOLR-9751: - Affects Version/s: 6.3 > PreanalyzedField can cause schema corruption > > > Key: SOLR-9751 > URL: https://issues.apache.org/jira/browse/SOLR-9751 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Schema and Analysis >Affects Versions: 6.2, 6.3 >Reporter: liuyang >Assignee: Steve Rowe >Priority: Minor > > The exception as follows: > Caused by: org.apache.solr.common.SolrException: Could not load conf for core > test_shard1_replica1: Can't load schema managed-schema: Plugin init failure > for [schema.xml] fieldType "preanalyzed": Cannot load analyzer: > org.apache.solr.schema.PreAnalyzedField$PreAnalyzedAnalyzer > at > org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:85) > at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1031) > ... 6 more > Caused by: org.apache.solr.common.SolrException: Can't load schema > managed-schema: Plugin init failure for [schema.xml] fieldType "preanalyzed": > Cannot load analyzer: > org.apache.solr.schema.PreAnalyzedField$PreAnalyzedAnalyzer > at org.apache.solr.schema.IndexSchema.readSchema(IndexSchema.java:600) > at org.apache.solr.schema.IndexSchema.(IndexSchema.java:183) > at > org.apache.solr.schema.ManagedIndexSchema.(ManagedIndexSchema.java:104) > at > org.apache.solr.schema.ManagedIndexSchemaFactory.create(ManagedIndexSchemaFactory.java:172) > at > org.apache.solr.schema.ManagedIndexSchemaFactory.create(ManagedIndexSchemaFactory.java:45) > at > org.apache.solr.schema.IndexSchemaFactory.buildIndexSchema(IndexSchemaFactory.java:75) > at > org.apache.solr.core.ConfigSetService.createIndexSchema(ConfigSetService.java:107) > at > org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:78) > ... 7 more > Test procedure: > 1.create collection using sample_techproducts_configs; > 2.add field in Solr web view; > 3.add field again in Solr web view. > manage-schema is modifyed as follows: > > > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9751) PreanalyzedField can cause schema corruption
[
https://issues.apache.org/jira/browse/SOLR-9751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15657718#comment-15657718
]
Steve Rowe commented on SOLR-9751:
--
The admin UI is not the problem - I can reproduce by cmdline only.
The original preanalyzed fieldtype is:
{code:xml}
{code}
After one field (any field type will do) is added, it becomes:
{code:xml}
{code}
and after the second field is added:
{code:xml}
{code}
> PreanalyzedField can cause schema corruption
>
>
> Key: SOLR-9751
> URL: https://issues.apache.org/jira/browse/SOLR-9751
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Schema and Analysis
>Affects Versions: 6.2
>Reporter: liuyang
>Assignee: Steve Rowe
>Priority: Minor
>
> The exception as follows:
> Caused by: org.apache.solr.common.SolrException: Could not load conf for core
> test_shard1_replica1: Can't load schema managed-schema: Plugin init failure
> for [schema.xml] fieldType "preanalyzed": Cannot load analyzer:
> org.apache.solr.schema.PreAnalyzedField$PreAnalyzedAnalyzer
> at
> org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:85)
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1031)
> ... 6 more
> Caused by: org.apache.solr.common.SolrException: Can't load schema
> managed-schema: Plugin init failure for [schema.xml] fieldType "preanalyzed":
> Cannot load analyzer:
> org.apache.solr.schema.PreAnalyzedField$PreAnalyzedAnalyzer
> at org.apache.solr.schema.IndexSchema.readSchema(IndexSchema.java:600)
> at org.apache.solr.schema.IndexSchema.(IndexSchema.java:183)
> at
> org.apache.solr.schema.ManagedIndexSchema.(ManagedIndexSchema.java:104)
> at
> org.apache.solr.schema.ManagedIndexSchemaFactory.create(ManagedIndexSchemaFactory.java:172)
> at
> org.apache.solr.schema.ManagedIndexSchemaFactory.create(ManagedIndexSchemaFactory.java:45)
> at
> org.apache.solr.schema.IndexSchemaFactory.buildIndexSchema(IndexSchemaFactory.java:75)
> at
> org.apache.solr.core.ConfigSetService.createIndexSchema(ConfigSetService.java:107)
> at
> org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:78)
> ... 7 more
> Test procedure:
> 1.create collection using sample_techproducts_configs;
> 2.add field in Solr web view;
> 3.add field again in Solr web view.
> manage-schema is modifyed as follows:
>
>
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-7546) Rename uses of people.apache.org to home.apache.org
[ https://issues.apache.org/jira/browse/LUCENE-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley resolved LUCENE-7546. -- Resolution: Fixed Fix Version/s: 6.4 > Rename uses of people.apache.org to home.apache.org > --- > > Key: LUCENE-7546 > URL: https://issues.apache.org/jira/browse/LUCENE-7546 > Project: Lucene - Core > Issue Type: Task >Reporter: David Smiley > Fix For: 6.4 > > Attachments: LUCENE_7546.patch > > > The people.apache.org server was replaced by a different server > home.apache.org officially last year, and it appears to have completed > sometime this year. DNS for both points to the same machine but we should > reference home.apache.org now. *Unfortunately, some data was large enough > that ASF Infra didn't automatically move it, leaving that up to the > individuals to do. I think any data that hasn't been moved by now might be > gone.* > Here's a useful reference to this: EMPIREDB-234 The second part of that > issue also informs us that RC artifacts don't belong on home.apache.org; > there is https://dist.apache.org/repos/dist/dev/ for that. 6.3 was > done the right way... yet I see references to using people.apache.org in the > build for RCs. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7546) Rename uses of people.apache.org to home.apache.org
[ https://issues.apache.org/jira/browse/LUCENE-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15657673#comment-15657673 ] ASF subversion and git services commented on LUCENE-7546: - Commit d8d3d29f9911c3057df553950d203f5ce22a9110 in lucene-solr's branch refs/heads/branch_6x from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d8d3d29 ] LUCENE-7546: people.apache.org -> home.apache.org (cherry picked from commit 77605fe) > Rename uses of people.apache.org to home.apache.org > --- > > Key: LUCENE-7546 > URL: https://issues.apache.org/jira/browse/LUCENE-7546 > Project: Lucene - Core > Issue Type: Task >Reporter: David Smiley > Attachments: LUCENE_7546.patch > > > The people.apache.org server was replaced by a different server > home.apache.org officially last year, and it appears to have completed > sometime this year. DNS for both points to the same machine but we should > reference home.apache.org now. *Unfortunately, some data was large enough > that ASF Infra didn't automatically move it, leaving that up to the > individuals to do. I think any data that hasn't been moved by now might be > gone.* > Here's a useful reference to this: EMPIREDB-234 The second part of that > issue also informs us that RC artifacts don't belong on home.apache.org; > there is https://dist.apache.org/repos/dist/dev/ for that. 6.3 was > done the right way... yet I see references to using people.apache.org in the > build for RCs. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7546) Rename uses of people.apache.org to home.apache.org
[ https://issues.apache.org/jira/browse/LUCENE-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15657671#comment-15657671 ] ASF subversion and git services commented on LUCENE-7546: - Commit 77605fe7b72ff0ca81f84a554abc86b1bbc79ffe in lucene-solr's branch refs/heads/master from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=77605fe ] LUCENE-7546: people.apache.org -> home.apache.org > Rename uses of people.apache.org to home.apache.org > --- > > Key: LUCENE-7546 > URL: https://issues.apache.org/jira/browse/LUCENE-7546 > Project: Lucene - Core > Issue Type: Task >Reporter: David Smiley > Attachments: LUCENE_7546.patch > > > The people.apache.org server was replaced by a different server > home.apache.org officially last year, and it appears to have completed > sometime this year. DNS for both points to the same machine but we should > reference home.apache.org now. *Unfortunately, some data was large enough > that ASF Infra didn't automatically move it, leaving that up to the > individuals to do. I think any data that hasn't been moved by now might be > gone.* > Here's a useful reference to this: EMPIREDB-234 The second part of that > issue also informs us that RC artifacts don't belong on home.apache.org; > there is https://dist.apache.org/repos/dist/dev/ for that. 6.3 was > done the right way... yet I see references to using people.apache.org in the > build for RCs. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-9756) CollapsingQParserPlugin doc should point out limitations
Neil Ireson created SOLR-9756: - Summary: CollapsingQParserPlugin doc should point out limitations Key: SOLR-9756 URL: https://issues.apache.org/jira/browse/SOLR-9756 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 6.3 Reporter: Neil Ireson Priority: Minor It would be good if the JavaDoc stated "min/max must be either TrieInt, TrieLong or TrieFloat." rather than it being a pleasant surprise when you try to use the function. Also is there any fundamental reason why the function is limited to these three field types. I had a look at the code and as far as I can fathom there's no reason why bytes, shorts and doubles couldn't also be included. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9751) PreanalyzedField can cause schema corruption
[ https://issues.apache.org/jira/browse/SOLR-9751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15657546#comment-15657546 ] Steve Rowe commented on SOLR-9751: -- I can reproduce on master. I'm looking into it. > PreanalyzedField can cause schema corruption > > > Key: SOLR-9751 > URL: https://issues.apache.org/jira/browse/SOLR-9751 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Schema and Analysis >Affects Versions: 6.2 >Reporter: liuyang >Assignee: Steve Rowe >Priority: Minor > > The exception as follows: > Caused by: org.apache.solr.common.SolrException: Could not load conf for core > test_shard1_replica1: Can't load schema managed-schema: Plugin init failure > for [schema.xml] fieldType "preanalyzed": Cannot load analyzer: > org.apache.solr.schema.PreAnalyzedField$PreAnalyzedAnalyzer > at > org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:85) > at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1031) > ... 6 more > Caused by: org.apache.solr.common.SolrException: Can't load schema > managed-schema: Plugin init failure for [schema.xml] fieldType "preanalyzed": > Cannot load analyzer: > org.apache.solr.schema.PreAnalyzedField$PreAnalyzedAnalyzer > at org.apache.solr.schema.IndexSchema.readSchema(IndexSchema.java:600) > at org.apache.solr.schema.IndexSchema.(IndexSchema.java:183) > at > org.apache.solr.schema.ManagedIndexSchema.(ManagedIndexSchema.java:104) > at > org.apache.solr.schema.ManagedIndexSchemaFactory.create(ManagedIndexSchemaFactory.java:172) > at > org.apache.solr.schema.ManagedIndexSchemaFactory.create(ManagedIndexSchemaFactory.java:45) > at > org.apache.solr.schema.IndexSchemaFactory.buildIndexSchema(IndexSchemaFactory.java:75) > at > org.apache.solr.core.ConfigSetService.createIndexSchema(ConfigSetService.java:107) > at > org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:78) > ... 7 more > Test procedure: > 1.create collection using sample_techproducts_configs; > 2.add field in Solr web view; > 3.add field again in Solr web view. > manage-schema is modifyed as follows: > > > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-9752) Reliable test failure in TestFieldCacheSort (Solr copy)
[
https://issues.apache.org/jira/browse/SOLR-9752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15657484#comment-15657484
]
Yonik Seeley edited comment on SOLR-9752 at 11/11/16 4:44 PM:
--
Hopefully this is just a test bug and not a Lucene bug, but I don't see
anything wrong with the test on first glance.
The test itself also has nothing to do with the fieldCache - it's testing
sorting by score.
Maybe it's something to do with this?
{code}
sim=RandomSimilarity(queryNorm=false,coord=crazy):
{code}
Perhaps some sort of crazy scoring can lead the scores of the two matching
documents to be equal, and hence a sort by score won't yield the reverse order
of a sort by reverse score (that's what the test is testing).
So perhaps this is just a little bit too much random craziness in the test
framework that makes this particular test not always true.
was (Author: ysee...@gmail.com):
Hopefully this is just a test bug and not a Lucene bug, but I don't see
anything wrong with the test on first glance.
The test itself also has nothing to do with the fieldCache - it's testing
sorting by score.
Maybe it's something to do with this?
{code}
sim=RandomSimilarity(queryNorm=false,coord=crazy):
{code>
Perhaps some sort of crazy scoring can lead the scores of the two matching
documents to be equal, and hence a sort by score won't yield the reverse order
of a sort by reverse score (that's what the test is testing).
So perhaps this is just a little bit too much random craziness in the test
framework that makes this particular test not always true.
> Reliable test failure in TestFieldCacheSort (Solr copy)
> ---
>
> Key: SOLR-9752
> URL: https://issues.apache.org/jira/browse/SOLR-9752
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Environment: OS X, Sierra
>Reporter: Erick Erickson
>
> I found this to reliably fail on 6x, see the whole dump below. At
> least the 4 times I tried it. I hit this running the full test suite
> for SOLR-9166, but then reproduced it on a fresh 6x checkout.
> It did NOT repro on trunk the one time I tried it there.
> OS X, Sierra
> Here's the test that failed, I didn't try other variants.
> ant test -Dtestcase=TestFieldCacheSort
> -Dtests.method=testFieldScoreReverse -Dtests.seed=8A982858396AE681
> -Dtests.slow=true -Dtests.locale=es-VE -Dtests.timezone=Asia/Baku
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
> [junit4:pickseed] Seed property 'tests.seed' already defined: 8A982858396AE681
>[junit4] says ciao! Master seed: 8A982858396AE681
>[junit4] Executing 1 suite with 1 JVM.
>[junit4]
>[junit4] Started J0 PID(19306@Ericks-MacBook-Pro.local).
>[junit4] Suite: org.apache.solr.uninverting.TestFieldCacheSort
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=TestFieldCacheSort -Dtests.method=testFieldScoreReverse
> -Dtests.seed=8A982858396AE681 -Dtests.slow=true -Dtests.locale=es-VE
> -Dtests.timezone=Asia/Baku -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 3.18s | TestFieldCacheSort.testFieldScoreReverse <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<0>
> but was:<1>
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([8A982858396AE681:F15FD36FC8A76C02]:0)
>[junit4]> at
> org.apache.solr.uninverting.TestFieldCacheSort.testFieldScoreReverse(TestFieldCacheSort.java:445)
>[junit4]> at java.lang.Thread.run(Thread.java:745)
>[junit4] 2> NOTE: test params are: codec=Asserting(Lucene62):
> {value=FSTOrd50}, docValues:{}, maxPointsInLeafNode=1095,
> maxMBSortInHeap=5.032597879580006,
> sim=RandomSimilarity(queryNorm=false,coord=crazy):
> {value=org.apache.lucene.search.similarities.BooleanSimilarity@5077995e},
> locale=es-VE, timezone=Asia/Baku
>[junit4] 2> NOTE: Mac OS X 10.12 x86_64/Oracle Corporation
> 1.8.0_45 (64-bit)/cpus=8,threads=1,free=243860576,total=257425408
>[junit4] 2> NOTE: All tests run in this JVM: [TestFieldCacheSort]
>[junit4] Completed [1/1 (1!)] in 6.14s, 1 test, 1 failure <<< FAILURES!
>[junit4] Tests with failures [seed: 8A982858396AE681]:
>[junit4] -
> org.apache.solr.uninverting.TestFieldCacheSort.testFieldScoreReverse
>[junit4] JVM J0: 0.57 .. 8.10 = 7.53s
>[junit4] Execution time total: 8.10 sec.
>[junit4] Tests summary: 1 suite, 1 test, 1 failure
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9752) Reliable test failure in TestFieldCacheSort (Solr copy)
[
https://issues.apache.org/jira/browse/SOLR-9752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15657484#comment-15657484
]
Yonik Seeley commented on SOLR-9752:
Hopefully this is just a test bug and not a Lucene bug, but I don't see
anything wrong with the test on first glance.
The test itself also has nothing to do with the fieldCache - it's testing
sorting by score.
Maybe it's something to do with this?
{code}
sim=RandomSimilarity(queryNorm=false,coord=crazy):
{code>
Perhaps some sort of crazy scoring can lead the scores of the two matching
documents to be equal, and hence a sort by score won't yield the reverse order
of a sort by reverse score (that's what the test is testing).
So perhaps this is just a little bit too much random craziness in the test
framework that makes this particular test not always true.
> Reliable test failure in TestFieldCacheSort (Solr copy)
> ---
>
> Key: SOLR-9752
> URL: https://issues.apache.org/jira/browse/SOLR-9752
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Environment: OS X, Sierra
>Reporter: Erick Erickson
>
> I found this to reliably fail on 6x, see the whole dump below. At
> least the 4 times I tried it. I hit this running the full test suite
> for SOLR-9166, but then reproduced it on a fresh 6x checkout.
> It did NOT repro on trunk the one time I tried it there.
> OS X, Sierra
> Here's the test that failed, I didn't try other variants.
> ant test -Dtestcase=TestFieldCacheSort
> -Dtests.method=testFieldScoreReverse -Dtests.seed=8A982858396AE681
> -Dtests.slow=true -Dtests.locale=es-VE -Dtests.timezone=Asia/Baku
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
> [junit4:pickseed] Seed property 'tests.seed' already defined: 8A982858396AE681
>[junit4] says ciao! Master seed: 8A982858396AE681
>[junit4] Executing 1 suite with 1 JVM.
>[junit4]
>[junit4] Started J0 PID(19306@Ericks-MacBook-Pro.local).
>[junit4] Suite: org.apache.solr.uninverting.TestFieldCacheSort
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=TestFieldCacheSort -Dtests.method=testFieldScoreReverse
> -Dtests.seed=8A982858396AE681 -Dtests.slow=true -Dtests.locale=es-VE
> -Dtests.timezone=Asia/Baku -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 3.18s | TestFieldCacheSort.testFieldScoreReverse <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<0>
> but was:<1>
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([8A982858396AE681:F15FD36FC8A76C02]:0)
>[junit4]> at
> org.apache.solr.uninverting.TestFieldCacheSort.testFieldScoreReverse(TestFieldCacheSort.java:445)
>[junit4]> at java.lang.Thread.run(Thread.java:745)
>[junit4] 2> NOTE: test params are: codec=Asserting(Lucene62):
> {value=FSTOrd50}, docValues:{}, maxPointsInLeafNode=1095,
> maxMBSortInHeap=5.032597879580006,
> sim=RandomSimilarity(queryNorm=false,coord=crazy):
> {value=org.apache.lucene.search.similarities.BooleanSimilarity@5077995e},
> locale=es-VE, timezone=Asia/Baku
>[junit4] 2> NOTE: Mac OS X 10.12 x86_64/Oracle Corporation
> 1.8.0_45 (64-bit)/cpus=8,threads=1,free=243860576,total=257425408
>[junit4] 2> NOTE: All tests run in this JVM: [TestFieldCacheSort]
>[junit4] Completed [1/1 (1!)] in 6.14s, 1 test, 1 failure <<< FAILURES!
>[junit4] Tests with failures [seed: 8A982858396AE681]:
>[junit4] -
> org.apache.solr.uninverting.TestFieldCacheSort.testFieldScoreReverse
>[junit4] JVM J0: 0.57 .. 8.10 = 7.53s
>[junit4] Execution time total: 8.10 sec.
>[junit4] Tests summary: 1 suite, 1 test, 1 failure
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+140) - Build # 2155 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2155/ Java: 32bit/jdk-9-ea+140 -server -XX:+UseG1GC 1 tests failed. FAILED: org.apache.lucene.search.grouping.GroupingSearchTest.testBasic Error Message: expected:<[61 75 74 68 6f 72 33]> but was:<[61 75 74 68 6f 72 31]> Stack Trace: java.lang.AssertionError: expected:<[61 75 74 68 6f 72 33]> but was:<[61 75 74 68 6f 72 31]> at __randomizedtesting.SeedInfo.seed([74AE3383447106F1:DF542E969BAD80DF]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:147) at org.apache.lucene.search.grouping.GroupingSearchTest.compareGroupValue(GroupingSearchTest.java:192) at org.apache.lucene.search.grouping.GroupingSearchTest.testBasic(GroupingSearchTest.java:134) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(java.base@9-ea/Thread.java:843) Build Log: [...truncated 6863 lines...] [junit4] Suite: org.apache.lucene.search.grouping.GroupingSearchTest [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=GroupingSearchTest -Dtests.method=testBasic -Dtests.seed=74AE3383447106F1
[jira] [Commented] (SOLR-9754) No shell specified in the su call
[
https://issues.apache.org/jira/browse/SOLR-9754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15657395#comment-15657395
]
Shawn Heisey commented on SOLR-9754:
The service install script creates the solr user with the system standard
shell, not /bin/false. I think it also creates that user such that it would be
unable to log in (on Linux, the user gets an asterisk in the password field,
not an empty value or a valid hash), regardless of the shell assigned.
The shebang in bin/solr is "/usr/bin/env bash" ... not "/bin/sh" ... so if we
were to implement your idea, I think we should use the same value that the
bin/solr script does. Although it's highly unlikely that /bin/sh will be
absent, using that value does represent another potential dependency that
running directly with bin/solr does not impose.
> No shell specified in the su call
> -
>
> Key: SOLR-9754
> URL: https://issues.apache.org/jira/browse/SOLR-9754
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 5.5.3
> Environment: Ubuntu Linux 16.04 LTS
>Reporter: Anton Boritskiy
>
> The tarball version downloaded from
> [here|http://www.apache.org/dyn/closer.lua/lucene/solr/5.5.3]
> has problem inside the {{bin/init.d/solr}} file.
> the very last lines of the file look like
> {code}
> ...
> if [ -n "$RUNAS" ]; then
> su -c "SOLR_INCLUDE=\"$SOLR_ENV\" \"$SOLR_INSTALL_DIR/bin/solr\" $SOLR_CMD"
> - "$RUNAS"
> else
> SOLR_INCLUDE="$SOLR_ENV" "$SOLR_INSTALL_DIR/bin/solr" "$SOLR_CMD"
> fi
> {code}
> the solr sturt up just breaks when {{solr}} user has {{/bin/false}} shell
> assigned to it.
> Suggested change is to make that file look like
> {code}
> ...
> if [ -n "$RUNAS" ]; then
> su -s "/bin/sh" -c "SOLR_INCLUDE=\"$SOLR_ENV\"
> \"$SOLR_INSTALL_DIR/bin/solr\" $SOLR_CMD" - "$RUNAS"
> else
> SOLR_INCLUDE="$SOLR_ENV" "$SOLR_INSTALL_DIR/bin/solr" "$SOLR_CMD"
> fi
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1150 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1150/ 8 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.ConcurrentDeleteAndCreateCollectionTest Error Message: ObjectTracker found 10 object(s) that were not released!!! [InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient] org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:43) at org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:267) at org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:214) at org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:201) at org.apache.solr.client.solrj.impl.HttpSolrClient.(HttpSolrClient.java:210) at org.apache.solr.client.solrj.impl.HttpSolrClient.(HttpSolrClient.java:183) at org.apache.solr.client.solrj.impl.HttpSolrClient.(HttpSolrClient.java:167) at org.apache.solr.SolrTestCaseJ4.getHttpSolrClient(SolrTestCaseJ4.java:2250) at org.apache.solr.cloud.ConcurrentDeleteAndCreateCollectionTest.testConcurrentCreateAndDeleteDoesNotFail(ConcurrentDeleteAndCreateCollectionTest.java:62) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at
[jira] [Assigned] (SOLR-9751) PreanalyzedField can cause schema corruption
[ https://issues.apache.org/jira/browse/SOLR-9751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Rowe reassigned SOLR-9751: Assignee: Steve Rowe > PreanalyzedField can cause schema corruption > > > Key: SOLR-9751 > URL: https://issues.apache.org/jira/browse/SOLR-9751 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Schema and Analysis >Affects Versions: 6.2 >Reporter: liuyang >Assignee: Steve Rowe >Priority: Minor > > The exception as follows: > Caused by: org.apache.solr.common.SolrException: Could not load conf for core > test_shard1_replica1: Can't load schema managed-schema: Plugin init failure > for [schema.xml] fieldType "preanalyzed": Cannot load analyzer: > org.apache.solr.schema.PreAnalyzedField$PreAnalyzedAnalyzer > at > org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:85) > at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1031) > ... 6 more > Caused by: org.apache.solr.common.SolrException: Can't load schema > managed-schema: Plugin init failure for [schema.xml] fieldType "preanalyzed": > Cannot load analyzer: > org.apache.solr.schema.PreAnalyzedField$PreAnalyzedAnalyzer > at org.apache.solr.schema.IndexSchema.readSchema(IndexSchema.java:600) > at org.apache.solr.schema.IndexSchema.(IndexSchema.java:183) > at > org.apache.solr.schema.ManagedIndexSchema.(ManagedIndexSchema.java:104) > at > org.apache.solr.schema.ManagedIndexSchemaFactory.create(ManagedIndexSchemaFactory.java:172) > at > org.apache.solr.schema.ManagedIndexSchemaFactory.create(ManagedIndexSchemaFactory.java:45) > at > org.apache.solr.schema.IndexSchemaFactory.buildIndexSchema(IndexSchemaFactory.java:75) > at > org.apache.solr.core.ConfigSetService.createIndexSchema(ConfigSetService.java:107) > at > org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:78) > ... 7 more > Test procedure: > 1.create collection using sample_techproducts_configs; > 2.add field in Solr web view; > 3.add field again in Solr web view. > manage-schema is modifyed as follows: > > > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-6.x-Linux (64bit/jdk-9-ea+140) - Build # 2154 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2154/ Java: 64bit/jdk-9-ea+140 -XX:+UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.handler.component.SpellCheckComponentTest.test Error Message: List size mismatch @ spellcheck/suggestions Stack Trace: java.lang.RuntimeException: List size mismatch @ spellcheck/suggestions at __randomizedtesting.SeedInfo.seed([5A516F9320DA1636:D20550498E267BCE]:0) at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:900) at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:847) at org.apache.solr.handler.component.SpellCheckComponentTest.test(SpellCheckComponentTest.java:147) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(java.base@9-ea/Thread.java:843) Build Log: [...truncated 11617 lines...] [junit4] Suite:
[jira] [Closed] (SOLR-9747) Issue when upgrade Apache Solr from version 5.4.1 to 5.5.0 the parse serialization is not working from SolrDocument class to json
[ https://issues.apache.org/jira/browse/SOLR-9747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan José closed SOLR-9747. --- Resolution: Works for Me >From version 2.7.3 of com.fasterxml.jackson.core:jackson-databind is >controlled this bug at class com.fasterxml.jackson.databind.type.TypeFactory >checking if exist a supertype with the same type that current field. > Issue when upgrade Apache Solr from version 5.4.1 to 5.5.0 the parse > serialization is not working from SolrDocument class to json > - > > Key: SOLR-9747 > URL: https://issues.apache.org/jira/browse/SOLR-9747 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: search >Affects Versions: 5.5, 6.3 >Reporter: Juan José > Attachments: issue-solr-code > > > When upgrade Apache Solr from version 5.4.1 to 5.5.0, the parse serialization > is not working from SolrDocument class to json. > we use library com.fasterxml.jackson.core:jackson-databind:2.5.4 for json > parsing. We are getting this exception: > org.springframework.web.util.NestedServletException: Handler processing > failed; nested exception is java.lang.StackOverflowError > > org.springframework.web.servlet.DispatcherServlet.triggerAfterCompletionWithError(DispatcherServlet.java:1302) > > org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:977) > > org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:893) > > org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:969) > > org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:871) > javax.servlet.http.HttpServlet.service(HttpServlet.java:647) > > org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:845) > javax.servlet.http.HttpServlet.service(HttpServlet.java:728) > org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51) >causa raíz > java.lang.StackOverflowError > > com.fasterxml.jackson.databind.type.HierarchicType.getRawClass(HierarchicType.java:74) > > com.fasterxml.jackson.databind.type.TypeFactory._doFindSuperInterfaceChain(TypeFactory.java:1009) > > com.fasterxml.jackson.databind.type.TypeFactory._findSuperInterfaceChain(TypeFactory.java:1004) > > com.fasterxml.jackson.databind.type.TypeFactory._findSuperTypeChain(TypeFactory.java:958) > > com.fasterxml.jackson.databind.type.TypeFactory.findTypeParameters(TypeFactory.java:285) > > com.fasterxml.jackson.databind.type.TypeFactory.findTypeParameters(TypeFactory.java:279) > > com.fasterxml.jackson.databind.type.TypeFactory._mapType(TypeFactory.java:891) > > com.fasterxml.jackson.databind.type.TypeFactory._fromClass(TypeFactory.java:732) > > com.fasterxml.jackson.databind.type.TypeFactory._constructType(TypeFactory.java:387) > > com.fasterxml.jackson.databind.type.TypeFactory.findTypeParameters(TypeFactory.java:303) > > com.fasterxml.jackson.databind.type.TypeFactory.findTypeParameters(TypeFactory.java:279) > > com.fasterxml.jackson.databind.type.TypeFactory._mapType(TypeFactory.java:891) > > com.fasterxml.jackson.databind.type.TypeFactory._fromClass(TypeFactory.java:732) > > com.fasterxml.jackson.databind.type.TypeFactory._constructType(TypeFactory.java:387) > > com.fasterxml.jackson.databind.type.TypeFactory.findTypeParameters(TypeFactory.java:303) > > com.fasterxml.jackson.databind.type.TypeFactory.findTypeParameters(TypeFactory.java:279) > > com.fasterxml.jackson.databind.type.TypeFactory._mapType(TypeFactory.java:891) > > com.fasterxml.jackson.databind.type.TypeFactory._fromClass(TypeFactory.java:732) > > com.fasterxml.jackson.databind.type.TypeFactory._constructType(TypeFactory.java:387) > > com.fasterxml.jackson.databind.type.TypeFactory.findTypeParameters(TypeFactory.java:303) > > com.fasterxml.jackson.databind.type.TypeFactory.findTypeParameters(TypeFactory.java:279) > > com.fasterxml.jackson.databind.type.TypeFactory._mapType(TypeFactory.java:891) > > com.fasterxml.jackson.databind.type.TypeFactory._fromClass(TypeFactory.java:732) > > com.fasterxml.jackson.databind.type.TypeFactory._constructType(TypeFactory.java:387) > > com.fasterxml.jackson.databind.type.TypeFactory.findTypeParameters(TypeFactory.java:303) > > com.fasterxml.jackson.databind.type.TypeFactory.findTypeParameters(TypeFactory.java:279) > > com.fasterxml.jackson.databind.type.TypeFactory._mapType(TypeFactory.java:891) > >
[jira] [Created] (SOLR-9754) No shell specified in the su call
Anton Boritskiy created SOLR-9754:
-
Summary: No shell specified in the su call
Key: SOLR-9754
URL: https://issues.apache.org/jira/browse/SOLR-9754
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 5.5.3
Environment: Ubuntu Linux 16.04 LTS
Reporter: Anton Boritskiy
The tarball version downloaded from
[here|http://www.apache.org/dyn/closer.lua/lucene/solr/5.5.3]
has problem inside the {{bin/init.d/solr}} file.
the very last lines of the file look like
{code}
...
if [ -n "$RUNAS" ]; then
su -c "SOLR_INCLUDE=\"$SOLR_ENV\" \"$SOLR_INSTALL_DIR/bin/solr\" $SOLR_CMD" -
"$RUNAS"
else
SOLR_INCLUDE="$SOLR_ENV" "$SOLR_INSTALL_DIR/bin/solr" "$SOLR_CMD"
fi
{code}
the solr sturt up just breaks when {{solr}} user has {{/bin/false}} shell
assigned to it.
Suggested change is to make that file look like
{code}
...
if [ -n "$RUNAS" ]; then
su -s "/bin/sh" -c "SOLR_INCLUDE=\"$SOLR_ENV\" \"$SOLR_INSTALL_DIR/bin/solr\"
$SOLR_CMD" - "$RUNAS"
else
SOLR_INCLUDE="$SOLR_ENV" "$SOLR_INSTALL_DIR/bin/solr" "$SOLR_CMD"
fi
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8339) SolrDocument and SolrInputDocument should have a common interface
[ https://issues.apache.org/jira/browse/SOLR-8339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15656886#comment-15656886 ] Juan José commented on SOLR-8339: - This issue is controlled from version 2.7.3 of com.fasterxml.jackson.core:jackson-databind > SolrDocument and SolrInputDocument should have a common interface > - > > Key: SOLR-8339 > URL: https://issues.apache.org/jira/browse/SOLR-8339 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Assignee: Shalin Shekhar Mangar > Fix For: 5.5, 6.0 > > Attachments: SOLR-8339.patch, SOLR-8339.patch, SOLR-8339.patch, > SOLR-8339.patch > > > Currently, both share a Map interface (SOLR-928). However, there are many > common methods like createField(), setField() etc. that should perhaps go > into an interface/abstract class. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7537) Add multi valued field support to index sorting
[ https://issues.apache.org/jira/browse/LUCENE-7537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15656881#comment-15656881 ] Michael McCandless commented on LUCENE-7537: Thank [~jim.ferenczi], I'll have a look. > Add multi valued field support to index sorting > --- > > Key: LUCENE-7537 > URL: https://issues.apache.org/jira/browse/LUCENE-7537 > Project: Lucene - Core > Issue Type: Improvement > Components: core/index >Reporter: Ferenczi Jim > Attachments: LUCENE-7537.patch, LUCENE-7537.patch > > > Today index sorting can be done on single valued field through the > NumericDocValues (for numerics) and SortedDocValues (for strings). > I'd like to add the ability to sort on multi valued fields. Since index > sorting does not accept custom comparator we could just take the minimum > value of each document for an ascending sort and the maximum value for a > descending sort. > This way we could handle all cases instead of throwing an exception during a > merge when we encounter a multi valued DVs. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-master - Build # 1472 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1472/ 1 tests failed. FAILED: org.apache.solr.cloud.HttpPartitionTest.test Error Message: Captured an uncaught exception in thread: Thread[id=7969, name=SocketProxy-Response-54015:58790, state=RUNNABLE, group=TGRP-HttpPartitionTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=7969, name=SocketProxy-Response-54015:58790, state=RUNNABLE, group=TGRP-HttpPartitionTest] at __randomizedtesting.SeedInfo.seed([5891F4C02DB09ABA:D0C5CB1A834CF742]:0) Caused by: java.lang.RuntimeException: java.net.SocketException: Socket is closed at __randomizedtesting.SeedInfo.seed([5891F4C02DB09ABA]:0) at org.apache.solr.cloud.SocketProxy$Bridge$Pump.run(SocketProxy.java:347) Caused by: java.net.SocketException: Socket is closed at java.net.Socket.setSoTimeout(Socket.java:1137) at org.apache.solr.cloud.SocketProxy$Bridge$Pump.run(SocketProxy.java:344) Build Log: [...truncated 11562 lines...] [junit4] Suite: org.apache.solr.cloud.HttpPartitionTest [junit4] 2> Creating dataDir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/build/solr-core/test/J2/temp/solr.cloud.HttpPartitionTest_5891F4C02DB09ABA-001/init-core-data-001 [junit4] 2> 750895 INFO (SUITE-HttpPartitionTest-seed#[5891F4C02DB09ABA]-worker) [] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: @org.apache.solr.SolrTestCaseJ4$SuppressSSL(bugUrl=https://issues.apache.org/jira/browse/SOLR-5776) [junit4] 2> 750895 INFO (SUITE-HttpPartitionTest-seed#[5891F4C02DB09ABA]-worker) [] o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: / [junit4] 2> 750933 INFO (TEST-HttpPartitionTest.test-seed#[5891F4C02DB09ABA]) [] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER [junit4] 2> 750933 INFO (Thread-2848) [] o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0 [junit4] 2> 750933 INFO (Thread-2848) [] o.a.s.c.ZkTestServer Starting server [junit4] 2> 751033 INFO (TEST-HttpPartitionTest.test-seed#[5891F4C02DB09ABA]) [] o.a.s.c.ZkTestServer start zk server on port:53048 [junit4] 2> 751072 INFO (TEST-HttpPartitionTest.test-seed#[5891F4C02DB09ABA]) [] o.a.s.c.AbstractZkTestCase put /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/solrconfig-tlog.xml to /configs/conf1/solrconfig.xml [junit4] 2> 751074 INFO (TEST-HttpPartitionTest.test-seed#[5891F4C02DB09ABA]) [] o.a.s.c.AbstractZkTestCase put /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/schema.xml to /configs/conf1/schema.xml [junit4] 2> 751076 INFO (TEST-HttpPartitionTest.test-seed#[5891F4C02DB09ABA]) [] o.a.s.c.AbstractZkTestCase put /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/solrconfig.snippet.randomindexconfig.xml to /configs/conf1/solrconfig.snippet.randomindexconfig.xml [junit4] 2> 751077 INFO (TEST-HttpPartitionTest.test-seed#[5891F4C02DB09ABA]) [] o.a.s.c.AbstractZkTestCase put /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/stopwords.txt to /configs/conf1/stopwords.txt [junit4] 2> 751078 INFO (TEST-HttpPartitionTest.test-seed#[5891F4C02DB09ABA]) [] o.a.s.c.AbstractZkTestCase put /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/protwords.txt to /configs/conf1/protwords.txt [junit4] 2> 751080 INFO (TEST-HttpPartitionTest.test-seed#[5891F4C02DB09ABA]) [] o.a.s.c.AbstractZkTestCase put /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/currency.xml to /configs/conf1/currency.xml [junit4] 2> 751081 INFO (TEST-HttpPartitionTest.test-seed#[5891F4C02DB09ABA]) [] o.a.s.c.AbstractZkTestCase put /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/enumsConfig.xml to /configs/conf1/enumsConfig.xml [junit4] 2> 751082 INFO (TEST-HttpPartitionTest.test-seed#[5891F4C02DB09ABA]) [] o.a.s.c.AbstractZkTestCase put /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/open-exchange-rates.json to /configs/conf1/open-exchange-rates.json [junit4] 2> 751084 INFO (TEST-HttpPartitionTest.test-seed#[5891F4C02DB09ABA]) [] o.a.s.c.AbstractZkTestCase put /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/mapping-ISOLatin1Accent.txt to /configs/conf1/mapping-ISOLatin1Accent.txt [junit4] 2> 751085 INFO (TEST-HttpPartitionTest.test-seed#[5891F4C02DB09ABA]) [] o.a.s.c.AbstractZkTestCase
