[jira] [Issue Comment Deleted] (SOLR-6562) Function query calculates the wrong value
[ https://issues.apache.org/jira/browse/SOLR-6562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Neumüller updated SOLR-6562: --- Comment: was deleted (was: I found a way to add hours to a date without a too big precision loss. I use ms to subtract a "negative" date with the correct amount of hours. For example if I want to add 4 hours to mydate I write: ms(mydate,1969-12-31T20:00:00.000Z).) > Function query calculates the wrong value > - > > Key: SOLR-6562 > URL: https://issues.apache.org/jira/browse/SOLR-6562 > Project: Solr > Issue Type: Bug >Affects Versions: 4.9 >Reporter: Stefan Neumüller >Priority: Critical > > This calculation > fl=sub(sum(abs(sub(1416906516710,141678360)),abs(sub(1036800,1416906516710))),10226321640) > should return 0. But the calculated value is 8388608 -- 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-5983) RoaringDocIdSet
[
https://issues.apache.org/jira/browse/LUCENE-5983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159986#comment-14159986
]
David Smiley commented on LUCENE-5983:
--
Cool. I also like that it's worst-case in advance() is not too shabby.
Why remove WAH8 & PFOR yet not also Elias-Fano? Because EF compresses the most
and doesn't perform as bad as those two in most advance() scenarios?
> RoaringDocIdSet
> ---
>
> Key: LUCENE-5983
> URL: https://issues.apache.org/jira/browse/LUCENE-5983
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-5983.patch
>
>
> Robert pointed me to this paper: http://arxiv.org/pdf/1402.6407v4 that
> describes an interesting way to build doc id sets: The bit space is divided
> into blocks of 2^16 bits so that you can store the bits which are set either
> in a short[] (2 bytes per doc ID) or in a FixedBitSet. The choice is easy, if
> less than 2^12 bits are set, then the short[] representation is more compact
> otherwise a FixedBitSet would be more compact. It's quite similar to the way
> that Solr builds DocSets in {{SolrIndexSearcher.getDocSet(DocsEnumState)}}.
--
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-b04) - Build # 4356 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4356/ Java: 32bit/jdk1.8.0_40-ea-b04 -server -XX:+UseG1GC 2 tests failed. REGRESSION: org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.testDistribSearch Error Message: expected:<0> but was:<1> Stack Trace: java.lang.AssertionError: expected:<0> but was:<1> at __randomizedtesting.SeedInfo.seed([E39CDBFCCD755522:627A55E4BA2A351E]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.doTest(ChaosMonkeySafeLeaderTest.java:153) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869) at sun.reflect.GeneratedMethodAccessor58.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:43) 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.ja
[jira] [Commented] (LUCENE-5989) Add BinaryField, to index a single binary token
[
https://issues.apache.org/jira/browse/LUCENE-5989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159825#comment-14159825
]
David Smiley commented on LUCENE-5989:
--
bq. This is supremely expert, I wonder if anyone out there has succeeded in
doing so?
{{org.apache.lucene.spatial.prefix.CellTokenStream}} :-)Though this doesn't
count since it's in Lucene.
+1 to make this easier via a BinaryField. With BinaryField and auto-prefixing,
CellTokenStream won't be needed for indexing a point. But it's needed for
other shapes and to support heat-map style faceting.
Jack's opinion about the "Keyword" name being far from obvious really resonated
with me. Despite Shai's reasonable explanation, it doesn't seem to me that
changing the status-quo to anything non-obvious is helpful. And it wouldn't
seem like the text equivalent of BinaryField -- for that the current name is
perfect, I think. But I do like the idea of simply having StringField taking a
byte[] too such that there is no BinaryField. Either way.
> Add BinaryField, to index a single binary token
> ---
>
> Key: LUCENE-5989
> URL: https://issues.apache.org/jira/browse/LUCENE-5989
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-5989.patch
>
>
> 5 years ago (LUCENE-1458) we "enabled" fully binary terms in the
> lowest levels of Lucene (the codec APIs) yet today, actually adding an
> arbitrary byte[] binary term during indexing is far from simple: you
> must make a custom Field with a custom TokenStream and a custom
> TermToBytesRefAttribute, as far as I know.
> This is supremely expert, I wonder if anyone out there has succeeded
> in doing so?
> I think we should make indexing a single byte[] as simple as indexing
> a single String.
> This is a pre-cursor for issues like LUCENE-5596 (encoding IPv6
> address as byte[16]) and LUCENE-5879 (encoding native numeric values
> in their simple binary form).
--
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-6589) testExampleConfig failing in trunk/branch5x
[
https://issues.apache.org/jira/browse/SOLR-6589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomás Fernández Löbbe updated SOLR-6589:
Attachment: SOLR-6589.patch
added test case
> testExampleConfig failing in trunk/branch5x
> ---
>
> Key: SOLR-6589
> URL: https://issues.apache.org/jira/browse/SOLR-6589
> Project: Solr
> Issue Type: Bug
>Reporter: Tomás Fernández Löbbe
> Attachments: SOLR-6589.patch, SOLR-6589.patch
>
>
> The test started failing recently and it's failing in all subclasses of
> {{SolrExampleTests}}
> {noformat}
> 5 tests failed.
> FAILED: org.apache.solr.client.solrj.SolrExampleBinaryTest.testExampleConfig
> Error Message:
> Expected mime type application/octet-stream but got text/html.
>
> Error 404 Can not find: /solr/admin/info/system
> HTTP ERROR: 404 Problem accessing /solr/admin/info/system.
> Reason: Can not find: /solr/admin/info/system />Powered by Jetty://
>
>
>
>
>
>
>
>
>
>
>
>
>
> Stack Trace:
> org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
> Expected mime type application/octet-stream but got text/html.
>
>
> Error 404 Can not find: /solr/admin/info/system
>
>
> HTTP ERROR: 404
> Problem accessing /solr/admin/info/system. Reason:
> Can not find: /solr/admin/info/system
> Powered by Jetty://
>
>
> at
> __randomizedtesting.SeedInfo.seed([52C2BA58AA8B46D5:E5EFAEC06D8CA00C]:0)
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:530)
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:215)
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:211)
> at
> org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:91)
> at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:301)
> at
> org.apache.solr.client.solrj.SolrExampleTests.testExampleConfig(SolrExampleTests.java:220)
> 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:484)
> 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.random
[jira] [Updated] (SOLR-6589) testExampleConfig failing in trunk/branch5x
[
https://issues.apache.org/jira/browse/SOLR-6589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomás Fernández Löbbe updated SOLR-6589:
Attachment: SOLR-6589.patch
> testExampleConfig failing in trunk/branch5x
> ---
>
> Key: SOLR-6589
> URL: https://issues.apache.org/jira/browse/SOLR-6589
> Project: Solr
> Issue Type: Bug
>Reporter: Tomás Fernández Löbbe
> Attachments: SOLR-6589.patch
>
>
> The test started failing recently and it's failing in all subclasses of
> {{SolrExampleTests}}
> {noformat}
> 5 tests failed.
> FAILED: org.apache.solr.client.solrj.SolrExampleBinaryTest.testExampleConfig
> Error Message:
> Expected mime type application/octet-stream but got text/html.
>
> Error 404 Can not find: /solr/admin/info/system
> HTTP ERROR: 404 Problem accessing /solr/admin/info/system.
> Reason: Can not find: /solr/admin/info/system />Powered by Jetty://
>
>
>
>
>
>
>
>
>
>
>
>
>
> Stack Trace:
> org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
> Expected mime type application/octet-stream but got text/html.
>
>
> Error 404 Can not find: /solr/admin/info/system
>
>
> HTTP ERROR: 404
> Problem accessing /solr/admin/info/system. Reason:
> Can not find: /solr/admin/info/system
> Powered by Jetty://
>
>
> at
> __randomizedtesting.SeedInfo.seed([52C2BA58AA8B46D5:E5EFAEC06D8CA00C]:0)
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:530)
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:215)
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:211)
> at
> org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:91)
> at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:301)
> at
> org.apache.solr.client.solrj.SolrExampleTests.testExampleConfig(SolrExampleTests.java:220)
> 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:484)
> 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.fork
[jira] [Commented] (SOLR-6589) testExampleConfig failing in trunk/branch5x
[
https://issues.apache.org/jira/browse/SOLR-6589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159746#comment-14159746
]
Tomás Fernández Löbbe commented on SOLR-6589:
-
I think the issue was introduced with SOLR-6585. I'll attach a possible fix
> testExampleConfig failing in trunk/branch5x
> ---
>
> Key: SOLR-6589
> URL: https://issues.apache.org/jira/browse/SOLR-6589
> Project: Solr
> Issue Type: Bug
>Reporter: Tomás Fernández Löbbe
>
> The test started failing recently and it's failing in all subclasses of
> {{SolrExampleTests}}
> {noformat}
> 5 tests failed.
> FAILED: org.apache.solr.client.solrj.SolrExampleBinaryTest.testExampleConfig
> Error Message:
> Expected mime type application/octet-stream but got text/html.
>
> Error 404 Can not find: /solr/admin/info/system
> HTTP ERROR: 404 Problem accessing /solr/admin/info/system.
> Reason: Can not find: /solr/admin/info/system />Powered by Jetty://
>
>
>
>
>
>
>
>
>
>
>
>
>
> Stack Trace:
> org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
> Expected mime type application/octet-stream but got text/html.
>
>
> Error 404 Can not find: /solr/admin/info/system
>
>
> HTTP ERROR: 404
> Problem accessing /solr/admin/info/system. Reason:
> Can not find: /solr/admin/info/system
> Powered by Jetty://
>
>
> at
> __randomizedtesting.SeedInfo.seed([52C2BA58AA8B46D5:E5EFAEC06D8CA00C]:0)
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:530)
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:215)
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:211)
> at
> org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:91)
> at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:301)
> at
> org.apache.solr.client.solrj.SolrExampleTests.testExampleConfig(SolrExampleTests.java:220)
> 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:484)
> 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
[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 1869 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/1869/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC 1 tests failed. REGRESSION: org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.testDistribSearch Error Message: expected:<0> but was:<1> Stack Trace: java.lang.AssertionError: expected:<0> but was:<1> at __randomizedtesting.SeedInfo.seed([958A190CF6D69FCA:146C97148189FFF6]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.doTest(ChaosMonkeySafeLeaderTest.java:153) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869) at sun.reflect.GeneratedMethodAccessor35.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:43) 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(ThreadLeakCo
[JENKINS] Lucene-Solr-Tests-trunk-Java7 - Build # 4907 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java7/4907/ 3 tests failed. REGRESSION: org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.testDistribSearch Error Message: expected:<0> but was:<1> Stack Trace: java.lang.AssertionError: expected:<0> but was:<1> at __randomizedtesting.SeedInfo.seed([71871D6926824D6E:F061937151DD2D52]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.doTest(ChaosMonkeySafeLeaderTest.java:153) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869) 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:43) 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$
[jira] [Comment Edited] (SOLR-6351) Let Stats Hang off of Pivots (via 'tag')
[
https://issues.apache.org/jira/browse/SOLR-6351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159648#comment-14159648
]
Vitaliy Zhovtyuk edited comment on SOLR-6351 at 10/5/14 7:20 PM:
-
1. Added stats fields pivot distribution to DistributedFacetPivotSmallTest
(same data and values from
org.apache.solr.handler.component.FacetPivotSmallTest used)
2. Fixed "LinkedHashMap cannot be casted to NamedList" exception, occurring on
stats distribution (changed
org.apache.solr.handler.component.PivotFacetHelper#convertStatsValuesToNamedList)
3. About Testing for not supported types, i think we need to cover/document
limitations as well.I'm not happy with asserting error message.
Added http code 400 assertion and error message substring assertion.
was (Author: vzhovtiuk):
1. Added stats fields pivot distribution to DistributedFacetPivotSmallTest
2. Fixed "LinkedHashMap cannot be casted to NamedList" exception, occurring on
stats distribution (changed
org.apache.solr.handler.component.PivotFacetHelper#convertStatsValuesToNamedList)
3. About Testing for not supported types, i think we need to cover/document
limitations as well.I'm not happy with asserting error message.
Added http code 400 assertion and error message substring assertion.
> Let Stats Hang off of Pivots (via 'tag')
>
>
> Key: SOLR-6351
> URL: https://issues.apache.org/jira/browse/SOLR-6351
> Project: Solr
> Issue Type: Sub-task
>Reporter: Hoss Man
> Attachments: SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch,
> SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch
>
>
> he goal here is basically flip the notion of "stats.facet" on it's head, so
> that instead of asking the stats component to also do some faceting
> (something that's never worked well with the variety of field types and has
> never worked in distributed mode) we instead ask the PivotFacet code to
> compute some stats X for each leaf in a pivot. We'll do this with the
> existing {{stats.field}} params, but we'll leverage the {{tag}} local param
> of the {{stats.field}} instances to be able to associate which stats we want
> hanging off of which {{facet.pivot}}
> Example...
> {noformat}
> facet.pivot={!stats=s1}category,manufacturer
> stats.field={!key=avg_price tag=s1 mean=true}price
> stats.field={!tag=s1 min=true max=true}user_rating
> {noformat}
> ...with the request above, in addition to computing the min/max user_rating
> and mean price (labeled "avg_price") over the entire result set, the
> PivotFacet component will also include those stats for every node of the tree
> it builds up when generating a pivot of the fields "category,manufacturer"
--
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-6351) Let Stats Hang off of Pivots (via 'tag')
[
https://issues.apache.org/jira/browse/SOLR-6351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-6351:
---
Attachment: SOLR-6351.patch
1. Added stats fields pivot distribution to DistributedFacetPivotSmallTest
2. Fixed "LinkedHashMap cannot be casted to NamedList" exception, occurring on
stats distribution (changed
org.apache.solr.handler.component.PivotFacetHelper#convertStatsValuesToNamedList)
3. About Testing for not supported types, i think we need to cover/document
limitations as well.I'm not happy with asserting error message.
Added http code 400 assertion and error message substring assertion.
> Let Stats Hang off of Pivots (via 'tag')
>
>
> Key: SOLR-6351
> URL: https://issues.apache.org/jira/browse/SOLR-6351
> Project: Solr
> Issue Type: Sub-task
>Reporter: Hoss Man
> Attachments: SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch,
> SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch
>
>
> he goal here is basically flip the notion of "stats.facet" on it's head, so
> that instead of asking the stats component to also do some faceting
> (something that's never worked well with the variety of field types and has
> never worked in distributed mode) we instead ask the PivotFacet code to
> compute some stats X for each leaf in a pivot. We'll do this with the
> existing {{stats.field}} params, but we'll leverage the {{tag}} local param
> of the {{stats.field}} instances to be able to associate which stats we want
> hanging off of which {{facet.pivot}}
> Example...
> {noformat}
> facet.pivot={!stats=s1}category,manufacturer
> stats.field={!key=avg_price tag=s1 mean=true}price
> stats.field={!tag=s1 min=true max=true}user_rating
> {noformat}
> ...with the request above, in addition to computing the min/max user_rating
> and mean price (labeled "avg_price") over the entire result set, the
> PivotFacet component will also include those stats for every node of the tree
> it builds up when generating a pivot of the fields "category,manufacturer"
--
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-Windows (32bit/jdk1.8.0_40-ea-b04) - Build # 4253 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4253/ Java: 32bit/jdk1.8.0_40-ea-b04 -server -XX:+UseSerialGC 1 tests failed. REGRESSION: org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.testDistribSearch Error Message: expected:<0> but was:<1> Stack Trace: java.lang.AssertionError: expected:<0> but was:<1> at __randomizedtesting.SeedInfo.seed([464AFC91D9F84B66:C7AC7289AEA72B5A]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.doTest(ChaosMonkeySafeLeaderTest.java:153) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869) at sun.reflect.GeneratedMethodAccessor49.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:43) 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.
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.9.0-ea-b28) - Build # 11392 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11392/ Java: 32bit/jdk1.9.0-ea-b28 -server -XX:+UseG1GC 5 tests failed. FAILED: org.apache.solr.client.solrj.SolrExampleBinaryTest.testExampleConfig Error Message: Expected mime type application/octet-stream but got text/html. Error 404 Can not find: /solr/admin/info/system HTTP ERROR: 404 Problem accessing /solr/admin/info/system. Reason: Can not find: /solr/admin/info/system Powered by Jetty:// Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Expected mime type application/octet-stream but got text/html. Error 404 Can not find: /solr/admin/info/system HTTP ERROR: 404 Problem accessing /solr/admin/info/system. Reason: Can not find: /solr/admin/info/system Powered by Jetty:// at __randomizedtesting.SeedInfo.seed([57F750C6567535B4:E0DA445E9172D36D]:0) at org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:530) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:215) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:211) at org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:91) at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:301) at org.apache.solr.client.solrj.SolrExampleTests.testExampleConfig(SolrExampleTests.java:220) 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:484) 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
[JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 648 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/648/ 2 tests failed. REGRESSION: org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testDistribSearch Error Message: Error CREATEing SolrCore 'halfcollection_shard1_replica1': Unable to create core [halfcollection_shard1_replica1] Caused by: Could not get shard id for core: halfcollection_shard1_replica1 Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Error CREATEing SolrCore 'halfcollection_shard1_replica1': Unable to create core [halfcollection_shard1_replica1] Caused by: Could not get shard id for core: halfcollection_shard1_replica1 at org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:570) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:215) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:211) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testErrorHandling(CollectionsAPIDistributedZkTest.java:583) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:205) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869) 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:43) at org.apache.lucene.util.TestRuleM
[jira] [Commented] (SOLR-6589) testExampleConfig failing in trunk/branch5x
[
https://issues.apache.org/jira/browse/SOLR-6589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159615#comment-14159615
]
ASF subversion and git services commented on SOLR-6589:
---
Commit 1629518 from [~tomasflobbe] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1629518 ]
SOLR-6589: Ignoring testExampleConfig until there is a fix
> testExampleConfig failing in trunk/branch5x
> ---
>
> Key: SOLR-6589
> URL: https://issues.apache.org/jira/browse/SOLR-6589
> Project: Solr
> Issue Type: Bug
>Reporter: Tomás Fernández Löbbe
>
> The test started failing recently and it's failing in all subclasses of
> {{SolrExampleTests}}
> {noformat}
> 5 tests failed.
> FAILED: org.apache.solr.client.solrj.SolrExampleBinaryTest.testExampleConfig
> Error Message:
> Expected mime type application/octet-stream but got text/html.
>
> Error 404 Can not find: /solr/admin/info/system
> HTTP ERROR: 404 Problem accessing /solr/admin/info/system.
> Reason: Can not find: /solr/admin/info/system />Powered by Jetty://
>
>
>
>
>
>
>
>
>
>
>
>
>
> Stack Trace:
> org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
> Expected mime type application/octet-stream but got text/html.
>
>
> Error 404 Can not find: /solr/admin/info/system
>
>
> HTTP ERROR: 404
> Problem accessing /solr/admin/info/system. Reason:
> Can not find: /solr/admin/info/system
> Powered by Jetty://
>
>
> at
> __randomizedtesting.SeedInfo.seed([52C2BA58AA8B46D5:E5EFAEC06D8CA00C]:0)
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:530)
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:215)
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:211)
> at
> org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:91)
> at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:301)
> at
> org.apache.solr.client.solrj.SolrExampleTests.testExampleConfig(SolrExampleTests.java:220)
> 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:484)
> 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
[jira] [Commented] (SOLR-6589) testExampleConfig failing in trunk/branch5x
[
https://issues.apache.org/jira/browse/SOLR-6589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159606#comment-14159606
]
ASF subversion and git services commented on SOLR-6589:
---
Commit 1629517 from [~tomasflobbe] in branch 'dev/trunk'
[ https://svn.apache.org/r1629517 ]
SOLR-6589: Ignoring testExampleConfig until there is a fix
> testExampleConfig failing in trunk/branch5x
> ---
>
> Key: SOLR-6589
> URL: https://issues.apache.org/jira/browse/SOLR-6589
> Project: Solr
> Issue Type: Bug
>Reporter: Tomás Fernández Löbbe
>
> The test started failing recently and it's failing in all subclasses of
> {{SolrExampleTests}}
> {noformat}
> 5 tests failed.
> FAILED: org.apache.solr.client.solrj.SolrExampleBinaryTest.testExampleConfig
> Error Message:
> Expected mime type application/octet-stream but got text/html.
>
> Error 404 Can not find: /solr/admin/info/system
> HTTP ERROR: 404 Problem accessing /solr/admin/info/system.
> Reason: Can not find: /solr/admin/info/system />Powered by Jetty://
>
>
>
>
>
>
>
>
>
>
>
>
>
> Stack Trace:
> org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
> Expected mime type application/octet-stream but got text/html.
>
>
> Error 404 Can not find: /solr/admin/info/system
>
>
> HTTP ERROR: 404
> Problem accessing /solr/admin/info/system. Reason:
> Can not find: /solr/admin/info/system
> Powered by Jetty://
>
>
> at
> __randomizedtesting.SeedInfo.seed([52C2BA58AA8B46D5:E5EFAEC06D8CA00C]:0)
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:530)
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:215)
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:211)
> at
> org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:91)
> at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:301)
> at
> org.apache.solr.client.solrj.SolrExampleTests.testExampleConfig(SolrExampleTests.java:220)
> 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:484)
> 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
[jira] [Created] (SOLR-6589) testExampleConfig failing in trunk/branch5x
Tomás Fernández Löbbe created SOLR-6589:
---
Summary: testExampleConfig failing in trunk/branch5x
Key: SOLR-6589
URL: https://issues.apache.org/jira/browse/SOLR-6589
Project: Solr
Issue Type: Bug
Reporter: Tomás Fernández Löbbe
The test started failing recently and it's failing in all subclasses of
{{SolrExampleTests}}
{noformat}
5 tests failed.
FAILED: org.apache.solr.client.solrj.SolrExampleBinaryTest.testExampleConfig
Error Message:
Expected mime type application/octet-stream but got text/html.
Error 404 Can not find: /solr/admin/info/system
HTTP ERROR: 404 Problem accessing /solr/admin/info/system. Reason:
Can not find: /solr/admin/info/system Powered by Jetty://
Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Expected
mime type application/octet-stream but got text/html.
Error 404 Can not find: /solr/admin/info/system
HTTP ERROR: 404
Problem accessing /solr/admin/info/system. Reason:
Can not find: /solr/admin/info/system
Powered by Jetty://
at
__randomizedtesting.SeedInfo.seed([52C2BA58AA8B46D5:E5EFAEC06D8CA00C]:0)
at
org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:530)
at
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:215)
at
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:211)
at
org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:91)
at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:301)
at
org.apache.solr.client.solrj.SolrExampleTests.testExampleConfig(SolrExampleTests.java:220)
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:484)
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.carrotsearc
[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_20) - Build # 11238 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11238/ Java: 64bit/jdk1.8.0_20 -XX:+UseCompressedOops -XX:+UseParallelGC 2 tests failed. REGRESSION: org.apache.solr.cloud.DeleteLastCustomShardedReplicaTest.testDistribSearch Error Message: No live SolrServers available to handle this request:[https://127.0.0.1:57998, https://127.0.0.1:43129, https://127.0.0.1:54009] Stack Trace: org.apache.solr.client.solrj.SolrServerException: No live SolrServers available to handle this request:[https://127.0.0.1:57998, https://127.0.0.1:43129, https://127.0.0.1:54009] at __randomizedtesting.SeedInfo.seed([4383ACBEC4D4D510:C26522A6B38BB52C]:0) at org.apache.solr.client.solrj.impl.LBHttpSolrServer.request(LBHttpSolrServer.java:322) at org.apache.solr.client.solrj.impl.CloudSolrServer.sendRequest(CloudSolrServer.java:880) at org.apache.solr.client.solrj.impl.CloudSolrServer.requestWithRetryOnStaleState(CloudSolrServer.java:658) at org.apache.solr.client.solrj.impl.CloudSolrServer.request(CloudSolrServer.java:601) at org.apache.solr.cloud.DeleteLastCustomShardedReplicaTest.removeAndWaitForLastReplicaGone(DeleteLastCustomShardedReplicaTest.java:117) at org.apache.solr.cloud.DeleteLastCustomShardedReplicaTest.doTest(DeleteLastCustomShardedReplicaTest.java:107) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869) 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 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36
[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.8.0_20) - Build # 4355 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4355/ Java: 32bit/jdk1.8.0_20 -server -XX:+UseSerialGC 5 tests failed. FAILED: org.apache.solr.client.solrj.SolrExampleBinaryTest.testExampleConfig Error Message: Expected mime type application/octet-stream but got text/html. Error 404 Can not find: /solr/admin/info/system HTTP ERROR: 404 Problem accessing /solr/admin/info/system. Reason: Can not find: /solr/admin/info/system Powered by Jetty:// Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Expected mime type application/octet-stream but got text/html. Error 404 Can not find: /solr/admin/info/system HTTP ERROR: 404 Problem accessing /solr/admin/info/system. Reason: Can not find: /solr/admin/info/system Powered by Jetty:// at __randomizedtesting.SeedInfo.seed([CF57BC94E6F618F4:787AA80C21F1FE2D]:0) at org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:530) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:215) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:211) at org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:91) at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:301) at org.apache.solr.client.solrj.SolrExampleTests.testExampleConfig(SolrExampleTests.java:220) 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.randomizedtestin
[JENKINS] Lucene-trunk-Linux-java7-64-analyzers - Build # 16483 - Failure!
Build: builds.flonkings.com/job/Lucene-trunk-Linux-java7-64-analyzers/16483/ 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.lucene.analysis.core.TestRandomChains Error Message: Suite timeout exceeded (>= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (>= 720 msec). at __randomizedtesting.SeedInfo.seed([E031AB6179147750]:0) REGRESSION: org.apache.lucene.analysis.core.TestRandomChains.testRandomChainsWithLargeStrings Error Message: Test abandoned because suite timeout was reached. Stack Trace: java.lang.Exception: Test abandoned because suite timeout was reached. at __randomizedtesting.SeedInfo.seed([E031AB6179147750]:0) Build Log: [...truncated 1360 lines...] [junit4] Suite: org.apache.lucene.analysis.core.TestRandomChains [junit4] 2> oct 05, 2014 8:52:55 AM com.carrotsearch.randomizedtesting.ThreadLeakControl$2 evaluate [junit4] 2> ADVERTENCIA: Suite execution timed out: org.apache.lucene.analysis.core.TestRandomChains [junit4] 2> jstack at approximately timeout time [junit4] 2> "TEST-TestRandomChains.testRandomChainsWithLargeStrings-seed#[E031AB6179147750]" ID=17 RUNNABLE [junit4] 2>at java.util.HashMap.hash(HashMap.java:362) [junit4] 2>at java.util.HashMap.getEntry(HashMap.java:462) [junit4] 2>at java.util.HashMap.get(HashMap.java:417) [junit4] 2>at org.apache.lucene.analysis.ValidatingTokenFilter.incrementToken(ValidatingTokenFilter.java:107) [junit4] 2>at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:703) [junit4] 2>at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:614) [junit4] 2>at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:512) [junit4] 2>at org.apache.lucene.analysis.core.TestRandomChains.testRandomChainsWithLargeStrings(TestRandomChains.java:930) [junit4] 2>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit4] 2>at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [junit4] 2>at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [junit4] 2>at java.lang.reflect.Method.invoke(Method.java:606) [junit4] 2>at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) [junit4] 2>at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) [junit4] 2>at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) [junit4] 2>at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) [junit4] 2>at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) [junit4] 2>at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) [junit4] 2>at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) [junit4] 2>at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) [junit4] 2>at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) [junit4] 2>at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) [junit4] 2>at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) [junit4] 2>at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) [junit4] 2>at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) [junit4] 2>at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) [junit4] 2>at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836) [junit4] 2>at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) [junit4] 2>at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) [junit4] 2>at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) [junit4] 2>at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) [junit4] 2>at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) [junit4] 2>at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluat
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_40-ea-b04) - Build # 11391 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11391/ Java: 32bit/jdk1.8.0_40-ea-b04 -client -XX:+UseG1GC 1 tests failed. REGRESSION: org.apache.solr.cloud.DeleteReplicaTest.testDistribSearch Error Message: No live SolrServers available to handle this request:[https://127.0.0.1:36471, https://127.0.0.1:58855, https://127.0.0.1:51677, https://127.0.0.1:40655, https://127.0.0.1:58222] Stack Trace: org.apache.solr.client.solrj.SolrServerException: No live SolrServers available to handle this request:[https://127.0.0.1:36471, https://127.0.0.1:58855, https://127.0.0.1:51677, https://127.0.0.1:40655, https://127.0.0.1:58222] at __randomizedtesting.SeedInfo.seed([79B149C10C7C8343:F857C7D97B23E37F]:0) at org.apache.solr.client.solrj.impl.LBHttpSolrServer.request(LBHttpSolrServer.java:322) at org.apache.solr.client.solrj.impl.CloudSolrServer.sendRequest(CloudSolrServer.java:880) at org.apache.solr.client.solrj.impl.CloudSolrServer.requestWithRetryOnStaleState(CloudSolrServer.java:658) at org.apache.solr.client.solrj.impl.CloudSolrServer.request(CloudSolrServer.java:601) at org.apache.solr.cloud.DeleteReplicaTest.removeAndWaitForReplicaGone(DeleteReplicaTest.java:172) at org.apache.solr.cloud.DeleteReplicaTest.deleteLiveReplicaTest(DeleteReplicaTest.java:145) at org.apache.solr.cloud.DeleteReplicaTest.doTest(DeleteReplicaTest.java:89) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869) 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)
[jira] [Commented] (LUCENE-5991) add minor-revision writers to backwards-codecs
[
https://issues.apache.org/jira/browse/LUCENE-5991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159554#comment-14159554
]
Robert Muir commented on LUCENE-5991:
-
By the way, i dont think we should add complex conditional logic on the
write-side. Since this is just for tests, we should focus on the authenticity
of the format and just have a writer for each or something simple if we need.
> add minor-revision writers to backwards-codecs
> --
>
> Key: LUCENE-5991
> URL: https://issues.apache.org/jira/browse/LUCENE-5991
> Project: Lucene - Core
> Issue Type: Test
>Reporter: Robert Muir
>
> Today we have backwards testing almost completely isolated cleanly, and tests
> against each format. But we only test old major formats, not the minor ones.
> Before it was probably the right tradeoff, but now that its isolated I think
> we should test all of them.
> For example the 4.1 stored fields format had two minor format changes across
> the 4.x release:
> {noformat}
> static final int VERSION_START = 0;
> static final int VERSION_BIG_CHUNKS = 1;
> static final int VERSION_CHECKSUM = 2;
> static final int VERSION_CURRENT = VERSION_CHECKSUM;
> {noformat}
> We could easily directly test these possibilities (e.g. take this as a
> parameter to the RW format and have 3 TestXXXStoredFieldsFormat, one for
> each) instead of only testing the latest one and relying on TestBackCompat to
> find issues, which it probably won't since the index is simplistic.
--
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-5991) add minor-revision writers to backwards-codecs
Robert Muir created LUCENE-5991:
---
Summary: add minor-revision writers to backwards-codecs
Key: LUCENE-5991
URL: https://issues.apache.org/jira/browse/LUCENE-5991
Project: Lucene - Core
Issue Type: Test
Reporter: Robert Muir
Today we have backwards testing almost completely isolated cleanly, and tests
against each format. But we only test old major formats, not the minor ones.
Before it was probably the right tradeoff, but now that its isolated I think we
should test all of them.
For example the 4.1 stored fields format had two minor format changes across
the 4.x release:
{noformat}
static final int VERSION_START = 0;
static final int VERSION_BIG_CHUNKS = 1;
static final int VERSION_CHECKSUM = 2;
static final int VERSION_CURRENT = VERSION_CHECKSUM;
{noformat}
We could easily directly test these possibilities (e.g. take this as a
parameter to the RW format and have 3 TestXXXStoredFieldsFormat, one for each)
instead of only testing the latest one and relying on TestBackCompat to find
issues, which it probably won't since the index is simplistic.
--
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-SmokeRelease-trunk - Build # 208 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-trunk/208/ No tests ran. Build Log: [...truncated 50832 lines...] prepare-release-no-sign: [mkdir] Created dir: /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/dist [copy] Copying 446 files to /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/dist/lucene [copy] Copying 245 files to /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/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-trunk/lucene/build/smokeTestRelease/dist/"... [smoker] [smoker] Test Lucene... [smoker] test basics... [smoker] get KEYS [smoker] 0.1 MB in 0.01 sec (11.6 MB/sec) [smoker] check changes HTML... [smoker] download lucene-6.0.0-src.tgz... [smoker] 27.6 MB in 0.04 sec (652.2 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-6.0.0.tgz... [smoker] 61.0 MB in 0.14 sec (427.9 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-6.0.0.zip... [smoker] 70.5 MB in 0.11 sec (663.4 MB/sec) [smoker] verify md5/sha1 digests [smoker] unpack lucene-6.0.0.tgz... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] test demo with 1.7... [smoker] got 5571 hits for query "lucene" [smoker] checkindex with 1.7... [smoker] check Lucene's javadoc JAR [smoker] unpack lucene-6.0.0.zip... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] test demo with 1.7... [smoker] got 5571 hits for query "lucene" [smoker] checkindex with 1.7... [smoker] check Lucene's javadoc JAR [smoker] unpack lucene-6.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.disableHdfs=true -Dtests.multiplier=1 -Dtests.slow=false'... [smoker] test demo with 1.7... [smoker] got 217 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] success! [smoker] [smoker] Test Solr... [smoker] test basics... [smoker] get KEYS [smoker] 0.1 MB in 0.00 sec (82.0 MB/sec) [smoker] check changes HTML... [smoker] download solr-6.0.0-src.tgz... [smoker] 33.8 MB in 0.04 sec (884.6 MB/sec) [smoker] verify md5/sha1 digests [smoker] download solr-6.0.0.tgz... [smoker] 115.8 MB in 0.59 sec (195.3 MB/sec) [smoker] verify md5/sha1 digests [smoker] download solr-6.0.0.zip... [smoker] 121.9 MB in 0.18 sec (683.8 MB/sec) [smoker] verify md5/sha1 digests [smoker] unpack solr-6.0.0.tgz... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] unpack lucene-6.0.0.tgz... [smoker] **WARNING**: skipping check of /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/tmp/unpack/solr-6.0.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar: it has javax.* classes [smoker] **WARNING**: skipping check of /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/tmp/unpack/solr-6.0.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar: it has javax.* classes [smoker] verify WAR metadata/contained JAR identity/no javax.* or java.* classes... [smoker] unpack lucene-6.0.0.tgz... [smoker] copying unpacked distribution for Java 7 ... [smoker] test solr example w/ Java 7... [smoker] start Solr instance (log=/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/tmp/unpack/solr-6.0.0-java7/solr-example.log)... [smoker] startup done [smoker] test utf8... [smoker] index example docs... [smoker] run query... [smoker] stop server (SIGINT)... [smoker] unpack solr-6.0.0.zip... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] unpack lucene-6.0.0.tgz... [smoker] **WARNING**: skipping check of /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/tmp/unpack/solr-6.0.0/contrib/dataimporthandler-extras/lib/activat
[jira] [Commented] (LUCENE-5969) Add Lucene50Codec
[ https://issues.apache.org/jira/browse/LUCENE-5969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159545#comment-14159545 ] ASF subversion and git services commented on LUCENE-5969: - Commit 1629503 from [~rcmuir] in branch 'dev/branches/lucene5969' [ https://svn.apache.org/r1629503 ] LUCENE-5969: recreate branch for phase 3 > Add Lucene50Codec > - > > Key: LUCENE-5969 > URL: https://issues.apache.org/jira/browse/LUCENE-5969 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless > Fix For: 5.0, Trunk > > Attachments: LUCENE-5969.patch, LUCENE-5969.patch, > LUCENE-5969_part2.patch > > > Spinoff from LUCENE-5952: > * Fix .si to write Version as 3 ints, not a String that requires parsing at > read time. > * Lucene42TermVectorsFormat should not use the same codecName as > Lucene41StoredFieldsFormat > It would also be nice if we had a "bumpCodecVersion" script so rolling a new > codec is not so daunting. -- 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-5969) Add Lucene50Codec
[ https://issues.apache.org/jira/browse/LUCENE-5969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159543#comment-14159543 ] ASF subversion and git services commented on LUCENE-5969: - Commit 1629501 from [~rcmuir] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1629501 ] LUCENE-5969: Lucene 5.0 codec, round two > Add Lucene50Codec > - > > Key: LUCENE-5969 > URL: https://issues.apache.org/jira/browse/LUCENE-5969 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless > Fix For: 5.0, Trunk > > Attachments: LUCENE-5969.patch, LUCENE-5969.patch, > LUCENE-5969_part2.patch > > > Spinoff from LUCENE-5952: > * Fix .si to write Version as 3 ints, not a String that requires parsing at > read time. > * Lucene42TermVectorsFormat should not use the same codecName as > Lucene41StoredFieldsFormat > It would also be nice if we had a "bumpCodecVersion" script so rolling a new > codec is not so daunting. -- 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-5990) Merging should pass correct fieldinfos to producers always
[
https://issues.apache.org/jira/browse/LUCENE-5990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159533#comment-14159533
]
Robert Muir commented on LUCENE-5990:
-
I will also think about assertingcodec and how it could check for such things.
maybe its producer on init could save fieldinfos, e.g. for DV
{code}
public DocValuesProducer fieldsProducer(SegmentReadState state) throws
IOException {
// save ref to state.fieldinfos
}
{code}
then whenever getXXXDocValues(FieldInfo) is called, it could lookup by number
or by name and assert the FieldInfo is the same instance.
> Merging should pass correct fieldinfos to producers always
> --
>
> Key: LUCENE-5990
> URL: https://issues.apache.org/jira/browse/LUCENE-5990
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Robert Muir
>
> I think its been a longstanding issue, but I noticed it in the bulk merge
> code today and see that we can fix it...
> instead of:
> {code}
> DocumentStoredFieldVisitor visitor = new DocumentStoredFieldVisitor();
> storedFieldsReader.visitDocument(docID, visitor);
> Document doc = visitor.getDocument();
> addDocument(doc, mergeState.mergeFieldInfos);
> {code}
> we should do:
> {code}
> addDocument(doc, mergeState.fieldInfos[i]);
> {code}
> This is a lot more consistent and reduce the possibility of scary bugs during
> merge because the codec does something strange. We should look into all merge
> logic to see if it can be improved here.
--
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-5990) Merging should pass correct fieldinfos to producers always
[
https://issues.apache.org/jira/browse/LUCENE-5990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159532#comment-14159532
]
Robert Muir commented on LUCENE-5990:
-
FWIW this example is actually bogus (duh), because it passing to the consumer.
But the idea still applies. I just wanted to open the issue to remind myself,
to check this for e.g. DV producers and so on that take fieldinfos as a
parameter.
> Merging should pass correct fieldinfos to producers always
> --
>
> Key: LUCENE-5990
> URL: https://issues.apache.org/jira/browse/LUCENE-5990
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Robert Muir
>
> I think its been a longstanding issue, but I noticed it in the bulk merge
> code today and see that we can fix it...
> instead of:
> {code}
> DocumentStoredFieldVisitor visitor = new DocumentStoredFieldVisitor();
> storedFieldsReader.visitDocument(docID, visitor);
> Document doc = visitor.getDocument();
> addDocument(doc, mergeState.mergeFieldInfos);
> {code}
> we should do:
> {code}
> addDocument(doc, mergeState.fieldInfos[i]);
> {code}
> This is a lot more consistent and reduce the possibility of scary bugs during
> merge because the codec does something strange. We should look into all merge
> logic to see if it can be improved here.
--
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-5990) Merging should pass correct fieldinfos to producers always
Robert Muir created LUCENE-5990:
---
Summary: Merging should pass correct fieldinfos to producers always
Key: LUCENE-5990
URL: https://issues.apache.org/jira/browse/LUCENE-5990
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir
I think its been a longstanding issue, but I noticed it in the bulk merge code
today and see that we can fix it...
instead of:
{code}
DocumentStoredFieldVisitor visitor = new DocumentStoredFieldVisitor();
storedFieldsReader.visitDocument(docID, visitor);
Document doc = visitor.getDocument();
addDocument(doc, mergeState.mergeFieldInfos);
{code}
we should do:
{code}
addDocument(doc, mergeState.fieldInfos[i]);
{code}
This is a lot more consistent and reduce the possibility of scary bugs during
merge because the codec does something strange. We should look into all merge
logic to see if it can be improved here.
--
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-5969) Add Lucene50Codec
[ https://issues.apache.org/jira/browse/LUCENE-5969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159529#comment-14159529 ] ASF subversion and git services commented on LUCENE-5969: - Commit 1629499 from [~rcmuir] in branch 'dev/trunk' [ https://svn.apache.org/r1629499 ] LUCENE-5969: Lucene 5.0 codec, round two > Add Lucene50Codec > - > > Key: LUCENE-5969 > URL: https://issues.apache.org/jira/browse/LUCENE-5969 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless > Fix For: 5.0, Trunk > > Attachments: LUCENE-5969.patch, LUCENE-5969.patch, > LUCENE-5969_part2.patch > > > Spinoff from LUCENE-5952: > * Fix .si to write Version as 3 ints, not a String that requires parsing at > read time. > * Lucene42TermVectorsFormat should not use the same codecName as > Lucene41StoredFieldsFormat > It would also be nice if we had a "bumpCodecVersion" script so rolling a new > codec is not so daunting. -- 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-5989) Add BinaryField, to index a single binary token
[ https://issues.apache.org/jira/browse/LUCENE-5989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159528#comment-14159528 ] Shai Erera commented on LUCENE-5989: bq. Is that simply a typo Yes, fixed :). The term 'keyword' is of course overloaded here. When I propose KeywordField, I am following the existing Keyword* classes that we have: KeywordTokenizer, KeywordAnalyzer, KeywordAttribute. And from what I remember, when users ask how to parse 'keywords' they indexed as StringFields, we often tell them to use PerFieldAnalyzerWrapper with a KeywordAnalyzer for that field. That's why I feel that KeywordField fits better with the overall Keyword* tokenstream API. > Add BinaryField, to index a single binary token > --- > > Key: LUCENE-5989 > URL: https://issues.apache.org/jira/browse/LUCENE-5989 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 5.0, Trunk > > Attachments: LUCENE-5989.patch > > > 5 years ago (LUCENE-1458) we "enabled" fully binary terms in the > lowest levels of Lucene (the codec APIs) yet today, actually adding an > arbitrary byte[] binary term during indexing is far from simple: you > must make a custom Field with a custom TokenStream and a custom > TermToBytesRefAttribute, as far as I know. > This is supremely expert, I wonder if anyone out there has succeeded > in doing so? > I think we should make indexing a single byte[] as simple as indexing > a single String. > This is a pre-cursor for issues like LUCENE-5596 (encoding IPv6 > address as byte[16]) and LUCENE-5879 (encoding native numeric values > in their simple binary form). -- 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
Re: 5.0 release status?
Why don't you just do as ryan suggests and read the JIRA issues. I already outlined things like the memory improvements being made in the new format and for merging. I don't need to summarize it again. And we don't have to "justify" fixing back compat corruptions with new features. It is the other way around. If anyone doesn't like this approach to unfucking these problems for 5.0 and wants to continue with 4.x releases, then they need to step up to the plate and do the work. Thats where the problem always is: lots of people that want to whine about back compat, but don't want to actually do any work. On Sun, Oct 5, 2014 at 9:30 AM, Jack Krupansky wrote: > To be clear, I myself am not trying to offer advice on whether or when > people should upgrade – I’m trying solely to determine if there is > significant value to do so, and what that value might be. I did indeed read > through Robert’s list and have watched the Jira flow over the years, but I > am unable to pinpoint “significant” improvements that will have more than > just a “minor” impact for users. I’m not trying to say that significant > improvements aren’t actually in there, just that I don’t know of any. If I > am wrong, please provide the details. Like... are there use cases where the > 5.0 index will be at least 10% faster or at least 10% smaller, and if so, > which specific features and use cases? Or if there is a cumulative > improvement in performance or capacity. > > Or... if there are specific feature transitions to recommend that would > result in dramatic improvements. > > I mean, as things stand, there has been a lot of “shuffling around”, but no > clear, quantified insight on the benefits of that shuffling/refactoring. I’m > all for cleaner code (which can manifest as more reliable and less bugs), > but is that is gist of most of the index changes? > > In short, I’m more interested in the impact of the 5.0 index changes (and > their use cases), not the details of the implementation of those changes. > > Put another way, will a typical app be at least 10% faster or 10% smaller > (or both!) when its index is converted from 4.x to 5.0? Or 5% or 20% or... > whatever it actually is? > > And if there are specific new features that rely on conversion to 5.0 index > format, lets get that list collected as some bullet points. Call this > preparation for the 5.0 release! Maybe it could be a summary section in the > 5.0 migration guide. > > Clearly there is plenty of goodness in the 5.0 work, but I’m just trying to > get a handle on the overall impact. > > -- Jack Krupansky > > From: Ryan Ernst > Sent: Sunday, October 5, 2014 12:48 AM > To: dev@lucene.apache.org > Subject: Re: 5.0 release status? > > > > On Oct 4, 2014 9:35 PM, "Jack Krupansky" wrote: >> >> Maybe I just can’t fully make sense of LUCENE-5934 – does it corrupt all >> 4.x indexes, or some, or under some conditions? I mean, I had the impression >> that it was only non-GA 4.0 indexes. And was it only 4.10 that was doing >> this, or 4.0 GA through 4.9 as well? > > The bug only affected people using the 4.10.0 release to read 4.0 beta/final > segments (it thought they were 3x indexes). > >> >> In any case, I’m still not clear on the direct benefits to users of, say, >> 4.9 upgrading to 5.0 indexes. Any performance improvement? Any disk space >> reduction? Any RAM reduction? > > Again, read through all the stuff Robert has mentioned, read through > lucene/CHANGES.txt, read the issues that are currently open. Your previous > comments have suggested users upgrading to 5.0 would only do so so they can > eventually upgrade to 6.0, implying they wouldn't upgrade their indexes for > minor releases. This simply is not the best advice. Look back at 4.9 and > 4.10 for recent improvements in heap usage for doc values and norms for > example. Going back farther, someone still on 4.0 doesn't benefit from the > postings format improvements in 4.1. Users should upgrade their format > whenever possible because improvements are always happening. > >> >> -- Jack Krupansky >> >> From: Ryan Ernst >> Sent: Sunday, October 5, 2014 12:24 AM >> To: dev@lucene.apache.org >> Subject: Re: 5.0 release status? >> >> >> >> On Oct 4, 2014 9:13 PM, "Jack Krupansky" wrote: >> > >> > Thanks for the further clarification. In short, the legacy of 3.x >> > support was destabilizing 4.x itself (including testing), not just >> > interfering with 6.x moving forward beyond 3.x index compatibility. So, 5.x >> > will have less baggage holding it down than 4.x has today. >> > >> > I still need answers to: >> > >> > 1. Will users of 5.0 get any immediate benefit by reindexing or >> > otherwise "upgrading" their 4.x indexes to 5.0? >> >> Yes, for all the reasons Robert already mentioned. >> >> > >> > 2. What is the easiest, most efficient way for users of 5.0 to upgrade >> > their 4.x indexes to 5.0 so that they will not have to worry or do anything >> > when 6.0 comes out? >> >> Again, users should always upgrade if possible.
[jira] [Comment Edited] (LUCENE-5989) Add BinaryField, to index a single binary token
[ https://issues.apache.org/jira/browse/LUCENE-5989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159500#comment-14159500 ] Shai Erera edited comment on LUCENE-5989 at 10/5/14 1:53 PM: - bq. we could maybe instead just add a ctor for StringField taking BytesRef... We could also rename StringField to KeywordField, making it more obvious that this field isn't tokenized. Then a KeywordField can take a String or BytesRef in ctors. was (Author: shaie): bq. we could maybe instead just add a ctor for StringField taking BytesRef... We could also rename StringField to KeywordField, making it more obvious that this field isn't tokenized. Then a KeywordsField can take a String or BytesRef in ctors. > Add BinaryField, to index a single binary token > --- > > Key: LUCENE-5989 > URL: https://issues.apache.org/jira/browse/LUCENE-5989 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 5.0, Trunk > > Attachments: LUCENE-5989.patch > > > 5 years ago (LUCENE-1458) we "enabled" fully binary terms in the > lowest levels of Lucene (the codec APIs) yet today, actually adding an > arbitrary byte[] binary term during indexing is far from simple: you > must make a custom Field with a custom TokenStream and a custom > TermToBytesRefAttribute, as far as I know. > This is supremely expert, I wonder if anyone out there has succeeded > in doing so? > I think we should make indexing a single byte[] as simple as indexing > a single String. > This is a pre-cursor for issues like LUCENE-5596 (encoding IPv6 > address as byte[16]) and LUCENE-5879 (encoding native numeric values > in their simple binary form). -- 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
Re: 5.0 release status?
To be clear, I myself am not trying to offer advice on whether or when people should upgrade – I’m trying solely to determine if there is significant value to do so, and what that value might be. I did indeed read through Robert’s list and have watched the Jira flow over the years, but I am unable to pinpoint “significant” improvements that will have more than just a “minor” impact for users. I’m not trying to say that significant improvements aren’t actually in there, just that I don’t know of any. If I am wrong, please provide the details. Like... are there use cases where the 5.0 index will be at least 10% faster or at least 10% smaller, and if so, which specific features and use cases? Or if there is a cumulative improvement in performance or capacity. Or... if there are specific feature transitions to recommend that would result in dramatic improvements. I mean, as things stand, there has been a lot of “shuffling around”, but no clear, quantified insight on the benefits of that shuffling/refactoring. I’m all for cleaner code (which can manifest as more reliable and less bugs), but is that is gist of most of the index changes? In short, I’m more interested in the impact of the 5.0 index changes (and their use cases), not the details of the implementation of those changes. Put another way, will a typical app be at least 10% faster or 10% smaller (or both!) when its index is converted from 4.x to 5.0? Or 5% or 20% or... whatever it actually is? And if there are specific new features that rely on conversion to 5.0 index format, lets get that list collected as some bullet points. Call this preparation for the 5.0 release! Maybe it could be a summary section in the 5.0 migration guide. Clearly there is plenty of goodness in the 5.0 work, but I’m just trying to get a handle on the overall impact. -- Jack Krupansky From: Ryan Ernst Sent: Sunday, October 5, 2014 12:48 AM To: dev@lucene.apache.org Subject: Re: 5.0 release status? On Oct 4, 2014 9:35 PM, "Jack Krupansky" wrote: > > Maybe I just can’t fully make sense of LUCENE-5934 – does it corrupt all 4.x > indexes, or some, or under some conditions? I mean, I had the impression that > it was only non-GA 4.0 indexes. And was it only 4.10 that was doing this, or > 4.0 GA through 4.9 as well? The bug only affected people using the 4.10.0 release to read 4.0 beta/final segments (it thought they were 3x indexes). > > In any case, I’m still not clear on the direct benefits to users of, say, 4.9 > upgrading to 5.0 indexes. Any performance improvement? Any disk space > reduction? Any RAM reduction? Again, read through all the stuff Robert has mentioned, read through lucene/CHANGES.txt, read the issues that are currently open. Your previous comments have suggested users upgrading to 5.0 would only do so so they can eventually upgrade to 6.0, implying they wouldn't upgrade their indexes for minor releases. This simply is not the best advice. Look back at 4.9 and 4.10 for recent improvements in heap usage for doc values and norms for example. Going back farther, someone still on 4.0 doesn't benefit from the postings format improvements in 4.1. Users should upgrade their format whenever possible because improvements are always happening. > > -- Jack Krupansky > > From: Ryan Ernst > Sent: Sunday, October 5, 2014 12:24 AM > To: dev@lucene.apache.org > Subject: Re: 5.0 release status? > > > > On Oct 4, 2014 9:13 PM, "Jack Krupansky" wrote: > > > > Thanks for the further clarification. In short, the legacy of 3.x support > > was destabilizing 4.x itself (including testing), not just interfering with > > 6.x moving forward beyond 3.x index compatibility. So, 5.x will have less > > baggage holding it down than 4.x has today. > > > > I still need answers to: > > > > 1. Will users of 5.0 get any immediate benefit by reindexing or otherwise > > "upgrading" their 4.x indexes to 5.0? > > Yes, for all the reasons Robert already mentioned. > > > > > 2. What is the easiest, most efficient way for users of 5.0 to upgrade > > their 4.x indexes to 5.0 so that they will not have to worry or do anything > > when 6.0 comes out? > > Again, users should always upgrade if possible. There are improvements for > memory and speed all the time. Currently they can use the IndexUpgrader > (offline) or wrap there merge policy with UpgradeIndexMergePolicy (although > both currently act like an optimize on the old segments, im hoping to change > that soon). > > Ryan > > > > > -- Jack Krupansky > > > > -Original Message- From: Robert Muir > > Sent: Saturday, October 4, 2014 10:43 PM > > > > To: dev@lucene.apache.org > > Subject: Re: 5.0 release status? > > > > On Sat, Oct 4, 2014 at 12:35 PM, Jack Krupansky > > wrote: > >> > >> I tried to follow all of the trunk 6/branch 5x discussion, but... AFAICT > >> there was no explicit decision or even implication that a release 5.0 would > >> be imminent or that there would not be a
[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b28) - Build # 11237 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11237/ Java: 64bit/jdk1.9.0-ea-b28 -XX:-UseCompressedOops -XX:+UseG1GC 5 tests failed. FAILED: org.apache.solr.client.solrj.SolrExampleBinaryTest.testExampleConfig Error Message: Expected mime type application/octet-stream but got text/html. Error 404 Can not find: /solr/admin/info/system HTTP ERROR: 404 Problem accessing /solr/admin/info/system. Reason: Can not find: /solr/admin/info/system Powered by Jetty:// Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Expected mime type application/octet-stream but got text/html. Error 404 Can not find: /solr/admin/info/system HTTP ERROR: 404 Problem accessing /solr/admin/info/system. Reason: Can not find: /solr/admin/info/system Powered by Jetty:// at __randomizedtesting.SeedInfo.seed([52C2BA58AA8B46D5:E5EFAEC06D8CA00C]:0) at org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:530) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:215) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:211) at org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:91) at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:301) at org.apache.solr.client.solrj.SolrExampleTests.testExampleConfig(SolrExampleTests.java:220) 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:484) 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.rand
[JENKINS-MAVEN] Lucene-Solr-Maven-trunk #1227: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/1227/ 5 tests failed. REGRESSION: org.apache.solr.client.solrj.SolrExampleBinaryTest.testExampleConfig Error Message: Expected mime type application/octet-stream but got text/html. Error 404 Can not find: /solr/admin/info/system HTTP ERROR: 404 Problem accessing /solr/admin/info/system. Reason: Can not find: /solr/admin/info/system Powered by Jetty:// Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Expected mime type application/octet-stream but got text/html. Error 404 Can not find: /solr/admin/info/system HTTP ERROR: 404 Problem accessing /solr/admin/info/system. Reason: Can not find: /solr/admin/info/system Powered by Jetty:// at __randomizedtesting.SeedInfo.seed([B2BB8B1D738D1977:5969F85B48AFFAE]:0) at org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:530) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:215) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:211) at org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:91) at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:301) at org.apache.solr.client.solrj.SolrExampleTests.testExampleConfig(SolrExampleTests.java:220) 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)
[JENKINS] Lucene-Solr-5.x-MacOSX (64bit/jdk1.7.0) - Build # 1828 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/1828/ Java: 64bit/jdk1.7.0 -XX:+UseCompressedOops -XX:+UseParallelGC 1 tests failed. REGRESSION: org.apache.solr.cloud.DeleteReplicaTest.testDistribSearch Error Message: No live SolrServers available to handle this request:[http://127.0.0.1:58873, http://127.0.0.1:58879, http://127.0.0.1:58868, http://127.0.0.1:58876, http://127.0.0.1:58882] Stack Trace: org.apache.solr.client.solrj.SolrServerException: No live SolrServers available to handle this request:[http://127.0.0.1:58873, http://127.0.0.1:58879, http://127.0.0.1:58868, http://127.0.0.1:58876, http://127.0.0.1:58882] at __randomizedtesting.SeedInfo.seed([A31F52F079E3C54D:22F9DCE80EBCA571]:0) at org.apache.solr.client.solrj.impl.LBHttpSolrServer.request(LBHttpSolrServer.java:322) at org.apache.solr.client.solrj.impl.CloudSolrServer.sendRequest(CloudSolrServer.java:880) at org.apache.solr.client.solrj.impl.CloudSolrServer.requestWithRetryOnStaleState(CloudSolrServer.java:658) at org.apache.solr.client.solrj.impl.CloudSolrServer.request(CloudSolrServer.java:601) at org.apache.solr.cloud.DeleteReplicaTest.removeAndWaitForReplicaGone(DeleteReplicaTest.java:172) at org.apache.solr.cloud.DeleteReplicaTest.deleteLiveReplicaTest(DeleteReplicaTest.java:145) at org.apache.solr.cloud.DeleteReplicaTest.doTest(DeleteReplicaTest.java:89) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869) at sun.reflect.GeneratedMethodAccessor64.invoke(Unknown Source) 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(StatementAdapt
[jira] [Commented] (LUCENE-5989) Add BinaryField, to index a single binary token
[
https://issues.apache.org/jira/browse/LUCENE-5989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159515#comment-14159515
]
Robert Muir commented on LUCENE-5989:
-
{quote}
This is supremely expert, I wonder if anyone out there has succeeded
in doing so?
{quote}
So the solution is to proceed and make matters worse by requiring the user to
*also* deal with the .document API?
If the user wants their field to work with various query-time features
(queryparser, morelikethis, whatever), then they must deal with the tokenstream
side anyway, so adding *Field doesn't help anything. It just adds yet another
place they must plug in "schema" information (as opposed to only being once in
Analyzer). Sure, its easier to get past indexwriter maybe, but you win the
battle and lose the war.
I'm not going to try to block the change, just please, please, please think
about it.
> Add BinaryField, to index a single binary token
> ---
>
> Key: LUCENE-5989
> URL: https://issues.apache.org/jira/browse/LUCENE-5989
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-5989.patch
>
>
> 5 years ago (LUCENE-1458) we "enabled" fully binary terms in the
> lowest levels of Lucene (the codec APIs) yet today, actually adding an
> arbitrary byte[] binary term during indexing is far from simple: you
> must make a custom Field with a custom TokenStream and a custom
> TermToBytesRefAttribute, as far as I know.
> This is supremely expert, I wonder if anyone out there has succeeded
> in doing so?
> I think we should make indexing a single byte[] as simple as indexing
> a single String.
> This is a pre-cursor for issues like LUCENE-5596 (encoding IPv6
> address as byte[16]) and LUCENE-5879 (encoding native numeric values
> in their simple binary form).
--
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-5989) Add BinaryField, to index a single binary token
[
https://issues.apache.org/jira/browse/LUCENE-5989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159511#comment-14159511
]
Jack Krupansky commented on LUCENE-5989:
bq. rename StringField to KeywordField, making it more obvious that this field
isn't tokenized. Then a KeywordsField can take a String or BytesRef in ctors.
Both Lucene and Solr are suffering from a conflation of the two concepts of
treating an input stream as a single token ("a keyword") and as a sequence of
tokens ("sequence of keywords"). We have the "KeywordTokenizer" that does NOT
tokenize the input stream into "a sequence of keywords". The term "keyword
search" is commonly used to describe the ability of search engines to find
"individual keywords" in extended streams of "text" - a clear reference to
"keyword" in a tokenized stream.
So, I don't understand how it is claimed that naming StringField to
KeywordField is making anything "obvious" - it seems to me to be adding to the
existing confusion rather than clarifying anything. I mean, the term "keyword"
should be treated more as a synonym for "token" or "term", NOT as synonym for
"string" or "raw character sequence".
I agree that we need a term for "raw, uninterpreted character sequence", but it
seems to me that "string" is a more "obvious" candidate than "keyword".
There has been some grumbling at the Solr level that KeywordTokenizer should be
renamed to... something, anything, but just not KeywordTokenizer, which
"obviously" implied that the input stream will be tokenized into a sequence of
keywords, which it does not.
In an effort to try to resolve this ongoing confusion, can somebody provide
from historical background as to how KeywordTokenizer got its name, and how a
subset of people continue to refer to an uninterpreted sequence of characters
as a "keyword" rather than a string. I checked the Javadoc, Jira, and even the
source code, but came up empty.
In short, it is a real eye-opener to see a claim that the term "keyword" in any
way makes it "obvious" that input is not tokenized!!
Maybe we could fix this for 5.0 to have a cleaner set of terminology going
forward. At a minimum, we should have some clarifying language in the Javadoc.
And hopefully we can refrain from making the confusion/conflation worse by
renaming StringField to KeywordField.
bq. Then a KeywordsField can take a String
Is that simply a typo or is the intent to have both a KeywordField (singular)
and a KeywordsField (plural)? I presume it is a typo, but... maybe it's a
Freudian slip and highlights this semantic difficulty that persists in the
Lucene terminology (and hence infects Solr terminology as well.)
> Add BinaryField, to index a single binary token
> ---
>
> Key: LUCENE-5989
> URL: https://issues.apache.org/jira/browse/LUCENE-5989
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-5989.patch
>
>
> 5 years ago (LUCENE-1458) we "enabled" fully binary terms in the
> lowest levels of Lucene (the codec APIs) yet today, actually adding an
> arbitrary byte[] binary term during indexing is far from simple: you
> must make a custom Field with a custom TokenStream and a custom
> TermToBytesRefAttribute, as far as I know.
> This is supremely expert, I wonder if anyone out there has succeeded
> in doing so?
> I think we should make indexing a single byte[] as simple as indexing
> a single String.
> This is a pre-cursor for issues like LUCENE-5596 (encoding IPv6
> address as byte[16]) and LUCENE-5879 (encoding native numeric values
> in their simple binary form).
--
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-Linux (32bit/jdk1.9.0-ea-b28) - Build # 11390 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11390/ Java: 32bit/jdk1.9.0-ea-b28 -client -XX:+UseParallelGC 5 tests failed. FAILED: org.apache.solr.client.solrj.SolrExampleBinaryTest.testExampleConfig Error Message: Expected mime type application/octet-stream but got text/html. Error 404 Can not find: /solr/admin/info/system HTTP ERROR: 404 Problem accessing /solr/admin/info/system. Reason: Can not find: /solr/admin/info/system Powered by Jetty:// Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Expected mime type application/octet-stream but got text/html. Error 404 Can not find: /solr/admin/info/system HTTP ERROR: 404 Problem accessing /solr/admin/info/system. Reason: Can not find: /solr/admin/info/system Powered by Jetty:// at __randomizedtesting.SeedInfo.seed([7AA362A64B6B35FE:CD8E763E8C6CD327]:0) at org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:530) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:215) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:211) at org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:91) at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:301) at org.apache.solr.client.solrj.SolrExampleTests.testExampleConfig(SolrExampleTests.java:220) 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:484) 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.randomizedt
[jira] [Commented] (LUCENE-5989) Add BinaryField, to index a single binary token
[ https://issues.apache.org/jira/browse/LUCENE-5989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159507#comment-14159507 ] Uwe Schindler commented on LUCENE-5989: --- bq. We could also rename StringField to KeywordField, making it more obvious that this field isn't tokenized. Then a KeywordsField can take a String or BytesRef in ctors. +1 bq. Patch, adding BinaryField I don't like the violation that clear() is a no-op in BytesTermAttribute. In a correct world, this should null the bytesref and the TokenStream should set the BytesRef after clearAttributes. This is not urgent here, but it violates the contract. I know NumericTermAttribute does similar things... :( > Add BinaryField, to index a single binary token > --- > > Key: LUCENE-5989 > URL: https://issues.apache.org/jira/browse/LUCENE-5989 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 5.0, Trunk > > Attachments: LUCENE-5989.patch > > > 5 years ago (LUCENE-1458) we "enabled" fully binary terms in the > lowest levels of Lucene (the codec APIs) yet today, actually adding an > arbitrary byte[] binary term during indexing is far from simple: you > must make a custom Field with a custom TokenStream and a custom > TermToBytesRefAttribute, as far as I know. > This is supremely expert, I wonder if anyone out there has succeeded > in doing so? > I think we should make indexing a single byte[] as simple as indexing > a single String. > This is a pre-cursor for issues like LUCENE-5596 (encoding IPv6 > address as byte[16]) and LUCENE-5879 (encoding native numeric values > in their simple binary form). -- 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-5989) Add BinaryField, to index a single binary token
[ https://issues.apache.org/jira/browse/LUCENE-5989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159500#comment-14159500 ] Shai Erera commented on LUCENE-5989: bq. we could maybe instead just add a ctor for StringField taking BytesRef... We could also rename StringField to KeywordField, making it more obvious that this field isn't tokenized. Then a KeywordsField can take a String or BytesRef in ctors. > Add BinaryField, to index a single binary token > --- > > Key: LUCENE-5989 > URL: https://issues.apache.org/jira/browse/LUCENE-5989 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 5.0, Trunk > > Attachments: LUCENE-5989.patch > > > 5 years ago (LUCENE-1458) we "enabled" fully binary terms in the > lowest levels of Lucene (the codec APIs) yet today, actually adding an > arbitrary byte[] binary term during indexing is far from simple: you > must make a custom Field with a custom TokenStream and a custom > TermToBytesRefAttribute, as far as I know. > This is supremely expert, I wonder if anyone out there has succeeded > in doing so? > I think we should make indexing a single byte[] as simple as indexing > a single String. > This is a pre-cursor for issues like LUCENE-5596 (encoding IPv6 > address as byte[16]) and LUCENE-5879 (encoding native numeric values > in their simple binary form). -- 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-5969) Add Lucene50Codec
[ https://issues.apache.org/jira/browse/LUCENE-5969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159496#comment-14159496 ] Uwe Schindler commented on LUCENE-5969: --- Cool! Very nice! I also checked how the "conventional" merging with a dumb foreign (filter) reader is wrapped and if its tested correctly :-) > Add Lucene50Codec > - > > Key: LUCENE-5969 > URL: https://issues.apache.org/jira/browse/LUCENE-5969 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless > Fix For: 5.0, Trunk > > Attachments: LUCENE-5969.patch, LUCENE-5969.patch, > LUCENE-5969_part2.patch > > > Spinoff from LUCENE-5952: > * Fix .si to write Version as 3 ints, not a String that requires parsing at > read time. > * Lucene42TermVectorsFormat should not use the same codecName as > Lucene41StoredFieldsFormat > It would also be nice if we had a "bumpCodecVersion" script so rolling a new > codec is not so daunting. -- 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.7.0) - Build # 1868 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/1868/ Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseG1GC 5 tests failed. FAILED: org.apache.solr.client.solrj.SolrExampleBinaryTest.testExampleConfig Error Message: Expected mime type application/octet-stream but got text/html. Error 404 Can not find: /solr/admin/info/system HTTP ERROR: 404 Problem accessing /solr/admin/info/system. Reason: Can not find: /solr/admin/info/system Powered by Jetty:// Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Expected mime type application/octet-stream but got text/html. Error 404 Can not find: /solr/admin/info/system HTTP ERROR: 404 Problem accessing /solr/admin/info/system. Reason: Can not find: /solr/admin/info/system Powered by Jetty:// at __randomizedtesting.SeedInfo.seed([44241F52C6B88CBA:F3090BCA01BF6A63]:0) at org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:530) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:215) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:211) at org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:91) at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:301) at org.apache.solr.client.solrj.SolrExampleTests.testExampleConfig(SolrExampleTests.java:220) 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.randomize
[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_40-ea-b04) - Build # 11236 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11236/ Java: 64bit/jdk1.8.0_40-ea-b04 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 5 tests failed. FAILED: org.apache.solr.client.solrj.SolrExampleBinaryTest.testExampleConfig Error Message: Expected mime type application/octet-stream but got text/html. Error 404 Can not find: /solr/admin/info/system HTTP ERROR: 404 Problem accessing /solr/admin/info/system. Reason: Can not find: /solr/admin/info/system Powered by Jetty:// Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Expected mime type application/octet-stream but got text/html. Error 404 Can not find: /solr/admin/info/system HTTP ERROR: 404 Problem accessing /solr/admin/info/system. Reason: Can not find: /solr/admin/info/system Powered by Jetty:// at __randomizedtesting.SeedInfo.seed([55A1A13019956444:E28CB5A8DE92829D]:0) at org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:530) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:215) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:211) at org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:91) at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:301) at org.apache.solr.client.solrj.SolrExampleTests.testExampleConfig(SolrExampleTests.java:220) 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.car
[jira] [Commented] (LUCENE-5969) Add Lucene50Codec
[ https://issues.apache.org/jira/browse/LUCENE-5969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159484#comment-14159484 ] Michael McCandless commented on LUCENE-5969: +1 to merge branch back, patch looks awesome. > Add Lucene50Codec > - > > Key: LUCENE-5969 > URL: https://issues.apache.org/jira/browse/LUCENE-5969 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless > Fix For: 5.0, Trunk > > Attachments: LUCENE-5969.patch, LUCENE-5969.patch, > LUCENE-5969_part2.patch > > > Spinoff from LUCENE-5952: > * Fix .si to write Version as 3 ints, not a String that requires parsing at > read time. > * Lucene42TermVectorsFormat should not use the same codecName as > Lucene41StoredFieldsFormat > It would also be nice if we had a "bumpCodecVersion" script so rolling a new > codec is not so daunting. -- 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-5879) Add auto-prefix terms to block tree terms dict
[ https://issues.apache.org/jira/browse/LUCENE-5879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159483#comment-14159483 ] Michael McCandless commented on LUCENE-5879: I think we can salvage parts of this patch by crumbling it up and breaking out separately committable pre-cursors ... I opened LUCENE-5879 to make it easier to index a single byte[] token. After that maybe we could break out the CheckIndex improvements for testing the Codec's impl of .intersect, adding Automata.makeBinaryRange. But there's still a huge gaping API hole, which is how the app can "easily"/"cleanly" notify Lucene that it intends to do range filtering on a given field: this is still a hard open question. > Add auto-prefix terms to block tree terms dict > -- > > Key: LUCENE-5879 > URL: https://issues.apache.org/jira/browse/LUCENE-5879 > Project: Lucene - Core > Issue Type: New Feature > Components: core/codecs >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 5.0, Trunk > > Attachments: LUCENE-5879.patch, LUCENE-5879.patch, LUCENE-5879.patch, > LUCENE-5879.patch, LUCENE-5879.patch, LUCENE-5879.patch, LUCENE-5879.patch, > LUCENE-5879.patch, LUCENE-5879.patch, LUCENE-5879.patch > > > This cool idea to generalize numeric/trie fields came from Adrien: > Today, when we index a numeric field (LongField, etc.) we pre-compute > (via NumericTokenStream) outside of indexer/codec which prefix terms > should be indexed. > But this can be inefficient: you set a static precisionStep, and > always add those prefix terms regardless of how the terms in the field > are actually distributed. Yet typically in real world applications > the terms have a non-random distribution. > So, it should be better if instead the terms dict decides where it > makes sense to insert prefix terms, based on how dense the terms are > in each region of term space. > This way we can speed up query time for both term (e.g. infix > suggester) and numeric ranges, and it should let us use less index > space and get faster range queries. > > This would also mean that min/maxTerm for a numeric field would now be > correct, vs today where the externally computed prefix terms are > placed after the full precision terms, causing hairy code like > NumericUtils.getMaxInt/Long. So optos like LUCENE-5860 become > feasible. > The terms dict can also do tricks not possible if you must live on top > of its APIs, e.g. to handle the adversary/over-constrained case when a > given prefix has too many terms following it but finer prefixes > have too few (what block tree calls "floor term blocks"). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-5.x - Build # 640 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/640/ 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.handler.TestReplicationHandler Error Message: Resource in scope SUITE failed to close. Resource was registered from thread Thread[id=2669, name=coreLoadExecutor-1361-thread-1, state=RUNNABLE, group=TGRP-TestReplicationHandler], registration stack trace below. Stack Trace: com.carrotsearch.randomizedtesting.ResourceDisposalError: Resource in scope SUITE failed to close. Resource was registered from thread Thread[id=2669, name=coreLoadExecutor-1361-thread-1, state=RUNNABLE, group=TGRP-TestReplicationHandler], registration stack trace below. at __randomizedtesting.SeedInfo.seed([E8AC740FA82B70BE]:0) at java.lang.Thread.getStackTrace(Thread.java:1589) at com.carrotsearch.randomizedtesting.RandomizedContext.closeAtEnd(RandomizedContext.java:166) at org.apache.lucene.util.LuceneTestCase.closeAfterSuite(LuceneTestCase.java:688) at org.apache.lucene.util.LuceneTestCase.wrapDirectory(LuceneTestCase.java:1231) at org.apache.lucene.util.LuceneTestCase.newDirectory(LuceneTestCase.java:1122) at org.apache.lucene.util.LuceneTestCase.newDirectory(LuceneTestCase.java:1114) at org.apache.solr.core.MockDirectoryFactory.create(MockDirectoryFactory.java:47) at org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:350) at org.apache.solr.core.SolrCore.getNewIndexDir(SolrCore.java:276) at org.apache.solr.core.SolrCore.initIndex(SolrCore.java:488) at org.apache.solr.core.SolrCore.(SolrCore.java:794) at org.apache.solr.core.SolrCore.(SolrCore.java:652) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:509) at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:273) at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:267) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.AssertionError: Directory not closed: MockDirectoryWrapper(NIOFSDirectory@/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler-E8AC740FA82B70BE-001/index-NIOFSDirectory-035 lockFactory=NativeFSLockFactory@/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler-E8AC740FA82B70BE-001/index-NIOFSDirectory-035) at org.junit.Assert.fail(Assert.java:93) at org.apache.lucene.util.CloseableDirectory.close(CloseableDirectory.java:47) at com.carrotsearch.randomizedtesting.RandomizedRunner$2$1.apply(RandomizedRunner.java:699) at com.carrotsearch.randomizedtesting.RandomizedRunner$2$1.apply(RandomizedRunner.java:696) at com.carrotsearch.randomizedtesting.RandomizedContext.closeResources(RandomizedContext.java:183) at com.carrotsearch.randomizedtesting.RandomizedRunner$2.afterAlways(RandomizedRunner.java:712) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) ... 1 more Build Log: [...truncated 12661 lines...] [junit4] Suite: org.apache.solr.handler.TestReplicationHandler [junit4] 2> Creating dataDir: /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler-E8AC740FA82B70BE-001/init-core-data-001 [junit4] 2> 1414627 T2114 oas.SolrTestCaseJ4.setUp ###Starting doTestStopPoll [junit4] 2> 1414644 T2114 oejs.Server.doStart jetty-8.1.10.v20130312 [junit4] 2> 1414650 T2114 oejs.AbstractConnector.doStart Started SocketConnector@127.0.0.1:20795 [junit4] 2> 1414651 T2114 oass.SolrDispatchFilter.init SolrDispatchFilter.init() [junit4] 2> 1414651 T2114 oasc.SolrResourceLoader.locateSolrHome JNDI not configured for solr (NoInitialContextEx) [junit4] 2> 1414652 T2114 oasc.SolrResourceLoader.locateSolrHome using system property solr.solr.home: /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler-E8AC740FA82B70BE-001/solr-instance-001 [junit4] 2> 1414652 T2114 oasc.SolrResourceLoader. new SolrResourceLoader for directory: '/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler-E8AC740FA82B70BE-001/solr-instance-001/' [junit4] 2> 1414717 T2114 oasc.ConfigSolr.fromFile Loading containe
[jira] [Updated] (LUCENE-5989) Add BinaryField, to index a single binary token
[ https://issues.apache.org/jira/browse/LUCENE-5989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-5989: --- Attachment: LUCENE-5989.patch Patch, adding BinaryField... the field types are the same as StringField so we could maybe instead just add a ctor for StringField taking BytesRef... > Add BinaryField, to index a single binary token > --- > > Key: LUCENE-5989 > URL: https://issues.apache.org/jira/browse/LUCENE-5989 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 5.0, Trunk > > Attachments: LUCENE-5989.patch > > > 5 years ago (LUCENE-1458) we "enabled" fully binary terms in the > lowest levels of Lucene (the codec APIs) yet today, actually adding an > arbitrary byte[] binary term during indexing is far from simple: you > must make a custom Field with a custom TokenStream and a custom > TermToBytesRefAttribute, as far as I know. > This is supremely expert, I wonder if anyone out there has succeeded > in doing so? > I think we should make indexing a single byte[] as simple as indexing > a single String. > This is a pre-cursor for issues like LUCENE-5596 (encoding IPv6 > address as byte[16]) and LUCENE-5879 (encoding native numeric values > in their simple binary form). -- 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-5989) Add BinaryField, to index a single binary token
Michael McCandless created LUCENE-5989: -- Summary: Add BinaryField, to index a single binary token Key: LUCENE-5989 URL: https://issues.apache.org/jira/browse/LUCENE-5989 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 5.0, Trunk 5 years ago (LUCENE-1458) we "enabled" fully binary terms in the lowest levels of Lucene (the codec APIs) yet today, actually adding an arbitrary byte[] binary term during indexing is far from simple: you must make a custom Field with a custom TokenStream and a custom TermToBytesRefAttribute, as far as I know. This is supremely expert, I wonder if anyone out there has succeeded in doing so? I think we should make indexing a single byte[] as simple as indexing a single String. This is a pre-cursor for issues like LUCENE-5596 (encoding IPv6 address as byte[16]) and LUCENE-5879 (encoding native numeric values in their simple binary form). -- 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-5987) Make indexwriter a mere mortal when exceptions strike
[
https://issues.apache.org/jira/browse/LUCENE-5987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159478#comment-14159478
]
Michael McCandless commented on LUCENE-5987:
+1, let's not be heroic here: IW's exc handling is terrifying.
> Make indexwriter a mere mortal when exceptions strike
> -
>
> Key: LUCENE-5987
> URL: https://issues.apache.org/jira/browse/LUCENE-5987
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Robert Muir
>
> IndexWriter's exception handling is overly complicated. Every method in
> general reads like this:
> {code}
> try {
> try {
> try {
> ...
> // lock order: COMPLICATED
> synchronized(this or that) {
> }
> ...
>} finally {
> if (!success5) {
>deleter.deleteThisFileOrThat();
> }
> ...
> }
> }
> {code}
> Part of the problem is it acts like its an invincible superhero, e.g. can
> take a disk full on merge or flush to the face and just keep on trucking, and
> you can somehow fix the root cause and then just go about making commits on
> the same instance.
> But we have a hard enough time ensuring exceptions dont do the wrong thing
> (e.g. cause corruption), and I don't think we really test this crazy behavior
> anywhere: e.g. making commits AFTER hitting disk full and so on.
> It would probably be simpler if when such things happen, IW just considered
> them "tragic" just like OOM and rolled itself back, instead of doing all
> kinds of really scary stuff to try to "keep itself healthy" (like the little
> dance it plays with IFD in mergeMiddle manually deleting CFS files).
> Besides, without something like a WAL, Indexwriter isn't really fit to be a
> superhero anyway: it can't prevent you from losing data in such situations.
> It just doesn't have the right tools for the job.
> edit: just to be clear I am referring to abort (low level exception during
> flush) and exceptions during merge. For simple non-aborting cases like
> analyzer errors, of course we can deal with this. We already made great
> progress on turning a lot of BS exceptions that would cause aborts into
> non-aborting ones recently.
--
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-Linux (64bit/jdk1.8.0_40-ea-b04) - Build # 11389 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11389/ Java: 64bit/jdk1.8.0_40-ea-b04 -XX:-UseCompressedOops -XX:+UseG1GC 11 tests failed. REGRESSION: org.apache.solr.client.solrj.SolrExampleBinaryTest.testChildDoctransformer Error Message: Expected mime type application/octet-stream but got text/html. Error 500 Server Error HTTP ERROR: 500 Problem accessing /solr/collection1/select. Reason: Server Error Powered by Jetty:// Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Expected mime type application/octet-stream but got text/html. Error 500 Server Error HTTP ERROR: 500 Problem accessing /solr/collection1/select. Reason: Server Error Powered by Jetty:// at __randomizedtesting.SeedInfo.seed([CE49354771E836AD:BD932ADDFDF041AB]:0) at org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:530) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:215) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:211) at org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:91) at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:301) at org.apache.solr.client.solrj.SolrExampleTests.testChildDoctransformer(SolrExampleTests.java:1373) 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)
