[jira] [Resolved] (LUCENE-5873) AssertionError in ToChildBlockJoinScorer.advance
[
https://issues.apache.org/jira/browse/LUCENE-5873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien Grand resolved LUCENE-5873.
--
Resolution: Fixed
Fix Version/s: Trunk
5.0
Merged, sorry for the delay Mikhail!
AssertionError in ToChildBlockJoinScorer.advance
Key: LUCENE-5873
URL: https://issues.apache.org/jira/browse/LUCENE-5873
Project: Lucene - Core
Issue Type: Bug
Reporter: Varun Thacker
Priority: Minor
Fix For: 5.0, Trunk
Attachments: LUCENE-5873.patch, LUCENE-5873.patch
When using ToChildBJQ and searching via IndexSearcher.search(Query query,
Filter filter, int n) if we provide a filter which matches both parent and
child documents we get this error
{noformat}
java.lang.AssertionError
at
__randomizedtesting.SeedInfo.seed([C346722DC1E4810C:A08F176AE828FA1D]:0)
at
org.apache.lucene.search.join.ToChildBlockJoinQuery$ToChildBlockJoinScorer.advance(ToChildBlockJoinQuery.java:286)
at
org.apache.lucene.search.FilteredQuery$LeapFrogScorer.advanceToNextCommonDoc(FilteredQuery.java:274)
at
org.apache.lucene.search.FilteredQuery$LeapFrogScorer.nextDoc(FilteredQuery.java:286)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:192)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:163)
at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:614)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:483)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:440)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
at
org.apache.lucene.search.join.TestBlockJoinValidation.testValidationForToChildBjqWithChildFilterQuery(TestBlockJoinValidation.java:124)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
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
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
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:365)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
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
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
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
[jira] [Assigned] (SOLR-6906) Fix typo bug in DistributedDebugComponentTest.testCompareWithNonDistributedRequest
[ https://issues.apache.org/jira/browse/SOLR-6906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson reassigned SOLR-6906: Assignee: Erick Erickson Fix typo bug in DistributedDebugComponentTest.testCompareWithNonDistributedRequest -- Key: SOLR-6906 URL: https://issues.apache.org/jira/browse/SOLR-6906 Project: Solr Issue Type: Bug Components: Tests Reporter: Ramkumar Aiyengar Assignee: Erick Erickson Priority: Minor Was making those two lines of the test effectively useless.. -- 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] (LUCENE-6157) Add the ability to compute fine-grained statistics on the filter cache
Adrien Grand created LUCENE-6157: Summary: Add the ability to compute fine-grained statistics on the filter cache Key: LUCENE-6157 URL: https://issues.apache.org/jira/browse/LUCENE-6157 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor The filter cache exposes some useful statistics about its usage, eg. hit count, eviction count, etc. In some cases it could be useful to give users the ability to compute finer-grained statistics though, for example by breaking up statistics by segment, index or by type of filter. -- 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-6906) Fix typo bug in DistributedDebugComponentTest.testCompareWithNonDistributedRequest
[ https://issues.apache.org/jira/browse/SOLR-6906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14263143#comment-14263143 ] ASF GitHub Bot commented on SOLR-6906: -- GitHub user andyetitmoves opened a pull request: https://github.com/apache/lucene-solr/pull/123 Fix typo bug in DistributedDebugComponentTest.testCompareWithNonDistributedRequest Patch for https://issues.apache.org/jira/browse/SOLR-6906 You can merge this pull request into a Git repository by running: $ git pull https://github.com/bloomberg/lucene-solr trunk-ddct-typo-bug Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/123.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #123 commit a3e5e016ae575208ab5f4f996e77620f7b635a2c Author: Ramkumar Aiyengar raiyen...@bloomberg.net Date: 2015-01-02T18:47:03Z Fix typo bug in DistributedDebugComponentTest.testCompareWithNonDistributedRequest Fix typo bug in DistributedDebugComponentTest.testCompareWithNonDistributedRequest -- Key: SOLR-6906 URL: https://issues.apache.org/jira/browse/SOLR-6906 Project: Solr Issue Type: Bug Components: Tests Reporter: Ramkumar Aiyengar Priority: Minor Was making those two lines of the test effectively useless.. -- 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
[GitHub] lucene-solr pull request: Fix typo bug in DistributedDebugComponen...
GitHub user andyetitmoves opened a pull request: https://github.com/apache/lucene-solr/pull/123 Fix typo bug in DistributedDebugComponentTest.testCompareWithNonDistributedRequest Patch for https://issues.apache.org/jira/browse/SOLR-6906 You can merge this pull request into a Git repository by running: $ git pull https://github.com/bloomberg/lucene-solr trunk-ddct-typo-bug Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/123.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #123 commit a3e5e016ae575208ab5f4f996e77620f7b635a2c Author: Ramkumar Aiyengar raiyen...@bloomberg.net Date: 2015-01-02T18:47:03Z Fix typo bug in DistributedDebugComponentTest.testCompareWithNonDistributedRequest --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6157) Add the ability to compute fine-grained statistics on the filter cache
[ https://issues.apache.org/jira/browse/LUCENE-6157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14263178#comment-14263178 ] Robert Muir commented on LUCENE-6157: - Is there a reason to pass readerCoreKey instead of just LeafReader? Add the ability to compute fine-grained statistics on the filter cache -- Key: LUCENE-6157 URL: https://issues.apache.org/jira/browse/LUCENE-6157 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Attachments: LUCENE-6157.patch The filter cache exposes some useful statistics about its usage, eg. hit count, eviction count, etc. In some cases it could be useful to give users the ability to compute finer-grained statistics though, for example by breaking up statistics by segment, index or by type of filter. -- 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-6157) Add the ability to compute fine-grained statistics on the filter cache
[ https://issues.apache.org/jira/browse/LUCENE-6157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand updated LUCENE-6157: - Attachment: LUCENE-6157.patch Here is a patch that adds some expert callbacks that can be used in order to break down stats eg. by index. Add the ability to compute fine-grained statistics on the filter cache -- Key: LUCENE-6157 URL: https://issues.apache.org/jira/browse/LUCENE-6157 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Attachments: LUCENE-6157.patch The filter cache exposes some useful statistics about its usage, eg. hit count, eviction count, etc. In some cases it could be useful to give users the ability to compute finer-grained statistics though, for example by breaking up statistics by segment, index or by type of filter. -- 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-6148) Accountable.getChildResources should return a Collection
[ https://issues.apache.org/jira/browse/LUCENE-6148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand resolved LUCENE-6148. -- Resolution: Fixed Fix Version/s: Trunk 5.0 Accountable.getChildResources should return a Collection Key: LUCENE-6148 URL: https://issues.apache.org/jira/browse/LUCENE-6148 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 5.0, Trunk Attachments: LUCENE-6148.patch Since the child resources must be a snapshot, their size has to be known anyway so returning a collection instead of an iterable would make consumption easier without introducing limitations. -- 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-4839) Jetty 9
[ https://issues.apache.org/jira/browse/SOLR-4839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14263179#comment-14263179 ] Timothy Potter commented on SOLR-4839: -- [~shalinmangar] can you try the patch I provided to SOLR-6874 to see if it fixes the issue for you here? I beast'd the HttpPartitionTest with the patched applied ontop of the latest patch here and it passed 15 of 15. Hoping you see the same. Jetty 9 --- Key: SOLR-4839 URL: https://issues.apache.org/jira/browse/SOLR-4839 Project: Solr Issue Type: Improvement Reporter: Bill Bell Assignee: Shalin Shekhar Mangar Fix For: 5.0, Trunk Attachments: SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch Implement Jetty 9 -- 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-6906) Fix typo bug in DistributedDebugComponentTest.testCompareWithNonDistributedRequest
Ramkumar Aiyengar created SOLR-6906: --- Summary: Fix typo bug in DistributedDebugComponentTest.testCompareWithNonDistributedRequest Key: SOLR-6906 URL: https://issues.apache.org/jira/browse/SOLR-6906 Project: Solr Issue Type: Bug Components: Tests Reporter: Ramkumar Aiyengar Priority: Minor Was making those two lines of the test effectively useless.. -- 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-4.10-Linux (32bit/jdk1.7.0_67) - Build # 206 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.10-Linux/206/
Java: 32bit/jdk1.7.0_67 -server -XX:+UseG1GC (asserts: true)
1 tests failed.
FAILED: org.apache.lucene.search.TestAutomatonQuery.testHugeAutomaton
Error Message:
Java heap space
Stack Trace:
java.lang.OutOfMemoryError: Java heap space
at
__randomizedtesting.SeedInfo.seed([BAF405A6C935A075:C55E1D61A373C9DC]:0)
at
org.apache.lucene.util.automaton.RunAutomaton.init(RunAutomaton.java:144)
at
org.apache.lucene.util.automaton.ByteRunAutomaton.init(ByteRunAutomaton.java:32)
at
org.apache.lucene.util.automaton.CompiledAutomaton.init(CompiledAutomaton.java:203)
at
org.apache.lucene.search.AutomatonQuery.init(AutomatonQuery.java:84)
at
org.apache.lucene.search.TestAutomatonQuery.testHugeAutomaton(TestAutomatonQuery.java:254)
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
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
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:365)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
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
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
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
Build Log:
[...truncated 1509 lines...]
[junit4] Suite: org.apache.lucene.search.TestAutomatonQuery
[junit4] 2 NOTE: reproduce with: ant test -Dtestcase=TestAutomatonQuery
-Dtests.method=testHugeAutomaton -Dtests.seed=BAF405A6C935A075
-Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=it_CH
-Dtests.timezone=Etc/GMT+3 -Dtests.file.encoding=US-ASCII
[junit4] ERROR 1.34s J1 | TestAutomatonQuery.testHugeAutomaton
[junit4] Throwable #1: java.lang.OutOfMemoryError: Java heap space
[junit4]at
__randomizedtesting.SeedInfo.seed([BAF405A6C935A075:C55E1D61A373C9DC]:0)
[junit4]at
org.apache.lucene.util.automaton.RunAutomaton.init(RunAutomaton.java:144)
[junit4]at
org.apache.lucene.util.automaton.ByteRunAutomaton.init(ByteRunAutomaton.java:32)
[junit4]at
org.apache.lucene.util.automaton.CompiledAutomaton.init(CompiledAutomaton.java:203)
[junit4]at
org.apache.lucene.search.AutomatonQuery.init(AutomatonQuery.java:84)
[junit4]at
org.apache.lucene.search.TestAutomatonQuery.testHugeAutomaton(TestAutomatonQuery.java:254)
[junit4] 2 NOTE: test params are: codec=Lucene49,
sim=RandomSimilarityProvider(queryNorm=true,coord=yes): {footer=IB LL-D1,
field=DFR I(n)L2, title=DFR I(n)Z(0.3)},
[jira] [Commented] (LUCENE-5873) AssertionError in ToChildBlockJoinScorer.advance
[
https://issues.apache.org/jira/browse/LUCENE-5873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14263370#comment-14263370
]
Mikhail Khludnev commented on LUCENE-5873:
--
Merci!
AssertionError in ToChildBlockJoinScorer.advance
Key: LUCENE-5873
URL: https://issues.apache.org/jira/browse/LUCENE-5873
Project: Lucene - Core
Issue Type: Bug
Reporter: Varun Thacker
Priority: Minor
Fix For: 5.0, Trunk
Attachments: LUCENE-5873.patch, LUCENE-5873.patch
When using ToChildBJQ and searching via IndexSearcher.search(Query query,
Filter filter, int n) if we provide a filter which matches both parent and
child documents we get this error
{noformat}
java.lang.AssertionError
at
__randomizedtesting.SeedInfo.seed([C346722DC1E4810C:A08F176AE828FA1D]:0)
at
org.apache.lucene.search.join.ToChildBlockJoinQuery$ToChildBlockJoinScorer.advance(ToChildBlockJoinQuery.java:286)
at
org.apache.lucene.search.FilteredQuery$LeapFrogScorer.advanceToNextCommonDoc(FilteredQuery.java:274)
at
org.apache.lucene.search.FilteredQuery$LeapFrogScorer.nextDoc(FilteredQuery.java:286)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:192)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:163)
at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:614)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:483)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:440)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
at
org.apache.lucene.search.join.TestBlockJoinValidation.testValidationForToChildBjqWithChildFilterQuery(TestBlockJoinValidation.java:124)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
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
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
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:365)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
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
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
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
[JENKINS] Lucene-Solr-SmokeRelease-5.x - Build # 226 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.x/226/
No tests ran.
Build Log:
[...truncated 51913 lines...]
prepare-release-no-sign:
[mkdir] Created dir:
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist
[copy] Copying 446 files to
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/lucene
[copy] Copying 245 files to
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/solr
[smoker] Java 1.7 JAVA_HOME=/home/jenkins/tools/java/latest1.7
[smoker] NOTE: output encoding is US-ASCII
[smoker]
[smoker] Load release URL
file:/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/...
[smoker]
[smoker] Test Lucene...
[smoker] test basics...
[smoker] get KEYS
[smoker] 0.1 MB in 0.01 sec (9.7 MB/sec)
[smoker] check changes HTML...
[smoker] download lucene-5.0.0-src.tgz...
[smoker] 27.9 MB in 0.04 sec (678.0 MB/sec)
[smoker] verify md5/sha1 digests
[smoker] download lucene-5.0.0.tgz...
[smoker] 64.0 MB in 0.15 sec (431.2 MB/sec)
[smoker] verify md5/sha1 digests
[smoker] download lucene-5.0.0.zip...
[smoker] 73.5 MB in 0.12 sec (589.9 MB/sec)
[smoker] verify md5/sha1 digests
[smoker] unpack lucene-5.0.0.tgz...
[smoker] verify JAR metadata/identity/no javax.* or java.* classes...
[smoker] test demo with 1.7...
[smoker] got 5631 hits for query lucene
[smoker] checkindex with 1.7...
[smoker] check Lucene's javadoc JAR
[smoker] unpack lucene-5.0.0.zip...
[smoker] verify JAR metadata/identity/no javax.* or java.* classes...
[smoker] test demo with 1.7...
[smoker] got 5631 hits for query lucene
[smoker] checkindex with 1.7...
[smoker] check Lucene's javadoc JAR
[smoker] unpack lucene-5.0.0-src.tgz...
[smoker] make sure no JARs/WARs in src dist...
[smoker] run ant validate
[smoker] run tests w/ Java 7 and testArgs='-Dtests.jettyConnector=Socket
-Dtests.multiplier=1 -Dtests.slow=false'...
[smoker] test demo with 1.7...
[smoker] got 209 hits for query lucene
[smoker] checkindex with 1.7...
[smoker] generate javadocs w/ Java 7...
[smoker]
[smoker] Crawl/parse...
[smoker]
[smoker] Verify...
[smoker] confirm all releases have coverage in TestBackwardsCompatibility
[smoker] find all past Lucene releases...
[smoker] run TestBackwardsCompatibility..
[smoker] Traceback (most recent call last):
[smoker] File
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py,
line 1527, in module
[smoker] main()
[smoker] File
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py,
line 1472, in main
[smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir,
c.is_signed, ' '.join(c.test_args))
[smoker] File
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py,
line 1510, in smokeTest
[smoker] unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' %
version, svnRevision, version, testArgs, baseURL)
[smoker] File
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py,
line 616, in unpackAndVerify
[smoker] verifyUnpacked(java, project, artifact, unpackPath,
svnRevision, version, testArgs, tmpDir, baseURL)
[smoker] File
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py,
line 801, in verifyUnpacked
[smoker] confirmAllReleasesAreTestedForBackCompat(unpackPath)
[smoker] File
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py,
line 1465, in confirmAllReleasesAreTestedForBackCompat
[smoker] Releases that don't seem to be tested:
[smoker] 4.10.3
[smoker] raise RuntimeError('some releases are not tested by
TestBackwardsCompatibility?')
[smoker] RuntimeError: some releases are not tested by
TestBackwardsCompatibility?
BUILD FAILED
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/build.xml:414:
exec returned: 1
Total time: 47 minutes 39 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure
Sending email for trigger: Failure
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-4839) Jetty 9
[
https://issues.apache.org/jira/browse/SOLR-4839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14263338#comment-14263338
]
Shalin Shekhar Mangar edited comment on SOLR-4839 at 1/3/15 12:37 AM:
--
{quote}
I just wanted to mention, that the move to Jetty 9 may need us to disable solr
test on FreeBSD Jenkins completely. Currently, FreeBSD Jenkins uses the special
sysprop tests.jettyConnector (or like that) to use the simple Java IO based
connector.
{quote}
I don't think we have a choice. I'd like to take advantage of async http for
inter-shard communication so we need Jetty 9. Also, the FreeBSD Jenkins has
been very unreliable in the past compared to your Policeman Jenkins box. I'm
never quite sure whether a test failing on FreeBSD is a genuine or not.
Can you please disable the FreeBSD jenkins [~thetaphi]?
was (Author: shalinmangar):
{quote}
I just wanted to mention, that the move to Jetty 9 may need us to disable solr
test on FreeBSD Jenkins completely. Currently, FreeBSD Jenkins uses the special
sysprop tests.jettyConnector (or like that) to use the simple Java IO based
connector.
{quote}
I don't think we have a choice. I'd like to take advantage of async http for
inter-shard communication so we need Jetty 9. Also, the FreeBSD Jenkins has
been very unreliable in the past compared to your Policeman Jenkins box. I'm
never quite sure whether a test failing on FreeBSD is a genuine or not.
Jetty 9
---
Key: SOLR-4839
URL: https://issues.apache.org/jira/browse/SOLR-4839
Project: Solr
Issue Type: Improvement
Reporter: Bill Bell
Assignee: Shalin Shekhar Mangar
Fix For: 5.0, Trunk
Attachments: SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch,
SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch
Implement Jetty 9
--
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-4839) Jetty 9
[
https://issues.apache.org/jira/browse/SOLR-4839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14263338#comment-14263338
]
Shalin Shekhar Mangar commented on SOLR-4839:
-
{quote}
I just wanted to mention, that the move to Jetty 9 may need us to disable solr
test on FreeBSD Jenkins completely. Currently, FreeBSD Jenkins uses the special
sysprop tests.jettyConnector (or like that) to use the simple Java IO based
connector.
{quote}
I don't think we have a choice. I'd like to take advantage of async http for
inter-shard communication so we need Jetty 9. Also, the FreeBSD Jenkins has
been very unreliable in the past compared to your Policeman Jenkins box. I'm
never quite sure whether a test failing on FreeBSD is a genuine or not.
Jetty 9
---
Key: SOLR-4839
URL: https://issues.apache.org/jira/browse/SOLR-4839
Project: Solr
Issue Type: Improvement
Reporter: Bill Bell
Assignee: Shalin Shekhar Mangar
Fix For: 5.0, Trunk
Attachments: SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch,
SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch
Implement Jetty 9
--
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-6874) There is a race around SocketProxy binding to it's port the way we setup JettySolrRunner and SocketProxy.
[ https://issues.apache.org/jira/browse/SOLR-6874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14263330#comment-14263330 ] ASF subversion and git services commented on SOLR-6874: --- Commit 1649154 from [~thelabdude] in branch 'dev/trunk' [ https://svn.apache.org/r1649154 ] SOLR-6874: There is a race around SocketProxy binding to it's port the way we setup JettySolrRunner and SocketProxy. There is a race around SocketProxy binding to it's port the way we setup JettySolrRunner and SocketProxy. - Key: SOLR-6874 URL: https://issues.apache.org/jira/browse/SOLR-6874 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Attachments: SOLR-6874.patch I ran into this while working on SOLR-4509 and have a fix there in my latest patch. Because we get an available port by opening and closing a scocket on port 0 and then try to use it again with the SocketProxy, sometimes it fails to bind and the test can fail. We can change the code a bit so that the SocketProxy itself can start on port 0 rather than this two step fragile process. -- 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-5147) Support Block Join documents in DIH
[
https://issues.apache.org/jira/browse/SOLR-5147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14263373#comment-14263373
]
Mikhail Khludnev commented on SOLR-5147:
usage example:
mind adding {{child='true'}} attribute into nesting child entity
{code}
document
entity name='PARENT' query='select * from PARENT'
field column='id' /
field column='desc' /
field column='type_s' /
entity child='true' name='CHILD' query=select * from CHILD where
parent_id='${PARENT.id}'
field column='id' /
field column='desc' /
field column='type_s' /
/entity
/entity
/document
{code}
Support Block Join documents in DIH
---
Key: SOLR-5147
URL: https://issues.apache.org/jira/browse/SOLR-5147
Project: Solr
Issue Type: Sub-task
Reporter: Vadim Kirilchuk
Assignee: Noble Paul
Fix For: 4.9, Trunk
Attachments: SOLR-5147-5x.patch, SOLR-5147.patch, SOLR-5147.patch
DIH should be able to index hierarchical documents, i.e. it should be able to
work with SolrInputDocuments#addChildDocument.
There was patch in SOLR-3076:
https://issues.apache.org/jira/secure/attachment/12576960/dih-3076.patch
But it is not uptodate and far from being complete.
--
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-4839) Jetty 9
[ https://issues.apache.org/jira/browse/SOLR-4839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-4839: Attachment: SOLR-4839.patch Latest patch which includes SOLR-6874. All tests pass. I think we should commit this and then work on a SSL switch in the bin scripts as well as easy to modify https/ssl configuration in the jetty configs. Jetty 9 --- Key: SOLR-4839 URL: https://issues.apache.org/jira/browse/SOLR-4839 Project: Solr Issue Type: Improvement Reporter: Bill Bell Assignee: Shalin Shekhar Mangar Fix For: 5.0, Trunk Attachments: SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch Implement Jetty 9 -- 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-4839) Jetty 9
[ https://issues.apache.org/jira/browse/SOLR-4839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-4839: Attachment: SOLR-4839.patch This patch removes the tests.jettyConnector sysprop as Uwe mentioned earlier. Jetty 9 --- Key: SOLR-4839 URL: https://issues.apache.org/jira/browse/SOLR-4839 Project: Solr Issue Type: Improvement Reporter: Bill Bell Assignee: Shalin Shekhar Mangar Fix For: 5.0, Trunk Attachments: SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch Implement Jetty 9 -- 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-5.x-Linux (32bit/jdk1.7.0_67) - Build # 11670 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11670/ Java: 32bit/jdk1.7.0_67 -client -XX:+UseConcMarkSweepGC (asserts: true) 1 tests failed. FAILED: org.apache.solr.handler.TestSolrConfigHandlerCloud.testDistribSearch Error Message: Could not get expected value BY val for path [params, b] full output null Stack Trace: java.lang.AssertionError: Could not get expected value BY val for path [params, b] full output null at __randomizedtesting.SeedInfo.seed([9B235EF2ACF22F6C:1AC5D0EADBAD4F50]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:231) at org.apache.solr.handler.TestSolrConfigHandlerCloud.testReqParams(TestSolrConfigHandlerCloud.java:197) at org.apache.solr.handler.TestSolrConfigHandlerCloud.doTest(TestSolrConfigHandlerCloud.java:61) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:868) 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:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) 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 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at
Re: Randomized testing talk (your favorite moment)
Some of the bugs it has helped me find that I am most appreciative of are in testing spatial code. One comes to mind when I developed the IsWithin predicate, and others in computing the bounding lat-lon box of a geodetic circle, and… and on and on… but the details are unimportant really and to tell you/your-audience would be a distraction. The point is, I don’t know where the bugs are a-priori; otherwise I’d fix them :-). When developing these tests, it’s almost pointless to put in particular static/fixed/boring test of the form: given this input, expect this output, unless I’m adding a regression test for a bug I found. Instead, the most thorough way to do it is to randomly come up with the shapes and have a brute-force way to test the result in the test, then test that the result is consistent when using the real code I want to test. It’s not all roses… developing these tests are hard! — particularly when there is ambiguity in the answer (i.e. values being close-enough for the precision supported in the particular scenario). And diagnosing a failure takes time. And there’s a bit of an art to choosing random but not too random values. For example, have coincident touching shapes, instead of purely random numerical values. Similar in concept is some random string generation utility methods I think you developed. ~ David Smiley Freelance Apache Lucene/Solr Search Consultant/Developer http://www.linkedin.com/in/davidwsmiley On Fri, Jan 2, 2015 at 4:00 AM, Dawid Weiss dawid.we...@gmail.com wrote: Hi everyone! I am giving a talk about randomized testing in a month or so and I thought it'd be cool to share some real-life ah-crap, gotcha, wtf moments related to the bugs discovered by randomized testing. My personal favorite is LUCENE-5168 (g1gc/ impossible code path) which, by the way, is still unresolved and we have no idea how to reproduce it reliably. Another is one of Robert's bugs with Unicode where he debugged what seemed like a megabutt of crazy-hairy random unicode that triggered the problem. These sorts of things. You can reply to the list or to my prv. e-mail if you wish. Dawid P.S. The talk's abstract is below here. Randomized Testing: When a Monkey Can do Better than Human. The talk will take a look at the concept of writing (unit) tests with predictable randomness. We will try to generalize: describe what such tests are, how to write them and how randomized testing can help in finding bugs in otherwise deterministic routines. We will also try to demonstrate on real-life examples that human understanding and predictions with regard to software are typically, ehm, incorrect (the same applies to mice and towels, see: THGTTG for full explanation). Randomized testing has been used extensively in Apache Lucene, Solr and ElasticSearch. Developers generally love it because it's effective at finding bugs and hate it when the bugs it finds are theirs to debug. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6797) Add score=degrees|kilometers|miles for AbstractSpatialFieldType
[
https://issues.apache.org/jira/browse/SOLR-6797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14262924#comment-14262924
]
David Smiley commented on SOLR-6797:
The remaining part we forgot about was geodist, as mentioned in the Review
Board minutes ago. That's a blocker.
BTW this is the CHANGES.txt additions I wrote up:
Upgrading:
{noformat}
* Spatial fields originating from Solr 4 (e.g.
SpatialRecursivePrefixTreeFieldType, BBoxField)
have the 'units' attribute deprecated, now replaced with 'distanceUnits'. If
you change it to
a unit other than 'degrees' (or if you don't specify it, which will default
to kilometers if
geo=true), then be sure to update maxDistErr as it's in those units. If you
keep units=degrees
then it should be backwards compatible but you'll get a deprecation warning
on startup. See
SOLR-6797.
{noformat}
New Features:
{noformat}
* SOLR-6797: Spatial fields that used to require units=degrees like
SpatialRecursivePrefixTreeFieldType (RPT) now don't; it's deprecated. It's
replaced with a
distanceUnits attribute allowing degrees|kilometers|miles. It affects the
result of the
score=distance|area|area2d mode of queries using this field which will now
use these units,
as well as maxDistErr, distErr and the 'd' parameter referenced by geofilt
and geodist. score
now supports kilometers|miles|degrees to choose at query time. It does NOT
affect distances
embedded in WKT strings like BUFFER(POINT(200 10),0.2))
(Ishan Chattopadhyaya, David Smiley)
{noformat}
Add score=degrees|kilometers|miles for AbstractSpatialFieldType
---
Key: SOLR-6797
URL: https://issues.apache.org/jira/browse/SOLR-6797
Project: Solr
Issue Type: Improvement
Components: spatial
Reporter: David Smiley
Assignee: David Smiley
Fix For: 5.0, Trunk
Attachments: SOLR-6797.patch, SOLR-6797.patch, SOLR-6797.patch,
SOLR-6797.patch, SOLR-6797.patch, SOLR-6797.patch
Annoyingly, the units=degrees attribute is required for fields extending
AbstractSpatialFieldType (e.g. RPT, BBox). And it doesn't really have any
effect. I propose the following:
* Simply drop the attribute; ignore it if someone sets it to degrees (for
back-compat).
* When using score=distance, or score=area or area2D (as seen in BBoxField)
then use kilometers if geo=true, otherwise degrees.
* Add support for score=degrees|kilometers|miles|degrees
--
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-6797) Add score=degrees|kilometers|miles for AbstractSpatialFieldType
[ https://issues.apache.org/jira/browse/SOLR-6797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14262852#comment-14262852 ] Ishan Chattopadhyaya commented on SOLR-6797: Thanks David! Updated the review request with this patch. Have a happy new year! Add score=degrees|kilometers|miles for AbstractSpatialFieldType --- Key: SOLR-6797 URL: https://issues.apache.org/jira/browse/SOLR-6797 Project: Solr Issue Type: Improvement Components: spatial Reporter: David Smiley Assignee: David Smiley Fix For: 5.0, Trunk Attachments: SOLR-6797.patch, SOLR-6797.patch, SOLR-6797.patch, SOLR-6797.patch, SOLR-6797.patch, SOLR-6797.patch Annoyingly, the units=degrees attribute is required for fields extending AbstractSpatialFieldType (e.g. RPT, BBox). And it doesn't really have any effect. I propose the following: * Simply drop the attribute; ignore it if someone sets it to degrees (for back-compat). * When using score=distance, or score=area or area2D (as seen in BBoxField) then use kilometers if geo=true, otherwise degrees. * Add support for score=degrees|kilometers|miles|degrees -- 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-6797) Add score=degrees|kilometers|miles for AbstractSpatialFieldType
[ https://issues.apache.org/jira/browse/SOLR-6797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14262851#comment-14262851 ] Ishan Chattopadhyaya commented on SOLR-6797: Thanks David! Updated the review request with this patch. Have a happy new year! Add score=degrees|kilometers|miles for AbstractSpatialFieldType --- Key: SOLR-6797 URL: https://issues.apache.org/jira/browse/SOLR-6797 Project: Solr Issue Type: Improvement Components: spatial Reporter: David Smiley Assignee: David Smiley Fix For: 5.0, Trunk Attachments: SOLR-6797.patch, SOLR-6797.patch, SOLR-6797.patch, SOLR-6797.patch, SOLR-6797.patch, SOLR-6797.patch Annoyingly, the units=degrees attribute is required for fields extending AbstractSpatialFieldType (e.g. RPT, BBox). And it doesn't really have any effect. I propose the following: * Simply drop the attribute; ignore it if someone sets it to degrees (for back-compat). * When using score=distance, or score=area or area2D (as seen in BBoxField) then use kilometers if geo=true, otherwise degrees. * Add support for score=degrees|kilometers|miles|degrees -- 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] [Issue Comment Deleted] (SOLR-6797) Add score=degrees|kilometers|miles for AbstractSpatialFieldType
[ https://issues.apache.org/jira/browse/SOLR-6797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya updated SOLR-6797: --- Comment: was deleted (was: Thanks David! Updated the review request with this patch. Have a happy new year!) Add score=degrees|kilometers|miles for AbstractSpatialFieldType --- Key: SOLR-6797 URL: https://issues.apache.org/jira/browse/SOLR-6797 Project: Solr Issue Type: Improvement Components: spatial Reporter: David Smiley Assignee: David Smiley Fix For: 5.0, Trunk Attachments: SOLR-6797.patch, SOLR-6797.patch, SOLR-6797.patch, SOLR-6797.patch, SOLR-6797.patch, SOLR-6797.patch Annoyingly, the units=degrees attribute is required for fields extending AbstractSpatialFieldType (e.g. RPT, BBox). And it doesn't really have any effect. I propose the following: * Simply drop the attribute; ignore it if someone sets it to degrees (for back-compat). * When using score=distance, or score=area or area2D (as seen in BBoxField) then use kilometers if geo=true, otherwise degrees. * Add support for score=degrees|kilometers|miles|degrees -- 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-5147) Support Block Join documents in DIH
[ https://issues.apache.org/jira/browse/SOLR-5147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14262906#comment-14262906 ] Shawn Heisey edited comment on SOLR-5147 at 1/2/15 2:02 PM: The change is simple, already described above. Here is a more explicit change description: I changed the StoredDocument import to org.apache.lucene.document.Document, then changed the type of doc to Document. was (Author: elyograg): The change is simple, already described above. Here is a more explicit change description: I changed the SolrDocument import to org.apache.lucene.document.Document, then changed the type of doc to Document. Support Block Join documents in DIH --- Key: SOLR-5147 URL: https://issues.apache.org/jira/browse/SOLR-5147 Project: Solr Issue Type: Sub-task Reporter: Vadim Kirilchuk Assignee: Noble Paul Fix For: 4.9, Trunk Attachments: SOLR-5147-5x.patch, SOLR-5147.patch, SOLR-5147.patch DIH should be able to index hierarchical documents, i.e. it should be able to work with SolrInputDocuments#addChildDocument. There was patch in SOLR-3076: https://issues.apache.org/jira/secure/attachment/12576960/dih-3076.patch But it is not uptodate and far from being complete. -- 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-5147) Support Block Join documents in DIH
[ https://issues.apache.org/jira/browse/SOLR-5147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14262906#comment-14262906 ] Shawn Heisey commented on SOLR-5147: The change is simple, already described above. Here is a more explicit change description: I changed the SolrDocument import to org.apache.lucene.document.Document, then changed the type of doc to Document. Support Block Join documents in DIH --- Key: SOLR-5147 URL: https://issues.apache.org/jira/browse/SOLR-5147 Project: Solr Issue Type: Sub-task Reporter: Vadim Kirilchuk Assignee: Noble Paul Fix For: 4.9, Trunk Attachments: SOLR-5147-5x.patch, SOLR-5147.patch, SOLR-5147.patch DIH should be able to index hierarchical documents, i.e. it should be able to work with SolrInputDocuments#addChildDocument. There was patch in SOLR-3076: https://issues.apache.org/jira/secure/attachment/12576960/dih-3076.patch But it is not uptodate and far from being complete. -- 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-5147) Support Block Join documents in DIH
[ https://issues.apache.org/jira/browse/SOLR-5147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Heisey updated SOLR-5147: --- Attachment: SOLR-5147-5x.patch Attached is a diff from 5x where I applied the original patch and then made a change in the new test so it would compile and run. Support Block Join documents in DIH --- Key: SOLR-5147 URL: https://issues.apache.org/jira/browse/SOLR-5147 Project: Solr Issue Type: Sub-task Reporter: Vadim Kirilchuk Assignee: Noble Paul Fix For: 4.9, Trunk Attachments: SOLR-5147-5x.patch, SOLR-5147.patch, SOLR-5147.patch DIH should be able to index hierarchical documents, i.e. it should be able to work with SolrInputDocuments#addChildDocument. There was patch in SOLR-3076: https://issues.apache.org/jira/secure/attachment/12576960/dih-3076.patch But it is not uptodate and far from being complete. -- 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-5873) AssertionError in ToChildBlockJoinScorer.advance
[
https://issues.apache.org/jira/browse/LUCENE-5873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14262977#comment-14262977
]
ASF subversion and git services commented on LUCENE-5873:
-
Commit 1649071 from [~jpountz] in branch 'dev/trunk'
[ https://svn.apache.org/r1649071 ]
LUCENE-5873: BJQ: Throw an error if the top-level filter is not in the child
space instead of just asserting.
AssertionError in ToChildBlockJoinScorer.advance
Key: LUCENE-5873
URL: https://issues.apache.org/jira/browse/LUCENE-5873
Project: Lucene - Core
Issue Type: Bug
Reporter: Varun Thacker
Priority: Minor
Attachments: LUCENE-5873.patch, LUCENE-5873.patch
When using ToChildBJQ and searching via IndexSearcher.search(Query query,
Filter filter, int n) if we provide a filter which matches both parent and
child documents we get this error
{noformat}
java.lang.AssertionError
at
__randomizedtesting.SeedInfo.seed([C346722DC1E4810C:A08F176AE828FA1D]:0)
at
org.apache.lucene.search.join.ToChildBlockJoinQuery$ToChildBlockJoinScorer.advance(ToChildBlockJoinQuery.java:286)
at
org.apache.lucene.search.FilteredQuery$LeapFrogScorer.advanceToNextCommonDoc(FilteredQuery.java:274)
at
org.apache.lucene.search.FilteredQuery$LeapFrogScorer.nextDoc(FilteredQuery.java:286)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:192)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:163)
at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:614)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:483)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:440)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
at
org.apache.lucene.search.join.TestBlockJoinValidation.testValidationForToChildBjqWithChildFilterQuery(TestBlockJoinValidation.java:124)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
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
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
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:365)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
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
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
[JENKINS-MAVEN] Lucene-Solr-Maven-5.x #806: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-5.x/806/ 5 tests failed. FAILED: org.apache.solr.hadoop.MorphlineGoLiveMiniMRTest.org.apache.solr.hadoop.MorphlineGoLiveMiniMRTest Error Message: null Stack Trace: java.lang.AssertionError: null at __randomizedtesting.SeedInfo.seed([D66B737BC79717D6]:0) at org.apache.lucene.util.TestRuleTemporaryFilesCleanup.before(TestRuleTemporaryFilesCleanup.java:105) at com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.before(TestRuleAdapter.java:26) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:35) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) FAILED: org.apache.solr.hadoop.MorphlineMapperTest.org.apache.solr.hadoop.MorphlineMapperTest Error Message: 1 thread leaked from SUITE scope at org.apache.solr.hadoop.MorphlineMapperTest: 1) Thread[id=645, name=java.util.concurrent.ThreadPoolExecutor$Worker@16717d41[State = -1, empty queue], state=WAITING, group=TGRP-MorphlineBasicMiniMRTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.hadoop.MorphlineMapperTest: 1) Thread[id=645, name=java.util.concurrent.ThreadPoolExecutor$Worker@16717d41[State = -1, empty queue], state=WAITING, group=TGRP-MorphlineBasicMiniMRTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) at __randomizedtesting.SeedInfo.seed([CE3F8A7A69FD3B07]:0) FAILED: org.apache.solr.hadoop.MorphlineMapperTest.org.apache.solr.hadoop.MorphlineMapperTest Error Message: There are still zombie threads that couldn't be terminated: 1) Thread[id=645, name=java.util.concurrent.ThreadPoolExecutor$Worker@16717d41[State = -1, empty queue], state=WAITING, group=TGRP-MorphlineBasicMiniMRTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie threads that couldn't be terminated: 1) Thread[id=645, name=java.util.concurrent.ThreadPoolExecutor$Worker@16717d41[State = -1, empty queue], state=WAITING, group=TGRP-MorphlineBasicMiniMRTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at
[jira] [Commented] (LUCENE-6156) StackOverFlow error during parsing of a request
[ https://issues.apache.org/jira/browse/LUCENE-6156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14262966#comment-14262966 ] Aurelien PISU commented on LUCENE-6156: --- here the value of regular expression sent to lucene. Note it was working with the version 10.6 of lucene aaa|accpp2|adx|apn|auto|autres||bch|bobsleigh|bopp|bretagne|ccko|ch|change|cme|cmx|cns|cp|cpt|credit|creditchec|csb|csb1|cxx|del|dom|eee|eric|etat|exe|exenot|fg|filtre|fourn|gb|gb2|gdd|gdd1|gdd2|gdd3|gh|giet|hub|ing|jha|jml|jpj|kiwi|lesautres|liasse|llc|lock|luge|lv01|mae|manhld|marge|mbt|mfg|mgtest|mkg|mkt|mls|mm|mm2|msl|myowncode|nature|niveau1|niveau2|niveau3|nivoj|nivok|nl|noacces|nochange|noexe|okmodif|par1|par2|parb|paris|pasokmodif|peseur1|peseur2|pp|pp2|proace|qualite|rep|salaires|sdr|ski|sophia|sordiv|sta|stats|sup|tbd|tbord|tdbcons|tdbexec|tdbmodif|test|testcce|testpp|topsecret|toto|trado||usua2|util|velo|vlt|xextmnt|xtest|xxx|yyy|za1|za2|za3|zcb|zeb|zhb|zinc|zqua|zz|zzcp|zzeb|zzjfl|zzlse|zzmb|zzmb1|zzmb2|zzmb3|zzmb4|zzzx||z|_all StackOverFlow error during parsing of a request --- Key: LUCENE-6156 URL: https://issues.apache.org/jira/browse/LUCENE-6156 Project: Lucene - Core Issue Type: Bug Components: core/queryparser Affects Versions: 4.10.2 Environment: windows 2008, osx yosemite with java 1.7.0_60 Reporter: Aurelien PISU Priority: Critical during parsing of a query send to lucene via elasticSearch 1.4.2, i encounter that stackOverFlow exception on RegExp. here the stack trace Caused by: java.lang.StackOverflowError at java.util.BitSet.(BitSet.java:154) at org.apache.lucene.util.automaton.Automaton.(Automaton.java:75) at org.apache.lucene.util.automaton.Automata.makeString(Automata.java:273) at org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:518) at org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:553) at org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:550) at org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:551) at org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:551) Note : the regular expression is quite large and contains only ascii character and '|' character. let me know, If you need the value of the regular expression. This issue was firstly raise to elastic search component on github that use the 4.10.2 version of lucene and identify as a lucene issue. -- 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-5702) Per-segment comparator API
[
https://issues.apache.org/jira/browse/LUCENE-5702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien Grand updated LUCENE-5702:
-
Attachment: SortBench.java
LUCENE-5702.patch
Updated patch to current trunk. I also did some benchmarking and the removal of
the one-comparator specialization had a bad impact on performance so I added it
back, we could discuss the over-specialization of top-field collectors in a
different issue...
You can find attached the (dummy) benchmark that I used to check the
performance impact of this patch. Times are in milliseconds (the smaller the
better).
|| sort || trunk || patch || difference ||
| long asc | 100 | 108 | +8% |
| long desc | 101 | 110 | +9% |
| double asc | 107 | 114 | +7% |
| double desc | 113 | 118 | +4% |
| string asc | 119 | 123 | +3% |
| string desc | 120 | 124 | +3% |
| long asc, double asc | 98 | 87 | -11% |
| long desc, double desc | 102 | 89 | -13% |
Some cases are slightly faster, others are slightly slower. This benchmark only
runs a sort to find the top 50 hits on a {{MatchAllDocsQuery}}, so differences
would be even smaller if you run an actual query and/or have other collectors
(eg. if you also want to compute facets).
This patch is **only** about API. It just splits FieldComparator into
* FieldComparator:
** compare(int slot1, int slot2)
** void setTopValue(T value)
** T value(int slot)
** LeafFieldComparator getLeafComparator(LeafReaderContext context)
* and LeafFieldComparator:
** int compareBottom(int doc)
** int compareTop(int doc)
** void copy(int slot, int doc)
** void setScorer(Scorer scorer)
All the logic about top-field collection is left unchanged. So there is still a
single top-level priority queue that all leaf collectors update. I think
changing the API is important for several reasons:
* it makes the FieldComparator API aligned with the Collector API
(LeafCollector - LeafFieldComparator)
* it makes the workflow easier to understand: you need to get a
LeafFieldComparator before you can call setScorer
* Even if the patch does not contain any optimization, it would make
per-segment optimizations easier. For instance, if all documents in a segment
have the same value, we could ignore this sort field in comparisons. Or if an
index has a single segment, we could decide to only use ordinals for
comparisons and avoid copying values on each competitive hit.
Per-segment comparator API
--
Key: LUCENE-5702
URL: https://issues.apache.org/jira/browse/LUCENE-5702
Project: Lucene - Core
Issue Type: New Feature
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
Fix For: Trunk
Attachments: LUCENE-5702.patch, LUCENE-5702.patch, SortBench.java
As a next step of LUCENE-5527, it would be nice to have per-segment
comparators, and maybe even change the default behavior of our top*
comparators so that they merge top hits in the end.
--
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-6494) Query filters applied in a wrong order
[
https://issues.apache.org/jira/browse/SOLR-6494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14262963#comment-14262963
]
Shawn Heisey commented on SOLR-6494:
bq. what if Solr detecting that the filter does use date rages like [* TO
2014-09-08T23:59:59Z] (or probably any ranges where cache is not very efficient)
I don't understand why a date range would not be very efficient on the cache.
If the values in the range are static, it is just like any other filter query.
The only time a date range affects cache usage is if that date range uses an
unaltered NOW keyword. NOW changes with every millisecond that passes, so
multiple queries using that keyword will be different, which makes the cache
useless. If NOW is rounded (NOW/HOUR, NOW/DAY, etc), then the value will not
change from query to query, and the cache will be useful.
There is a capability called postfilter, which lets you declare a filter's cost
as high enough that it will be executed AFTER everything else, but I don't
think the standard query parser supports that functionality. I would love to
be proven wrong about that assumption.
http://heliosearch.org/advanced-filter-caching-in-solr/
Query filters applied in a wrong order
--
Key: SOLR-6494
URL: https://issues.apache.org/jira/browse/SOLR-6494
Project: Solr
Issue Type: Bug
Affects Versions: 4.8.1
Reporter: Alexander S.
This query:
{code}
{
fq: [type:Award::Nomination],
sort: score desc,
start: 0,
rows: 20,
q: *:*
}
{code}
takes just a few milliseconds, but this one:
{code}
{
fq: [
type:Award::Nomination,
created_at_d:[* TO 2014-09-08T23:59:59Z]
],
sort: score desc,
start: 0,
rows: 20,
q: *:*
}
{code}
takes almost 15 seconds.
I have just ≈12k of documents with type Award::Nomination, but around half
a billion with created_at_d field set. And it seems Solr applies the
created_at_d filter first going through all documents where this field is
set, which is not very smart.
I think if it can't do anything better than applying filters in the alphabet
order it should apply them in the order they were received.
--
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-6494) Query filters applied in a wrong order
[
https://issues.apache.org/jira/browse/SOLR-6494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14262969#comment-14262969
]
Alexander S. commented on SOLR-6494:
Correct, and that's exactly my case, because the time is entered by users and
differ between queries. I'd love to have something like this working with the
standard query parser:
{code}
fq={!cache=false cost=101}field:value
{code}
It seems that `cache=false` does actually work, but `cost` doesn't (some
parsers, like the frange one, do threat and apply all queries with the `cost`
higher than 100 as post filters).
Query filters applied in a wrong order
--
Key: SOLR-6494
URL: https://issues.apache.org/jira/browse/SOLR-6494
Project: Solr
Issue Type: Bug
Affects Versions: 4.8.1
Reporter: Alexander S.
This query:
{code}
{
fq: [type:Award::Nomination],
sort: score desc,
start: 0,
rows: 20,
q: *:*
}
{code}
takes just a few milliseconds, but this one:
{code}
{
fq: [
type:Award::Nomination,
created_at_d:[* TO 2014-09-08T23:59:59Z]
],
sort: score desc,
start: 0,
rows: 20,
q: *:*
}
{code}
takes almost 15 seconds.
I have just ≈12k of documents with type Award::Nomination, but around half
a billion with created_at_d field set. And it seems Solr applies the
created_at_d filter first going through all documents where this field is
set, which is not very smart.
I think if it can't do anything better than applying filters in the alphabet
order it should apply them in the order they were received.
--
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-6156) StackOverFlow error during parsing of a request
[ https://issues.apache.org/jira/browse/LUCENE-6156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14262959#comment-14262959 ] Robert Muir commented on LUCENE-6156: - Can you supply the regular expression? StackOverFlow error during parsing of a request --- Key: LUCENE-6156 URL: https://issues.apache.org/jira/browse/LUCENE-6156 Project: Lucene - Core Issue Type: Bug Components: core/queryparser Affects Versions: 4.10.2 Environment: windows 2008, osx yosemite with java 1.7.0_60 Reporter: Aurelien PISU Priority: Critical during parsing of a query send to lucene via elasticSearch 1.4.2, i encounter that stackOverFlow exception on RegExp. here the stack trace Caused by: java.lang.StackOverflowError at java.util.BitSet.(BitSet.java:154) at org.apache.lucene.util.automaton.Automaton.(Automaton.java:75) at org.apache.lucene.util.automaton.Automata.makeString(Automata.java:273) at org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:518) at org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:553) at org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:550) at org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:551) at org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:551) Note : the regular expression is quite large and contains only ascii character and '|' character. let me know, If you need the value of the regular expression. This issue was firstly raise to elastic search component on github that use the 4.10.2 version of lucene and identify as a lucene issue. -- 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] (LUCENE-6156) StackOverFlow error during parsing of a request
Aurelien PISU created LUCENE-6156: - Summary: StackOverFlow error during parsing of a request Key: LUCENE-6156 URL: https://issues.apache.org/jira/browse/LUCENE-6156 Project: Lucene - Core Issue Type: Bug Components: core/queryparser Affects Versions: 4.10.2 Environment: windows 2008, osx yosemite with java 1.7.0_60 Reporter: Aurelien PISU Priority: Critical during parsing of a query send to lucene via elasticSearch 1.4.2, i encounter that stackOverFlow exception on RegExp. here the stack trace Caused by: java.lang.StackOverflowError at java.util.BitSet.(BitSet.java:154) at org.apache.lucene.util.automaton.Automaton.(Automaton.java:75) at org.apache.lucene.util.automaton.Automata.makeString(Automata.java:273) at org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:518) at org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:553) at org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:550) at org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:551) at org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:551) Note : the regular expression is quite large and contains only ascii character and '|' character. let me know, If you need the value of the regular expression. This issue was firstly raise to elastic search component on github that use the 4.10.2 version of lucene and identify as a lucene issue. -- 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-6905) Test pseudo-field retrieval in distributed search
Ramkumar Aiyengar created SOLR-6905:
---
Summary: Test pseudo-field retrieval in distributed search
Key: SOLR-6905
URL: https://issues.apache.org/jira/browse/SOLR-6905
Project: Solr
Issue Type: Improvement
Components: Tests
Reporter: Ramkumar Aiyengar
Priority: Minor
Add a few trivial tests to search for pseudo field retrieval with distributed
search, currently only non-distrib is tested with {{TestPseudoReturnFields}}.
Currently the only place which kinda trips it (unintentionally) if you muck
with the distributed part of it alone is a test in
{{TermVectorComponentDistributedTest}}.
--
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-6157) Add the ability to compute fine-grained statistics on the filter cache
[ https://issues.apache.org/jira/browse/LUCENE-6157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14263190#comment-14263190 ] Adrien Grand commented on LUCENE-6157: -- That would be nice as core keys don't cary any meaning but it felt a bit awkward to implement. For instance, when we evict a filter in order to clear up some space, we don't have a reference to a LeafReader available. So we would need the per-leaf cache to keep a reference to the first used LeafReader and use this instance when performing evictions. But then it means that we might give a reference to a closed LeafReader (if the original leaf reader was closed but there is still another LeafReader sharing the same core because of eg. deletions) in these callbacks? Would it be ok? Add the ability to compute fine-grained statistics on the filter cache -- Key: LUCENE-6157 URL: https://issues.apache.org/jira/browse/LUCENE-6157 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Attachments: LUCENE-6157.patch The filter cache exposes some useful statistics about its usage, eg. hit count, eviction count, etc. In some cases it could be useful to give users the ability to compute finer-grained statistics though, for example by breaking up statistics by segment, index or by type of filter. -- 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-6616) Make shards.tolerant and timeAllowed work together
[
https://issues.apache.org/jira/browse/SOLR-6616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14263191#comment-14263191
]
Yonik Seeley commented on SOLR-6616:
bq. However, I think we should start returning the error and return partial
results only when shards.tolerant is set to true.
+1
Make shards.tolerant and timeAllowed work together
--
Key: SOLR-6616
URL: https://issues.apache.org/jira/browse/SOLR-6616
Project: Solr
Issue Type: Bug
Reporter: Anshum Gupta
Assignee: Anshum Gupta
Attachments: SOLR-6616.patch
From SOLR-5986:
{quote}
As of now, when timeAllowed is set, we never get back an exception but just
partialResults in the response header is set to true in case of a shard
failure. This translates to shards.tolerant being ignored in that case.
On the code level, the TimeExceededException never reaches ShardHandler and
so the Exception is never set (similarly for ExitingReaderException) and/or
returned to the client.
{quote}
--
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-6906) Fix typo bug in DistributedDebugComponentTest.testCompareWithNonDistributedRequest
[ https://issues.apache.org/jira/browse/SOLR-6906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-6906. -- Resolution: Fixed Fix Version/s: Trunk 5.0 Thanks Ramkumar! Fix typo bug in DistributedDebugComponentTest.testCompareWithNonDistributedRequest -- Key: SOLR-6906 URL: https://issues.apache.org/jira/browse/SOLR-6906 Project: Solr Issue Type: Bug Components: Tests Reporter: Ramkumar Aiyengar Assignee: Erick Erickson Priority: Minor Fix For: 5.0, Trunk Was making those two lines of the test effectively useless.. -- 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-6906) Fix typo bug in DistributedDebugComponentTest.testCompareWithNonDistributedRequest
[ https://issues.apache.org/jira/browse/SOLR-6906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14263201#comment-14263201 ] ASF subversion and git services commented on SOLR-6906: --- Commit 1649109 from [~erickoerickson] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1649109 ] SOLR-6906: Fix typo bug in DistributedDebugComponentTest.testCompareWithNonDistributedRequest Fix typo bug in DistributedDebugComponentTest.testCompareWithNonDistributedRequest -- Key: SOLR-6906 URL: https://issues.apache.org/jira/browse/SOLR-6906 Project: Solr Issue Type: Bug Components: Tests Reporter: Ramkumar Aiyengar Assignee: Erick Erickson Priority: Minor Fix For: 5.0, Trunk Was making those two lines of the test effectively useless.. -- 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-6905) Test pseudo-field retrieval in distributed search
[
https://issues.apache.org/jira/browse/SOLR-6905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14263205#comment-14263205
]
ASF subversion and git services commented on SOLR-6905:
---
Commit 1649112 from sha...@apache.org in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1649112 ]
SOLR-6905: Test pseudo-field retrieval in distributed search
Test pseudo-field retrieval in distributed search
-
Key: SOLR-6905
URL: https://issues.apache.org/jira/browse/SOLR-6905
Project: Solr
Issue Type: Improvement
Components: Tests
Reporter: Ramkumar Aiyengar
Assignee: Shalin Shekhar Mangar
Priority: Minor
Fix For: 5.0, Trunk
Add a few trivial tests to search for pseudo field retrieval with distributed
search, currently only non-distrib is tested with {{TestPseudoReturnFields}}.
Currently the only place which kinda trips it (unintentionally) if you muck
with the distributed part of it alone is a test in
{{TermVectorComponentDistributedTest}}.
--
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-6905) Test pseudo-field retrieval in distributed search
[
https://issues.apache.org/jira/browse/SOLR-6905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14263203#comment-14263203
]
ASF subversion and git services commented on SOLR-6905:
---
Commit 1649110 from sha...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1649110 ]
SOLR-6905: Test pseudo-field retrieval in distributed search
This closes #122.
Test pseudo-field retrieval in distributed search
-
Key: SOLR-6905
URL: https://issues.apache.org/jira/browse/SOLR-6905
Project: Solr
Issue Type: Improvement
Components: Tests
Reporter: Ramkumar Aiyengar
Assignee: Shalin Shekhar Mangar
Priority: Minor
Add a few trivial tests to search for pseudo field retrieval with distributed
search, currently only non-distrib is tested with {{TestPseudoReturnFields}}.
Currently the only place which kinda trips it (unintentionally) if you muck
with the distributed part of it alone is a test in
{{TermVectorComponentDistributedTest}}.
--
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-6905) Test pseudo-field retrieval in distributed search
[
https://issues.apache.org/jira/browse/SOLR-6905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14263217#comment-14263217
]
ASF GitHub Bot commented on SOLR-6905:
--
Github user asfgit closed the pull request at:
https://github.com/apache/lucene-solr/pull/122
Test pseudo-field retrieval in distributed search
-
Key: SOLR-6905
URL: https://issues.apache.org/jira/browse/SOLR-6905
Project: Solr
Issue Type: Improvement
Components: Tests
Reporter: Ramkumar Aiyengar
Assignee: Shalin Shekhar Mangar
Priority: Minor
Fix For: 5.0, Trunk
Add a few trivial tests to search for pseudo field retrieval with distributed
search, currently only non-distrib is tested with {{TestPseudoReturnFields}}.
Currently the only place which kinda trips it (unintentionally) if you muck
with the distributed part of it alone is a test in
{{TermVectorComponentDistributedTest}}.
--
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-6905) Test pseudo-field retrieval in distributed search
[
https://issues.apache.org/jira/browse/SOLR-6905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar resolved SOLR-6905.
-
Resolution: Fixed
Fix Version/s: Trunk
5.0
Thanks Ramkumar!
Test pseudo-field retrieval in distributed search
-
Key: SOLR-6905
URL: https://issues.apache.org/jira/browse/SOLR-6905
Project: Solr
Issue Type: Improvement
Components: Tests
Reporter: Ramkumar Aiyengar
Assignee: Shalin Shekhar Mangar
Priority: Minor
Fix For: 5.0, Trunk
Add a few trivial tests to search for pseudo field retrieval with distributed
search, currently only non-distrib is tested with {{TestPseudoReturnFields}}.
Currently the only place which kinda trips it (unintentionally) if you muck
with the distributed part of it alone is a test in
{{TermVectorComponentDistributedTest}}.
--
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-6157) Add the ability to compute fine-grained statistics on the filter cache
[ https://issues.apache.org/jira/browse/LUCENE-6157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14263200#comment-14263200 ] Robert Muir commented on LUCENE-6157: - yeah, lets stick with the cache key. Add the ability to compute fine-grained statistics on the filter cache -- Key: LUCENE-6157 URL: https://issues.apache.org/jira/browse/LUCENE-6157 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Attachments: LUCENE-6157.patch The filter cache exposes some useful statistics about its usage, eg. hit count, eviction count, etc. In some cases it could be useful to give users the ability to compute finer-grained statistics though, for example by breaking up statistics by segment, index or by type of filter. -- 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-6906) Fix typo bug in DistributedDebugComponentTest.testCompareWithNonDistributedRequest
[ https://issues.apache.org/jira/browse/SOLR-6906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14263197#comment-14263197 ] ASF subversion and git services commented on SOLR-6906: --- Commit 1649106 from [~erickoerickson] in branch 'dev/trunk' [ https://svn.apache.org/r1649106 ] SOLR-6906: Fix typo bug in DistributedDebugComponentTest.testCompareWithNonDistributedRequest Fix typo bug in DistributedDebugComponentTest.testCompareWithNonDistributedRequest -- Key: SOLR-6906 URL: https://issues.apache.org/jira/browse/SOLR-6906 Project: Solr Issue Type: Bug Components: Tests Reporter: Ramkumar Aiyengar Assignee: Erick Erickson Priority: Minor Was making those two lines of the test effectively useless.. -- 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
[GitHub] lucene-solr pull request: Test pseudo-field retrieval in distribut...
Github user asfgit closed the pull request at: https://github.com/apache/lucene-solr/pull/122 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.9.0-ea-b34) - Build # 11673 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11673/
Java: 32bit/jdk1.9.0-ea-b34 -client -XX:+UseG1GC (asserts: true)
1 tests failed.
FAILED: org.apache.solr.handler.TestSolrConfigHandlerCloud.testDistribSearch
Error Message:
Could not get expected value P val for path [response, params, y, p] full
output { responseHeader:{ status:0, QTime:0}, response:{
znodeVersion:1, params:{ x:{ a:A val,
b:B val, :{v:0}}, y:{ c:CY val,
b:BY val, :{v:0}
Stack Trace:
java.lang.AssertionError: Could not get expected value P val for path
[response, params, y, p] full output {
responseHeader:{
status:0,
QTime:0},
response:{
znodeVersion:1,
params:{
x:{
a:A val,
b:B val,
:{v:0}},
y:{
c:CY val,
b:BY val,
:{v:0}
at
__randomizedtesting.SeedInfo.seed([342316537B6E926C:B5C5984B0C31F250]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:231)
at
org.apache.solr.handler.TestSolrConfigHandlerCloud.testReqParams(TestSolrConfigHandlerCloud.java:253)
at
org.apache.solr.handler.TestSolrConfigHandlerCloud.doTest(TestSolrConfigHandlerCloud.java:61)
at
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:868)
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: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:365)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
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
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
[JENKINS] Lucene-Solr-NightlyTests-5.x - Build # 722 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/722/ 1 tests failed. REGRESSION: org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testDistribSearch Error Message: Error from server at https://127.0.0.1:62231/q_e/o: java.lang.NullPointerException Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at https://127.0.0.1:62231/q_e/o: java.lang.NullPointerException at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:558) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:214) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:210) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testErrorHandling(CollectionsAPIDistributedZkTest.java:449) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:201) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:868) 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:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) 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 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at
[jira] [Commented] (SOLR-6367) empty tolg on HDFS when hard crash - no docs to replay on recovery
[
https://issues.apache.org/jira/browse/SOLR-6367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14263302#comment-14263302
]
Venkata Praneeth Varma Gottumukkala commented on SOLR-6367:
---
This is because of a bug
[here|https://github.com/apache/lucene-solr/blob/lucene_solr_4_10_3/solr/core/src/java/org/apache/solr/update/HdfsTransactionLog.java#L276]
in the HdfsTransactionLog. The call {{fos.flushBuffer()}} should be
{{fos.flush()}}. {{flushBuffer()}} in the underlying {{FastOutputStream}} does
not actually flush. I could have taken up the task of making the minor change
but I haven't contributed before and do not know the process.
empty tolg on HDFS when hard crash - no docs to replay on recovery
--
Key: SOLR-6367
URL: https://issues.apache.org/jira/browse/SOLR-6367
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Filing this bug based on an email to solr-user@lucene from Tom Chen (Fri, 18
Jul 2014)...
{panel}
Reproduce steps:
1) Setup Solr to run on HDFS like this:
{noformat}
java -Dsolr.directoryFactory=HdfsDirectoryFactory
-Dsolr.lock.type=hdfs
-Dsolr.hdfs.home=hdfs://host:port/path
{noformat}
For the purpose of this testing, turn off the default auto commit in
solrconfig.xml, i.e. comment out autoCommit like this:
{code}
!--
autoCommit
maxTime${solr.autoCommit.maxTime:15000}/maxTime
openSearcherfalse/openSearcher
/autoCommit
--
{code}
2) Add a document without commit:
{{curl http://localhost:8983/solr/collection1/update?commit=false; -H
Content-type:text/xml; charset=utf-8 --data-binary @solr.xml}}
3) Solr generate empty tlog file (0 file size, the last one ends with 6):
{noformat}
[hadoop@hdtest042 exampledocs]$ hadoop fs -ls
/path/collection1/core_node1/data/tlog
Found 5 items
-rw-r--r-- 1 hadoop hadoop667 2014-07-18 08:47
/path/collection1/core_node1/data/tlog/tlog.001
-rw-r--r-- 1 hadoop hadoop 67 2014-07-18 08:47
/path/collection1/core_node1/data/tlog/tlog.003
-rw-r--r-- 1 hadoop hadoop667 2014-07-18 08:47
/path/collection1/core_node1/data/tlog/tlog.004
-rw-r--r-- 1 hadoop hadoop 0 2014-07-18 09:02
/path/collection1/core_node1/data/tlog/tlog.005
-rw-r--r-- 1 hadoop hadoop 0 2014-07-18 09:02
/path/collection1/core_node1/data/tlog/tlog.006
{noformat}
4) Simulate Solr crash by killing the process with -9 option.
5) restart the Solr process. Observation is that uncommitted document are
not replayed, files in tlog directory are cleaned up. Hence uncommitted
document(s) is lost.
Am I missing anything or this is a bug?
BTW, additional observations:
a) If in step 4) Solr is stopped gracefully (i.e. without -9 option),
non-empty tlog file is geneated and after re-starting Solr, uncommitted
document is replayed as expected.
b) If Solr doesn't run on HDFS (i.e. on local file system), this issue is
not observed either.
{panel}
--
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-6149) Infix suggesters' highlighting, allTermsRequired options are hardwired and not configurable for non-contextual lookup
[
https://issues.apache.org/jira/browse/LUCENE-6149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14263308#comment-14263308
]
Tomás Fernández Löbbe commented on LUCENE-6149:
---
[~boonious], could you update the patch to a recent version of trunk? Also,
could you add javadocs to the newly added constructors?
Infix suggesters' highlighting, allTermsRequired options are hardwired and
not configurable for non-contextual lookup
-
Key: LUCENE-6149
URL: https://issues.apache.org/jira/browse/LUCENE-6149
Project: Lucene - Core
Issue Type: Improvement
Components: modules/other
Affects Versions: 4.9, 4.10.1, 4.10.2, 4.10.3
Reporter: Boon Low
Assignee: Tomás Fernández Löbbe
Priority: Minor
Labels: suggester
Fix For: 5.0, Trunk
Attachments: LUCENE-6149.patch
Highlighting and allTermsRequired are hardwired in _AnalyzingInfixSuggester_
for non-contextual lookup (via _Lookup_) see *true*, *true* below:
{code:title=AnalyzingInfixSuggester.java (extends Lookup.java) }
public ListLookupResult lookup(CharSequence key, SetBytesRef contexts,
boolean onlyMorePopular, int num) throws IOException {
return lookup(key, contexts, num, true, true);
}
/** Lookup, without any context. */
public ListLookupResult lookup(CharSequence key, int num, boolean
allTermsRequired, boolean doHighlight) throws IOException {
return lookup(key, null, num, allTermsRequired, doHighlight);
}
{code}
{code:title=Lookup.java}
public ListLookupResult lookup(CharSequence key, boolean onlyMorePopular,
int num) throws IOException {
return lookup(key, null, onlyMorePopular, num);
}
{code}
The above means the majority of the current infix suggester lookup always
return highlighted results with allTermsRequired in effect. There is no way
to change this despite the options and improvement of LUCENE-6050, made to
incorporate Boolean lookup clauses (MUST/SHOULD). This shortcoming has also
been reported in SOLR-6648.
The suggesters (AnalyzingInfixSuggester, BlendedInfixSuggester) should
provide a proper mechanism to set defaults for highlighting and
allTermsRequired, e.g. in constructors (and in Solr factories, thus
configurable via solrconfig.xml).
--
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-6581) Prepare CollapsingQParserPlugin and ExpandComponent for 5.0
[
https://issues.apache.org/jira/browse/SOLR-6581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-6581:
-
Attachment: SOLR-6581.patch
Prepare CollapsingQParserPlugin and ExpandComponent for 5.0
---
Key: SOLR-6581
URL: https://issues.apache.org/jira/browse/SOLR-6581
Project: Solr
Issue Type: Bug
Reporter: Joel Bernstein
Assignee: Joel Bernstein
Priority: Minor
Fix For: 5.0
Attachments: SOLR-6581.patch, SOLR-6581.patch, SOLR-6581.patch,
SOLR-6581.patch, SOLR-6581.patch, SOLR-6581.patch, renames.diff
*Background*
The 4x implementation of the CollapsingQParserPlugin and the ExpandComponent
are optimized to work with a top level FieldCache. Top level FieldCaches have
a very fast docID to top-level ordinal lookup. Fast access to the top-level
ordinals allows for very high performance field collapsing on high
cardinality fields.
LUCENE-5666 unified the DocValues and FieldCache api's so that the top level
FieldCache is no longer in regular use. Instead all top level caches are
accessed through MultiDocValues.
There are some major advantages of using the MultiDocValues rather then a top
level FieldCache. But there is one disadvantage, the lookup from docId to
top-level ordinals is slower using MultiDocValues.
My testing has shown that *after optimizing* the CollapsingQParserPlugin code
to use MultiDocValues, the performance drop is around 100%. For some use
cases this performance drop is a blocker.
*What About Faceting?*
String faceting also relies on the top level ordinals. Is faceting
performance affected also? My testing has shown that the faceting performance
is affected much less then collapsing.
One possible reason for this may be that field collapsing is memory bound and
faceting is not. So the additional memory accesses needed for MultiDocValues
affects field collapsing much more then faceting.
*Proposed Solution*
The proposed solution is to have the default Collapse and Expand algorithm
use MultiDocValues, but to provide an option to use a top level FieldCache if
the performance of MultiDocValues is a blocker.
The proposed mechanism for switching to the FieldCache would be a new hint
parameter. If the hint parameter is set to FAST_QUERY then the top-level
FieldCache would be used for both Collapse and Expand.
Example syntax:
{code}
fq={!collapse field=x hint=FAST_QUERY}
{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
UUIDUpdateProcessorFactory causes repeated documents when uploading csv files?
Happy New Year Everyone :) I am trying to automatically generate document Id when indexing a csv file that contains multiple lines of documents. The desired case: if the csv file contains 2 lines (each line is a document), then the index should contain 2 documents. What I observed: If the csv files contains 2 lines, then the index contains 3 documents, because the 1st document is repeated once, an example output: doc sr name =col1 doc1 /str sr name= col2 rank1 /str str name=id randomlyGeneratedId1/str /doc doc sr name =col1 doc1 /str sr name= col2 rank1 /str str name=id randomlyGeneratedId2/str /doc doc sr name =col1 doc2 /str sr name= col2 rank2 /str str name=id randomlyGeneratedId3/str /doc And if the csv file contains 3 lines, then the index contains 6 elements, because document 1 is repeated 3 times and document 2 is repeated twice, as following: doc sr name =col1 doc1 /str sr name= col2 rank1 /str str name=id randomlyGeneratedId1/str /doc doc sr name =col1 doc1 /str sr name= col2 rank1 /str str name=id randomlyGeneratedId2/str /doc doc sr name =col1 doc2 /str sr name= col2 rank2 /str str name=id randomlyGeneratedId3/str doc sr name =col1 doc1 /str sr name= col2 rank1 /str str name=id randomlyGeneratedId4/str /doc doc sr name =col1 doc2 /str sr name= col2 rank2 /str str name=id randomlyGeneratedId5/str /doc doc sr name =col1 doc3 /str sr name= col2 rank3 /str str name=id randomlyGeneratedId6/str /doc Here's what I have done: 1. In my solrConfig: updateRequestProcessorChain name=autoGenId processor class=solr.UUIDUpdateProcessorFactory str name=fieldNamedoc_key/str /processor processor class=solr.LogUpdateProcessorFactory / processor class=solr.RunUpdateProcessorFactory / /updateRequestProcessorChain requestHandler name=/update class=solr.UpdateRequestHandler lst name=defaults str name=update.chainautoGenId/str /lst /requestHandler 2. in schema.xml: field name=doc_key type=string indexed=true stored=true required=true multiValued=false/ field name = col1 type=string indexed=true stored=true required=true multiValued=false/ field name = col2 type=string indexed=true stored=true required=true multiValued=false/ uniqueKeyid/uniqueKey This problem doesn't exist when I assign an Id field, instead of using the UUIDUpdateProcessorFactory, so I assumed the problem is there? Looks like the csv file is processed one line at a time, and the index shows the entire process: so we see each previous line repeated in the output. Is there a way to not show the 'appending of previous lines', and rather just the 'final results' - so the total number of indexed document would match the input number of documents from the csv file? Many thanks, Jia - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5507) Admin UI - Refactoring using AngularJS
[ https://issues.apache.org/jira/browse/SOLR-5507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14263256#comment-14263256 ] Upayavira commented on SOLR-5507: - Connection lost functionality implemented. It intercepts errors on all HTTP requests, and shows a connection lost dialog. It continues to retry, until, when it succeeds, shows a connection recovered message and then proceeds where it left off. loading functionality is there in the backend, and shows ugly on the front end. I'd appreciate ideas as to how to show that we are loading some data. I've got a spinning circle (see the logging page), but am not yet sure where to put it! http errors - non-timeouts should give an error message at the top of the page with a red 'exception' heading. Unlike pretty much everything else I've done, this is new code, not a simple refactoring of the existing, so I would appreciate some folks trying it out. Kill Solr - restart it, make Solr return http errors, see if they display well. Admin UI - Refactoring using AngularJS -- Key: SOLR-5507 URL: https://issues.apache.org/jira/browse/SOLR-5507 Project: Solr Issue Type: Improvement Components: web gui Reporter: Stefan Matheis (steffkes) Assignee: Stefan Matheis (steffkes) Priority: Minor Attachments: SOLR-5507.patch On the LSR in Dublin, i've talked again to [~upayavira] and this time we talked about Refactoring the existing UI - using AngularJS: providing (more, internal) structure and what not ; He already started working on the Refactoring, so this is more a 'tracking' issue about the progress he/we do there. Will extend this issue with a bit more context additional information, w/ thoughts about the possible integration in the existing UI and more (: -- 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-5507) Admin UI - Refactoring using AngularJS
[ https://issues.apache.org/jira/browse/SOLR-5507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Upayavira updated SOLR-5507: Attachment: SOLR5507.patch Attached a patch, against branch_5x when this project started (a few weeks ago). Created in git, I believe will apply to SVN checkout with: cd $workspace/solr/webapp/web patch -p0 SOLR5507.patch Admin UI - Refactoring using AngularJS -- Key: SOLR-5507 URL: https://issues.apache.org/jira/browse/SOLR-5507 Project: Solr Issue Type: Improvement Components: web gui Reporter: Stefan Matheis (steffkes) Assignee: Stefan Matheis (steffkes) Priority: Minor Attachments: SOLR-5507.patch, SOLR5507.patch On the LSR in Dublin, i've talked again to [~upayavira] and this time we talked about Refactoring the existing UI - using AngularJS: providing (more, internal) structure and what not ; He already started working on the Refactoring, so this is more a 'tracking' issue about the progress he/we do there. Will extend this issue with a bit more context additional information, w/ thoughts about the possible integration in the existing UI and more (: -- 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-6874) There is a race around SocketProxy binding to it's port the way we setup JettySolrRunner and SocketProxy.
[ https://issues.apache.org/jira/browse/SOLR-6874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14263317#comment-14263317 ] Shalin Shekhar Mangar commented on SOLR-6874: - +1 to commit. This resolves the failures seen in SOLR-4839 as well. There is a race around SocketProxy binding to it's port the way we setup JettySolrRunner and SocketProxy. - Key: SOLR-6874 URL: https://issues.apache.org/jira/browse/SOLR-6874 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Attachments: SOLR-6874.patch I ran into this while working on SOLR-4509 and have a fix there in my latest patch. Because we get an available port by opening and closing a scocket on port 0 and then try to use it again with the SocketProxy, sometimes it fails to bind and the test can fail. We can change the code a bit so that the SocketProxy itself can start on port 0 rather than this two step fragile process. -- 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-trunk-MacOSX (64bit/jdk1.8.0) - Build # 2030 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2030/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC (asserts: false) 1 tests failed. FAILED: org.apache.solr.TestHighlightDedupGrouping.testDistribSearch Error Message: Timeout occured while waiting response from server at: https://127.0.0.1:49340 Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: https://127.0.0.1:49340 at __randomizedtesting.SeedInfo.seed([7311205B95A03674:F2F7AE43E2FF5648]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:570) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:214) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:210) at org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:124) at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:117) at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:103) at org.apache.solr.TestHighlightDedupGrouping.addDoc(TestHighlightDedupGrouping.java:127) at org.apache.solr.TestHighlightDedupGrouping.randomizedTest(TestHighlightDedupGrouping.java:101) at org.apache.solr.TestHighlightDedupGrouping.doTest(TestHighlightDedupGrouping.java:47) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:868) 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:483) 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:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) 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 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[JENKINS] Lucene-Solr-4.10-Linux (64bit/jdk1.8.0_40-ea-b09) - Build # 203 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.10-Linux/203/ Java: 64bit/jdk1.8.0_40-ea-b09 -XX:-UseCompressedOops -XX:+UseParallelGC (asserts: true) 1 tests failed. FAILED: org.apache.solr.client.solrj.TestLBHttpSolrServer.testReliability Error Message: IOException occured when talking to server at: https://127.0.0.1:59966/solr Stack Trace: org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: https://127.0.0.1:59966/solr at __randomizedtesting.SeedInfo.seed([A6EBD026F95E3F03:67230D605838EEAA]:0) at org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:567) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:210) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:206) at org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:124) at org.apache.solr.client.solrj.SolrServer.commit(SolrServer.java:168) at org.apache.solr.client.solrj.SolrServer.commit(SolrServer.java:146) at org.apache.solr.client.solrj.TestLBHttpSolrServer.addDocs(TestLBHttpSolrServer.java:115) at org.apache.solr.client.solrj.TestLBHttpSolrServer.setUp(TestLBHttpSolrServer.java:98) at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:861) 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.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) 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:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) 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 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at
Re: Randomized testing talk (your favorite moment)
Hi Rory, It's a local (?) one-day event/ conference here in my home town: http://2015.tdd.geecon.org/ Dawid On Fri, Jan 2, 2015 at 10:38 AM, Rory O'Donnell rory.odonn...@oracle.com wrote: Hi Dawid, I would love to hear more about randomized testing, where are you giving the talk ? Rgds,Rory On 02/01/2015 09:00, Dawid Weiss wrote: Hi everyone! I am giving a talk about randomized testing in a month or so and I thought it'd be cool to share some real-life ah-crap, gotcha, wtf moments related to the bugs discovered by randomized testing. My personal favorite is LUCENE-5168 (g1gc/ impossible code path) which, by the way, is still unresolved and we have no idea how to reproduce it reliably. Another is one of Robert's bugs with Unicode where he debugged what seemed like a megabutt of crazy-hairy random unicode that triggered the problem. These sorts of things. You can reply to the list or to my prv. e-mail if you wish. Dawid P.S. The talk's abstract is below here. Randomized Testing: When a Monkey Can do Better than Human. The talk will take a look at the concept of writing (unit) tests with predictable randomness. We will try to generalize: describe what such tests are, how to write them and how randomized testing can help in finding bugs in otherwise deterministic routines. We will also try to demonstrate on real-life examples that human understanding and predictions with regard to software are typically, ehm, incorrect (the same applies to mice and towels, see: THGTTG for full explanation). Randomized testing has been used extensively in Apache Lucene, Solr and ElasticSearch. Developers generally love it because it's effective at finding bugs and hate it when the bugs it finds are theirs to debug. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Randomized testing talk (your favorite moment)
Hi Dawid, I would love to hear more about randomized testing, where are you giving the talk ? Rgds,Rory On 02/01/2015 09:00, Dawid Weiss wrote: Hi everyone! I am giving a talk about randomized testing in a month or so and I thought it'd be cool to share some real-life ah-crap, gotcha, wtf moments related to the bugs discovered by randomized testing. My personal favorite is LUCENE-5168 (g1gc/ impossible code path) which, by the way, is still unresolved and we have no idea how to reproduce it reliably. Another is one of Robert's bugs with Unicode where he debugged what seemed like a megabutt of crazy-hairy random unicode that triggered the problem. These sorts of things. You can reply to the list or to my prv. e-mail if you wish. Dawid P.S. The talk's abstract is below here. Randomized Testing: When a Monkey Can do Better than Human. The talk will take a look at the concept of writing (unit) tests with predictable randomness. We will try to generalize: describe what such tests are, how to write them and how randomized testing can help in finding bugs in otherwise deterministic routines. We will also try to demonstrate on real-life examples that human understanding and predictions with regard to software are typically, ehm, incorrect (the same applies to mice and towels, see: THGTTG for full explanation). Randomized testing has been used extensively in Apache Lucene, Solr and ElasticSearch. Developers generally love it because it's effective at finding bugs and hate it when the bugs it finds are theirs to debug. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Randomized testing talk (your favorite moment)
Hi everyone! I am giving a talk about randomized testing in a month or so and I thought it'd be cool to share some real-life ah-crap, gotcha, wtf moments related to the bugs discovered by randomized testing. My personal favorite is LUCENE-5168 (g1gc/ impossible code path) which, by the way, is still unresolved and we have no idea how to reproduce it reliably. Another is one of Robert's bugs with Unicode where he debugged what seemed like a megabutt of crazy-hairy random unicode that triggered the problem. These sorts of things. You can reply to the list or to my prv. e-mail if you wish. Dawid P.S. The talk's abstract is below here. Randomized Testing: When a Monkey Can do Better than Human. The talk will take a look at the concept of writing (unit) tests with predictable randomness. We will try to generalize: describe what such tests are, how to write them and how randomized testing can help in finding bugs in otherwise deterministic routines. We will also try to demonstrate on real-life examples that human understanding and predictions with regard to software are typically, ehm, incorrect (the same applies to mice and towels, see: THGTTG for full explanation). Randomized testing has been used extensively in Apache Lucene, Solr and ElasticSearch. Developers generally love it because it's effective at finding bugs and hate it when the bugs it finds are theirs to debug. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_20) - Build # 11839 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11839/
Java: 64bit/jdk1.8.0_20 -XX:-UseCompressedOops -XX:+UseG1GC (asserts: false)
1 tests failed.
FAILED: org.apache.solr.core.TestDynamicLoading.testDistribSearch
Error Message:
{ responseHeader:{ status:404, QTime:5}, error:{
msg:no such blob or version available: test/1, code:404}}
Stack Trace:
java.lang.AssertionError: {
responseHeader:{
status:404,
QTime:5},
error:{
msg:no such blob or version available: test/1,
code:404}}
at
__randomizedtesting.SeedInfo.seed([A9F643A9FE512D91:2810CDB1890E4DAD]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at
org.apache.solr.core.TestDynamicLoading.dynamicLoading(TestDynamicLoading.java:108)
at
org.apache.solr.core.TestDynamicLoading.doTest(TestDynamicLoading.java:64)
at
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:868)
at sun.reflect.GeneratedMethodAccessor39.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
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:365)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
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
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at
[jira] [Commented] (LUCENE-5873) AssertionError in ToChildBlockJoinScorer.advance
[
https://issues.apache.org/jira/browse/LUCENE-5873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14262981#comment-14262981
]
ASF subversion and git services commented on LUCENE-5873:
-
Commit 1649073 from [~jpountz] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1649073 ]
LUCENE-5873: BJQ: Throw an error if the top-level filter is not in the child
space instead of just asserting.
AssertionError in ToChildBlockJoinScorer.advance
Key: LUCENE-5873
URL: https://issues.apache.org/jira/browse/LUCENE-5873
Project: Lucene - Core
Issue Type: Bug
Reporter: Varun Thacker
Priority: Minor
Attachments: LUCENE-5873.patch, LUCENE-5873.patch
When using ToChildBJQ and searching via IndexSearcher.search(Query query,
Filter filter, int n) if we provide a filter which matches both parent and
child documents we get this error
{noformat}
java.lang.AssertionError
at
__randomizedtesting.SeedInfo.seed([C346722DC1E4810C:A08F176AE828FA1D]:0)
at
org.apache.lucene.search.join.ToChildBlockJoinQuery$ToChildBlockJoinScorer.advance(ToChildBlockJoinQuery.java:286)
at
org.apache.lucene.search.FilteredQuery$LeapFrogScorer.advanceToNextCommonDoc(FilteredQuery.java:274)
at
org.apache.lucene.search.FilteredQuery$LeapFrogScorer.nextDoc(FilteredQuery.java:286)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:192)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:163)
at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:614)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:483)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:440)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
at
org.apache.lucene.search.join.TestBlockJoinValidation.testValidationForToChildBjqWithChildFilterQuery(TestBlockJoinValidation.java:124)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
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
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
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:365)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
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
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] [Closed] (SOLR-5857) StatsComponent returns invalid string representation in facets
[ https://issues.apache.org/jira/browse/SOLR-5857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson closed SOLR-5857. Resolution: Cannot Reproduce I _finally_ got around to trying this in 4.10.3 and in the interval since it was first reported the problem seems to have been fixed, at least I can't make it happen. So closing, we can re-open if it's really a problem. Don't quite know what version it was fixed in though. StatsComponent returns invalid string representation in facets -- Key: SOLR-5857 URL: https://issues.apache.org/jira/browse/SOLR-5857 Project: Solr Issue Type: Bug Reporter: Elran Dvir Assignee: Erick Erickson Attachments: SOLR-5857.patch I have an EnumField called severity. When I run the following query: rows=0q=*:*fq=(severity:Critical OR severity:High)fq=fieldB:[* TO *]fq=severity:[* TO *]stats=truestats.field=fieldBf.fieldB.stats.facet=severity I get the following response: result name=response numFound=1786 start=0/ lst name=stats lst name=stats_fields lst name=fieldB str name=minBej/str str name=maxdmfbsrvftu/str long name=count1786/long long name=missing0/long lst name=facets lst name=severity lst name=`#8;#0;#0;#0;#5; str name=minCfo Qbsbejtf )cfoq@be/difdlqpjou/dpn*!/str str name=maxTiblfe Evobz )tiblfee*!/str long name=count24/long long name=missing0/long lst name=facets/ /lst lst name=`#8;#0;#0;#0;#4; str name=minBej Cbcbj )bejc*!/str str name=maxdmfbsrvftu/str long name=count1762/long long name=missing0/long lst name=facets/ /lst /lst /lst /lst /lst /lst As can be seen, the string representation of severity is invalid So I concluded there is a bug with displaying statscomponent facet value. I attached a patch fixing the bug. It now returns the proper string representation of the term. I think StatsComponent facet value should be the Object itself and not the string representation, similar to all other stats values. (For example, If it's an object, the facet field values can be sorted in case the field is a Number or EnumField) I tried to change it, but statscomponent facet value is FieldStatsInfo's name and it gets it from NamedList element's name. If someone can take a look and fix it, I think it will be great. Thanks. -- 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-6905) Test pseudo-field retrieval in distributed search
[
https://issues.apache.org/jira/browse/SOLR-6905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14262979#comment-14262979
]
ASF GitHub Bot commented on SOLR-6905:
--
GitHub user andyetitmoves opened a pull request:
https://github.com/apache/lucene-solr/pull/122
Test pseudo-field retrieval in distributed search
Patch for https://issues.apache.org/jira/browse/SOLR-6905
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/bloomberg/lucene-solr
trunk-test-pseudo-distrib
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/lucene-solr/pull/122.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #122
commit dee760f4c79f93f77960fef0d2e67ad06c93b9fa
Author: Ramkumar Aiyengar raiyen...@bloomberg.net
Date: 2015-01-02T15:56:24Z
Test pseudo-field retrieval in distributed search
Test pseudo-field retrieval in distributed search
-
Key: SOLR-6905
URL: https://issues.apache.org/jira/browse/SOLR-6905
Project: Solr
Issue Type: Improvement
Components: Tests
Reporter: Ramkumar Aiyengar
Priority: Minor
Add a few trivial tests to search for pseudo field retrieval with distributed
search, currently only non-distrib is tested with {{TestPseudoReturnFields}}.
Currently the only place which kinda trips it (unintentionally) if you muck
with the distributed part of it alone is a test in
{{TermVectorComponentDistributedTest}}.
--
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-6874) There is a race around SocketProxy binding to it's port the way we setup JettySolrRunner and SocketProxy.
[ https://issues.apache.org/jira/browse/SOLR-6874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Potter updated SOLR-6874: - Attachment: SOLR-6874.patch Thanks for fixing this Mark! I needed this to get the hangs resolved for SOLR-4839 so pulled your changes from the other ticket into this patch and added a few changes of my own. There is a race around SocketProxy binding to it's port the way we setup JettySolrRunner and SocketProxy. - Key: SOLR-6874 URL: https://issues.apache.org/jira/browse/SOLR-6874 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Attachments: SOLR-6874.patch I ran into this while working on SOLR-4509 and have a fix there in my latest patch. Because we get an available port by opening and closing a scocket on port 0 and then try to use it again with the SocketProxy, sometimes it fails to bind and the test can fail. We can change the code a bit so that the SocketProxy itself can start on port 0 rather than this two step fragile process. -- 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-5.x-Java7 - Build # 2416 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2416/ All tests passed Build Log: [...truncated 45028 lines...] BUILD FAILED /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/build.xml:529: The following error occurred while executing this line: /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/build.xml:83: The following error occurred while executing this line: /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/lucene/build.xml:134: The following error occurred while executing this line: /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/lucene/build.xml:460: The following error occurred while executing this line: /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/lucene/common-build.xml:2502: Can't get https://issues.apache.org/jira/rest/api/2/project/LUCENE to /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/lucene/build/docs/changes/jiraVersionList.json Total time: 87 minutes 41 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Sending artifact delta relative to Lucene-Solr-Tests-5.x-Java7 #2415 Archived 1 artifacts Archive block size is 32768 Received 0 blocks and 464 bytes Compression is 0.0% Took 0.48 sec Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_40-ea-b09) - Build # 11840 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11840/ Java: 64bit/jdk1.8.0_40-ea-b09 -XX:+UseCompressedOops -XX:+UseG1GC (asserts: true) All tests passed Build Log: [...truncated 58485 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:519: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:83: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build.xml:560: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build.xml:535: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:2422: Can't get https://issues.apache.org/jira/rest/api/2/project/SOLR to /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/docs/changes/jiraVersionList.json Total time: 85 minutes 1 second Build step 'Invoke Ant' marked build as failure [description-setter] Description set: Java: 64bit/jdk1.8.0_40-ea-b09 -XX:+UseCompressedOops -XX:+UseG1GC (asserts: true) Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request: Test pseudo-field retrieval in distribut...
GitHub user andyetitmoves opened a pull request: https://github.com/apache/lucene-solr/pull/122 Test pseudo-field retrieval in distributed search Patch for https://issues.apache.org/jira/browse/SOLR-6905 You can merge this pull request into a Git repository by running: $ git pull https://github.com/bloomberg/lucene-solr trunk-test-pseudo-distrib Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/122.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #122 commit dee760f4c79f93f77960fef0d2e67ad06c93b9fa Author: Ramkumar Aiyengar raiyen...@bloomberg.net Date: 2015-01-02T15:56:24Z Test pseudo-field retrieval in distributed search --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6148) Accountable.getChildResources should return a Collection
[ https://issues.apache.org/jira/browse/LUCENE-6148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14262984#comment-14262984 ] ASF subversion and git services commented on LUCENE-6148: - Commit 1649074 from [~jpountz] in branch 'dev/trunk' [ https://svn.apache.org/r1649074 ] LUCENE-6148: Accountable.getChildResources returns a Collection. Accountable.getChildResources should return a Collection Key: LUCENE-6148 URL: https://issues.apache.org/jira/browse/LUCENE-6148 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Attachments: LUCENE-6148.patch Since the child resources must be a snapshot, their size has to be known anyway so returning a collection instead of an iterable would make consumption easier without introducing limitations. -- 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-6905) Test pseudo-field retrieval in distributed search
[
https://issues.apache.org/jira/browse/SOLR-6905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar reassigned SOLR-6905:
---
Assignee: Shalin Shekhar Mangar
Test pseudo-field retrieval in distributed search
-
Key: SOLR-6905
URL: https://issues.apache.org/jira/browse/SOLR-6905
Project: Solr
Issue Type: Improvement
Components: Tests
Reporter: Ramkumar Aiyengar
Assignee: Shalin Shekhar Mangar
Priority: Minor
Add a few trivial tests to search for pseudo field retrieval with distributed
search, currently only non-distrib is tested with {{TestPseudoReturnFields}}.
Currently the only place which kinda trips it (unintentionally) if you muck
with the distributed part of it alone is a test in
{{TermVectorComponentDistributedTest}}.
--
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-trunk-Windows (32bit/jdk1.8.0_40-ea-b09) - Build # 4529 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4529/ Java: 32bit/jdk1.8.0_40-ea-b09 -client -XX:+UseConcMarkSweepGC (asserts: false) 1 tests failed. FAILED: org.apache.solr.cloud.ReplicationFactorTest.testDistribSearch Error Message: org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: http://127.0.0.1:57564/m_/repfacttest_c8n_1x3_shard1_replica3 Stack Trace: org.apache.solr.client.solrj.SolrServerException: org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: http://127.0.0.1:57564/m_/repfacttest_c8n_1x3_shard1_replica3 at __randomizedtesting.SeedInfo.seed([F553CBCDE4036642:74B545D5935C067E]:0) at org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:581) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:890) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:793) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:736) at org.apache.solr.cloud.ReplicationFactorTest.testRf3(ReplicationFactorTest.java:277) at org.apache.solr.cloud.ReplicationFactorTest.doTest(ReplicationFactorTest.java:123) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:868) 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:497) 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:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) 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 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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)
[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2419 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2419/
1 tests failed.
REGRESSION:
org.apache.solr.handler.TestSolrConfigHandlerCloud.testDistribSearch
Error Message:
Could not get expected value BY val for path [params, b] full output {
responseHeader:{ status:0, QTime:0}, params:{
wt:json, useParams:y}, context:{ webapp:,
httpMethod:GET, path:/dump1}}
Stack Trace:
java.lang.AssertionError: Could not get expected value BY val for path
[params, b] full output {
responseHeader:{
status:0,
QTime:0},
params:{
wt:json,
useParams:y},
context:{
webapp:,
httpMethod:GET,
path:/dump1}}
at
__randomizedtesting.SeedInfo.seed([42E7ABA63F5DBBEA:C30125BE4802DBD6]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:231)
at
org.apache.solr.handler.TestSolrConfigHandlerCloud.testReqParams(TestSolrConfigHandlerCloud.java:197)
at
org.apache.solr.handler.TestSolrConfigHandlerCloud.doTest(TestSolrConfigHandlerCloud.java:61)
at
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:868)
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:365)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
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
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at
Re: [JENKINS] Lucene-Solr-SmokeRelease-5.x - Build # 226 - Still Failing
Mark are you going to add the 4.10.3 back compat indices to
TestBackwardsCompatibility?
Mike McCandless
http://blog.mikemccandless.com
On Fri, Jan 2, 2015 at 9:47 PM, Apache Jenkins Server
jenk...@builds.apache.org wrote:
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.x/226/
No tests ran.
Build Log:
[...truncated 51913 lines...]
prepare-release-no-sign:
[mkdir] Created dir:
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist
[copy] Copying 446 files to
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/lucene
[copy] Copying 245 files to
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/solr
[smoker] Java 1.7 JAVA_HOME=/home/jenkins/tools/java/latest1.7
[smoker] NOTE: output encoding is US-ASCII
[smoker]
[smoker] Load release URL
file:/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/...
[smoker]
[smoker] Test Lucene...
[smoker] test basics...
[smoker] get KEYS
[smoker] 0.1 MB in 0.01 sec (9.7 MB/sec)
[smoker] check changes HTML...
[smoker] download lucene-5.0.0-src.tgz...
[smoker] 27.9 MB in 0.04 sec (678.0 MB/sec)
[smoker] verify md5/sha1 digests
[smoker] download lucene-5.0.0.tgz...
[smoker] 64.0 MB in 0.15 sec (431.2 MB/sec)
[smoker] verify md5/sha1 digests
[smoker] download lucene-5.0.0.zip...
[smoker] 73.5 MB in 0.12 sec (589.9 MB/sec)
[smoker] verify md5/sha1 digests
[smoker] unpack lucene-5.0.0.tgz...
[smoker] verify JAR metadata/identity/no javax.* or java.* classes...
[smoker] test demo with 1.7...
[smoker] got 5631 hits for query lucene
[smoker] checkindex with 1.7...
[smoker] check Lucene's javadoc JAR
[smoker] unpack lucene-5.0.0.zip...
[smoker] verify JAR metadata/identity/no javax.* or java.* classes...
[smoker] test demo with 1.7...
[smoker] got 5631 hits for query lucene
[smoker] checkindex with 1.7...
[smoker] check Lucene's javadoc JAR
[smoker] unpack lucene-5.0.0-src.tgz...
[smoker] make sure no JARs/WARs in src dist...
[smoker] run ant validate
[smoker] run tests w/ Java 7 and
testArgs='-Dtests.jettyConnector=Socket -Dtests.multiplier=1
-Dtests.slow=false'...
[smoker] test demo with 1.7...
[smoker] got 209 hits for query lucene
[smoker] checkindex with 1.7...
[smoker] generate javadocs w/ Java 7...
[smoker]
[smoker] Crawl/parse...
[smoker]
[smoker] Verify...
[smoker] confirm all releases have coverage in TestBackwardsCompatibility
[smoker] find all past Lucene releases...
[smoker] run TestBackwardsCompatibility..
[smoker] Traceback (most recent call last):
[smoker] File
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py,
line 1527, in module
[smoker] main()
[smoker] File
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py,
line 1472, in main
[smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir,
c.is_signed, ' '.join(c.test_args))
[smoker] File
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py,
line 1510, in smokeTest
[smoker] unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' %
version, svnRevision, version, testArgs, baseURL)
[smoker] File
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py,
line 616, in unpackAndVerify
[smoker] verifyUnpacked(java, project, artifact, unpackPath,
svnRevision, version, testArgs, tmpDir, baseURL)
[smoker] File
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py,
line 801, in verifyUnpacked
[smoker] confirmAllReleasesAreTestedForBackCompat(unpackPath)
[smoker] File
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py,
line 1465, in confirmAllReleasesAreTestedForBackCompat
[smoker] Releases that don't seem to be tested:
[smoker] 4.10.3
[smoker] raise RuntimeError('some releases are not tested by
TestBackwardsCompatibility?')
[smoker] RuntimeError: some releases are not tested by
TestBackwardsCompatibility?
BUILD FAILED
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/build.xml:414:
exec returned: 1
Total time: 47 minutes 39 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure
Sending email for trigger: Failure
