[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_121) - Build # 19533 - Unstable!

2017-05-01 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19533/
Java: 64bit/jdk1.8.0_121 -XX:-UseCompressedOops -XX:+UseParallelGC

36 tests failed.
FAILED:  org.apache.solr.rest.schema.TestBulkSchemaAPI.testSimilarityParser

Error Message:
wrong sim for field=similarityTestField expected: but was:

Stack Trace:
java.lang.AssertionError: wrong sim for field=similarityTestField 
expected: but 
was:
at 
__randomizedtesting.SeedInfo.seed([B8BC3101966E27A6:5F404CE89A596B76]: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.apache.solr.rest.schema.TestBulkSchemaAPI.assertFieldSimilarity(TestBulkSchemaAPI.java:956)
at 
org.apache.solr.rest.schema.TestBulkSchemaAPI.testSimilarityParser(TestBulkSchemaAPI.java:860)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:745)


FAILED:  

[JENKINS] Lucene-Solr-6.x-Solaris (64bit/jdk1.8.0) - Build # 809 - Unstable!

2017-05-01 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/809/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

42 tests failed.
FAILED:  org.apache.solr.rest.schema.TestBulkSchemaAPI.testSimilarityParser

Error Message:
wrong sim for field=similarityTestField expected: but was:

Stack Trace:
java.lang.AssertionError: wrong sim for field=similarityTestField 
expected: but 
was:
at 
__randomizedtesting.SeedInfo.seed([74268551D8C375B8:93DAF8B8D4F43968]: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.apache.solr.rest.schema.TestBulkSchemaAPI.assertFieldSimilarity(TestBulkSchemaAPI.java:956)
at 
org.apache.solr.rest.schema.TestBulkSchemaAPI.testSimilarityParser(TestBulkSchemaAPI.java:860)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:745)


FAILED:  

[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 1278 - Still Unstable!

2017-05-01 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1278/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

36 tests failed.
FAILED:  org.apache.solr.rest.schema.TestBulkSchemaAPI.testMultipleCommands

Error Message:
wrong sim for field=a4 expected: but was:

Stack Trace:
java.lang.AssertionError: wrong sim for field=a4 expected: but was:
at 
__randomizedtesting.SeedInfo.seed([88BA8A05154C9E54:F67ADE30AA184C57]: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.apache.solr.rest.schema.TestBulkSchemaAPI.assertFieldSimilarity(TestBulkSchemaAPI.java:956)
at 
org.apache.solr.rest.schema.TestBulkSchemaAPI.testMultipleCommands(TestBulkSchemaAPI.java:563)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:745)


FAILED:  org.apache.solr.rest.schema.TestBulkSchemaAPI.testSimilarityParser


[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_121) - Build # 3417 - Unstable!

2017-05-01 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3417/
Java: 32bit/jdk1.8.0_121 -client -XX:+UseSerialGC

42 tests failed.
FAILED:  org.apache.solr.rest.schema.TestBulkSchemaAPI.testMultipleCommands

Error Message:
wrong sim for field=a4 expected: but was:

Stack Trace:
java.lang.AssertionError: wrong sim for field=a4 expected: but was:
at 
__randomizedtesting.SeedInfo.seed([C17123362ED6E875:BFB1770391823A76]: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.apache.solr.rest.schema.TestBulkSchemaAPI.assertFieldSimilarity(TestBulkSchemaAPI.java:956)
at 
org.apache.solr.rest.schema.TestBulkSchemaAPI.testMultipleCommands(TestBulkSchemaAPI.java:563)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:745)


FAILED:  org.apache.solr.rest.schema.TestBulkSchemaAPI.testSimilarityParser

Error Message:
wrong sim 

[jira] [Commented] (SOLR-10588) SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection failure caused by concurrent core reload.

2017-05-01 Thread Erick Erickson (JIRA)

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

Erick Erickson commented on SOLR-10588:
---

OK, 2,000 runs and 
> no NPEs
> no test failures

I was usually able to get 1-2% failure rate before this patch, so LGTM.

And note that I did not run any tests except SolrCloudExampleTest.


> SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection failure caused 
> by concurrent core reload. 
> 
>
> Key: SOLR-10588
> URL: https://issues.apache.org/jira/browse/SOLR-10588
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
> Attachments: consoleFull.html.zip, SOLR-10588.patch
>
>
> https://builds.apache.org/job/Lucene-Solr-Tests-master/1788/testReport/junit/junit.framework/TestSuite/org_apache_solr_cloud_SolrCloudExampleTest/
> this NPE, even it might be quite reasonable itself, breaks core reload, and 
> applying config param. I'm -not- sure, -how- it -'s related- causes to these 
> constant failures.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[JENKINS] Lucene-Solr-6.x-MacOSX (64bit/jdk1.8.0) - Build # 844 - Still Unstable!

2017-05-01 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/844/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.solr.schema.TestUseDocValuesAsStored.testMultipleSearchResults

Error Message:
mismatch: 'myid1'!='myid' @ response/docs/[0]/id

Stack Trace:
java.lang.RuntimeException: mismatch: 'myid1'!='myid' @ response/docs/[0]/id
at 
__randomizedtesting.SeedInfo.seed([53CD0FA9AF4B9362:61E7083757B5B7BB]:0)
at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:983)
at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:930)
at 
org.apache.solr.schema.TestUseDocValuesAsStored.testMultipleSearchResults(TestUseDocValuesAsStored.java:243)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 12130 lines...]
   [junit4] Suite: org.apache.solr.schema.TestUseDocValuesAsStored
   [junit4]   2> Creating dataDir: 

[jira] [Commented] (SOLR-1485) Payload scoring support

2017-05-01 Thread Erik Hatcher (JIRA)

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

Erik Hatcher commented on SOLR-1485:


Leaving this ticket open until the documentation is done, but otherwise, whew, 
DONE!

> Payload scoring support
> ---
>
> Key: SOLR-1485
> URL: https://issues.apache.org/jira/browse/SOLR-1485
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: 6.6, master (7.0)
>
> Attachments: PayloadTermQueryPlugin.java, payload_value_source.png, 
> SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, 
> SOLR-1485.patch
>
>
> Solr has no support for Lucene's PayloadScoreQuery, yet it has support for 
> indexing payloads (via DelimitedPayloadTokenFilter or 
> NumericPayloadTokenFilter). 
> This issue adds value source and query parser support for leveraging payloads 
> created by those token filters.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (SOLR-1485) Payload scoring support

2017-05-01 Thread Erik Hatcher (JIRA)

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

Erik Hatcher commented on SOLR-1485:


I'm not seeing the git message here, but I've committed to branch_6x now too, 
including a minor tweak to the similarity wrapper due to API change on master.  
https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a=shortlog;h=refs/heads/branch_6x

> Payload scoring support
> ---
>
> Key: SOLR-1485
> URL: https://issues.apache.org/jira/browse/SOLR-1485
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: 6.6, master (7.0)
>
> Attachments: PayloadTermQueryPlugin.java, payload_value_source.png, 
> SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, 
> SOLR-1485.patch
>
>
> Solr has no support for Lucene's PayloadScoreQuery, yet it has support for 
> indexing payloads (via DelimitedPayloadTokenFilter or 
> NumericPayloadTokenFilter). 
> This issue adds value source and query parser support for leveraging payloads 
> created by those token filters.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (SOLR-10591) Backup and Restore Solr Index based on Time

2017-05-01 Thread Avinash Gaddam (JIRA)

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

Avinash Gaddam commented on SOLR-10591:
---

@Shawn,
When we restored the Index it was identical to backup.It did not merge.
That was my Question is it possible to Merge Runtime based on the document 
Indexed time?

@Eric -
Need to understand the functionality. Hence raised the question here. 
If it is not possible, is it doable? Or considered?

Regards,
Avinash

> Backup and Restore Solr Index based on Time
> ---
>
> Key: SOLR-10591
> URL: https://issues.apache.org/jira/browse/SOLR-10591
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Backup/Restore
>Affects Versions: 5.0
>Reporter: Avinash Gaddam
>Priority: Critical
>
> Hi,
> I am fairly new to Solr world, had an requirement regarding Backup/Solr data -
>  Requirement -
> Currently we are Indexing Metadatasin Solr which has been for around year. 
> We want to take a backup of data on Month to Month basis and restore the same 
> when required. i.e. say - take back up of March data alone and restore the 
> same back in the month of May.
> Tried till now –
> I was able to take back up of Complete Index and restore the same back as new 
> Index.
> But unable to merge it with Current latest Index. Is this doable?
> Can  I take Partial data Backup and Restore the same to the current Index.?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
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 # 1794 - Unstable

2017-05-01 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1794/

1 tests failed.
FAILED:  
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI

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

Stack Trace:
java.lang.AssertionError: expected:<3> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([2F687C8087AF5E62:671D0834819C71F7]: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.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:530)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 12064 lines...]
   [junit4] Suite: org.apache.solr.cloud.CollectionsAPIDistributedZkTest
   [junit4]   2> Creating dataDir: 

[jira] [Commented] (SOLR-1485) Payload scoring support

2017-05-01 Thread ASF subversion and git services (JIRA)

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

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

Commit 6c565c001bb48af0c37a4d4909ba2f98d51e7fe6 in lucene-solr's branch 
refs/heads/master from [~ehatcher]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6c565c0 ]

SOLR-1485: Add payload support


> Payload scoring support
> ---
>
> Key: SOLR-1485
> URL: https://issues.apache.org/jira/browse/SOLR-1485
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: 6.6, master (7.0)
>
> Attachments: PayloadTermQueryPlugin.java, payload_value_source.png, 
> SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, 
> SOLR-1485.patch
>
>
> Solr has no support for Lucene's PayloadScoreQuery, yet it has support for 
> indexing payloads (via DelimitedPayloadTokenFilter or 
> NumericPayloadTokenFilter). 
> This issue adds value source and query parser support for leveraging payloads 
> created by those token filters.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Assigned] (SOLR-10285) Reduce state messages when there are leader only shards

2017-05-01 Thread Cao Manh Dat (JIRA)

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

Cao Manh Dat reassigned SOLR-10285:
---

Assignee: Cao Manh Dat

> Reduce state messages when there are leader only shards
> ---
>
> Key: SOLR-10285
> URL: https://issues.apache.org/jira/browse/SOLR-10285
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Cao Manh Dat
>
> For shards which have 1 replica ( leader ) we know it doesn't need to recover 
> from anyone. We should short-circuit the recovery process in this case. 
> The motivation for this being that we will generate less state events and be 
> able to mark these replicas as active again without it needing to go into 
> 'recovering' state. 
> We already short circuit when you set {{-Dsolrcloud.skip.autorecovery=true}} 
> but that sys prop was meant for tests only. Extending this to make sure the 
> code short-circuits when the core knows its the only replica in the shard is 
> the motivation of the Jira.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (SOLR-10105) JDBCStream should be able to load driver from runtime lib

2017-05-01 Thread Noble Paul (JIRA)

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

Noble Paul commented on SOLR-10105:
---

It's not a good idea to move any part of streaming expression to core. It 
should work anywhere outside solr

> JDBCStream should be able to load driver from runtime lib
> -
>
> Key: SOLR-10105
> URL: https://issues.apache.org/jira/browse/SOLR-10105
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Parallel SQL
>Reporter: Noble Paul
>Assignee: Kevin Risden
>Priority: Minor
> Attachments: SOLR-10105.patch
>
>
> Currently the JDBCStream uses Class.forName() to load the driver class. This 
> should be improved to try to use the classloader from runtimeLib and the blob 
> store API like SOLR-10087. It may be possible to do something like 
> Class.forName(driverClassName, true, core.getMemClassLoader()) just need to 
> figure out how to get a reference to the core.
> The relevant code is here:
> https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/JDBCStream.java#L180



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Assigned] (SOLR-10547) implement min/max facet functions for string fields

2017-05-01 Thread Yonik Seeley (JIRA)

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

Yonik Seeley reassigned SOLR-10547:
---

Assignee: Yonik Seeley

> implement min/max facet functions for string fields
> ---
>
> Key: SOLR-10547
> URL: https://issues.apache.org/jira/browse/SOLR-10547
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>
> The min and max functions currently only work on numeric fields.  This JIRA 
> is about adding support for String fields, with min/max defined as index 
> order.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (SOLR-10522) Duplicate keys in "collations" object with JSON response format

2017-05-01 Thread Zoran Avtarovski (JIRA)

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

Zoran Avtarovski commented on SOLR-10522:
-

I thought about this when I ran into the issue and one solution which might 
work and still accomodate legacy use is to name the first collation key 
"collation" and then append a numeric value to each subsequent key. eg
"collations":[
"collation",{...},
"collation1",{...},
"collation2",{...},
"collation3",{...},
"collation4",{...}
]

This way, legacy applications looking for the "collation" key would be fine but 
the json format would also be valid and enable parsers to parse through all the 
collations.

Just a suggestion. 

> Duplicate keys in "collations" object with JSON response format
> ---
>
> Key: SOLR-10522
> URL: https://issues.apache.org/jira/browse/SOLR-10522
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spellchecker
>Affects Versions: 6.5
>Reporter: Nikita Pchelintsev
>Assignee: James Dyer
>Priority: Minor
>
> After upgrading Solr 6.3 -> 6.5 I've noticed a change in how json response 
> writer outputs "collations" response key when spellchecking is enabled 
> (wt=json=arrarr)
> Solr 6.3:
> "collations":
> [
>   ["collation",{
>   "collationQuery":"the",
>   "hits":48,
>   "maxScore":"30.282",
>   "misspellingsAndCorrections":
>   [
> ["thea","the"]]}],
>   ["collation",{
>   "collationQuery":"tea",
>   "hits":3,
>   "maxScore":"2.936",
>   "misspellingsAndCorrections":
>   [
> ["thea","tea"]]}],
>   ...
> Solr 6.5:
> "collations":{
>   "collation":{
> "collationQuery":"the",
> "hits":43,
> "misspellingsAndCorrections":
> [
>   ["thea","the"]]},
>   "collation":{
> "collationQuery":"tea",
> "hits":3,
> "misspellingsAndCorrections":
> [
>   ["thea","tea"]]},
> ...
> Solr 6.5 outputs object instead of an array, and it has duplicate keys which 
> is not valid for JSON format.
> Any help is appreciated.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Resolved] (SOLR-10593) Change Ref Guide site name at comments.apache.org for comment integration

2017-05-01 Thread Cassandra Targett (JIRA)

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

Cassandra Targett resolved SOLR-10593.
--
Resolution: Fixed

> Change Ref Guide site name at comments.apache.org for comment integration
> -
>
> Key: SOLR-10593
> URL: https://issues.apache.org/jira/browse/SOLR-10593
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>Priority: Minor
>
> The new HTML site incorporates comments from comments.apache.org, and a long 
> time ago we had a site created named "solrcwiki". Since we're moving off 
> Confluence (cwiki) that name doesn't make a ton of sense and will make less 
> sense in the future, so now is a great time to change it/delete it/recreate 
> it.
> INFRA-14063 asked for this change to be made, and I was granted access to 
> create a new site. This issue is to take care of that and update the 
> Javascript in the HTML page templates accordingly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (SOLR-7041) Remove defaultSearchField and solrQueryParser from schema

2017-05-01 Thread Hoss Man (JIRA)

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

Hoss Man commented on SOLR-7041:


they've been logging a {{WARN}} for so long I don't have strong opinions 
against removing them in 7.0 ... i'm not sure that i ever had strong opinions 
about removing them, i just raised the question/concern that there didn't seem 
to be a lot of benefit in doing so since that code didn't seem to particularly 
be standing in the way of any new code/features, but (at the time anyway) 
removing them was confusing/problematic to existing users.

> Remove defaultSearchField and solrQueryParser from schema
> -
>
> Key: SOLR-7041
> URL: https://issues.apache.org/jira/browse/SOLR-7041
> Project: Solr
>  Issue Type: Improvement
>  Components: Schema and Analysis
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 6.0
>
> Attachments: SOLR-7041-defaultOperator.patch, SOLR-7041.patch
>
>
> The two tags {{}} and {{solrQueryParser}} were deprecated 
> in Solr3.6 (SOLR-2724). Time to nuke them from code and {{schema.xml}} in 5.0?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (SOLR-10105) JDBCStream should be able to load driver from runtime lib

2017-05-01 Thread James Dyer (JIRA)

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

James Dyer commented on SOLR-10105:
---

Would it be acceptable to just check for a "solr-core" key on the context, then 
if it exists, access the appropriate method via reflextion?  This would allow 
us to keep this class outside of core but have access to the shared lib dir, 
without having to have SolrCore implement a new interface just for this 
purpose.  

But also, I am not so sure what the design goal here is, how important it is to 
keep streams out of core.  It seems odd we'd have all of this as part of SolrJ. 
 Maybe just moving JDBCStream to core is the right answer?

> JDBCStream should be able to load driver from runtime lib
> -
>
> Key: SOLR-10105
> URL: https://issues.apache.org/jira/browse/SOLR-10105
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Parallel SQL
>Reporter: Noble Paul
>Assignee: Kevin Risden
>Priority: Minor
> Attachments: SOLR-10105.patch
>
>
> Currently the JDBCStream uses Class.forName() to load the driver class. This 
> should be improved to try to use the classloader from runtimeLib and the blob 
> store API like SOLR-10087. It may be possible to do something like 
> Class.forName(driverClassName, true, core.getMemClassLoader()) just need to 
> figure out how to get a reference to the core.
> The relevant code is here:
> https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/JDBCStream.java#L180



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (SOLR-10593) Change Ref Guide site name at comments.apache.org for comment integration

2017-05-01 Thread Cassandra Targett (JIRA)

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

Cassandra Targett commented on SOLR-10593:
--

Figured out finally what was wrong with the styling - I spent a day on this 
before, but couldn't get it working right, but now I think I've got it. 

The comments.a.o docs say to put the link to a custom stylesheet in the JS 
snippet you add to each page to get the comments to appear, but it wasn't 
really happening. On further analysis, it seems all the elements of the 
comments section are loaded _before_ the stylesheet is loaded so the stylesheet 
is never applied. I added a link to the stylesheet to the head.html that's used 
in the page, and now the stylesheet is applied.

> Change Ref Guide site name at comments.apache.org for comment integration
> -
>
> Key: SOLR-10593
> URL: https://issues.apache.org/jira/browse/SOLR-10593
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>Priority: Minor
>
> The new HTML site incorporates comments from comments.apache.org, and a long 
> time ago we had a site created named "solrcwiki". Since we're moving off 
> Confluence (cwiki) that name doesn't make a ton of sense and will make less 
> sense in the future, so now is a great time to change it/delete it/recreate 
> it.
> INFRA-14063 asked for this change to be made, and I was granted access to 
> create a new site. This issue is to take care of that and update the 
> Javascript in the HTML page templates accordingly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (SOLR-10338) Configure SecureRandom non blocking for tests.

2017-05-01 Thread Mark Miller (JIRA)

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

Mark Miller commented on SOLR-10338:


I also was a little skeptical of the timed checking but was focusing on whether 
the patch worked alright first.

Have another iteration [~mihaly.toth]?

> Configure SecureRandom non blocking for tests.
> --
>
> Key: SOLR-10338
> URL: https://issues.apache.org/jira/browse/SOLR-10338
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Mihaly Toth
>Assignee: Mark Miller
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-10338.patch, SOLR-10338.patch, SOLR-10338.patch, 
> SOLR-10338.patch
>
>
> It would be best if SecureRandom could be made non blocking. In that case we 
> could get rid of random entropy exhaustion issue related to all usages of 
> SecureRandom.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (SOLR-7041) Remove defaultSearchField and solrQueryParser from schema

2017-05-01 Thread JIRA

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

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

Skimmed through SOLR-2724. It's a long time since these discussions and also a 
long time since the 3.6 deprecation of these schema features.

What is the sentiment now, in particular from [~hossman] and 
[~yo...@apache.org]? The code handling {{defaultOperator}} or 
{{defaultSearchField}} in schema will go away in 7.0, and we'll fail-fast if we 
encounter these from 6.6 (silently ignoring would be worse than failing).

Personally I haven't used these for years. But the main reason I started 
working on this is that it feels good to actually remove deprecated stuff and 
simplify the code, config and complexity of the product. But I don't have a 
problem either with just leaving it in there forever, as seemed to be what some 
of you (strongly) wanted way back then. If I get serious, well-founded 
push-back now, I'll unassign myself and leave the fate of this change in the 
hands of [~dsmiley] :-)

> Remove defaultSearchField and solrQueryParser from schema
> -
>
> Key: SOLR-7041
> URL: https://issues.apache.org/jira/browse/SOLR-7041
> Project: Solr
>  Issue Type: Improvement
>  Components: Schema and Analysis
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 6.0
>
> Attachments: SOLR-7041-defaultOperator.patch, SOLR-7041.patch
>
>
> The two tags {{}} and {{solrQueryParser}} were deprecated 
> in Solr3.6 (SOLR-2724). Time to nuke them from code and {{schema.xml}} in 5.0?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
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+164) - Build # 19530 - Unstable!

2017-05-01 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19530/
Java: 32bit/jdk-9-ea+164 -server -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.solr.handler.admin.SegmentsInfoRequestHandlerTest.testSegmentInfosVersion

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([EEB7FF118AD74472:16696AF9F2BB9521]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:896)
at 
org.apache.solr.handler.admin.SegmentsInfoRequestHandlerTest.testSegmentInfosVersion(SegmentsInfoRequestHandlerTest.java:70)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:563)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
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:368)
at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=2=count(//lst[@name='segments']/lst/str[@name='version'][.='7.0.0'])
xml response was: 


[jira] [Resolved] (SOLR-10591) Backup and Restore Solr Index based on Time

2017-05-01 Thread Erick Erickson (JIRA)

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

Erick Erickson resolved SOLR-10591.
---
Resolution: Invalid

Please raise issues like this on the user's list. If it's determined that it is 
a code issue or would be a good (and possible) improvement, _then_ raise a JIRA.

> Backup and Restore Solr Index based on Time
> ---
>
> Key: SOLR-10591
> URL: https://issues.apache.org/jira/browse/SOLR-10591
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Backup/Restore
>Affects Versions: 5.0
>Reporter: Avinash Gaddam
>Priority: Critical
>
> Hi,
> I am fairly new to Solr world, had an requirement regarding Backup/Solr data -
>  Requirement -
> Currently we are Indexing Metadatasin Solr which has been for around year. 
> We want to take a backup of data on Month to Month basis and restore the same 
> when required. i.e. say - take back up of March data alone and restore the 
> same back in the month of May.
> Tried till now –
> I was able to take back up of Complete Index and restore the same back as new 
> Index.
> But unable to merge it with Current latest Index. Is this doable?
> Can  I take Partial data Backup and Restore the same to the current Index.?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (SOLR-10591) Backup and Restore Solr Index based on Time

2017-05-01 Thread Shawn Heisey (JIRA)

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

Shawn Heisey commented on SOLR-10591:
-

I have not actually used the backup feature, but I would be VERY surprised if a 
"merge" was possible.  Pretty sure that restoring an index will make the index 
identical to the backup, because I think it's a file level operation.  Merging 
the indexes would require *document* level operations.

> Backup and Restore Solr Index based on Time
> ---
>
> Key: SOLR-10591
> URL: https://issues.apache.org/jira/browse/SOLR-10591
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Backup/Restore
>Affects Versions: 5.0
>Reporter: Avinash Gaddam
>Priority: Critical
>
> Hi,
> I am fairly new to Solr world, had an requirement regarding Backup/Solr data -
>  Requirement -
> Currently we are Indexing Metadatasin Solr which has been for around year. 
> We want to take a backup of data on Month to Month basis and restore the same 
> when required. i.e. say - take back up of March data alone and restore the 
> same back in the month of May.
> Tried till now –
> I was able to take back up of Complete Index and restore the same back as new 
> Index.
> But unable to merge it with Current latest Index. Is this doable?
> Can  I take Partial data Backup and Restore the same to the current Index.?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (SOLR-9386) Upgrade Zookeeper to 3.4.10

2017-05-01 Thread Shawn Heisey (JIRA)

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

Shawn Heisey commented on SOLR-9386:


bq.  Perhaps if you think we should no longer enable that, it should be dealt 
with in another issue?

Sounds reasonable.  Thanks for your effort here.


> Upgrade Zookeeper to 3.4.10
> ---
>
> Key: SOLR-9386
> URL: https://issues.apache.org/jira/browse/SOLR-9386
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-9386-fix-clientPort-parsing.patch, SOLR-9386.patch, 
> SOLR-9386.patch, SOLR-9386.patch, zookeeper-3.4.8-upgrade-tests-pass.patch, 
> zookeeper-3.4.9-upgrade-tests-fail.patch
>
>
> Zookeeper 3.4.10 release should be happening fairly soon, and the ZK issue 
> blocking incorporation into Solr (ZOOKEEPER-2383) has a 3.4.10-targetted 
> patch that fixes the test failures problem noted on SOLR-8724.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (SOLR-10430) Add ls command to ZkCLI for listing only sub-directories

2017-05-01 Thread Mark Miller (JIRA)

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

Mark Miller commented on SOLR-10430:


Thanks for the patch [~szantaikis], looks like a couple precommit violations:

{noformat}
[forbidden-apis] Scanning classes for violations...
[forbidden-apis] Forbidden method invocation: 
java.io.PrintStream#(java.io.OutputStream) [Uses default charset]
[forbidden-apis]   in org.apache.solr.cloud.ZkCLITest (ZkCLITest.java:198)
[forbidden-apis] Forbidden method invocation: 
java.io.ByteArrayOutputStream#toString() [Uses default charset]
[forbidden-apis]   in org.apache.solr.cloud.ZkCLITest (ZkCLITest.java:203)
[forbidden-apis] Forbidden method invocation: 
java.io.PrintStream#(java.io.OutputStream) [Uses default charset]
[forbidden-apis]   in org.apache.solr.cloud.ZkCLITest (ZkCLITest.java:215)
[forbidden-apis] Forbidden method invocation: 
java.io.ByteArrayOutputStream#toString() [Uses default charset]
[forbidden-apis]   in org.apache.solr.cloud.ZkCLITest (ZkCLITest.java:220)
[forbidden-apis] Scanned 3641 (and 2473 related) class file(s) for forbidden 
API invocations (in 3.22s), 4 error(s).
{noformat}

We forbid using methods that use the default charset - generally you want to 
use .ROOT or .ENGLISH.

> Add ls command to ZkCLI for listing only sub-directories
> 
>
> Key: SOLR-10430
> URL: https://issues.apache.org/jira/browse/SOLR-10430
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Reporter: Peter Szantai-Kis
>Assignee: Mark Miller
>Priority: Minor
> Attachments: SOLR-10430.patch, SOLR-10430.patch, SOLR-10430.patch
>
>
> Current list command prints out the whole directory/file tree, which can be 
> too verbose for some situations, especially when the cluster gets bigger over 
> time. 
> Add a "ls" command that would support listing only part of the file tree 
> based on the input path given



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (SOLR-10593) Change Ref Guide site name at comments.apache.org for comment integration

2017-05-01 Thread Cassandra Targett (JIRA)

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

Cassandra Targett commented on SOLR-10593:
--

I've got the new site created in the Comments dashboard: 
https://comments.apache.org/panel.lua?view=dashboard=solr-refguide=741d0acac05816701215f891d97c8b451fe320b5,
 and have committed to the jira/solr-10290 branch the required change for the 
pages to use the new site.

In the process of this, I realized that I neglected to finish some work I'd 
started to fix the styling of the comments - it's currently horrific, so I'll 
use this issue to keep working on that a bit more.

> Change Ref Guide site name at comments.apache.org for comment integration
> -
>
> Key: SOLR-10593
> URL: https://issues.apache.org/jira/browse/SOLR-10593
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>Priority: Minor
>
> The new HTML site incorporates comments from comments.apache.org, and a long 
> time ago we had a site created named "solrcwiki". Since we're moving off 
> Confluence (cwiki) that name doesn't make a ton of sense and will make less 
> sense in the future, so now is a great time to change it/delete it/recreate 
> it.
> INFRA-14063 asked for this change to be made, and I was granted access to 
> create a new site. This issue is to take care of that and update the 
> Javascript in the HTML page templates accordingly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (SOLR-9386) Upgrade Zookeeper to 3.4.10

2017-05-01 Thread Steve Rowe (JIRA)

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

Steve Rowe commented on SOLR-9386:
--

The machinery that we're talking about makes supplying the {{myid}} file 
unnecessary in the embedded ZK quorum case.  Perhaps if you think we should no 
longer enable that, it should be dealt with in another issue?  Seems orthogonal 
to me to upgrading ZK.

> Upgrade Zookeeper to 3.4.10
> ---
>
> Key: SOLR-9386
> URL: https://issues.apache.org/jira/browse/SOLR-9386
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-9386-fix-clientPort-parsing.patch, SOLR-9386.patch, 
> SOLR-9386.patch, SOLR-9386.patch, zookeeper-3.4.8-upgrade-tests-pass.patch, 
> zookeeper-3.4.9-upgrade-tests-fail.patch
>
>
> Zookeeper 3.4.10 release should be happening fairly soon, and the ZK issue 
> blocking incorporation into Solr (ZOOKEEPER-2383) has a 3.4.10-targetted 
> patch that fixes the test failures problem noted on SOLR-8724.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (SOLR-9386) Upgrade Zookeeper to 3.4.10

2017-05-01 Thread Shawn Heisey (JIRA)

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

Shawn Heisey commented on SOLR-9386:


bq. I haven't tested setting up a quorum exclusively with embedded ZK

I am pretty sure that this is possible, by configuring the zoo_data and zoo.cfg 
just like you would for an external ensemble, including the myid file.


> Upgrade Zookeeper to 3.4.10
> ---
>
> Key: SOLR-9386
> URL: https://issues.apache.org/jira/browse/SOLR-9386
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-9386-fix-clientPort-parsing.patch, SOLR-9386.patch, 
> SOLR-9386.patch, SOLR-9386.patch, zookeeper-3.4.8-upgrade-tests-pass.patch, 
> zookeeper-3.4.9-upgrade-tests-fail.patch
>
>
> Zookeeper 3.4.10 release should be happening fairly soon, and the ZK issue 
> blocking incorporation into Solr (ZOOKEEPER-2383) has a 3.4.10-targetted 
> patch that fixes the test failures problem noted on SOLR-8724.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (SOLR-9386) Upgrade Zookeeper to 3.4.10

2017-05-01 Thread Steve Rowe (JIRA)

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

Steve Rowe commented on SOLR-9386:
--

bq. Steve Rowe, in newer ZK versions, standalone servers no longer require a 
myid file. We shouldn't need to handle that any more. I can't locate the 
ZOOKEEPER issue where that was changed, so I do not know what version made our 
standalone config work, but I'm pretty sure that 3.4.8 had it.

I looked at the {{QuorumPeerConfig.parseConfiguration()}} code, and as you say, 
the existence of a {{myid}} file is only checked for when the number of servers 
is greater than one.

However, there is other code that enables Solr's embedded ZK to participate in 
a quorum, so I think removing code that allows that would be a mistake.  I 
haven't tested setting up a quorum exclusively with embedded ZK in multiple 
Solr nodes, but I assume that's possible. 

> Upgrade Zookeeper to 3.4.10
> ---
>
> Key: SOLR-9386
> URL: https://issues.apache.org/jira/browse/SOLR-9386
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-9386-fix-clientPort-parsing.patch, SOLR-9386.patch, 
> SOLR-9386.patch, SOLR-9386.patch, zookeeper-3.4.8-upgrade-tests-pass.patch, 
> zookeeper-3.4.9-upgrade-tests-fail.patch
>
>
> Zookeeper 3.4.10 release should be happening fairly soon, and the ZK issue 
> blocking incorporation into Solr (ZOOKEEPER-2383) has a 3.4.10-targetted 
> patch that fixes the test failures problem noted on SOLR-8724.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (SOLR-10565) SolrJmxReporterTest.testEnabled() failure

2017-05-01 Thread Steve Rowe (JIRA)

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

Steve Rowe commented on SOLR-10565:
---

My Jenkins found a reproducing branch_6x seed:

{noformat}
Checking out Revision 66bf7a8e32ed5c541a30b72df709ec5290c88715 
(refs/remotes/origin/branch_6x)
[...]
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=SolrJmxReporterTest 
-Dtests.method=testEnabled -Dtests.seed=66AEE62D6CEBF613 -Dtests.slow=true 
-Dtests.locale=nl-NL -Dtests.timezone=Asia/Tel_Aviv -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] FAILURE 2.91s J4  | SolrJmxReporterTest.testEnabled <<<
   [junit4]> Throwable #1: java.lang.AssertionError: expected:<8> but 
was:<10>
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([66AEE62D6CEBF613:516F47F32D4E8663]:0)
   [junit4]>at 
org.apache.solr.metrics.reporters.SolrJmxReporterTest.testEnabled(SolrJmxReporterTest.java:197)
[...]
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene62): {}, 
docValues:{}, maxPointsInLeafNode=1877, maxMBSortInHeap=6.611606782323239, 
sim=RandomSimilarity(queryNorm=false,coord=no): {}, locale=nl-NL, 
timezone=Asia/Tel_Aviv
   [junit4]   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 
1.8.0_77 (64-bit)/cpus=16,threads=1,free=219929096,total=362807296
{noformat}

> SolrJmxReporterTest.testEnabled() failure
> -
>
> Key: SOLR-10565
> URL: https://issues.apache.org/jira/browse/SOLR-10565
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Reporter: Steve Rowe
>Assignee: Andrzej Bialecki 
> Fix For: 6.6, master (7.0)
>
>
> My Jenkins found a reproducing branch_6x seed:
> {noformat}
> Checking out Revision ea3f9bb87d1e6c3cf812122c3a6f9160a8b49a19 
> (refs/remotes/origin/branch_6x)
> [...]
>[junit4]   2> 86968 INFO  
> (TEST-SolrJmxReporterTest.testEnabled-seed#[79BD33EADDE24AC0]) [
> x:collection1] o.a.s.SolrTestCaseJ4 ###Ending testEnabled
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=SolrJmxReporterTest -Dtests.method=testEnabled 
> -Dtests.seed=79BD33EADDE24AC0 -Dtests.slow=true -Dtests.locale=cs 
> -Dtests.timezone=Europe/Amsterdam -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 0.82s J6  | SolrJmxReporterTest.testEnabled <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<1> but 
> was:<2>
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([79BD33EADDE24AC0:4E7C92349C473AB0]:0)
>[junit4]>  at 
> org.apache.solr.metrics.reporters.SolrJmxReporterTest.testEnabled(SolrJmxReporterTest.java:197)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene62): {}, 
> docValues:{}, maxPointsInLeafNode=1415, maxMBSortInHeap=6.528209197753226, 
> sim=RandomSimilarity(queryNorm=false,coord=yes): {}, locale=cs, 
> timezone=Europe/Amsterdam
>[junit4]   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 
> 1.8.0_77 (64-bit)/cpus=16,threads=1,free=154074736,total=443023360
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (SOLR-9386) Upgrade Zookeeper to 3.4.10

2017-05-01 Thread Shawn Heisey (JIRA)

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

Shawn Heisey commented on SOLR-9386:


[~steve_rowe], in newer ZK versions, standalone servers no longer require a 
myid file.  We shouldn't need to handle that any more.  I can't locate the 
ZOOKEEPER issue where that was changed, so I do not know what version made our 
standalone config work, but I'm pretty sure that 3.4.8 had it.


> Upgrade Zookeeper to 3.4.10
> ---
>
> Key: SOLR-9386
> URL: https://issues.apache.org/jira/browse/SOLR-9386
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-9386-fix-clientPort-parsing.patch, SOLR-9386.patch, 
> SOLR-9386.patch, SOLR-9386.patch, zookeeper-3.4.8-upgrade-tests-pass.patch, 
> zookeeper-3.4.9-upgrade-tests-fail.patch
>
>
> Zookeeper 3.4.10 release should be happening fairly soon, and the ZK issue 
> blocking incorporation into Solr (ZOOKEEPER-2383) has a 3.4.10-targetted 
> patch that fixes the test failures problem noted on SOLR-8724.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Created] (SOLR-10593) Change Ref Guide site name at comments.apache.org for comment integration

2017-05-01 Thread Cassandra Targett (JIRA)
Cassandra Targett created SOLR-10593:


 Summary: Change Ref Guide site name at comments.apache.org for 
comment integration
 Key: SOLR-10593
 URL: https://issues.apache.org/jira/browse/SOLR-10593
 Project: Solr
  Issue Type: Sub-task
  Security Level: Public (Default Security Level. Issues are Public)
  Components: documentation
Reporter: Cassandra Targett
Assignee: Cassandra Targett
Priority: Minor


The new HTML site incorporates comments from comments.apache.org, and a long 
time ago we had a site created named "solrcwiki". Since we're moving off 
Confluence (cwiki) that name doesn't make a ton of sense and will make less 
sense in the future, so now is a great time to change it/delete it/recreate it.

INFRA-14063 asked for this change to be made, and I was granted access to 
create a new site. This issue is to take care of that and update the Javascript 
in the HTML page templates accordingly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (SOLR-10587) Ban defaultSearchField in schema for luceneMatchVersion =>6.6.0

2017-05-01 Thread JIRA

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

Jan Høydahl commented on SOLR-10587:


Thanks. Think this is more or less what we need. I'll try to switch tests to 
using "df" and then commit this.

> Ban defaultSearchField in schema for luceneMatchVersion =>6.6.0
> ---
>
> Key: SOLR-10587
> URL: https://issues.apache.org/jira/browse/SOLR-10587
> Project: Solr
>  Issue Type: Sub-task
>  Components: Schema and Analysis
>Reporter: Jan Høydahl
> Fix For: 6.6
>
> Attachments: SOLR-10587.patch, SOLR-10587.patch
>
>
> Sub task of SOLR-7041.
> For new configs with luceneMatchVersion >=6.6.0 we'll throw an exception if  
> defaultSearchField is used in schema.
> For luceneMatchVersion < 6.0.0 we'll behave like before (warn only). This is 
> to deliver on our back-compat promise between minor versions.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Created] (SOLR-10592) SolrCoreMetricManagerTest.testRegisterMetricsWithReplacements() failure

2017-05-01 Thread Steve Rowe (JIRA)
Steve Rowe created SOLR-10592:
-

 Summary: 
SolrCoreMetricManagerTest.testRegisterMetricsWithReplacements() failure
 Key: SOLR-10592
 URL: https://issues.apache.org/jira/browse/SOLR-10592
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Steve Rowe


My Jenkins found a reproducing master seed:

{noformat}
Checking out Revision e96dc4f21c48044ac60086ce4419746125d67c3d 
(refs/remotes/origin/master)
[...]
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=SolrCoreMetricManagerTest 
-Dtests.method=testRegisterMetricsWithReplacements 
-Dtests.seed=86E81F42B75FE0C6 -Dtests.slow=true -Dtests.locale=cs 
-Dtests.timezone=America/Nassau -Dtests.asserts=true -Dtests.file.encoding=UTF-8
   [junit4] FAILURE 0.43s J7  | 
SolrCoreMetricManagerTest.testRegisterMetricsWithReplacements <<<
   [junit4]> Throwable #1: java.lang.AssertionError: expected:<79> but 
was:<81>
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([86E81F42B75FE0C6:328602625B1AA842]:0)
   [junit4]>at 
org.apache.solr.metrics.SolrCoreMetricManagerTest.assertRegistered(SolrCoreMetricManagerTest.java:139)
   [junit4]>at 
org.apache.solr.metrics.SolrCoreMetricManagerTest.testRegisterMetricsWithReplacements(SolrCoreMetricManagerTest.java:96)
[...]
   [junit4]   2> NOTE: test params are: 
codec=HighCompressionCompressingStoredFields(storedFieldsFormat=CompressingStoredFieldsFormat(compressionMode=HIGH_COMPRESSION,
 chunkSize=398, maxDocsPerChunk=10, blockSize=150), 
termVectorsFormat=CompressingTermVectorsFormat(compressionMode=HIGH_COMPRESSION,
 chunkSize=398, blockSize=150)), sim=RandomSimilarity(queryNorm=false): {}, 
locale=cs, timezone=America/Nassau
   [junit4]   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 
1.8.0_77 (64-bit)/cpus=16,threads=1,free=246563960,total=529006592
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Updated] (SOLR-10591) Backup and Restore Solr Index based on Time

2017-05-01 Thread Avinash Gaddam (JIRA)

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

Avinash Gaddam updated SOLR-10591:
--
Priority: Critical  (was: Major)

> Backup and Restore Solr Index based on Time
> ---
>
> Key: SOLR-10591
> URL: https://issues.apache.org/jira/browse/SOLR-10591
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Backup/Restore
>Affects Versions: 5.0
>Reporter: Avinash Gaddam
>Priority: Critical
>
> Hi,
> I am fairly new to Solr world, had an requirement regarding Backup/Solr data -
>  Requirement -
> Currently we are Indexing Metadatasin Solr which has been for around year. 
> We want to take a backup of data on Month to Month basis and restore the same 
> when required. i.e. say - take back up of March data alone and restore the 
> same back in the month of May.
> Tried till now –
> I was able to take back up of Complete Index and restore the same back as new 
> Index.
> But unable to merge it with Current latest Index. Is this doable?
> Can  I take Partial data Backup and Restore the same to the current Index.?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (SOLR-9386) Upgrade Zookeeper to 3.4.10

2017-05-01 Thread Joel Bernstein (JIRA)

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

Joel Bernstein commented on SOLR-9386:
--

This fixed the problem, thanks [~steve_rowe]!

> Upgrade Zookeeper to 3.4.10
> ---
>
> Key: SOLR-9386
> URL: https://issues.apache.org/jira/browse/SOLR-9386
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-9386-fix-clientPort-parsing.patch, SOLR-9386.patch, 
> SOLR-9386.patch, SOLR-9386.patch, zookeeper-3.4.8-upgrade-tests-pass.patch, 
> zookeeper-3.4.9-upgrade-tests-fail.patch
>
>
> Zookeeper 3.4.10 release should be happening fairly soon, and the ZK issue 
> blocking incorporation into Solr (ZOOKEEPER-2383) has a 3.4.10-targetted 
> patch that fixes the test failures problem noted on SOLR-8724.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Updated] (SOLR-10549) /schema/fieldtypes doesn't include "large" if configured as a fieldType default

2017-05-01 Thread David Smiley (JIRA)

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

David Smiley updated SOLR-10549:

Attachment: SOLR_10549___schema_fieldtypes_showDefaults_misses_large.patch

Here's a simple patch.  It included updating a test.  Furthermore I tested it 
manually.

> /schema/fieldtypes doesn't include "large" if configured as a fieldType 
> default
> ---
>
> Key: SOLR-10549
> URL: https://issues.apache.org/jira/browse/SOLR-10549
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.5.1
>Reporter: Hoss Man
>Assignee: David Smiley
> Attachments: 
> SOLR_10549___schema_fieldtypes_showDefaults_misses_large.patch
>
>
> spin off of SOLR-10439 since that fix for {{/schema/fields}} is likely to be 
> included in 6.5.1, so the comparable fix for  {{/schema/fieldtypess}} needs 
> to be tracked in it's own jira



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
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 # 1277 - Unstable!

2017-05-01 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1277/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC

2 tests failed.
FAILED:  
org.apache.solr.store.blockcache.BlockDirectoryTest.testRandomAccessWrites

Error Message:
Direct buffer memory

Stack Trace:
java.lang.OutOfMemoryError: Direct buffer memory
at java.nio.Bits.reserveMemory(Bits.java:693)
at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123)
at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
at 
org.apache.solr.store.blockcache.BlockCache.(BlockCache.java:71)
at 
org.apache.solr.store.blockcache.BlockDirectoryTest.setUp(BlockDirectoryTest.java:119)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:941)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:745)


FAILED:  org.apache.solr.update.AutoCommitTest.testMaxTime

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([470CE34A8D87F6A:9E84B3D63642E356]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:896)
   

[jira] [Commented] (SOLR-10522) Duplicate keys in "collations" object with JSON response format

2017-05-01 Thread James Dyer (JIRA)

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

James Dyer commented on SOLR-10522:
---

We might need to re-think our work with SOLR-9972.  My apologizes [~cpoerschke] 
in that when I reviewed SOLR-9972, I hadn't realized we had more than 1 json 
format and that fixing one might break the others. 

prior to SOLR-9972, our "flat" (default) json looked like this for the 
collation section:
{noformat}
"collations":[
"collation",{
"collationQuery":"lowerfilt:(+faith +hope +loaves)",
"hits":1,
"misspellingsAndCorrections":[
"fauth","faith",
"home","hope",
"loane","loaves"]},
"collation",{
"collationQuery":"lowerfilt:(+faith +hope +love)",
"hits":1,
"misspellingsAndCorrections":[
"fauth","faith",
"home","hope",
"loane","love"]}]
{noformat}

...by having "collations" as a NamedList, we avoid having duplicate keys with 
"collation".  But the "arrntv" format chokes around the "collationQuery":

{noformat}
"collations":
[
{"name":"collation",{
"type":"str","value":"collationQuery":"lowerfilt:(+faith +hope +loaves)",
"hits":1,
"misspellingsAndCorrections":
[
{"name":"fauth","type":"str","value":"faith"},
{"name":"home","type":"str","value":"hope"},
{"name":"loane","type":"str","value":"loaves"}]}},
{"name":"collation",{
"type":"str","value":"collationQuery":"lowerfilt:(+faith +hope +love)",
"hits":1,
"misspellingsAndCorrections":
[
{"name":"fauth","type":"str","value":"faith"},
{"name":"home","type":"str","value":"hope"},
{"name":"loane","type":"str","value":"love"}]}}]
{noformat}

...So SOLR-9972 changed "collations" to be a SimpleOrderedMap.  Now we get this 
for "arrntv":
{noformat}
"collations":{
"collation":{
"collationQuery":"lowerfilt:(+faith +hope +loaves)",
"hits":1,
"misspellingsAndCorrections":
[
{"name":"fauth","type":"str","value":"faith"},
{"name":"home","type":"str","value":"hope"},
{"name":"loane","type":"str","value":"loaves"}]},
"collation":{
"collationQuery":"lowerfilt:(+faith +hope +love)",
"hits":1,
"misspellingsAndCorrections":
[
{"name":"fauth","type":"str","value":"faith"},
{"name":"home","type":"str","value":"hope"},
{"name":"loane","type":"str","value":"love"}]}}
{noformat}

...so now it renders valid json.  But under "collations", we have duplicate 
keys, right?  If there is more than 1 collation, the "collation" key keeps 
getting overwritten.  

So then, it seems that SOLR-9972 is only a partial fix for "arrntv" because 
while we have valid json, there are duplicate keys.  But worse, SOLR-9972 broke 
the default json format, both from a backwards-compatibility standpoint, and 
also from a correctness standpoint as this is also subject to duplicate keys.

I'd think reverting SOLR-9972 would leave us in a better situation than the 
current one.  But can someone suggest a solution that would result in:
- valid json for all the various json formats we support
- no duplicate keys when there are multiple collations
- no breaking backwards compatibility until 7.0, except for the 
completely-broken "arrntv" case ? (6.5 changes notwithstanding, breaking 
backwards here was a bug in my opinion).

??




> Duplicate keys in "collations" object with JSON response format
> ---
>
> Key: SOLR-10522
> URL: https://issues.apache.org/jira/browse/SOLR-10522
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spellchecker
>Affects Versions: 6.5
>Reporter: Nikita Pchelintsev
>Assignee: James Dyer
>Priority: Minor
>
> After upgrading Solr 6.3 -> 6.5 I've noticed a change in how json response 
> writer outputs "collations" response key when spellchecking is enabled 
> (wt=json=arrarr)
> Solr 6.3:
> "collations":
> [
>   ["collation",{
>   "collationQuery":"the",
>   "hits":48,
>   "maxScore":"30.282",
>   "misspellingsAndCorrections":
>   [
> ["thea","the"]]}],
>   ["collation",{
>   "collationQuery":"tea",
>   "hits":3,
>   "maxScore":"2.936",
>   "misspellingsAndCorrections":
>   [
> ["thea","tea"]]}],
>   ...
> Solr 6.5:
> "collations":{
>   "collation":{
> "collationQuery":"the",
> "hits":43,
> "misspellingsAndCorrections":
> [
>   ["thea","the"]]},
>   "collation":{
> "collationQuery":"tea",
> "hits":3,
> "misspellingsAndCorrections":
> [
>   

[jira] [Commented] (SOLR-10559) Add let and get Streaming Expressions

2017-05-01 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-10559:


Commit ee8ce57e51e488a706f9ec64825ad23bda07afdf in lucene-solr's branch 
refs/heads/master from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ee8ce57 ]

SOLR-10559: Fix TupStream to respect field order


> Add let and get Streaming Expressions
> -
>
> Key: SOLR-10559
> URL: https://issues.apache.org/jira/browse/SOLR-10559
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Attachments: SOLR-10559.patch, SOLR-10559.patch, SOLR-10559.patch, 
> SOLR-10559.patch
>
>
> The *let* and *get* Streaming Expressions allows the tuples in a stream to be 
> assigned to a variable so it can be used more then once during an expression.
> This builds on the *list* and *cell* expressions (SOLR-10551) 
> Here is the sample syntax:
> {code}
> let(cell(a, expr), 
> cell(b, expr), 
> list(cell(a, get(a)),
>  cell(b, get(b)),
>  cell(correlation, correlate(get(a), fielda, get(b), fieldb)))
> {code}
> In the example above the *let* expression is saving the contents of two 
> *cell* expressions (a, b). The *get* expression is retrieving the tuples and 
> using them later in the expression.
> So for example two facet expressions could be stored in the *let*, and then 
> displayed and correlated later in the expression.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 337 - Still Unstable

2017-05-01 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.x/337/

2 tests failed.
FAILED:  
org.apache.lucene.codecs.simpletext.TestSimpleTextTermVectorsFormat.testRamBytesUsed

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([D8F73D5A98A34F7B]:0)


FAILED:  
junit.framework.TestSuite.org.apache.lucene.codecs.simpletext.TestSimpleTextTermVectorsFormat

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([D8F73D5A98A34F7B]:0)




Build Log:
[...truncated 6940 lines...]
   [junit4] Suite: 
org.apache.lucene.codecs.simpletext.TestSimpleTextTermVectorsFormat
   [junit4]   2> may 01, 2017 3:32:17 AM 
com.carrotsearch.randomizedtesting.ThreadLeakControl$2 evaluate
   [junit4]   2> WARNING: Suite execution timed out: 
org.apache.lucene.codecs.simpletext.TestSimpleTextTermVectorsFormat
   [junit4]   2>1) Thread[id=3854, 
name=TEST-TestSimpleTextTermVectorsFormat.testRamBytesUsed-seed#[D8F73D5A98A34F7B],
 state=RUNNABLE, group=TGRP-TestSimpleTextTermVectorsFormat]
   [junit4]   2> at 
org.apache.lucene.store.BufferedChecksumIndexInput.readByte(BufferedChecksumIndexInput.java:41)
   [junit4]   2> at 
org.apache.lucene.codecs.simpletext.SimpleTextUtil.readLine(SimpleTextUtil.java:59)
   [junit4]   2> at 
org.apache.lucene.codecs.simpletext.SimpleTextTermVectorsReader.readIndex(SimpleTextTermVectorsReader.java:98)
   [junit4]   2> at 
org.apache.lucene.codecs.simpletext.SimpleTextTermVectorsReader.(SimpleTextTermVectorsReader.java:81)
   [junit4]   2> at 
org.apache.lucene.codecs.simpletext.SimpleTextTermVectorsFormat.vectorsReader(SimpleTextTermVectorsFormat.java:40)
   [junit4]   2> at 
org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:128)
   [junit4]   2> at 
org.apache.lucene.index.SegmentReader.(SegmentReader.java:74)
   [junit4]   2> at 
org.apache.lucene.index.ReadersAndUpdates.getReader(ReadersAndUpdates.java:145)
   [junit4]   2> at 
org.apache.lucene.index.ReadersAndUpdates.getReaderForMerge(ReadersAndUpdates.java:617)
   [junit4]   2> at 
org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4286)
   [junit4]   2> at 
org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3931)
   [junit4]   2> at 
org.apache.lucene.index.SerialMergeScheduler.merge(SerialMergeScheduler.java:40)
   [junit4]   2> at 
org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:2083)
   [junit4]   2> at 
org.apache.lucene.index.IndexWriter.doAfterSegmentFlushed(IndexWriter.java:5005)
   [junit4]   2> at 
org.apache.lucene.index.DocumentsWriter$MergePendingEvent.process(DocumentsWriter.java:731)
   [junit4]   2> at 
org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:5043)
   [junit4]   2> at 
org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:5034)
   [junit4]   2> at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1574)
   [junit4]   2> at 
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1316)
   [junit4]   2> at 
org.apache.lucene.index.BaseIndexFileFormatTestCase.testRamBytesUsed(BaseIndexFileFormatTestCase.java:257)
   [junit4]   2> at 
org.apache.lucene.index.BaseTermVectorsFormatTestCase.testRamBytesUsed(BaseTermVectorsFormatTestCase.java:71)
   [junit4]   2> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
   [junit4]   2> at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   [junit4]   2> at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   [junit4]   2> at java.lang.reflect.Method.invoke(Method.java:498)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
   [junit4]   2> at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
   [junit4]   2> at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
   [junit4]   2> at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
   [junit4]   2> at 

[jira] [Commented] (SOLR-10566) Add timeseries Streaming Expression

2017-05-01 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-10566:


Commit 0a2286c5f26d77f1bdf64e2c3843c7505ff6c356 in lucene-solr's branch 
refs/heads/master from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0a2286c ]

SOLR-10566: Fix error handling


> Add timeseries Streaming Expression
> ---
>
> Key: SOLR-10566
> URL: https://issues.apache.org/jira/browse/SOLR-10566
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Attachments: SOLR-10566.patch, SOLR-10566.patch
>
>
> This ticket is to add specific time series support to streaming expressions. 
> Under the covers the timeseries expression will use the json facet API. 
> sample syntax:
> {code}
> timeseries(collection, 
>q="*:*", 
>field="rectime_dt",
>start = "2011-04-01T01:00:00.000Z",
>  end = "2016-04-01T01:00:00.000Z",
>  gap = "+1MONTH",
>count(*),
>sum(price))
> {code}
> This goes nicely with SOLR-10559. The idea is to support expressions that 
> cross-correlate and regress time series data.
> {code}
> let(cell(timeseriesA, timeseries(...)), 
> cell(timeSeriesB, timeseries(...)), 
> list(cell(a, get(timeseriesA)),
>  cell(b, get(timeseriesB)),
>  cell(stats, regres(col(timeseriesA, count(*)), col(timeseriesB, 
> count(*))
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[JENKINS] Lucene-Solr-6.x-MacOSX (64bit/jdk1.8.0) - Build # 843 - Unstable!

2017-05-01 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/843/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.solr.cloud.CustomCollectionTest.testRouteFieldForImplicitRouter

Error Message:
Collection not found: withShardField

Stack Trace:
org.apache.solr.common.SolrException: Collection not found: withShardField
at 
__randomizedtesting.SeedInfo.seed([1665D046525E1607:433538D4FEA7D9F7]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.getCollectionNames(CloudSolrClient.java:1401)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1094)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1073)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:160)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.cloud.CustomCollectionTest.testRouteFieldForImplicitRouter(CustomCollectionTest.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-10588) SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection failure caused by concurrent core reload.

2017-05-01 Thread Erick Erickson (JIRA)

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

Erick Erickson commented on SOLR-10588:
---

At least it's in the same ballpark. [~shalinmangar]'s comments may shed some 
light on this.

Mikhail: I can get SolrCloudExapmleTest to fail on my system, I'll give this a 
spin momentarily.

Erick

> SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection failure caused 
> by concurrent core reload. 
> 
>
> Key: SOLR-10588
> URL: https://issues.apache.org/jira/browse/SOLR-10588
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
> Attachments: consoleFull.html.zip, SOLR-10588.patch
>
>
> https://builds.apache.org/job/Lucene-Solr-Tests-master/1788/testReport/junit/junit.framework/TestSuite/org_apache_solr_cloud_SolrCloudExampleTest/
> this NPE, even it might be quite reasonable itself, breaks core reload, and 
> applying config param. I'm -not- sure, -how- it -'s related- causes to these 
> constant failures.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Assigned] (SOLR-10430) Add ls command to ZkCLI for listing only sub-directories

2017-05-01 Thread Mark Miller (JIRA)

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

Mark Miller reassigned SOLR-10430:
--

Assignee: Mark Miller

> Add ls command to ZkCLI for listing only sub-directories
> 
>
> Key: SOLR-10430
> URL: https://issues.apache.org/jira/browse/SOLR-10430
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Reporter: Peter Szantai-Kis
>Assignee: Mark Miller
>Priority: Minor
> Attachments: SOLR-10430.patch, SOLR-10430.patch, SOLR-10430.patch
>
>
> Current list command prints out the whole directory/file tree, which can be 
> too verbose for some situations, especially when the cluster gets bigger over 
> time. 
> Add a "ls" command that would support listing only part of the file tree 
> based on the input path given



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Resolved] (SOLR-9386) Upgrade Zookeeper to 3.4.10

2017-05-01 Thread Steve Rowe (JIRA)

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

Steve Rowe resolved SOLR-9386.
--
Resolution: Fixed

Resolving as fixed.  Thanks [~joel.bernstein] for reporting the clientPort 
problem.

> Upgrade Zookeeper to 3.4.10
> ---
>
> Key: SOLR-9386
> URL: https://issues.apache.org/jira/browse/SOLR-9386
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-9386-fix-clientPort-parsing.patch, SOLR-9386.patch, 
> SOLR-9386.patch, SOLR-9386.patch, zookeeper-3.4.8-upgrade-tests-pass.patch, 
> zookeeper-3.4.9-upgrade-tests-fail.patch
>
>
> Zookeeper 3.4.10 release should be happening fairly soon, and the ZK issue 
> blocking incorporation into Solr (ZOOKEEPER-2383) has a 3.4.10-targetted 
> patch that fixes the test failures problem noted on SOLR-8724.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (SOLR-9386) Upgrade Zookeeper to 3.4.10

2017-05-01 Thread ASF subversion and git services (JIRA)

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

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

Commit 8c11f81a9505a0719e971ed6c54c9b6fc10bfa13 in lucene-solr's branch 
refs/heads/master from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8c11f81 ]

SOLR-9386: Move default clientPort specification to before calling 
QuorumPeerConfig.parseProperties(), which requires that clientPort be specified.


> Upgrade Zookeeper to 3.4.10
> ---
>
> Key: SOLR-9386
> URL: https://issues.apache.org/jira/browse/SOLR-9386
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-9386-fix-clientPort-parsing.patch, SOLR-9386.patch, 
> SOLR-9386.patch, SOLR-9386.patch, zookeeper-3.4.8-upgrade-tests-pass.patch, 
> zookeeper-3.4.9-upgrade-tests-fail.patch
>
>
> Zookeeper 3.4.10 release should be happening fairly soon, and the ZK issue 
> blocking incorporation into Solr (ZOOKEEPER-2383) has a 3.4.10-targetted 
> patch that fixes the test failures problem noted on SOLR-8724.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (SOLR-9386) Upgrade Zookeeper to 3.4.10

2017-05-01 Thread ASF subversion and git services (JIRA)

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

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

Commit c44d0bc89c03de2a3a69a1765d70b8aa0d81b475 in lucene-solr's branch 
refs/heads/branch_6x from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c44d0bc ]

SOLR-9386: Move default clientPort specification to before calling 
QuorumPeerConfig.parseProperties(), which requires that clientPort be specified.


> Upgrade Zookeeper to 3.4.10
> ---
>
> Key: SOLR-9386
> URL: https://issues.apache.org/jira/browse/SOLR-9386
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-9386-fix-clientPort-parsing.patch, SOLR-9386.patch, 
> SOLR-9386.patch, SOLR-9386.patch, zookeeper-3.4.8-upgrade-tests-pass.patch, 
> zookeeper-3.4.9-upgrade-tests-fail.patch
>
>
> Zookeeper 3.4.10 release should be happening fairly soon, and the ZK issue 
> blocking incorporation into Solr (ZOOKEEPER-2383) has a 3.4.10-targetted 
> patch that fixes the test failures problem noted on SOLR-8724.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (SOLR-9386) Upgrade Zookeeper to 3.4.10

2017-05-01 Thread Steve Rowe (JIRA)

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

Steve Rowe commented on SOLR-9386:
--

All tests & precommit pass with [^SOLR-9386-fix-clientPort-parsing.patch], and 
{{bin/solr start -e cloud -noprompt}} works.

Committing shortly.

> Upgrade Zookeeper to 3.4.10
> ---
>
> Key: SOLR-9386
> URL: https://issues.apache.org/jira/browse/SOLR-9386
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-9386-fix-clientPort-parsing.patch, SOLR-9386.patch, 
> SOLR-9386.patch, SOLR-9386.patch, zookeeper-3.4.8-upgrade-tests-pass.patch, 
> zookeeper-3.4.9-upgrade-tests-fail.patch
>
>
> Zookeeper 3.4.10 release should be happening fairly soon, and the ZK issue 
> blocking incorporation into Solr (ZOOKEEPER-2383) has a 3.4.10-targetted 
> patch that fixes the test failures problem noted on SOLR-8724.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Updated] (LUCENE-7813) Force toString implementation for payload functions

2017-05-01 Thread Markus Jelsma (JIRA)

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

Markus Jelsma updated LUCENE-7813:
--
Attachment: LUCENE-7813.patch

Patch for master

> Force toString implementation for payload functions
> ---
>
> Key: LUCENE-7813
> URL: https://issues.apache.org/jira/browse/LUCENE-7813
> Project: Lucene - Core
>  Issue Type: Task
>Affects Versions: 6.5.1
>Reporter: Markus Jelsma
>Priority: Trivial
> Fix For: master (7.0)
>
> Attachments: LUCENE-7813.patch
>
>
> Patch provides toString for payload functions. With this, queries and score 
> in debug output is better readable.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Created] (LUCENE-7813) Force toString implementation for payload functions

2017-05-01 Thread Markus Jelsma (JIRA)
Markus Jelsma created LUCENE-7813:
-

 Summary: Force toString implementation for payload functions
 Key: LUCENE-7813
 URL: https://issues.apache.org/jira/browse/LUCENE-7813
 Project: Lucene - Core
  Issue Type: Task
Affects Versions: 6.5.1
Reporter: Markus Jelsma
Priority: Trivial
 Fix For: master (7.0)


Patch provides toString for payload functions. With this, queries and score in 
debug output is better readable.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Updated] (SOLR-9386) Upgrade Zookeeper to 3.4.10

2017-05-01 Thread Steve Rowe (JIRA)

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

Steve Rowe updated SOLR-9386:
-
Attachment: SOLR-9386-fix-clientPort-parsing.patch

Patch moving default {{clientPort}} specification to before parsing of 
{{zoo.cfg}}.

> Upgrade Zookeeper to 3.4.10
> ---
>
> Key: SOLR-9386
> URL: https://issues.apache.org/jira/browse/SOLR-9386
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-9386-fix-clientPort-parsing.patch, SOLR-9386.patch, 
> SOLR-9386.patch, SOLR-9386.patch, zookeeper-3.4.8-upgrade-tests-pass.patch, 
> zookeeper-3.4.9-upgrade-tests-fail.patch
>
>
> Zookeeper 3.4.10 release should be happening fairly soon, and the ZK issue 
> blocking incorporation into Solr (ZOOKEEPER-2383) has a 3.4.10-targetted 
> patch that fixes the test failures problem noted on SOLR-8724.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Closed] (LUCENE-6882) java.lang.NoClassDefFoundError: org/apache/lucene/codecs/lucene54/Lucene54Codec

2017-05-01 Thread Ishan Chattopadhyaya (JIRA)

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

Ishan Chattopadhyaya closed LUCENE-6882.


> java.lang.NoClassDefFoundError: 
> org/apache/lucene/codecs/lucene54/Lucene54Codec
> ---
>
> Key: LUCENE-6882
> URL: https://issues.apache.org/jira/browse/LUCENE-6882
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: -tools
>Affects Versions: 5.3
> Environment: maven 3.2.5
> JDK 1.8
>Reporter: Martin Gainty
>   Original Estimate: 8h
>  Remaining Estimate: 8h
>
> ---
> Test set: org.apache.lucene.analysis.ar.TestArabicAnalyzer
> ---
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.159 sec <<< 
> FAILURE! - in org.apache.lucene.analysis.ar.TestArabicAnalyzer
> org.apache.lucene.analysis.ar.TestArabicAnalyzer  Time elapsed: 0.156 sec  
> <<< ERROR!
> java.lang.NoClassDefFoundError: 
> org/apache/lucene/codecs/lucene54/Lucene54Codec
>   at 
> org.apache.lucene.util.LuceneTestCase.(LuceneTestCase.java:606)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Unknown Source)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:581)
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.lucene.codecs.lucene54.Lucene54Codec
>   at java.net.URLClassLoader.findClass(Unknown Source)
>   at java.lang.ClassLoader.loadClass(Unknown Source)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
>   at java.lang.ClassLoader.loadClass(Unknown Source)
>   at 
> org.apache.lucene.util.LuceneTestCase.(LuceneTestCase.java:606)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Unknown Source)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:581)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Resolved] (LUCENE-6882) java.lang.NoClassDefFoundError: org/apache/lucene/codecs/lucene54/Lucene54Codec

2017-05-01 Thread Ishan Chattopadhyaya (JIRA)

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

Ishan Chattopadhyaya resolved LUCENE-6882.
--
Resolution: Not A Problem

> java.lang.NoClassDefFoundError: 
> org/apache/lucene/codecs/lucene54/Lucene54Codec
> ---
>
> Key: LUCENE-6882
> URL: https://issues.apache.org/jira/browse/LUCENE-6882
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: -tools
>Affects Versions: 5.3
> Environment: maven 3.2.5
> JDK 1.8
>Reporter: Martin Gainty
>   Original Estimate: 8h
>  Remaining Estimate: 8h
>
> ---
> Test set: org.apache.lucene.analysis.ar.TestArabicAnalyzer
> ---
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.159 sec <<< 
> FAILURE! - in org.apache.lucene.analysis.ar.TestArabicAnalyzer
> org.apache.lucene.analysis.ar.TestArabicAnalyzer  Time elapsed: 0.156 sec  
> <<< ERROR!
> java.lang.NoClassDefFoundError: 
> org/apache/lucene/codecs/lucene54/Lucene54Codec
>   at 
> org.apache.lucene.util.LuceneTestCase.(LuceneTestCase.java:606)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Unknown Source)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:581)
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.lucene.codecs.lucene54.Lucene54Codec
>   at java.net.URLClassLoader.findClass(Unknown Source)
>   at java.lang.ClassLoader.loadClass(Unknown Source)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
>   at java.lang.ClassLoader.loadClass(Unknown Source)
>   at 
> org.apache.lucene.util.LuceneTestCase.(LuceneTestCase.java:606)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Unknown Source)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:581)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Assigned] (SOLR-10522) Duplicate keys in "collations" object with JSON response format

2017-05-01 Thread James Dyer (JIRA)

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

James Dyer reassigned SOLR-10522:
-

Assignee: James Dyer

> Duplicate keys in "collations" object with JSON response format
> ---
>
> Key: SOLR-10522
> URL: https://issues.apache.org/jira/browse/SOLR-10522
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spellchecker
>Affects Versions: 6.5
>Reporter: Nikita Pchelintsev
>Assignee: James Dyer
>Priority: Minor
>
> After upgrading Solr 6.3 -> 6.5 I've noticed a change in how json response 
> writer outputs "collations" response key when spellchecking is enabled 
> (wt=json=arrarr)
> Solr 6.3:
> "collations":
> [
>   ["collation",{
>   "collationQuery":"the",
>   "hits":48,
>   "maxScore":"30.282",
>   "misspellingsAndCorrections":
>   [
> ["thea","the"]]}],
>   ["collation",{
>   "collationQuery":"tea",
>   "hits":3,
>   "maxScore":"2.936",
>   "misspellingsAndCorrections":
>   [
> ["thea","tea"]]}],
>   ...
> Solr 6.5:
> "collations":{
>   "collation":{
> "collationQuery":"the",
> "hits":43,
> "misspellingsAndCorrections":
> [
>   ["thea","the"]]},
>   "collation":{
> "collationQuery":"tea",
> "hits":3,
> "misspellingsAndCorrections":
> [
>   ["thea","tea"]]},
> ...
> Solr 6.5 outputs object instead of an array, and it has duplicate keys which 
> is not valid for JSON format.
> Any help is appreciated.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Reopened] (SOLR-9386) Upgrade Zookeeper to 3.4.10

2017-05-01 Thread Steve Rowe (JIRA)

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

Steve Rowe reopened SOLR-9386:
--

{quote}
I'm currently getting the following error when starting Solr in cloud mode 
(bin/solr start -c) in master. Could be related to this ticket, but not sure.

2017-05-01 02:36:29.297 ERROR (main) [ ] o.a.s.c.SolrCore 
null:java.lang.IllegalArgumentException: clientPort is not set
{quote}

Pretty sure this ^ is caused by the ZK upgrade.  Reopening to address.

Prior to this issue, Solr did its own parsing of {{zoo.cfg}}, but after this 
issue, Solr delegates to ZK's {{QuorumPeerConfig.parseProperties()}} to do so. 
ZK's method (unlike Solr's previous parsing code) requires that {{clientPort}} 
be specified in {{zoo.cfg}}.

Solr's check for missing {{clientPort}} configuration (and setting to 
{{solrPort + 1000}} if absent) is currently performed *after* parsing 
{{zoo.cfg}}.  I have a patch I'm testing that moves supplying a default 
{{clientPort}} to before {{QuorumPeerConfig.parseProperties()}}.

> Upgrade Zookeeper to 3.4.10
> ---
>
> Key: SOLR-9386
> URL: https://issues.apache.org/jira/browse/SOLR-9386
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-9386.patch, SOLR-9386.patch, SOLR-9386.patch, 
> zookeeper-3.4.8-upgrade-tests-pass.patch, 
> zookeeper-3.4.9-upgrade-tests-fail.patch
>
>
> Zookeeper 3.4.10 release should be happening fairly soon, and the ZK issue 
> blocking incorporation into Solr (ZOOKEEPER-2383) has a 3.4.10-targetted 
> patch that fixes the test failures problem noted on SOLR-8724.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (SOLR-7759) DebugComponent's explain should be implemented as a distributed query

2017-05-01 Thread Markus Jelsma (JIRA)

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

Markus Jelsma commented on SOLR-7759:
-

Hello Alessandro, i do not seem to be able to reproduce the problem in the 
first place.

> DebugComponent's explain should be implemented as a distributed query
> -
>
> Key: SOLR-7759
> URL: https://issues.apache.org/jira/browse/SOLR-7759
> Project: Solr
>  Issue Type: Bug
>Reporter: Varun Thacker
> Attachments: SOLR_7759.patch
>
>
> Currently when we use debugQuery to see the explanation of the matched 
> documents, the query fired to get the statistics for the matched documents is 
> not a distributed query.
> This is a problem when using distributed idf. The actual documents are being 
> scored using the global stats and not per shard stats , but the explain will 
> show us the score by taking into account the stats from the shard where the 
> document belongs to.
> We should try to implement the explain query as a distributed request so that 
> the scores match the actual document scores.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (SOLR-8314) Group offset not working in SolrCloud with more than one shard

2017-05-01 Thread Shiva Kumar Sanapala (JIRA)

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

Shiva Kumar Sanapala commented on SOLR-8314:


Hello [~yo...@apache.org]
Even I am facing the same issue, kindly suggest if there are any other 
alternatives.
Thanks.

> Group offset not working in SolrCloud with more than one shard
> --
>
> Key: SOLR-8314
> URL: https://issues.apache.org/jira/browse/SOLR-8314
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3.1
>Reporter: Rafał Kuć
>
> Hi, 
> Unless I'm missing something it seems that there is a problem with 
> group.offset in SolrCloud. For the example cloud Solr and the example data 
> take a look at the following two queries:
> {noformat}
> http://localhost:8983/solr/gettingstarted/select?q=*:*=id+desc=id=true=cat:electronics=cat:connector=5=0=0=json=on
> {noformat}
> And:
> {noformat}
> http://localhost:8983/solr/gettingstarted/select?q=*:*=id+desc=id=true=cat:electronics=cat:connector=5=0=4=json=on
> {noformat}
> The response for the first query looks as follows:
> {noformat}
> {
>   "responseHeader":{
> "status":0,
> "QTime":8,
> "params":{
>   "q":"*:*",
>   "indent":"on",
>   "fl":"id",
>   "group.limit":"0",
>   "sort":"id desc",
>   "group.offset":"0",
>   "group.query":["cat:electronics",
> "cat:connector"],
>   "rows":"5",
>   "wt":"json",
>   "group":"true"}},
>   "grouped":{
> "cat:connector":{
>   "matches":32,
>   "doclist":{"numFound":2,"start":0,"docs":[
>   {
> "id":"IW-02"},
>   {
> "id":"F8V7067-APL-KIT"}]
>   }},
> "cat:electronics":{
>   "matches":32,
>   "doclist":{"numFound":12,"start":0,"docs":[
>   {
> "id":"VS1GB400C3"},
>   {
> "id":"VDBDB1A16"},
>   {
> "id":"TWINX2048-3200PRO"},
>   {
> "id":"SP2514N"},
>   {
> "id":"MA147LL/A"}]
>   
> {noformat}
> And the response to the second query looks as follows:
> {noformat}
> {
>   "responseHeader":{
> "status":0,
> "QTime":10,
> "params":{
>   "q":"*:*",
>   "indent":"on",
>   "fl":"id",
>   "group.limit":"0",
>   "sort":"id desc",
>   "group.offset":"4",
>   "group.query":["cat:electronics",
> "cat:connector"],
>   "rows":"5",
>   "wt":"json",
>   "group":"true"}},
>   "grouped":{
> "cat:connector":{
>   "matches":32,
>   "doclist":{"numFound":2,"start":4,"docs":[
>   {
> "id":"IW-02"},
>   {
> "id":"F8V7067-APL-KIT"}]
>   }},
> "cat:electronics":{
>   "matches":32,
>   "doclist":{"numFound":12,"start":4,"docs":[
>   {
> "id":"VS1GB400C3"},
>   {
> "id":"VDBDB1A16"},
>   {
> "id":"TWINX2048-3200PRO"},
>   {
> "id":"SP2514N"},
>   {
> "id":"MA147LL/A"}]
>   
> {noformat}
> You can see that the second query has group.offset=4 and even the header 
> states that the start is set to 4, but the documents are still the same as 
> the group.offset was set to 0. 
> If this something I'm missing or we have a bug?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (SOLR-10587) Ban defaultSearchField in schema for luceneMatchVersion =>6.6.0

2017-05-01 Thread Jason Gerlowski (JIRA)

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

Jason Gerlowski commented on SOLR-10587:


If you're not happy with the move of the log message, I am more than happy to 
change it back to living in {{readSchema}} or wherever else you'd prefer.

> Ban defaultSearchField in schema for luceneMatchVersion =>6.6.0
> ---
>
> Key: SOLR-10587
> URL: https://issues.apache.org/jira/browse/SOLR-10587
> Project: Solr
>  Issue Type: Sub-task
>  Components: Schema and Analysis
>Reporter: Jan Høydahl
> Fix For: 6.6
>
> Attachments: SOLR-10587.patch, SOLR-10587.patch
>
>
> Sub task of SOLR-7041.
> For new configs with luceneMatchVersion >=6.6.0 we'll throw an exception if  
> defaultSearchField is used in schema.
> For luceneMatchVersion < 6.0.0 we'll behave like before (warn only). This is 
> to deliver on our back-compat promise between minor versions.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Updated] (SOLR-10587) Ban defaultSearchField in schema for luceneMatchVersion =>6.6.0

2017-05-01 Thread Jason Gerlowski (JIRA)

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

Jason Gerlowski updated SOLR-10587:
---
Attachment: SOLR-10587.patch

Updated patch addresses your comments.  I trimmed down the schema.xml file as 
you proposed.  The *WARNING* message you asked about is still there in this 
patch, but has been moved to the 
{{checkVersionCompatibilityForDefaultSearchField}} method, as it seemed to fit 
there.

> Ban defaultSearchField in schema for luceneMatchVersion =>6.6.0
> ---
>
> Key: SOLR-10587
> URL: https://issues.apache.org/jira/browse/SOLR-10587
> Project: Solr
>  Issue Type: Sub-task
>  Components: Schema and Analysis
>Reporter: Jan Høydahl
> Fix For: 6.6
>
> Attachments: SOLR-10587.patch, SOLR-10587.patch
>
>
> Sub task of SOLR-7041.
> For new configs with luceneMatchVersion >=6.6.0 we'll throw an exception if  
> defaultSearchField is used in schema.
> For luceneMatchVersion < 6.0.0 we'll behave like before (warn only). This is 
> to deliver on our back-compat promise between minor versions.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
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_121) - Build # 19527 - Unstable!

2017-05-01 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19527/
Java: 64bit/jdk1.8.0_121 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.util.TestSolrCLIRunExample

Error Message:
ObjectTracker found 5 object(s) that were not released!!! 
[MockDirectoryWrapper, TransactionLog, MockDirectoryWrapper, 
MockDirectoryWrapper, MDCAwareThreadPoolExecutor] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at org.apache.solr.update.SolrIndexWriter.create(SolrIndexWriter.java:92)  at 
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:752)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:947)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:854)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:959)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:894)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:91)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:378)
  at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:388)
  at 
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:174)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:178)
  at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:747)  
at 
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:728)  
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:509)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:355)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:306)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582) 
 at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)  
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:395)  
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) 
 at org.eclipse.jetty.server.Server.handle(Server.java:534)  at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)  at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)  at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)  at 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) 
 at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
  at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
  at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589) 
 at java.lang.Thread.run(Thread.java:745)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.update.TransactionLog  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.update.TransactionLog.(TransactionLog.java:190)  at 
org.apache.solr.update.UpdateLog.newTransactionLog(UpdateLog.java:438)  at 
org.apache.solr.update.UpdateLog.ensureLog(UpdateLog.java:1250)  at 
org.apache.solr.update.UpdateLog.add(UpdateLog.java:524)  at 
org.apache.solr.update.UpdateLog.add(UpdateLog.java:509)  at 
org.apache.solr.update.DirectUpdateHandler2.doNormalUpdate(DirectUpdateHandler2.java:349)
  at 
org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:268)
  at 
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:218)
  at 
org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:67)
  at 

[jira] [Updated] (LUCENE-7812) modified test for testing payload

2017-05-01 Thread Martin Gainty (JIRA)

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

Martin Gainty updated LUCENE-7812:
--
Attachment: TestPayloadCheckQuery.java

> modified test for testing payload
> -
>
> Key: LUCENE-7812
> URL: https://issues.apache.org/jira/browse/LUCENE-7812
> Project: Lucene - Core
>  Issue Type: Test
>  Components: core/queryparser
>Affects Versions: 6.5.1
> Environment: jdk 1.8
> mvn 3.3
>Reporter: Martin Gainty
>Priority: Minor
> Attachments: TestPayloadCheckQuery.java
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
>  no specific test for SpanPayloadCheckQuery method specifically
> matches = payloadToMatch.get(upto).bytesEquals(payload);
> the only implementation i could locate was in collectLeaf of 
> SpanPayloadCheckQuery
> modified SpanPayloadCheckQueryTest now tests collectLeaf of 
> SpanPayloadCheckQuery
> patch for test attached
> suggestions/advice are most welcome



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Created] (LUCENE-7812) modified test for testing payload

2017-05-01 Thread Martin Gainty (JIRA)
Martin Gainty created LUCENE-7812:
-

 Summary: modified test for testing payload
 Key: LUCENE-7812
 URL: https://issues.apache.org/jira/browse/LUCENE-7812
 Project: Lucene - Core
  Issue Type: Test
  Components: core/queryparser
Affects Versions: 6.5.1
 Environment: jdk 1.8
mvn 3.3
Reporter: Martin Gainty
Priority: Minor


 no specific test for SpanPayloadCheckQuery method specifically

matches = payloadToMatch.get(upto).bytesEquals(payload);

the only implementation i could locate was in collectLeaf of 
SpanPayloadCheckQuery

modified SpanPayloadCheckQueryTest now tests collectLeaf of 
SpanPayloadCheckQuery

patch for test attached

suggestions/advice are most welcome



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



Re: Release 6.6

2017-05-01 Thread Martin Gainty
i was wondering if there was a specific test for SpanPayloadCheckQuery method


matches = payloadToMatch.get(upto).bytesEquals(payload);


the only implementation i could locate was in collectLeaf of 
SpanPayloadCheckQuery


I will submit JIRA with Patch


as a CS *dinosaur* I am more familiar with LISP for dissecting sentence 
fragments (what we called phenomes) than current SEO implementations


Can you suggest a book to read to better understand Lucenes pattern dissection 
and match algorithms?


Many Thanks for helpful guidance

Martin
__




From: Erik Hatcher 
Sent: Sunday, April 30, 2017 2:06 PM
To: dev@lucene.apache.org
Subject: Re: Release 6.6

Martin -

I have to admit to still being unsure what the gist is here - is there a bug?   
Apologies for not catching what you’re saying/showing here.  Again, as far as I 
can tell SpanPayloadCheckQuery is working as expected now.

I’m going to focus purely on SOLR-1485 this week to get it committed for 6.6.  
If there is an issue to address with your work would you please open a JIRA and 
include your patch there?

Thanks,
Erik


On Apr 30, 2017, at 7:47 AM, Martin Gainty 
> wrote:

Mornin' Erik

there is a collectLeaf  override in 
org.apache.lucene.queries.payloads.TestPayloadSpans ..but its never called:

static class VerifyingCollector implements SpanCollector {
List payloads = new ArrayList<>();
@Override
public void collectLeaf(PostingsEnum postings, int position, Term term) 
throws IOException {
 
 }
}

the modification in org.apache.lucene.queries.payloads.TestPayloadCheckQuery 
tests collectLeaf for query

//initialise term

log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 231 before 
term1=new org.apache.lucene.index.Term('field','withPayload')");
org.apache.lucene.index.Term term1=new org.apache.lucene.index.Term("field", 
"withPayload");
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 233 term1="+term1);

//assume position is 5
int position=5;
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 235 
position="+position);

BytesRef pay = new BytesRef("pos: " + position);
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 237 pay="+pay);

//build spanQuery with term parameter
org.apache.lucene.search.spans.SpanQuery spanQuery1 = new 
SpanTermQuery(term1);
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 239 
spanQuery1="+spanQuery1);

//add BytesRef to payloadToMatch list
java.util.List payloadToMatch=new 
java.util.ArrayList();
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 241 
payloadToMatch="+payloadToMatch);
payloadToMatch.add(pay);


//build SpanPayloadCheckQuery

query=new org.apache.lucene.queries.payloads.SpanPayloadCheckQuery(
(org.apache.lucene.search.spans.SpanQuery)query,
(java.util.List)payloadToMatch);
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 249 query="+query);

//build lucene Directory (TODO: we should use an existing directory with REAL 
test-data)
org.apache.lucene.store.Directory ram = 
newDirectory(com.carrotsearch.randomizedtesting.RandomizedContext.current().getRandom());

//build SegmentReader from Directory
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 251 ram="+ram);
SegmentReader reader = 
getOnlySegmentReader(org.apache.lucene.index.DirectoryReader.open(ram));
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 253 
reader="+reader);

//populate SlowCompositeReaderWrapper with SegmentReader
org.apache.lucene.index.LeafReader sr = 
org.apache.lucene.index.SlowCompositeReaderWrapper.wrap(reader);
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 255 sr="+sr);

//add term to SegmentReader postings
org.apache.lucene.index.PostingsEnum postings = sr.postings(term1, 
PostingsEnum.PAYLOADS);

log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257 before 
query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
 (int)position,(org.apache.lucene.index.Term)term1) where postings="+postings);

//display the parameters for collectLeaf method for query:
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258 before 
query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
 (int)position,(org.apache.lucene.index.Term)term1) where position="+position);

log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259 before 
query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
 (int)position,(org.apache.lucene.index.Term)term1) where term1="+term1);
try
{ //public void collectLeaf(org.apache.lucene.index.PostingsEnum postings, 
int position,   //org.apache.lucene.index.Term term) throws 
java.io.IOException {

[JENKINS] Lucene-Solr-6.x-Solaris (64bit/jdk1.8.0) - Build # 807 - Unstable!

2017-05-01 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/807/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC

2 tests failed.
FAILED:  org.apache.solr.cloud.OverseerTest.testStateChange

Error Message:
java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 
127.0.0.1:34193/solr within 3 ms

Stack Trace:
org.apache.solr.common.SolrException: java.util.concurrent.TimeoutException: 
Could not connect to ZooKeeper 127.0.0.1:34193/solr within 3 ms
at 
__randomizedtesting.SeedInfo.seed([D081385F60B54D77:F3052C7EBC96ACA0]:0)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:182)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:116)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:111)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:98)
at 
org.apache.solr.cloud.OverseerTest.testStateChange(OverseerTest.java:536)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
 

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1291 - Still unstable

2017-05-01 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1291/

1 tests failed.
FAILED:  org.apache.solr.cloud.hdfs.StressHdfsTest.test

Error Message:
Could not find collection:delete_data_dir

Stack Trace:
java.lang.AssertionError: Could not find collection:delete_data_dir
at 
__randomizedtesting.SeedInfo.seed([237FCD4FC409A0C0:AB2BF2956AF5CD38]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:159)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:144)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:139)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:861)
at 
org.apache.solr.cloud.hdfs.StressHdfsTest.createAndDeleteCollection(StressHdfsTest.java:159)
at 
org.apache.solr.cloud.hdfs.StressHdfsTest.test(StressHdfsTest.java:103)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java: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:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at