[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+120) - Build # 16886 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16886/
Java: 64bit/jdk-9-ea+120 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
org.apache.solr.common.cloud.TestCollectionStateWatchers.testWaitForStateWatcherIsRetainedOnPredicateFailure

Error Message:
Did not see a fully active cluster after 30 seconds

Stack Trace:
java.lang.AssertionError: Did not see a fully active cluster after 30 seconds
at 
__randomizedtesting.SeedInfo.seed([34E75E20242312A2:BCD1FC73FC8CFAB0]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.common.cloud.TestCollectionStateWatchers.testWaitForStateWatcherIsRetainedOnPredicateFailure(TestCollectionStateWatchers.java:227)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(java.base@9-ea/Thread.java:843)




Build Log:
[...truncated 

[jira] [Commented] (SOLR-9107) add annotation for more fine grained control of SSL per test-class

[Steve Rowe (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15309284#comment-15309284
 ] 

Steve Rowe commented on SOLR-9107:
--

bq. precommit currently complains about malformed javadocs... [...] Anybody 
have any idea what's going on here? Steve Rowe? Uwe Schindler?

See LUCENE-7308

> add annotation for more fine grained control of SSL per test-class
> --
>
> Key: SOLR-9107
> URL: https://issues.apache.org/jira/browse/SOLR-9107
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Hoss Man
> Fix For: 4.9, 6.0
>
> Attachments: SOLR-9107.patch, SOLR-9107.patch
>
>
> Spinning off this idea from my earlier comment in SOLR-5776...
> 
> At some point in the future, after all this soaks, we should consider 
> increasing the odds of using SSL – perhaps even add a new annotation (or 
> replace @SupressSSL) with a param to help control the odds of using SSL / 
> clientAuth on a per-class basis, ie...
> {noformat}
>   @UseSSL(false) // same as @SupressSSL
>   @UseSSL() //  same as default if no annotation: SolrTestCaseJ4 picks SSL / 
> clientAuth using LuceneTestCase.rarely
>   @UseSSL(ssl=0.75,clientAuth=0.25) // fine control of odds of using ssl & 
> clientauth
> {noformat}
> ...some tests, like TestSSLRandomization should ideally have much higher odds 
> of using SSL then other tests, and if we had an easy way to say "these 
> handful of simple cloud tests should use SSL very frequently" then it 
> wouldn't matter so much if the odds of other really 'expensive' tests only 
> use SSL once in a blue moon.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-7308) checkJavaDocs.py mis-chunks javadocs HTML and then wrongly reports imbalanced tags

[Steve Rowe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Rowe updated LUCENE-7308:
---
Attachment: LUCENE-7308.patch

Patch re-implementing the checkClassDetails() chunking procedure, to pull out 
chunks bounded by {{}}, starting at {{}}, and ending at {{}}, but 
only checking for balanced tags within the most deeply nested {{}}-s, where 
the detailed javadocs go.

When I manually insert imbalanced tags in the detail items in a generated HTML 
file, the script finds them, including the final item, which the current 
implementation does not find.

With the latest patch on SOLR-9107, and this patch, {{ant documentation-lint}} 
succeeds at the top level.

> checkJavaDocs.py mis-chunks javadocs HTML and then wrongly reports imbalanced 
> tags
> --
>
> Key: LUCENE-7308
> URL: https://issues.apache.org/jira/browse/LUCENE-7308
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
> Attachments: LUCENE-7308.patch
>
>
> Spin-off from SOLR-9107, where [~hossman] wrote:
> {quote}
> but as things stand with this patch, precommit currently complains about 
> malformed javadocs...
> {noformat}
>  [echo] Checking for malformed docs...
>  [exec] 
>  [exec] 
> /home/hossman/lucene/dev/solr/build/docs/solr-test-framework/org/apache/solr/util/RandomizeSSL.html
>  [exec]   broken details HTML: Field Detail: reason: saw closing "" 
> without opening 
>  [exec]   broken details HTML: Field Detail: ssl: saw closing "" 
> without opening 
>  [exec]   broken details HTML: Field Detail: clientAuth: saw closing 
> "" without opening 
> {noformat}
> ...but i can't really understand why. The  tags look balanced to me, and 
> tidy -output /dev/null .../RandomizeSSL.html concurs that "No warnings or 
> errors were found." I thought maybe the problem was related to some of the 
> @see tags in the docs for these attributes, but even if i completley remove 
> the javadocs the same validation errors occur.
> {quote}
> When I modify {{checkJavaDocs.py}} to print out the offending chunk of HTML, 
> here's what I see for the first of the above:
> {noformat}
> solr/build/docs/solr-test-framework/org/apache/solr/util/RandomizeSSL.html
>   broken details HTML: Field Detail: reason: saw closing "" without 
> opening  in:
> -
> public abstract href="https://docs.oracle.com/javase/8/docs/api/java/lang/String.html?is-external=true;
>  title="class or interface in java.lang">Stringreason
> Comment to inlcude when logging details of SSL 
> randomization
> 
> Default:
> ""
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> {noformat}
> So the chunking that's happening here isn't aligning with the detail HTML for 
> methods, fields etc. - it doesn't start early enough and ends too late.
> Furthormore, I can see that the chunking procedure ignores the final item in 
> an HTML file (the stuff after the last {{}}) - if I insert trash after 
> the final , but within the javadocs for the corresponding final detail 
> item in the HTML file, the current implementation ignores the problem.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-7308) checkJavaDocs.py mis-chunks javadocs HTML and then wrongly reports imbalanced tags

[Steve Rowe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Rowe updated LUCENE-7308:
---
Description: 
Spin-off from SOLR-9107, where [~hossman] wrote:

{quote}
but as things stand with this patch, precommit currently complains about 
malformed javadocs...
{noformat}
 [echo] Checking for malformed docs...
 [exec] 
 [exec] 
/home/hossman/lucene/dev/solr/build/docs/solr-test-framework/org/apache/solr/util/RandomizeSSL.html
 [exec]   broken details HTML: Field Detail: reason: saw closing "" 
without opening 
 [exec]   broken details HTML: Field Detail: ssl: saw closing "" 
without opening 
 [exec]   broken details HTML: Field Detail: clientAuth: saw closing 
"" without opening 
{noformat}
...but i can't really understand why. The  tags look balanced to me, and 
tidy -output /dev/null .../RandomizeSSL.html concurs that "No warnings or 
errors were found." I thought maybe the problem was related to some of the @see 
tags in the docs for these attributes, but even if i completley remove the 
javadocs the same validation errors occur.
{quote}

When I modify {{checkJavaDocs.py}} to print out the offending chunk of HTML, 
here's what I see for the first of the above:

{noformat}
solr/build/docs/solr-test-framework/org/apache/solr/util/RandomizeSSL.html
  broken details HTML: Field Detail: reason: saw closing "" without 
opening  in:
-
public abstracthttps://docs.oracle.com/javase/8/docs/api/java/lang/String.html?is-external=true;
 title="class or interface in java.lang">Stringreason
Comment to inlcude when logging details of SSL 
randomization

Default:
""












{noformat}

So the chunking that's happening here isn't aligning with the detail HTML for 
methods, fields etc. - it doesn't start early enough and ends too late.

Furthormore, I can see that the chunking procedure ignores the final item in an 
HTML file (the stuff after the last {{}}) - if I insert trash after the 
final , but within the javadocs for the corresponding final detail item in 
the HTML file, the current implementation ignores the problem.

  was:
Spin-off from SOLR-9107, where [~hossman] wrote:

{quote}
but as things stand with this patch, precommit currently complains about 
malformed javadocs...
{noformat}
 [echo] Checking for malformed docs...
 [exec] 
 [exec] 
/home/hossman/lucene/dev/solr/build/docs/solr-test-framework/org/apache/solr/util/RandomizeSSL.html
 [exec]   broken details HTML: Field Detail: reason: saw closing "" 
without opening 
 [exec]   broken details HTML: Field Detail: ssl: saw closing "" 
without opening 
 [exec]   broken details HTML: Field Detail: clientAuth: saw closing 
"" without opening 
{noformat}
...but i can't really understand why. The  tags look balanced to me, and 
tidy -output /dev/null .../RandomizeSSL.html concurs that "No warnings or 
errors were found." I thought maybe the problem was related to some of the @see 
tags in the docs for these attributes, but even if i completley remove the 
javadocs the same validation errors occur.
{quote}

When I modify {{checkJavaDocs.py}} to print out the offending chunk of HTML, 
here's what I see for the first of the above:

{noformat}
solr/build/docs/solr-test-framework/org/apache/solr/util/RandomizeSSL.html
  broken details HTML: Field Detail: reason: saw closing "" without 
opening  in:
-
public abstracthttps://docs.oracle.com/javase/8/docs/api/java/lang/String.html?is-external=true;
 title="class or interface in java.lang">Stringreason
Comment to inlcude when logging details of SSL 
randomization

Default:
""












{noformat}

So the chunking that's happening here isn't aligning with the detail HTML for 
methods, fields etc. - it doesn't start early enough and ends too late.

Furthormore, I can see that the chunking procedure ignores the final item in an 
HTML file (the stuff after the last {{}} - if I insert trash after the 
final  (but within the javadocs for the corresponding final detail item in 
the HTML file), the current implementation ignores the problem.


> checkJavaDocs.py mis-chunks javadocs HTML and then wrongly reports imbalanced 
> tags
> --
>
> Key: LUCENE-7308
> URL: https://issues.apache.org/jira/browse/LUCENE-7308
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
>
> Spin-off from SOLR-9107, where [~hossman] wrote:
> {quote}
> but as things stand with this patch, precommit currently complains about 
> malformed javadocs...
> {noformat}
>  [echo] Checking for malformed docs...
>  [exec] 
>  [exec] 
> /home/hossman/lucene/dev/solr/build/docs/solr-test-framework/org/apache/solr/util/RandomizeSSL.html
>  [exec]   broken details HTML: Field Detail: reason: saw closing "" 
> without opening 
>  [exec] 

[jira] [Created] (LUCENE-7308) checkJavaDocs.py mis-chunks javadocs HTML and then wrongly reports imbalanced tags

[Steve Rowe (JIRA)]

Steve Rowe created LUCENE-7308:
--

 Summary: checkJavaDocs.py mis-chunks javadocs HTML and then 
wrongly reports imbalanced tags
 Key: LUCENE-7308
 URL: https://issues.apache.org/jira/browse/LUCENE-7308
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Steve Rowe


Spin-off from SOLR-9107, where [~hossman] wrote:

{quote}
but as things stand with this patch, precommit currently complains about 
malformed javadocs...
{noformat}
 [echo] Checking for malformed docs...
 [exec] 
 [exec] 
/home/hossman/lucene/dev/solr/build/docs/solr-test-framework/org/apache/solr/util/RandomizeSSL.html
 [exec]   broken details HTML: Field Detail: reason: saw closing "" 
without opening 
 [exec]   broken details HTML: Field Detail: ssl: saw closing "" 
without opening 
 [exec]   broken details HTML: Field Detail: clientAuth: saw closing 
"" without opening 
{noformat}
...but i can't really understand why. The  tags look balanced to me, and 
tidy -output /dev/null .../RandomizeSSL.html concurs that "No warnings or 
errors were found." I thought maybe the problem was related to some of the @see 
tags in the docs for these attributes, but even if i completley remove the 
javadocs the same validation errors occur.
{quote}

When I modify {{checkJavaDocs.py}} to print out the offending chunk of HTML, 
here's what I see for the first of the above:

{noformat}
solr/build/docs/solr-test-framework/org/apache/solr/util/RandomizeSSL.html
  broken details HTML: Field Detail: reason: saw closing "" without 
opening  in:
-
public abstracthttps://docs.oracle.com/javase/8/docs/api/java/lang/String.html?is-external=true;
 title="class or interface in java.lang">Stringreason
Comment to inlcude when logging details of SSL 
randomization

Default:
""












{noformat}

So the chunking that's happening here isn't aligning with the detail HTML for 
methods, fields etc. - it doesn't start early enough and ends too late.

Furthormore, I can see that the chunking procedure ignores the final item in an 
HTML file (the stuff after the last {{}} - if I insert trash after the 
final  (but within the javadocs for the corresponding final detail item in 
the HTML file), the current implementation ignores the problem.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 619 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/619/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC

No tests ran.

Build Log:
[...truncated 11482 lines...]
   [junit4] Suite: org.apache.solr.update.HardAutoCommitTest
   [junit4]   2> Creating dataDir: 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/build/solr-core/test/J1/temp/solr.update.HardAutoCommitTest_1402D57A37AC2DFE-001/init-core-data-001
   [junit4]   2> 2122351 INFO  
(SUITE-HardAutoCommitTest-seed#[1402D57A37AC2DFE]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (true)
   [junit4]   2> 2122353 INFO  
(SUITE-HardAutoCommitTest-seed#[1402D57A37AC2DFE]-worker) [] 
o.a.s.SolrTestCaseJ4 initCore
   [junit4]   2> 2122353 INFO  
(SUITE-HardAutoCommitTest-seed#[1402D57A37AC2DFE]-worker) [] 
o.a.s.c.SolrResourceLoader new SolrResourceLoader for directory: 
'/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/core/src/test-files/solr/collection1'
   [junit4]   2> 2122353 INFO  
(SUITE-HardAutoCommitTest-seed#[1402D57A37AC2DFE]-worker) [] 
o.a.s.c.SolrResourceLoader JNDI not configured for solr (NoInitialContextEx)
   [junit4]   2> 2122353 INFO  
(SUITE-HardAutoCommitTest-seed#[1402D57A37AC2DFE]-worker) [] 
o.a.s.c.SolrResourceLoader using system property solr.solr.home: 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/core/src/test-files/solr
   [junit4]   2> 2122353 INFO  
(SUITE-HardAutoCommitTest-seed#[1402D57A37AC2DFE]-worker) [] 
o.a.s.c.SolrResourceLoader Adding 
'file:/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/core/src/test-files/solr/collection1/lib/classes/'
 to classloader
   [junit4]   2> 2122353 INFO  
(SUITE-HardAutoCommitTest-seed#[1402D57A37AC2DFE]-worker) [] 
o.a.s.c.SolrResourceLoader Adding 
'file:/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/core/src/test-files/solr/collection1/lib/README'
 to classloader
   [junit4]   2> 2122377 INFO  
(SUITE-HardAutoCommitTest-seed#[1402D57A37AC2DFE]-worker) [] 
o.a.s.c.SolrConfig current version of requestparams : -1
   [junit4]   2> 2122384 WARN  
(SUITE-HardAutoCommitTest-seed#[1402D57A37AC2DFE]-worker) [] o.a.s.c.Config 
Beginning with Solr 5.5,  is deprecated, use  
instead.
   [junit4]   2> 2122385 INFO  
(SUITE-HardAutoCommitTest-seed#[1402D57A37AC2DFE]-worker) [] 
o.a.s.c.SolrConfig Using Lucene MatchVersion: 7.0.0
   [junit4]   2> 2122403 INFO  
(SUITE-HardAutoCommitTest-seed#[1402D57A37AC2DFE]-worker) [] 
o.a.s.c.SolrConfig Loaded SolrConfig: solrconfig.xml
   [junit4]   2> 2122414 INFO  
(SUITE-HardAutoCommitTest-seed#[1402D57A37AC2DFE]-worker) [] 
o.a.s.s.IndexSchema [null] Schema name=test
   [junit4]   2> 2122523 INFO  
(SUITE-HardAutoCommitTest-seed#[1402D57A37AC2DFE]-worker) [] 
o.a.s.s.OpenExchangeRatesOrgProvider Initialized with 
rates=open-exchange-rates.json, refreshInterval=1440.
   [junit4]   2> 2122527 INFO  
(SUITE-HardAutoCommitTest-seed#[1402D57A37AC2DFE]-worker) [] 
o.a.s.s.IndexSchema default search field in schema is text
   [junit4]   2> 2122528 INFO  
(SUITE-HardAutoCommitTest-seed#[1402D57A37AC2DFE]-worker) [] 
o.a.s.s.IndexSchema unique key field: id
   [junit4]   2> 2122531 INFO  
(SUITE-HardAutoCommitTest-seed#[1402D57A37AC2DFE]-worker) [] 
o.a.s.s.FileExchangeRateProvider Reloading exchange rates from file currency.xml
   [junit4]   2> 2122532 INFO  
(SUITE-HardAutoCommitTest-seed#[1402D57A37AC2DFE]-worker) [] 
o.a.s.s.FileExchangeRateProvider Reloading exchange rates from file currency.xml
   [junit4]   2> 2122533 INFO  
(SUITE-HardAutoCommitTest-seed#[1402D57A37AC2DFE]-worker) [] 
o.a.s.s.OpenExchangeRatesOrgProvider Reloading exchange rates from 
open-exchange-rates.json
   [junit4]   2> 2122534 INFO  
(SUITE-HardAutoCommitTest-seed#[1402D57A37AC2DFE]-worker) [] 
o.a.s.s.OpenExchangeRatesOrgProvider Reloading exchange rates from 
open-exchange-rates.json
   [junit4]   2> 2122534 INFO  
(SUITE-HardAutoCommitTest-seed#[1402D57A37AC2DFE]-worker) [] 
o.a.s.c.SolrResourceLoader JNDI not configured for solr (NoInitialContextEx)
   [junit4]   2> 2122534 INFO  
(SUITE-HardAutoCommitTest-seed#[1402D57A37AC2DFE]-worker) [] 
o.a.s.c.SolrResourceLoader using system property solr.solr.home: 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/core/src/test-files/solr
   [junit4]   2> 2122534 INFO  
(SUITE-HardAutoCommitTest-seed#[1402D57A37AC2DFE]-worker) [] 
o.a.s.c.SolrResourceLoader new SolrResourceLoader for directory: 
'/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/core/src/test-files/solr'
   [junit4]   2> 2122534 INFO  
(SUITE-HardAutoCommitTest-seed#[1402D57A37AC2DFE]-worker) [] 
o.a.s.c.SolrResourceLoader JNDI not configured for solr (NoInitialContextEx)
   [junit4]   2> 2122534 INFO  
(SUITE-HardAutoCommitTest-seed#[1402D57A37AC2DFE]-worker) [] 
o.a.s.c.SolrResourceLoader using system property 

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_92) - Build # 16885 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16885/
Java: 32bit/jdk1.8.0_92 -server -XX:+UseConcMarkSweepGC

2 tests failed.
FAILED:  org.apache.solr.handler.TestReqParamsAPI.test

Error Message:
Could not get expected value  'CY val' for path 'params/c' full output: {   
"responseHeader":{ "status":0, "QTime":0},   "params":{ "a":"A 
val", "b":"B val", "wt":"json", "useParams":""},   "context":{ 
"webapp":"/q_qu/ii", "path":"/dump1", "httpMethod":"GET"}},  from 
server:  http://127.0.0.1:46529/q_qu/ii/collection1

Stack Trace:
java.lang.AssertionError: Could not get expected value  'CY val' for path 
'params/c' full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "params":{
"a":"A val",
"b":"B val",
"wt":"json",
"useParams":""},
  "context":{
"webapp":"/q_qu/ii",
"path":"/dump1",
"httpMethod":"GET"}},  from server:  
http://127.0.0.1:46529/q_qu/ii/collection1
at 
__randomizedtesting.SeedInfo.seed([D5640F95001631D9:5D30304FAEEA5C21]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:457)
at 
org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:172)
at 
org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:62)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[JENKINS] Lucene-Solr-Tests-master - Build # 1182 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1182/

2 tests failed.
FAILED:  org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test

Error Message:
Expected 2 of 3 replicas to be active but only found 1; 
[core_node2:{"core":"c8n_1x3_lf_shard1_replica3","base_url":"http://127.0.0.1:39653","node_name":"127.0.0.1:39653_","state":"active","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf)={   "replicationFactor":"3",   
"shards":{"shard1":{   "range":"8000-7fff",   "state":"active", 
  "replicas":{ "core_node1":{   "state":"down",   
"base_url":"http://127.0.0.1:37452;,   
"core":"c8n_1x3_lf_shard1_replica2",   "node_name":"127.0.0.1:37452_"}, 
"core_node2":{   "core":"c8n_1x3_lf_shard1_replica3",   
"base_url":"http://127.0.0.1:39653;,   "node_name":"127.0.0.1:39653_",  
 "state":"active",   "leader":"true"}, "core_node3":{   
"core":"c8n_1x3_lf_shard1_replica1",   
"base_url":"http://127.0.0.1:58988;,   "node_name":"127.0.0.1:58988_",  
 "state":"down",   "router":{"name":"compositeId"},   
"maxShardsPerNode":"1",   "autoAddReplicas":"false"}

Stack Trace:
java.lang.AssertionError: Expected 2 of 3 replicas to be active but only found 
1; 
[core_node2:{"core":"c8n_1x3_lf_shard1_replica3","base_url":"http://127.0.0.1:39653","node_name":"127.0.0.1:39653_","state":"active","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf)={
  "replicationFactor":"3",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node1":{
  "state":"down",
  "base_url":"http://127.0.0.1:37452;,
  "core":"c8n_1x3_lf_shard1_replica2",
  "node_name":"127.0.0.1:37452_"},
"core_node2":{
  "core":"c8n_1x3_lf_shard1_replica3",
  "base_url":"http://127.0.0.1:39653;,
  "node_name":"127.0.0.1:39653_",
  "state":"active",
  "leader":"true"},
"core_node3":{
  "core":"c8n_1x3_lf_shard1_replica1",
  "base_url":"http://127.0.0.1:58988;,
  "node_name":"127.0.0.1:58988_",
  "state":"down",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false"}
at 
__randomizedtesting.SeedInfo.seed([40260AD5749A29FD:C872350FDA664405]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:170)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)

[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 504 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/504/

No tests ran.

Build Log:
[...truncated 40507 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 
JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (15.8 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-7.0.0-src.tgz...
   [smoker] 28.6 MB in 0.02 sec (1166.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.0.0.tgz...
   [smoker] 63.0 MB in 0.06 sec (1124.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.0.0.zip...
   [smoker] 73.6 MB in 0.07 sec (1092.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-7.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6011 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6011 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.0.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 221 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [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.2 MB in 0.00 sec (37.4 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-7.0.0-src.tgz...
   [smoker] 37.8 MB in 0.87 sec (43.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.0.0.tgz...
   [smoker] 132.4 MB in 1.10 sec (119.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.0.0.zip...
   [smoker] 141.0 MB in 1.58 sec (89.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-7.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-7.0.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8
   [smoker] Creating Solr home directory 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8/example/techproducts/solr
   [smoker] 
   [smoker] Starting up Solr on port 8983 using command:
   [smoker] bin/solr start -p 8983 -s "example/techproducts/solr"
   [smoker] 
   [smoker] Waiting up to 30 seconds to see Solr running on port 8983 [|]  
 [/]   [-]   [\]   [|]   [/]   [-]   
[\]   [|]  

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_92) - Build # 16884 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16884/
Java: 32bit/jdk1.8.0_92 -server -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.util.SolrPluginUtilsTest.testInvokeSetters

Error Message:
argument type mismatch

Stack Trace:
java.lang.IllegalArgumentException: argument type mismatch
at 
__randomizedtesting.SeedInfo.seed([D7085877C52128C4:BE17F37730174A6F]:0)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.apache.solr.util.SolrPluginUtils.invokeSetters(SolrPluginUtils.java:1071)
at 
org.apache.solr.util.SolrPluginUtilsTest.implTestInvokeSetters(SolrPluginUtilsTest.java:482)
at 
org.apache.solr.util.SolrPluginUtilsTest.testInvokeSetters(SolrPluginUtilsTest.java:474)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

Re: [DISCUSS] Lucene/Solr release management

[Chris Hostetter]

: I was thinking of an alternative documentation/form/to-do list thingy 
: that could provide not just examples, but exact command lines to run.  
: Such a sort of filled-out template thing (is it a “notebook”? not sure 
: what to call it) could provide a running reminder of where the RM is in 
: the process (e.g. checkboxes for items), along with space for notes for 
: each item, and could be scriptable, to fill out command lines with RC 
: numbers and git commit hashes, and to select the appropriate task 
: branches (e.g. for major/minor/bugfix releases).

As someone who has gone out of my way to avoid doing a full release of 
lucene-solr for the precise reasons that it intimidated the fuck out of 
me, i'm the last person to criticise opinions on how to improve the 
process from folks who have actually gone through it themselves (and 
recently!) but changing where/how a big ass long list of manual steps is 
tracked doesn't really seem like very significant progress towards making 
life easier for the RMs.

if keeping track of what's already been done (and making it easier to make 
notes on problematic bits as they happen) then it seems like just cloning 
the "ReleaseTodo" page before the release, and adding a big  HERE 
 that moves down the page as the RM steps through things, and 
NOTE: ... to things above the HERE marker that had 
problems ... then when the release is done, folks can discuss/edit the 
original ReleaseTodo page based on the red notes.

If that sounds hackish to folks i would agree with them -- but it 
seems only slightly more hackish to me then tracking all of this in some 
other todo list tool, or a giant spreedsheet, and wouldn't require porting 
the existing docs into some other tool.


My alternative straw man suggestion would be to make imcremental 
progress on simplifying the steps by writing small scripts to automated as 
many of the steps as possible, and merge those scripts when/where 
possible as we get more confident in them -- with the end goal being that 
ASF jenkins could run the whole thing with a few simple paramaterized jobs 
that are run on demand by RMs... the "create new major branch" job, 
the "create new minor branch" job, and the "create RC" job.

I know i've suggested this before, and folks who have been RMs many times 
have told me it's a bad idea to trust automation for all of this -- but we 
should at least be able to automate *some* of it.  

Even if folks don't agree with the idea of letting scripts commit things 
or pushing RCs to the dist repo, there's still very little reason i can 
think of not to have scripts that *generate* & echo the exact commands 
based on the type of build so it's trivial for the RM to run them 
manually.

(as a trivial example of this in practice, consider the 
publish-solr-ref-guide.sh and archive-solr-ref-guide.sh scripts in 
dev-tools.  A ref guide RM doesn't have to remember the exact SVN commands 
based on the version # being released, or cut/paste the commands from a 
doc and edit them to use the correct version# and RC# -- the scripts take 
that info on the command line and generates the exact svn commands to run 
-- including any "svn rm" commands needed to clean up old RCs based on 
"svn list http:///...; -- ready to copy/paste exactly as is)

The fact that we're using git now, where having all branches "locally" on 
the RM's machine is the default beahvior, should make a lot of this really 
easy.

Consider the "Update Version Numbers in the Source Code" section of the 
doc, with it's conditional logic about major releases, minor releases, bug 
fix releases, and the list branches that diff commands need run on in all 
of these cases.  Couldn't we script this down to a 
"run-addversion-on-needed-branches.sh ~/my-lucene/checkout --next-release 
X.Y.Z" that looks at the passed in X.Y.Z version# and does all the 
neccessary "git co ...", "addVersion.py ...", and "git add ..." needed in 
~/my-lucene/checkout bassed on the branches it finds?  leaving the (local) 
working status of the ~/my-lucene/checkout repo ready for the user to 
review & test as they see fit, so all they have to do is "git push" to the 
ASF repo. (it could even end by echoing out the "git push origin master 
branch_6x ..." command the user should run with a list of every branch it 
touched)


if having a "checklist" is something RMs think would really be helpful -- 
why not at least automate the creation / processing of the checklist as 
much as possible with some simple scripts? 

Imagine having a simple JSON file in our repo listing all the steps and 
some metadata about when/why they matter, along with a 
release-checklist.py script...

release-checklist.py 6.1.0 RC0
  - makes a copy of the checklist JSON in some file that is .gitignore'd
  - updates the JSON to note that we're working on 6.1.0, RC0
  - deletes any stuff from the JSON that's only applicable for an X.0.0 
  - deletes any stuff that's only applicable when there are previous RCs

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 3310 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/3310/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader

Error Message:
expected:<2> but was:<1>

Stack Trace:
java.lang.AssertionError: expected:<2> but was:<1>
at 
__randomizedtesting.SeedInfo.seed([3B263DFD49D99367:DDB1093D705B6A06]: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.ForceLeaderTest.testReplicasInLIRNoLeader(ForceLeaderTest.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

[JENKINS] Lucene-Solr-Tests-6.x - Build # 240 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.x/240/

1 tests failed.
FAILED:  
org.apache.solr.cloud.OverseerTest.testExternalClusterStateChangeBehavior

Error Message:
Illegal state, was: down expected:active clusterState:live 
nodes:[]collections:{c1=DocCollection(c1)={   "shards":{"shard1":{   
"parent":null,   "range":null,   "state":"active",   
"replicas":{"core_node1":{   "base_url":"http://127.0.0.1/solr;,
   "node_name":"node1",   "core":"core1",   "roles":"", 
  "state":"down",   "router":{"name":"implicit"}}, 
test=LazyCollectionRef(test)}

Stack Trace:
java.lang.AssertionError: Illegal state, was: down expected:active 
clusterState:live nodes:[]collections:{c1=DocCollection(c1)={
  "shards":{"shard1":{
  "parent":null,
  "range":null,
  "state":"active",
  "replicas":{"core_node1":{
  "base_url":"http://127.0.0.1/solr;,
  "node_name":"node1",
  "core":"core1",
  "roles":"",
  "state":"down",
  "router":{"name":"implicit"}}, test=LazyCollectionRef(test)}
at 
__randomizedtesting.SeedInfo.seed([3BAE7D3244743A1C:53B07EDEA6E46052]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.verifyReplicaStatus(AbstractDistribZkTestBase.java:243)
at 
org.apache.solr.cloud.OverseerTest.testExternalClusterStateChangeBehavior(OverseerTest.java:1273)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 

[JENKINS-EA] Lucene-Solr-6.x-Linux (64bit/jdk-9-ea+120) - Build # 791 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/791/
Java: 64bit/jdk-9-ea+120 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
org.apache.solr.common.cloud.TestCollectionStateWatchers.testWaitForStateWatcherIsRetainedOnPredicateFailure

Error Message:
Did not see a fully active cluster after 30 seconds

Stack Trace:
java.lang.AssertionError: Did not see a fully active cluster after 30 seconds
at 
__randomizedtesting.SeedInfo.seed([CC0B197E394FAB59:443DBB2DE1E0434B]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.common.cloud.TestCollectionStateWatchers.testWaitForStateWatcherIsRetainedOnPredicateFailure(TestCollectionStateWatchers.java:227)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(java.base@9-ea/Thread.java:843)




Build Log:
[...truncated 13170 

[JENKINS] Lucene-Solr-6.x-Windows (32bit/jdk1.8.0_92) - Build # 220 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/220/
Java: 32bit/jdk1.8.0_92 -server -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.handler.TestReplicationHandler.doTestStressReplication

Error Message:
[index.20160601084956219, index.20160601084957326, index.properties, 
replication.properties] expected:<1> but was:<2>

Stack Trace:
java.lang.AssertionError: [index.20160601084956219, index.20160601084957326, 
index.properties, replication.properties] expected:<1> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([2473720D53417E81:FFD872CB56691732]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:907)
at 
org.apache.solr.handler.TestReplicationHandler.doTestStressReplication(TestReplicationHandler.java:874)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Resolved] (SOLR-8940) group.sort broken, can through AIOOBE if clause length differs from sort param, or cast exception if datatypes are incompatible with sort clause types

[Hoss Man (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hoss Man resolved SOLR-8940.

   Resolution: Fixed
Fix Version/s: master (7.0)
   6.1

thanks for reporting this Henrik!

> group.sort broken, can through AIOOBE if clause length differs from sort 
> param, or cast exception if datatypes are incompatible with sort clause types
> --
>
> Key: SOLR-8940
> URL: https://issues.apache.org/jira/browse/SOLR-8940
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 5.5, 5.5.1, 6.0, 6.0.1
>Reporter: Henrik
>Assignee: Hoss Man
>Priority: Blocker
>  Labels: 5.5, arrayindexoutofbounds, exception, query, 
> regression, search
> Fix For: 6.1, master (7.0)
>
> Attachments: 
> 0001-SOLR-8940-Avoid-ArrayIndexOutOfBoundsException-in-To.patch, 
> SOLR-8940.patch, schema-types.xml, schema.xml, solr-query-exception.txt, 
> solrconfig.xml
>
>
> We get an ArrayIndexOutOfBoundsException when searching after upgrading to 
> solr 5.5.
> Here's the query:
> {code}
> "params":{
>   "q":"*:*",
>   "group.sort":"priceAmount asc,rnd desc",
>   "indent":"on",
>   "fl":"priceAmount,flightTripId,brand,slob,cabinType,tripDuration",
>   "group.limit":"100",
>   "fq":["searchId:e31a0c58-9056-4297-8d70-049017ba4906",
> "doctype:offer",
> "flightTripId:(DY6020421-SK2360519 OR DY6020421-SK2600519 OR 
> DY6020421-SK2620519 OR DY6020421-SK2740519 OR DY6020421-SK2900519 OR 
> DY6020421-SK2860519 OR DY6040421-SK2380519 OR DY6040421-SK2440519 OR 
> DY6040421-SK2480519 OR DY6040421-SK2520519 OR DY6040421-SK2600519 OR 
> DY6040421-SK2620519 OR DY6040421-SK2720519 OR DY6040421-SK2740519 OR 
> DY6040421-SK2800519 OR DY6040421-SK2840519 OR DY6040421-SK2820519 OR 
> DY6060421-SK2480519 OR DY6060421-SK2740519 OR DY6060421-SK2800519 OR 
> DY6060421-SK2840519 OR DY6060421-SK2900519 OR DY6060421-SK2860519 OR 
> DY6060421-SK2820519 OR DY6080421-SK2440519)",
> "maximumLegDuration:[* TO 180]",
> "departureAirportLeg1:(OSL)",
> "(arrivalAirportLeg2:(OSL) OR (* NOT arrivalAirportLeg2:*))",
> "arrivalAirportLeg1:(BGO)",
> "(departureAirportLeg2:(BGO) OR (* NOT departureAirportLeg2:*))"],
>   "group.ngroups":"true",
>   "wt":"json",
>   "group.field":"flightTripId",
>   "group":"true"}}
> {code}
> And here's the exception:
> {code}
> ERROR [20160404T104846,333] qtp315138752-3037 
> org.apache.solr.servlet.HttpSolrCall - 
> null:java.lang.ArrayIndexOutOfBoundsException: 1
> at 
> org.apache.solr.search.grouping.distributed.shardresultserializer.TopGroupsResultTransformer.transformToNativeShardDoc(TopGroupsResultTransformer.java:175)
> at 
> org.apache.solr.search.grouping.distributed.shardresultserializer.TopGroupsResultTransformer.transformToNative(TopGroupsResultTransformer.java:137)
> at 
> org.apache.solr.search.grouping.distributed.responseprocessor.TopGroupsShardResponseProcessor.process(TopGroupsShardResponseProcessor.java:129)
> at 
> org.apache.solr.handler.component.QueryComponent.handleGroupedResponses(QueryComponent.java:750)
> at 
> org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:733)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:405)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2082)
> {code}
> The exception is thrown at the last line here 
> (TopGroupsResultTransformer.java line 175):
> {code}
>   protected ScoreDoc[] transformToNativeShardDoc(List 
> documents, Sort groupSort, String shard,
>  IndexSchema schema) {
> [...]
> for (NamedList document : documents) {
>   [...]
>   Object sortValuesVal = document.get("sortValues");
>   if (sortValuesVal != null) {
> sortValues = ((List) sortValuesVal).toArray();
> for (int k = 0; k < sortValues.length; k++) {
>   SchemaField field = groupSort.getSort()[k].getField() != null
>   ? schema.getFieldOrNull(groupSort.getSort()[k].getField()) : 
> null;
> {code}
> It's not obvious to me that {{sortValues.length == 
> groupSort.getSort().length}}, but I guess there's some logic behind it :)
> I have attached the schema and json result.
> The problem disappears when rolling back to 5.4.0.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, 

[jira] [Commented] (SOLR-8940) group.sort broken, can through AIOOBE if clause length differs from sort param, or cast exception if datatypes are incompatible with sort clause types

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15308896#comment-15308896
 ] 

ASF subversion and git services commented on SOLR-8940:
---

Commit 18256fc2873f198e8e577c6eb0f337df1d1cda24 in lucene-solr's branch 
refs/heads/master from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=18256fc ]

SOLR-8940: Fix group.sort option


> group.sort broken, can through AIOOBE if clause length differs from sort 
> param, or cast exception if datatypes are incompatible with sort clause types
> --
>
> Key: SOLR-8940
> URL: https://issues.apache.org/jira/browse/SOLR-8940
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 5.5, 5.5.1, 6.0, 6.0.1
>Reporter: Henrik
>Assignee: Hoss Man
>Priority: Blocker
>  Labels: 5.5, arrayindexoutofbounds, exception, query, 
> regression, search
> Attachments: 
> 0001-SOLR-8940-Avoid-ArrayIndexOutOfBoundsException-in-To.patch, 
> SOLR-8940.patch, schema-types.xml, schema.xml, solr-query-exception.txt, 
> solrconfig.xml
>
>
> We get an ArrayIndexOutOfBoundsException when searching after upgrading to 
> solr 5.5.
> Here's the query:
> {code}
> "params":{
>   "q":"*:*",
>   "group.sort":"priceAmount asc,rnd desc",
>   "indent":"on",
>   "fl":"priceAmount,flightTripId,brand,slob,cabinType,tripDuration",
>   "group.limit":"100",
>   "fq":["searchId:e31a0c58-9056-4297-8d70-049017ba4906",
> "doctype:offer",
> "flightTripId:(DY6020421-SK2360519 OR DY6020421-SK2600519 OR 
> DY6020421-SK2620519 OR DY6020421-SK2740519 OR DY6020421-SK2900519 OR 
> DY6020421-SK2860519 OR DY6040421-SK2380519 OR DY6040421-SK2440519 OR 
> DY6040421-SK2480519 OR DY6040421-SK2520519 OR DY6040421-SK2600519 OR 
> DY6040421-SK2620519 OR DY6040421-SK2720519 OR DY6040421-SK2740519 OR 
> DY6040421-SK2800519 OR DY6040421-SK2840519 OR DY6040421-SK2820519 OR 
> DY6060421-SK2480519 OR DY6060421-SK2740519 OR DY6060421-SK2800519 OR 
> DY6060421-SK2840519 OR DY6060421-SK2900519 OR DY6060421-SK2860519 OR 
> DY6060421-SK2820519 OR DY6080421-SK2440519)",
> "maximumLegDuration:[* TO 180]",
> "departureAirportLeg1:(OSL)",
> "(arrivalAirportLeg2:(OSL) OR (* NOT arrivalAirportLeg2:*))",
> "arrivalAirportLeg1:(BGO)",
> "(departureAirportLeg2:(BGO) OR (* NOT departureAirportLeg2:*))"],
>   "group.ngroups":"true",
>   "wt":"json",
>   "group.field":"flightTripId",
>   "group":"true"}}
> {code}
> And here's the exception:
> {code}
> ERROR [20160404T104846,333] qtp315138752-3037 
> org.apache.solr.servlet.HttpSolrCall - 
> null:java.lang.ArrayIndexOutOfBoundsException: 1
> at 
> org.apache.solr.search.grouping.distributed.shardresultserializer.TopGroupsResultTransformer.transformToNativeShardDoc(TopGroupsResultTransformer.java:175)
> at 
> org.apache.solr.search.grouping.distributed.shardresultserializer.TopGroupsResultTransformer.transformToNative(TopGroupsResultTransformer.java:137)
> at 
> org.apache.solr.search.grouping.distributed.responseprocessor.TopGroupsShardResponseProcessor.process(TopGroupsShardResponseProcessor.java:129)
> at 
> org.apache.solr.handler.component.QueryComponent.handleGroupedResponses(QueryComponent.java:750)
> at 
> org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:733)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:405)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2082)
> {code}
> The exception is thrown at the last line here 
> (TopGroupsResultTransformer.java line 175):
> {code}
>   protected ScoreDoc[] transformToNativeShardDoc(List 
> documents, Sort groupSort, String shard,
>  IndexSchema schema) {
> [...]
> for (NamedList document : documents) {
>   [...]
>   Object sortValuesVal = document.get("sortValues");
>   if (sortValuesVal != null) {
> sortValues = ((List) sortValuesVal).toArray();
> for (int k = 0; k < sortValues.length; k++) {
>   SchemaField field = groupSort.getSort()[k].getField() != null
>   ? schema.getFieldOrNull(groupSort.getSort()[k].getField()) : 
> null;
> {code}
> It's not obvious to me that {{sortValues.length == 
> groupSort.getSort().length}}, but I guess there's some logic behind it :)
> I have attached the schema and json result.
> The problem disappears when rolling back to 5.4.0.



--

[jira] [Commented] (SOLR-8940) group.sort broken, can through AIOOBE if clause length differs from sort param, or cast exception if datatypes are incompatible with sort clause types

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15308895#comment-15308895
 ] 

ASF subversion and git services commented on SOLR-8940:
---

Commit 22faa09882f818ce5f91d0230d84f7dc8cc1c084 in lucene-solr's branch 
refs/heads/branch_6x from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=22faa09 ]

SOLR-8940: Fix group.sort option

(cherry picked from commit 18256fc2873f198e8e577c6eb0f337df1d1cda24)


> group.sort broken, can through AIOOBE if clause length differs from sort 
> param, or cast exception if datatypes are incompatible with sort clause types
> --
>
> Key: SOLR-8940
> URL: https://issues.apache.org/jira/browse/SOLR-8940
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 5.5, 5.5.1, 6.0, 6.0.1
>Reporter: Henrik
>Assignee: Hoss Man
>Priority: Blocker
>  Labels: 5.5, arrayindexoutofbounds, exception, query, 
> regression, search
> Attachments: 
> 0001-SOLR-8940-Avoid-ArrayIndexOutOfBoundsException-in-To.patch, 
> SOLR-8940.patch, schema-types.xml, schema.xml, solr-query-exception.txt, 
> solrconfig.xml
>
>
> We get an ArrayIndexOutOfBoundsException when searching after upgrading to 
> solr 5.5.
> Here's the query:
> {code}
> "params":{
>   "q":"*:*",
>   "group.sort":"priceAmount asc,rnd desc",
>   "indent":"on",
>   "fl":"priceAmount,flightTripId,brand,slob,cabinType,tripDuration",
>   "group.limit":"100",
>   "fq":["searchId:e31a0c58-9056-4297-8d70-049017ba4906",
> "doctype:offer",
> "flightTripId:(DY6020421-SK2360519 OR DY6020421-SK2600519 OR 
> DY6020421-SK2620519 OR DY6020421-SK2740519 OR DY6020421-SK2900519 OR 
> DY6020421-SK2860519 OR DY6040421-SK2380519 OR DY6040421-SK2440519 OR 
> DY6040421-SK2480519 OR DY6040421-SK2520519 OR DY6040421-SK2600519 OR 
> DY6040421-SK2620519 OR DY6040421-SK2720519 OR DY6040421-SK2740519 OR 
> DY6040421-SK2800519 OR DY6040421-SK2840519 OR DY6040421-SK2820519 OR 
> DY6060421-SK2480519 OR DY6060421-SK2740519 OR DY6060421-SK2800519 OR 
> DY6060421-SK2840519 OR DY6060421-SK2900519 OR DY6060421-SK2860519 OR 
> DY6060421-SK2820519 OR DY6080421-SK2440519)",
> "maximumLegDuration:[* TO 180]",
> "departureAirportLeg1:(OSL)",
> "(arrivalAirportLeg2:(OSL) OR (* NOT arrivalAirportLeg2:*))",
> "arrivalAirportLeg1:(BGO)",
> "(departureAirportLeg2:(BGO) OR (* NOT departureAirportLeg2:*))"],
>   "group.ngroups":"true",
>   "wt":"json",
>   "group.field":"flightTripId",
>   "group":"true"}}
> {code}
> And here's the exception:
> {code}
> ERROR [20160404T104846,333] qtp315138752-3037 
> org.apache.solr.servlet.HttpSolrCall - 
> null:java.lang.ArrayIndexOutOfBoundsException: 1
> at 
> org.apache.solr.search.grouping.distributed.shardresultserializer.TopGroupsResultTransformer.transformToNativeShardDoc(TopGroupsResultTransformer.java:175)
> at 
> org.apache.solr.search.grouping.distributed.shardresultserializer.TopGroupsResultTransformer.transformToNative(TopGroupsResultTransformer.java:137)
> at 
> org.apache.solr.search.grouping.distributed.responseprocessor.TopGroupsShardResponseProcessor.process(TopGroupsShardResponseProcessor.java:129)
> at 
> org.apache.solr.handler.component.QueryComponent.handleGroupedResponses(QueryComponent.java:750)
> at 
> org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:733)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:405)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2082)
> {code}
> The exception is thrown at the last line here 
> (TopGroupsResultTransformer.java line 175):
> {code}
>   protected ScoreDoc[] transformToNativeShardDoc(List 
> documents, Sort groupSort, String shard,
>  IndexSchema schema) {
> [...]
> for (NamedList document : documents) {
>   [...]
>   Object sortValuesVal = document.get("sortValues");
>   if (sortValuesVal != null) {
> sortValues = ((List) sortValuesVal).toArray();
> for (int k = 0; k < sortValues.length; k++) {
>   SchemaField field = groupSort.getSort()[k].getField() != null
>   ? schema.getFieldOrNull(groupSort.getSort()[k].getField()) : 
> null;
> {code}
> It's not obvious to me that {{sortValues.length == 
> groupSort.getSort().length}}, but I guess there's some logic behind it :)
> I have attached the schema 

[jira] [Commented] (LUCENE-7301) updateNumericDocValue mixed with updateDocument can cause data loss in some randomized testing

[Ishan Chattopadhyaya (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15308857#comment-15308857
 ] 

Ishan Chattopadhyaya commented on LUCENE-7301:
--

2000+ rounds of beasting the test (for the Solr integration), and they look 
good! +1 to the fix.

> updateNumericDocValue mixed with updateDocument can cause data loss in some 
> randomized testing
> --
>
> Key: LUCENE-7301
> URL: https://issues.apache.org/jira/browse/LUCENE-7301
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Hoss Man
> Attachments: LUCENE-7301.patch, LUCENE-7301.patch, LUCENE-7301.patch
>
>
> SOLR-5944 has been held up by a while due to some extremely rare randomized 
> test failures.
> Ishan and I have been working on whitling those Solr test failures down, 
> trying to create more isolated reproducable test failures, and i *think* i've 
> tracked it down to a bug in IndexWriter when the client calls to 
> updateDocument intermixed with calls to updateNumericDocValue *AND* 
> IndexWriterConfig.setMaxBufferedDocs is very low (i suspect "how low" depends 
> on the number of quantity/types of updates -- but *just* got something that 
> reproduced, and haven't tried reproducing with higher values of 
> maxBufferedDocs and larger sequences of updateDocument / 
> updateNumericDocValue calls.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-Tests-master - Build # 1181 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1181/

4 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestCoreDiscovery

Error Message:
ObjectTracker found 4 object(s) that were not released!!! 
[MDCAwareThreadPoolExecutor, SolrCore, MockDirectoryWrapper, 
MockDirectoryWrapper]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 4 object(s) that were not 
released!!! [MDCAwareThreadPoolExecutor, SolrCore, MockDirectoryWrapper, 
MockDirectoryWrapper]
at __randomizedtesting.SeedInfo.seed([215705D5D7C6AE78]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:255)
at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestCoreDiscovery

Error Message:
1 thread leaked from SUITE scope at org.apache.solr.core.TestCoreDiscovery: 
1) Thread[id=14109, name=searcherExecutor-5620-thread-1, state=WAITING, 
group=TGRP-TestCoreDiscovery] at sun.misc.Unsafe.park(Native Method)
 at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)   
  at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.core.TestCoreDiscovery: 
   1) Thread[id=14109, name=searcherExecutor-5620-thread-1, state=WAITING, 
group=TGRP-TestCoreDiscovery]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at 

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_92) - Build # 16883 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16883/
Java: 64bit/jdk1.8.0_92 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.util.SolrPluginUtilsTest.testInvokeSetters

Error Message:
argument type mismatch

Stack Trace:
java.lang.IllegalArgumentException: argument type mismatch
at 
__randomizedtesting.SeedInfo.seed([81428D2BC210BBDC:E85D262B3726D977]:0)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.apache.solr.util.SolrPluginUtils.invokeSetters(SolrPluginUtils.java:1071)
at 
org.apache.solr.util.SolrPluginUtilsTest.implTestInvokeSetters(SolrPluginUtilsTest.java:482)
at 
org.apache.solr.util.SolrPluginUtilsTest.testInvokeSetters(SolrPluginUtilsTest.java:474)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Updated] (SOLR-8940) group.sort broken, can through AIOOBE if clause length differs from sort param, or cast exception if datatypes are incompatible with sort clause types

[Hoss Man (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hoss Man updated SOLR-8940:
---
Summary: group.sort broken, can through AIOOBE if clause length differs 
from sort param, or cast exception if datatypes are incompatible with sort 
clause types  (was: ArrayIndexOutOfBoundsException in 
TopGroupsResultTransformer.transformToNativeShardDoc after upgrading to 5.5.0)

> group.sort broken, can through AIOOBE if clause length differs from sort 
> param, or cast exception if datatypes are incompatible with sort clause types
> --
>
> Key: SOLR-8940
> URL: https://issues.apache.org/jira/browse/SOLR-8940
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 5.5, 5.5.1, 6.0, 6.0.1
>Reporter: Henrik
>Assignee: Hoss Man
>Priority: Blocker
>  Labels: 5.5, arrayindexoutofbounds, exception, query, 
> regression, search
> Attachments: 
> 0001-SOLR-8940-Avoid-ArrayIndexOutOfBoundsException-in-To.patch, 
> SOLR-8940.patch, schema-types.xml, schema.xml, solr-query-exception.txt, 
> solrconfig.xml
>
>
> We get an ArrayIndexOutOfBoundsException when searching after upgrading to 
> solr 5.5.
> Here's the query:
> {code}
> "params":{
>   "q":"*:*",
>   "group.sort":"priceAmount asc,rnd desc",
>   "indent":"on",
>   "fl":"priceAmount,flightTripId,brand,slob,cabinType,tripDuration",
>   "group.limit":"100",
>   "fq":["searchId:e31a0c58-9056-4297-8d70-049017ba4906",
> "doctype:offer",
> "flightTripId:(DY6020421-SK2360519 OR DY6020421-SK2600519 OR 
> DY6020421-SK2620519 OR DY6020421-SK2740519 OR DY6020421-SK2900519 OR 
> DY6020421-SK2860519 OR DY6040421-SK2380519 OR DY6040421-SK2440519 OR 
> DY6040421-SK2480519 OR DY6040421-SK2520519 OR DY6040421-SK2600519 OR 
> DY6040421-SK2620519 OR DY6040421-SK2720519 OR DY6040421-SK2740519 OR 
> DY6040421-SK2800519 OR DY6040421-SK2840519 OR DY6040421-SK2820519 OR 
> DY6060421-SK2480519 OR DY6060421-SK2740519 OR DY6060421-SK2800519 OR 
> DY6060421-SK2840519 OR DY6060421-SK2900519 OR DY6060421-SK2860519 OR 
> DY6060421-SK2820519 OR DY6080421-SK2440519)",
> "maximumLegDuration:[* TO 180]",
> "departureAirportLeg1:(OSL)",
> "(arrivalAirportLeg2:(OSL) OR (* NOT arrivalAirportLeg2:*))",
> "arrivalAirportLeg1:(BGO)",
> "(departureAirportLeg2:(BGO) OR (* NOT departureAirportLeg2:*))"],
>   "group.ngroups":"true",
>   "wt":"json",
>   "group.field":"flightTripId",
>   "group":"true"}}
> {code}
> And here's the exception:
> {code}
> ERROR [20160404T104846,333] qtp315138752-3037 
> org.apache.solr.servlet.HttpSolrCall - 
> null:java.lang.ArrayIndexOutOfBoundsException: 1
> at 
> org.apache.solr.search.grouping.distributed.shardresultserializer.TopGroupsResultTransformer.transformToNativeShardDoc(TopGroupsResultTransformer.java:175)
> at 
> org.apache.solr.search.grouping.distributed.shardresultserializer.TopGroupsResultTransformer.transformToNative(TopGroupsResultTransformer.java:137)
> at 
> org.apache.solr.search.grouping.distributed.responseprocessor.TopGroupsShardResponseProcessor.process(TopGroupsShardResponseProcessor.java:129)
> at 
> org.apache.solr.handler.component.QueryComponent.handleGroupedResponses(QueryComponent.java:750)
> at 
> org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:733)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:405)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2082)
> {code}
> The exception is thrown at the last line here 
> (TopGroupsResultTransformer.java line 175):
> {code}
>   protected ScoreDoc[] transformToNativeShardDoc(List 
> documents, Sort groupSort, String shard,
>  IndexSchema schema) {
> [...]
> for (NamedList document : documents) {
>   [...]
>   Object sortValuesVal = document.get("sortValues");
>   if (sortValuesVal != null) {
> sortValues = ((List) sortValuesVal).toArray();
> for (int k = 0; k < sortValues.length; k++) {
>   SchemaField field = groupSort.getSort()[k].getField() != null
>   ? schema.getFieldOrNull(groupSort.getSort()[k].getField()) : 
> null;
> {code}
> It's not obvious to me that {{sortValues.length == 
> groupSort.getSort().length}}, but I guess there's some logic behind it :)
> I have attached the schema and json result.
> The problem disappears when rolling back to 5.4.0.



--
This message was 

[jira] [Updated] (SOLR-8940) ArrayIndexOutOfBoundsException in TopGroupsResultTransformer.transformToNativeShardDoc after upgrading to 5.5.0

[Hoss Man (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hoss Man updated SOLR-8940:
---
 Assignee: Hoss Man
Affects Version/s: 6.0
   6.0.1

> ArrayIndexOutOfBoundsException in 
> TopGroupsResultTransformer.transformToNativeShardDoc after upgrading to 5.5.0
> ---
>
> Key: SOLR-8940
> URL: https://issues.apache.org/jira/browse/SOLR-8940
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 5.5, 5.5.1, 6.0, 6.0.1
>Reporter: Henrik
>Assignee: Hoss Man
>Priority: Blocker
>  Labels: 5.5, arrayindexoutofbounds, exception, query, 
> regression, search
> Attachments: 
> 0001-SOLR-8940-Avoid-ArrayIndexOutOfBoundsException-in-To.patch, 
> SOLR-8940.patch, schema-types.xml, schema.xml, solr-query-exception.txt, 
> solrconfig.xml
>
>
> We get an ArrayIndexOutOfBoundsException when searching after upgrading to 
> solr 5.5.
> Here's the query:
> {code}
> "params":{
>   "q":"*:*",
>   "group.sort":"priceAmount asc,rnd desc",
>   "indent":"on",
>   "fl":"priceAmount,flightTripId,brand,slob,cabinType,tripDuration",
>   "group.limit":"100",
>   "fq":["searchId:e31a0c58-9056-4297-8d70-049017ba4906",
> "doctype:offer",
> "flightTripId:(DY6020421-SK2360519 OR DY6020421-SK2600519 OR 
> DY6020421-SK2620519 OR DY6020421-SK2740519 OR DY6020421-SK2900519 OR 
> DY6020421-SK2860519 OR DY6040421-SK2380519 OR DY6040421-SK2440519 OR 
> DY6040421-SK2480519 OR DY6040421-SK2520519 OR DY6040421-SK2600519 OR 
> DY6040421-SK2620519 OR DY6040421-SK2720519 OR DY6040421-SK2740519 OR 
> DY6040421-SK2800519 OR DY6040421-SK2840519 OR DY6040421-SK2820519 OR 
> DY6060421-SK2480519 OR DY6060421-SK2740519 OR DY6060421-SK2800519 OR 
> DY6060421-SK2840519 OR DY6060421-SK2900519 OR DY6060421-SK2860519 OR 
> DY6060421-SK2820519 OR DY6080421-SK2440519)",
> "maximumLegDuration:[* TO 180]",
> "departureAirportLeg1:(OSL)",
> "(arrivalAirportLeg2:(OSL) OR (* NOT arrivalAirportLeg2:*))",
> "arrivalAirportLeg1:(BGO)",
> "(departureAirportLeg2:(BGO) OR (* NOT departureAirportLeg2:*))"],
>   "group.ngroups":"true",
>   "wt":"json",
>   "group.field":"flightTripId",
>   "group":"true"}}
> {code}
> And here's the exception:
> {code}
> ERROR [20160404T104846,333] qtp315138752-3037 
> org.apache.solr.servlet.HttpSolrCall - 
> null:java.lang.ArrayIndexOutOfBoundsException: 1
> at 
> org.apache.solr.search.grouping.distributed.shardresultserializer.TopGroupsResultTransformer.transformToNativeShardDoc(TopGroupsResultTransformer.java:175)
> at 
> org.apache.solr.search.grouping.distributed.shardresultserializer.TopGroupsResultTransformer.transformToNative(TopGroupsResultTransformer.java:137)
> at 
> org.apache.solr.search.grouping.distributed.responseprocessor.TopGroupsShardResponseProcessor.process(TopGroupsShardResponseProcessor.java:129)
> at 
> org.apache.solr.handler.component.QueryComponent.handleGroupedResponses(QueryComponent.java:750)
> at 
> org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:733)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:405)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2082)
> {code}
> The exception is thrown at the last line here 
> (TopGroupsResultTransformer.java line 175):
> {code}
>   protected ScoreDoc[] transformToNativeShardDoc(List 
> documents, Sort groupSort, String shard,
>  IndexSchema schema) {
> [...]
> for (NamedList document : documents) {
>   [...]
>   Object sortValuesVal = document.get("sortValues");
>   if (sortValuesVal != null) {
> sortValues = ((List) sortValuesVal).toArray();
> for (int k = 0; k < sortValues.length; k++) {
>   SchemaField field = groupSort.getSort()[k].getField() != null
>   ? schema.getFieldOrNull(groupSort.getSort()[k].getField()) : 
> null;
> {code}
> It's not obvious to me that {{sortValues.length == 
> groupSort.getSort().length}}, but I guess there's some logic behind it :)
> I have attached the schema and json result.
> The problem disappears when rolling back to 5.4.0.



--
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-8940) ArrayIndexOutOfBoundsException in TopGroupsResultTransformer.transformToNativeShardDoc after upgrading to 5.5.0

[Hoss Man (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hoss Man updated SOLR-8940:
---
Attachment: SOLR-8940.patch

bq. I suspect this bug was introduced by a mistake in some of the refactoring 
in LUCENE-6900, ...

confirmed.  some near identical code was refactored into the (new in 5.5) 
transformToNativeShardDoc method, but the two places where the code was 
refactored were updated to include identical calls to this method with 
identical arguments including {{groupSort}} -- in one of those cases 
{{sortWithinGroup}} should have been used as the method arg instead.



Attaching a patch with fix and some new non trivial group.sort tests that 
demonstrate the bug w/o the fix applied

> ArrayIndexOutOfBoundsException in 
> TopGroupsResultTransformer.transformToNativeShardDoc after upgrading to 5.5.0
> ---
>
> Key: SOLR-8940
> URL: https://issues.apache.org/jira/browse/SOLR-8940
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 5.5, 5.5.1
>Reporter: Henrik
>Priority: Blocker
>  Labels: 5.5, arrayindexoutofbounds, exception, query, 
> regression, search
> Attachments: 
> 0001-SOLR-8940-Avoid-ArrayIndexOutOfBoundsException-in-To.patch, 
> SOLR-8940.patch, schema-types.xml, schema.xml, solr-query-exception.txt, 
> solrconfig.xml
>
>
> We get an ArrayIndexOutOfBoundsException when searching after upgrading to 
> solr 5.5.
> Here's the query:
> {code}
> "params":{
>   "q":"*:*",
>   "group.sort":"priceAmount asc,rnd desc",
>   "indent":"on",
>   "fl":"priceAmount,flightTripId,brand,slob,cabinType,tripDuration",
>   "group.limit":"100",
>   "fq":["searchId:e31a0c58-9056-4297-8d70-049017ba4906",
> "doctype:offer",
> "flightTripId:(DY6020421-SK2360519 OR DY6020421-SK2600519 OR 
> DY6020421-SK2620519 OR DY6020421-SK2740519 OR DY6020421-SK2900519 OR 
> DY6020421-SK2860519 OR DY6040421-SK2380519 OR DY6040421-SK2440519 OR 
> DY6040421-SK2480519 OR DY6040421-SK2520519 OR DY6040421-SK2600519 OR 
> DY6040421-SK2620519 OR DY6040421-SK2720519 OR DY6040421-SK2740519 OR 
> DY6040421-SK2800519 OR DY6040421-SK2840519 OR DY6040421-SK2820519 OR 
> DY6060421-SK2480519 OR DY6060421-SK2740519 OR DY6060421-SK2800519 OR 
> DY6060421-SK2840519 OR DY6060421-SK2900519 OR DY6060421-SK2860519 OR 
> DY6060421-SK2820519 OR DY6080421-SK2440519)",
> "maximumLegDuration:[* TO 180]",
> "departureAirportLeg1:(OSL)",
> "(arrivalAirportLeg2:(OSL) OR (* NOT arrivalAirportLeg2:*))",
> "arrivalAirportLeg1:(BGO)",
> "(departureAirportLeg2:(BGO) OR (* NOT departureAirportLeg2:*))"],
>   "group.ngroups":"true",
>   "wt":"json",
>   "group.field":"flightTripId",
>   "group":"true"}}
> {code}
> And here's the exception:
> {code}
> ERROR [20160404T104846,333] qtp315138752-3037 
> org.apache.solr.servlet.HttpSolrCall - 
> null:java.lang.ArrayIndexOutOfBoundsException: 1
> at 
> org.apache.solr.search.grouping.distributed.shardresultserializer.TopGroupsResultTransformer.transformToNativeShardDoc(TopGroupsResultTransformer.java:175)
> at 
> org.apache.solr.search.grouping.distributed.shardresultserializer.TopGroupsResultTransformer.transformToNative(TopGroupsResultTransformer.java:137)
> at 
> org.apache.solr.search.grouping.distributed.responseprocessor.TopGroupsShardResponseProcessor.process(TopGroupsShardResponseProcessor.java:129)
> at 
> org.apache.solr.handler.component.QueryComponent.handleGroupedResponses(QueryComponent.java:750)
> at 
> org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:733)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:405)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2082)
> {code}
> The exception is thrown at the last line here 
> (TopGroupsResultTransformer.java line 175):
> {code}
>   protected ScoreDoc[] transformToNativeShardDoc(List 
> documents, Sort groupSort, String shard,
>  IndexSchema schema) {
> [...]
> for (NamedList document : documents) {
>   [...]
>   Object sortValuesVal = document.get("sortValues");
>   if (sortValuesVal != null) {
> sortValues = ((List) sortValuesVal).toArray();
> for (int k = 0; k < sortValues.length; k++) {
>   SchemaField field = groupSort.getSort()[k].getField() != null
>   ? schema.getFieldOrNull(groupSort.getSort()[k].getField()) : 
> null;
> {code}
> It's not obvious to me that 

[JENKINS] Lucene-Solr-SmokeRelease-6.x - Build # 72 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-6.x/72/

No tests ran.

Build Log:
[...truncated 40524 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 
JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (15.2 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-6.1.0-src.tgz...
   [smoker] 28.7 MB in 0.03 sec (1114.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.1.0.tgz...
   [smoker] 63.0 MB in 0.06 sec (1145.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.1.0.zip...
   [smoker] 73.6 MB in 0.06 sec (1147.6 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-6.1.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6009 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.1.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6009 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.1.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 218 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [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.2 MB in 0.00 sec (38.0 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-6.1.0-src.tgz...
   [smoker] 37.9 MB in 0.52 sec (72.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-6.1.0.tgz...
   [smoker] 132.4 MB in 1.69 sec (78.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-6.1.0.zip...
   [smoker] 141.0 MB in 1.57 sec (89.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-6.1.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-6.1.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.1.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.1.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.1.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.1.0-java8
   [smoker] Creating Solr home directory 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.1.0-java8/example/techproducts/solr
   [smoker] 
   [smoker] Starting up Solr on port 8983 using command:
   [smoker] bin/solr start -p 8983 -s "example/techproducts/solr"
   [smoker] 
   [smoker] Waiting up to 30 seconds to see Solr running on port 8983 [|]  
 [/]   [-]   [\]   [|]   [/]   [-]   
[\]   [|]   [/]   [-]  
   

[jira] [Commented] (SOLR-9176) Legacy Faceting Term Enum Method Regression

[Jesse McLaughlin (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15308770#comment-15308770
 ] 

Jesse McLaughlin commented on SOLR-9176:


Here's a representative, minimal patch that restores the old 4.x behaviour:

https://github.com/nzjess/lucene-solr/commit/512298fc153738cc0d323dfc7aadbde241085d5b

Haven't re-run the unit tests on this, but you get the idea...


> Legacy Faceting Term Enum Method Regression
> ---
>
> Key: SOLR-9176
> URL: https://issues.apache.org/jira/browse/SOLR-9176
> Project: Solr
>  Issue Type: Bug
>  Components: faceting
>Affects Versions: 5.2, 5.2.1, 5.3, 5.3.1, 5.3.2, 5.4, 5.4.1, 5.5, 5.5.1, 
> 6.0, 6.0.1
>Reporter: Alessandro Benedetti
>
> Starting from this commit :
> LUCENE-5666: get solr started
> git-svn-id: 
> https://svn.apache.org/repos/asf/lucene/dev/branches/lucene5666@1594254 
> 13f79535-47bb-0310-9956-ffa450edef68
> https://github.com/apache/lucene-solr/commit/1489085807cb10981a7ea5b5663ada4e3f85953e#diff-5ac9dc7b128b4dd99b764060759222b2
> It is not possible to use Term Enum as a faceting method, for numeric and 
> single valued fields ( org.apache.solr.request.SimpleFacets ) .
> We personally verified that there are use cases when this is bringing a quite 
> big performance regression  ( even with DocValues enabled) .
> In the mailing list from time to time people complain about a regression 
> happening with the term enum method, but actually it is more likely to be the 
>   automatic forcing of FCS.
> Forcing FCS in co-op with the famous regression that happened in SOLR-8096 
> could be confused as a term Enum regression.



--
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-7307) Add getters to PointInSetQuery and PointRangeQuery classes

[Michael McCandless (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15308721#comment-15308721
 ] 

Michael McCandless commented on LUCENE-7307:


+1

> Add getters to PointInSetQuery and PointRangeQuery classes
> --
>
> Key: LUCENE-7307
> URL: https://issues.apache.org/jira/browse/LUCENE-7307
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Martijn van Groningen
>Priority: Trivial
> Attachments: LUCENE_7307.patch
>
>




--
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-6.x-Linux (64bit/jdk1.8.0_92) - Build # 790 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/790/
Java: 64bit/jdk1.8.0_92 -XX:+UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  
org.apache.solr.common.cloud.TestCollectionStateWatchers.testWaitForStateWatcherIsRetainedOnPredicateFailure

Error Message:
Did not see a fully active cluster after 30 seconds

Stack Trace:
java.lang.AssertionError: Did not see a fully active cluster after 30 seconds
at 
__randomizedtesting.SeedInfo.seed([3DB05FCA58ADBFE6:B586FD99800257F4]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.common.cloud.TestCollectionStateWatchers.testWaitForStateWatcherIsRetainedOnPredicateFailure(TestCollectionStateWatchers.java:227)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 13176 lines...]
   [junit4] Suite: org.apache.solr.common.cloud.TestCollectionStateWatchers
   [junit4]   2> Creating 

[jira] [Commented] (SOLR-9174) After Solr 5.5, mm parameter doesn't work properly

[JIRA]

[ 
https://issues.apache.org/jira/browse/SOLR-9174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15308597#comment-15308597
 ] 

Jan Høydahl commented on SOLR-9174:
---

As long as you set mm, you should not need to set q.op. But there seems to be a 
bug leading to q.op=AND overriding mm in some cases, so just try your 
particular use case with q.op=OR and report back your findings. I'm afraid you 
may end up with other queries not working the way you intended with q.op=OR :(

> After Solr 5.5, mm parameter doesn't work properly
> --
>
> Key: SOLR-9174
> URL: https://issues.apache.org/jira/browse/SOLR-9174
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers, search
>Affects Versions: 5.5, 6.0, 6.0.1
>Reporter: Issei Nishigata
>
> “mm" parameter does not work properly, when I set "q.op=AND” after Solr 5.5.
> In Solr 5.4, mm parameter works expectedly with the following setting.
> [schema]
> {code:xml}
> 
>   
>  maxGramSize="2"/>
>   
> 
> {code}
> [request]
> {quote}
> http://localhost:8983/solr/collection1/select?defType=edismax=AND=2=solar
> {quote}
> After Solr 5.5, the result will not be the same as Solr 5.4.
> [Solr 5.4]
> {code:xml}
> 
> ...
>   
> 2
> solar
> edismax
> AND
>   
> ...
> 
>   
> 0
> 
>   solr
> 
>   
> 
> 
>   solar
>   solar
>   
>   (+DisjunctionMaxQuerytext:so text:ol text:la text:ar)~2/no_coord
>   
>   +(((text:so text:ol text:la 
> text:ar)~2))
>   ...
> 
> {code}
> [Solr 6.0.1]
> {code:xml}
> 
> ...
>   
> 2
> solar
> edismax
> AND
>   
> ...
> 
>   
> solar
> solar
> 
> (+DisjunctionMaxQuery(((+text:so +text:ol +text:la +text:ar/no_coord
> 
> +((+text:so +text:ol +text:la 
> +text:ar))
> ...
> {code}
> As shown above, parsedquery also differs from Solr 5.4 and Solr 6.0.1(after 
> Solr 5.5).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+120) - Build # 16882 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16882/
Java: 64bit/jdk-9-ea+120 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.util.SolrPluginUtilsTest.testInvokeSetters

Error Message:
argument type mismatch

Stack Trace:
java.lang.IllegalArgumentException: argument type mismatch
at 
__randomizedtesting.SeedInfo.seed([849C64E832D099C4:ED83CFE8C7E6FB6F]:0)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
at 
org.apache.solr.util.SolrPluginUtils.invokeSetters(SolrPluginUtils.java:1071)
at 
org.apache.solr.util.SolrPluginUtilsTest.implTestInvokeSetters(SolrPluginUtilsTest.java:482)
at 
org.apache.solr.util.SolrPluginUtilsTest.testInvokeSetters(SolrPluginUtilsTest.java:474)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 

[jira] [Updated] (LUCENE-7304) Doc values based block join implementation

[Paul Elschot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Elschot updated LUCENE-7304:
-
Attachment: LUCENE-7304-20160531.patch

Patch of 31 May 2016.
Adds DocBlocksIterator and uses it in ToChildBlockJoinQuery only.

This is mostly an update of LUCENE-5092 to today, except that it does not 
include the ToParentBlockJoinQuery yet.

To my surprise this compiles, but I did not run the tests in the join module.

This is only to show a possible direction, BitSetProducer in the join queries 
may also need to be replaced by a DocBlocksIteratorProducer.


> Doc values based block join implementation
> --
>
> Key: LUCENE-7304
> URL: https://issues.apache.org/jira/browse/LUCENE-7304
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Martijn van Groningen
>Priority: Minor
> Attachments: LUCENE-5092-20140313.patch, LUCENE-7304-20160531.patch, 
> LUCENE_7304.patch
>
>
> At query time the block join relies on a bitset for finding the previous 
> parent doc during advancing the doc id iterator. On large indices these 
> bitsets can consume large amounts of jvm heap space.  Also typically due the 
> nature how these bitsets are set, the 'FixedBitSet' implementation is used.
> The idea I had was to replace the bitset usage by a numeric doc values field 
> that stores offsets. Each child doc stores how many docids it is from its 
> parent doc and each parent stores how many docids it is apart from its first 
> child. At query time this information can be used to perform the block join.
> I think another benefit of this approach is that external tools can now 
> easily determine if a doc is part of a block of documents and perhaps this 
> also helps index time sorting?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9174) After Solr 5.5, mm parameter doesn't work properly

[JIRA]

[ 
https://issues.apache.org/jira/browse/SOLR-9174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15308589#comment-15308589
 ] 

Jan Høydahl commented on SOLR-9174:
---

There is a long history here. Back in the days, (e)dismax did only care about 
{{mm}}, which defaulted to {{100%}}. Then people got confused when they had 
{{q.op=OR}} or {{defaultOperator=OR}} in the schema, so we added some logic 
{{if q.op==OR then mm=0 else mm=100%}} which kicked in *if user did not 
explicitly set mm*.

But then there was the case of explicit operators in the query, which pre-5.5 
used to ignore {{mm}} completely, see SOLR-2649. So in 5.5 we tried to solve 
that one, changing the interaction between {{q.op}} and {{mm}} a bit, leading 
to SOLR-8812, and perhaps also the root case for this issue?

> After Solr 5.5, mm parameter doesn't work properly
> --
>
> Key: SOLR-9174
> URL: https://issues.apache.org/jira/browse/SOLR-9174
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers, search
>Affects Versions: 5.5, 6.0, 6.0.1
>Reporter: Issei Nishigata
>
> “mm" parameter does not work properly, when I set "q.op=AND” after Solr 5.5.
> In Solr 5.4, mm parameter works expectedly with the following setting.
> [schema]
> {code:xml}
> 
>   
>  maxGramSize="2"/>
>   
> 
> {code}
> [request]
> {quote}
> http://localhost:8983/solr/collection1/select?defType=edismax=AND=2=solar
> {quote}
> After Solr 5.5, the result will not be the same as Solr 5.4.
> [Solr 5.4]
> {code:xml}
> 
> ...
>   
> 2
> solar
> edismax
> AND
>   
> ...
> 
>   
> 0
> 
>   solr
> 
>   
> 
> 
>   solar
>   solar
>   
>   (+DisjunctionMaxQuerytext:so text:ol text:la text:ar)~2/no_coord
>   
>   +(((text:so text:ol text:la 
> text:ar)~2))
>   ...
> 
> {code}
> [Solr 6.0.1]
> {code:xml}
> 
> ...
>   
> 2
> solar
> edismax
> AND
>   
> ...
> 
>   
> solar
> solar
> 
> (+DisjunctionMaxQuery(((+text:so +text:ol +text:la +text:ar/no_coord
> 
> +((+text:so +text:ol +text:la 
> +text:ar))
> ...
> {code}
> As shown above, parsedquery also differs from Solr 5.4 and Solr 6.0.1(after 
> Solr 5.5).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8940) ArrayIndexOutOfBoundsException in TopGroupsResultTransformer.transformToNativeShardDoc after upgrading to 5.5.0

[Henrik (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15308571#comment-15308571
 ] 

Henrik commented on SOLR-8940:
--

Thanks for diving into this [~hossman] 

> ArrayIndexOutOfBoundsException in 
> TopGroupsResultTransformer.transformToNativeShardDoc after upgrading to 5.5.0
> ---
>
> Key: SOLR-8940
> URL: https://issues.apache.org/jira/browse/SOLR-8940
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 5.5, 5.5.1
>Reporter: Henrik
>Priority: Blocker
>  Labels: 5.5, arrayindexoutofbounds, exception, query, 
> regression, search
> Attachments: 
> 0001-SOLR-8940-Avoid-ArrayIndexOutOfBoundsException-in-To.patch, 
> schema-types.xml, schema.xml, solr-query-exception.txt, solrconfig.xml
>
>
> We get an ArrayIndexOutOfBoundsException when searching after upgrading to 
> solr 5.5.
> Here's the query:
> {code}
> "params":{
>   "q":"*:*",
>   "group.sort":"priceAmount asc,rnd desc",
>   "indent":"on",
>   "fl":"priceAmount,flightTripId,brand,slob,cabinType,tripDuration",
>   "group.limit":"100",
>   "fq":["searchId:e31a0c58-9056-4297-8d70-049017ba4906",
> "doctype:offer",
> "flightTripId:(DY6020421-SK2360519 OR DY6020421-SK2600519 OR 
> DY6020421-SK2620519 OR DY6020421-SK2740519 OR DY6020421-SK2900519 OR 
> DY6020421-SK2860519 OR DY6040421-SK2380519 OR DY6040421-SK2440519 OR 
> DY6040421-SK2480519 OR DY6040421-SK2520519 OR DY6040421-SK2600519 OR 
> DY6040421-SK2620519 OR DY6040421-SK2720519 OR DY6040421-SK2740519 OR 
> DY6040421-SK2800519 OR DY6040421-SK2840519 OR DY6040421-SK2820519 OR 
> DY6060421-SK2480519 OR DY6060421-SK2740519 OR DY6060421-SK2800519 OR 
> DY6060421-SK2840519 OR DY6060421-SK2900519 OR DY6060421-SK2860519 OR 
> DY6060421-SK2820519 OR DY6080421-SK2440519)",
> "maximumLegDuration:[* TO 180]",
> "departureAirportLeg1:(OSL)",
> "(arrivalAirportLeg2:(OSL) OR (* NOT arrivalAirportLeg2:*))",
> "arrivalAirportLeg1:(BGO)",
> "(departureAirportLeg2:(BGO) OR (* NOT departureAirportLeg2:*))"],
>   "group.ngroups":"true",
>   "wt":"json",
>   "group.field":"flightTripId",
>   "group":"true"}}
> {code}
> And here's the exception:
> {code}
> ERROR [20160404T104846,333] qtp315138752-3037 
> org.apache.solr.servlet.HttpSolrCall - 
> null:java.lang.ArrayIndexOutOfBoundsException: 1
> at 
> org.apache.solr.search.grouping.distributed.shardresultserializer.TopGroupsResultTransformer.transformToNativeShardDoc(TopGroupsResultTransformer.java:175)
> at 
> org.apache.solr.search.grouping.distributed.shardresultserializer.TopGroupsResultTransformer.transformToNative(TopGroupsResultTransformer.java:137)
> at 
> org.apache.solr.search.grouping.distributed.responseprocessor.TopGroupsShardResponseProcessor.process(TopGroupsShardResponseProcessor.java:129)
> at 
> org.apache.solr.handler.component.QueryComponent.handleGroupedResponses(QueryComponent.java:750)
> at 
> org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:733)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:405)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2082)
> {code}
> The exception is thrown at the last line here 
> (TopGroupsResultTransformer.java line 175):
> {code}
>   protected ScoreDoc[] transformToNativeShardDoc(List 
> documents, Sort groupSort, String shard,
>  IndexSchema schema) {
> [...]
> for (NamedList document : documents) {
>   [...]
>   Object sortValuesVal = document.get("sortValues");
>   if (sortValuesVal != null) {
> sortValues = ((List) sortValuesVal).toArray();
> for (int k = 0; k < sortValues.length; k++) {
>   SchemaField field = groupSort.getSort()[k].getField() != null
>   ? schema.getFieldOrNull(groupSort.getSort()[k].getField()) : 
> null;
> {code}
> It's not obvious to me that {{sortValues.length == 
> groupSort.getSort().length}}, but I guess there's some logic behind it :)
> I have attached the schema and json result.
> The problem disappears when rolling back to 5.4.0.



--
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-6.x-Solaris (64bit/jdk1.8.0) - Build # 169 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/169/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.response.transform.TestSubQueryTransformerDistrib

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.response.transform.TestSubQueryTransformerDistrib: 1) 
Thread[id=42668, 
name=OverseerHdfsCoreFailoverThread-95992286034460682-127.0.0.1:65096_solr-n_01,
 state=TIMED_WAITING, group=Overseer Hdfs SolrCore Failover Thread.] at 
java.lang.Thread.sleep(Native Method) at 
org.apache.solr.cloud.OverseerAutoReplicaFailoverThread.run(OverseerAutoReplicaFailoverThread.java:137)
 at java.lang.Thread.run(Thread.java:745)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.response.transform.TestSubQueryTransformerDistrib: 
   1) Thread[id=42668, 
name=OverseerHdfsCoreFailoverThread-95992286034460682-127.0.0.1:65096_solr-n_01,
 state=TIMED_WAITING, group=Overseer Hdfs SolrCore Failover Thread.]
at java.lang.Thread.sleep(Native Method)
at 
org.apache.solr.cloud.OverseerAutoReplicaFailoverThread.run(OverseerAutoReplicaFailoverThread.java:137)
at java.lang.Thread.run(Thread.java:745)
at __randomizedtesting.SeedInfo.seed([CA8859203006FD5C]:0)


FAILED:  
junit.framework.TestSuite.org.apache.solr.response.transform.TestSubQueryTransformerDistrib

Error Message:
There are still zombie threads that couldn't be terminated:1) 
Thread[id=42668, 
name=OverseerHdfsCoreFailoverThread-95992286034460682-127.0.0.1:65096_solr-n_01,
 state=RUNNABLE, group=Overseer Hdfs SolrCore Failover Thread.] at 
java.lang.Thread.interrupt0(Native Method) at 
java.lang.Thread.interrupt(Thread.java:923) at 
org.apache.solr.cloud.OverseerAutoReplicaFailoverThread.run(OverseerAutoReplicaFailoverThread.java:139)
 at java.lang.Thread.run(Thread.java:745)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie 
threads that couldn't be terminated:
   1) Thread[id=42668, 
name=OverseerHdfsCoreFailoverThread-95992286034460682-127.0.0.1:65096_solr-n_01,
 state=RUNNABLE, group=Overseer Hdfs SolrCore Failover Thread.]
at java.lang.Thread.interrupt0(Native Method)
at java.lang.Thread.interrupt(Thread.java:923)
at 
org.apache.solr.cloud.OverseerAutoReplicaFailoverThread.run(OverseerAutoReplicaFailoverThread.java:139)
at java.lang.Thread.run(Thread.java:745)
at __randomizedtesting.SeedInfo.seed([CA8859203006FD5C]:0)




Build Log:
[...truncated 11465 lines...]
   [junit4] Suite: 
org.apache.solr.response.transform.TestSubQueryTransformerDistrib
   [junit4]   2> Creating dataDir: 
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/solr/build/solr-core/test/J1/temp/solr.response.transform.TestSubQueryTransformerDistrib_CA8859203006FD5C-001/init-core-data-001
   [junit4]   2> 2172957 INFO  
(SUITE-TestSubQueryTransformerDistrib-seed#[CA8859203006FD5C]-worker) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 2172958 INFO  (Thread-7219) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 2172958 INFO  (Thread-7219) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 2173057 INFO  
(SUITE-TestSubQueryTransformerDistrib-seed#[CA8859203006FD5C]-worker) [] 
o.a.s.c.ZkTestServer start zk server on port:40354
   [junit4]   2> 2173058 INFO  
(SUITE-TestSubQueryTransformerDistrib-seed#[CA8859203006FD5C]-worker) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 2173058 INFO  
(SUITE-TestSubQueryTransformerDistrib-seed#[CA8859203006FD5C]-worker) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 2173061 INFO  (zkCallback-9524-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@76fc6918 
name:ZooKeeperConnection Watcher:127.0.0.1:40354 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 2173061 INFO  
(SUITE-TestSubQueryTransformerDistrib-seed#[CA8859203006FD5C]-worker) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 2173061 INFO  
(SUITE-TestSubQueryTransformerDistrib-seed#[CA8859203006FD5C]-worker) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 2173061 INFO  
(SUITE-TestSubQueryTransformerDistrib-seed#[CA8859203006FD5C]-worker) [] 
o.a.s.c.c.SolrZkClient makePath: /solr/solr.xml
   [junit4]   2> 2173066 INFO  (jetty-launcher-9523-thread-1) [] 
o.e.j.s.Server jetty-9.3.8.v20160314
   [junit4]   2> 2173067 INFO  (jetty-launcher-9523-thread-2) [] 
o.e.j.s.Server jetty-9.3.8.v20160314
   [junit4]   2> 2173068 INFO  (jetty-launcher-9523-thread-5) [] 
o.e.j.s.Server jetty-9.3.8.v20160314
   

[jira] [Commented] (SOLR-6741) IPv6 Field Type

[Erick Erickson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15308500#comment-15308500
 ] 

Erick Erickson commented on SOLR-6741:
--

Again assigned it to myself but if someone else wants to pick this up, please 
feel free.

I have no idea how this plays with LUCENE-7043 at all, but it _really_ looks 
like it should use the InetAddressPoint. I have no idea when I'll be able to 
even take a look. This JIRA though has a bunch of tests that we should respect 
and possibly expand to IPV6 as well.

I've had an offline conversation that claims that the current patch should have 
this change:
 protected static boolean isCidrPrefixInteger(String str) {
return str.matches("^(3[0-2]|[1-2][0-9]|[1-9])$");
  }

Not putting it in the patch pending review of the patch itself to see how it 
would all fit.

> IPv6 Field Type
> ---
>
> Key: SOLR-6741
> URL: https://issues.apache.org/jira/browse/SOLR-6741
> Project: Solr
>  Issue Type: Improvement
>Reporter: Lloyd Ramey
>Assignee: Erick Erickson
> Attachments: SOLR-6741.patch
>
>
> It would be nice if Solr had a field type which could be used to index IPv6 
> data and supported efficient range queries. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Assigned] (SOLR-6741) IPv6 Field Type

[Erick Erickson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-6741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erick Erickson reassigned SOLR-6741:


Assignee: Erick Erickson

> IPv6 Field Type
> ---
>
> Key: SOLR-6741
> URL: https://issues.apache.org/jira/browse/SOLR-6741
> Project: Solr
>  Issue Type: Improvement
>Reporter: Lloyd Ramey
>Assignee: Erick Erickson
> Attachments: SOLR-6741.patch
>
>
> It would be nice if Solr had a field type which could be used to index IPv6 
> data and supported efficient range queries. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-8981) Upgrade to Tika 1.13 when it is available

[Tim Allison (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15308355#comment-15308355
 ] 

Tim Allison edited comment on SOLR-8981 at 5/31/16 7:27 PM:


I'm getting a failure on that test too.  I'm getting exactly the same output 
with the standalone Tika 1.7 and 1.13 apps on the test file...argh...

For some reason, it looks like Tika is now emitting 2 bodies, if you double the 
body in both tests, this now works:
{noformat}
ExtractingParams.XPATH_EXPRESSION, 
"/xhtml:html/xhtml:body/xhtml:body/xhtml:a/descendant::node()",
{noformat}
{noformat}
"xpath", "/xhtml:html/xhtml:body/xhtml:body/xhtml:div//node()",
{noformat}


was (Author: talli...@mitre.org):
I'm getting a failure on that test too.  I can't figure out what's going on.  
I'm getting exactly the same output with the standalone Tika 1.7 and 1.13 apps 
on the test file...argh...

> Upgrade to Tika 1.13 when it is available
> -
>
> Key: SOLR-8981
> URL: https://issues.apache.org/jira/browse/SOLR-8981
> Project: Solr
>  Issue Type: Improvement
>Reporter: Tim Allison
>Priority: Minor
>
> Tika 1.13 should be out within a month.  This includes PDFBox 2.0.0 and a 
> number of other upgrades and improvements.  
> If there are any showstoppers in 1.13 from Solr's side or requests before we 
> roll 1.13, let us know.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8096) Major faceting performance regressions

[Joel Bernstein (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15308387#comment-15308387
 ] 

Joel Bernstein commented on SOLR-8096:
--

I haven't reviewed the code, but if the enum faceting is actually using FCS 
then this is a bug. It would also explain the regression on enum faceting that 
has been reported.

> Major faceting performance regressions
> --
>
> Key: SOLR-8096
> URL: https://issues.apache.org/jira/browse/SOLR-8096
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.0, 5.1, 5.2, 5.3, 6.0
>Reporter: Yonik Seeley
>Priority: Critical
> Attachments: simple_facets.diff
>
>
> Use of the highly optimized faceting that Solr had for multi-valued fields 
> over relatively static indexes was removed as part of LUCENE-5666, causing 
> severe performance regressions.
> Here are some quick benchmarks to gauge the damage, on a 5M document index, 
> with each field having between 0 and 5 values per document.  *Higher numbers 
> represent worse 5x performance*.
> Solr 5.4_dev faceting time as a percent of Solr 4.10.3 faceting time  
> ||...|| Percent of index being faceted
> ||num_unique_values|| 10% || 50% || 90% ||
> |10   | 351.17%   | 1587.08%  | 3057.28% |
> |100  | 158.10%   | 203.61%   | 1421.93% |
> |1000 | 143.78%   | 168.01%   | 1325.87% |
> |1| 137.98%   | 175.31%   | 1233.97% |
> |10   | 142.98%   | 159.42%   | 1252.45% |
> |100  | 255.15%   | 165.17%   | 1236.75% |
> For example, a field with 1000 unique values in the whole index, faceting 
> with 5x took 143% of the 4x time, when ~10% of the docs in the index were 
> faceted.
> One user who brought the performance problem to our attention: 
> http://markmail.org/message/ekmqh4ocbkwxv3we
> "faceting is unusable slow since upgrade to 5.3.0" (from 4.10.3)
> The disabling of the UnInvertedField algorithm was previously discovered in 
> SOLR-7190, but we didn't know just how bad the problem was at that time.
> edit: removed "secret" adverb by request



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8981) Upgrade to Tika 1.13 when it is available

[Tim Allison (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15308355#comment-15308355
 ] 

Tim Allison commented on SOLR-8981:
---

I'm getting a failure on that test too.  I can't figure out what's going on.  
I'm getting exactly the same output with the standalone Tika 1.7 and 1.13 apps 
on the test file...argh...

> Upgrade to Tika 1.13 when it is available
> -
>
> Key: SOLR-8981
> URL: https://issues.apache.org/jira/browse/SOLR-8981
> Project: Solr
>  Issue Type: Improvement
>Reporter: Tim Allison
>Priority: Minor
>
> Tika 1.13 should be out within a month.  This includes PDFBox 2.0.0 and a 
> number of other upgrades and improvements.  
> If there are any showstoppers in 1.13 from Solr's side or requests before we 
> roll 1.13, let us know.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8940) ArrayIndexOutOfBoundsException in TopGroupsResultTransformer.transformToNativeShardDoc after upgrading to 5.5.0

[Hoss Man (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15308333#comment-15308333
 ] 

Hoss Man commented on SOLR-8940:



Henrik: your patch would definitely just mask the underlying problem.

The crux of the issue seems to be that the code is convoluting 
variables/properties of "sorting within groups" and "sorting the groups" -- the 
AIOOBE happens anytime the (effective) value of {{group.sort}} (how docs in a 
group are sorted) has more clauses then the (effective) value of the {{sort}} 
param (how the groups are sorted).

Henrik: wih your suggested patch, the AIOOBE may goe away, in your sample query 
but i think that's only because it's ignroning any group.sort clauses after the 
first one (since hte default effective value of the "sort" param is one clause: 
"score desc").

But even when sort & group.sort have the exact same number of clauses, there 
are still bugs.  For example using the techproducs sample data (in a 2 shard 
cloud collection) this query throws an error about not being able to fast a 
Float to a String because of how the sort metadata is getting confused between 
the sort=id vs the group.sort=price...

http://localhost:8983/solr/techproducts/select?wt=json=true=id,name,price=solr+memory=true=id+asc=manu_exact=2=price+desc

...in a single node collection (bin/solr -e techproducts) that query works just 
fine.

I suspect this bug was introduced by a mistake in some of the refactoring in 
LUCENE-6900, but it doesn't immediately jump out at me when skimming the diff 
... i'll review more throughly a bit later today.



> ArrayIndexOutOfBoundsException in 
> TopGroupsResultTransformer.transformToNativeShardDoc after upgrading to 5.5.0
> ---
>
> Key: SOLR-8940
> URL: https://issues.apache.org/jira/browse/SOLR-8940
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 5.5, 5.5.1
>Reporter: Henrik
>Priority: Blocker
>  Labels: 5.5, arrayindexoutofbounds, exception, query, 
> regression, search
> Attachments: 
> 0001-SOLR-8940-Avoid-ArrayIndexOutOfBoundsException-in-To.patch, 
> schema-types.xml, schema.xml, solr-query-exception.txt, solrconfig.xml
>
>
> We get an ArrayIndexOutOfBoundsException when searching after upgrading to 
> solr 5.5.
> Here's the query:
> {code}
> "params":{
>   "q":"*:*",
>   "group.sort":"priceAmount asc,rnd desc",
>   "indent":"on",
>   "fl":"priceAmount,flightTripId,brand,slob,cabinType,tripDuration",
>   "group.limit":"100",
>   "fq":["searchId:e31a0c58-9056-4297-8d70-049017ba4906",
> "doctype:offer",
> "flightTripId:(DY6020421-SK2360519 OR DY6020421-SK2600519 OR 
> DY6020421-SK2620519 OR DY6020421-SK2740519 OR DY6020421-SK2900519 OR 
> DY6020421-SK2860519 OR DY6040421-SK2380519 OR DY6040421-SK2440519 OR 
> DY6040421-SK2480519 OR DY6040421-SK2520519 OR DY6040421-SK2600519 OR 
> DY6040421-SK2620519 OR DY6040421-SK2720519 OR DY6040421-SK2740519 OR 
> DY6040421-SK2800519 OR DY6040421-SK2840519 OR DY6040421-SK2820519 OR 
> DY6060421-SK2480519 OR DY6060421-SK2740519 OR DY6060421-SK2800519 OR 
> DY6060421-SK2840519 OR DY6060421-SK2900519 OR DY6060421-SK2860519 OR 
> DY6060421-SK2820519 OR DY6080421-SK2440519)",
> "maximumLegDuration:[* TO 180]",
> "departureAirportLeg1:(OSL)",
> "(arrivalAirportLeg2:(OSL) OR (* NOT arrivalAirportLeg2:*))",
> "arrivalAirportLeg1:(BGO)",
> "(departureAirportLeg2:(BGO) OR (* NOT departureAirportLeg2:*))"],
>   "group.ngroups":"true",
>   "wt":"json",
>   "group.field":"flightTripId",
>   "group":"true"}}
> {code}
> And here's the exception:
> {code}
> ERROR [20160404T104846,333] qtp315138752-3037 
> org.apache.solr.servlet.HttpSolrCall - 
> null:java.lang.ArrayIndexOutOfBoundsException: 1
> at 
> org.apache.solr.search.grouping.distributed.shardresultserializer.TopGroupsResultTransformer.transformToNativeShardDoc(TopGroupsResultTransformer.java:175)
> at 
> org.apache.solr.search.grouping.distributed.shardresultserializer.TopGroupsResultTransformer.transformToNative(TopGroupsResultTransformer.java:137)
> at 
> org.apache.solr.search.grouping.distributed.responseprocessor.TopGroupsShardResponseProcessor.process(TopGroupsShardResponseProcessor.java:129)
> at 
> org.apache.solr.handler.component.QueryComponent.handleGroupedResponses(QueryComponent.java:750)
> at 
> org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:733)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:405)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
> at 

[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 79 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.x/79/

2 tests failed.
FAILED:  org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test

Error Message:
Captured an uncaught exception in thread: Thread[id=43325, name=collection5, 
state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=43325, name=collection5, state=RUNNABLE, 
group=TGRP-CollectionsAPIDistributedZkTest]
Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:47057: collection already exists: 
awholynewstresscollection_collection5_0
at __randomizedtesting.SeedInfo.seed([36E19CFDDC88E5BE]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:590)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:404)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:357)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1228)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:998)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:934)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1599)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1620)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:987)


FAILED:  org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test

Error Message:
Captured an uncaught exception in thread: Thread[id=108667, name=Thread-7641, 
state=RUNNABLE, group=TGRP-FullSolrCloudDistribCmdsTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=108667, name=Thread-7641, state=RUNNABLE, 
group=TGRP-FullSolrCloudDistribCmdsTest]
Caused by: java.lang.RuntimeException: 
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:36119/collection1
at __randomizedtesting.SeedInfo.seed([36E19CFDDC88E5BE]:0)
at 
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest$1IndexThread.run(FullSolrCloudDistribCmdsTest.java:644)
Caused by: org.apache.solr.client.solrj.SolrServerException: Timeout occured 
while waiting response from server at: http://127.0.0.1:36119/collection1
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:601)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:166)
at 
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest$1IndexThread.run(FullSolrCloudDistribCmdsTest.java:642)
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:170)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at 
org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:160)
at 
org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:84)
at 
org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:273)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
at 
org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
at 
org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:283)
at 
org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:251)
at 
org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:197)
at 

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+120) - Build # 16881 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16881/
Java: 64bit/jdk-9-ea+120 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.util.SolrPluginUtilsTest.testInvokeSetters

Error Message:
argument type mismatch

Stack Trace:
java.lang.IllegalArgumentException: argument type mismatch
at 
__randomizedtesting.SeedInfo.seed([EB11928FFA37323D:820E398F0F015096]:0)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
at 
org.apache.solr.util.SolrPluginUtils.invokeSetters(SolrPluginUtils.java:1071)
at 
org.apache.solr.util.SolrPluginUtilsTest.implTestInvokeSetters(SolrPluginUtilsTest.java:482)
at 
org.apache.solr.util.SolrPluginUtilsTest.testInvokeSetters(SolrPluginUtilsTest.java:474)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 

Re: [JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+120) - Build # 16869 - Still Failing!

[Steve Rowe]

You’re right Hoss, I misread the bounds check in my JDK’s source 
Random.nextInt() as allowing zero.

> On May 31, 2016, at 1:02 PM, Chris Hostetter  wrote:
> 
> 
> : This failure looks impossible to me - docsSent, an AtomicInteger 
> : initialized at 0 with only .incrementAndGet() and .get() called on it, 
> : should never be less than zero - I don’t have Java9 but this does not 
> : reproduce with Java8:
> 
> It wouldn't have to be less then zero -- if the value was zero this same 
> IllegalArgumentException would be thrown from Random.nextInt.
> 
> AS for why the value would still be zero by the time it gets to that line 
> ... no idea.  This test is pretty light on logging / exception handling. 
> 
> 
> : > On May 30, 2016, at 9:44 AM, Policeman Jenkins Server 
>  wrote:
> : > 
> : > Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16869/
> : > Java: 64bit/jdk-9-ea+120 -XX:-UseCompressedOops -XX:+UseG1GC
> : > 
> : > FAILED:  
> org.apache.solr.cloud.DistributedVersionInfoTest.testReplicaVersionHandling
> : > 
> : > Error Message:
> : > Captured an uncaught exception in thread: Thread[id=11139, 
> name=Thread-3542, state=RUNNABLE, group=TGRP-DistributedVersionInfoTest]
> : > 
> : > Stack Trace:
> : > com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an 
> uncaught exception in thread: Thread[id=11139, name=Thread-3542, 
> state=RUNNABLE, group=TGRP-DistributedVersionInfoTest]
> : >   at 
> __randomizedtesting.SeedInfo.seed([C143D2FAB9AFC4F3:1DBA05001BD40EB2]:0)
> : > Caused by: java.lang.IllegalArgumentException: bound must be positive
> : >   at __randomizedtesting.SeedInfo.seed([C143D2FAB9AFC4F3]:0)
> : >   at java.util.Random.nextInt(java.base@9-ea/Random.java:388)
> : >   at 
> org.apache.solr.cloud.DistributedVersionInfoTest$3.run(DistributedVersionInfoTest.java:204)
> : 
> : 
> : 
> : -
> : To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> : For additional commands, e-mail: dev-h...@lucene.apache.org
> : 
> : 
> 
> -Hoss
> http://www.lucidworks.com/
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9174) After Solr 5.5, mm parameter doesn't work properly

[Ahmet Arslan (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15308266#comment-15308266
 ] 

Ahmet Arslan commented on SOLR-9174:


Can someone explain why (e)dismax should honor/respect/care the {{q.op}} 
parameter?
(e)dismax has its own parameter {{mm}} for the task.

> After Solr 5.5, mm parameter doesn't work properly
> --
>
> Key: SOLR-9174
> URL: https://issues.apache.org/jira/browse/SOLR-9174
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers, search
>Affects Versions: 5.5, 6.0, 6.0.1
>Reporter: Issei Nishigata
>
> “mm" parameter does not work properly, when I set "q.op=AND” after Solr 5.5.
> In Solr 5.4, mm parameter works expectedly with the following setting.
> [schema]
> {code:xml}
> 
>   
>  maxGramSize="2"/>
>   
> 
> {code}
> [request]
> {quote}
> http://localhost:8983/solr/collection1/select?defType=edismax=AND=2=solar
> {quote}
> After Solr 5.5, the result will not be the same as Solr 5.4.
> [Solr 5.4]
> {code:xml}
> 
> ...
>   
> 2
> solar
> edismax
> AND
>   
> ...
> 
>   
> 0
> 
>   solr
> 
>   
> 
> 
>   solar
>   solar
>   
>   (+DisjunctionMaxQuerytext:so text:ol text:la text:ar)~2/no_coord
>   
>   +(((text:so text:ol text:la 
> text:ar)~2))
>   ...
> 
> {code}
> [Solr 6.0.1]
> {code:xml}
> 
> ...
>   
> 2
> solar
> edismax
> AND
>   
> ...
> 
>   
> solar
> solar
> 
> (+DisjunctionMaxQuery(((+text:so +text:ol +text:la +text:ar/no_coord
> 
> +((+text:so +text:ol +text:la 
> +text:ar))
> ...
> {code}
> As shown above, parsedquery also differs from Solr 5.4 and Solr 6.0.1(after 
> Solr 5.5).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9174) After Solr 5.5, mm parameter doesn't work properly

[Issei Nishigata (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15308192#comment-15308192
 ] 

Issei Nishigata commented on SOLR-9174:
---

Thank you for your suggestion.

Is q.op=OR completely replaceable with q.op=AND parameter?
Is the result with q.op=OR perfectly identical with the result with q.op=AND 
parameter 
as long as mm parameter is used, even under different condition such that there 
are multiple search words?
If so, I will use q.op=OR tentatively.

> After Solr 5.5, mm parameter doesn't work properly
> --
>
> Key: SOLR-9174
> URL: https://issues.apache.org/jira/browse/SOLR-9174
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers, search
>Affects Versions: 5.5, 6.0, 6.0.1
>Reporter: Issei Nishigata
>
> “mm" parameter does not work properly, when I set "q.op=AND” after Solr 5.5.
> In Solr 5.4, mm parameter works expectedly with the following setting.
> [schema]
> {code:xml}
> 
>   
>  maxGramSize="2"/>
>   
> 
> {code}
> [request]
> {quote}
> http://localhost:8983/solr/collection1/select?defType=edismax=AND=2=solar
> {quote}
> After Solr 5.5, the result will not be the same as Solr 5.4.
> [Solr 5.4]
> {code:xml}
> 
> ...
>   
> 2
> solar
> edismax
> AND
>   
> ...
> 
>   
> 0
> 
>   solr
> 
>   
> 
> 
>   solar
>   solar
>   
>   (+DisjunctionMaxQuerytext:so text:ol text:la text:ar)~2/no_coord
>   
>   +(((text:so text:ol text:la 
> text:ar)~2))
>   ...
> 
> {code}
> [Solr 6.0.1]
> {code:xml}
> 
> ...
>   
> 2
> solar
> edismax
> AND
>   
> ...
> 
>   
> solar
> solar
> 
> (+DisjunctionMaxQuery(((+text:so +text:ol +text:la +text:ar/no_coord
> 
> +((+text:so +text:ol +text:la 
> +text:ar))
> ...
> {code}
> As shown above, parsedquery also differs from Solr 5.4 and Solr 6.0.1(after 
> Solr 5.5).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9176) Legacy Faceting Term Enum Method Regression

[Alessandro Benedetti (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15308128#comment-15308128
 ] 

Alessandro Benedetti commented on SOLR-9176:


[~rcmuir] I know it is an old commit, but do you have any idea about the reason 
of that change?

org/apache/solr/request/SimpleFacets.java:431

> Legacy Faceting Term Enum Method Regression
> ---
>
> Key: SOLR-9176
> URL: https://issues.apache.org/jira/browse/SOLR-9176
> Project: Solr
>  Issue Type: Bug
>  Components: faceting
>Affects Versions: 5.2, 5.2.1, 5.3, 5.3.1, 5.3.2, 5.4, 5.4.1, 5.5, 5.5.1, 
> 6.0, 6.0.1
>Reporter: Alessandro Benedetti
>
> Starting from this commit :
> LUCENE-5666: get solr started
> git-svn-id: 
> https://svn.apache.org/repos/asf/lucene/dev/branches/lucene5666@1594254 
> 13f79535-47bb-0310-9956-ffa450edef68
> https://github.com/apache/lucene-solr/commit/1489085807cb10981a7ea5b5663ada4e3f85953e#diff-5ac9dc7b128b4dd99b764060759222b2
> It is not possible to use Term Enum as a faceting method, for numeric and 
> single valued fields ( org.apache.solr.request.SimpleFacets ) .
> We personally verified that there are use cases when this is bringing a quite 
> big performance regression  ( even with DocValues enabled) .
> In the mailing list from time to time people complain about a regression 
> happening with the term enum method, but actually it is more likely to be the 
>   automatic forcing of FCS.
> Forcing FCS in co-op with the famous regression that happened in SOLR-8096 
> could be confused as a term Enum regression.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9176) Legacy Faceting Term Enum Method Regression

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15308122#comment-15308122
 ] 

ASF GitHub Bot commented on SOLR-9176:
--

Github user alessandrobenedetti commented on the pull request:


https://github.com/apache/lucene-solr/commit/1489085807cb10981a7ea5b5663ada4e3f85953e#commitcomment-17682489
  
In solr/core/src/java/org/apache/solr/request/SimpleFacets.java:
In solr/core/src/java/org/apache/solr/request/SimpleFacets.java on line 392:
https://issues.apache.org/jira/browse/SOLR-9176


> Legacy Faceting Term Enum Method Regression
> ---
>
> Key: SOLR-9176
> URL: https://issues.apache.org/jira/browse/SOLR-9176
> Project: Solr
>  Issue Type: Bug
>  Components: faceting
>Affects Versions: 5.2, 5.2.1, 5.3, 5.3.1, 5.3.2, 5.4, 5.4.1, 5.5, 5.5.1, 
> 6.0, 6.0.1
>Reporter: Alessandro Benedetti
>
> Starting from this commit :
> LUCENE-5666: get solr started
> git-svn-id: 
> https://svn.apache.org/repos/asf/lucene/dev/branches/lucene5666@1594254 
> 13f79535-47bb-0310-9956-ffa450edef68
> https://github.com/apache/lucene-solr/commit/1489085807cb10981a7ea5b5663ada4e3f85953e#diff-5ac9dc7b128b4dd99b764060759222b2
> It is not possible to use Term Enum as a faceting method, for numeric and 
> single valued fields ( org.apache.solr.request.SimpleFacets ) .
> We personally verified that there are use cases when this is bringing a quite 
> big performance regression  ( even with DocValues enabled) .
> In the mailing list from time to time people complain about a regression 
> happening with the term enum method, but actually it is more likely to be the 
>   automatic forcing of FCS.
> Forcing FCS in co-op with the famous regression that happened in SOLR-8096 
> could be confused as a term Enum regression.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] lucene-solr pull request:

[alessandrobenedetti]

Github user alessandrobenedetti commented on the pull request:


https://github.com/apache/lucene-solr/commit/1489085807cb10981a7ea5b5663ada4e3f85953e#commitcomment-17682489
  
In solr/core/src/java/org/apache/solr/request/SimpleFacets.java:
In solr/core/src/java/org/apache/solr/request/SimpleFacets.java on line 392:
https://issues.apache.org/jira/browse/SOLR-9176


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+120) - Build # 16869 - Still Failing!

[Chris Hostetter]

: This failure looks impossible to me - docsSent, an AtomicInteger 
: initialized at 0 with only .incrementAndGet() and .get() called on it, 
: should never be less than zero - I don’t have Java9 but this does not 
: reproduce with Java8:

It wouldn't have to be less then zero -- if the value was zero this same 
IllegalArgumentException would be thrown from Random.nextInt.

AS for why the value would still be zero by the time it gets to that line 
... no idea.  This test is pretty light on logging / exception handling. 


: > On May 30, 2016, at 9:44 AM, Policeman Jenkins Server  
wrote:
: > 
: > Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16869/
: > Java: 64bit/jdk-9-ea+120 -XX:-UseCompressedOops -XX:+UseG1GC
: > 
: > FAILED:  
org.apache.solr.cloud.DistributedVersionInfoTest.testReplicaVersionHandling
: > 
: > Error Message:
: > Captured an uncaught exception in thread: Thread[id=11139, 
name=Thread-3542, state=RUNNABLE, group=TGRP-DistributedVersionInfoTest]
: > 
: > Stack Trace:
: > com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an 
uncaught exception in thread: Thread[id=11139, name=Thread-3542, 
state=RUNNABLE, group=TGRP-DistributedVersionInfoTest]
: > at 
__randomizedtesting.SeedInfo.seed([C143D2FAB9AFC4F3:1DBA05001BD40EB2]:0)
: > Caused by: java.lang.IllegalArgumentException: bound must be positive
: > at __randomizedtesting.SeedInfo.seed([C143D2FAB9AFC4F3]:0)
: > at java.util.Random.nextInt(java.base@9-ea/Random.java:388)
: > at 
org.apache.solr.cloud.DistributedVersionInfoTest$3.run(DistributedVersionInfoTest.java:204)
: 
: 
: 
: -
: To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
: For additional commands, e-mail: dev-h...@lucene.apache.org
: 
: 

-Hoss
http://www.lucidworks.com/

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8096) Major faceting performance regressions

[Alessandro Benedetti (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15308099#comment-15308099
 ] 

Alessandro Benedetti commented on SOLR-8096:


We found finally our suspect !

https://issues.apache.org/jira/browse/SOLR-9176

I would like an opinion soon, it seems to me, a mistake, as the code is not 
equivalent and in the commit message there is no reason why we have lost the 
possibility of using the term Enum for single valued numeric fields.
For static indexes I can confirm this causes a visible performance regression ( 
very hidden as you think to use Term Enum while actually Solr uses FCS under 
the hood)

> Major faceting performance regressions
> --
>
> Key: SOLR-8096
> URL: https://issues.apache.org/jira/browse/SOLR-8096
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.0, 5.1, 5.2, 5.3, 6.0
>Reporter: Yonik Seeley
>Priority: Critical
> Attachments: simple_facets.diff
>
>
> Use of the highly optimized faceting that Solr had for multi-valued fields 
> over relatively static indexes was removed as part of LUCENE-5666, causing 
> severe performance regressions.
> Here are some quick benchmarks to gauge the damage, on a 5M document index, 
> with each field having between 0 and 5 values per document.  *Higher numbers 
> represent worse 5x performance*.
> Solr 5.4_dev faceting time as a percent of Solr 4.10.3 faceting time  
> ||...|| Percent of index being faceted
> ||num_unique_values|| 10% || 50% || 90% ||
> |10   | 351.17%   | 1587.08%  | 3057.28% |
> |100  | 158.10%   | 203.61%   | 1421.93% |
> |1000 | 143.78%   | 168.01%   | 1325.87% |
> |1| 137.98%   | 175.31%   | 1233.97% |
> |10   | 142.98%   | 159.42%   | 1252.45% |
> |100  | 255.15%   | 165.17%   | 1236.75% |
> For example, a field with 1000 unique values in the whole index, faceting 
> with 5x took 143% of the 4x time, when ~10% of the docs in the index were 
> faceted.
> One user who brought the performance problem to our attention: 
> http://markmail.org/message/ekmqh4ocbkwxv3we
> "faceting is unusable slow since upgrade to 5.3.0" (from 4.10.3)
> The disabling of the UnInvertedField algorithm was previously discovered in 
> SOLR-7190, but we didn't know just how bad the problem was at that time.
> edit: removed "secret" adverb by request



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-9176) Legacy Faceting Term Enum Method Regression

[Alessandro Benedetti (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15308089#comment-15308089
 ] 

Alessandro Benedetti edited comment on SOLR-9176 at 5/31/16 4:53 PM:
-

The same commit seems to be involved [~yo...@apache.org]


was (Author: alessandro.benedetti):
The same commit seems to be involved.

> Legacy Faceting Term Enum Method Regression
> ---
>
> Key: SOLR-9176
> URL: https://issues.apache.org/jira/browse/SOLR-9176
> Project: Solr
>  Issue Type: Bug
>  Components: faceting
>Affects Versions: 5.2, 5.2.1, 5.3, 5.3.1, 5.3.2, 5.4, 5.4.1, 5.5, 5.5.1, 
> 6.0, 6.0.1
>Reporter: Alessandro Benedetti
>
> Starting from this commit :
> LUCENE-5666: get solr started
> git-svn-id: 
> https://svn.apache.org/repos/asf/lucene/dev/branches/lucene5666@1594254 
> 13f79535-47bb-0310-9956-ffa450edef68
> https://github.com/apache/lucene-solr/commit/1489085807cb10981a7ea5b5663ada4e3f85953e#diff-5ac9dc7b128b4dd99b764060759222b2
> It is not possible to use Term Enum as a faceting method, for numeric and 
> single valued fields ( org.apache.solr.request.SimpleFacets ) .
> We personally verified that there are use cases when this is bringing a quite 
> big performance regression  ( even with DocValues enabled) .
> In the mailing list from time to time people complain about a regression 
> happening with the term enum method, but actually it is more likely to be the 
>   automatic forcing of FCS.
> Forcing FCS in co-op with the famous regression that happened in SOLR-8096 
> could be confused as a term Enum regression.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9176) Legacy Faceting Term Enum Method Regression

[Alessandro Benedetti (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15308089#comment-15308089
 ] 

Alessandro Benedetti commented on SOLR-9176:


The same commit seems to be involved.

> Legacy Faceting Term Enum Method Regression
> ---
>
> Key: SOLR-9176
> URL: https://issues.apache.org/jira/browse/SOLR-9176
> Project: Solr
>  Issue Type: Bug
>  Components: faceting
>Affects Versions: 5.2, 5.2.1, 5.3, 5.3.1, 5.3.2, 5.4, 5.4.1, 5.5, 5.5.1, 
> 6.0, 6.0.1
>Reporter: Alessandro Benedetti
>
> Starting from this commit :
> LUCENE-5666: get solr started
> git-svn-id: 
> https://svn.apache.org/repos/asf/lucene/dev/branches/lucene5666@1594254 
> 13f79535-47bb-0310-9956-ffa450edef68
> https://github.com/apache/lucene-solr/commit/1489085807cb10981a7ea5b5663ada4e3f85953e#diff-5ac9dc7b128b4dd99b764060759222b2
> It is not possible to use Term Enum as a faceting method, for numeric and 
> single valued fields ( org.apache.solr.request.SimpleFacets ) .
> We personally verified that there are use cases when this is bringing a quite 
> big performance regression  ( even with DocValues enabled) .
> In the mailing list from time to time people complain about a regression 
> happening with the term enum method, but actually it is more likely to be the 
>   automatic forcing of FCS.
> Forcing FCS in co-op with the famous regression that happened in SOLR-8096 
> could be confused as a term Enum regression.



--
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-9176) Legacy Faceting Term Enum Method Regression

[Alessandro Benedetti (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-9176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alessandro Benedetti updated SOLR-9176:
---
Description: 
Starting from this commit :

LUCENE-5666: get solr started
git-svn-id: 
https://svn.apache.org/repos/asf/lucene/dev/branches/lucene5666@1594254 
13f79535-47bb-0310-9956-ffa450edef68

https://github.com/apache/lucene-solr/commit/1489085807cb10981a7ea5b5663ada4e3f85953e#diff-5ac9dc7b128b4dd99b764060759222b2


It is not possible to use Term Enum as a faceting method, for numeric and 
single valued fields ( org.apache.solr.request.SimpleFacets ) .

We personally verified that there are use cases when this is bringing a quite 
big performance regression  ( even with DocValues enabled) .
In the mailing list from time to time people complain about a regression 
happening with the term enum method, but actually it is more likely to be the   
automatic forcing of FCS.

Forcing FCS in co-op with the famous regression that happened in SOLR-8096 
could be confused as a term Enum regression.

  was:
Starting from this commit :

LUCENE-5666: get solr started
git-svn-id: 
https://svn.apache.org/repos/asf/lucene/dev/branches/lucene5666@1594254 
13f79535-47bb-0310-9956-ffa450edef68

It is not possible to use Term Enum as a faceting method, for numeric and 
single valued fields.
We personally verified that there are use cases when this is bringing a quite 
big performance regression  ( even with DocValues enabled) .
In the mailing list from time to time people complain about a regression 
happening with the term enum method, but actually it is more likely to be the   
automatic forcing of FCS.

Forcing FCS in co-op with the famous regression that happened in SOLR-8096 
could be confused as a term Enum regression.


> Legacy Faceting Term Enum Method Regression
> ---
>
> Key: SOLR-9176
> URL: https://issues.apache.org/jira/browse/SOLR-9176
> Project: Solr
>  Issue Type: Bug
>  Components: faceting
>Affects Versions: 5.2, 5.2.1, 5.3, 5.3.1, 5.3.2, 5.4, 5.4.1, 5.5, 5.5.1, 
> 6.0, 6.0.1
>Reporter: Alessandro Benedetti
>
> Starting from this commit :
> LUCENE-5666: get solr started
> git-svn-id: 
> https://svn.apache.org/repos/asf/lucene/dev/branches/lucene5666@1594254 
> 13f79535-47bb-0310-9956-ffa450edef68
> https://github.com/apache/lucene-solr/commit/1489085807cb10981a7ea5b5663ada4e3f85953e#diff-5ac9dc7b128b4dd99b764060759222b2
> It is not possible to use Term Enum as a faceting method, for numeric and 
> single valued fields ( org.apache.solr.request.SimpleFacets ) .
> We personally verified that there are use cases when this is bringing a quite 
> big performance regression  ( even with DocValues enabled) .
> In the mailing list from time to time people complain about a regression 
> happening with the term enum method, but actually it is more likely to be the 
>   automatic forcing of FCS.
> Forcing FCS in co-op with the famous regression that happened in SOLR-8096 
> could be confused as a term Enum regression.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-9176) Legacy Faceting Term Enum Method Regression

[Alessandro Benedetti (JIRA)]

Alessandro Benedetti created SOLR-9176:
--

 Summary: Legacy Faceting Term Enum Method Regression
 Key: SOLR-9176
 URL: https://issues.apache.org/jira/browse/SOLR-9176
 Project: Solr
  Issue Type: Bug
  Components: faceting
Affects Versions: 6.0.1, 6.0, 5.5.1, 5.5, 5.4.1, 5.4, 5.3.2, 5.3.1, 5.3, 
5.2.1, 5.2
Reporter: Alessandro Benedetti


Starting from this commit :

LUCENE-5666: get solr started
git-svn-id: 
https://svn.apache.org/repos/asf/lucene/dev/branches/lucene5666@1594254 
13f79535-47bb-0310-9956-ffa450edef68

It is not possible to use Term Enum as a faceting method, for numeric and 
single valued fields.
We personally verified that there are use cases when this is bringing a quite 
big performance regression  ( even with DocValues enabled) .
In the mailing list from time to time people complain about a regression 
happening with the term enum method, but actually it is more likely to be the   
automatic forcing of FCS.

Forcing FCS in co-op with the famous regression that happened in SOLR-8096 
could be confused as a term Enum regression.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_92) - Build # 16880 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16880/
Java: 64bit/jdk1.8.0_92 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.util.SolrPluginUtilsTest.testInvokeSetters

Error Message:
argument type mismatch

Stack Trace:
java.lang.IllegalArgumentException: argument type mismatch
at 
__randomizedtesting.SeedInfo.seed([B524B13F0F92153C:DC3B1A3FFAA47797]:0)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.apache.solr.util.SolrPluginUtils.invokeSetters(SolrPluginUtils.java:1071)
at 
org.apache.solr.util.SolrPluginUtilsTest.implTestInvokeSetters(SolrPluginUtilsTest.java:482)
at 
org.apache.solr.util.SolrPluginUtilsTest.testInvokeSetters(SolrPluginUtilsTest.java:474)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Updated] (LUCENE-7307) Add getters to PointInSetQuery and PointRangeQuery classes

[Martijn van Groningen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Martijn van Groningen updated LUCENE-7307:
--
Attachment: LUCENE_7307.patch

> Add getters to PointInSetQuery and PointRangeQuery classes
> --
>
> Key: LUCENE-7307
> URL: https://issues.apache.org/jira/browse/LUCENE-7307
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Martijn van Groningen
>Priority: Trivial
> Attachments: LUCENE_7307.patch
>
>




--
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-7307) Add getters to PointInSetQuery and PointRangeQuery classes

[Martijn van Groningen (JIRA)]

Martijn van Groningen created LUCENE-7307:
-

 Summary: Add getters to PointInSetQuery and PointRangeQuery classes
 Key: LUCENE-7307
 URL: https://issues.apache.org/jira/browse/LUCENE-7307
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Martijn van Groningen
Priority: Trivial
 Attachments: LUCENE_7307.patch





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-7374) Backup/Restore should provide a param for specifying the directory implementation it should use

[Hrishikesh Gadre (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15307998#comment-15307998
 ] 

Hrishikesh Gadre commented on SOLR-7374:


[~varunthacker] could you please review the patch?

> Backup/Restore should provide a param for specifying the directory 
> implementation it should use
> ---
>
> Key: SOLR-7374
> URL: https://issues.apache.org/jira/browse/SOLR-7374
> Project: Solr
>  Issue Type: Bug
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Fix For: 5.2, 6.0
>
> Attachments: SOLR-7374.patch, SOLR-7374.patch, SOLR-7374.patch
>
>
> Currently when we create a backup we use SimpleFSDirectory to write the 
> backup indexes. Similarly during a restore we open the index using 
> FSDirectory.open . 
> We should provide a param called {{directoryImpl}} or {{type}} which will be 
> used to specify the Directory implementation to backup the index. 
> Likewise during a restore you would need to specify the directory impl which 
> was used during backup so that the index can be opened correctly.
> This param will address the problem that currently if a user is running Solr 
> on HDFS there is no way to use the backup/restore functionality as the 
> directory is hardcoded.
> With this one could be running Solr on a local FS but backup the index on 
> HDFS etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8029) Modernize and standardize Solr APIs

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15307924#comment-15307924
 ] 

ASF subversion and git services commented on SOLR-8029:
---

Commit f72c6914a83f6cf5b287c53beb40c52244ba5a9b in lucene-solr's branch 
refs/heads/apiv2 from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f72c691 ]

SOLR-8029: Added configset and blob store APIs to /v2 path


> Modernize and standardize Solr APIs
> ---
>
> Key: SOLR-8029
> URL: https://issues.apache.org/jira/browse/SOLR-8029
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.0
>Reporter: Noble Paul
>Assignee: Noble Paul
>  Labels: API, EaseOfUse
> Fix For: 6.0
>
> Attachments: SOLR-8029.patch, SOLR-8029.patch, SOLR-8029.patch, 
> SOLR-8029.patch
>
>
> Solr APIs have organically evolved and they are sometimes inconsistent with 
> each other or not in sync with the widely followed conventions of HTTP 
> protocol. Trying to make incremental changes to make them modern is like 
> applying band-aid. So, we have done a complete rethink of what the APIs 
> should be. The most notable aspects of the API are as follows:
> The new set of APIs will be placed under a new path {{/solr2}}. The legacy 
> APIs will continue to work under the {{/solr}} path as they used to and they 
> will be eventually deprecated.
> There are 4 types of requests in the new API 
> * {{/v2//*}} : Hit a collection directly or manage 
> collections/shards/replicas 
> * {{/v2//*}} : Hit a core directly or manage cores 
> * {{/v2/cluster/*}} : Operations on cluster not pertaining to any collection 
> or core. e.g: security, overseer ops etc
> This will be released as part of a major release. Check the link given below 
> for the full specification.  Your comments are welcome
> [Solr API version 2 Specification | http://bit.ly/1JYsBMQ]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS-EA] Lucene-Solr-6.x-Linux (64bit/jdk-9-ea+120) - Build # 787 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/787/
Java: 64bit/jdk-9-ea+120 -XX:-UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.cloud.TestCloudBackupRestore.test

Error Message:
Error from server at http://127.0.0.1:44702/solr: Backup directory already 
exists: 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/test/J0/temp/solr.cloud.TestCloudBackupRestore_94AFE3D5356C0B2E-001/tempDir-002/mytestbackup

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:44702/solr: Backup directory already exists: 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/test/J0/temp/solr.cloud.TestCloudBackupRestore_94AFE3D5356C0B2E-001/tempDir-002/mytestbackup
at 
__randomizedtesting.SeedInfo.seed([94AFE3D5356C0B2E:1CFBDC0F9B9066D6]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:590)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:404)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:357)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1228)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:998)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:934)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:166)
at 
org.apache.solr.cloud.TestCloudBackupRestore.testBackupAndRestore(TestCloudBackupRestore.java:153)
at 
org.apache.solr.cloud.TestCloudBackupRestore.test(TestCloudBackupRestore.java:110)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 

[jira] [Commented] (LUCENE-7306) Use radix sort for points too

[Michael McCandless (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15307780#comment-15307780
 ] 

Michael McCandless commented on LUCENE-7306:


Here's the direct URL to the indexing chart: 
http://people.apache.org/~mikemccand/geobench.html#index-times

Looks like [~jpountz] already added the annotation (thanks!), I just pushed it.

> Use radix sort for points too
> -
>
> Key: LUCENE-7306
> URL: https://issues.apache.org/jira/browse/LUCENE-7306
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 6.1, master (7.0)
>
> Attachments: LUCENE-7306.patch, LUCENE-7903.patch
>
>
> Like postings, points make heavy use of sorting at indexing time, so we 
> should try to leverage radix sort too?



--
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-7306) Use radix sort for points too

[Michael McCandless (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15307776#comment-15307776
 ] 

Michael McCandless commented on LUCENE-7306:


bq. Mike's benchmarks confirm the speedup with a +36% jump in indexing speed

Wow :)

I will add an annotation!  Thanks [~jpountz].

> Use radix sort for points too
> -
>
> Key: LUCENE-7306
> URL: https://issues.apache.org/jira/browse/LUCENE-7306
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 6.1, master (7.0)
>
> Attachments: LUCENE-7306.patch, LUCENE-7903.patch
>
>
> Like postings, points make heavy use of sorting at indexing time, so we 
> should try to leverage radix sort too?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_92) - Build # 16879 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16879/
Java: 64bit/jdk1.8.0_92 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.solr.common.cloud.TestCollectionStateWatchers.testWaitForStateWatcherIsRetainedOnPredicateFailure

Error Message:
Did not see a fully active cluster after 30 seconds

Stack Trace:
java.lang.AssertionError: Did not see a fully active cluster after 30 seconds
at 
__randomizedtesting.SeedInfo.seed([2FC6226AE4BA19AE:A7F080393C15F1BC]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.common.cloud.TestCollectionStateWatchers.testWaitForStateWatcherIsRetainedOnPredicateFailure(TestCollectionStateWatchers.java:227)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 13125 lines...]
   [junit4] Suite: org.apache.solr.common.cloud.TestCollectionStateWatchers
   [junit4]   2> Creating 

[jira] [Commented] (SOLR-7739) Lucene Classification Integration - UpdateRequestProcessor

[Tomas Ramanauskas (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15307712#comment-15307712
 ] 

Tomas Ramanauskas commented on SOLR-7739:
-

Hello, I tried this feature few days ago, but I couldn't get it to work. I left 
couple of comments on this Blog site with my examples:

https://alexbenedetti.blogspot.co.uk/2015/07/solr-document-classification-part-1.html

May someone who was able to get this feature to work, share some query 
examples? 

> Lucene Classification Integration - UpdateRequestProcessor
> --
>
> Key: SOLR-7739
> URL: https://issues.apache.org/jira/browse/SOLR-7739
> Project: Solr
>  Issue Type: New Feature
>  Components: update
>Reporter: Alessandro Benedetti
>Assignee: Tommaso Teofili
>Priority: Minor
>  Labels: classification, index-time, update.chain, 
> updateProperties
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-7739.1.patch, SOLR-7739.patch, SOLR-7739.patch, 
> SOLR-7739.patch
>
>
> It would be nice to have an UpdateRequestProcessor to interact with the 
> Lucene Classification Module and provide an easy way of auto classifying Solr 
> Documents on indexing.
> Documentation will be provided with the patch
> A first design will be provided soon.



--
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-7301) updateNumericDocValue mixed with updateDocument can cause data loss in some randomized testing

[Ishan Chattopadhyaya (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15307704#comment-15307704
 ] 

Ishan Chattopadhyaya commented on LUCENE-7301:
--

bq.  Hoss Man can you test it with your Solr issue and see if it works?
Thanks Mike, the patch seems to have fixed the randomized failure for the 
SOLR-5944 that I was fighting against all this while. I shall do a bit more 
beasting later today to see if there are other failures.

> updateNumericDocValue mixed with updateDocument can cause data loss in some 
> randomized testing
> --
>
> Key: LUCENE-7301
> URL: https://issues.apache.org/jira/browse/LUCENE-7301
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Hoss Man
> Attachments: LUCENE-7301.patch, LUCENE-7301.patch, LUCENE-7301.patch
>
>
> SOLR-5944 has been held up by a while due to some extremely rare randomized 
> test failures.
> Ishan and I have been working on whitling those Solr test failures down, 
> trying to create more isolated reproducable test failures, and i *think* i've 
> tracked it down to a bug in IndexWriter when the client calls to 
> updateDocument intermixed with calls to updateNumericDocValue *AND* 
> IndexWriterConfig.setMaxBufferedDocs is very low (i suspect "how low" depends 
> on the number of quantity/types of updates -- but *just* got something that 
> reproduced, and haven't tried reproducing with higher values of 
> maxBufferedDocs and larger sequences of updateDocument / 
> updateNumericDocValue calls.



--
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-7306) Use radix sort for points too

[Adrien Grand (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15307645#comment-15307645
 ] 

Adrien Grand commented on LUCENE-7306:
--

Mike's benchmarks confirm the speedup with a +36% jump in indexing speed: 
http://people.apache.org/~mikemccand/geobench.html

> Use radix sort for points too
> -
>
> Key: LUCENE-7306
> URL: https://issues.apache.org/jira/browse/LUCENE-7306
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 6.1, master (7.0)
>
> Attachments: LUCENE-7306.patch, LUCENE-7903.patch
>
>
> Like postings, points make heavy use of sorting at indexing time, so we 
> should try to leverage radix sort too?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_92) - Build # 5881 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/5881/
Java: 32bit/jdk1.8.0_92 -server -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.core.TestDynamicLoading.testDynamicLoading

Error Message:
Could not get expected value  'X val changed' for path 'x' full output: {   
"responseHeader":{ "status":0, "QTime":0},   "params":{"wt":"json"},   
"context":{ "webapp":"/ny_/s", "path":"/test1", 
"httpMethod":"GET"},   
"class":"org.apache.solr.core.BlobStoreTestRequestHandler",   "x":null},  from 
server:  null

Stack Trace:
java.lang.AssertionError: Could not get expected value  'X val changed' for 
path 'x' full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "params":{"wt":"json"},
  "context":{
"webapp":"/ny_/s",
"path":"/test1",
"httpMethod":"GET"},
  "class":"org.apache.solr.core.BlobStoreTestRequestHandler",
  "x":null},  from server:  null
at 
__randomizedtesting.SeedInfo.seed([8487D80219599D48:5CCAF555EE8438E8]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:457)
at 
org.apache.solr.core.TestDynamicLoading.testDynamicLoading(TestDynamicLoading.java:250)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Comment Edited] (SOLR-7452) json facet api returning inconsistent counts in cloud set up

[Saar Carmi (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15307627#comment-15307627
 ] 

Saar Carmi edited comment on SOLR-7452 at 5/31/16 12:06 PM:


Do you expect it to get into 5.5.2 ?  Thanks!


was (Author: saar32):
Do you expect it to get into 5.5.2 ? 

> json facet api returning inconsistent counts in cloud set up
> 
>
> Key: SOLR-7452
> URL: https://issues.apache.org/jira/browse/SOLR-7452
> Project: Solr
>  Issue Type: Bug
>  Components: Facet Module
>Affects Versions: 5.1
>Reporter: Vamsi Krishna D
>  Labels: count, facet, sort
> Fix For: 5.2
>
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> While using the newly added feature of json term facet api 
> (http://yonik.com/json-facet-api/#TermsFacet) I am encountering inconsistent 
> returns of counts of faceted value ( Note I am running on a cloud mode of 
> solr). For example consider that i have txns_id(unique field or key), 
> consumer_number and amount. Now for a 10 million such records , lets say i 
> query for 
> q=*:*=0&
>  json.facet={
>biskatoo:{
>type : terms,
>field : consumer_number,
>limit : 20,
>   sort : {y:desc},
>   numBuckets : true,
>   facet:{
>y : "sum(amount)"
>}
>}
>  }
> the results are as follows ( some are omitted ):
> "facets":{
> "count":6641277,
> "biskatoo":{
>   "numBuckets":3112708,
>   "buckets":[{
>   "val":"surya",
>   "count":4,
>   "y":2.264506},
>   {
>   "val":"raghu",
>   "COUNT":3,   // capitalised for recognition 
>   "y":1.8},
> {
>   "val":"malli",
>   "count":4,
>   "y":1.78}]}}}
> but if i restrict the query to 
> q=consumer_number:raghu=0&
>  json.facet={
>biskatoo:{
>type : terms,
>field : consumer_number,
>limit : 20,
>   sort : {y:desc},
>   numBuckets : true,
>   facet:{
>y : "sum(amount)"
>}
>}
>  }
> i get :
>   "facets":{
> "count":4,
> "biskatoo":{
>   "numBuckets":1,
>   "buckets":[{
>   "val":"raghu",
>   "COUNT":4,
>   "y":2429708.24}]}}}
> One can see the count results are inconsistent ( and I found many occasions 
> of inconsistencies).
> I have tried the patch https://issues.apache.org/jira/browse/SOLR-7412 but 
> still the issue seems not resolved



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-7452) json facet api returning inconsistent counts in cloud set up

[Saar Carmi (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15307627#comment-15307627
 ] 

Saar Carmi commented on SOLR-7452:
--

Do you expect it to get into 5.5.2 ? 

> json facet api returning inconsistent counts in cloud set up
> 
>
> Key: SOLR-7452
> URL: https://issues.apache.org/jira/browse/SOLR-7452
> Project: Solr
>  Issue Type: Bug
>  Components: Facet Module
>Affects Versions: 5.1
>Reporter: Vamsi Krishna D
>  Labels: count, facet, sort
> Fix For: 5.2
>
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> While using the newly added feature of json term facet api 
> (http://yonik.com/json-facet-api/#TermsFacet) I am encountering inconsistent 
> returns of counts of faceted value ( Note I am running on a cloud mode of 
> solr). For example consider that i have txns_id(unique field or key), 
> consumer_number and amount. Now for a 10 million such records , lets say i 
> query for 
> q=*:*=0&
>  json.facet={
>biskatoo:{
>type : terms,
>field : consumer_number,
>limit : 20,
>   sort : {y:desc},
>   numBuckets : true,
>   facet:{
>y : "sum(amount)"
>}
>}
>  }
> the results are as follows ( some are omitted ):
> "facets":{
> "count":6641277,
> "biskatoo":{
>   "numBuckets":3112708,
>   "buckets":[{
>   "val":"surya",
>   "count":4,
>   "y":2.264506},
>   {
>   "val":"raghu",
>   "COUNT":3,   // capitalised for recognition 
>   "y":1.8},
> {
>   "val":"malli",
>   "count":4,
>   "y":1.78}]}}}
> but if i restrict the query to 
> q=consumer_number:raghu=0&
>  json.facet={
>biskatoo:{
>type : terms,
>field : consumer_number,
>limit : 20,
>   sort : {y:desc},
>   numBuckets : true,
>   facet:{
>y : "sum(amount)"
>}
>}
>  }
> i get :
>   "facets":{
> "count":4,
> "biskatoo":{
>   "numBuckets":1,
>   "buckets":[{
>   "val":"raghu",
>   "COUNT":4,
>   "y":2429708.24}]}}}
> One can see the count results are inconsistent ( and I found many occasions 
> of inconsistencies).
> I have tried the patch https://issues.apache.org/jira/browse/SOLR-7412 but 
> still the issue seems not resolved



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+120) - Build # 16878 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16878/
Java: 64bit/jdk-9-ea+120 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.TestDistributedSearch.test

Error Message:
Expected to find shardAddress in the up shard info

Stack Trace:
java.lang.AssertionError: Expected to find shardAddress in the up shard info
at 
__randomizedtesting.SeedInfo.seed([5E9C42EC8968D02F:D6C87D362794BDD7]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.TestDistributedSearch.comparePartialResponses(TestDistributedSearch.java:1172)
at 
org.apache.solr.TestDistributedSearch.queryPartialResults(TestDistributedSearch.java:1113)
at 
org.apache.solr.TestDistributedSearch.test(TestDistributedSearch.java:973)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsRepeatStatement.callStatement(BaseDistributedSearchTestCase.java:1011)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 

[jira] [Commented] (SOLR-9167) Unable to connect to solr via solrj jdbc driver

[Christian Schwarzinger (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15307468#comment-15307468
 ] 

Christian Schwarzinger commented on SOLR-9167:
--

Thanks for your reply.

Both aggregationModes work for me with curl, none with the jdbc driver. Same 
error log for both modes here.
Could it be a problem with the transport layer of the jdbc driver?
I tried to debug the driver, but due to asynchronous connect this is a bit 
challenging. I did not debug the server component yet. 
If you have any advice how to proceed, I will gladly contribute in fixing this 
issue. 

Tried to start the server on a ubuntu 16.04 and connect to it with same result. 
  


> Unable to connect to solr via solrj jdbc driver 
> 
>
> Key: SOLR-9167
> URL: https://issues.apache.org/jira/browse/SOLR-9167
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud, SolrJ
>Affects Versions: 6.0
> Environment: java.version=1.8.0_77
> java.vendor=Oracle Corporation
> os.name=Mac OS X
> os.arch=x86_64
> os.version=10.11.5
>Reporter: Christian Schwarzinger
>Priority: Minor
>
> Getting the following error, when trying to connect to solr via jdbc driver.
> {panel:title=client 
> error|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> (ClientCnxn.java:1102) - Session 0x0 for server 
> fe80:0:0:0:0:0:0:1%1/fe80:0:0:0:0:0:0:1%1:8983, unexpected error, closing 
> socket connection and attempting reconnect
> java.io.IOException: Packet len1213486160 is out of range!
>   at 
> org.apache.zookeeper.ClientCnxnSocket.readLength(ClientCnxnSocket.java:112) 
> ~[zookeeper-3.4.6.jar:3.4.6-1569965]
>   at 
> org.apache.zookeeper.ClientCnxnSocketNIO.doIO(ClientCnxnSocketNIO.java:79) 
> ~[zookeeper-3.4.6.jar:3.4.6-1569965]
>   at 
> org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:366)
>  ~[zookeeper-3.4.6.jar:3.4.6-1569965]
>   at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1081) 
> [zookeeper-3.4.6.jar:3.4.6-1569965]
> {panel}
> This is imho. caused by the following server error:
> {panel:title=server 
> error|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> Illegal character 0x0 in state=START for buffer 
> HeapByteBuffer@5cc6fe87[p=1,l=49,c=8192,r=48]={\x00<<<\x00\x00-\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00...\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00>>>charset=UTF-8\r\nCo...\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00}
> {panel}
> Using http interface for sql via curl works however:
> {code}
> bin/solr start -cloud
> bin/solr create -c test
> curl -X POST -H 'Content-Type: application/json' 
> 'http://localhost:8983/solr/test/update/json/docs' --data-binary '
> {
>   "id": "1",
>   "title": "Doc 1"
> }'
> curl 'http://localhost:8983/solr/test/update?commit=true'
> curl --data-urlencode 'stmt=SELECT count(*) FROM test' 
> http://localhost:8983/solr/test/sql?aggregationMode=facet
> {code}
> This is the code, that fails:
> {code}
> Connection con = 
> DriverManager.getConnection("jdbc:solr://localhost:8983?collection=test=map_reduce=2");
> {code}
> taken from: 
> https://cwiki.apache.org/confluence/display/solr/Parallel+SQL+Interface
> Same error also occurs in 6.1.0-68 developer snapshot.
> Background: I'm trying to write a solr sql connector for Jedox BI Suite, 
> which should allow for better integration of solr into BI processes. Any 
> advice / help appreciated.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+120) - Build # 16877 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16877/
Java: 32bit/jdk-9-ea+120 -client -XX:+UseConcMarkSweepGC

2 tests failed.
FAILED:  org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test

Error Message:
Expected 2 of 3 replicas to be active but only found 1; 
[core_node3:{"core":"c8n_1x3_lf_shard1_replica1","base_url":"http://127.0.0.1:43904/_xt/fr","node_name":"127.0.0.1:43904__xt%2Ffr","state":"active","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf)={   "replicationFactor":"3",   
"shards":{"shard1":{   "range":"8000-7fff",   "state":"active", 
  "replicas":{ "core_node1":{   
"core":"c8n_1x3_lf_shard1_replica3",   
"base_url":"http://127.0.0.1:45360/_xt/fr;,   
"node_name":"127.0.0.1:45360__xt%2Ffr",   "state":"down"}, 
"core_node2":{   "state":"down",   
"base_url":"http://127.0.0.1:43547/_xt/fr;,   
"core":"c8n_1x3_lf_shard1_replica2",   
"node_name":"127.0.0.1:43547__xt%2Ffr"}, "core_node3":{   
"core":"c8n_1x3_lf_shard1_replica1",   
"base_url":"http://127.0.0.1:43904/_xt/fr;,   
"node_name":"127.0.0.1:43904__xt%2Ffr",   "state":"active",   
"leader":"true",   "router":{"name":"compositeId"},   
"maxShardsPerNode":"1",   "autoAddReplicas":"false"}

Stack Trace:
java.lang.AssertionError: Expected 2 of 3 replicas to be active but only found 
1; 
[core_node3:{"core":"c8n_1x3_lf_shard1_replica1","base_url":"http://127.0.0.1:43904/_xt/fr","node_name":"127.0.0.1:43904__xt%2Ffr","state":"active","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf)={
  "replicationFactor":"3",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node1":{
  "core":"c8n_1x3_lf_shard1_replica3",
  "base_url":"http://127.0.0.1:45360/_xt/fr;,
  "node_name":"127.0.0.1:45360__xt%2Ffr",
  "state":"down"},
"core_node2":{
  "state":"down",
  "base_url":"http://127.0.0.1:43547/_xt/fr;,
  "core":"c8n_1x3_lf_shard1_replica2",
  "node_name":"127.0.0.1:43547__xt%2Ffr"},
"core_node3":{
  "core":"c8n_1x3_lf_shard1_replica1",
  "base_url":"http://127.0.0.1:43904/_xt/fr;,
  "node_name":"127.0.0.1:43904__xt%2Ffr",
  "state":"active",
  "leader":"true",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false"}
at 
__randomizedtesting.SeedInfo.seed([C18188D084621EDD:49D5B70A2A9E7325]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:170)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:57)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 

[jira] [Commented] (LUCENE-7304) Doc values based block join implementation

[Martijn van Groningen (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15307395#comment-15307395
 ] 

Martijn van Groningen commented on LUCENE-7304:
---

Having different block join implementations with different trade offs around is 
good. If EliasFanoDocIdSet can extend from `BitSet` then I think it would be a 
nice addition to the jojn module, so that `ToParentBlockJoinQuery` and friends 
can use it as `parentsFilter`. This way the block join that exists today can be 
improved in certain scenarios (I think that largely depends on how dense this 
parentsFilter is. Typically it tends to be on the dense side).

> Doc values based block join implementation
> --
>
> Key: LUCENE-7304
> URL: https://issues.apache.org/jira/browse/LUCENE-7304
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Martijn van Groningen
>Priority: Minor
> Attachments: LUCENE-5092-20140313.patch, LUCENE_7304.patch
>
>
> At query time the block join relies on a bitset for finding the previous 
> parent doc during advancing the doc id iterator. On large indices these 
> bitsets can consume large amounts of jvm heap space.  Also typically due the 
> nature how these bitsets are set, the 'FixedBitSet' implementation is used.
> The idea I had was to replace the bitset usage by a numeric doc values field 
> that stores offsets. Each child doc stores how many docids it is from its 
> parent doc and each parent stores how many docids it is apart from its first 
> child. At query time this information can be used to perform the block join.
> I think another benefit of this approach is that external tools can now 
> easily determine if a doc is part of a block of documents and perhaps this 
> also helps index time sorting?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9174) After Solr 5.5, mm parameter doesn't work properly

[JIRA]

[ 
https://issues.apache.org/jira/browse/SOLR-9174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15307383#comment-15307383
 ] 

Jan Høydahl commented on SOLR-9174:
---

As a workaround you could try to set q.op=OR

> After Solr 5.5, mm parameter doesn't work properly
> --
>
> Key: SOLR-9174
> URL: https://issues.apache.org/jira/browse/SOLR-9174
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers, search
>Affects Versions: 5.5, 6.0, 6.0.1
>Reporter: Issei Nishigata
>
> “mm" parameter does not work properly, when I set "q.op=AND” after Solr 5.5.
> In Solr 5.4, mm parameter works expectedly with the following setting.
> [schema]
> {code:xml}
> 
>   
>  maxGramSize="2"/>
>   
> 
> {code}
> [request]
> {quote}
> http://localhost:8983/solr/collection1/select?defType=edismax=AND=2=solar
> {quote}
> After Solr 5.5, the result will not be the same as Solr 5.4.
> [Solr 5.4]
> {code:xml}
> 
> ...
>   
> 2
> solar
> edismax
> AND
>   
> ...
> 
>   
> 0
> 
>   solr
> 
>   
> 
> 
>   solar
>   solar
>   
>   (+DisjunctionMaxQuerytext:so text:ol text:la text:ar)~2/no_coord
>   
>   +(((text:so text:ol text:la 
> text:ar)~2))
>   ...
> 
> {code}
> [Solr 6.0.1]
> {code:xml}
> 
> ...
>   
> 2
> solar
> edismax
> AND
>   
> ...
> 
>   
> solar
> solar
> 
> (+DisjunctionMaxQuery(((+text:so +text:ol +text:la +text:ar/no_coord
> 
> +((+text:so +text:ol +text:la 
> +text:ar))
> ...
> {code}
> As shown above, parsedquery also differs from Solr 5.4 and Solr 6.0.1(after 
> Solr 5.5).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_92) - Build # 16876 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16876/
Java: 32bit/jdk1.8.0_92 -client -XX:+UseConcMarkSweepGC

2 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.schema.TestManagedSchemaAPI

Error Message:
ObjectTracker found 8 object(s) that were not released!!! 
[MockDirectoryWrapper, TransactionLog, MockDirectoryWrapper, 
MDCAwareThreadPoolExecutor, MockDirectoryWrapper, MDCAwareThreadPoolExecutor, 
TransactionLog, MockDirectoryWrapper]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 8 object(s) that were not 
released!!! [MockDirectoryWrapper, TransactionLog, MockDirectoryWrapper, 
MDCAwareThreadPoolExecutor, MockDirectoryWrapper, MDCAwareThreadPoolExecutor, 
TransactionLog, MockDirectoryWrapper]
at __randomizedtesting.SeedInfo.seed([659DD564AF7C260B]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:255)
at sun.reflect.GeneratedMethodAccessor36.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  org.apache.solr.util.SolrPluginUtilsTest.testInvokeSetters

Error Message:
argument type mismatch

Stack Trace:
java.lang.IllegalArgumentException: argument type mismatch
at 
__randomizedtesting.SeedInfo.seed([659DD564AF7C260B:C827E645A4A44A0]:0)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.apache.solr.util.SolrPluginUtils.invokeSetters(SolrPluginUtils.java:1071)
at 
org.apache.solr.util.SolrPluginUtilsTest.implTestInvokeSetters(SolrPluginUtilsTest.java:482)
at 
org.apache.solr.util.SolrPluginUtilsTest.testInvokeSetters(SolrPluginUtilsTest.java:474)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 

[JENKINS] Lucene-Solr-Tests-master - Build # 1180 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1180/

1 tests failed.
FAILED:  org.apache.solr.util.SolrPluginUtilsTest.testInvokeSetters

Error Message:
argument type mismatch

Stack Trace:
java.lang.IllegalArgumentException: argument type mismatch
at 
__randomizedtesting.SeedInfo.seed([473A3595586E00E4:2E259E95AD58624F]:0)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.apache.solr.util.SolrPluginUtils.invokeSetters(SolrPluginUtils.java:1071)
at 
org.apache.solr.util.SolrPluginUtilsTest.implTestInvokeSetters(SolrPluginUtilsTest.java:482)
at 
org.apache.solr.util.SolrPluginUtilsTest.testInvokeSetters(SolrPluginUtilsTest.java:474)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)