[jira] [Commented] (SOLR-6181) SliceStateUpdateTest.testSliceStateUpdate FAILS
[
https://issues.apache.org/jira/browse/SOLR-6181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14046777#comment-14046777
]
Shalin Shekhar Mangar commented on SOLR-6181:
-
Those cancelElection calls aren't really necessary in this test. We can remove
those to fix the exceptions from the test. But I think we should just nuke this
test -- it really doesn't give us much. It was useful when slice states were
added to ClusterState but now that shard split and migrate tests exist, this
SliceStateUpdateTest is redundant.
SliceStateUpdateTest.testSliceStateUpdate FAILS
---
Key: SOLR-6181
URL: https://issues.apache.org/jira/browse/SOLR-6181
Project: Solr
Issue Type: Bug
Components: SolrCloud
Reporter: Noble Paul
Assignee: Noble Paul
Sample failure
http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/1658/testReport/org.apache.solr.cloud/SliceStateUpdateTest/testSliceStateUpdate/
{noformat}
Error Message:
Path cannot be null
Stack Trace:
java.lang.IllegalArgumentException: Path cannot be null
at
__randomizedtesting.SeedInfo.seed([DCDA3A02C8236D70:CB8B74E96F6B7F4]:0)
at
org.apache.zookeeper.common.PathUtils.validatePath(PathUtils.java:45)
at org.apache.zookeeper.ZooKeeper.delete(ZooKeeper.java:851)
at
org.apache.solr.common.cloud.SolrZkClient$2.execute(SolrZkClient.java:177)
at
org.apache.solr.common.cloud.SolrZkClient$2.execute(SolrZkClient.java:174)
at
org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:73)
at
org.apache.solr.common.cloud.SolrZkClient.delete(SolrZkClient.java:174)
at
org.apache.solr.cloud.ElectionContext.cancelElection(ElectionContext.java:71)
at
org.apache.solr.cloud.OverseerElectionContext.cancelElection(ElectionContext.java:533)
at
org.apache.solr.cloud.SliceStateUpdateTest.testSliceStateUpdate(SliceStateUpdateTest.java:184)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:360)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:793)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:453)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
[jira] [Commented] (SOLR-6181) SliceStateUpdateTest.testSliceStateUpdate FAILS
[
https://issues.apache.org/jira/browse/SOLR-6181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14046778#comment-14046778
]
Shalin Shekhar Mangar commented on SOLR-6181:
-
Looks like Mark made the same observation:
https://issues.apache.org/jira/browse/SOLR-5369?focusedCommentId=13828401page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13828401
This test doesn't give us any new coverage. I'll remove this test now.
SliceStateUpdateTest.testSliceStateUpdate FAILS
---
Key: SOLR-6181
URL: https://issues.apache.org/jira/browse/SOLR-6181
Project: Solr
Issue Type: Bug
Components: SolrCloud
Reporter: Noble Paul
Assignee: Noble Paul
Sample failure
http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/1658/testReport/org.apache.solr.cloud/SliceStateUpdateTest/testSliceStateUpdate/
{noformat}
Error Message:
Path cannot be null
Stack Trace:
java.lang.IllegalArgumentException: Path cannot be null
at
__randomizedtesting.SeedInfo.seed([DCDA3A02C8236D70:CB8B74E96F6B7F4]:0)
at
org.apache.zookeeper.common.PathUtils.validatePath(PathUtils.java:45)
at org.apache.zookeeper.ZooKeeper.delete(ZooKeeper.java:851)
at
org.apache.solr.common.cloud.SolrZkClient$2.execute(SolrZkClient.java:177)
at
org.apache.solr.common.cloud.SolrZkClient$2.execute(SolrZkClient.java:174)
at
org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:73)
at
org.apache.solr.common.cloud.SolrZkClient.delete(SolrZkClient.java:174)
at
org.apache.solr.cloud.ElectionContext.cancelElection(ElectionContext.java:71)
at
org.apache.solr.cloud.OverseerElectionContext.cancelElection(ElectionContext.java:533)
at
org.apache.solr.cloud.SliceStateUpdateTest.testSliceStateUpdate(SliceStateUpdateTest.java:184)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:360)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:793)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:453)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at
[jira] [Commented] (SOLR-6181) SliceStateUpdateTest.testSliceStateUpdate FAILS
[
https://issues.apache.org/jira/browse/SOLR-6181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14046779#comment-14046779
]
ASF subversion and git services commented on SOLR-6181:
---
Commit 1606299 from sha...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1606299 ]
SOLR-6181: Deleting SliceStateUpdateTest since it has become redundant with
ShardSplitTest and MigrateRouteKeyTest coming in.
SliceStateUpdateTest.testSliceStateUpdate FAILS
---
Key: SOLR-6181
URL: https://issues.apache.org/jira/browse/SOLR-6181
Project: Solr
Issue Type: Bug
Components: SolrCloud
Reporter: Noble Paul
Assignee: Noble Paul
Sample failure
http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/1658/testReport/org.apache.solr.cloud/SliceStateUpdateTest/testSliceStateUpdate/
{noformat}
Error Message:
Path cannot be null
Stack Trace:
java.lang.IllegalArgumentException: Path cannot be null
at
__randomizedtesting.SeedInfo.seed([DCDA3A02C8236D70:CB8B74E96F6B7F4]:0)
at
org.apache.zookeeper.common.PathUtils.validatePath(PathUtils.java:45)
at org.apache.zookeeper.ZooKeeper.delete(ZooKeeper.java:851)
at
org.apache.solr.common.cloud.SolrZkClient$2.execute(SolrZkClient.java:177)
at
org.apache.solr.common.cloud.SolrZkClient$2.execute(SolrZkClient.java:174)
at
org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:73)
at
org.apache.solr.common.cloud.SolrZkClient.delete(SolrZkClient.java:174)
at
org.apache.solr.cloud.ElectionContext.cancelElection(ElectionContext.java:71)
at
org.apache.solr.cloud.OverseerElectionContext.cancelElection(ElectionContext.java:533)
at
org.apache.solr.cloud.SliceStateUpdateTest.testSliceStateUpdate(SliceStateUpdateTest.java:184)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:360)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:793)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:453)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at
[jira] [Commented] (SOLR-6181) SliceStateUpdateTest.testSliceStateUpdate FAILS
[
https://issues.apache.org/jira/browse/SOLR-6181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14046780#comment-14046780
]
ASF subversion and git services commented on SOLR-6181:
---
Commit 1606300 from sha...@apache.org in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1606300 ]
SOLR-6181: Deleting SliceStateUpdateTest since it has become redundant with
ShardSplitTest and MigrateRouteKeyTest coming in.
SliceStateUpdateTest.testSliceStateUpdate FAILS
---
Key: SOLR-6181
URL: https://issues.apache.org/jira/browse/SOLR-6181
Project: Solr
Issue Type: Bug
Components: SolrCloud
Reporter: Noble Paul
Assignee: Noble Paul
Fix For: 4.10
Sample failure
http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/1658/testReport/org.apache.solr.cloud/SliceStateUpdateTest/testSliceStateUpdate/
{noformat}
Error Message:
Path cannot be null
Stack Trace:
java.lang.IllegalArgumentException: Path cannot be null
at
__randomizedtesting.SeedInfo.seed([DCDA3A02C8236D70:CB8B74E96F6B7F4]:0)
at
org.apache.zookeeper.common.PathUtils.validatePath(PathUtils.java:45)
at org.apache.zookeeper.ZooKeeper.delete(ZooKeeper.java:851)
at
org.apache.solr.common.cloud.SolrZkClient$2.execute(SolrZkClient.java:177)
at
org.apache.solr.common.cloud.SolrZkClient$2.execute(SolrZkClient.java:174)
at
org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:73)
at
org.apache.solr.common.cloud.SolrZkClient.delete(SolrZkClient.java:174)
at
org.apache.solr.cloud.ElectionContext.cancelElection(ElectionContext.java:71)
at
org.apache.solr.cloud.OverseerElectionContext.cancelElection(ElectionContext.java:533)
at
org.apache.solr.cloud.SliceStateUpdateTest.testSliceStateUpdate(SliceStateUpdateTest.java:184)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:360)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:793)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:453)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at
[jira] [Resolved] (SOLR-6181) SliceStateUpdateTest.testSliceStateUpdate FAILS
[
https://issues.apache.org/jira/browse/SOLR-6181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar resolved SOLR-6181.
-
Resolution: Not a Problem
Fix Version/s: 4.10
I have removed this test completely.
SliceStateUpdateTest.testSliceStateUpdate FAILS
---
Key: SOLR-6181
URL: https://issues.apache.org/jira/browse/SOLR-6181
Project: Solr
Issue Type: Bug
Components: SolrCloud
Reporter: Noble Paul
Assignee: Noble Paul
Fix For: 4.10
Sample failure
http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/1658/testReport/org.apache.solr.cloud/SliceStateUpdateTest/testSliceStateUpdate/
{noformat}
Error Message:
Path cannot be null
Stack Trace:
java.lang.IllegalArgumentException: Path cannot be null
at
__randomizedtesting.SeedInfo.seed([DCDA3A02C8236D70:CB8B74E96F6B7F4]:0)
at
org.apache.zookeeper.common.PathUtils.validatePath(PathUtils.java:45)
at org.apache.zookeeper.ZooKeeper.delete(ZooKeeper.java:851)
at
org.apache.solr.common.cloud.SolrZkClient$2.execute(SolrZkClient.java:177)
at
org.apache.solr.common.cloud.SolrZkClient$2.execute(SolrZkClient.java:174)
at
org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:73)
at
org.apache.solr.common.cloud.SolrZkClient.delete(SolrZkClient.java:174)
at
org.apache.solr.cloud.ElectionContext.cancelElection(ElectionContext.java:71)
at
org.apache.solr.cloud.OverseerElectionContext.cancelElection(ElectionContext.java:533)
at
org.apache.solr.cloud.SliceStateUpdateTest.testSliceStateUpdate(SliceStateUpdateTest.java:184)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:360)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:793)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:453)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
[jira] [Updated] (LUCENE-5791) QueryParserUtil, big query with wildcards - runs endlessly and produces heavy load
[
https://issues.apache.org/jira/browse/LUCENE-5791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-5791:
---
Attachment: afterdet.png
abc*mno*xyz*pqr*def determinized
QueryParserUtil, big query with wildcards - runs endlessly and produces
heavy load
---
Key: LUCENE-5791
URL: https://issues.apache.org/jira/browse/LUCENE-5791
Project: Lucene - Core
Issue Type: Bug
Components: modules/queryparser
Environment: Lucene 4.7.2
Java 6
Reporter: Clemens Wyss
Attachments: afterdet.png
The following testcase runs endlessly and produces VERY heavy load.
...
String query = Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed
diam nonumy eirmod tempor invidunt ut
+ labore et dolore magna aliquyam erat, sed
diam voluptua. At vero eos et accusam et justo duo dolores et
+ ea rebum. Stet clita kasd gubergren, no sea
takimata sanctus est Lorem ipsum dolor sit amet.
+ Lorem ipsum dolor sit amet, consetetur
sadipscing elitr, sed diam nonumy eirmod tempor invidunt
+ ut labore et dolore magna aliquyam erat, sed
diam voluptua. At vero eos et accusam et justo duo dolores
+ et ea rebum. Stet clita kasd gubergren, no
sea takimata sanctus est Lorem ipsum dolor sit amet; String query =
query.replaceAll( \\s+, * ); try { QueryParserUtil.parse( query, new
String[] { test }, new Occur[] { Occur.MUST }, new KeywordAnalyzer() ); }
catch ( Exception e ) { Assert.fail( e.getMessage() ); } ...
I don't say this testcase makes sense, nevertheless the question remains
whether this is a bug or a feature?
99% the threaddump/stacktrace looks as follows:
BasicOperations.determinize(Automaton) line: 680
Automaton.determinize() line: 759
SpecialOperations.getCommonSuffixBytesRef(Automaton) line: 165
CompiledAutomaton.init(Automaton, Boolean, boolean) line: 168
CompiledAutomaton.init(Automaton) line: 91
WildcardQuery(AutomatonQuery).init(Term, Automaton) line: 67
WildcardQuery.init(Term) line: 57
WildcardQueryNodeBuilder.build(QueryNode) line: 42
WildcardQueryNodeBuilder.build(QueryNode) line: 32
StandardQueryTreeBuilder(QueryTreeBuilder).processNode(QueryNode,
QueryBuilder) line: 186
StandardQueryTreeBuilder(QueryTreeBuilder).process(QueryNode) line: 125
StandardQueryTreeBuilder(QueryTreeBuilder).build(QueryNode) line: 218
StandardQueryTreeBuilder.build(QueryNode) line: 82
StandardQueryTreeBuilder.build(QueryNode) line: 53
StandardQueryParser(QueryParserHelper).parse(String, String) line: 258
StandardQueryParser.parse(String, String) line: 168
QueryParserUtil.parse(String, String[], BooleanClause$Occur[], Analyzer)
line: 119
IndexingTest.queryParserUtilLimit() line: 1450
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5791) QueryParserUtil, big query with wildcards - runs endlessly and produces heavy load
[
https://issues.apache.org/jira/browse/LUCENE-5791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14046806#comment-14046806
]
Michael McCandless commented on LUCENE-5791:
Ahh so this is indeed because of the determinize in Automaton. Unfortunately,
determinize has worst-case exponential complexity, and I think this example in
fact hits the worst case. I'm attaching the determinized automaton for
abc*mno*xyz*pqr*def ... you can see it gets larger and larger as you add parts
between the *
QueryParserUtil, big query with wildcards - runs endlessly and produces
heavy load
---
Key: LUCENE-5791
URL: https://issues.apache.org/jira/browse/LUCENE-5791
Project: Lucene - Core
Issue Type: Bug
Components: modules/queryparser
Environment: Lucene 4.7.2
Java 6
Reporter: Clemens Wyss
Attachments: afterdet.png
The following testcase runs endlessly and produces VERY heavy load.
...
String query = Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed
diam nonumy eirmod tempor invidunt ut
+ labore et dolore magna aliquyam erat, sed
diam voluptua. At vero eos et accusam et justo duo dolores et
+ ea rebum. Stet clita kasd gubergren, no sea
takimata sanctus est Lorem ipsum dolor sit amet.
+ Lorem ipsum dolor sit amet, consetetur
sadipscing elitr, sed diam nonumy eirmod tempor invidunt
+ ut labore et dolore magna aliquyam erat, sed
diam voluptua. At vero eos et accusam et justo duo dolores
+ et ea rebum. Stet clita kasd gubergren, no
sea takimata sanctus est Lorem ipsum dolor sit amet; String query =
query.replaceAll( \\s+, * ); try { QueryParserUtil.parse( query, new
String[] { test }, new Occur[] { Occur.MUST }, new KeywordAnalyzer() ); }
catch ( Exception e ) { Assert.fail( e.getMessage() ); } ...
I don't say this testcase makes sense, nevertheless the question remains
whether this is a bug or a feature?
99% the threaddump/stacktrace looks as follows:
BasicOperations.determinize(Automaton) line: 680
Automaton.determinize() line: 759
SpecialOperations.getCommonSuffixBytesRef(Automaton) line: 165
CompiledAutomaton.init(Automaton, Boolean, boolean) line: 168
CompiledAutomaton.init(Automaton) line: 91
WildcardQuery(AutomatonQuery).init(Term, Automaton) line: 67
WildcardQuery.init(Term) line: 57
WildcardQueryNodeBuilder.build(QueryNode) line: 42
WildcardQueryNodeBuilder.build(QueryNode) line: 32
StandardQueryTreeBuilder(QueryTreeBuilder).processNode(QueryNode,
QueryBuilder) line: 186
StandardQueryTreeBuilder(QueryTreeBuilder).process(QueryNode) line: 125
StandardQueryTreeBuilder(QueryTreeBuilder).build(QueryNode) line: 218
StandardQueryTreeBuilder.build(QueryNode) line: 82
StandardQueryTreeBuilder.build(QueryNode) line: 53
StandardQueryParser(QueryParserHelper).parse(String, String) line: 258
StandardQueryParser.parse(String, String) line: 168
QueryParserUtil.parse(String, String[], BooleanClause$Occur[], Analyzer)
line: 119
IndexingTest.queryParserUtilLimit() line: 1450
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5791) QueryParserUtil, big query with wildcards - runs endlessly and produces heavy load
[
https://issues.apache.org/jira/browse/LUCENE-5791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14046813#comment-14046813
]
Jack Krupansky commented on LUCENE-5791:
At least consider clear Javadoc on limitations and performance, such as the
need to keep wildcard patterns brief.
Maybe consider a limit of how many wildcards can be used in a single wildcard
query. Possibly configurable.
Maybe consider a trim mode - if too many wildcards appear, simply trim
trailing portions of the pattern to get under the limit. For example, this test
case might get trimmed to abc*mno*xyz*. This would still match all of the
intended matches, albeit also matching some unintended cases. Maybe a limit of
three wildcards would be reasonable.
Does ? have the same issue, or is it much more linear? Would ???*???*???*??? be
as bad as abc*mno*xyz*pqr* ?
Do adjacent ** get collapsed to a single * ?
QueryParserUtil, big query with wildcards - runs endlessly and produces
heavy load
---
Key: LUCENE-5791
URL: https://issues.apache.org/jira/browse/LUCENE-5791
Project: Lucene - Core
Issue Type: Bug
Components: modules/queryparser
Environment: Lucene 4.7.2
Java 6
Reporter: Clemens Wyss
Attachments: afterdet.png
The following testcase runs endlessly and produces VERY heavy load.
...
String query = Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed
diam nonumy eirmod tempor invidunt ut
+ labore et dolore magna aliquyam erat, sed
diam voluptua. At vero eos et accusam et justo duo dolores et
+ ea rebum. Stet clita kasd gubergren, no sea
takimata sanctus est Lorem ipsum dolor sit amet.
+ Lorem ipsum dolor sit amet, consetetur
sadipscing elitr, sed diam nonumy eirmod tempor invidunt
+ ut labore et dolore magna aliquyam erat, sed
diam voluptua. At vero eos et accusam et justo duo dolores
+ et ea rebum. Stet clita kasd gubergren, no
sea takimata sanctus est Lorem ipsum dolor sit amet; String query =
query.replaceAll( \\s+, * ); try { QueryParserUtil.parse( query, new
String[] { test }, new Occur[] { Occur.MUST }, new KeywordAnalyzer() ); }
catch ( Exception e ) { Assert.fail( e.getMessage() ); } ...
I don't say this testcase makes sense, nevertheless the question remains
whether this is a bug or a feature?
99% the threaddump/stacktrace looks as follows:
BasicOperations.determinize(Automaton) line: 680
Automaton.determinize() line: 759
SpecialOperations.getCommonSuffixBytesRef(Automaton) line: 165
CompiledAutomaton.init(Automaton, Boolean, boolean) line: 168
CompiledAutomaton.init(Automaton) line: 91
WildcardQuery(AutomatonQuery).init(Term, Automaton) line: 67
WildcardQuery.init(Term) line: 57
WildcardQueryNodeBuilder.build(QueryNode) line: 42
WildcardQueryNodeBuilder.build(QueryNode) line: 32
StandardQueryTreeBuilder(QueryTreeBuilder).processNode(QueryNode,
QueryBuilder) line: 186
StandardQueryTreeBuilder(QueryTreeBuilder).process(QueryNode) line: 125
StandardQueryTreeBuilder(QueryTreeBuilder).build(QueryNode) line: 218
StandardQueryTreeBuilder.build(QueryNode) line: 82
StandardQueryTreeBuilder.build(QueryNode) line: 53
StandardQueryParser(QueryParserHelper).parse(String, String) line: 258
StandardQueryParser.parse(String, String) line: 168
QueryParserUtil.parse(String, String[], BooleanClause$Occur[], Analyzer)
line: 119
IndexingTest.queryParserUtilLimit() line: 1450
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-5791) QueryParserUtil, big query with wildcards - runs endlessly and produces heavy load
[
https://issues.apache.org/jira/browse/LUCENE-5791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14046813#comment-14046813
]
Jack Krupansky edited comment on LUCENE-5791 at 6/28/14 11:11 AM:
--
At least consider clear Javadoc on limitations and performance, such as the
need to keep wildcard patterns brief.
Maybe consider a limit of how many wildcards can be used in a single wildcard
query. Possibly configurable.
Maybe consider a trim mode - if too many wildcards appear, simply trim
trailing portions of the pattern to get under the limit. For example, this test
case might get trimmed to abc*mno*xyz*. This would still match all of the
intended matches, albeit also matching some unintended cases. Maybe a limit of
three wildcards would be reasonable.
Does ? have the same issue, or is it much more linear? Would ???*???*???*??? be
as bad as abc*mno*xyz*pqr* ?
Do adjacent ** get collapsed to a single * ?
Fuzzy query has a very strict limit to assure that it is performant - I would
think that these two query types should have the same performance goals.
was (Author: jkrupan):
At least consider clear Javadoc on limitations and performance, such as the
need to keep wildcard patterns brief.
Maybe consider a limit of how many wildcards can be used in a single wildcard
query. Possibly configurable.
Maybe consider a trim mode - if too many wildcards appear, simply trim
trailing portions of the pattern to get under the limit. For example, this test
case might get trimmed to abc*mno*xyz*. This would still match all of the
intended matches, albeit also matching some unintended cases. Maybe a limit of
three wildcards would be reasonable.
Does ? have the same issue, or is it much more linear? Would ???*???*???*??? be
as bad as abc*mno*xyz*pqr* ?
Do adjacent ** get collapsed to a single * ?
QueryParserUtil, big query with wildcards - runs endlessly and produces
heavy load
---
Key: LUCENE-5791
URL: https://issues.apache.org/jira/browse/LUCENE-5791
Project: Lucene - Core
Issue Type: Bug
Components: modules/queryparser
Environment: Lucene 4.7.2
Java 6
Reporter: Clemens Wyss
Attachments: afterdet.png
The following testcase runs endlessly and produces VERY heavy load.
...
String query = Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed
diam nonumy eirmod tempor invidunt ut
+ labore et dolore magna aliquyam erat, sed
diam voluptua. At vero eos et accusam et justo duo dolores et
+ ea rebum. Stet clita kasd gubergren, no sea
takimata sanctus est Lorem ipsum dolor sit amet.
+ Lorem ipsum dolor sit amet, consetetur
sadipscing elitr, sed diam nonumy eirmod tempor invidunt
+ ut labore et dolore magna aliquyam erat, sed
diam voluptua. At vero eos et accusam et justo duo dolores
+ et ea rebum. Stet clita kasd gubergren, no
sea takimata sanctus est Lorem ipsum dolor sit amet; String query =
query.replaceAll( \\s+, * ); try { QueryParserUtil.parse( query, new
String[] { test }, new Occur[] { Occur.MUST }, new KeywordAnalyzer() ); }
catch ( Exception e ) { Assert.fail( e.getMessage() ); } ...
I don't say this testcase makes sense, nevertheless the question remains
whether this is a bug or a feature?
99% the threaddump/stacktrace looks as follows:
BasicOperations.determinize(Automaton) line: 680
Automaton.determinize() line: 759
SpecialOperations.getCommonSuffixBytesRef(Automaton) line: 165
CompiledAutomaton.init(Automaton, Boolean, boolean) line: 168
CompiledAutomaton.init(Automaton) line: 91
WildcardQuery(AutomatonQuery).init(Term, Automaton) line: 67
WildcardQuery.init(Term) line: 57
WildcardQueryNodeBuilder.build(QueryNode) line: 42
WildcardQueryNodeBuilder.build(QueryNode) line: 32
StandardQueryTreeBuilder(QueryTreeBuilder).processNode(QueryNode,
QueryBuilder) line: 186
StandardQueryTreeBuilder(QueryTreeBuilder).process(QueryNode) line: 125
StandardQueryTreeBuilder(QueryTreeBuilder).build(QueryNode) line: 218
StandardQueryTreeBuilder.build(QueryNode) line: 82
StandardQueryTreeBuilder.build(QueryNode) line: 53
StandardQueryParser(QueryParserHelper).parse(String, String) line: 258
StandardQueryParser.parse(String, String) line: 168
QueryParserUtil.parse(String, String[], BooleanClause$Occur[], Analyzer)
line: 119
IndexingTest.queryParserUtilLimit() line: 1450
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail:
Re: [jira] [Comment Edited] (LUCENE-5791) QueryParserUtil, big query with wildcards - runs endlessly and produces heavy load
H. +1 to limiting this somehow. Whether it's configurable or not I
don't really care, I'd be perfectly fine with reducing it to some sane
(handleable) limit. I can argue that having a regex like this is
useless from a practical standpoint anyway. But a few of these could
make search responsive.
Supporting this kind of edge case doesn't seem worth the effort.
Clemens was very clear that this is a test case, the implication that
it's not the result of a required use-case. Not complaining at all,
mind you, it's great to have stuff like this flushed out.
FWIW
Erick
On Sat, Jun 28, 2014 at 4:13 AM, Jack Krupansky (JIRA) j...@apache.org wrote:
[
https://issues.apache.org/jira/browse/LUCENE-5791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14046813#comment-14046813
]
Jack Krupansky edited comment on LUCENE-5791 at 6/28/14 11:11 AM:
--
At least consider clear Javadoc on limitations and performance, such as the
need to keep wildcard patterns brief.
Maybe consider a limit of how many wildcards can be used in a single wildcard
query. Possibly configurable.
Maybe consider a trim mode - if too many wildcards appear, simply trim
trailing portions of the pattern to get under the limit. For example, this
test case might get trimmed to abc*mno*xyz*. This would still match all of
the intended matches, albeit also matching some unintended cases. Maybe a
limit of three wildcards would be reasonable.
Does ? have the same issue, or is it much more linear? Would ???*???*???*???
be as bad as abc*mno*xyz*pqr* ?
Do adjacent ** get collapsed to a single * ?
Fuzzy query has a very strict limit to assure that it is performant - I would
think that these two query types should have the same performance goals.
was (Author: jkrupan):
At least consider clear Javadoc on limitations and performance, such as the
need to keep wildcard patterns brief.
Maybe consider a limit of how many wildcards can be used in a single wildcard
query. Possibly configurable.
Maybe consider a trim mode - if too many wildcards appear, simply trim
trailing portions of the pattern to get under the limit. For example, this
test case might get trimmed to abc*mno*xyz*. This would still match all of
the intended matches, albeit also matching some unintended cases. Maybe a
limit of three wildcards would be reasonable.
Does ? have the same issue, or is it much more linear? Would ???*???*???*???
be as bad as abc*mno*xyz*pqr* ?
Do adjacent ** get collapsed to a single * ?
QueryParserUtil, big query with wildcards - runs endlessly and produces
heavy load
---
Key: LUCENE-5791
URL: https://issues.apache.org/jira/browse/LUCENE-5791
Project: Lucene - Core
Issue Type: Bug
Components: modules/queryparser
Environment: Lucene 4.7.2
Java 6
Reporter: Clemens Wyss
Attachments: afterdet.png
The following testcase runs endlessly and produces VERY heavy load.
...
String query = Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed
diam nonumy eirmod tempor invidunt ut
+ labore et dolore magna aliquyam erat, sed
diam voluptua. At vero eos et accusam et justo duo dolores et
+ ea rebum. Stet clita kasd gubergren, no sea
takimata sanctus est Lorem ipsum dolor sit amet.
+ Lorem ipsum dolor sit amet, consetetur
sadipscing elitr, sed diam nonumy eirmod tempor invidunt
+ ut labore et dolore magna aliquyam erat,
sed diam voluptua. At vero eos et accusam et justo duo dolores
+ et ea rebum. Stet clita kasd gubergren, no
sea takimata sanctus est Lorem ipsum dolor sit amet; String query =
query.replaceAll( \\s+, * ); try { QueryParserUtil.parse( query, new
String[] { test }, new Occur[] { Occur.MUST }, new KeywordAnalyzer() ); }
catch ( Exception e ) { Assert.fail( e.getMessage() ); } ...
I don't say this testcase makes sense, nevertheless the question remains
whether this is a bug or a feature?
99% the threaddump/stacktrace looks as follows:
BasicOperations.determinize(Automaton) line: 680
Automaton.determinize() line: 759
SpecialOperations.getCommonSuffixBytesRef(Automaton) line: 165
CompiledAutomaton.init(Automaton, Boolean, boolean) line: 168
CompiledAutomaton.init(Automaton) line: 91
WildcardQuery(AutomatonQuery).init(Term, Automaton) line: 67
WildcardQuery.init(Term) line: 57
WildcardQueryNodeBuilder.build(QueryNode) line: 42
WildcardQueryNodeBuilder.build(QueryNode) line: 32
StandardQueryTreeBuilder(QueryTreeBuilder).processNode(QueryNode,
QueryBuilder) line: 186
StandardQueryTreeBuilder(QueryTreeBuilder).process(QueryNode)
[jira] [Commented] (LUCENE-5786) Unflushed/ truncated events file (hung testing subprocess)
[
https://issues.apache.org/jira/browse/LUCENE-5786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14046959#comment-14046959
]
Dawid Weiss commented on LUCENE-5786:
-
I've temporarily disabled ALL active configurations on freebsd jenkins. That
is, the following:
- Lucene-Solr-NightlyTests-trunk
- Lucene-Artifacts-trunk
- Lucene-Solr-Clover-4.x
- Lucene-Solr-Clover-trunk
- Lucene-Solr-Maven-4.x
- Lucene-Solr-Maven-trunk
- Lucene-Solr-NightlyTests-4.x
- Lucene-Artifacts-4.x
- Lucene-Solr-SmokeRelease-4.x
- Lucene-Solr-SmokeRelease-trunk
- Lucene-Solr-Tests-4.x-Java7
- Lucene-Solr-Tests-trunk-Java7
- Solr-Artifacts-4.x
- Solr-Artifacts-trunk
Most of these didn't have a successful run in what seems like months, so I
don't think it's a big problem. Still digging what's causing the death of the
test thread (apart from socket interrupt issue we know about there's still
something odd about those tests on freebsd).
Unflushed/ truncated events file (hung testing subprocess)
--
Key: LUCENE-5786
URL: https://issues.apache.org/jira/browse/LUCENE-5786
Project: Lucene - Core
Issue Type: Bug
Components: general/test
Reporter: Dawid Weiss
Assignee: Dawid Weiss
This has happened several times on Jenkins, typically on
SSLMigrationTest.testDistribSearch, but probably on other tests as well.
The symptom is: the test framework never terminates, it also reports an
incorrect (?) hung test.
The problem is that the actual forked JVM is hung on reading stdin, waiting
for the next test suite (no test thread is present); the master process is
hung on receiving data from the forked jvm (both the events file and stdout
spill is truncated in the middle of a test). The last output is:
{code}
[
APPEND_STDERR,
{
chunk: 612639 T30203 oasu.DefaultSolrCoreState.doRecovery Running
recovery - first canceling any ongoing recovery%0A
}
]
[
APPEND_STDERR
{code}
Overall, it looks insane -- there are flushes after each test completes
(normally or not), there are tests *following* the one that last reported
output and before dynamic suites on stdin.
I have no idea. The best explanation is insane -- looks like the test thread
just died in the middle of executing Java code...
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5786) Unflushed/ truncated events file (hung testing subprocess)
[
https://issues.apache.org/jira/browse/LUCENE-5786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14046970#comment-14046970
]
Uwe Schindler commented on LUCENE-5786:
---
Would it be possible to keep the artifacts tasks alive? Those do not run tests,
but they provide (Maven-) artifacts to our users.
Unflushed/ truncated events file (hung testing subprocess)
--
Key: LUCENE-5786
URL: https://issues.apache.org/jira/browse/LUCENE-5786
Project: Lucene - Core
Issue Type: Bug
Components: general/test
Reporter: Dawid Weiss
Assignee: Dawid Weiss
This has happened several times on Jenkins, typically on
SSLMigrationTest.testDistribSearch, but probably on other tests as well.
The symptom is: the test framework never terminates, it also reports an
incorrect (?) hung test.
The problem is that the actual forked JVM is hung on reading stdin, waiting
for the next test suite (no test thread is present); the master process is
hung on receiving data from the forked jvm (both the events file and stdout
spill is truncated in the middle of a test). The last output is:
{code}
[
APPEND_STDERR,
{
chunk: 612639 T30203 oasu.DefaultSolrCoreState.doRecovery Running
recovery - first canceling any ongoing recovery%0A
}
]
[
APPEND_STDERR
{code}
Overall, it looks insane -- there are flushes after each test completes
(normally or not), there are tests *following* the one that last reported
output and before dynamic suites on stdin.
I have no idea. The best explanation is insane -- looks like the test thread
just died in the middle of executing Java code...
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5786) Unflushed/ truncated events file (hung testing subprocess)
[
https://issues.apache.org/jira/browse/LUCENE-5786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14046984#comment-14046984
]
Dawid Weiss commented on LUCENE-5786:
-
I will re-enable all test plans I disabled once I'm done testing. I wanted a
faster build cycle. It shouldn't take too long (if I don't find it until Monday
I'll probably give up).
Unflushed/ truncated events file (hung testing subprocess)
--
Key: LUCENE-5786
URL: https://issues.apache.org/jira/browse/LUCENE-5786
Project: Lucene - Core
Issue Type: Bug
Components: general/test
Reporter: Dawid Weiss
Assignee: Dawid Weiss
This has happened several times on Jenkins, typically on
SSLMigrationTest.testDistribSearch, but probably on other tests as well.
The symptom is: the test framework never terminates, it also reports an
incorrect (?) hung test.
The problem is that the actual forked JVM is hung on reading stdin, waiting
for the next test suite (no test thread is present); the master process is
hung on receiving data from the forked jvm (both the events file and stdout
spill is truncated in the middle of a test). The last output is:
{code}
[
APPEND_STDERR,
{
chunk: 612639 T30203 oasu.DefaultSolrCoreState.doRecovery Running
recovery - first canceling any ongoing recovery%0A
}
]
[
APPEND_STDERR
{code}
Overall, it looks insane -- there are flushes after each test completes
(normally or not), there are tests *following* the one that last reported
output and before dynamic suites on stdin.
I have no idea. The best explanation is insane -- looks like the test thread
just died in the middle of executing Java code...
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5109) Solr 4.4 will not deploy in Glassfish 4.x
[ https://issues.apache.org/jira/browse/SOLR-5109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dodsworth updated SOLR-5109: Attachment: LUCENE-5109.patch Here's a patch for branch_4x to upgrade Guava to 17.0 (in which, the problematic annotation has been removed). Solr 4.4 will not deploy in Glassfish 4.x - Key: SOLR-5109 URL: https://issues.apache.org/jira/browse/SOLR-5109 Project: Solr Issue Type: Bug Affects Versions: 4.4 Environment: Glassfish 4.x Reporter: jamon camisso Priority: Blocker Labels: guava Attachments: LUCENE-5109.patch, guava-15.0-SNAPSHOT.jar The bundled Guava 14.0.1 JAR blocks deploying Solr 4.4 in Glassfish 4.x. This failure is a known issue with upstream Guava and is described here: https://code.google.com/p/guava-libraries/issues/detail?id=1433 Building Guava guava-15.0-SNAPSHOT.jar from master and bundling it in Solr allows for a successful deployment. Until the Guava developers release version 15 using their HEAD or even an RC tag seems like the only way to resolve this. This is frustrating since it was proposed that Guava be removed as a dependency before Solr 4.0 was released and yet it remains and blocks upgrading: https://issues.apache.org/jira/browse/SOLR-3601 -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4787) The QueryScorer.getMaxWeight method is not found.
[ https://issues.apache.org/jira/browse/LUCENE-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dodsworth updated LUCENE-4787: -- Attachment: LUCENE-4787.patch The QueryScorer.getMaxWeight method is not found. - Key: LUCENE-4787 URL: https://issues.apache.org/jira/browse/LUCENE-4787 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Affects Versions: 4.1 Reporter: Hao Zhong Priority: Critical Attachments: LUCENE-4787.patch The following API documents refer to the QueryScorer.getMaxWeight method: http://lucene.apache.org/core/4_1_0/highlighter/org/apache/lucene/search/highlight/package-summary.html The QueryScorer.getMaxWeight method is useful when passed to the GradientFormatter constructor to define the top score which is associated with the top color. http://lucene.apache.org/core/4_1_0/highlighter/org/apache/lucene/search/highlight/GradientFormatter.html See QueryScorer.getMaxWeight which can be used to calibrate scoring scale However, the QueryScorer class does not declare a getMaxWeight method in lucene 4.1, according to its document: http://lucene.apache.org/core/4_1_0/highlighter/org/apache/lucene/search/highlight/QueryScorer.html Instead, the class declares a getMaxTermWeight method. Is that the correct method in the preceding two documents? If it is, please revise the two documents. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-3496) Query parser exceptions no longer displayed in response - just displays null
[
https://issues.apache.org/jira/browse/SOLR-3496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Ryan closed SOLR-3496.
--
Resolution: Cannot Reproduce
This must have been fixed sometime in 4.x. Works fine in 4.9.0.
Query parser exceptions no longer displayed in response - just displays null
--
Key: SOLR-3496
URL: https://issues.apache.org/jira/browse/SOLR-3496
Project: Solr
Issue Type: Bug
Affects Versions: 3.6
Reporter: Michael Ryan
Priority: Minor
Prior to 3.6, if you did a query like this:
{noformat}http://localhost:8983/solr/select?q=AND{noformat}
...you would get an exception and stacktrace in the response like this:
{noformat}Problem accessing /solr/select. Reason:
org.apache.lucene.queryParser.ParseException: Cannot parse 'AND'{noformat}
In 3.6, you get something like this:
{noformat}Problem accessing /solr/select. Reason:
null{noformat}
I think the old behavior was preferable :)
It looks like this was broken by SOLR-3022. Quick fix I think would be to
change this:
{code} public SolrException(ErrorCode code, Throwable th) {
this(code, null, th, (th instanceof SolrException) ?
((SolrException)th).logged : false);
}{code}
To this:
{code} public SolrException(ErrorCode code, Throwable th) {
this(code, th.toString(), th, (th instanceof SolrException) ?
((SolrException)th).logged : false);
}{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4730) SmartChineseAnalyzer got wrong matched offset
[
https://issues.apache.org/jira/browse/LUCENE-4730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14047046#comment-14047046
]
Michael Dodsworth commented on LUCENE-4730:
---
This appears to be a symptom of LUCENE-4984 (fixed in 4.8).
The following test fails:
{code:java}
// note Version.LUCENE_4_7
assertAnalyzesTo(new SmartChineseAnalyzer(Version.LUCENE_4_7, true), My China
,
new String[] { my, china}, new int[] {0,3}, new int[] {2, 8});
{code}
whereas this passes:
{code:java}
note Version.LUCENE_4_8
assertAnalyzesTo(new SmartChineseAnalyzer(Version.LUCENE_4_8, true), My China
,
new String[] { my, china}, new int[] {0,3}, new int[] {2, 8});
{code}
I'll add a test to verify this double-whitespace case but otherwise, this can
be closed out.
SmartChineseAnalyzer got wrong matched offset
-
Key: LUCENE-4730
URL: https://issues.apache.org/jira/browse/LUCENE-4730
Project: Lucene - Core
Issue Type: Bug
Components: modules/analysis
Affects Versions: 4.0, 4.1
Environment: JDK1.7 Linux/Windows
Reporter: Jinsong Hu
Priority: Critical
We found that SmartChineseAnalyzer got wrong matched offset with the
following test code:
public void testHighlight() throws Exception {
String text = My China ;
String queryText = China;
StringBuilder builder = new StringBuilder(html);
Analyzer analyzer = new SmartChineseAnalyzer(Version.LUCENE_40);
//Analyzer analyzer = new StandardAnalyzer(Version.LUCENE_40);
QueryParser parser = new QueryParser(Version.LUCENE_40, text,
analyzer);
Query query = parser.parse(queryText);
SimpleHTMLFormatter formatter = new SimpleHTMLFormatter(span
style=\background: yellow\, /span);
TokenStream tokens = analyzer.tokenStream(text, new
StringReader(text));
QueryScorer scorer = new QueryScorer(query, text);
Highlighter highlighter = new Highlighter(formatter, scorer);
highlighter.setTextFragmenter(new SimpleSpanFragmenter(scorer));
String result = highlighter.getBestFragments(tokens, text, 10, ...);
if (result.length() text.length()) {
result = text;
}
builder.append(body);
builder.append(result);
builder.append(/body);
builder.append(/html);
System.out.println(builder.toString());
}
This method will generate a hilighted text, however, the highlight position
is obviously wrong, and if we remove one space from the text, that is, change
text from My China (ends with two spaces) to My China (ends with one
space), it will generate a text with correct highlight. If we change the
analyzer from SmartChineseAnalyzer to StandardAnalyzer, the highlight issue
will disappear.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4730) SmartChineseAnalyzer got wrong matched offset
[
https://issues.apache.org/jira/browse/LUCENE-4730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dodsworth updated LUCENE-4730:
--
Attachment: LUCENE-4730.patch
SmartChineseAnalyzer got wrong matched offset
-
Key: LUCENE-4730
URL: https://issues.apache.org/jira/browse/LUCENE-4730
Project: Lucene - Core
Issue Type: Bug
Components: modules/analysis
Affects Versions: 4.0, 4.1
Environment: JDK1.7 Linux/Windows
Reporter: Jinsong Hu
Priority: Critical
Attachments: LUCENE-4730.patch
We found that SmartChineseAnalyzer got wrong matched offset with the
following test code:
public void testHighlight() throws Exception {
String text = My China ;
String queryText = China;
StringBuilder builder = new StringBuilder(html);
Analyzer analyzer = new SmartChineseAnalyzer(Version.LUCENE_40);
//Analyzer analyzer = new StandardAnalyzer(Version.LUCENE_40);
QueryParser parser = new QueryParser(Version.LUCENE_40, text,
analyzer);
Query query = parser.parse(queryText);
SimpleHTMLFormatter formatter = new SimpleHTMLFormatter(span
style=\background: yellow\, /span);
TokenStream tokens = analyzer.tokenStream(text, new
StringReader(text));
QueryScorer scorer = new QueryScorer(query, text);
Highlighter highlighter = new Highlighter(formatter, scorer);
highlighter.setTextFragmenter(new SimpleSpanFragmenter(scorer));
String result = highlighter.getBestFragments(tokens, text, 10, ...);
if (result.length() text.length()) {
result = text;
}
builder.append(body);
builder.append(result);
builder.append(/body);
builder.append(/html);
System.out.println(builder.toString());
}
This method will generate a hilighted text, however, the highlight position
is obviously wrong, and if we remove one space from the text, that is, change
text from My China (ends with two spaces) to My China (ends with one
space), it will generate a text with correct highlight. If we change the
analyzer from SmartChineseAnalyzer to StandardAnalyzer, the highlight issue
will disappear.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4787) The QueryScorer.getMaxWeight method is not found.
[ https://issues.apache.org/jira/browse/LUCENE-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14047050#comment-14047050 ] Michael Dodsworth commented on LUCENE-4787: --- doc fixed in the attached patch. The QueryScorer.getMaxWeight method is not found. - Key: LUCENE-4787 URL: https://issues.apache.org/jira/browse/LUCENE-4787 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Affects Versions: 4.1 Reporter: Hao Zhong Priority: Critical Attachments: LUCENE-4787.patch The following API documents refer to the QueryScorer.getMaxWeight method: http://lucene.apache.org/core/4_1_0/highlighter/org/apache/lucene/search/highlight/package-summary.html The QueryScorer.getMaxWeight method is useful when passed to the GradientFormatter constructor to define the top score which is associated with the top color. http://lucene.apache.org/core/4_1_0/highlighter/org/apache/lucene/search/highlight/GradientFormatter.html See QueryScorer.getMaxWeight which can be used to calibrate scoring scale However, the QueryScorer class does not declare a getMaxWeight method in lucene 4.1, according to its document: http://lucene.apache.org/core/4_1_0/highlighter/org/apache/lucene/search/highlight/QueryScorer.html Instead, the class declares a getMaxTermWeight method. Is that the correct method in the preceding two documents? If it is, please revise the two documents. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
