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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/952/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC

2 tests failed.
FAILED:  org.apache.solr.cloud.CustomCollectionTest.testRouteFieldForHashRouter

Error Message:
Collection not found: routeFieldColl

Stack Trace:
org.apache.solr.common.SolrException: Collection not found: routeFieldColl
at 
__randomizedtesting.SeedInfo.seed([649D45FD5E1A300A:CCABDB20C17BDB50]: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.testRouteFieldForHashRouter(CustomCollectionTest.java:166)
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 

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

[Policeman Jenkins Server]

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

7 tests failed.
FAILED:  org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test

Error Message:
Could not find collection:collection2

Stack Trace:
java.lang.AssertionError: Could not find collection:collection2
at 
__randomizedtesting.SeedInfo.seed([5567E7E82F16:DD33D207791442EE]: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:910)
at 
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.testIndexingBatchPerRequestWithHttpSolrClient(FullSolrCloudDistribCmdsTest.java:612)
at 
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test(FullSolrCloudDistribCmdsTest.java:152)
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 

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_131) - Build # 19921 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19921/
Java: 32bit/jdk1.8.0_131 -server -XX:+UseSerialGC

1 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.AutoScalingHandlerTest.testPolicyAndPreferences

Error Message:
Adding a policy with 'cores' attribute should not have succeeded.

Stack Trace:
java.lang.AssertionError: Adding a policy with 'cores' attribute should not 
have succeeded.
at 
__randomizedtesting.SeedInfo.seed([CCD3FF77EE788217:6D1BA15E973E8419]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.autoscaling.AutoScalingHandlerTest.testPolicyAndPreferences(AutoScalingHandlerTest.java:83)
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:748)




Build Log:
[...truncated 11435 lines...]
   [junit4] Suite: org.apache.solr.cloud.autoscaling.AutoScalingHandlerTest
   [junit4]   2> Creating dataDir: 

[jira] [Resolved] (SOLR-10923) AutoScalingHandlerTest.testPolicyAndPreferences() failure: Adding a policy with 'cores' attribute should not have succeeded

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat resolved SOLR-10923.
-
Resolution: Fixed

> AutoScalingHandlerTest.testPolicyAndPreferences() failure: Adding a policy 
> with 'cores' attribute should not have succeeded
> ---
>
> Key: SOLR-10923
> URL: https://issues.apache.org/jira/browse/SOLR-10923
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Cao Manh Dat
>
> Policeman Jenkins found a reproducing seed 
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19914]:
> {noformat}
> Checking out Revision b1b566f57bba46cadae33bc8198246fa05609287 
> (refs/remotes/origin/master)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=AutoScalingHandlerTest -Dtests.method=testPolicyAndPreferences 
> -Dtests.seed=DB220AFF163D3283 -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=to-TO -Dtests.timezone=America/Montserrat -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 0.01s J2 | 
> AutoScalingHandlerTest.testPolicyAndPreferences <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Adding a policy with 
> 'cores' attribute should not have succeeded.
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([DB220AFF163D3283:7AEA54D66F7B348D]:0)
>[junit4]>  at 
> org.apache.solr.cloud.autoscaling.AutoScalingHandlerTest.testPolicyAndPreferences(AutoScalingHandlerTest.java:83)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]>  at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]>  at 
> java.base/java.lang.reflect.Method.invoke(Method.java:564)
> [...]
>[junit4]   2> NOTE: test params are: codec=Lucene70, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=to-TO, 
> timezone=America/Montserrat
>[junit4]   2> NOTE: Linux 4.10.0-21-generic i386/Oracle Corporation 9-ea 
> (32-bit)/cpus=8,threads=1,free=151310248,total=411041792
> {noformat}
> Another reproducing seed 
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19916]:
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=AutoScalingHandlerTest -Dtests.method=testPolicyAndPreferences 
> -Dtests.seed=3D04238B59F9D32D -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=en-MW -Dtests.timezone=America/Recife -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 0.02s J2 | 
> AutoScalingHandlerTest.testPolicyAndPreferences <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Adding a policy with 
> 'cores' attribute should not have succeeded.
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([3D04238B59F9D32D:9CCC7DA220BFD523]:0)
>[junit4]>  at 
> org.apache.solr.cloud.autoscaling.AutoScalingHandlerTest.testPolicyAndPreferences(AutoScalingHandlerTest.java:83)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]>  at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]>  at 
> java.base/java.lang.reflect.Method.invoke(Method.java:564)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10923) AutoScalingHandlerTest.testPolicyAndPreferences() failure: Adding a policy with 'cores' attribute should not have succeeded

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10923:


Commit 2d26d7e8718960842125ba42e078612744ddaf90 in lucene-solr's branch 
refs/heads/master from [~caomanhdat]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2d26d7e ]

SOLR-10923: AutoScalingHandlerTest.testPolicyAndPreferences() failure: Adding a 
policy with 'cores' attribute should not have succeeded


> AutoScalingHandlerTest.testPolicyAndPreferences() failure: Adding a policy 
> with 'cores' attribute should not have succeeded
> ---
>
> Key: SOLR-10923
> URL: https://issues.apache.org/jira/browse/SOLR-10923
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Cao Manh Dat
>
> Policeman Jenkins found a reproducing seed 
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19914]:
> {noformat}
> Checking out Revision b1b566f57bba46cadae33bc8198246fa05609287 
> (refs/remotes/origin/master)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=AutoScalingHandlerTest -Dtests.method=testPolicyAndPreferences 
> -Dtests.seed=DB220AFF163D3283 -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=to-TO -Dtests.timezone=America/Montserrat -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 0.01s J2 | 
> AutoScalingHandlerTest.testPolicyAndPreferences <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Adding a policy with 
> 'cores' attribute should not have succeeded.
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([DB220AFF163D3283:7AEA54D66F7B348D]:0)
>[junit4]>  at 
> org.apache.solr.cloud.autoscaling.AutoScalingHandlerTest.testPolicyAndPreferences(AutoScalingHandlerTest.java:83)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]>  at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]>  at 
> java.base/java.lang.reflect.Method.invoke(Method.java:564)
> [...]
>[junit4]   2> NOTE: test params are: codec=Lucene70, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=to-TO, 
> timezone=America/Montserrat
>[junit4]   2> NOTE: Linux 4.10.0-21-generic i386/Oracle Corporation 9-ea 
> (32-bit)/cpus=8,threads=1,free=151310248,total=411041792
> {noformat}
> Another reproducing seed 
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19916]:
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=AutoScalingHandlerTest -Dtests.method=testPolicyAndPreferences 
> -Dtests.seed=3D04238B59F9D32D -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=en-MW -Dtests.timezone=America/Recife -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 0.02s J2 | 
> AutoScalingHandlerTest.testPolicyAndPreferences <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Adding a policy with 
> 'cores' attribute should not have succeeded.
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([3D04238B59F9D32D:9CCC7DA220BFD523]:0)
>[junit4]>  at 
> org.apache.solr.cloud.autoscaling.AutoScalingHandlerTest.testPolicyAndPreferences(AutoScalingHandlerTest.java:83)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]>  at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]>  at 
> java.base/java.lang.reflect.Method.invoke(Method.java:564)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS-EA] Lucene-Solr-6.x-Windows (32bit/jdk-9-ea+173) - Build # 988 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/988/
Java: 32bit/jdk-9-ea+173 -client -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.MissingSegmentRecoveryTest.testLeaderRecovery

Error Message:
Expected a collection with one shard and two replicas null Last available 
state: 
DocCollection(MissingSegmentRecoveryTest//collections/MissingSegmentRecoveryTest/state.json/6)={
   "replicationFactor":"2",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node1":{   "core":"MissingSegmentRecoveryTest_shard1_replica1",   
"base_url":"http://127.0.0.1:53861/solr;,   
"node_name":"127.0.0.1:53861_solr",   "state":"active",   
"leader":"true"}, "core_node2":{   
"core":"MissingSegmentRecoveryTest_shard1_replica2",   
"base_url":"http://127.0.0.1:53860/solr;,   
"node_name":"127.0.0.1:53860_solr",   "state":"down",   
"router":{"name":"compositeId"},   "maxShardsPerNode":"1",   
"autoAddReplicas":"false"}

Stack Trace:
java.lang.AssertionError: Expected a collection with one shard and two replicas
null
Last available state: 
DocCollection(MissingSegmentRecoveryTest//collections/MissingSegmentRecoveryTest/state.json/6)={
  "replicationFactor":"2",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node1":{
  "core":"MissingSegmentRecoveryTest_shard1_replica1",
  "base_url":"http://127.0.0.1:53861/solr;,
  "node_name":"127.0.0.1:53861_solr",
  "state":"active",
  "leader":"true"},
"core_node2":{
  "core":"MissingSegmentRecoveryTest_shard1_replica2",
  "base_url":"http://127.0.0.1:53860/solr;,
  "node_name":"127.0.0.1:53860_solr",
  "state":"down",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false"}
at 
__randomizedtesting.SeedInfo.seed([408007252BE207A4:10D59F2672C3B1B9]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:265)
at 
org.apache.solr.cloud.MissingSegmentRecoveryTest.testLeaderRecovery(MissingSegmentRecoveryTest.java:105)
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:564)
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 

[jira] [Assigned] (SOLR-10923) AutoScalingHandlerTest.testPolicyAndPreferences() failure: Adding a policy with 'cores' attribute should not have succeeded

[Hoss Man (JIRA)]

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

Hoss Man reassigned SOLR-10923:
---

Assignee: Cao Manh Dat

I havne't dug into the code, but based on the comments in SOLR-10406 it looks 
like that jira changed what/how errors are written to clients when using the V2 
API. -- and i'm guessing that this test has some explicit checks/assertions 
regarding the failure it expects when it tries to "add a policy with cores 
attribute" and probably randomizes if/when it uses the V2 API?

Dat - can you please investigate?



> AutoScalingHandlerTest.testPolicyAndPreferences() failure: Adding a policy 
> with 'cores' attribute should not have succeeded
> ---
>
> Key: SOLR-10923
> URL: https://issues.apache.org/jira/browse/SOLR-10923
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Cao Manh Dat
>
> Policeman Jenkins found a reproducing seed 
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19914]:
> {noformat}
> Checking out Revision b1b566f57bba46cadae33bc8198246fa05609287 
> (refs/remotes/origin/master)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=AutoScalingHandlerTest -Dtests.method=testPolicyAndPreferences 
> -Dtests.seed=DB220AFF163D3283 -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=to-TO -Dtests.timezone=America/Montserrat -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 0.01s J2 | 
> AutoScalingHandlerTest.testPolicyAndPreferences <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Adding a policy with 
> 'cores' attribute should not have succeeded.
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([DB220AFF163D3283:7AEA54D66F7B348D]:0)
>[junit4]>  at 
> org.apache.solr.cloud.autoscaling.AutoScalingHandlerTest.testPolicyAndPreferences(AutoScalingHandlerTest.java:83)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]>  at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]>  at 
> java.base/java.lang.reflect.Method.invoke(Method.java:564)
> [...]
>[junit4]   2> NOTE: test params are: codec=Lucene70, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=to-TO, 
> timezone=America/Montserrat
>[junit4]   2> NOTE: Linux 4.10.0-21-generic i386/Oracle Corporation 9-ea 
> (32-bit)/cpus=8,threads=1,free=151310248,total=411041792
> {noformat}
> Another reproducing seed 
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19916]:
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=AutoScalingHandlerTest -Dtests.method=testPolicyAndPreferences 
> -Dtests.seed=3D04238B59F9D32D -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=en-MW -Dtests.timezone=America/Recife -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 0.02s J2 | 
> AutoScalingHandlerTest.testPolicyAndPreferences <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Adding a policy with 
> 'cores' attribute should not have succeeded.
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([3D04238B59F9D32D:9CCC7DA220BFD523]:0)
>[junit4]>  at 
> org.apache.solr.cloud.autoscaling.AutoScalingHandlerTest.testPolicyAndPreferences(AutoScalingHandlerTest.java:83)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]>  at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]>  at 
> java.base/java.lang.reflect.Method.invoke(Method.java:564)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10406) v2 API error messages list the URL request path as /solr/____v2/... when the original path was /v2/...

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10406:
-

FYI: git bisect says the commit for this jira caused the test failures in 
SOLR-10923

> v2 API error messages list the URL request path as /solr/v2/... when the 
> original path was /v2/...
> --
>
> Key: SOLR-10406
> URL: https://issues.apache.org/jira/browse/SOLR-10406
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: v2 API
>Reporter: Steve Rowe
>Assignee: Cao Manh Dat
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: SOLR-10406.patch, SOLR-10406.patch
>
>
> E.g. attempting introspect on {{/v2/c/.system/blob}} will fail if the 
> {{.system}} collection has not yet been CREATE'd - after {{bin/solr start -e 
> cloud -noprompt}}:
> {noformat}
> $ curl "http://localhost:8983/v2/c/.system/blob/_introspect?indent=on;
> 
> 
> 
> Error 404 Not Found
> 
> HTTP ERROR 404
> Problem accessing /solr/v2/c/.system/blob/_introspect. Reason:
> Not Found
> 
> 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10923) AutoScalingHandlerTest.testPolicyAndPreferences() failure: Adding a policy with 'cores' attribute should not have succeeded

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10923:
-

FWIW...

{noformat}
$ git bisect start HEAD f1e2be64519a9ec815785b59e6187c3e99f7d998
$ git bisect run bash -c 'ant clean && cd solr/core && ant test  
-Dtestcase=AutoScalingHandlerTest -Dtests.seed=3D04238B59F9D32D'
...
b1b566f57bba46cadae33bc8198246fa05609287 is the first bad commit
commit b1b566f57bba46cadae33bc8198246fa05609287
Author: Cao Manh Dat 
Date:   Tue Jun 20 12:46:33 2017 +0700

SOLR-10406: v2 API error messages list the URL request path as 
/solr/v2/... when the original path was /v2/...

:04 04 ca5574b04f37b24c898d202b7b078d0a17b781b3 
e3cd48c9681af5718606d1d24657c083121d983b M  solr
bisect run success
{noformat}

> AutoScalingHandlerTest.testPolicyAndPreferences() failure: Adding a policy 
> with 'cores' attribute should not have succeeded
> ---
>
> Key: SOLR-10923
> URL: https://issues.apache.org/jira/browse/SOLR-10923
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>
> Policeman Jenkins found a reproducing seed 
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19914]:
> {noformat}
> Checking out Revision b1b566f57bba46cadae33bc8198246fa05609287 
> (refs/remotes/origin/master)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=AutoScalingHandlerTest -Dtests.method=testPolicyAndPreferences 
> -Dtests.seed=DB220AFF163D3283 -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=to-TO -Dtests.timezone=America/Montserrat -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 0.01s J2 | 
> AutoScalingHandlerTest.testPolicyAndPreferences <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Adding a policy with 
> 'cores' attribute should not have succeeded.
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([DB220AFF163D3283:7AEA54D66F7B348D]:0)
>[junit4]>  at 
> org.apache.solr.cloud.autoscaling.AutoScalingHandlerTest.testPolicyAndPreferences(AutoScalingHandlerTest.java:83)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]>  at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]>  at 
> java.base/java.lang.reflect.Method.invoke(Method.java:564)
> [...]
>[junit4]   2> NOTE: test params are: codec=Lucene70, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=to-TO, 
> timezone=America/Montserrat
>[junit4]   2> NOTE: Linux 4.10.0-21-generic i386/Oracle Corporation 9-ea 
> (32-bit)/cpus=8,threads=1,free=151310248,total=411041792
> {noformat}
> Another reproducing seed 
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19916]:
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=AutoScalingHandlerTest -Dtests.method=testPolicyAndPreferences 
> -Dtests.seed=3D04238B59F9D32D -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=en-MW -Dtests.timezone=America/Recife -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 0.02s J2 | 
> AutoScalingHandlerTest.testPolicyAndPreferences <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Adding a policy with 
> 'cores' attribute should not have succeeded.
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([3D04238B59F9D32D:9CCC7DA220BFD523]:0)
>[junit4]>  at 
> org.apache.solr.cloud.autoscaling.AutoScalingHandlerTest.testPolicyAndPreferences(AutoScalingHandlerTest.java:83)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]>  at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]>  at 
> java.base/java.lang.reflect.Method.invoke(Method.java:564)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

DataImportHandler - Delta Import

[Roopesh Uniyal]

Hello,

I am running *Solr 3.5* and using Data Import Handler. I am using the
following query -



Although the FULL Import is running fine but the delta import is having
trouble. Here is what I am experiencing -

1.   Delta Imports are working in cumulative fashion - any increment
(delta) is the cumulative from the point last FULL import was taken.

2.   Delta Import is running for only records that have been added (New
Inserted) and *not* updated (Metadata Changes to the records indexed during
FULL Import).
Will appreciate your inputs to fix these two issues.

Thanks!

Re: SolrException: Error trying to proxy request for url: solr/sync-status/admin/system

[S G]

Got no response on the solr-user mailing list and so trying the dev-mailing
list.

Please guide me if this should not be done. But I thought that the issue
looks strange enough to post it here.

Thanks
SG


On Mon, Jun 19, 2017 at 8:13 PM, S G  wrote:

> Hi,
>
> We are stuck in a strange problem.
> Whole cluster is red. All nodes are being shown as down.
> Restart of the nodes is not helping either.
>
> All our nodes seem to have gone into a distributed lock.
> Here is the grep command I ran on all the solr.log files:
>
> grep "Error trying to proxy request" $f | cut -d" " -f14 | sort | uniq
> -c
> And the output from 10 different solr-nodes' solr.log file is shown below:
> (Basically each node is calling admin/system on other nodes and throwing
> exceptions. You can see number of exceptions thrown by each server for
> every other server).
>
>
>
> SVR_1.log
>   13 http://SVR_2:8983/solr/my-collection/admin/system
>   18 http://SVR_3:8983/solr/my-collection/admin/system
>   19 http://SVR_4:8983/solr/my-collection/admin/system
>   15 http://SVR_6:8983/solr/my-collection/admin/system
>   13 http://SVR_7:8983/solr/my-collection/admin/system
>   13 http://SVR_9:8983/solr/my-collection/admin/system
>
> SVR_2.log
>  335 http://SVR_3:8983/solr/my-collection/admin/system
>   23 http://SVR_4:8983/solr/my-collection/admin/system
>   21 http://SVR_6:8983/solr/my-collection/admin/system
>   23 http://SVR_7:8983/solr/my-collection/admin/system
>   23 http://SVR_9:8983/solr/my-collection/admin/system
>
> SVR_3.log
>   24 http://SVR_2:8983/solr/my-collection/admin/system
>   14 http://SVR_4:8983/solr/my-collection/admin/system
>   13 http://SVR_6:8983/solr/my-collection/admin/system
>   14 http://SVR_7:8983/solr/my-collection/admin/system
>   16 http://SVR_9:8983/solr/my-collection/admin/system
>
> SVR_4.log
>   11 http://SVR_2:8983/solr/my-collection/admin/system
>   29 http://SVR_3:8983/solr/my-collection/admin/system
>7 http://SVR_6:8983/solr/my-collection/admin/system
>   16 http://SVR_7:8983/solr/my-collection/admin/system
>   11 http://SVR_9:8983/solr/my-collection/admin/system
>
> SVR_5.log
>   18 http://SVR_2:8983/solr/my-collection/admin/system
>   16 http://SVR_3:8983/solr/my-collection/admin/system
>   13 http://SVR_4:8983/solr/my-collection/admin/system
>   12 http://SVR_6:8983/solr/my-collection/admin/system
>   16 http://SVR_7:8983/solr/my-collection/admin/system
>   11 http://SVR_9:8983/solr/my-collection/admin/system
>
> SVR_6.log
>   44 http://SVR_2:8983/solr/my-collection/admin/system
>  296 http://SVR_3:8983/solr/my-collection/admin/system
>   40 http://SVR_4:8983/solr/my-collection/admin/system
>   15 http://SVR_7:8983/solr/my-collection/admin/system
>   15 http://SVR_9:8983/solr/my-collection/admin/system
>
> SVR_7.log
>   59 http://SVR_2:8983/solr/my-collection/admin/system
>  215 http://SVR_3:8983/solr/my-collection/admin/system
>   62 http://SVR_4:8983/solr/my-collection/admin/system
>   47 http://SVR_6:8983/solr/my-collection/admin/system
>   61 http://SVR_9:8983/solr/my-collection/admin/system
>
> SVR_8.log
>   13 http://SVR_2:8983/solr/my-collection/admin/system
>   18 http://SVR_3:8983/solr/my-collection/admin/system
>   10 http://SVR_4:8983/solr/my-collection/admin/system
>7 http://SVR_6:8983/solr/my-collection/admin/system
>   12 http://SVR_7:8983/solr/my-collection/admin/system
>   13 http://SVR_9:8983/solr/my-collection/admin/system
>
> SVR_9.log
>   38 http://SVR_2:8983/solr/my-collection/admin/system
>  229 http://SVR_3:8983/solr/my-collection/admin/system
>   15 http://SVR_4:8983/solr/my-collection/admin/system
>   22 http://SVR_6:8983/solr/my-collection/admin/system
>   26 http://SVR_7:8983/solr/my-collection/admin/system
>
> SVR_10.log
>9 http://SVR_2:8983/solr/my-collection/admin/system
>   22 http://SVR_3:8983/solr/my-collection/admin/system
>   18 http://SVR_4:8983/solr/my-collection/admin/system
>   14 http://SVR_6:8983/solr/my-collection/admin/system
>   18 http://SVR_7:8983/solr/my-collection/admin/system
>   10 http://SVR_9:8983/solr/my-collection/admin/system
>
>
> Thanks
> SG
>

[jira] [Updated] (SOLR-10864) Add static (test only) boolean to PointField indicating 'precisionStep' should be ignored so we can simplify points randomization in our schemas

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-10864:

Attachment: SOLR-10864.patch

bq. Still one nocommit in there to work around SOLR-10929, ...

Bah! ... 2 patches agao i had a perfectly good workaround for this issue, but I 
"simplified" it in the last patch and broke BadIndexSchemaTest.

Update patch fixes my stupidity.

> Add static (test only) boolean to PointField indicating 'precisionStep' 
> should be ignored so we can simplify points randomization in our schemas
> 
>
> Key: SOLR-10864
> URL: https://issues.apache.org/jira/browse/SOLR-10864
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: master (7.0)
>
> Attachments: SOLR-10864.patch, SOLR-10864.patch, SOLR-10864.patch, 
> SOLR-10864.patch
>
>
> (I'm spinning this idea out of parent jira SOLR-10807 so that it gets it's 
> own jira# w/ it's own summary for increased visibility/comments)
> In the interest of making it easier & more straight forward to get good 
> randomized test coverage of Points fields, I'd like to add the following to 
> the {{PointField}} class...
> {code}
>  /**
>   * 
>   * The Test framework can set this global variable to instruct PointField 
> that
>   * (on init) it should be tollerant of the precisionStep 
> argument used by TrieFields.
>   * This allows for simple randomization of TrieFields and PointFields w/o 
> extensive duplication
>   * of fieldType/ declarations.
>   * 
>   *
>   * NOTE: When {@link TrieField} is removed, this boolean must also be 
> removed
>   *
>   * @lucene.internal
>   * @lucene.experimental
>   */
>  public static boolean TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS = false;
>  /** 
>   * NOTE: This method can be removed completely when
>   * {@link #TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS} is removed 
>   */
>  @Override
>  protected void init(IndexSchema schema, Map args) {
>super.init(schema, args);
>if (TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS) {
>  args.remove("precisionStep");
>}
>  }
> {code}
> Then in SolrTestCaseJ4, set 
> {{PointField.TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS}} on a class by class 
> basis when randomizing Trie/Points (and unset \@AfterClass).
> (details to follow in comment)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_131) - Build # 6666 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows//
Java: 32bit/jdk1.8.0_131 -client -XX:+UseG1GC

2 tests failed.
FAILED:  org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDocAbsent

Error Message:
Did not find the expected number of groups for field intGSF expected:<4> but 
was:<3>

Stack Trace:
java.lang.AssertionError: Did not find the expected number of groups for field 
intGSF expected:<4> but was:<3>
at 
__randomizedtesting.SeedInfo.seed([2A5FE275F7553291:F4E839FD12047254]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDocAbsent(DocValuesNotIndexedTest.java:304)
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:748)


FAILED:  

[jira] [Updated] (SOLR-10864) Add static (test only) boolean to PointField indicating 'precisionStep' should be ignored so we can simplify points randomization in our schemas

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-10864:

Attachment: SOLR-10864.patch


Ok, here's what i've got.

Been hammering on the tests, I think I've got all the changes needed to account 
for both the randomized points and randomized docvalues. (but i also just 
updated to current master, so maybe i missed something)

Still one nocommit in there to work around SOLR-10929, but I'm going to tackle 
that next ... then fix the inevitable unused imports and hopefully commit to 
master soon (tomorow maybe?)


> Add static (test only) boolean to PointField indicating 'precisionStep' 
> should be ignored so we can simplify points randomization in our schemas
> 
>
> Key: SOLR-10864
> URL: https://issues.apache.org/jira/browse/SOLR-10864
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: master (7.0)
>
> Attachments: SOLR-10864.patch, SOLR-10864.patch, SOLR-10864.patch
>
>
> (I'm spinning this idea out of parent jira SOLR-10807 so that it gets it's 
> own jira# w/ it's own summary for increased visibility/comments)
> In the interest of making it easier & more straight forward to get good 
> randomized test coverage of Points fields, I'd like to add the following to 
> the {{PointField}} class...
> {code}
>  /**
>   * 
>   * The Test framework can set this global variable to instruct PointField 
> that
>   * (on init) it should be tollerant of the precisionStep 
> argument used by TrieFields.
>   * This allows for simple randomization of TrieFields and PointFields w/o 
> extensive duplication
>   * of fieldType/ declarations.
>   * 
>   *
>   * NOTE: When {@link TrieField} is removed, this boolean must also be 
> removed
>   *
>   * @lucene.internal
>   * @lucene.experimental
>   */
>  public static boolean TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS = false;
>  /** 
>   * NOTE: This method can be removed completely when
>   * {@link #TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS} is removed 
>   */
>  @Override
>  protected void init(IndexSchema schema, Map args) {
>super.init(schema, args);
>if (TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS) {
>  args.remove("precisionStep");
>}
>  }
> {code}
> Then in SolrTestCaseJ4, set 
> {{PointField.TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS}} on a class by class 
> basis when randomizing Trie/Points (and unset \@AfterClass).
> (details to follow in comment)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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 # 1886 - Still Unstable

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.AutoScalingHandlerTest.testPolicyAndPreferences

Error Message:
Adding a policy with 'cores' attribute should not have succeeded.

Stack Trace:
java.lang.AssertionError: Adding a policy with 'cores' attribute should not 
have succeeded.
at 
__randomizedtesting.SeedInfo.seed([B7F7EB47CDFAAA31:163FB56EB4BCAC3F]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.autoscaling.AutoScalingHandlerTest.testPolicyAndPreferences(AutoScalingHandlerTest.java:83)
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:748)




Build Log:
[...truncated 11883 lines...]
   [junit4] Suite: org.apache.solr.cloud.autoscaling.AutoScalingHandlerTest
   [junit4]   2> Creating dataDir: 

[jira] [Created] (SOLR-10929) remove useless valType from ExternalFileField

[Hoss Man (JIRA)]

Hoss Man created SOLR-10929:
---

 Summary: remove useless valType from ExternalFileField
 Key: SOLR-10929
 URL: https://issues.apache.org/jira/browse/SOLR-10929
 Project: Solr
  Issue Type: Sub-task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man
Assignee: Hoss Man


{{valType}} has always been a useless prop on ExternalFileField. 

SOLR-2971 made it optional, but if specified it must be a TrieFloatField or 
else there is a failure.

We should just eliminate it completely in 7.0



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10928) Support elevate.q in QueryElevationComponent

[jefferyyuan (JIRA)]

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

jefferyyuan updated SOLR-10928:
---
Summary: Support elevate.q in QueryElevationComponent  (was: Support 
elevate.q () in QueryElevationComponent)

> Support elevate.q in QueryElevationComponent
> 
>
> Key: SOLR-10928
> URL: https://issues.apache.org/jira/browse/SOLR-10928
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SearchComponents - other
>Reporter: jefferyyuan
>Priority: Critical
> Fix For: 6.6.1
>
>
> QueryElevationComponent uses the query in parameter to match the elevate.xml.
> "query text" from elevate.xml 
> : has to match the query (q=...). So in this case, elevation works only for 
> : http://localhost:8080/solr/elevate?q=brain, but not for 
> : http://localhost:8080/solr/elevate?q=indexingabstract:brain type of 
> queries. 
> But sometimes, the query is more complex, we may use some nested query or 
> complexphrase.
> it would also be fairly easy to make QEC support an "elevate.q"  param 
> similar to how there is a "spellcheck.q" param and a "hl.q" param to  let the 
> client specify an alternate, simplified, string for the feature to  use.
> Conten copied from:
> http://lucene.472066.n3.nabble.com/Problems-with-elevation-component-configuration-td3993204.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-10928) Support elevate.q () in QueryElevationComponent

[jefferyyuan (JIRA)]

jefferyyuan created SOLR-10928:
--

 Summary: Support elevate.q () in QueryElevationComponent
 Key: SOLR-10928
 URL: https://issues.apache.org/jira/browse/SOLR-10928
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SearchComponents - other
Reporter: jefferyyuan
Priority: Critical
 Fix For: 6.6.1


QueryElevationComponent uses the query in parameter to match the elevate.xml.

"query text" from elevate.xml 
: has to match the query (q=...). So in this case, elevation works only for 
: http://localhost:8080/solr/elevate?q=brain, but not for 
: http://localhost:8080/solr/elevate?q=indexingabstract:brain type of queries. 

But sometimes, the query is more complex, we may use some nested query or 
complexphrase.

it would also be fairly easy to make QEC support an "elevate.q"  param similar 
to how there is a "spellcheck.q" param and a "hl.q" param to  let the client 
specify an alternate, simplified, string for the feature to  use.

Conten copied from:
http://lucene.472066.n3.nabble.com/Problems-with-elevation-component-configuration-td3993204.html




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10922) NPE in PeerSync

[Pushkar Raste (JIRA)]

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

Pushkar Raste commented on SOLR-10922:
--

Is this duplicate of SOLR-9915 ?

> NPE in PeerSync
> ---
>
> Key: SOLR-10922
> URL: https://issues.apache.org/jira/browse/SOLR-10922
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: Markus Jelsma
>Priority: Minor
> Fix For: master (7.0)
>
>
> {code}
> Error while trying to recover. 
> core=search_shard2_replica2:java.lang.NullPointerException
>   at org.apache.solr.update.PeerSync.alreadyInSync(PeerSync.java:381)
>   at org.apache.solr.update.PeerSync.sync(PeerSync.java:251)
>   at 
> org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:439)
>   at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:284)
>   at 
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10169) PeerSync will hit an NPE on no response errors when looking for fingerprint.

[Pushkar Raste (JIRA)]

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

Pushkar Raste commented on SOLR-10169:
--

Is this duplicate of SOLR-9915

> PeerSync will hit an NPE on no response errors when looking for fingerprint.
> 
>
> Key: SOLR-10169
> URL: https://issues.apache.org/jira/browse/SOLR-10169
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10574) Choose a default configset for Solr 7

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10574:


Commit 1a58412e4ac9ff85f82696da8f3b0597ca45617e in lucene-solr's branch 
refs/heads/master from [~ichattopadhyaya]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1a58412 ]

SOLR-10574: Reverting previous commits to tackle test failues


> Choose a default configset for Solr 7
> -
>
> Key: SOLR-10574
> URL: https://issues.apache.org/jira/browse/SOLR-10574
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10574.patch, SOLR-10574.patch, SOLR-10574.patch, 
> SOLR-10574.patch
>
>
> Currently, the data_driven_schema_configs is the default configset when 
> collections are created using the bin/solr script and no configset is 
> specified.
> However, that may not be the best choice. We need to decide which is the best 
> choice, out of the box, considering many users might create collections 
> without knowing about the concept of a configset going forward.
> (See also SOLR-10272)
> Proposed changes:
> # Remove data_driven_schema_configs and basic_configs
> # Introduce a combined configset, {{_default}} based on the above two 
> configsets.
> # Build a "toggleable" data driven functionality into {{_default}}
> Usage:
> # Create a collection (using _default configset)
> # Data driven / schemaless functionality is enabled by default; so just start 
> indexing your documents.
> # If don't want data driven / schemaless, disable this behaviour: {code}
> curl http://host:8983/solr/coll1/config -d '{"set-user-property": 
> {"update.autoCreateFields":"false"}}'
> {code}
> # Create schema fields using schema API, and index documents



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10574) Choose a default configset for Solr 7

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-10574:
-

Thanks, Steve, Jan, Cassandra. I'll take a look at the tests and the numeric 
types right away.

> Choose a default configset for Solr 7
> -
>
> Key: SOLR-10574
> URL: https://issues.apache.org/jira/browse/SOLR-10574
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10574.patch, SOLR-10574.patch, SOLR-10574.patch, 
> SOLR-10574.patch
>
>
> Currently, the data_driven_schema_configs is the default configset when 
> collections are created using the bin/solr script and no configset is 
> specified.
> However, that may not be the best choice. We need to decide which is the best 
> choice, out of the box, considering many users might create collections 
> without knowing about the concept of a configset going forward.
> (See also SOLR-10272)
> Proposed changes:
> # Remove data_driven_schema_configs and basic_configs
> # Introduce a combined configset, {{_default}} based on the above two 
> configsets.
> # Build a "toggleable" data driven functionality into {{_default}}
> Usage:
> # Create a collection (using _default configset)
> # Data driven / schemaless functionality is enabled by default; so just start 
> indexing your documents.
> # If don't want data driven / schemaless, disable this behaviour: {code}
> curl http://host:8983/solr/coll1/config -d '{"set-user-property": 
> {"update.autoCreateFields":"false"}}'
> {code}
> # Create schema fields using schema API, and index documents



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7882) Maybe expression compiler should cache recently compiled expressions?

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7882:
-

I know i have benchmarked that its definitely slower not to reuse. But 
compiling a new one per-query was not that much overhead with lower concurrency 
and tests did not run as long as yours.

Each one gets its own loader for the reason it can be GC'ed properly (you can 
test that this works). But i am not sure that java land is the issue. Maybe you 
just have codecache scanning/sweeping during a safepoint and thats how it 
looks?  Or maybe its related to class dictionaries and stuff in the JDK, i dont 
know.

Maybe run with some improved debugging such as a better profiler, enable 
compilation log, look at codecache stats (they are at least in JMX), etc. Maybe 
try disabling inlining (at least for expression evaluation) to hope for a 
better stacktrace. 

I know this stuff is a PITA but it would be good to understand before adding a 
cache (as it would then hang onto cached classes and maybe have other 
downsides/user annoyances related to that).

> Maybe expression compiler should cache recently compiled expressions?
> -
>
> Key: LUCENE-7882
> URL: https://issues.apache.org/jira/browse/LUCENE-7882
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/expressions
>Reporter: Michael McCandless
>
> I've been running search performance tests using a simple expression 
> ({{_score + ln(1000+unit_sales)}}) for sorting and hit this odd bottleneck:
> {noformat}
> "pool-1-thread-30" #70 prio=5 os_prio=0 tid=0x7eea7000a000 nid=0x1ea8a 
> waiting for monitor entry [0x7eea867dd000]
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at 
> org.apache.lucene.expressions.js.JavascriptCompiler$CompiledExpression.evaluate(_score
>  + ln(1000+unit_sales))
>   at 
> org.apache.lucene.expressions.ExpressionFunctionValues.doubleValue(ExpressionFunctionValues.java:49)
>   at 
> com.amazon.lucene.OrderedVELeafCollector.collectInternal(OrderedVELeafCollector.java:123)
>   at 
> com.amazon.lucene.OrderedVELeafCollector.collect(OrderedVELeafCollector.java:108)
>   at 
> org.apache.lucene.search.MultiCollectorManager$Collectors$LeafCollectors.collect(MultiCollectorManager.java:102)
>   at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:241)
>   at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:184)
>   at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:658)
>   at org.apache.lucene.search.IndexSearcher$5.call(IndexSearcher.java:600)
>   at org.apache.lucene.search.IndexSearcher$5.call(IndexSearcher.java:597)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> I couldn't see any {{synchronized}} in the sources here, so I'm not sure 
> which object monitor it's blocked on.
> I was accidentally compiling a new expression for every query, and that 
> bottleneck would cause overall QPS to slow down drastically (~4X slower after 
> ~1 hour of redline tests), as if the JVM is getting slower and slower to 
> evaluate each expression the more expressions I had compiled.
> I tested JDK 9-ea and it also kept slowing down over time as the performance 
> test ran.
> Maybe we should put a small cache in front of the expressions compiler to 
> make it less trappy?  Or maybe we can get to the root cause of why the JVM 
> slows down more and more, the more expressions you compile?
> I won't have time to work on this in the near future so if anyone else feels 
> the itch, please scratch it!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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_131) - Build # 19919 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19919/
Java: 64bit/jdk1.8.0_131 -XX:-UseCompressedOops -XX:+UseParallelGC

4 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.SolrSchemalessExampleTest

Error Message:
Source 
'/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/server/solr/configsets/data_driven_schema_configs/conf'
 does not exist

Stack Trace:
java.io.FileNotFoundException: Source 
'/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/server/solr/configsets/data_driven_schema_configs/conf'
 does not exist
at __randomizedtesting.SeedInfo.seed([22DF99456B929F04]:0)
at 
org.apache.commons.io.FileUtils.checkFileRequirements(FileUtils.java:1405)
at org.apache.commons.io.FileUtils.copyDirectory(FileUtils.java:1368)
at org.apache.commons.io.FileUtils.copyDirectory(FileUtils.java:1268)
at 
org.apache.commons.io.FileUtils.copyDirectoryToDirectory(FileUtils.java:1209)
at 
org.apache.solr.client.solrj.SolrSchemalessExampleTest.beforeClass(SolrSchemalessExampleTest.java:54)
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$6.evaluate(RandomizedRunner.java:847)
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:748)


FAILED:  
org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection

Error Message:
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/server/solr/configsets/data_driven_schema_configs/conf
 not found!

Stack Trace:
java.lang.AssertionError: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/server/solr/configsets/data_driven_schema_configs/conf
 not found!
at 
__randomizedtesting.SeedInfo.seed([18F6FDC9C2A52F0:12EC5DB3AD45EB56]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection(SolrCloudExampleTest.java:77)
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 

[jira] [Commented] (SOLR-10915) Make SolrClient classes extendable without code duplication

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-10915:
-

There's existing constructors that were released in 6.6, which need to be 
handled and either removed, or deprecated with our move to the single format 
constructor for SolrClients. 

[~gerlowskija], [~elyograg], and I had a discussion on irc and decided that we 
shouldn't be going crazy with the code removal, and instead should just happily 
deprecate stuff. It does mean working around with the current code and leaving 
it unclean but considering this is publicly released code, it doesn't make 
sense to just remove it.

Here's the approach that Jason suggested, which I think makes sense to handle 
existing constructors. This routes everything through the new Builder 
implementation.

{code:java}
public HttpSolrClient(String url, ResponseParser parser, Foo foo, Bar bar) {
final HttpSolrClient.Builder builder = new 
HttpSolrClient.Builder(url).withResponseParser(parser).withFoo(foo)...;
this(builder);
}

public HttpSolrClient(Builder builder) {
  /* actual constructor implementation/logic */
}
{code}

> Make SolrClient classes extendable without code duplication
> ---
>
> Key: SOLR-10915
> URL: https://issues.apache.org/jira/browse/SOLR-10915
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: clients - java
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10915.patch.with-deprecations, 
> SOLR-10915.patch.without-deprecations
>
>
> SolrClient used to be easily extendable but our move to Builder pattern has 
> made it impossible to extend those classes without code duplication. 
> As an example, if we wanted to extend HttpSolrClient we would also want to 
> extend the Builder. The problem is that the constructor of the main class, 
> does not accept the builder object but explicit parameters, and the inherited 
> class doesn't have access to any of those values from the Builder object as 
> they are all private. 
> Generally, we'd want to have the client object constructor accept the 
> Builder, instead of explicit values, and also make the Builder values 
> protected so the inherited classes could use them.
> I'm marking this as a blocker for 7.0 as this is an important piece that 
> needs to be fixed before the major release, specially now that we know that 
> this problem exists.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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 # 1885 - Still Unstable

[Apache Jenkins Server]

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

4 tests failed.
FAILED:  
org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection

Error Message:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/server/solr/configsets/data_driven_schema_configs/conf
 not found!

Stack Trace:
java.lang.AssertionError: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/server/solr/configsets/data_driven_schema_configs/conf
 not found!
at 
__randomizedtesting.SeedInfo.seed([903B7AFD170613EF:835848922669AA49]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection(SolrCloudExampleTest.java:77)
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 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

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

[Policeman Jenkins Server]

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

5 tests failed.
FAILED:  
org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection

Error Message:
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/server/solr/configsets/data_driven_schema_configs/conf
 not found!

Stack Trace:
java.lang.AssertionError: 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/server/solr/configsets/data_driven_schema_configs/conf
 not found!
at 
__randomizedtesting.SeedInfo.seed([DF796E02442B4FB9:CC1A5C6D7544F61F]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection(SolrCloudExampleTest.java:77)
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 
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 

[jira] [Updated] (SOLR-10921) Make boolean query clause limit configurable per-query

[Yonik Seeley (JIRA)]

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

Yonik Seeley updated SOLR-10921:

Attachment: SOLR-10921.patch

Here's a draft / in-progress patch showing the current approach.  Needs more 
changes and tests.

> Make boolean query clause limit configurable per-query
> --
>
> Key: SOLR-10921
> URL: https://issues.apache.org/jira/browse/SOLR-10921
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Yonik Seeley
> Fix For: master (7.0)
>
> Attachments: SOLR-10921.patch
>
>
> This is the Solr version of LUCENE-7880
> Background: The removal of the arbitrary maxBooleanClauses has been blocked 
> in SOLR-4586, and there were objections to adding the ability to override 
> maxBooleanClauses at the Lucene level in LUCENE-7880.
> That leaves us with this last option of implementing the check in solr by 
> raising the lucene limit and then using the maxBooleanClauses from 
> solrconfig.xml to throw an exception when the limit is exceeded.  Solr 
> QParsers have access to the request object, which knows the 
> schema/core/config.  This should fix the last-core-wins behavior due to the 
> lucene limit being a static.
> Although this enables controlling the limit on a per-query basis, this issue 
> is not about adding any user API to do so.  The capability will only be used 
> to make the current Solr maxBooleanClauses setting truly per-solr-core rather 
> than last-core-wins.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7882) Maybe expression compiler should cache recently compiled expressions?

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7882:


That's a great question [~dawid.weiss]; I don't know the answer.  Maybe 
[~jdconradson] or [~rcmuir] knows?

> Maybe expression compiler should cache recently compiled expressions?
> -
>
> Key: LUCENE-7882
> URL: https://issues.apache.org/jira/browse/LUCENE-7882
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/expressions
>Reporter: Michael McCandless
>
> I've been running search performance tests using a simple expression 
> ({{_score + ln(1000+unit_sales)}}) for sorting and hit this odd bottleneck:
> {noformat}
> "pool-1-thread-30" #70 prio=5 os_prio=0 tid=0x7eea7000a000 nid=0x1ea8a 
> waiting for monitor entry [0x7eea867dd000]
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at 
> org.apache.lucene.expressions.js.JavascriptCompiler$CompiledExpression.evaluate(_score
>  + ln(1000+unit_sales))
>   at 
> org.apache.lucene.expressions.ExpressionFunctionValues.doubleValue(ExpressionFunctionValues.java:49)
>   at 
> com.amazon.lucene.OrderedVELeafCollector.collectInternal(OrderedVELeafCollector.java:123)
>   at 
> com.amazon.lucene.OrderedVELeafCollector.collect(OrderedVELeafCollector.java:108)
>   at 
> org.apache.lucene.search.MultiCollectorManager$Collectors$LeafCollectors.collect(MultiCollectorManager.java:102)
>   at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:241)
>   at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:184)
>   at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:658)
>   at org.apache.lucene.search.IndexSearcher$5.call(IndexSearcher.java:600)
>   at org.apache.lucene.search.IndexSearcher$5.call(IndexSearcher.java:597)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> I couldn't see any {{synchronized}} in the sources here, so I'm not sure 
> which object monitor it's blocked on.
> I was accidentally compiling a new expression for every query, and that 
> bottleneck would cause overall QPS to slow down drastically (~4X slower after 
> ~1 hour of redline tests), as if the JVM is getting slower and slower to 
> evaluate each expression the more expressions I had compiled.
> I tested JDK 9-ea and it also kept slowing down over time as the performance 
> test ran.
> Maybe we should put a small cache in front of the expressions compiler to 
> make it less trappy?  Or maybe we can get to the root cause of why the JVM 
> slows down more and more, the more expressions you compile?
> I won't have time to work on this in the near future so if anyone else feels 
> the itch, please scratch it!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (LUCENE-7883) Remove references to Thread#getContextClassLoader() from Lucene/Solr codebase

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated LUCENE-7883:
--
Attachment: LUCENE-7883.patch

Patch removing context classloader usage. Tests seem to pass, unfortunately 
Solr trunk is very unstable. Some unrelated tests also fail on Jenkins, so I 
cannot be sure all is fine.

This patch also adds context class loaders on te forbidden api list. Because of 
that I used the {{withContextClassLoader(ClassLoader, () -> \{ ... \})}} lambda 
method.

> Remove references to Thread#getContextClassLoader() from Lucene/Solr codebase
> -
>
> Key: LUCENE-7883
> URL: https://issues.apache.org/jira/browse/LUCENE-7883
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
> Fix For: master (7.0)
>
> Attachments: LUCENE-7883.patch
>
>
> As discussed in LUCENE-7873, the use of 
> {{Thread.currentThread().getContextClassLoader()}} is in most cases a bug 
> caused by sloppy usage of ClassLoader APIs and should be replaced by 
> {{getClass().getClassLoader()}}.
> In Lucene we only have the ClassPathResourceLoader, but this one can be 
> solved by removing the "default" constructor. It only affects CustomAnalyzer, 
> that should also be extended in Lucene 7.
> The uses in Solr and its test are all to be replaced by 
> {{getClass().getClassLoader()}} (except some workaround with clustering using 
> a try-finally). This is in most cases historical code, when Solr was a web 
> application to workaround some buggy webapp containers. In the current state, 
> the code is "just wrong".
> Finally, we should add {{java.lang.Thread#getContextClassLoader()}} to 
> forbidden-apis.
> I'd like to get this into Lucene 7, as it affects some APIs in Lucene.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10915) Make SolrClient classes extendable without code duplication

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-10915:
-

[~gerlowskija] one more thing, can you have the extension of the patch be 
{{.patch}} so my browser doesn't auto-download the file? 

> Make SolrClient classes extendable without code duplication
> ---
>
> Key: SOLR-10915
> URL: https://issues.apache.org/jira/browse/SOLR-10915
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: clients - java
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10915.patch.with-deprecations, 
> SOLR-10915.patch.without-deprecations
>
>
> SolrClient used to be easily extendable but our move to Builder pattern has 
> made it impossible to extend those classes without code duplication. 
> As an example, if we wanted to extend HttpSolrClient we would also want to 
> extend the Builder. The problem is that the constructor of the main class, 
> does not accept the builder object but explicit parameters, and the inherited 
> class doesn't have access to any of those values from the Builder object as 
> they are all private. 
> Generally, we'd want to have the client object constructor accept the 
> Builder, instead of explicit values, and also make the Builder values 
> protected so the inherited classes could use them.
> I'm marking this as a blocker for 7.0 as this is an important piece that 
> needs to be fixed before the major release, specially now that we know that 
> this problem exists.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-4319) New atomic update operation: AddToSet

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-4319:


This issue would probably be solved with docValues=true stored=false.  The app 
I'm using at the moment is back on 4.10.4 though and I don't believe this works 
(though I didn't check to be fair).

> New atomic update operation: AddToSet
> -
>
> Key: SOLR-4319
> URL: https://issues.apache.org/jira/browse/SOLR-4319
> Project: Solr
>  Issue Type: Wish
>  Components: Schema and Analysis
>Reporter: Mikael Koskinen
>  Labels: atomic
>
> Currently Solr supports the following atomic operations:
> add, set, inc
> It would be great to have operation "addToSet". This would be useful in 
> situations where a document has a multivalued field (like category) and I 
> want to add a new value to list if it doesn't already exists. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (LUCENE-7884) StringHelper needs to catch NoClassDefFoundError

[Yan Zhao (JIRA)]

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

Yan Zhao updated LUCENE-7884:
-
Labels: easyfix newbie newdev patch  (was: easyfix newbie patch)

> StringHelper needs to catch NoClassDefFoundError
> 
>
> Key: LUCENE-7884
> URL: https://issues.apache.org/jira/browse/LUCENE-7884
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/other
>Affects Versions: 5.x, 6.x, 6.5.1
> Environment: Google App Engine: https://cloud.google.com/appengine/
>Reporter: Yan Zhao
>Priority: Minor
>  Labels: easyfix, newbie, newdev, patch
> Attachments: LUCENE-7884.patch
>
>
> h3. Problem:
> As shown 
> [here|https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/util/StringHelper.java#L252-L255],
>  StringHelpers currently use *Paths* to generate random and catch *Exception* 
> when resources are unavailable.
> However, in some platform, calling *Paths* will result *NoClassDefFoundError* 
> which is not handled by catching *Exception*.
> h3. Change:
> Change to catch **Throwable** instead.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10494) Switch Solr's Default Response Type from XML to JSON

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-10494:
--

Is it? Damn it. We need How To Contribute docs that don't assume every task is 
2nd nature to everyone at all times.

Second try attached. If it's still wrong I don't know what to do.

> Switch Solr's Default Response Type from XML to JSON
> 
>
> Key: SOLR-10494
> URL: https://issues.apache.org/jira/browse/SOLR-10494
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (7.0)
>Reporter: Trey Grainger
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: SOLR-10494, SOLR-10494, SOLR-10494-withdocs.patch, 
> SOLR-10494-withdocs.patch
>
>
> Solr's default response format is still XML, despite the fact that Solr has 
> supported the JSON response format for over a decade, developer mindshare has 
> clearly shifted toward JSON over the years, and most modern/competing systems 
> also use JSON format now by default.
> In fact, Solr's admin UI even explicitly adds wt=json to the request (by 
> default in the UI) to override the default of wt=xml, so Solr's Admin UI 
> effectively has a different default than the API.
> We have now introduced things like the JSON faceting API, and the new more 
> modern /V2 apis assume JSON for the areas of Solr they cover, so clearly 
> we're moving in the direction of JSON anyway.
> I'd like propose that we switch the default response writer to JSON (wt=json) 
> instead of XML for Solr 7.0, as this seems to me like the right direction and 
> a good time to make this change with the next major version.
> Based upon feedback from the Lucene Dev's mailing list, we want to:
> 1) Change the default response writer type to "wt=json" and also change to 
> "indent=on" by default
> 2) Make no changes on the update handler side; it already works as desired 
> (it returns the response in the same content-type as the request unless the 
> "wt" is passed in explicitly).
> 3) Keep the /query request handler around since people have already used it 
> for years to do JSON queries
> 4) Add a commented-out "wt=xml" to the solrconfig.xml as a reminder for folks 
> on how to change (back) the response format.
> The default format change, plus the addition of "indent=on" are back compat 
> changes, so we need to make sure we doc those clearly in the CHANGES.txt. 
> There will also need to be significant adjustments to the Solr Ref Guide, 
> Tutorial, etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10494) Switch Solr's Default Response Type from XML to JSON

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-10494:
-
Attachment: SOLR-10494-withdocs.patch

> Switch Solr's Default Response Type from XML to JSON
> 
>
> Key: SOLR-10494
> URL: https://issues.apache.org/jira/browse/SOLR-10494
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (7.0)
>Reporter: Trey Grainger
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: SOLR-10494, SOLR-10494, SOLR-10494-withdocs.patch, 
> SOLR-10494-withdocs.patch
>
>
> Solr's default response format is still XML, despite the fact that Solr has 
> supported the JSON response format for over a decade, developer mindshare has 
> clearly shifted toward JSON over the years, and most modern/competing systems 
> also use JSON format now by default.
> In fact, Solr's admin UI even explicitly adds wt=json to the request (by 
> default in the UI) to override the default of wt=xml, so Solr's Admin UI 
> effectively has a different default than the API.
> We have now introduced things like the JSON faceting API, and the new more 
> modern /V2 apis assume JSON for the areas of Solr they cover, so clearly 
> we're moving in the direction of JSON anyway.
> I'd like propose that we switch the default response writer to JSON (wt=json) 
> instead of XML for Solr 7.0, as this seems to me like the right direction and 
> a good time to make this change with the next major version.
> Based upon feedback from the Lucene Dev's mailing list, we want to:
> 1) Change the default response writer type to "wt=json" and also change to 
> "indent=on" by default
> 2) Make no changes on the update handler side; it already works as desired 
> (it returns the response in the same content-type as the request unless the 
> "wt" is passed in explicitly).
> 3) Keep the /query request handler around since people have already used it 
> for years to do JSON queries
> 4) Add a commented-out "wt=xml" to the solrconfig.xml as a reminder for folks 
> on how to change (back) the response format.
> The default format change, plus the addition of "indent=on" are back compat 
> changes, so we need to make sure we doc those clearly in the CHANGES.txt. 
> There will also need to be significant adjustments to the Solr Ref Guide, 
> Tutorial, etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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 # 951 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/951/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

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

Error Message:
Could not find collection : implicitcoll

Stack Trace:
org.apache.solr.common.SolrException: Could not find collection : implicitcoll
at 
__randomizedtesting.SeedInfo.seed([13C5E25CE2302AC6:79246C37DFAA9CBE]:0)
at 
org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:194)
at 
org.apache.solr.cloud.SolrCloudTestCase.getCollectionState(SolrCloudTestCase.java:245)
at 
org.apache.solr.cloud.CustomCollectionTest.testCustomCollectionsAPI(CustomCollectionTest.java:68)
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:748)




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

[newbie] LUCENE-7884: StringHelper needs to catch NoClassDefFoundError

[Yan Zhao]

Hi folks,

First time contributing to Lucene, here is a small patch for StringHelper:
https://issues.apache.org/jira/browse/LUCENE-7884

Can someone please take a look?

Thanks,
Yan

[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 789 - Failure

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 25926 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 215 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.02 sec (14.1 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-7.0.0-src.tgz...
   [smoker] 29.4 MB in 0.03 sec (865.4 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.0.0.tgz...
   [smoker] 69.0 MB in 0.08 sec (911.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.0.0.zip...
   [smoker] 79.3 MB in 0.09 sec (887.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-7.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6159 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6159 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.0.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 215 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.00 sec (239.0 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-7.0.0-src.tgz...
   [smoker] 50.0 MB in 0.06 sec (833.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.0.0.tgz...
   [smoker] 141.2 MB in 0.17 sec (827.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.0.0.zip...
   [smoker] 142.2 MB in 0.17 sec (843.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-7.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-7.0.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8
   [smoker] Creating Solr home directory 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8/example/techproducts/solr
   [smoker] 
   [smoker] Starting up Solr on port 8983 using command:
   [smoker] "bin/solr" start -p 8983 -s "example/techproducts/solr"
   [smoker] 
   [smoker] Waiting up to 180 seconds to see Solr running on port 8983 [|]  
 [/]   [-]   [\]  
   [smoker] Started Solr server on port 8983 (pid=23412). Happy searching!
   

[jira] [Updated] (LUCENE-7884) StringHelper needs to catch NoClassDefFoundError

[Yan Zhao (JIRA)]

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

Yan Zhao updated LUCENE-7884:
-
Attachment: LUCENE-7884.patch

> StringHelper needs to catch NoClassDefFoundError
> 
>
> Key: LUCENE-7884
> URL: https://issues.apache.org/jira/browse/LUCENE-7884
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/other
>Affects Versions: 5.x, 6.x, 6.5.1
> Environment: Google App Engine: https://cloud.google.com/appengine/
>Reporter: Yan Zhao
>Priority: Minor
>  Labels: easyfix, newbie, patch
> Attachments: LUCENE-7884.patch
>
>
> h3. Problem:
> As shown 
> [here|https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/util/StringHelper.java#L252-L255],
>  StringHelpers currently use *Paths* to generate random and catch *Exception* 
> when resources are unavailable.
> However, in some platform, calling *Paths* will result *NoClassDefFoundError* 
> which is not handled by catching *Exception*.
> h3. Change:
> Change to catch **Throwable** instead.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (LUCENE-7884) StringHelper needs to catch NoClassDefFoundError

[Yan Zhao (JIRA)]

Yan Zhao created LUCENE-7884:


 Summary: StringHelper needs to catch NoClassDefFoundError
 Key: LUCENE-7884
 URL: https://issues.apache.org/jira/browse/LUCENE-7884
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/other
Affects Versions: 6.5.1, 5.x, 6.x
 Environment: Google App Engine: https://cloud.google.com/appengine/
Reporter: Yan Zhao
Priority: Minor


h3. Problem:
As shown 
[here|https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/util/StringHelper.java#L252-L255],
 StringHelpers currently use *Paths* to generate random and catch *Exception* 
when resources are unavailable.

However, in some platform, calling *Paths* will result *NoClassDefFoundError* 
which is not handled by catching *Exception*.

h3. Change:
Change to catch **Throwable** instead.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10494) Switch Solr's Default Response Type from XML to JSON

[JIRA]

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

Jan Høydahl commented on SOLR-10494:


Good work Cassandra. Think your patch is reversed though :)

> Switch Solr's Default Response Type from XML to JSON
> 
>
> Key: SOLR-10494
> URL: https://issues.apache.org/jira/browse/SOLR-10494
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (7.0)
>Reporter: Trey Grainger
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: SOLR-10494, SOLR-10494, SOLR-10494-withdocs.patch
>
>
> Solr's default response format is still XML, despite the fact that Solr has 
> supported the JSON response format for over a decade, developer mindshare has 
> clearly shifted toward JSON over the years, and most modern/competing systems 
> also use JSON format now by default.
> In fact, Solr's admin UI even explicitly adds wt=json to the request (by 
> default in the UI) to override the default of wt=xml, so Solr's Admin UI 
> effectively has a different default than the API.
> We have now introduced things like the JSON faceting API, and the new more 
> modern /V2 apis assume JSON for the areas of Solr they cover, so clearly 
> we're moving in the direction of JSON anyway.
> I'd like propose that we switch the default response writer to JSON (wt=json) 
> instead of XML for Solr 7.0, as this seems to me like the right direction and 
> a good time to make this change with the next major version.
> Based upon feedback from the Lucene Dev's mailing list, we want to:
> 1) Change the default response writer type to "wt=json" and also change to 
> "indent=on" by default
> 2) Make no changes on the update handler side; it already works as desired 
> (it returns the response in the same content-type as the request unless the 
> "wt" is passed in explicitly).
> 3) Keep the /query request handler around since people have already used it 
> for years to do JSON queries
> 4) Add a commented-out "wt=xml" to the solrconfig.xml as a reminder for folks 
> on how to change (back) the response format.
> The default format change, plus the addition of "indent=on" are back compat 
> changes, so we need to make sure we doc those clearly in the CHANGES.txt. 
> There will also need to be significant adjustments to the Solr Ref Guide, 
> Tutorial, etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10494) Switch Solr's Default Response Type from XML to JSON

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-10494:
-
Attachment: SOLR-10494-withdocs.patch

Here's a patch with [~solrtrey]'s changes + ref guide changes. Nearly all of 
the changes needed were to simply remove {{=json=true}} from 
examples. Of course I found a couple unrelated glaring issues I couldn't let 
pass by, but I kept those to an extreme minimum. 

I reviewed all the places in the Ref Guide where {{wt}} is mentioned. Turns out 
we never actually said XML is the default...just said you had to use 
{{wt=json}}. I also updated the solrconfig.xml request handler defaults 
examples.

One thing I neglected to look for were places where an example request does not 
specify {{wt=xml}} but the example response is XML. I can do another pass for 
those at a later time - I would guess there aren't a lot of those.

> Switch Solr's Default Response Type from XML to JSON
> 
>
> Key: SOLR-10494
> URL: https://issues.apache.org/jira/browse/SOLR-10494
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (7.0)
>Reporter: Trey Grainger
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: SOLR-10494, SOLR-10494, SOLR-10494-withdocs.patch
>
>
> Solr's default response format is still XML, despite the fact that Solr has 
> supported the JSON response format for over a decade, developer mindshare has 
> clearly shifted toward JSON over the years, and most modern/competing systems 
> also use JSON format now by default.
> In fact, Solr's admin UI even explicitly adds wt=json to the request (by 
> default in the UI) to override the default of wt=xml, so Solr's Admin UI 
> effectively has a different default than the API.
> We have now introduced things like the JSON faceting API, and the new more 
> modern /V2 apis assume JSON for the areas of Solr they cover, so clearly 
> we're moving in the direction of JSON anyway.
> I'd like propose that we switch the default response writer to JSON (wt=json) 
> instead of XML for Solr 7.0, as this seems to me like the right direction and 
> a good time to make this change with the next major version.
> Based upon feedback from the Lucene Dev's mailing list, we want to:
> 1) Change the default response writer type to "wt=json" and also change to 
> "indent=on" by default
> 2) Make no changes on the update handler side; it already works as desired 
> (it returns the response in the same content-type as the request unless the 
> "wt" is passed in explicitly).
> 3) Keep the /query request handler around since people have already used it 
> for years to do JSON queries
> 4) Add a commented-out "wt=xml" to the solrconfig.xml as a reminder for folks 
> on how to change (back) the response format.
> The default format change, plus the addition of "indent=on" are back compat 
> changes, so we need to make sure we doc those clearly in the CHANGES.txt. 
> There will also need to be significant adjustments to the Solr Ref Guide, 
> Tutorial, etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-4319) New atomic update operation: AddToSet

[Michael Schumann (JIRA)]

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

Michael Schumann commented on SOLR-4319:


This would be nice. We achieved this behavior by always doing a "remove" before 
an "add"; if no value exists the remove has no effect. 

> New atomic update operation: AddToSet
> -
>
> Key: SOLR-4319
> URL: https://issues.apache.org/jira/browse/SOLR-4319
> Project: Solr
>  Issue Type: Wish
>  Components: Schema and Analysis
>Reporter: Mikael Koskinen
>  Labels: atomic
>
> Currently Solr supports the following atomic operations:
> add, set, inc
> It would be great to have operation "addToSet". This would be useful in 
> situations where a document has a multivalued field (like category) and I 
> want to add a new value to list if it doesn't already exists. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10927) Support position to context.xml in Query Elevation Component

[jefferyyuan (JIRA)]

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

jefferyyuan updated SOLR-10927:
---
Summary: Support position to context.xml in Query Elevation Component  
(was: Suuport position to context.xml in Query Elevation Component)

> Support position to context.xml in Query Elevation Component
> 
>
> Key: SOLR-10927
> URL: https://issues.apache.org/jira/browse/SOLR-10927
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SearchComponents - other
>Reporter: jefferyyuan
> Fix For: 6.7, 6.6.1
>
>
> Query Elevation Component is useful but is kind of limited.
> Usually we want to boost one document for one query, but not necessary put at 
> the first one.
> For example, user searches walking dead - we want to boost our shows "Deadly 
> Vampire", but we don't want to show it as the first one - as that may piss 
> off the user.
> We want to show "Deadly Vampire" at the 2nd or maybe 3rd, 4th position.
> Seems at Editorial Query Boosting Component 
> [https://issues.apache.org/jira/browse/SOLR-418], the original draft 
> implementation actually supports it - the priority property.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-10927) Suuport position to context.xml in Query Elevation Component

[jefferyyuan (JIRA)]

jefferyyuan created SOLR-10927:
--

 Summary: Suuport position to context.xml in Query Elevation 
Component
 Key: SOLR-10927
 URL: https://issues.apache.org/jira/browse/SOLR-10927
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SearchComponents - other
Reporter: jefferyyuan
 Fix For: 6.7, 6.6.1


Query Elevation Component is useful but is kind of limited.

Usually we want to boost one document for one query, but not necessary put at 
the first one.

For example, user searches walking dead - we want to boost our shows "Deadly 
Vampire", but we don't want to show it as the first one - as that may piss off 
the user.
We want to show "Deadly Vampire" at the 2nd or maybe 3rd, 4th position.

Seems at Editorial Query Boosting Component 
[https://issues.apache.org/jira/browse/SOLR-418], the original draft 
implementation actually supports it - the priority property.




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-4319) New atomic update operation: AddToSet

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-4319:


Certainly... I hit this recently.  I'm surprised "add" wasn't implemented this 
way to begin with since I bet most users effectively have a set anyways.

> New atomic update operation: AddToSet
> -
>
> Key: SOLR-4319
> URL: https://issues.apache.org/jira/browse/SOLR-4319
> Project: Solr
>  Issue Type: Wish
>  Components: Schema and Analysis
>Reporter: Mikael Koskinen
>  Labels: atomic
>
> Currently Solr supports the following atomic operations:
> add, set, inc
> It would be great to have operation "addToSet". This would be useful in 
> situations where a document has a multivalued field (like category) and I 
> want to add a new value to list if it doesn't already exists. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-10926) increase the odds of randomly choosing point fields

[Hoss Man (JIRA)]

Hoss Man created SOLR-10926:
---

 Summary: increase the odds of randomly choosing point fields
 Key: SOLR-10926
 URL: https://issues.apache.org/jira/browse/SOLR-10926
 Project: Solr
  Issue Type: Sub-task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man


currently it's a 50/50 chance of using point fields vs trie fields ... once we 
are more confident in the utility/reliability of point fields and/or they are 
the "default" in our example configsets, we should tweak those odds so Point 
fields get tested much more often then TrieFields



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-10925) remove explicit FooPointField types & usages from test configs once randomization is universal

[Hoss Man (JIRA)]

Hoss Man created SOLR-10925:
---

 Summary: remove explicit FooPointField types & usages from test 
configs once randomization is universal
 Key: SOLR-10925
 URL: https://issues.apache.org/jira/browse/SOLR-10925
 Project: Solr
  Issue Type: Sub-task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man


Once SOLR-10807's objective of getting FooPointField usage randomized in every 
test config is in place, we should consider removing the explicit 
FooPointFields that are configured in these schemas, and either remove the 
associated fields/dynamicfields or update them to use the randomized 
equivilents.

In many cases, these types/fields are usedin tests that loop over a list of 
field names, or will otherwise be redundantly testing points fields multiple 
times.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10844) group.facet failures when the grouping field is Points based (or Trie w/docValues??)

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-10844:

Description: 
As discovered when working on SOLR-10807: if you change all existing test 
configs to use FooPointField instead of TrieFooField, you get odd failures when 
{{group.facet}} is used in conjunction with grouping on a point field (even if 
the group.facet field is a string field)



Actually: the problem may be more nuanced.  In general the grouping code seems 
to have hardcoded assumptions about the DV type it will get for the grouping 
field when doing group.facet that can fail even if the field is single valued 
Trie field with docValues.

  was:
As discovered when working on SOLR-10807: if you change all existing test 
configs to use FooPointField instead of TrieFooField, you get odd failures when 
{{group.facet}} is used in conjunction with grouping on a point field (even if 
the group.facet field is a string field)


Summary: group.facet failures when the grouping field is Points based 
(or Trie w/docValues??)  (was: group.facet failures when the grouping field is 
Points based)

updated summary & description to note that as i work on SOLR-10864 and increase 
the randomization points & docValues i've found similar looking errors from 
single valued trie fields w/docValues=true (in the pre-existing tests, the 
numeric fields used were only ever using the FieldCache)

> group.facet failures when the grouping field is Points based (or Trie 
> w/docValues??)
> 
>
> Key: SOLR-10844
> URL: https://issues.apache.org/jira/browse/SOLR-10844
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
> Attachments: SOLR-10844.patch
>
>
> As discovered when working on SOLR-10807: if you change all existing test 
> configs to use FooPointField instead of TrieFooField, you get odd failures 
> when {{group.facet}} is used in conjunction with grouping on a point field 
> (even if the group.facet field is a string field)
> 
> Actually: the problem may be more nuanced.  In general the grouping code 
> seems to have hardcoded assumptions about the DV type it will get for the 
> grouping field when doing group.facet that can fail even if the field is 
> single valued Trie field with docValues.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10574) Choose a default configset for Solr 7

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-10574:
--

bq. Looks like there are some failing tests after this commit 

I'm going to guess these failures are at least related to a problem I have in a 
local "master" build where I had to manually enter "_default" as the name of 
the configset. None of the options were acceptable (because they no longer 
exist).

> Choose a default configset for Solr 7
> -
>
> Key: SOLR-10574
> URL: https://issues.apache.org/jira/browse/SOLR-10574
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10574.patch, SOLR-10574.patch, SOLR-10574.patch, 
> SOLR-10574.patch
>
>
> Currently, the data_driven_schema_configs is the default configset when 
> collections are created using the bin/solr script and no configset is 
> specified.
> However, that may not be the best choice. We need to decide which is the best 
> choice, out of the box, considering many users might create collections 
> without knowing about the concept of a configset going forward.
> (See also SOLR-10272)
> Proposed changes:
> # Remove data_driven_schema_configs and basic_configs
> # Introduce a combined configset, {{_default}} based on the above two 
> configsets.
> # Build a "toggleable" data driven functionality into {{_default}}
> Usage:
> # Create a collection (using _default configset)
> # Data driven / schemaless functionality is enabled by default; so just start 
> indexing your documents.
> # If don't want data driven / schemaless, disable this behaviour: {code}
> curl http://host:8983/solr/coll1/config -d '{"set-user-property": 
> {"update.autoCreateFields":"false"}}'
> {code}
> # Create schema fields using schema API, and index documents



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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+173) - Build # 19918 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19918/
Java: 32bit/jdk-9-ea+173 -client -XX:+UseParallelGC

8 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.SolrSchemalessExampleTest

Error Message:
Source 
'/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/server/solr/configsets/data_driven_schema_configs/conf'
 does not exist

Stack Trace:
java.io.FileNotFoundException: Source 
'/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/server/solr/configsets/data_driven_schema_configs/conf'
 does not exist
at __randomizedtesting.SeedInfo.seed([F6E0676C69D3EF73]:0)
at 
org.apache.commons.io.FileUtils.checkFileRequirements(FileUtils.java:1405)
at org.apache.commons.io.FileUtils.copyDirectory(FileUtils.java:1368)
at org.apache.commons.io.FileUtils.copyDirectory(FileUtils.java:1268)
at 
org.apache.commons.io.FileUtils.copyDirectoryToDirectory(FileUtils.java:1209)
at 
org.apache.solr.client.solrj.SolrSchemalessExampleTest.beforeClass(SolrSchemalessExampleTest.java:54)
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:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:847)
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)


FAILED:  
org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection

Error Message:
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/server/solr/configsets/data_driven_schema_configs/conf
 not found!

Stack Trace:
java.lang.AssertionError: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/server/solr/configsets/data_driven_schema_configs/conf
 not found!
at 
__randomizedtesting.SeedInfo.seed([9CA7D2A6C8BC40D1:8FC4E0C9F9D3F977]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection(SolrCloudExampleTest.java:77)
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:564)
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 

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4091/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC

9 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([6CC078B02ABB1E9C:399090228642D16C]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.getCollectionNames(CloudSolrClient.java:1153)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:836)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:807)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
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] [Closed] (SOLR-5077) Inconsistencies in solrconfig upload limits - examples and test-files

[JIRA]

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

Jan Høydahl closed SOLR-5077.
-
Resolution: Done

Done in SOLR-9623

> Inconsistencies in solrconfig upload limits - examples and test-files
> -
>
> Key: SOLR-5077
> URL: https://issues.apache.org/jira/browse/SOLR-5077
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 4.4
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
> Fix For: 6.0, 4.9
>
>
> In the various solrconfig.xml files, there is no consistency in how the 
> request parser upload limits are configured.  In some of them, only 
> multipartUploadLimitInKB is configured.  In others, formdataUploadLimitInKB 
> is also defined.  Most of them have a multipart value of 2048, but a few 
> (including the main example) have 2048000, which represents nearly 2GB 
> instead of 2MB.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-9623) Disable remote streaming by default

[JIRA]

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

Jan Høydahl resolved SOLR-9623.
---
Resolution: Fixed

> Disable remote streaming by default
> ---
>
> Key: SOLR-9623
> URL: https://issues.apache.org/jira/browse/SOLR-9623
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Blocker
>  Labels: configset
> Fix For: master (7.0)
>
> Attachments: SOLR-9623.patch, SOLR-9623.patch, SOLR-9623.patch, 
> SOLR-9623.patch
>
>
> As we set more and more config settings suitable for production use, perhaps 
> it is time to disable remoteStreaming by default, and document how to enable 
> it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-6092) Provide a REST managed QueryElevationComponent

[jefferyyuan (JIRA)]

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

jefferyyuan edited comment on SOLR-6092 at 6/20/17 7:14 PM:


Vote for this.

We can manage stop words, synonyms, why not QueryElevation which are much more 
useful.
Also the content in elevate.xml - what we want to upselll for different query 
changed very frequently

Thanks


was (Author: yuanyun.cn):
Vote for this.

We can manage stop words, synonyms, why not QueryElevation which are much more 
useful.

Thanks

> Provide a REST managed QueryElevationComponent
> --
>
> Key: SOLR-6092
> URL: https://issues.apache.org/jira/browse/SOLR-6092
> Project: Solr
>  Issue Type: New Feature
>Reporter: Timothy Potter
>Priority: Minor
>
> Provide a managed query elevation component to allow CRUD operations from a 
> REST API.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-9623) Disable remote streaming by default

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9623: Fix test errors related to some test expecting streaming to be 
enabled


> Disable remote streaming by default
> ---
>
> Key: SOLR-9623
> URL: https://issues.apache.org/jira/browse/SOLR-9623
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Blocker
>  Labels: configset
> Fix For: master (7.0)
>
> Attachments: SOLR-9623.patch, SOLR-9623.patch, SOLR-9623.patch, 
> SOLR-9623.patch
>
>
> As we set more and more config settings suitable for production use, perhaps 
> it is time to disable remoteStreaming by default, and document how to enable 
> it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10494) Switch Solr's Default Response Type from XML to JSON

[JIRA]

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

Jan Høydahl commented on SOLR-10494:


That was just a IDEA search, see 
https://www.dropbox.com/s/4dan2pdt21d2t99/wt_json.png?dl=0
Could be that all the uses in {{TestSolrConfigHandler.java}} are still 
necessary, or should that API also default to JSON response...


> Switch Solr's Default Response Type from XML to JSON
> 
>
> Key: SOLR-10494
> URL: https://issues.apache.org/jira/browse/SOLR-10494
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (7.0)
>Reporter: Trey Grainger
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: SOLR-10494, SOLR-10494
>
>
> Solr's default response format is still XML, despite the fact that Solr has 
> supported the JSON response format for over a decade, developer mindshare has 
> clearly shifted toward JSON over the years, and most modern/competing systems 
> also use JSON format now by default.
> In fact, Solr's admin UI even explicitly adds wt=json to the request (by 
> default in the UI) to override the default of wt=xml, so Solr's Admin UI 
> effectively has a different default than the API.
> We have now introduced things like the JSON faceting API, and the new more 
> modern /V2 apis assume JSON for the areas of Solr they cover, so clearly 
> we're moving in the direction of JSON anyway.
> I'd like propose that we switch the default response writer to JSON (wt=json) 
> instead of XML for Solr 7.0, as this seems to me like the right direction and 
> a good time to make this change with the next major version.
> Based upon feedback from the Lucene Dev's mailing list, we want to:
> 1) Change the default response writer type to "wt=json" and also change to 
> "indent=on" by default
> 2) Make no changes on the update handler side; it already works as desired 
> (it returns the response in the same content-type as the request unless the 
> "wt" is passed in explicitly).
> 3) Keep the /query request handler around since people have already used it 
> for years to do JSON queries
> 4) Add a commented-out "wt=xml" to the solrconfig.xml as a reminder for folks 
> on how to change (back) the response format.
> The default format change, plus the addition of "indent=on" are back compat 
> changes, so we need to make sure we doc those clearly in the CHANGES.txt. 
> There will also need to be significant adjustments to the Solr Ref Guide, 
> Tutorial, etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10494) Switch Solr's Default Response Type from XML to JSON

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-10494:
--

I'm happy to help with doc/website updates. Some of the ref guide references 
might be big and would delay this change significantly (IOW, may make it miss 
7.0).

Re: quickstart - I proposed in SOLR-10842 to move that to the Ref Guide, and 
I'm working up a patch (maybe this week? it's a huge reorg). I think we could 
let that go from this patch in deference to this other effort, again to not 
hold up what should be a pretty minor change.

bq. Remove superflous wt=json from various places (There are hundreds, 
including Admin UI, READMEs etc)

I could not find 100s of references. [~janhoy], Can you give a list, or the 
grep/sed/whatever that you used to find those?

> Switch Solr's Default Response Type from XML to JSON
> 
>
> Key: SOLR-10494
> URL: https://issues.apache.org/jira/browse/SOLR-10494
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (7.0)
>Reporter: Trey Grainger
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: SOLR-10494, SOLR-10494
>
>
> Solr's default response format is still XML, despite the fact that Solr has 
> supported the JSON response format for over a decade, developer mindshare has 
> clearly shifted toward JSON over the years, and most modern/competing systems 
> also use JSON format now by default.
> In fact, Solr's admin UI even explicitly adds wt=json to the request (by 
> default in the UI) to override the default of wt=xml, so Solr's Admin UI 
> effectively has a different default than the API.
> We have now introduced things like the JSON faceting API, and the new more 
> modern /V2 apis assume JSON for the areas of Solr they cover, so clearly 
> we're moving in the direction of JSON anyway.
> I'd like propose that we switch the default response writer to JSON (wt=json) 
> instead of XML for Solr 7.0, as this seems to me like the right direction and 
> a good time to make this change with the next major version.
> Based upon feedback from the Lucene Dev's mailing list, we want to:
> 1) Change the default response writer type to "wt=json" and also change to 
> "indent=on" by default
> 2) Make no changes on the update handler side; it already works as desired 
> (it returns the response in the same content-type as the request unless the 
> "wt" is passed in explicitly).
> 3) Keep the /query request handler around since people have already used it 
> for years to do JSON queries
> 4) Add a commented-out "wt=xml" to the solrconfig.xml as a reminder for folks 
> on how to change (back) the response format.
> The default format change, plus the addition of "indent=on" are back compat 
> changes, so we need to make sure we doc those clearly in the CHANGES.txt. 
> There will also need to be significant adjustments to the Solr Ref Guide, 
> Tutorial, etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7880) Make boolean query clause limit configurable per-query

[Erick Erickson (JIRA)]

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

Erick Erickson commented on LUCENE-7880:


bq: It wouldn't be an issue if it was a cluster setting? What is the value of 
letting one user generate huge boolean queries and prevent others?

This is where the focus on making it configurable per-query is confusing things 
a bit I think. Making it per-query just provides a way to get around the static 
nature of the variable and allow limits on a per-core basis is how I've been 
interpreting it. And why I suggested thinking of it from a clean-slate 
perspective.

Practically what I want to see is a way that each core can have a different 
setting that's respected. I don't care if it's per-query or per-core. In the 
Solr world at least it's becoming quite common for there to be replicas (cores) 
from multiple collections hosted in the same JVM which may have very different 
usage patterns. It may make sense that one collection has a much different 
limit than the others in that case, which we can't do now.

And it's quite easy to blow past the 1024 limit. It doesn't even take a 
horribly complex query when you start spreading it across 100 fields.



> Make boolean query clause limit configurable per-query
> --
>
> Key: LUCENE-7880
> URL: https://issues.apache.org/jira/browse/LUCENE-7880
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Yonik Seeley
>
> As we know, the magic BooleanQuery.maxClauseCount has bitten many people over 
> time.
> It's also a static, which really hurts multi-tenancy (i.e. we can't have 
> different settings for different users, clients, or use-cases).
> If we want to keep this static as a default, then at least we should allow it 
> to be overridden on a per-query basis when we know it is the desired behavior 
> and not a bug.
> Perhaps the simplest way to achieve this would be a setter on 
> BooleanQuery.Builder that configures the limit for that instance only?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10924) PointField multivalued docValues don't "dedup" like TrieField

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10924:
-

I've filed this "bug" so we have a record of the discrepency, but personally I 
don't think there is anything we should really do to "fix" it.  If users are 
sending duplicate values to a field and want to dedup just like Trie fields 
did, they can use UniqFieldsUpdateProcessorFactory on all numeric fields.


> PointField multivalued docValues don't "dedup" like TrieField
> -
>
> Key: SOLR-10924
> URL: https://issues.apache.org/jira/browse/SOLR-10924
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>
> As noted by Tomas in SOLR-10835, since the numeric FooPointField classes use 
> SortedNumericDocValues, the docvalues don't "dedup" when the same value 
> exists multiple times for a single document -- this is different from the 
> numeric TrieFooField classes that use SortedSetDocValues - which are by 
> definition a _set_ -- so multiple instances of the same value are 
> de-duplicated.
> This impacts things like the ExportWriter, as well as fields that 
> {{useDocValuesAsStored="true"}} if users have particular expecations when 
> converting from Trie fields to Point fields.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-10924) PointField multivalued docValues don't "dedup" like TrieField

[Hoss Man (JIRA)]

Hoss Man created SOLR-10924:
---

 Summary: PointField multivalued docValues don't "dedup" like 
TrieField
 Key: SOLR-10924
 URL: https://issues.apache.org/jira/browse/SOLR-10924
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man


As noted by Tomas in SOLR-10835, since the numeric FooPointField classes use 
SortedNumericDocValues, the docvalues don't "dedup" when the same value exists 
multiple times for a single document -- this is different from the numeric 
TrieFooField classes that use SortedSetDocValues - which are by definition a 
_set_ -- so multiple instances of the same value are de-duplicated.

This impacts things like the ExportWriter, as well as fields that 
{{useDocValuesAsStored="true"}} if users have particular expecations when 
converting from Trie fields to Point fields.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-4586) Eliminate the maxBooleanClauses limit

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-4586:
--

Jan:

Got it. I think moving it to solr.xml is sub-optimal, but much better than what 
we do now. Putting it in solr.xml conveys that it's an instance-wide setting 
_much_ better than putting it in solrconfig.xml. 

And functionally this is no different than what we do currently in the sense 
that to be useful _all_ the solrconfig files for _all_ the cores in the JVM 
need to have the same setting. Which means you can't have one core respect one 
limit and another core respect another limit.

Which would be just what putting it in solr.xml would do too. The solr.xml 
option makes it a lot less trappy.

> Eliminate the maxBooleanClauses limit
> -
>
> Key: SOLR-4586
> URL: https://issues.apache.org/jira/browse/SOLR-4586
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Affects Versions: 4.2
> Environment: 4.3-SNAPSHOT 1456767M - ncindex - 2013-03-15 13:11:50
>Reporter: Shawn Heisey
> Fix For: master (7.0)
>
> Attachments: SOLR-4586.patch, SOLR-4586.patch, SOLR-4586.patch, 
> SOLR-4586.patch, SOLR-4586.patch, SOLR-4586.patch, 
> SOLR-4586_verify_maxClauses.patch
>
>
> In the #solr IRC channel, I mentioned the maxBooleanClauses limitation to 
> someone asking a question about queries.  Mark Miller told me that 
> maxBooleanClauses no longer applies, that the limitation was removed from 
> Lucene sometime in the 3.x series.  The config still shows up in the example 
> even in the just-released 4.2.
> Checking through the source code, I found that the config option is parsed 
> and the value stored in objects, but does not actually seem to be used by 
> anything.  I removed every trace of it that I could find, and all tests still 
> pass.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Reopened] (SOLR-9623) Disable remote streaming by default

[JIRA]

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

Jan Høydahl reopened SOLR-9623:
---

Thanks Steve, I'm on the case

> Disable remote streaming by default
> ---
>
> Key: SOLR-9623
> URL: https://issues.apache.org/jira/browse/SOLR-9623
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Blocker
>  Labels: configset
> Fix For: master (7.0)
>
> Attachments: SOLR-9623.patch, SOLR-9623.patch, SOLR-9623.patch, 
> SOLR-9623.patch
>
>
> As we set more and more config settings suitable for production use, perhaps 
> it is time to disable remoteStreaming by default, and document how to enable 
> it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-4586) Eliminate the maxBooleanClauses limit

[JIRA]

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

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

[~erickerickson] yes I know the bug, experienced it myself. What I meant to say 
is that we should fix that, either by making it a truly per-core setting or by 
moving the (still global) config up to solr.xml.

> Eliminate the maxBooleanClauses limit
> -
>
> Key: SOLR-4586
> URL: https://issues.apache.org/jira/browse/SOLR-4586
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Affects Versions: 4.2
> Environment: 4.3-SNAPSHOT 1456767M - ncindex - 2013-03-15 13:11:50
>Reporter: Shawn Heisey
> Fix For: master (7.0)
>
> Attachments: SOLR-4586.patch, SOLR-4586.patch, SOLR-4586.patch, 
> SOLR-4586.patch, SOLR-4586.patch, SOLR-4586.patch, 
> SOLR-4586_verify_maxClauses.patch
>
>
> In the #solr IRC channel, I mentioned the maxBooleanClauses limitation to 
> someone asking a question about queries.  Mark Miller told me that 
> maxBooleanClauses no longer applies, that the limitation was removed from 
> Lucene sometime in the 3.x series.  The config still shows up in the example 
> even in the just-released 4.2.
> Checking through the source code, I found that the config option is parsed 
> and the value stored in objects, but does not actually seem to be used by 
> anything.  I removed every trace of it that I could find, and all tests still 
> pass.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10915) Make SolrClient classes extendable without code duplication

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-10915:
-

Sorry about that confusion, should've read what I wrote :). 

I do intend to have only constructors that accept a builder object. Everything 
else that has never been released i.e. was added after the last release OR is 
private can be completely removed, and constructors that are protected/public 
should be marked as deprecated.

Does this make sense?

> Make SolrClient classes extendable without code duplication
> ---
>
> Key: SOLR-10915
> URL: https://issues.apache.org/jira/browse/SOLR-10915
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: clients - java
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10915.patch.with-deprecations, 
> SOLR-10915.patch.without-deprecations
>
>
> SolrClient used to be easily extendable but our move to Builder pattern has 
> made it impossible to extend those classes without code duplication. 
> As an example, if we wanted to extend HttpSolrClient we would also want to 
> extend the Builder. The problem is that the constructor of the main class, 
> does not accept the builder object but explicit parameters, and the inherited 
> class doesn't have access to any of those values from the Builder object as 
> they are all private. 
> Generally, we'd want to have the client object constructor accept the 
> Builder, instead of explicit values, and also make the Builder values 
> protected so the inherited classes could use them.
> I'm marking this as a blocker for 7.0 as this is an important piece that 
> needs to be fixed before the major release, specially now that we know that 
> this problem exists.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10915) Make SolrClient classes extendable without code duplication

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski commented on SOLR-10915:


I think I'm reading you wrong.

bq. we should only have client constructors that accept the builder, and 
nothing else - even private constructors.

and

bq. We aren't 'removing' anything here but just deprecating so we should be fine

seem to conflict a little bit.  The first implies removing all constructors 
except the ones created by this patch.  The second (as I read it) says that we 
should be deprecating but not removing any constructors here.

I'm fine with either approach, just wanted to clarify before updating the 
patch.  Sorry for the confusion on my part.

> Make SolrClient classes extendable without code duplication
> ---
>
> Key: SOLR-10915
> URL: https://issues.apache.org/jira/browse/SOLR-10915
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: clients - java
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10915.patch.with-deprecations, 
> SOLR-10915.patch.without-deprecations
>
>
> SolrClient used to be easily extendable but our move to Builder pattern has 
> made it impossible to extend those classes without code duplication. 
> As an example, if we wanted to extend HttpSolrClient we would also want to 
> extend the Builder. The problem is that the constructor of the main class, 
> does not accept the builder object but explicit parameters, and the inherited 
> class doesn't have access to any of those values from the Builder object as 
> they are all private. 
> Generally, we'd want to have the client object constructor accept the 
> Builder, instead of explicit values, and also make the Builder values 
> protected so the inherited classes could use them.
> I'm marking this as a blocker for 7.0 as this is an important piece that 
> needs to be fixed before the major release, specially now that we know that 
> this problem exists.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-3346) qt Dispatching Request Handler

[David Smiley (JIRA)]

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

David Smiley edited comment on SOLR-3346 at 6/20/17 6:04 PM:
-

[~janhoy] see SOLR-6807.  I'd love to see 6807 done for v7.0.  Then we can 
think of either ripping out handleSelect functionality out and stop there or as 
this issue suggest, replace with a similar request handler.


was (Author: dsmiley):
[~janhoy] see SOLR-6807.  I'd love to see this done as an initial step in 7.0.

> qt Dispatching Request Handler
> --
>
> Key: SOLR-3346
> URL: https://issues.apache.org/jira/browse/SOLR-3346
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: David Smiley
>
> Instead of 'qt' being handled by the SolrDispatchFilter (a Servlet Filter), 
> it would be better implemented as a request handler, with a suggested name of 
> DispatchingRequestHandler.  This is better because:
> * it keeps the servlet filter more focused / simplified (albeit just a little)
> * it simplifies solrconfig.xml by removing/deprecating handleSelect="true".  
> 'qt' is less magic, it works more explicitly.
> * if you don't want to use 'qt' dispatch, simply don't use 
> DispatchingRequestHandler
> * DispatchingRequestHandler would get used by EmbeddedSolrServer but 
> SolrDispatchFilter is not.
> Credit: Hoss's idea, Erik coded a first draft



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-3346) qt Dispatching Request Handler

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-3346:


[~janhoy] see SOLR-6807.  I'd love to see this done as an initial step in 7.0.

> qt Dispatching Request Handler
> --
>
> Key: SOLR-3346
> URL: https://issues.apache.org/jira/browse/SOLR-3346
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: David Smiley
>
> Instead of 'qt' being handled by the SolrDispatchFilter (a Servlet Filter), 
> it would be better implemented as a request handler, with a suggested name of 
> DispatchingRequestHandler.  This is better because:
> * it keeps the servlet filter more focused / simplified (albeit just a little)
> * it simplifies solrconfig.xml by removing/deprecating handleSelect="true".  
> 'qt' is less magic, it works more explicitly.
> * if you don't want to use 'qt' dispatch, simply don't use 
> DispatchingRequestHandler
> * DispatchingRequestHandler would get used by EmbeddedSolrServer but 
> SolrDispatchFilter is not.
> Credit: Hoss's idea, Erik coded a first draft



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10915) Make SolrClient classes extendable without code duplication

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-10915:
-

Thanks Jason. The patch looks good overall but I think we should only have 
client constructors that accept the builder, and nothing else - even private 
constructors. Everything that is needed is a part of the builder object, and so 
can be extracted. That certainly means more work, but I think it is worth it. 
e.g.
{code:java}
// L209 in the patch
  protected CloudSolrClient(Builder builder) {
this(builder.zkHosts, builder.zkChroot, builder.solrUrls, 
builder.httpClient, builder.loadBalancedSolrClient,
builder.lbClientBuilder, builder.shardLeadersOnly, 
builder.directUpdatesToLeadersOnly, builder.stateProvider);
}
{code}

We should just move the implementation of that private constructor in here.

I don't personally have a strong opinion around {{withFoo}} methods Vs those 
being a part of the constructor. As long as that list is restricted to < 3 
params (almost an arbitrary number that's not too high), I don't have a problem.

bq. That seems reasonable to me, but I also see an argument that methods marked 
as protected are a part of our API and we'd need to give more warning. Either 
way would be fine with me.
We aren't 'removing' anything here but just deprecating so we should be fine.

> Make SolrClient classes extendable without code duplication
> ---
>
> Key: SOLR-10915
> URL: https://issues.apache.org/jira/browse/SOLR-10915
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: clients - java
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10915.patch.with-deprecations, 
> SOLR-10915.patch.without-deprecations
>
>
> SolrClient used to be easily extendable but our move to Builder pattern has 
> made it impossible to extend those classes without code duplication. 
> As an example, if we wanted to extend HttpSolrClient we would also want to 
> extend the Builder. The problem is that the constructor of the main class, 
> does not accept the builder object but explicit parameters, and the inherited 
> class doesn't have access to any of those values from the Builder object as 
> they are all private. 
> Generally, we'd want to have the client object constructor accept the 
> Builder, instead of explicit values, and also make the Builder values 
> protected so the inherited classes could use them.
> I'm marking this as a blocker for 7.0 as this is an important piece that 
> needs to be fixed before the major release, specially now that we know that 
> this problem exists.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10494) Switch Solr's Default Response Type from XML to JSON

[Trey Grainger (JIRA)]

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

Trey Grainger commented on SOLR-10494:
--

yes, I'll address all of the code/config changes above. I'll get the patch 
updated to include the indent=on change first (fixing unit tests now... were 
more that broke than I was expecting due to indention) and then do the cleanup 
of the configs, admin, readme's, as a follow on patch.

Once those are in, I can take a look at the ref-guide, website, and quickstart, 
though I'm afraid I may need some help pull all of those off in any reasonable 
timeframe for 7.0, as I'd expect there to be a lot of changes required there.

> Switch Solr's Default Response Type from XML to JSON
> 
>
> Key: SOLR-10494
> URL: https://issues.apache.org/jira/browse/SOLR-10494
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (7.0)
>Reporter: Trey Grainger
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: SOLR-10494, SOLR-10494
>
>
> Solr's default response format is still XML, despite the fact that Solr has 
> supported the JSON response format for over a decade, developer mindshare has 
> clearly shifted toward JSON over the years, and most modern/competing systems 
> also use JSON format now by default.
> In fact, Solr's admin UI even explicitly adds wt=json to the request (by 
> default in the UI) to override the default of wt=xml, so Solr's Admin UI 
> effectively has a different default than the API.
> We have now introduced things like the JSON faceting API, and the new more 
> modern /V2 apis assume JSON for the areas of Solr they cover, so clearly 
> we're moving in the direction of JSON anyway.
> I'd like propose that we switch the default response writer to JSON (wt=json) 
> instead of XML for Solr 7.0, as this seems to me like the right direction and 
> a good time to make this change with the next major version.
> Based upon feedback from the Lucene Dev's mailing list, we want to:
> 1) Change the default response writer type to "wt=json" and also change to 
> "indent=on" by default
> 2) Make no changes on the update handler side; it already works as desired 
> (it returns the response in the same content-type as the request unless the 
> "wt" is passed in explicitly).
> 3) Keep the /query request handler around since people have already used it 
> for years to do JSON queries
> 4) Add a commented-out "wt=xml" to the solrconfig.xml as a reminder for folks 
> on how to change (back) the response format.
> The default format change, plus the addition of "indent=on" are back compat 
> changes, so we need to make sure we doc those clearly in the CHANGES.txt. 
> There will also need to be significant adjustments to the Solr Ref Guide, 
> Tutorial, etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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+173) - Build # 19917 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19917/
Java: 32bit/jdk-9-ea+173 -server -XX:+UseParallelGC

9 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.AutoScalingHandlerTest.testPolicyAndPreferences

Error Message:
Adding a policy with 'cores' attribute should not have succeeded.

Stack Trace:
java.lang.AssertionError: Adding a policy with 'cores' attribute should not 
have succeeded.
at 
__randomizedtesting.SeedInfo.seed([23F7935B6B74E6F9:823FCD721232E0F7]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.autoscaling.AutoScalingHandlerTest.testPolicyAndPreferences(AutoScalingHandlerTest.java:83)
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:564)
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)


FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.SolrSchemalessExampleTest

Error Message:
Source 
'/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/server/solr/configsets/data_driven_schema_configs/conf'
 does not exist

Stack Trace:

[jira] [Assigned] (SOLR-10923) AutoScalingHandlerTest.testPolicyAndPreferences() failure: Adding a policy with 'cores' attribute should not have succeeded

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat reassigned SOLR-10923:
---

Assignee: (was: Cao Manh Dat)

> AutoScalingHandlerTest.testPolicyAndPreferences() failure: Adding a policy 
> with 'cores' attribute should not have succeeded
> ---
>
> Key: SOLR-10923
> URL: https://issues.apache.org/jira/browse/SOLR-10923
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>
> Policeman Jenkins found a reproducing seed 
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19914]:
> {noformat}
> Checking out Revision b1b566f57bba46cadae33bc8198246fa05609287 
> (refs/remotes/origin/master)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=AutoScalingHandlerTest -Dtests.method=testPolicyAndPreferences 
> -Dtests.seed=DB220AFF163D3283 -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=to-TO -Dtests.timezone=America/Montserrat -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 0.01s J2 | 
> AutoScalingHandlerTest.testPolicyAndPreferences <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Adding a policy with 
> 'cores' attribute should not have succeeded.
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([DB220AFF163D3283:7AEA54D66F7B348D]:0)
>[junit4]>  at 
> org.apache.solr.cloud.autoscaling.AutoScalingHandlerTest.testPolicyAndPreferences(AutoScalingHandlerTest.java:83)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]>  at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]>  at 
> java.base/java.lang.reflect.Method.invoke(Method.java:564)
> [...]
>[junit4]   2> NOTE: test params are: codec=Lucene70, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=to-TO, 
> timezone=America/Montserrat
>[junit4]   2> NOTE: Linux 4.10.0-21-generic i386/Oracle Corporation 9-ea 
> (32-bit)/cpus=8,threads=1,free=151310248,total=411041792
> {noformat}
> Another reproducing seed 
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19916]:
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=AutoScalingHandlerTest -Dtests.method=testPolicyAndPreferences 
> -Dtests.seed=3D04238B59F9D32D -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=en-MW -Dtests.timezone=America/Recife -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 0.02s J2 | 
> AutoScalingHandlerTest.testPolicyAndPreferences <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Adding a policy with 
> 'cores' attribute should not have succeeded.
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([3D04238B59F9D32D:9CCC7DA220BFD523]:0)
>[junit4]>  at 
> org.apache.solr.cloud.autoscaling.AutoScalingHandlerTest.testPolicyAndPreferences(AutoScalingHandlerTest.java:83)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]>  at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]>  at 
> java.base/java.lang.reflect.Method.invoke(Method.java:564)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7880) Make boolean query clause limit configurable per-query

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-7880:
--

bq. If you were writing this from scratch would you advocate the current design?

I suspect I would not have added the limit, but probably more by lack of care 
than because I think it is not useful. Now it's here, and if it is common to 
deal with that large boolean queries then there is a question of whether Lucene 
is the right tool for the job since all the efforts we make at index-time in 
order to make reads sequential at search time and keep the search-time memory 
footprint low are pointless, especially if you're using NIOFSDirectory. So I'm 
on the fence about removing this setting or changing its default value. I agree 
the fact it is static is not nice, but it has the good side-effect that we do 
not have to set options eg. on query parsers in order to make them apply it.

bq. Having a static variable where setting it in one core affects others may 
have made sense N years ago, but now it's generating problems or we wouldn't be 
having this discussion

It wouldn't be an issue if it was a cluster setting? What is the value of 
letting one user generate huge boolean queries and prevent others?

> Make boolean query clause limit configurable per-query
> --
>
> Key: LUCENE-7880
> URL: https://issues.apache.org/jira/browse/LUCENE-7880
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Yonik Seeley
>
> As we know, the magic BooleanQuery.maxClauseCount has bitten many people over 
> time.
> It's also a static, which really hurts multi-tenancy (i.e. we can't have 
> different settings for different users, clients, or use-cases).
> If we want to keep this static as a default, then at least we should allow it 
> to be overridden on a per-query basis when we know it is the desired behavior 
> and not a bug.
> Perhaps the simplest way to achieve this would be a setter on 
> BooleanQuery.Builder that configures the limit for that instance only?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (SOLR-10923) AutoScalingHandlerTest.testPolicyAndPreferences() failure: Adding a policy with 'cores' attribute should not have succeeded

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat reassigned SOLR-10923:
---

Assignee: Cao Manh Dat

> AutoScalingHandlerTest.testPolicyAndPreferences() failure: Adding a policy 
> with 'cores' attribute should not have succeeded
> ---
>
> Key: SOLR-10923
> URL: https://issues.apache.org/jira/browse/SOLR-10923
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Cao Manh Dat
>
> Policeman Jenkins found a reproducing seed 
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19914]:
> {noformat}
> Checking out Revision b1b566f57bba46cadae33bc8198246fa05609287 
> (refs/remotes/origin/master)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=AutoScalingHandlerTest -Dtests.method=testPolicyAndPreferences 
> -Dtests.seed=DB220AFF163D3283 -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=to-TO -Dtests.timezone=America/Montserrat -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 0.01s J2 | 
> AutoScalingHandlerTest.testPolicyAndPreferences <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Adding a policy with 
> 'cores' attribute should not have succeeded.
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([DB220AFF163D3283:7AEA54D66F7B348D]:0)
>[junit4]>  at 
> org.apache.solr.cloud.autoscaling.AutoScalingHandlerTest.testPolicyAndPreferences(AutoScalingHandlerTest.java:83)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]>  at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]>  at 
> java.base/java.lang.reflect.Method.invoke(Method.java:564)
> [...]
>[junit4]   2> NOTE: test params are: codec=Lucene70, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=to-TO, 
> timezone=America/Montserrat
>[junit4]   2> NOTE: Linux 4.10.0-21-generic i386/Oracle Corporation 9-ea 
> (32-bit)/cpus=8,threads=1,free=151310248,total=411041792
> {noformat}
> Another reproducing seed 
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19916]:
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=AutoScalingHandlerTest -Dtests.method=testPolicyAndPreferences 
> -Dtests.seed=3D04238B59F9D32D -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=en-MW -Dtests.timezone=America/Recife -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 0.02s J2 | 
> AutoScalingHandlerTest.testPolicyAndPreferences <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Adding a policy with 
> 'cores' attribute should not have succeeded.
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([3D04238B59F9D32D:9CCC7DA220BFD523]:0)
>[junit4]>  at 
> org.apache.solr.cloud.autoscaling.AutoScalingHandlerTest.testPolicyAndPreferences(AutoScalingHandlerTest.java:83)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]>  at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]>  at 
> java.base/java.lang.reflect.Method.invoke(Method.java:564)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10915) Make SolrClient classes extendable without code duplication

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski commented on SOLR-10915:


A few responses:

bq. Where a Builder class has been added, it doesn't have any explicit 
visibility, while the existing Builder classes are explicitly marked public.

That's a good point/question.  Most of the builders added in this patch were 
for trivial SolrClient subclasses that were only used in that same Java file. 
Because of that I didn't give visibility a ton of thought- I just left them as 
package-scoped.  But we could probably do something more thoughtful on a 
case-by-case basis here if it's worth it.

bq. The new Builder classes do not have any fluent "with*" methods, only a 
multiple-argument constructor.

The convention I've been trying to follow is that truly required arguments 
should go in the {{Builder()}} ctor, to force users to provide them.  Optional 
ones I've been creating fluent {{withFoo}} methods for.  The lack of added 
{{withFoo}} methods in this patch is (I think) just a coincidence related to 
the sort of SolrClient subclasses I ran into with this patch (created with a 
very directed purpose, with limited visibility, for 1 or 2 Java files).  If I 
made any mistakes following that convention, or you would prefer deviating from 
the convention for other reasons, I'd be fine with that too.

bq. The remaining non-deprecated constructor (before this patch) is likely 
private or protected, and I don't think we have any reason to worry about 
deprecating it before we change it to one that accepts a Builder.

That seems reasonable to me, but I also see an argument that methods marked as 
protected are a part of our API and we'd need to give more warning.  Either way 
would be fine with me.

> Make SolrClient classes extendable without code duplication
> ---
>
> Key: SOLR-10915
> URL: https://issues.apache.org/jira/browse/SOLR-10915
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: clients - java
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10915.patch.with-deprecations, 
> SOLR-10915.patch.without-deprecations
>
>
> SolrClient used to be easily extendable but our move to Builder pattern has 
> made it impossible to extend those classes without code duplication. 
> As an example, if we wanted to extend HttpSolrClient we would also want to 
> extend the Builder. The problem is that the constructor of the main class, 
> does not accept the builder object but explicit parameters, and the inherited 
> class doesn't have access to any of those values from the Builder object as 
> they are all private. 
> Generally, we'd want to have the client object constructor accept the 
> Builder, instead of explicit values, and also make the Builder values 
> protected so the inherited classes could use them.
> I'm marking this as a blocker for 7.0 as this is an important piece that 
> needs to be fixed before the major release, specially now that we know that 
> this problem exists.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6665/
Java: 64bit/jdk1.8.0_131 -XX:-UseCompressedOops -XX:+UseSerialGC

9 tests failed.
FAILED:  
org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection

Error Message:
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\server\solr\configsets\data_driven_schema_configs\conf
 not found!

Stack Trace:
java.lang.AssertionError: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\server\solr\configsets\data_driven_schema_configs\conf
 not found!
at 
__randomizedtesting.SeedInfo.seed([8FD675A129796297:9CB547CE1816DB31]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection(SolrCloudExampleTest.java:77)
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 
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 

[jira] [Commented] (SOLR-9623) Disable remote streaming by default

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-9623:
--

Also these {{SolrRequestParserTest}} failures ("Remote Streaming is disabled.") 
[https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1384/]:

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=SolrRequestParserTest -Dtests.method=testStreamURL 
-Dtests.seed=E690D262D7E2F6BE -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=de-DE -Dtests.timezone=America/Aruba -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] ERROR   0.01s J2 | SolrRequestParserTest.testStreamURL <<<
   [junit4]> Throwable #1: org.apache.solr.common.SolrException: Remote 
Streaming is disabled.
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([E690D262D7E2F6BE:BFA5EC71A3C03B8B]:0)
   [junit4]>at 
org.apache.solr.servlet.SolrRequestParsers.buildRequestFrom(SolrRequestParsers.java:190)
   [junit4]>at 
org.apache.solr.servlet.SolrRequestParsers.buildRequestFrom(SolrRequestParsers.java:178)
   [junit4]>at 
org.apache.solr.servlet.SolrRequestParserTest.testStreamURL(SolrRequestParserTest.java:140)
[...]
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=SolrRequestParserTest -Dtests.method=testStreamFile 
-Dtests.seed=E690D262D7E2F6BE -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=de-DE -Dtests.timezone=America/Aruba -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] ERROR   0.00s J2 | SolrRequestParserTest.testStreamFile <<<
   [junit4]> Throwable #1: org.apache.solr.common.SolrException: Remote 
Streaming is disabled.
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([E690D262D7E2F6BE:795923A829FF9159]:0)
   [junit4]>at 
org.apache.solr.servlet.SolrRequestParsers.buildRequestFrom(SolrRequestParsers.java:205)
   [junit4]>at 
org.apache.solr.servlet.SolrRequestParsers.buildRequestFrom(SolrRequestParsers.java:178)
   [junit4]>at 
org.apache.solr.servlet.SolrRequestParserTest.testStreamFile(SolrRequestParserTest.java:162)
{noformat}

> Disable remote streaming by default
> ---
>
> Key: SOLR-9623
> URL: https://issues.apache.org/jira/browse/SOLR-9623
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Blocker
>  Labels: configset
> Fix For: master (7.0)
>
> Attachments: SOLR-9623.patch, SOLR-9623.patch, SOLR-9623.patch, 
> SOLR-9623.patch
>
>
> As we set more and more config settings suitable for production use, perhaps 
> it is time to disable remoteStreaming by default, and document how to enable 
> it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-9623) Disable remote streaming by default

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-9623:
--

{{git bisect}} blames the commit on this issue for a reproducing 
{{CacheHeaderTest.testCacheVetoHandler()}} failure 
[https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1384/]:

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=CacheHeaderTest 
-Dtests.method=testCacheVetoHandler -Dtests.seed=E690D262D7E2F6BE 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=nl-NL 
-Dtests.timezone=America/Panama -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] FAILURE 0.04s J0 | CacheHeaderTest.testCacheVetoHandler <<<
   [junit4]> Throwable #1: java.lang.AssertionError: expected:<200> but 
was:<400>
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([E690D262D7E2F6BE:3636A5FEF7DCEF8F]:0)
   [junit4]>at 
org.apache.solr.servlet.CacheHeaderTest.testCacheVetoHandler(CacheHeaderTest.java:67)
{noformat}

> Disable remote streaming by default
> ---
>
> Key: SOLR-9623
> URL: https://issues.apache.org/jira/browse/SOLR-9623
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Blocker
>  Labels: configset
> Fix For: master (7.0)
>
> Attachments: SOLR-9623.patch, SOLR-9623.patch, SOLR-9623.patch, 
> SOLR-9623.patch
>
>
> As we set more and more config settings suitable for production use, perhaps 
> it is time to disable remoteStreaming by default, and document how to enable 
> it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10915) Make SolrClient classes extendable without code duplication

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-10915:
-

If I'm understanding what's going on here, I really like it.  I hadn't thought 
of using the builder in the constructor ... that's a really good idea.

It sounds like this would make both the client itself and its builder 
user-extendable.

I did notice a couple of things in the patch, not sure if these are actual 
problems or a lack of understanding on my part:

 * Where a Builder class has been added, it doesn't have any explicit 
visibility, while the existing Builder classes are explicitly marked public.
 * The new Builder classes do not have any fluent "with*" methods, only a 
multiple-argument constructor.  The existing ones have simple constructors 
(no-arg and in some cases one-arg) and fluent methods for configuration.

As for how to handle removal and deprecation ... are we at a point where we can 
simply remove the other constructors in master/branch_7x?  They should have 
already been deprecated when the Builder pattern was implemented.  The 
remaining non-deprecated constructor (before this patch) is likely private or 
protected, and I don't think we have any reason to worry about deprecating it 
before we change it to one that accepts a Builder.


> Make SolrClient classes extendable without code duplication
> ---
>
> Key: SOLR-10915
> URL: https://issues.apache.org/jira/browse/SOLR-10915
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: clients - java
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10915.patch.with-deprecations, 
> SOLR-10915.patch.without-deprecations
>
>
> SolrClient used to be easily extendable but our move to Builder pattern has 
> made it impossible to extend those classes without code duplication. 
> As an example, if we wanted to extend HttpSolrClient we would also want to 
> extend the Builder. The problem is that the constructor of the main class, 
> does not accept the builder object but explicit parameters, and the inherited 
> class doesn't have access to any of those values from the Builder object as 
> they are all private. 
> Generally, we'd want to have the client object constructor accept the 
> Builder, instead of explicit values, and also make the Builder values 
> protected so the inherited classes could use them.
> I'm marking this as a blocker for 7.0 as this is an important piece that 
> needs to be fixed before the major release, specially now that we know that 
> this problem exists.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3798/
Java: 32bit/jdk1.8.0_131 -server -XX:+UseSerialGC

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

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

Stack Trace:
java.lang.AssertionError: expected:<3> but was:<1>
at 
__randomizedtesting.SeedInfo.seed([94CAC7A5936EB6AE:DCBFB311955D993B]: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:522)
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:748)


FAILED:  org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey

Error Message:
There are still 

[JENKINS] Lucene-Solr-Tests-master - Build # 1884 - Unstable

[Apache Jenkins Server]

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

9 tests failed.
FAILED:  
org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection

Error Message:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/server/solr/configsets/data_driven_schema_configs/conf
 not found!

Stack Trace:
java.lang.AssertionError: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/server/solr/configsets/data_driven_schema_configs/conf
 not found!
at 
__randomizedtesting.SeedInfo.seed([E690D262D7E2F6BE:F5F3E00DE68D4F18]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection(SolrCloudExampleTest.java:77)
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 
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 

[jira] [Commented] (LUCENE-7880) Make boolean query clause limit configurable per-query

[Alan Woodward (JIRA)]

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

Alan Woodward commented on LUCENE-7880:
---

bq. we should find a heuristic that can detect when a TermInSetQuery will 
perform better than a BooleanQuery with good confidence

Exactly this!  Which is what we don't have at the moment, we have an API that 
throws a RuntimeException instead...

What the heuristic should be is an interesting question in itself though.  When 
is it cheaper to build a DocIdSet up-front?  I guess if we know that all of the 
leaves of the disjunction have low costs?  Could we add a scorerSupplier to 
BooleanWeight?  Or does the bulk-scoring BooleanScorer actually cope with this 
anyway?

> Make boolean query clause limit configurable per-query
> --
>
> Key: LUCENE-7880
> URL: https://issues.apache.org/jira/browse/LUCENE-7880
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Yonik Seeley
>
> As we know, the magic BooleanQuery.maxClauseCount has bitten many people over 
> time.
> It's also a static, which really hurts multi-tenancy (i.e. we can't have 
> different settings for different users, clients, or use-cases).
> If we want to keep this static as a default, then at least we should allow it 
> to be overridden on a per-query basis when we know it is the desired behavior 
> and not a bug.
> Perhaps the simplest way to achieve this would be a setter on 
> BooleanQuery.Builder that configures the limit for that instance only?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-9623) Disable remote streaming by default

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-9623:
--

{{TestRemoteStreaming.testStreamUrl()}} now fails for me without a seed (for an 
example, see 
{{https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19916/}})

> Disable remote streaming by default
> ---
>
> Key: SOLR-9623
> URL: https://issues.apache.org/jira/browse/SOLR-9623
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Blocker
>  Labels: configset
> Fix For: master (7.0)
>
> Attachments: SOLR-9623.patch, SOLR-9623.patch, SOLR-9623.patch, 
> SOLR-9623.patch
>
>
> As we set more and more config settings suitable for production use, perhaps 
> it is time to disable remoteStreaming by default, and document how to enable 
> it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10911) Fix inspection warnings reported by IntelliJ

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-10911:
---

Hey Shalin:

If you happen across a good way to _ignore_ some lint warnings, please pass it 
on (yes, I'm lazy).

Background. When looking through some of the JavaBinCodec precommit WARNINGs, I 
saw some other warnings that should be ignored. Especially the reference 
counted objects (IndexWriter comes to mind). So if we ever want to make 
precommit fail on warnings, we need a way to _not_ generate warnings in some 
specific cases.

Strictly if you happen to see something

> Fix inspection warnings reported by IntelliJ
> 
>
> Key: SOLR-10911
> URL: https://issues.apache.org/jira/browse/SOLR-10911
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: master (7.0)
>
>
> I'd like to fix some warnings reported by IntelliJ Idea that seem pertinent.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: JIRA Status - Finding Patch Submissions

[Allen Wittenauer]

On 2017-05-17 19:10 (-0700), David Smiley  wrote: 
> > How else other than a comment could the system communicate results back to
> > the user? Or do you mean that whatever runs should post a comment, but
> > suppress email notification somehow.
> >
> 
> Yes; that.  The rationale being that if someone posts a patch, it'll become
> inevitable that there will be a follow-up bot comment.  It's not a big deal
> though.

Hi.  I hope you don't mind if I chime in here. :)

When the original JIRA support for Apache Yetus was written, we 
actually looked at a way to prevent comments from getting emailed out.  At that 
point in time, the REST interface lacked the functionality. Much sadness. But 
good news: JIRA 7.2.0 does include the necessary magic:  
https://jira.atlassian.com/browse/JRASERVER-34423  .  Now we just have to wait 
until the ASF instance gets upgraded.

> > If the state is set automatically, how do we know when to set it?
> >
> > Maybe this could be an extra (optional?) step for the committer looking at
> > the issue? Change to "Patch Available" triggers a run on the most recent
> > attached patch?
> >
> 
> +1 nice idea; seems straight-forward compared to other ideas.  I don't
> think we need to limit this transition to only committers though; even the
> submitter might do it to demonstrate their patch is ready.

Just to fill in some blanks as to how the current projects are using 
it  

Submitter sets JIRA issue to Patch Available. There is a job on ASF 
Jenkins called "Precommit-Admin" that uses a JIRA filter to look for (group of 
projects)+"Patch Available"+(updated time frame).  It then submits any found 
issues to Precommit-(project)-build with the issue id.  For Solr, Lucene, or 
any other project, it's just a matter of adding your project to the JIRA filter 
and creating the precommit job.  Manually running a job is simple, because you 
just use that project's dedicated precommit job and a supplied id.

[I'm in the process of "rescuing" the precommit-admin codebase from 
within the (old) Hadoop svn tree into the much more public Yetus source tree, 
writing documentation, etc.  Right now, this is all tribal knowledge. :( ]

 


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

[jira] [Commented] (LUCENE-7880) Make boolean query clause limit configurable per-query

[Erick Erickson (JIRA)]

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

Erick Erickson commented on LUCENE-7880:


Adrien:

So how would you fix the design? Let's forget the foregoing discussion and 
start with a clean-slate. You obviously know lots more about Lucene than I do 
so what's solutions can you think of?

There are solid arguments why this limit is too low. Complexifying Lucene isn't 
ideal either. Whether it's making the limit configurable per-query is the right 
solution is obviously debatable.

So what would work? Having a static variable where setting it in one core 
affects others may have made sense N years ago, but now it's generating 
problems or we wouldn't be having this discussion. If you were writing this 
from scratch would you advocate the current design? If not, can you think of a 
different design that wouldn't have this limitation?





> Make boolean query clause limit configurable per-query
> --
>
> Key: LUCENE-7880
> URL: https://issues.apache.org/jira/browse/LUCENE-7880
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Yonik Seeley
>
> As we know, the magic BooleanQuery.maxClauseCount has bitten many people over 
> time.
> It's also a static, which really hurts multi-tenancy (i.e. we can't have 
> different settings for different users, clients, or use-cases).
> If we want to keep this static as a default, then at least we should allow it 
> to be overridden on a per-query basis when we know it is the desired behavior 
> and not a bug.
> Perhaps the simplest way to achieve this would be a setter on 
> BooleanQuery.Builder that configures the limit for that instance only?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10864) Add static (test only) boolean to PointField indicating 'precisionStep' should be ignored so we can simplify points randomization in our schemas

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10864:
---

bq. ...but actually in hindsight, I think your idea is just plain objectively 
better, because it would keep the usage simpler... (almost) every numeric field 
type should have docValues="${solr.tests.numeric.dv}"  Sound Good?

+1

bq. one other question I had was about changing the semantics of the current 
solr.tests.preferPointFields users can set ... it can currently only be used to 
"prefer points" for tests that don't have @SuppressPointFields, but I think it 
would be better to change that to solr.tests.use.numeric.points  any 
objections?

+1

> Add static (test only) boolean to PointField indicating 'precisionStep' 
> should be ignored so we can simplify points randomization in our schemas
> 
>
> Key: SOLR-10864
> URL: https://issues.apache.org/jira/browse/SOLR-10864
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: master (7.0)
>
> Attachments: SOLR-10864.patch, SOLR-10864.patch
>
>
> (I'm spinning this idea out of parent jira SOLR-10807 so that it gets it's 
> own jira# w/ it's own summary for increased visibility/comments)
> In the interest of making it easier & more straight forward to get good 
> randomized test coverage of Points fields, I'd like to add the following to 
> the {{PointField}} class...
> {code}
>  /**
>   * 
>   * The Test framework can set this global variable to instruct PointField 
> that
>   * (on init) it should be tollerant of the precisionStep 
> argument used by TrieFields.
>   * This allows for simple randomization of TrieFields and PointFields w/o 
> extensive duplication
>   * of fieldType/ declarations.
>   * 
>   *
>   * NOTE: When {@link TrieField} is removed, this boolean must also be 
> removed
>   *
>   * @lucene.internal
>   * @lucene.experimental
>   */
>  public static boolean TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS = false;
>  /** 
>   * NOTE: This method can be removed completely when
>   * {@link #TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS} is removed 
>   */
>  @Override
>  protected void init(IndexSchema schema, Map args) {
>super.init(schema, args);
>if (TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS) {
>  args.remove("precisionStep");
>}
>  }
> {code}
> Then in SolrTestCaseJ4, set 
> {{PointField.TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS}} on a class by class 
> basis when randomizing Trie/Points (and unset \@AfterClass).
> (details to follow in comment)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10574) Choose a default configset for Solr 7

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10574:
---

Looks like there are some failing tests after this commit - see 
[https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1384/] and 
[https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19916/]. I think 
these are the affected tests:

org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection
org.apache.solr.util.TestSolrCLIRunExample.testInteractiveSolrCloudExample
org.apache.solr.util.TestSolrCLIRunExample.testSchemalessExample



> Choose a default configset for Solr 7
> -
>
> Key: SOLR-10574
> URL: https://issues.apache.org/jira/browse/SOLR-10574
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10574.patch, SOLR-10574.patch, SOLR-10574.patch, 
> SOLR-10574.patch
>
>
> Currently, the data_driven_schema_configs is the default configset when 
> collections are created using the bin/solr script and no configset is 
> specified.
> However, that may not be the best choice. We need to decide which is the best 
> choice, out of the box, considering many users might create collections 
> without knowing about the concept of a configset going forward.
> (See also SOLR-10272)
> Proposed changes:
> # Remove data_driven_schema_configs and basic_configs
> # Introduce a combined configset, {{_default}} based on the above two 
> configsets.
> # Build a "toggleable" data driven functionality into {{_default}}
> Usage:
> # Create a collection (using _default configset)
> # Data driven / schemaless functionality is enabled by default; so just start 
> indexing your documents.
> # If don't want data driven / schemaless, disable this behaviour: {code}
> curl http://host:8983/solr/coll1/config -d '{"set-user-property": 
> {"update.autoCreateFields":"false"}}'
> {code}
> # Create schema fields using schema API, and index documents



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-10923) AutoScalingHandlerTest.testPolicyAndPreferences() failure: Adding a policy with 'cores' attribute should not have succeeded

[Steve Rowe (JIRA)]

Steve Rowe created SOLR-10923:
-

 Summary: AutoScalingHandlerTest.testPolicyAndPreferences() 
failure: Adding a policy with 'cores' attribute should not have succeeded
 Key: SOLR-10923
 URL: https://issues.apache.org/jira/browse/SOLR-10923
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Steve Rowe


Policeman Jenkins found a reproducing seed 
[https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19914]:

{noformat}
Checking out Revision b1b566f57bba46cadae33bc8198246fa05609287 
(refs/remotes/origin/master)
[...]
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=AutoScalingHandlerTest -Dtests.method=testPolicyAndPreferences 
-Dtests.seed=DB220AFF163D3283 -Dtests.multiplier=3 -Dtests.slow=true 
-Dtests.locale=to-TO -Dtests.timezone=America/Montserrat -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] FAILURE 0.01s J2 | AutoScalingHandlerTest.testPolicyAndPreferences 
<<<
   [junit4]> Throwable #1: java.lang.AssertionError: Adding a policy with 
'cores' attribute should not have succeeded.
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([DB220AFF163D3283:7AEA54D66F7B348D]:0)
   [junit4]>at 
org.apache.solr.cloud.autoscaling.AutoScalingHandlerTest.testPolicyAndPreferences(AutoScalingHandlerTest.java:83)
   [junit4]>at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   [junit4]>at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   [junit4]>at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   [junit4]>at 
java.base/java.lang.reflect.Method.invoke(Method.java:564)
[...]
   [junit4]   2> NOTE: test params are: codec=Lucene70, 
sim=RandomSimilarity(queryNorm=true): {}, locale=to-TO, 
timezone=America/Montserrat
   [junit4]   2> NOTE: Linux 4.10.0-21-generic i386/Oracle Corporation 9-ea 
(32-bit)/cpus=8,threads=1,free=151310248,total=411041792
{noformat}

Another reproducing seed 
[https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19916]:

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=AutoScalingHandlerTest -Dtests.method=testPolicyAndPreferences 
-Dtests.seed=3D04238B59F9D32D -Dtests.multiplier=3 -Dtests.slow=true 
-Dtests.locale=en-MW -Dtests.timezone=America/Recife -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII
   [junit4] FAILURE 0.02s J2 | AutoScalingHandlerTest.testPolicyAndPreferences 
<<<
   [junit4]> Throwable #1: java.lang.AssertionError: Adding a policy with 
'cores' attribute should not have succeeded.
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([3D04238B59F9D32D:9CCC7DA220BFD523]:0)
   [junit4]>at 
org.apache.solr.cloud.autoscaling.AutoScalingHandlerTest.testPolicyAndPreferences(AutoScalingHandlerTest.java:83)
   [junit4]>at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   [junit4]>at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   [junit4]>at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   [junit4]>at 
java.base/java.lang.reflect.Method.invoke(Method.java:564)
{noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-4586) Eliminate the maxBooleanClauses limit

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-4586:
--

[~janhoy] 
"last core wins" is my shorthand for the fact that this is static in Lucene. So 
when a core loads and it encounters a  entry it sets this 
static. 

So let's say core1 has a value of 64 and core2 has a value of 100,000.
If core2 loads last both core1 and core2 have a limit of 100,000. 
If core1 loads last both core1 and core2 have a limit of 64.

And since you can load cores in parallel it's not even determinate which one 
will always load last.

This is especially problematic in SolrCloud when you have heterogeneous 
collections sharing JVMs and users are left wondering why they got this 
exception after bumping the limit up. Not to mention adding a replica to some 
core someplace may suddenly cause the replicas on that JVM to fail. Imagine my 
limit is 100,000 for collection1 and all the replicas on a particular JVM are 
from collection1. Now I create a new collection with a different config set. 
BOOM.

> Eliminate the maxBooleanClauses limit
> -
>
> Key: SOLR-4586
> URL: https://issues.apache.org/jira/browse/SOLR-4586
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Affects Versions: 4.2
> Environment: 4.3-SNAPSHOT 1456767M - ncindex - 2013-03-15 13:11:50
>Reporter: Shawn Heisey
> Fix For: master (7.0)
>
> Attachments: SOLR-4586.patch, SOLR-4586.patch, SOLR-4586.patch, 
> SOLR-4586.patch, SOLR-4586.patch, SOLR-4586.patch, 
> SOLR-4586_verify_maxClauses.patch
>
>
> In the #solr IRC channel, I mentioned the maxBooleanClauses limitation to 
> someone asking a question about queries.  Mark Miller told me that 
> maxBooleanClauses no longer applies, that the limitation was removed from 
> Lucene sometime in the 3.x series.  The config still shows up in the example 
> even in the just-released 4.2.
> Checking through the source code, I found that the config option is parsed 
> and the value stored in objects, but does not actually seem to be used by 
> anything.  I removed every trace of it that I could find, and all tests still 
> pass.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+173) - Build # 19916 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19916/
Java: 64bit/jdk-9-ea+173 -XX:+UseCompressedOops -XX:+UseParallelGC

9 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.AutoScalingHandlerTest.testPolicyAndPreferences

Error Message:
Adding a policy with 'cores' attribute should not have succeeded.

Stack Trace:
java.lang.AssertionError: Adding a policy with 'cores' attribute should not 
have succeeded.
at 
__randomizedtesting.SeedInfo.seed([3D04238B59F9D32D:9CCC7DA220BFD523]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.autoscaling.AutoScalingHandlerTest.testPolicyAndPreferences(AutoScalingHandlerTest.java:83)
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:564)
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)


FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.SolrSchemalessExampleTest

Error Message:
Source 
'/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/server/solr/configsets/data_driven_schema_configs/conf'
 does not exist

Stack 

[jira] [Comment Edited] (LUCENE-7870) Use cl.loadClass(...) instead of Class.forName(..., cl) in SPIClassIterator

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on LUCENE-7870 at 6/20/17 2:49 PM:


Hi Andreas,
this issue should be solved in Lucene 7.0. We will not backport this as it 
breaks backwards compatibility: We no longer use the context class loader for 
looking up services. It takes the class loader that defined the interface. If 
you require another one (e.g. in OSGI without using buddy classloading) you can 
call Codec.reloadCodecs(ClassLoader) and similar methods. See the MIGRATE.txt 
in Lucene 7.


was (Author: thetaphi):
Hi Andreas,
this issue should be solved in Lucene 7.0. We will not backport this as it 
breaks backwards compatibility: We no longer use the context class loader for 
looking up services. It takes the class loader that defined the interface. If 
you require another one (e.g. in OSGI without using buddy classloading) you can 
call Codec.reloadCodes(ClassLoader) and similar methods. See the MIGRATE.txt in 
Lucene 7.

> Use cl.loadClass(...) instead of Class.forName(..., cl) in SPIClassIterator
> ---
>
> Key: LUCENE-7870
> URL: https://issues.apache.org/jira/browse/LUCENE-7870
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 5.2.1, 6.1
> Environment: Eclipse Equinox 4.7
>Reporter: Andreas Sewe
>
> This issue is initially described in [Eclipse Bug 
> 517935|https://bugs.eclipse.org/bugs/show_bug.cgi?id=517935] and prevents 
> multiple versions of Lucene Core coexisting in an Equinox environment (FYI, 
> Equinox is the OSGi container used by the Eclipse IDE).
> Here’s how the problem manifests: While Equinox cleanly separates two 
> versions of the same Lucene Core bundle (e.g., 
> {{org.apache.lucene.core_5.2.1}} and  {{org.apache.lucene.core_6.1.0}}) using 
> two different bundle class loaders, it uses a single context classloader for 
> all threads: the 
> [{{ContextFinder}}|https://wiki.eclipse.org/Context_Class_Loader_Enhancements#Context_Finder_2].
>  When asked to load a class, the {{ContextFinder}} *initiates* a search 
> through all bundle class loaders currently “on“ the call stack; the class to 
> be loaded is then *defined* by the respective bundle’s class loader.
> And here is where the use of {{Class.forName(..., classLoader)}} rather than 
> {{classLoader.loadClass(...)}} causes problems. Consider the following 
> sequence of events:
> # The {{NamedSPILoader}} of bundle {{o.a.l.core_5.2.1}} (re)loads some 
> service (e.g., the {{Lucene50PostingFormat}}).
> ## It (through {{SPIClassIterator}}) first uses {{Class.forName}} with the 
> bundle class loader of {{o.a.l.core_5.2.1}} (as per LUCENE-4713) to 
> successfully load {{Lucene50PostingFormat}} from the {{o.a.l.core_5.2.1}} 
> bundle.
> ## Then (through another {{SPIClassIterator}}) it uses {{Class.forName}} with 
> the thread’s context class loader (here: {{ContextFinder}}) to load 
> {{Lucene50PostingFormat}}. The {{ContextFinder}} delegates loading to the 
> {{o.a.l.core_5.2.1}} bundle’s class loader, as that bundle is topmost on the 
> call stack. This bundle class loader (again) successfully loads 
> {{Lucene50PostingFormat}} from the {{o.a.l.core_5.2.1}} bundle.
> # Later, the {{NamedSPILoader}} of *another* bundle {{o.a.l.core_6.1.0}} 
> loads the {{Lucene50PostingFormat}} service.
> ## It (through {{SPIClassIterator}}) first uses {{Class.forName}} with the 
> bundle class loader of {{o.a.l.core_6.1.0}} to successfully load 
> {{Lucene50PostingFormat}} from the {{o.a.l.core_6.1.0}} bundle.
> ## Then (through another {{SPIClassIterator}}) it uses {{Class.forName}} with 
> the thread’s context class loader (the same {{ContextFinder}} again) to load 
> {{Lucene50PostingFormat}}. As {{Class.forName}} remembers that the 
> {{ContextFinder}} has successfully initiated the loading of 
> {{Lucene50PostingFormat}} before, it simply returns the {{Class}} instance 
> defined earlier in step _1.2_. But that class was defined by a different 
> bundle class loader, namely that of {{o.a.l.core_5.2.1}}! This cache look up 
> happens in native code; the {{ContextFinder}}‘s {{loadClass}} method isn’t 
> even called, so there’s no way it can load the class from the 
> {{o.a.l.core_6.1.0}} bundle, even though it now is topmost on the stack.
> ## Casting the {{Lucene50PostingFormat}} loading from bundle 
> {{o.a.l.core_5.2.1}} to {{PostingFormat}} from bundle {{o.a.l.core_6.1.0}} 
> then fails, leaving the {{o.a.l.core_6.1.0}} bundle in a broken state.
> It {{SPIClassIterator.next()}} would use {{classLoader.loadClass(...)}} 
> rather than {{Class.forName(..., classLoader}}), then class loading in step 
> _1.2_ wouldn’t *lock in* the {{Lucene50PostingFormat}} class from 
> 

[jira] [Commented] (LUCENE-7870) Use cl.loadClass(...) instead of Class.forName(..., cl) in SPIClassIterator

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-7870:
---

Hi Andreas,
this issue should be solved in Lucene 7.0. We will not backport this as it 
breaks backwards compatibility: We no longer use the context class loader for 
looking up services. It takes the class loader that defined the interface. If 
you require another one (e.g. in OSGI without using buddy classloading) you can 
call Codec.reloadCodes(ClassLoader) and similar methods. See the MIGRATE.txt in 
Lucene 7.

> Use cl.loadClass(...) instead of Class.forName(..., cl) in SPIClassIterator
> ---
>
> Key: LUCENE-7870
> URL: https://issues.apache.org/jira/browse/LUCENE-7870
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 5.2.1, 6.1
> Environment: Eclipse Equinox 4.7
>Reporter: Andreas Sewe
>
> This issue is initially described in [Eclipse Bug 
> 517935|https://bugs.eclipse.org/bugs/show_bug.cgi?id=517935] and prevents 
> multiple versions of Lucene Core coexisting in an Equinox environment (FYI, 
> Equinox is the OSGi container used by the Eclipse IDE).
> Here’s how the problem manifests: While Equinox cleanly separates two 
> versions of the same Lucene Core bundle (e.g., 
> {{org.apache.lucene.core_5.2.1}} and  {{org.apache.lucene.core_6.1.0}}) using 
> two different bundle class loaders, it uses a single context classloader for 
> all threads: the 
> [{{ContextFinder}}|https://wiki.eclipse.org/Context_Class_Loader_Enhancements#Context_Finder_2].
>  When asked to load a class, the {{ContextFinder}} *initiates* a search 
> through all bundle class loaders currently “on“ the call stack; the class to 
> be loaded is then *defined* by the respective bundle’s class loader.
> And here is where the use of {{Class.forName(..., classLoader)}} rather than 
> {{classLoader.loadClass(...)}} causes problems. Consider the following 
> sequence of events:
> # The {{NamedSPILoader}} of bundle {{o.a.l.core_5.2.1}} (re)loads some 
> service (e.g., the {{Lucene50PostingFormat}}).
> ## It (through {{SPIClassIterator}}) first uses {{Class.forName}} with the 
> bundle class loader of {{o.a.l.core_5.2.1}} (as per LUCENE-4713) to 
> successfully load {{Lucene50PostingFormat}} from the {{o.a.l.core_5.2.1}} 
> bundle.
> ## Then (through another {{SPIClassIterator}}) it uses {{Class.forName}} with 
> the thread’s context class loader (here: {{ContextFinder}}) to load 
> {{Lucene50PostingFormat}}. The {{ContextFinder}} delegates loading to the 
> {{o.a.l.core_5.2.1}} bundle’s class loader, as that bundle is topmost on the 
> call stack. This bundle class loader (again) successfully loads 
> {{Lucene50PostingFormat}} from the {{o.a.l.core_5.2.1}} bundle.
> # Later, the {{NamedSPILoader}} of *another* bundle {{o.a.l.core_6.1.0}} 
> loads the {{Lucene50PostingFormat}} service.
> ## It (through {{SPIClassIterator}}) first uses {{Class.forName}} with the 
> bundle class loader of {{o.a.l.core_6.1.0}} to successfully load 
> {{Lucene50PostingFormat}} from the {{o.a.l.core_6.1.0}} bundle.
> ## Then (through another {{SPIClassIterator}}) it uses {{Class.forName}} with 
> the thread’s context class loader (the same {{ContextFinder}} again) to load 
> {{Lucene50PostingFormat}}. As {{Class.forName}} remembers that the 
> {{ContextFinder}} has successfully initiated the loading of 
> {{Lucene50PostingFormat}} before, it simply returns the {{Class}} instance 
> defined earlier in step _1.2_. But that class was defined by a different 
> bundle class loader, namely that of {{o.a.l.core_5.2.1}}! This cache look up 
> happens in native code; the {{ContextFinder}}‘s {{loadClass}} method isn’t 
> even called, so there’s no way it can load the class from the 
> {{o.a.l.core_6.1.0}} bundle, even though it now is topmost on the stack.
> ## Casting the {{Lucene50PostingFormat}} loading from bundle 
> {{o.a.l.core_5.2.1}} to {{PostingFormat}} from bundle {{o.a.l.core_6.1.0}} 
> then fails, leaving the {{o.a.l.core_6.1.0}} bundle in a broken state.
> It {{SPIClassIterator.next()}} would use {{classLoader.loadClass(...)}} 
> rather than {{Class.forName(..., classLoader}}), then class loading in step 
> _1.2_ wouldn’t *lock in* the {{Lucene50PostingFormat}} class from 
> {{org.apache.lucene.core_5.2.1}}; instead, step _2.2_ would perform a 
> completely independent look up that retrieves the class from the correct 
> bundle. The cast in step _2.3_ would then succeed.
> At Eclipse Orbit, we plan to distribute a [patched 
> version|https://git.eclipse.org/r/98804/] of Lucene Core, but obviously we 
> would like to see the (one-line) change included in the upstream project.
> BTW, if you fear that bypassing {{Class.forName}} “caching” affects 
> performance, then 

[jira] [Resolved] (LUCENE-7873) Remove context classloader from SPI lookups by default

[Uwe Schindler (JIRA)]

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

Uwe Schindler resolved LUCENE-7873.
---
Resolution: Fixed

> Remove context classloader from SPI lookups by default
> --
>
> Key: LUCENE-7873
> URL: https://issues.apache.org/jira/browse/LUCENE-7873
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
> Fix For: master (7.0)
>
> Attachments: LUCENE-7873.patch, LUCENE-7873.patch
>
>
> As discussed on LUCENE-7870, we should really remove the context class loader 
> from Lucene's SPI lookup (NamedSPLoader, SPIClassIterator, AnalysisSPI stuff).
> {quote}
> My idea would be (as stated before): Get rid of the Context Classloader in 
> SPI lookups! Lucene never uses it, it is just there for backwards 
> compatibility. The current setup of SPI does not work with modules of Java 9 
> and it does not work with stuff in completely different classloaders. So OSGI 
> fails in any case, if you have lucene-core.jar and 
> lucene-backwards-codecs.jar as OSGI modules, because both would use different 
> loaders. The context loader won't help.
> The problem is that we may break some apps that rely on the context loader 
> traversal. In my opinion, we may add a system property that is read on setup 
> of NamedSPILoader / SPIClassIterator that can be set to true (e.g. 
> lucene.useContextLoaderForSPI, defaulting to false). This may fix legacy apps 
> and new apps would only traverse the classloader that loaded lucene-core.jar.
> For Java 9 and "Lucene as Java 9 module") we have to refactor this anyways, 
> becaue we need to respect module-info,java and look for SPI exports.
> FYI: Context class loaders were the worst idea ever in Java. I personally 
> hate them and I would do anything - just to make them disappear from the 
> spec! When drinking beers with Mark Reinhold in Brussels, I am always 
> reminding him about this together with the inability to unmap byte buffers... 
> :-)
> {quote}
> Unfortunately the sysprop approach is the only way to handle this as this 
> must be done very early on JVM/Lucene setup. If somebody called 
> Codec.forName() its too late to change the default... But I am fine with 
> using a sysprop with AccessController.doPrivileged(), as this is only 
> required for those legacy WEBAPP stuff. Normal applications should see the 
> META-INF files on the application classloader anyways.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7873) Remove context classloader from SPI lookups by default

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on LUCENE-7873:
-

Commit 63a400528267e1ce396b53b162b64fb49e3e4e45 in lucene-solr's branch 
refs/heads/master from [~thetaphi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=63a4005 ]

LUCENE-7873: The SPI lookup of Codecs, PostingsFormats, DocValuesFormats and 
all analysis factories was changed to only inspect the current classloader that 
defined the interface class (lucene-core.jar)


> Remove context classloader from SPI lookups by default
> --
>
> Key: LUCENE-7873
> URL: https://issues.apache.org/jira/browse/LUCENE-7873
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
> Fix For: master (7.0)
>
> Attachments: LUCENE-7873.patch, LUCENE-7873.patch
>
>
> As discussed on LUCENE-7870, we should really remove the context class loader 
> from Lucene's SPI lookup (NamedSPLoader, SPIClassIterator, AnalysisSPI stuff).
> {quote}
> My idea would be (as stated before): Get rid of the Context Classloader in 
> SPI lookups! Lucene never uses it, it is just there for backwards 
> compatibility. The current setup of SPI does not work with modules of Java 9 
> and it does not work with stuff in completely different classloaders. So OSGI 
> fails in any case, if you have lucene-core.jar and 
> lucene-backwards-codecs.jar as OSGI modules, because both would use different 
> loaders. The context loader won't help.
> The problem is that we may break some apps that rely on the context loader 
> traversal. In my opinion, we may add a system property that is read on setup 
> of NamedSPILoader / SPIClassIterator that can be set to true (e.g. 
> lucene.useContextLoaderForSPI, defaulting to false). This may fix legacy apps 
> and new apps would only traverse the classloader that loaded lucene-core.jar.
> For Java 9 and "Lucene as Java 9 module") we have to refactor this anyways, 
> becaue we need to respect module-info,java and look for SPI exports.
> FYI: Context class loaders were the worst idea ever in Java. I personally 
> hate them and I would do anything - just to make them disappear from the 
> spec! When drinking beers with Mark Reinhold in Brussels, I am always 
> reminding him about this together with the inability to unmap byte buffers... 
> :-)
> {quote}
> Unfortunately the sysprop approach is the only way to handle this as this 
> must be done very early on JVM/Lucene setup. If somebody called 
> Codec.forName() its too late to change the default... But I am fine with 
> using a sysprop with AccessController.doPrivileged(), as this is only 
> required for those legacy WEBAPP stuff. Normal applications should see the 
> META-INF files on the application classloader anyways.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-10922) NPE in PeerSync

[Markus Jelsma (JIRA)]

Markus Jelsma created SOLR-10922:


 Summary: NPE in PeerSync
 Key: SOLR-10922
 URL: https://issues.apache.org/jira/browse/SOLR-10922
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.6
Reporter: Markus Jelsma
Priority: Minor
 Fix For: master (7.0)


{code}
Error while trying to recover. 
core=search_shard2_replica2:java.lang.NullPointerException
at org.apache.solr.update.PeerSync.alreadyInSync(PeerSync.java:381)
at org.apache.solr.update.PeerSync.sync(PeerSync.java:251)
at 
org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:439)
at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:284)
at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10317) Solr Nightly Benchmarks

[Michael Sun (JIRA)]

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

Michael Sun commented on SOLR-10317:


bq.the fluctuations are now been contained
[~vivek.nar...@uga.edu]  That's cool. What is the change to solve the 
fluctuations?


> Solr Nightly Benchmarks
> ---
>
> Key: SOLR-10317
> URL: https://issues.apache.org/jira/browse/SOLR-10317
> Project: Solr
>  Issue Type: Task
>Reporter: Ishan Chattopadhyaya
>  Labels: gsoc2017, mentor
> Attachments: changes-lucene-20160907.json, 
> changes-solr-20160907.json, managed-schema, 
> Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks.docx, 
> Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks-FINAL-PROPOSAL.pdf, 
> SOLR-10317.patch, solrconfig.xml
>
>
> Solr needs nightly benchmarks reporting. Similar Lucene benchmarks can be 
> found here, https://home.apache.org/~mikemccand/lucenebench/.
> Preferably, we need:
> # A suite of benchmarks that build Solr from a commit point, start Solr 
> nodes, both in SolrCloud and standalone mode, and record timing information 
> of various operations like indexing, querying, faceting, grouping, 
> replication etc.
> # It should be possible to run them either as an independent suite or as a 
> Jenkins job, and we should be able to report timings as graphs (Jenkins has 
> some charting plugins).
> # The code should eventually be integrated in the Solr codebase, so that it 
> never goes out of date.
> There is some prior work / discussion:
> # https://github.com/shalinmangar/solr-perf-tools (Shalin)
> # https://github.com/chatman/solr-upgrade-tests/blob/master/BENCHMARKS.md 
> (Ishan/Vivek)
> # SOLR-2646 & SOLR-9863 (Mark Miller)
> # https://home.apache.org/~mikemccand/lucenebench/ (Mike McCandless)
> # https://github.com/lucidworks/solr-scale-tk (Tim Potter)
> There is support for building, starting, indexing/querying and stopping Solr 
> in some of these frameworks above. However, the benchmarks run are very 
> limited. Any of these can be a starting point, or a new framework can as well 
> be used. The motivation is to be able to cover every functionality of Solr 
> with a corresponding benchmark that is run every night.
> Proposing this as a GSoC 2017 project. I'm willing to mentor, and I'm sure 
> [~shalinmangar] and [~markrmil...@gmail.com] would help here.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Closed] (SOLR-7190) Remove unused UninvertedField

[David Smiley (JIRA)]

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

David Smiley closed SOLR-7190.
--
   Resolution: Not A Problem
Fix Version/s: (was: 5.2)
   5.5

The title, "Remove unused UninvertedField" is no longer accurate -- it is used 
by the JSON Facet API {{FacetFieldProcessorByArrayUIF}} on some issue or 
another.  This is in turn used by SimpleFacets (classic/standard Solr faceting) 
via SOLR-8466 when facet.method=uif (which only happens when you explicitly ask 
for it like this). So I'm closing this issue.

> Remove unused UninvertedField
> -
>
> Key: SOLR-7190
> URL: https://issues.apache.org/jira/browse/SOLR-7190
> Project: Solr
>  Issue Type: Task
>Reporter: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: 6.0, 5.5
>
>
> I was surprised to find that UninvertedField is no longer used in Solr. The 
> only references to UninvertedField is from the fieldValueCache inside 
> SolrIndexSearcher and that itself is not used anywhere in SolrIndexSearcher 
> except for initialization and regeneration. I can't trace when Solr stopped 
> using this class but in any case, we should remove it.
> In a related note, Lucene's DocTermOrds has a copy of the class level 
> javadocs of UninvertedField (which extends DocTermOrds). This was done in in 
> LUCENE-5666.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (LUCENE-7868) Use multiple threads to apply deletes and DV updates

[Michael McCandless (JIRA)]

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

Michael McCandless updated LUCENE-7868:
---
Attachment: LUCENE-7868.patch

Another iteration folding [~simonw]'s last feedback.  Test, ant precommit 
-Dtests.nightly=true pass!

> Use multiple threads to apply deletes and DV updates
> 
>
> Key: LUCENE-7868
> URL: https://issues.apache.org/jira/browse/LUCENE-7868
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master (7.0)
>
> Attachments: cpu-after.png, cpu-before.png, LUCENE-7868.patch, 
> LUCENE-7868.patch, LUCENE-7868.patch, LUCENE-7868.patch, LUCENE-7868.patch, 
> LUCENE-7868.patch
>
>
> Today, when users delete documents or apply doc values updates, IndexWriter 
> buffers them up into frozen packets and then eventually uses a single thread 
> (BufferedUpdatesStream.applyDeletesAndUpdates) to resolve delete/update terms 
> to docids.  This thread also holds IW's monitor lock, so it also blocks 
> refresh, merges starting/finishing, commits, etc.
> We have heavily optimized this part of Lucene over time, e.g. LUCENE-6161, 
> LUCENE-2897, LUCENE-2680, LUCENE-3342, but still, it's a single thread so it 
> can't use multiple CPU cores commonly available now.
> This doesn't affect append-only usage, but for update-heavy users (me!) this 
> can be a big bottleneck, and causes long stop-the-world hangs during indexing.
> I have an initial exploratory patch to make these lookups concurrent, without 
> holding IW's lock, so that when a new packet of deletes is pushed, which 
> happens when we flush a new segment, we immediately use that same indexing 
> thread to and resolve the deletions.
> This is analogous to when we made segment flushing concurrent (LUCENE-3023), 
> just for deletes and DV updates as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: Release planning for 7.0

[Anshum Gupta]

>From my understanding, there's not really a 'plan' but some intention to
release a 6.7 at some time if enough people need it, right? In that case I
wouldn't hold back anything for a 6x line release and cut the 7x, and 7.0
branches around, but not before the coming weekend. I will send out an
email a day before cutting the branch, as well as once the branch is in
place.

If anyone has any objections to that, do let me know.

Once that happens, we'd have a feature freeze on the 7.0 branch but we can
take our time to iron out the bugs.

@Alan: Thanks for informing. I'll make sure that LUCENE-7877 is committed
before I cut the branch. I have added the right fixVersion to the issue.

-Anshum



On Mon, Jun 19, 2017 at 8:33 AM Erick Erickson 
wrote:

> Anshum:
>
> I'm one of the people that expect a 6.7 release, but it's more along
> the lines of setting expectations than having features I really want
> to get in to the 6x code line. We nearly always have "just a few
> things" that someone would like to put in, and/or a bug fix or two
> that surfaces.
>
> I expect people to back-port stuff they consider easy/beneficial to
> 6.x for "a while" as 7.0 solidifies, at their discretion of course.
> Think of my position as giving people a target for tidying up 6.x
> rather than a concrete plan ;). Just seems to always happen.
>
> And if there is no 6.7, that's OK too. Additions to master-2 usually
> pretty swiftly stop as the hassle of merging any change into 3 code
> lines causes people to pick what goes into master-2 more carefully ;)
>
> Erick
>
> On Mon, Jun 19, 2017 at 8:03 AM, Alan Woodward  wrote:
> > I’d like to get https://issues.apache.org/jira/browse/LUCENE-7877 in
> for 7.0
> > - should be able to commit in the next couple of days.
> >
> > Alan Woodward
> > www.flax.co.uk
> >
> >
> > On 19 Jun 2017, at 15:45, Anshum Gupta  wrote:
> >
> > Hi everyone,
> >
> > Here's the update about 7.0 release:
> >
> > There are still  unresolved blockers for 7.0.
> > Solr (12):
> >
> https://issues.apache.org/jira/browse/SOLR-6630?jql=project%20%3D%20Solr%20AND%20fixVersion%20%3D%20%22master%20(7.0)%22%20and%20resolution%20%3D%20Unresolved%20and%20priority%20%3D%20Blocker
> >
> > Lucene (None):
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20%22Lucene%20-%20Core%22%20AND%20fixVersion%20%3D%20%22master%20(7.0)%22%20AND%20resolution%20%3D%20Unresolved%20AND%20priority%20%3D%20Blocker
> >
> > Here are the ones that are unassigned:
> > https://issues.apache.org/jira/browse/SOLR-6630
> > https://issues.apache.org/jira/browse/SOLR-10887
> > https://issues.apache.org/jira/browse/SOLR-10803
> > https://issues.apache.org/jira/browse/SOLR-10756
> > https://issues.apache.org/jira/browse/SOLR-10710
> > https://issues.apache.org/jira/browse/SOLR-9321
> > https://issues.apache.org/jira/browse/SOLR-8256
> >
> > The ones that are already assigned, I'd request you to update the JIRA
> so we
> > can track it better.
> >
> > In addition, I am about to create another one as I wasn’t able to extend
> > SolrClient easily without a code duplication on master.
> >
> > This brings us to - 'when can we cut the branch'. I can create the branch
> > this week and we can continue to work on these as long as none of these
> are
> > 'new features' but I'd be happy to hear what everyone has to say.
> >
> > I know there were suggestions around a 6.7 release, does anyone who's
> > interested in leading that have a timeline or an idea around what
> features
> > did you want in that release? If yes, I’d really want to wait until at
> least
> > the branch for 6.7 is cur for the purpose of easy back-compat management
> and
> > guarantee.
> >
> > Also, sorry for being on radio silence for the last few days. I’d been
> > traveling but now I’m back :).
> >
> > -Anshum Gupta
> >
> > On Sun, Jun 18, 2017 at 8:57 AM Dennis Gove  wrote:
> >>
> >> I've committed the most critical changes I wanted to make. Please don't
> >> hold up on a v7 release on my part.
> >>
> >> Thanks!
> >>
> >> Dennis
> >>
> >> On Tue, Jun 13, 2017 at 9:27 AM, Dennis Gove  wrote:
> >>>
> >>> Hi,
> >>>
> >>> I also have some cleanup I'd like to do prior to a cut of 7. There are
> >>> some new stream evaluators that I'm finding don't flow with the general
> >>> flavor of evaluators. I'm using
> >>> https://issues.apache.org/jira/browse/SOLR-10882 for the cleanup, but
> I do
> >>> intend to be complete by June 16th.
> >>>
> >>> Thanks,
> >>> Dennis
> >>>
> >>>
> >>> On Sat, Jun 10, 2017 at 11:21 AM, Ishan Chattopadhyaya
> >>>  wrote:
> 
>  Hi Anshum,
>  I would like to request you to consider delaying the branch cutting
> by a
>  bit till we finalize the SOLR-10574 discussions and make the changes.
>  Alternatively, we could backport the changes to that branch after you
> cut
>  the branch now.
>  Regards,
>  Ishan
>