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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.handler.admin.TestApiFramework.testFramework

Error Message:


Stack Trace:
java.lang.ExceptionInInitializerError
at 
__randomizedtesting.SeedInfo.seed([98F85471534EEC5:1EF94F6013E002F8]:0)
at 
net.sf.cglib.core.KeyFactory$Generator.generateClass(KeyFactory.java:166)
at 
net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25)
at 
net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:216)
at net.sf.cglib.core.KeyFactory$Generator.create(KeyFactory.java:144)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:116)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:108)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:104)
at net.sf.cglib.proxy.Enhancer.(Enhancer.java:69)
at 
org.easymock.internal.ClassProxyFactory.createEnhancer(ClassProxyFactory.java:259)
at 
org.easymock.internal.ClassProxyFactory.createProxy(ClassProxyFactory.java:174)
at org.easymock.internal.MocksControl.createMock(MocksControl.java:60)
at org.easymock.EasyMock.createMock(EasyMock.java:104)
at 
org.apache.solr.handler.admin.TestCoreAdminApis.getCoreContainerMock(TestCoreAdminApis.java:83)
at 
org.apache.solr.handler.admin.TestApiFramework.testFramework(TestApiFramework.java:59)
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:543)
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 

[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+155) - Build # 18982 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18982/
Java: 32bit/jdk-9-ea+155 -server -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.handler.admin.TestApiFramework.testFramework

Error Message:


Stack Trace:
java.lang.ExceptionInInitializerError
at 
__randomizedtesting.SeedInfo.seed([B2E5B838C9FA287E:A593721FCF2EC443]:0)
at 
net.sf.cglib.core.KeyFactory$Generator.generateClass(KeyFactory.java:166)
at 
net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25)
at 
net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:216)
at net.sf.cglib.core.KeyFactory$Generator.create(KeyFactory.java:144)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:116)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:108)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:104)
at net.sf.cglib.proxy.Enhancer.(Enhancer.java:69)
at 
org.easymock.internal.ClassProxyFactory.createEnhancer(ClassProxyFactory.java:259)
at 
org.easymock.internal.ClassProxyFactory.createProxy(ClassProxyFactory.java:174)
at org.easymock.internal.MocksControl.createMock(MocksControl.java:60)
at org.easymock.EasyMock.createMock(EasyMock.java:104)
at 
org.apache.solr.handler.admin.TestCoreAdminApis.getCoreContainerMock(TestCoreAdminApis.java:83)
at 
org.apache.solr.handler.admin.TestApiFramework.testFramework(TestApiFramework.java:59)
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:543)
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 

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.TestCloudRecovery.leaderRecoverFromLogOnStartupTest

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

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




Build Log:
[...truncated 11780 lines...]
   [junit4] Suite: 

[JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+155) - Build # 2873 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2873/
Java: 32bit/jdk-9-ea+155 -server -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.handler.admin.TestApiFramework.testFramework

Error Message:


Stack Trace:
java.lang.ExceptionInInitializerError
at 
__randomizedtesting.SeedInfo.seed([B7BB67CC3268542B:A0CDADEB34BCB816]:0)
at 
net.sf.cglib.core.KeyFactory$Generator.generateClass(KeyFactory.java:166)
at 
net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25)
at 
net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:216)
at net.sf.cglib.core.KeyFactory$Generator.create(KeyFactory.java:144)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:116)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:108)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:104)
at net.sf.cglib.proxy.Enhancer.(Enhancer.java:69)
at 
org.easymock.internal.ClassProxyFactory.createEnhancer(ClassProxyFactory.java:259)
at 
org.easymock.internal.ClassProxyFactory.createProxy(ClassProxyFactory.java:174)
at org.easymock.internal.MocksControl.createMock(MocksControl.java:60)
at org.easymock.EasyMock.createMock(EasyMock.java:104)
at 
org.apache.solr.handler.admin.TestCoreAdminApis.getCoreContainerMock(TestCoreAdminApis.java:83)
at 
org.apache.solr.handler.admin.TestApiFramework.testFramework(TestApiFramework.java:59)
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:543)
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 

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

[Policeman Jenkins Server]

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

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

Error Message:
Collection not found: withShardField

Stack Trace:
org.apache.solr.common.SolrException: Collection not found: withShardField
at 
__randomizedtesting.SeedInfo.seed([F53CABC0B3C6DE6F:A06C43521F3F119F]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.getCollectionNames(CloudSolrClient.java:1376)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1072)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1042)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:160)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:232)
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 

[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+155) - Build # 18981 - Still Unstable!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.handler.admin.TestApiFramework.testFramework

Error Message:


Stack Trace:
java.lang.ExceptionInInitializerError
at 
__randomizedtesting.SeedInfo.seed([8A63BD1EAA2A9221:9D157739ACFE7E1C]:0)
at 
net.sf.cglib.core.KeyFactory$Generator.generateClass(KeyFactory.java:166)
at 
net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25)
at 
net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:216)
at net.sf.cglib.core.KeyFactory$Generator.create(KeyFactory.java:144)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:116)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:108)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:104)
at net.sf.cglib.proxy.Enhancer.(Enhancer.java:69)
at 
org.easymock.internal.ClassProxyFactory.createEnhancer(ClassProxyFactory.java:259)
at 
org.easymock.internal.ClassProxyFactory.createProxy(ClassProxyFactory.java:174)
at org.easymock.internal.MocksControl.createMock(MocksControl.java:60)
at org.easymock.EasyMock.createMock(EasyMock.java:104)
at 
org.apache.solr.handler.admin.TestCoreAdminApis.getCoreContainerMock(TestCoreAdminApis.java:83)
at 
org.apache.solr.handler.admin.TestApiFramework.testFramework(TestApiFramework.java:59)
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:543)
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 

[jira] [Resolved] (LUCENE-7449) Add CROSSES query support to RangeField

[Nicholas Knize (JIRA)]

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

Nicholas Knize resolved LUCENE-7449.

   Resolution: Implemented
 Assignee: Nicholas Knize
Fix Version/s: 6.5
   master (7.0)

> Add CROSSES query support to RangeField
> ---
>
> Key: LUCENE-7449
> URL: https://issues.apache.org/jira/browse/LUCENE-7449
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
> Fix For: master (7.0), 6.5
>
> Attachments: LUCENE-7449.patch, LUCENE-7449.patch, LUCENE-7449.patch
>
>
> {{RangeField}} currently supports {{INTERSECTS}}, {{WITHIN}}, and 
> {{CONTAINS}} query behavior. This feature adds support for an explicit 
> {{CROSSES}} query. Unlike {{INTERSECT}} and {{OVERLAP}} queries the 
> {{CROSSES}} query finds any indexed ranges whose interior (within range) 
> intersect the interior AND exterior (outside range) of the query range.



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

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

[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+155) - Build # 18980 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18980/
Java: 32bit/jdk-9-ea+155 -client -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.handler.admin.TestApiFramework.testFramework

Error Message:


Stack Trace:
java.lang.ExceptionInInitializerError
at 
__randomizedtesting.SeedInfo.seed([B355EE5A17E20C5F:A423247D1136E062]:0)
at 
net.sf.cglib.core.KeyFactory$Generator.generateClass(KeyFactory.java:166)
at 
net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25)
at 
net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:216)
at net.sf.cglib.core.KeyFactory$Generator.create(KeyFactory.java:144)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:116)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:108)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:104)
at net.sf.cglib.proxy.Enhancer.(Enhancer.java:69)
at 
org.easymock.internal.ClassProxyFactory.createEnhancer(ClassProxyFactory.java:259)
at 
org.easymock.internal.ClassProxyFactory.createProxy(ClassProxyFactory.java:174)
at org.easymock.internal.MocksControl.createMock(MocksControl.java:60)
at org.easymock.EasyMock.createMock(EasyMock.java:104)
at 
org.apache.solr.handler.admin.TestCoreAdminApis.getCoreContainerMock(TestCoreAdminApis.java:83)
at 
org.apache.solr.handler.admin.TestApiFramework.testFramework(TestApiFramework.java:59)
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:543)
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 

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

[Policeman Jenkins Server]

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

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

Error Message:
Could not get expected value  'A val' for path 'params/a' full output: {   
"responseHeader":{ "status":0, "QTime":0},   "params":{ 
"wt":"json", "useParams":""},   "context":{ "webapp":"/solr", 
"path":"/dump0", "httpMethod":"GET"}},  from server:  
http://127.0.0.1:59233/solr/collection1_shard1_replica2

Stack Trace:
java.lang.AssertionError: Could not get expected value  'A val' for path 
'params/a' full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "params":{
"wt":"json",
"useParams":""},
  "context":{
"webapp":"/solr",
"path":"/dump0",
"httpMethod":"GET"}},  from server:  
http://127.0.0.1:59233/solr/collection1_shard1_replica2
at 
__randomizedtesting.SeedInfo.seed([229553DB7D7CD29F:AAC16C01D380BF67]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:556)
at 
org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:127)
at 
org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:69)
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)
 

[JENKINS] Lucene-Solr-Tests-6.x - Build # 729 - Unstable

[Apache Jenkins Server]

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

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

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

Stack Trace:
java.lang.AssertionError: expected:<3> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([798097BE1D934169:31F5E30A1BA06EFC]: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:745)




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

[jira] [Updated] (LUCENE-7674) java.lang.IllegalStateException: Child query must not match same docs with parent filter. Combine them as must clauses (+) to find a problem doc. docId=2147483647, class

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated LUCENE-7674:
-
Attachment: (was: LUCENE-7674-attempt-to-reproduce.patch)

> java.lang.IllegalStateException: Child query must not match same docs with 
> parent filter. Combine them as must clauses (+) to find a problem doc. 
> docId=2147483647, class org.apache.lucene.search.ConjunctionScorer
> 
>
> Key: LUCENE-7674
> URL: https://issues.apache.org/jira/browse/LUCENE-7674
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.3
>Reporter: Tim Underwood
> Attachments: LUCENE-7674-attempt-to-reproduce.patch, LUCENE-7674.patch
>
>
> Started seeing this error message on a production Solr 6.3.0 system today 
> making use of parent/child documents:
> {code}
> java.lang.IllegalStateException: Child query must not match same docs with 
> parent filter. Combine them as must clauses (+) to find a problem doc. 
> docId=2147483647, class org.apache.lucene.search.ConjunctionScorer
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.checkOrthogonal(ToParentBlockJoinQuery.java:403)
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.access$400(ToParentBlockJoinQuery.java:206)
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer$1.nextDoc(ToParentBlockJoinQuery.java:327)
> at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:219)
> at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:172)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:669)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:473)
> at 
> org.apache.solr.search.DocSetUtil.createDocSetGeneric(DocSetUtil.java:106)
> at org.apache.solr.search.DocSetUtil.createDocSet(DocSetUtil.java:95)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1379)
> at 
> org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:1057)
> at 
> org.apache.solr.search.SolrIndexSearcher.getProcessedFilter(SolrIndexSearcher.java:1227)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListAndSetNC(SolrIndexSearcher.java:1842)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1616)
> at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:617)
> at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:531)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:153)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2213)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:303)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:254)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:518)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
> at 
> 

[jira] [Updated] (LUCENE-7674) java.lang.IllegalStateException: Child query must not match same docs with parent filter. Combine them as must clauses (+) to find a problem doc. docId=2147483647, class

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated LUCENE-7674:
-
Attachment: LUCENE-7674-attempt-to-reproduce.patch

> java.lang.IllegalStateException: Child query must not match same docs with 
> parent filter. Combine them as must clauses (+) to find a problem doc. 
> docId=2147483647, class org.apache.lucene.search.ConjunctionScorer
> 
>
> Key: LUCENE-7674
> URL: https://issues.apache.org/jira/browse/LUCENE-7674
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.3
>Reporter: Tim Underwood
> Attachments: LUCENE-7674-attempt-to-reproduce.patch, LUCENE-7674.patch
>
>
> Started seeing this error message on a production Solr 6.3.0 system today 
> making use of parent/child documents:
> {code}
> java.lang.IllegalStateException: Child query must not match same docs with 
> parent filter. Combine them as must clauses (+) to find a problem doc. 
> docId=2147483647, class org.apache.lucene.search.ConjunctionScorer
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.checkOrthogonal(ToParentBlockJoinQuery.java:403)
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.access$400(ToParentBlockJoinQuery.java:206)
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer$1.nextDoc(ToParentBlockJoinQuery.java:327)
> at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:219)
> at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:172)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:669)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:473)
> at 
> org.apache.solr.search.DocSetUtil.createDocSetGeneric(DocSetUtil.java:106)
> at org.apache.solr.search.DocSetUtil.createDocSet(DocSetUtil.java:95)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1379)
> at 
> org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:1057)
> at 
> org.apache.solr.search.SolrIndexSearcher.getProcessedFilter(SolrIndexSearcher.java:1227)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListAndSetNC(SolrIndexSearcher.java:1842)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1616)
> at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:617)
> at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:531)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:153)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2213)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:303)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:254)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:518)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
> at 
> 

[jira] [Updated] (LUCENE-7674) java.lang.IllegalStateException: Child query must not match same docs with parent filter. Combine them as must clauses (+) to find a problem doc. docId=2147483647, class

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated LUCENE-7674:
-
Attachment: LUCENE-7674-attempt-to-reproduce.patch

> java.lang.IllegalStateException: Child query must not match same docs with 
> parent filter. Combine them as must clauses (+) to find a problem doc. 
> docId=2147483647, class org.apache.lucene.search.ConjunctionScorer
> 
>
> Key: LUCENE-7674
> URL: https://issues.apache.org/jira/browse/LUCENE-7674
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.3
>Reporter: Tim Underwood
> Attachments: LUCENE-7674-attempt-to-reproduce.patch, LUCENE-7674.patch
>
>
> Started seeing this error message on a production Solr 6.3.0 system today 
> making use of parent/child documents:
> {code}
> java.lang.IllegalStateException: Child query must not match same docs with 
> parent filter. Combine them as must clauses (+) to find a problem doc. 
> docId=2147483647, class org.apache.lucene.search.ConjunctionScorer
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.checkOrthogonal(ToParentBlockJoinQuery.java:403)
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.access$400(ToParentBlockJoinQuery.java:206)
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer$1.nextDoc(ToParentBlockJoinQuery.java:327)
> at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:219)
> at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:172)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:669)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:473)
> at 
> org.apache.solr.search.DocSetUtil.createDocSetGeneric(DocSetUtil.java:106)
> at org.apache.solr.search.DocSetUtil.createDocSet(DocSetUtil.java:95)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1379)
> at 
> org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:1057)
> at 
> org.apache.solr.search.SolrIndexSearcher.getProcessedFilter(SolrIndexSearcher.java:1227)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListAndSetNC(SolrIndexSearcher.java:1842)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1616)
> at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:617)
> at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:531)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:153)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2213)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:303)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:254)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:518)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
> at 
> 

[jira] [Commented] (LUCENE-7674) java.lang.IllegalStateException: Child query must not match same docs with parent filter. Combine them as must clauses (+) to find a problem doc. docId=2147483647, cla

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on LUCENE-7674:
--

Ok. I started to scratch the spec at SOLR-10144. Everybody are welcome. 
Meanwhile, I tried to reproduce this exact failure to come up with more 
informative message. But it seems like it's impossible - recently redesigned 
BlockJoinQuery ignores children behind the last parent in segment.  

> java.lang.IllegalStateException: Child query must not match same docs with 
> parent filter. Combine them as must clauses (+) to find a problem doc. 
> docId=2147483647, class org.apache.lucene.search.ConjunctionScorer
> 
>
> Key: LUCENE-7674
> URL: https://issues.apache.org/jira/browse/LUCENE-7674
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.3
>Reporter: Tim Underwood
> Attachments: LUCENE-7674-attempt-to-reproduce.patch, LUCENE-7674.patch
>
>
> Started seeing this error message on a production Solr 6.3.0 system today 
> making use of parent/child documents:
> {code}
> java.lang.IllegalStateException: Child query must not match same docs with 
> parent filter. Combine them as must clauses (+) to find a problem doc. 
> docId=2147483647, class org.apache.lucene.search.ConjunctionScorer
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.checkOrthogonal(ToParentBlockJoinQuery.java:403)
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.access$400(ToParentBlockJoinQuery.java:206)
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer$1.nextDoc(ToParentBlockJoinQuery.java:327)
> at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:219)
> at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:172)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:669)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:473)
> at 
> org.apache.solr.search.DocSetUtil.createDocSetGeneric(DocSetUtil.java:106)
> at org.apache.solr.search.DocSetUtil.createDocSet(DocSetUtil.java:95)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1379)
> at 
> org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:1057)
> at 
> org.apache.solr.search.SolrIndexSearcher.getProcessedFilter(SolrIndexSearcher.java:1227)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListAndSetNC(SolrIndexSearcher.java:1842)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1616)
> at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:617)
> at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:531)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:153)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2213)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:303)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:254)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
> 

Re: Welcome Toke Eskildsen as a Lucene/Solr committer

[jim ferenczi]

Welcome Toke!

Le 16 févr. 2017 5:08 PM, "Erick Erickson"  a
écrit :

> Congrats Toke!
>
> On Thu, Feb 16, 2017 at 6:37 AM, Dmitry Kan 
> wrote:
> > Hi Toke, congrats! Glad for you and well deserved!
> >
> > P.S. Was awesome to test faceting module speed ups you did for high
> > cardinality fields. Your skill to explain complex things very
> efficiently is
> > unmatched.
> >
> > Dmitry
> > --
> > Dmitry Kan
> > Luke Toolbox: http://github.com/DmitryKey/luke
> > Blog: http://dmitrykan.blogspot.com
> > Twitter: http://twitter.com/dmitrykan
> >
> > On 14 February 2017 at 20:11, Toke Eskildsen  wrote:
> >>
> >> Thank you for the invitation and the warm welcome.
> >>
> >>
> >> I am a 43 year old Danish man, with a family and a job at the Royal
> Danish
> >> Library, where I have been working mostly with search-related
> technology for
> >> 10 years.
> >>
> >> I have done a fair bit of Lucene/Solr hacking during the years, with
> focus
> >> on speed- and memory-optimizations. Implementing bit-packing structures,
> >> eliminating steps in calculations and in general making more things
> possible
> >> on less hardware is a bit of an obsession. I hope to continue in that
> >> direction as a committer and am looking forward to a more controlled and
> >> community-oriented way of writing code: The one-man-show is a lot of
> fun and
> >> can work well for specific use cases, but it tends to get a bit out of
> >> control and the result might not be that usable elsewhere.
> >>
> >> Happy to be here,
> >> Toke
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Commented] (SOLR-10130) Serious performance degradation in Solr 6.4.1 due to the new metrics collection

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-10130:
---

How on earth did you get a 4.7G tlog? It looks like you somehow didn't commit, 
shut the node down are replaying a ton of docs (well, how much does 4.7G weigh 
anyway?) from the tlog.

So, simple test:
1> wait for the node to come up.
2> insure you've issued a hard commit
3> try restarting.

My claim is that the restart will be reasonable and the slowness you're seeing 
is a result of somehow shutting down without doing a commit. Of course 
depending on your autocommit interval you may not need to do the hard commit 
before restarting...

Best,
Erick

> Serious performance degradation in Solr 6.4.1 due to the new metrics 
> collection
> ---
>
> Key: SOLR-10130
> URL: https://issues.apache.org/jira/browse/SOLR-10130
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 6.4.1
> Environment: Centos 7, OpenJDK 1.8.0 update 111
>Reporter: Ere Maijala
>Assignee: Andrzej Bialecki 
>Priority: Blocker
>  Labels: perfomance
> Fix For: master (7.0), 6.4.2
>
> Attachments: SOLR-10130.patch, SOLR-10130.patch, 
> solr-8983-console-f1.log
>
>
> We've stumbled on serious performance issues after upgrading to Solr 6.4.1. 
> Looks like the new metrics collection system in MetricsDirectoryFactory is 
> causing a major slowdown. This happens with an index configuration that, as 
> far as I can see, has no metrics specific configuration and uses 
> luceneMatchVersion 5.5.0. In practice a moderate load will completely bog 
> down the server with Solr threads constantly using up all CPU (600% on 6 core 
> machine) capacity with a load that normally  where we normally see an average 
> load of < 50%.
> I took stack traces (I'll attach them) and noticed that the threads are 
> spending time in com.codahale.metrics.Meter.mark. I tested building Solr 
> 6.4.1 with the metrics collection disabled in MetricsDirectoryFactory getByte 
> and getBytes methods and was unable to reproduce the issue.
> As far as I can see there are several issues:
> 1. Collecting metrics on every single byte read is slow.
> 2. Having it enabled by default is not a good idea.
> 3. The comment "enable coarse-grained metrics by default" at 
> https://github.com/apache/lucene-solr/blob/branch_6x/solr/core/src/java/org/apache/solr/update/SolrIndexConfig.java#L104
>  implies that only coarse-grained metrics should be enabled by default, and 
> this contradicts with collecting metrics on every single byte read.



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

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

[jira] [Commented] (SOLR-7341) xjoin - join data from external sources

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-7341:
--

Shamik:

In a word no. The "fix versions" are suggestions of what was current when the 
patch was first created. I would guess the last version it was applied to 
successfully was 4.10.3.

Best,
Erick

> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Tom Winch
>Priority: Minor
> Fix For: 4.10.3, 5.3.2, 6.0
>
> Attachments: SOLR-7341.patch-4_10, SOLR-7341.patch-4.10.3, 
> SOLR-7341.patch-5_3, SOLR-7341.patch-5.3.2, SOLR-7341.patch-master, 
> SOLR-7341.patch-trunk, SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR 
> results in a query and the SOLR result set to be filtered by the results of 
> an external query. Values from the external results are made available in the 
> SOLR results and may also be used to boost the scores of corresponding 
> documents during the search. The contrib consists of the Java classes 
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and 
> associated classes), which must be configured in solrconfig.xml, and the 
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the 
> user to provide the link between SOLR and the external results source (but 
> see below for details of how to use the in-built SimpleXJoinResultsFactory 
> implementation). External results and SOLR documents are matched via a single 
> configurable attribute (the "join field").
> To include the XJoin contrib classes, add the following config to 
> solrconfig.xml:
> {code:xml}
> 
>   ..
>
>regex=".*\.jar" />
>regex="solr-xjoin-\d.*\.jar" />
>   ..
> 
> {code}
> Note that any JARs containing implementations of the XJoinResultsFactory must 
> also be included.
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an 
> external source to perform a query (or otherwise collect results). Parameters 
> with prefix ".external." are passed from the SOLR query URL 
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and 
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR 
> search to generate external results, and is passed parameters from the SOLR 
> query URL (as above)
> For example, the implementation might perform queries of an external source 
> based on the 'q' SOLR query URL parameter (in full,  name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults() 
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result 
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending) 
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component, 
> configured in solrconfig.xml and included in one or more SOLR request 
> handlers. There is one XJoin search component per external source, and each 
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves 
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and 
> external results via the join field, adding attributes from the external 
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing 
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR 
> documents and external results
> * external - this parameter set is passed to configure the 
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
>  class="org.apache.solr.search.xjoin.XJoinSearchComponent">
>   test.TestXJoinResultsFactory
>   id
>   
> 1,2,3
>   
> 
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during 
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure 
> it. To properly use the XJoinSearchComponent in a request handler, it must be 
> included at the start and end of the component list, and may be 

[jira] [Commented] (SOLR-10130) Serious performance degradation in Solr 6.4.1 due to the new metrics collection

[Walter Underwood (JIRA)]

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

Walter Underwood commented on SOLR-10130:
-

This might be part of it:

[wunder@new-solr-c01.test3]# ls -lh 
/solr/data/questions_shard2_replica1/data/tlog/
total 4.7G
-rw-r--r-- 1 bin bin 4.7G Feb 13 11:04 tlog.000
[wunder@new-solr-c01.test3]# du -sh /solr/data/questions_shard2_replica1/data/*
8.4G/solr/data/questions_shard2_replica1/data/index
4.0K/solr/data/questions_shard2_replica1/data/snapshot_metadata
4.7G/solr/data/questions_shard2_replica1/data/tlog


Last Modified: 3 days ago
Num Docs: 3683075
Max Doc: 3683075
Heap Memory Usage: -1
Deleted Docs: 0
Version: 2737
Segment Count: 26
Optimized: yes
Current: yes



> Serious performance degradation in Solr 6.4.1 due to the new metrics 
> collection
> ---
>
> Key: SOLR-10130
> URL: https://issues.apache.org/jira/browse/SOLR-10130
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 6.4.1
> Environment: Centos 7, OpenJDK 1.8.0 update 111
>Reporter: Ere Maijala
>Assignee: Andrzej Bialecki 
>Priority: Blocker
>  Labels: perfomance
> Fix For: master (7.0), 6.4.2
>
> Attachments: SOLR-10130.patch, SOLR-10130.patch, 
> solr-8983-console-f1.log
>
>
> We've stumbled on serious performance issues after upgrading to Solr 6.4.1. 
> Looks like the new metrics collection system in MetricsDirectoryFactory is 
> causing a major slowdown. This happens with an index configuration that, as 
> far as I can see, has no metrics specific configuration and uses 
> luceneMatchVersion 5.5.0. In practice a moderate load will completely bog 
> down the server with Solr threads constantly using up all CPU (600% on 6 core 
> machine) capacity with a load that normally  where we normally see an average 
> load of < 50%.
> I took stack traces (I'll attach them) and noticed that the threads are 
> spending time in com.codahale.metrics.Meter.mark. I tested building Solr 
> 6.4.1 with the metrics collection disabled in MetricsDirectoryFactory getByte 
> and getBytes methods and was unable to reproduce the issue.
> As far as I can see there are several issues:
> 1. Collecting metrics on every single byte read is slow.
> 2. Having it enabled by default is not a good idea.
> 3. The comment "enable coarse-grained metrics by default" at 
> https://github.com/apache/lucene-solr/blob/branch_6x/solr/core/src/java/org/apache/solr/update/SolrIndexConfig.java#L104
>  implies that only coarse-grained metrics should be enabled by default, and 
> this contradicts with collecting metrics on every single byte read.



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

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

[jira] [Commented] (SOLR-10130) Serious performance degradation in Solr 6.4.1 due to the new metrics collection

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-10130:
--

bq.Is there any way you could pull/build a new version of Solr 6.4 (or apply 
the patch on this JIRA locally) and try? I'd hate to have the 6.4.2 release get 
out (coming soon, due to this) and not have fixed a different issue.
I concur. [~wunder] - we are not sure if your situation is caused by the issue 
fixed here or by some other bug, it would be very helpful if you could try a 
build that contains this patch to see if it solves the problem in your 
environment.

> Serious performance degradation in Solr 6.4.1 due to the new metrics 
> collection
> ---
>
> Key: SOLR-10130
> URL: https://issues.apache.org/jira/browse/SOLR-10130
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 6.4.1
> Environment: Centos 7, OpenJDK 1.8.0 update 111
>Reporter: Ere Maijala
>Assignee: Andrzej Bialecki 
>Priority: Blocker
>  Labels: perfomance
> Fix For: master (7.0), 6.4.2
>
> Attachments: SOLR-10130.patch, SOLR-10130.patch, 
> solr-8983-console-f1.log
>
>
> We've stumbled on serious performance issues after upgrading to Solr 6.4.1. 
> Looks like the new metrics collection system in MetricsDirectoryFactory is 
> causing a major slowdown. This happens with an index configuration that, as 
> far as I can see, has no metrics specific configuration and uses 
> luceneMatchVersion 5.5.0. In practice a moderate load will completely bog 
> down the server with Solr threads constantly using up all CPU (600% on 6 core 
> machine) capacity with a load that normally  where we normally see an average 
> load of < 50%.
> I took stack traces (I'll attach them) and noticed that the threads are 
> spending time in com.codahale.metrics.Meter.mark. I tested building Solr 
> 6.4.1 with the metrics collection disabled in MetricsDirectoryFactory getByte 
> and getBytes methods and was unable to reproduce the issue.
> As far as I can see there are several issues:
> 1. Collecting metrics on every single byte read is slow.
> 2. Having it enabled by default is not a good idea.
> 3. The comment "enable coarse-grained metrics by default" at 
> https://github.com/apache/lucene-solr/blob/branch_6x/solr/core/src/java/org/apache/solr/update/SolrIndexConfig.java#L104
>  implies that only coarse-grained metrics should be enabled by default, and 
> this contradicts with collecting metrics on every single byte read.



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

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

[jira] [Commented] (SOLR-7242) Schema API: Edit remaining schema elements: Name, Version, Unique Key, and Global Similarity

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-7242:
-

I've never actually seen schema name used for anything useful. So, +1 on 
getting rid of it. 

Schema version I guess is a little messier, as important defaults get switched 
around, but if there is clear way to map it to luceneMatchVersion, I am all for 
it. 

> Schema API: Edit remaining schema elements: Name, Version, Unique Key, and 
> Global Similarity
> 
>
> Key: SOLR-7242
> URL: https://issues.apache.org/jira/browse/SOLR-7242
> Project: Solr
>  Issue Type: Sub-task
>  Components: Schema and Analysis
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>
> We should be able to specify an entire schema via the bulk schema API.
> The bulk schema API should have the following commands in addition to those 
> already available/planned:
> # {{set-name}}
> # {{set-version}}
> # {{set-unique-key}}/{{unset-unique-key}}
> # {{set-similarity}}



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

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

[jira] [Comment Edited] (LUCENE-7674) java.lang.IllegalStateException: Child query must not match same docs with parent filter. Combine them as must clauses (+) to find a problem doc. docId=2147483647

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev edited comment on LUCENE-7674 at 2/16/17 8:56 PM:
---

[~tpunder], you've got everything right! Thanks for gathering those pet peeves 
in the list. Here is one more, SOLR-7606 - it's my favorite ones. I need to 
tackle them sooner or later. 


was (Author: mkhludnev):
[~tpunder], you've got everything right! Thanks for gathering those pet peeves 
in the list. I need to tackle them sooner or later. 

> java.lang.IllegalStateException: Child query must not match same docs with 
> parent filter. Combine them as must clauses (+) to find a problem doc. 
> docId=2147483647, class org.apache.lucene.search.ConjunctionScorer
> 
>
> Key: LUCENE-7674
> URL: https://issues.apache.org/jira/browse/LUCENE-7674
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.3
>Reporter: Tim Underwood
> Attachments: LUCENE-7674.patch
>
>
> Started seeing this error message on a production Solr 6.3.0 system today 
> making use of parent/child documents:
> {code}
> java.lang.IllegalStateException: Child query must not match same docs with 
> parent filter. Combine them as must clauses (+) to find a problem doc. 
> docId=2147483647, class org.apache.lucene.search.ConjunctionScorer
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.checkOrthogonal(ToParentBlockJoinQuery.java:403)
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.access$400(ToParentBlockJoinQuery.java:206)
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer$1.nextDoc(ToParentBlockJoinQuery.java:327)
> at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:219)
> at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:172)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:669)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:473)
> at 
> org.apache.solr.search.DocSetUtil.createDocSetGeneric(DocSetUtil.java:106)
> at org.apache.solr.search.DocSetUtil.createDocSet(DocSetUtil.java:95)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1379)
> at 
> org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:1057)
> at 
> org.apache.solr.search.SolrIndexSearcher.getProcessedFilter(SolrIndexSearcher.java:1227)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListAndSetNC(SolrIndexSearcher.java:1842)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1616)
> at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:617)
> at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:531)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:153)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2213)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:303)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:254)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> at 
> 

[jira] [Updated] (SOLR-10144) redesign block-join support

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-10144:

Description: 
This is a placeholder for new block join design. Let's comeup with the name 
first: -whether- it will be nested-, child docs or blocks?- 
h2. Feature Delivery plan
h3. Naming
Nested Documents

h3. Scopes in schema.xml 
# fields can be grouped with {{}};
# it can be _any_ level deep, and fan out _any_ subscopes ({{name}} necessary 
for distinguishing {{sons}}, {{daugthers}} subscopes);
# (?) I'm not sure whether {{name}} is uniq or traverse path is unique. _I'd 
like the former_;
# btw, maybe  {{type}} (?) ;
# {{default}} attribute is necessary to map existing blocks, which has only one 
nesting dimension: {{childrenDocuments}};  
# fields beside of scopes (_global_) can appear on any scope. it should work 
with uniqueKey (!);
# coming to roots (?) how many root scopes we can have? _I think we can have a 
few ones that introducing notion of document types._ 

h3. Updates
# All formats XML, JSON, JSONdoc, Javabin accept nesting in named scopes;
# Current format (unnamed nesting) is supported by {{default}} marked scope;
# field are accepted only if they are defined at the certain scope, beside of 
the _global_ ones.

h3. Default experience 
*# submitting {{q=\*:\*=\*}} responds root documents with all children from 
all subscopes nested in according to the scopes hierarchy. i.e. \[child] is 
*on* by default
*# {{fq=}} aims root docs

h3. Query
# let's follow -Elastic- JSON.facet idea, and piggyback on its' request parsing 
facilities;   
# this query should contains of nested query nodes, every node represent 
\{!parser param=baram v='input'};
# this syntax should have handy defaluts/shortcut, to search {{foo:bar}} in 
less than fifteen brackets,quotes and commas;
# it should use existing QParsers including \{!func} ;
# searching scopes is supported by _named scope_ QParser, handled in this 
syntax by regular way;
# subscope query should be easily hooked in any occur (should, must, not )  ;
# it should be available in a dedicated \[transformer], and support the 
following scenarios: search parents by certain children, return them nested in 
response _without repeating query_, do the same but return all children of 
selected parents   ;
# naming standalone nodes and referencing them is cool.

h3. Update/deletes/uniqueness/versioning
# delete query/id hits root docs, and also nukes subordinate children;
# updating existing root doc completely removes existing subdocs, and replace 
all of them with the new ones ;
# field update fully rewrites whole doc hierarchy, and can aim any subdoc in 
hierarchy (this won't be easy, how to identify children?)
# (!) unique id value should span whole block (?) oh'really?? _it seems like we 
can avoid it_ 
# (?) do we need to identify separate subdocs with id? probably _yes_ for field 
updates  
# _version_ should span whole block (_If I've got the recent SOLR-10114 right_) 

h3. Faceting
# subject for support by Json.facet

h3. Named scopes support in DIH
# _Old sport_, you know.

h2. Inception
[comment|https://issues.apache.org/jira/browse/LUCENE-7674?focusedCommentId=15855698=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15855698]
 and [the next 
one|https://issues.apache.org/jira/browse/LUCENE-7674?focusedCommentId=15855708=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15855708]

  was:
This is a placeholder for new block join design. Let's comeup with the name 
first: whether it will be nested, child docs or blocks? 
h2. Feature Delivery plan
h3. Naming
Nested Documents

h3. Scopes in schema.xml 
*# fields can be grouped with {{}}
*# it can be _any_ level deep, and fan out _any_ subscopes (they are necessary 
for distinguishing {{sons}}, {{daugthers}})
*# (?) I'm not sure whether {{name}} is uniq or traverse path is unique. btw, 
maybe  {{type}} (?).   
*# {{default}} attribute is necessary to map existing blocks, which has only 
single nesting dimension: {{childrenDocuments}}  
*# fields beside of scopes (_global_) can appear on any scope
*# coming to roots (?) how many root scopes we can have? I think we can have a 
few ones that introducing notion of document types. 

h3. Updates
*# All formats XML, JSON, JSONdoc, Javabin accept nesting in named scopes. 
*# Current format (unnamed nesting) is supported by {{default}} marked scope.
*# field are accepted only if they are defined at the certain scope, beside of 
the _global_ ones

h3. Default experience 
*# submitting {{q=*:*=*}} responds root documents with all children from all 
subscopes nested in according to the scopes hierarchy. i.e. \[child] is *on* by 
default
*# {{fq=}} aims root docs

h3. Query
*# let's follow -Elastic- JSON.facet idea, and piggyback on its' request 
parsing facilities   
*# this query should contains of nested 

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

[Policeman Jenkins Server]

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

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

Error Message:
expected:<152> but was:<141>

Stack Trace:
java.lang.AssertionError: expected:<152> but was:<141>
at 
__randomizedtesting.SeedInfo.seed([B402B6074086A705:3C5689DDEE7ACAFD]: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.PeerSyncReplicationTest.bringUpDeadNodeAndEnsureNoReplication(PeerSyncReplicationTest.java:286)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.forceNodeFailureAndDoPeerSync(PeerSyncReplicationTest.java:259)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:138)
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 

[jira] [Commented] (SOLR-7242) Schema API: Edit remaining schema elements: Name, Version, Unique Key, and Global Similarity

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-7242:


And _perhaps_ starting with 7.0, schema version be removed in lieu of using 
luceneMatchVersion for this.  One less thing to manage.

Separately, I'd like to see the _removal_ of deprecated things like default 
field & default query operator from this API.  It's odd they were created in 
the first place since these underlying schema features have been deprecated for 
a long time now.

> Schema API: Edit remaining schema elements: Name, Version, Unique Key, and 
> Global Similarity
> 
>
> Key: SOLR-7242
> URL: https://issues.apache.org/jira/browse/SOLR-7242
> Project: Solr
>  Issue Type: Sub-task
>  Components: Schema and Analysis
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>
> We should be able to specify an entire schema via the bulk schema API.
> The bulk schema API should have the following commands in addition to those 
> already available/planned:
> # {{set-name}}
> # {{set-version}}
> # {{set-unique-key}}/{{unset-unique-key}}
> # {{set-similarity}}



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

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

[jira] [Commented] (SOLR-7242) Schema API: Edit remaining schema elements: Name, Version, Unique Key, and Global Similarity

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-7242:


I suggest tossing the notion of a schema name.  It tends to be something copied 
from another configset, e.g. "example" and never updated which creates 
misinformation as it stays.

> Schema API: Edit remaining schema elements: Name, Version, Unique Key, and 
> Global Similarity
> 
>
> Key: SOLR-7242
> URL: https://issues.apache.org/jira/browse/SOLR-7242
> Project: Solr
>  Issue Type: Sub-task
>  Components: Schema and Analysis
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>
> We should be able to specify an entire schema via the bulk schema API.
> The bulk schema API should have the following commands in addition to those 
> already available/planned:
> # {{set-name}}
> # {{set-version}}
> # {{set-unique-key}}/{{unset-unique-key}}
> # {{set-similarity}}



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

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

[jira] [Updated] (SOLR-10144) redesign block-join support

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-10144:

Description: 
This is a placeholder for new block join design. Let's comeup with the name 
first: whether it will be nested, child docs or blocks? 
h2. Feature Delivery plan
h3. Naming
Nested Documents

h3. Scopes in schema.xml 
*# fields can be grouped with {{}}
*# it can be _any_ level deep, and fan out _any_ subscopes (they are necessary 
for distinguishing {{sons}}, {{daugthers}})
*# (?) I'm not sure whether {{name}} is uniq or traverse path is unique. btw, 
maybe  {{type}} (?).   
*# {{default}} attribute is necessary to map existing blocks, which has only 
single nesting dimension: {{childrenDocuments}}  
*# fields beside of scopes (_global_) can appear on any scope
*# coming to roots (?) how many root scopes we can have? I think we can have a 
few ones that introducing notion of document types. 

h3. Updates
*# All formats XML, JSON, JSONdoc, Javabin accept nesting in named scopes. 
*# Current format (unnamed nesting) is supported by {{default}} marked scope.
*# field are accepted only if they are defined at the certain scope, beside of 
the _global_ ones

h3. Default experience 
*# submitting {{q=*:*=*}} responds root documents with all children from all 
subscopes nested in according to the scopes hierarchy. i.e. \[child] is *on* by 
default
*# {{fq=}} aims root docs

h3. Query
*# let's follow -Elastic- JSON.facet idea, and piggyback on its' request 
parsing facilities   
*# this query should contains of nested nodes, every node represent \{!parser 
param=baram v='input'}
*# this syntax should have handy defaluts/shortcut, to search {{foo:bar}} in 
less than fifteen brackets,quotes and commas
*# it should use existing QParsers including \{!func} 
*# searching scopes is supported by _named scope_ QParser, handled in this 
syntax by regular way
*# subscope query should be easily hooked in any occur (should, must, not )  
*# it should be available in a dedicated \[transformer], and support the 
following scenarios: search parents by certain children, return them nested in 
response _without repeating query_, do the same but return all children of 
selected parents   
*# naming separate nodes and named references is cool

h3. Update/deletes/uniqueness/versioning
*# delete query/id hits root docs, and also nukes subordinate children
*# updating existing root doc completely removes existing subdocs, and replace 
all of them with the new one 
*# field update fully rewrites whole doc hierarchy, and can aim any subdoc in 
hierarchy (this won't be easy, how to identify children?)
*# (!) unique id value should span whole block (?) oh'really?? _it seems like 
we can avoid it_ 
*# (?) do we need to identify separate subdocs with id? probably _yes_ for 
field updates  
*# _version_ should span whole block (_If I've got the recent SOLR-10114 
right_) 

h3. Faceting
subject for support by Json.facet

h3. Named scopes support in DIH
_Old sport_, you know.

h2. Inception
[comment|https://issues.apache.org/jira/browse/LUCENE-7674?focusedCommentId=15855698=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15855698]
 and [the next 
one|https://issues.apache.org/jira/browse/LUCENE-7674?focusedCommentId=15855708=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15855708]

  was:
This is a placeholder for new block join design. Let's comeup with the name 
first: whether it will be nested, child docs or blocks? 
h2. Feature Delivery plan
 
h2. Idea
[comment|https://issues.apache.org/jira/browse/LUCENE-7674?focusedCommentId=15855698=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15855698]
 and [the 
next|https://issues.apache.org/jira/browse/LUCENE-7674?focusedCommentId=15855708=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15855708]


> redesign block-join support
> ---
>
> Key: SOLR-10144
> URL: https://issues.apache.org/jira/browse/SOLR-10144
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers, update
> Environment: Java. https://wiki.apache.org/solr/HowToContribute
>Reporter: Mikhail Khludnev
>  Labels: gsoc2017, java
>
> This is a placeholder for new block join design. Let's comeup with the name 
> first: whether it will be nested, child docs or blocks? 
> h2. Feature Delivery plan
> h3. Naming
> Nested Documents
> h3. Scopes in schema.xml 
> *# fields can be grouped with {{}}
> *# it can be _any_ level deep, and fan out _any_ subscopes (they are 
> necessary for distinguishing {{sons}}, {{daugthers}})
> *# (?) I'm not sure whether {{name}} is uniq or traverse path is unique. btw, 
> maybe  {{type}} (?). 

[jira] [Commented] (SOLR-10114) Reordered delete-by-query can delete or omit child documents

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10114:


Commit 7a45f1015e73bc4f793a63be6b7414d53e008e05 in lucene-solr's branch 
refs/heads/master from [~yo...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7a45f10 ]

SOLR-10114: fix flakey TestRecovery


> Reordered delete-by-query can delete or omit child documents
> 
>
> Key: SOLR-10114
> URL: https://issues.apache.org/jira/browse/SOLR-10114
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 4.5
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: master (7.0)
>
> Attachments: SOLR-10114-2.patch, SOLR-10114-2.patch, 
> SOLR-10114-3.patch, SOLR-10114.patch, SOLR-10114.patch, 
> SOLR-10114-test-cleanup.patch, SOLR-10114-validation.patch
>
>
> It looks like when a block of documents is indexed, child documents get no 
> \_version\_ field.  This means (among other potential issues) that a 
> delete-by-query that is reordered will cause matching child documents to be 
> deleted.  DBQ normally prevents deleting newer docs by including a 
> restriction on \_version\_, which doesn't work for anything lacking that 
> field.  Re-ordered delete-by-term of any child docs would also be affected 
> (although it should be a much rarer issue.)
> The leading candidate for a fix is to use the exact same \_version\_ for all 
> child docs.



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

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

[jira] [Updated] (SOLR-10114) Reordered delete-by-query can delete or omit child documents

[Mano Kovacs (JIRA)]

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

Mano Kovacs updated SOLR-10114:
---
Attachment: SOLR-10114-3.patch

Adding test fix 
I went with namespacing, as monotonic counter would be a bigger change (added 
jira for that SOLR-10151).
I changed the {{id:*}} to delete by id and by root, since the purpose of the 
test was to validate that DBQ replayed version filter protects child-docs as 
well.

Sorry for the inconvenience.

> Reordered delete-by-query can delete or omit child documents
> 
>
> Key: SOLR-10114
> URL: https://issues.apache.org/jira/browse/SOLR-10114
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 4.5
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: master (7.0)
>
> Attachments: SOLR-10114-2.patch, SOLR-10114-2.patch, 
> SOLR-10114-3.patch, SOLR-10114.patch, SOLR-10114.patch, 
> SOLR-10114-test-cleanup.patch, SOLR-10114-validation.patch
>
>
> It looks like when a block of documents is indexed, child documents get no 
> \_version\_ field.  This means (among other potential issues) that a 
> delete-by-query that is reordered will cause matching child documents to be 
> deleted.  DBQ normally prevents deleting newer docs by including a 
> restriction on \_version\_, which doesn't work for anything lacking that 
> field.  Re-ordered delete-by-term of any child docs would also be affected 
> (although it should be a much rarer issue.)
> The leading candidate for a fix is to use the exact same \_version\_ for all 
> child docs.



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

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

[jira] [Created] (SOLR-10151) TestRecovery.java - use monotonic increasing version number among all the tests to avoid unintentional reordering

[Mano Kovacs (JIRA)]

Mano Kovacs created SOLR-10151:
--

 Summary: TestRecovery.java - use monotonic increasing version 
number among all the tests to avoid unintentional reordering
 Key: SOLR-10151
 URL: https://issues.apache.org/jira/browse/SOLR-10151
 Project: Solr
  Issue Type: Test
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Mano Kovacs
Priority: Minor


{{TestRecovery}} has several tests inserting updates and deletes into a shared 
core. The tests are using fixed version number which can overlap and can cause 
issues depending on the order of the tests.

Proposing using a monotonically incrementing counter for each test and changing 
tests that they would allocate the used versions would ensure that later 
running tests would send updates with higher version only. That would prevent 
any intentional reordering.

h5. Example:
Before:
{noformat}
...
updateJ(jsonAdd(sdoc("id", "RDBQ1_1", "_version_", "1010")), 
params(DISTRIB_UPDATE_PARAM, FROM_LEADER));
updateJ(jsonDelQ("id:RDBQ1_2"), params(DISTRIB_UPDATE_PARAM, FROM_LEADER, 
"_version_", "-1017")); // This should've arrived after the 1015th update
updateJ(jsonAdd(sdoc("id", "RDBQ1_2", "_version_", "1015")), 
params(DISTRIB_UPDATE_PARAM, FROM_LEADER));
updateJ(jsonAdd(sdoc("id", "RDBQ1_3", "_version_", "1020")), 
params(DISTRIB_UPDATE_PARAM, FROM_LEADER));
...
{noformat}
After:
{noformat}
...
String insVer1 = getNextVersion();
String insVer2 = getNextVersion();
String deleteVer = getNextVersion();
String insVer3 = getNextVersion();
updateJ(jsonAdd(sdoc("id", "RDBQ1_1", "_version_",insVer1)), 
params(DISTRIB_UPDATE_PARAM, FROM_LEADER));
updateJ(jsonDelQ("id:RDBQ1_2"), params(DISTRIB_UPDATE_PARAM, FROM_LEADER, 
"_version_", "-"+deleteVer)); // This should've arrived after the 1015th update
updateJ(jsonAdd(sdoc("id", "RDBQ1_2", "_version_", insVer2)), 
params(DISTRIB_UPDATE_PARAM, FROM_LEADER));
updateJ(jsonAdd(sdoc("id", "RDBQ1_3", "_version_", insVer3)), 
params(DISTRIB_UPDATE_PARAM, FROM_LEADER));
...
{noformat}

It might increase readability as the generation of the versions happen in the 
preferred replay order.



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

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

Re: Solr JIRA: Merge components "web gui" and "UI"

[Jan Høydahl]

We could start by narrowing the admin group to equal the PMC group and then 
educate ourselves about when (not) to create new components or releases. 

Then if someone need admin rights (I could imagine e.g. Release Managers) we 
could tackle it as we go.

Next, someone suggests a complete revised component list (keep it short) and we 
clean up the mess (when you click delete you are asked what component to move 
the issues to instead so that part is easy).

Jan

Sendt fra min iPhone

> Den 16. feb. 2017 kl. 17.33 skrev Alexandre Rafalovitch :
> 
> I thought I had a memory of being able to add a component before I got
> committer access. But perhaps it would have been rejected when I
> clicked submit. Or my memory is faulty.
> 
> Either way, that was the reason I thought maybe some permission got
> perhaps assigned to 'Registered' users. I am happy to be wrong, it
> will make things easier.
> 
> Regards,
>   Alex.
> 
> http://www.solr-start.com/ - Resources for Solr users, new and experienced
> 
> 
>> On 16 February 2017 at 11:23, Cassandra Targett  
>> wrote:
>> On Thu, Feb 16, 2017 at 10:17 AM, Alexandre Rafalovitch
>>  wrote:
>>> Are we SURE that the role has not been relaxed by INFRA? Because if it
>>> is just us, we could do a one-time cleanup and try to be neat.
>> 
>> Relaxed in what way? That all users have project admin-level
>> permissions? That seems unlikely.
>> 
>> It's a default setting in JIRA that can't be changed. If you read the
>> comments in that issue Jan pointed to, the situation becomes clear: If
>> you have project admin permissions, you can edit components (by
>> default, and unchangeable) because that's part of administering a
>> project, and thus you have permission to create them on the fly in the
>> UI (also by default, and unchangeable).
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

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

[jira] [Commented] (SOLR-10114) Reordered delete-by-query can delete or omit child documents

[Mano Kovacs (JIRA)]

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

Mano Kovacs commented on SOLR-10114:


Yeah, that could be simple solution, but saying that we cannot test {{id:*}} 
for that reason is not too robust. I am thinking of creating an only 
incrementing version counter, so tests could not insert future deletes for each 
other. It would be a future-proof solution, I guess.

> Reordered delete-by-query can delete or omit child documents
> 
>
> Key: SOLR-10114
> URL: https://issues.apache.org/jira/browse/SOLR-10114
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 4.5
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: master (7.0)
>
> Attachments: SOLR-10114-2.patch, SOLR-10114-2.patch, 
> SOLR-10114.patch, SOLR-10114.patch, SOLR-10114-test-cleanup.patch, 
> SOLR-10114-validation.patch
>
>
> It looks like when a block of documents is indexed, child documents get no 
> \_version\_ field.  This means (among other potential issues) that a 
> delete-by-query that is reordered will cause matching child documents to be 
> deleted.  DBQ normally prevents deleting newer docs by including a 
> restriction on \_version\_, which doesn't work for anything lacking that 
> field.  Re-ordered delete-by-term of any child docs would also be affected 
> (although it should be a much rarer issue.)
> The leading candidate for a fix is to use the exact same \_version\_ for all 
> child docs.



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

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

[jira] [Commented] (LUCENE-6819) Deprecate index-time boosts?

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-6819:
--

I agree index-time and search-time boosting have different trade-offs that may 
both be interesting. The problem I have is that supporting index-time boosts 
means that length norm is less accurate for _everyone_. Right now if you do not 
use index-time boosts, which I think is the case for a majority of users, you 
end up with a length norm that is between 0 and 1 ({{1/sqrt(fieldLen)}}). The 
length norm may only be greater than 1 if you use a boost that is greater than 
1. Out of the 256 values that {{SmallFloat.byte315ToFloat}} supports, only 125 
of them are less than or equal to 1, the other 131 values are all greater than 
1. Said otherwise, more than half the norm values we support are wasted if you 
do not use index-time boosts.

If instead we could assume that norms were always between 0 and 1, we could 
take one bit from the exponent and spend it on the mantissa instead to improve 
accuracy. For instance I rebuilt the table that had been built for LUCENE-5005 
and expanded it with a couple more length values, as well as what the rounded 
norm would be if we spent 1 more bit on the mantissa (while still being able to 
encode the norm on a single byte, see the float415 column):

||numTerms||1/sqrt(numTerms)||1/sqrt(numTerms) to float315||1/sqrt(numTerms) to 
float415||
| 1 | 1.0 | 1.0 | 1.0 |
| 2 | 0.70710677 | 0.625 | 0.6875 |
| 3 | 0.57735026 | 0.5 | 0.5625 |
| 4 | 0.5 | 0.5 | 0.5 |
| 5 | 0.4472136 | 0.4375 | 0.4375 |
| 6 | 0.4082483 | 0.375 | 0.40625 |
| 7 | 0.37796447 | 0.375 | 0.375 |
| 8 | 0.35355338 | 0.3125 | 0.34375 |
| 9 | 0.3334 | 0.3125 | 0.3125 |
| 10 | 0.31622776 | 0.3125 | 0.3125 |
| 11 | 0.30151135 | 0.25 | 0.28125 |
| 12 | 0.28867513 | 0.25 | 0.28125 |
| 13 | 0.2773501 | 0.25 | 0.25 |
| 14 | 0.26726124 | 0.25 | 0.25 |
| 15 | 0.2581989 | 0.25 | 0.25 |
| 16 | 0.25 | 0.25 | 0.25 |
| 17 | 0.24253562 | 0.21875 | 0.234375 |
| 18 | 0.23570226 | 0.21875 | 0.234375 |
| 19 | 0.22941573 | 0.21875 | 0.21875 |
| 20 | 0.2236068 | 0.21875 | 0.21875 |

Something I really like about it is that for all length values between 1 and 9 
included, you get different values for the rounded norms. I have seen several 
users asking why "A B C D" would score as well as "A B C" when the query is eg. 
"A" in spite of being longer, and if we could get this addressed for short 
fields (think eg. product names), I think that would be a great win.

> Deprecate index-time boosts?
> 
>
> Key: LUCENE-6819
> URL: https://issues.apache.org/jira/browse/LUCENE-6819
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
>Priority: Minor
>
> Follow-up of this comment: 
> https://issues.apache.org/jira/browse/LUCENE-6818?focusedCommentId=14934801=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14934801
> Index-time boosts are a very expert feature whose behaviour is tight to the 
> Similarity impl. Additionally users have often be confused by the poor 
> precision due to the fact that we encode values on a single byte. But now we 
> have doc values that allow you to encode any values the way you want with as 
> much precision as you need so maybe we should deprecate index-time boosts and 
> recommend to encode index-time scoring factors into doc values fields instead.



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

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

[JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+155) - Build # 2870 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2870/
Java: 32bit/jdk-9-ea+155 -server -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.handler.admin.TestApiFramework.testFramework

Error Message:


Stack Trace:
java.lang.ExceptionInInitializerError
at 
__randomizedtesting.SeedInfo.seed([1419B784F4F20FF4:36F7DA3F226E3C9]:0)
at 
net.sf.cglib.core.KeyFactory$Generator.generateClass(KeyFactory.java:166)
at 
net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25)
at 
net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:216)
at net.sf.cglib.core.KeyFactory$Generator.create(KeyFactory.java:144)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:116)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:108)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:104)
at net.sf.cglib.proxy.Enhancer.(Enhancer.java:69)
at 
org.easymock.internal.ClassProxyFactory.createEnhancer(ClassProxyFactory.java:259)
at 
org.easymock.internal.ClassProxyFactory.createProxy(ClassProxyFactory.java:174)
at org.easymock.internal.MocksControl.createMock(MocksControl.java:60)
at org.easymock.EasyMock.createMock(EasyMock.java:104)
at 
org.apache.solr.handler.admin.TestCoreAdminApis.getCoreContainerMock(TestCoreAdminApis.java:83)
at 
org.apache.solr.handler.admin.TestApiFramework.testFramework(TestApiFramework.java:59)
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:543)
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 

[jira] [Commented] (SOLR-7341) xjoin - join data from external sources

[Shamik Bandopadhyay (JIRA)]

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

Shamik Bandopadhyay commented on SOLR-7341:
---

The master or the trunk patch (SOLR-7341.patch-master/SOLR-7341.patch-trunk) 
doesn't seem to work with 5.5 version onwards. I've tried applying the patch on 
5.5/6.0/master source code, but it fails. Is it compatible with the above 
versions?

> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Tom Winch
>Priority: Minor
> Fix For: 4.10.3, 5.3.2, 6.0
>
> Attachments: SOLR-7341.patch-4_10, SOLR-7341.patch-4.10.3, 
> SOLR-7341.patch-5_3, SOLR-7341.patch-5.3.2, SOLR-7341.patch-master, 
> SOLR-7341.patch-trunk, SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR 
> results in a query and the SOLR result set to be filtered by the results of 
> an external query. Values from the external results are made available in the 
> SOLR results and may also be used to boost the scores of corresponding 
> documents during the search. The contrib consists of the Java classes 
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and 
> associated classes), which must be configured in solrconfig.xml, and the 
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the 
> user to provide the link between SOLR and the external results source (but 
> see below for details of how to use the in-built SimpleXJoinResultsFactory 
> implementation). External results and SOLR documents are matched via a single 
> configurable attribute (the "join field").
> To include the XJoin contrib classes, add the following config to 
> solrconfig.xml:
> {code:xml}
> 
>   ..
>
>regex=".*\.jar" />
>regex="solr-xjoin-\d.*\.jar" />
>   ..
> 
> {code}
> Note that any JARs containing implementations of the XJoinResultsFactory must 
> also be included.
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an 
> external source to perform a query (or otherwise collect results). Parameters 
> with prefix ".external." are passed from the SOLR query URL 
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and 
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR 
> search to generate external results, and is passed parameters from the SOLR 
> query URL (as above)
> For example, the implementation might perform queries of an external source 
> based on the 'q' SOLR query URL parameter (in full,  name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults() 
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result 
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending) 
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component, 
> configured in solrconfig.xml and included in one or more SOLR request 
> handlers. There is one XJoin search component per external source, and each 
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves 
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and 
> external results via the join field, adding attributes from the external 
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing 
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR 
> documents and external results
> * external - this parameter set is passed to configure the 
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
>  class="org.apache.solr.search.xjoin.XJoinSearchComponent">
>   test.TestXJoinResultsFactory
>   id
>   
> 1,2,3
>   
> 
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during 
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure 
> it. To properly use the XJoinSearchComponent in a request handler, it must be 
> included at 

[jira] [Commented] (SOLR-10114) Reordered delete-by-query can delete or omit child documents

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-10114:
-

Test methods of a test class are run in a randomized order.  Transaction log 
tests are tricky since tests can see what the previous tests left behind in the 
transaction logs.  This is why I used different ID spaces for some of these 
tests (id:A1,A2,... for one test, id:B1,B2, etc for another test).

Perhaps try making any delete-by-queries test-specific?

> Reordered delete-by-query can delete or omit child documents
> 
>
> Key: SOLR-10114
> URL: https://issues.apache.org/jira/browse/SOLR-10114
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 4.5
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: master (7.0)
>
> Attachments: SOLR-10114-2.patch, SOLR-10114-2.patch, 
> SOLR-10114.patch, SOLR-10114.patch, SOLR-10114-test-cleanup.patch, 
> SOLR-10114-validation.patch
>
>
> It looks like when a block of documents is indexed, child documents get no 
> \_version\_ field.  This means (among other potential issues) that a 
> delete-by-query that is reordered will cause matching child documents to be 
> deleted.  DBQ normally prevents deleting newer docs by including a 
> restriction on \_version\_, which doesn't work for anything lacking that 
> field.  Re-ordered delete-by-term of any child docs would also be affected 
> (although it should be a much rarer issue.)
> The leading candidate for a fix is to use the exact same \_version\_ for all 
> child docs.



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

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

[jira] [Commented] (LUCENE-7449) Add CROSSES query support to RangeField

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7449: Add CROSSES relation support to RangeFieldQuery.


> Add CROSSES query support to RangeField
> ---
>
> Key: LUCENE-7449
> URL: https://issues.apache.org/jira/browse/LUCENE-7449
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Nicholas Knize
> Attachments: LUCENE-7449.patch, LUCENE-7449.patch, LUCENE-7449.patch
>
>
> {{RangeField}} currently supports {{INTERSECTS}}, {{WITHIN}}, and 
> {{CONTAINS}} query behavior. This feature adds support for an explicit 
> {{CROSSES}} query. Unlike {{INTERSECT}} and {{OVERLAP}} queries the 
> {{CROSSES}} query finds any indexed ranges whose interior (within range) 
> intersect the interior AND exterior (outside range) of the query range.



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

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

[jira] [Comment Edited] (SOLR-10114) Reordered delete-by-query can delete or omit child documents

[Mano Kovacs (JIRA)]

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

Mano Kovacs edited comment on SOLR-10114 at 2/16/17 6:55 PM:
-

Yeah, conflict between tests.
{noformat}
26292 INFO  (TEST-TestRecovery.testCorruptLog-seed#[BC979C5AA13AC6F7]) [] 
o.a.s.u.DirectUpdateHandler2 Reordered DBQs detected.  
Update=add{_version_=104,id=G4} DBQs=[DBQ{version=1017,q=id:*}]
26331 INFO  (TEST-TestRecovery.testCorruptLog-seed#[BC979C5AA13AC6F7]) [] 
o.a.s.s.SolrIndexSearcher Opening [Searcher@26c39adc[collection1] realtime]
26331 INFO  (TEST-TestRecovery.testCorruptLog-seed#[BC979C5AA13AC6F7]) [] 
o.a.s.u.p.LogUpdateProcessorFactory [collection1]  webapp=null path=null 
params={update.distrib=FROMLEADER=json=true}{add=[G4 (104)]} 0 40
26332 INFO  (TEST-TestRecovery.testCorruptLog-seed#[BC979C5AA13AC6F7]) [] 
o.a.s.u.DirectUpdateHandler2 Reordered DBQs detected.  
Update=add{_version_=105,id=G5} DBQs=[DBQ{version=1017,q=id:*}]
26349 INFO  (TEST-TestRecovery.testCorruptLog-seed#[BC979C5AA13AC6F7]) [] 
o.a.s.s.SolrIndexSearcher Opening [Searcher@17fd92d4[collection1] realtime]
26349 INFO  (TEST-TestRecovery.testCorruptLog-seed#[BC979C5AA13AC6F7]) [] 
o.a.s.u.p.LogUpdateProcessorFactory [collection1]  webapp=null path=null 
params={update.distrib=FROMLEADER=json=true}{add=[G5 (105)]} 0 17
26350 INFO  (TEST-TestRecovery.testCorruptLog-seed#[BC979C5AA13AC6F7]) [] 
o.a.s.u.DirectUpdateHandler2 Reordered DBQs detected.  
Update=add{_version_=106,id=G6} DBQs=[DBQ{version=1017,q=id:*}]
26374 INFO  (TEST-TestRecovery.testCorruptLog-seed#[BC979C5AA13AC6F7]) [] 
o.a.s.s.SolrIndexSearcher Opening [Searcher@6453c66a[collection1] realtime]
{noformat}

The {{id:*}} is from the newly added tests. SOLR-9941 was supposed to resolve 
this, but it does not, I am trying to work it out but any idea is welcome.


was (Author: manokovacs):
Yeah, conflict between tests.
{{noformat}}
26292 INFO  (TEST-TestRecovery.testCorruptLog-seed#[BC979C5AA13AC6F7]) [] 
o.a.s.u.DirectUpdateHandler2 Reordered DBQs detected.  
Update=add{_version_=104,id=G4} DBQs=[DBQ{version=1017,q=id:*}]
26331 INFO  (TEST-TestRecovery.testCorruptLog-seed#[BC979C5AA13AC6F7]) [] 
o.a.s.s.SolrIndexSearcher Opening [Searcher@26c39adc[collection1] realtime]
26331 INFO  (TEST-TestRecovery.testCorruptLog-seed#[BC979C5AA13AC6F7]) [] 
o.a.s.u.p.LogUpdateProcessorFactory [collection1]  webapp=null path=null 
params={update.distrib=FROMLEADER=json=true}{add=[G4 (104)]} 0 40
26332 INFO  (TEST-TestRecovery.testCorruptLog-seed#[BC979C5AA13AC6F7]) [] 
o.a.s.u.DirectUpdateHandler2 Reordered DBQs detected.  
Update=add{_version_=105,id=G5} DBQs=[DBQ{version=1017,q=id:*}]
26349 INFO  (TEST-TestRecovery.testCorruptLog-seed#[BC979C5AA13AC6F7]) [] 
o.a.s.s.SolrIndexSearcher Opening [Searcher@17fd92d4[collection1] realtime]
26349 INFO  (TEST-TestRecovery.testCorruptLog-seed#[BC979C5AA13AC6F7]) [] 
o.a.s.u.p.LogUpdateProcessorFactory [collection1]  webapp=null path=null 
params={update.distrib=FROMLEADER=json=true}{add=[G5 (105)]} 0 17
26350 INFO  (TEST-TestRecovery.testCorruptLog-seed#[BC979C5AA13AC6F7]) [] 
o.a.s.u.DirectUpdateHandler2 Reordered DBQs detected.  
Update=add{_version_=106,id=G6} DBQs=[DBQ{version=1017,q=id:*}]
26374 INFO  (TEST-TestRecovery.testCorruptLog-seed#[BC979C5AA13AC6F7]) [] 
o.a.s.s.SolrIndexSearcher Opening [Searcher@6453c66a[collection1] realtime]
{{noformat}}

The {{id:*}} is from the newly added tests. SOLR-9941 was supposed to resolve 
this, but it does not, I am trying to work it out but any idea is welcome.

> Reordered delete-by-query can delete or omit child documents
> 
>
> Key: SOLR-10114
> URL: https://issues.apache.org/jira/browse/SOLR-10114
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 4.5
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: master (7.0)
>
> Attachments: SOLR-10114-2.patch, SOLR-10114-2.patch, 
> SOLR-10114.patch, SOLR-10114.patch, SOLR-10114-test-cleanup.patch, 
> SOLR-10114-validation.patch
>
>
> It looks like when a block of documents is indexed, child documents get no 
> \_version\_ field.  This means (among other potential issues) that a 
> delete-by-query that is reordered will cause matching child documents to be 
> deleted.  DBQ normally prevents deleting newer docs by including a 
> restriction on \_version\_, which doesn't work for anything lacking that 
> field.  Re-ordered delete-by-term of any child docs would also be affected 
> (although it should be a much rarer issue.)
> The leading candidate for a fix is to use the exact same \_version\_ for all 
> child docs.



--

[jira] [Commented] (SOLR-10114) Reordered delete-by-query can delete or omit child documents

[Mano Kovacs (JIRA)]

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

Mano Kovacs commented on SOLR-10114:


Yeah, conflict between tests.
{{noformat}}
26292 INFO  (TEST-TestRecovery.testCorruptLog-seed#[BC979C5AA13AC6F7]) [] 
o.a.s.u.DirectUpdateHandler2 Reordered DBQs detected.  
Update=add{_version_=104,id=G4} DBQs=[DBQ{version=1017,q=id:*}]
26331 INFO  (TEST-TestRecovery.testCorruptLog-seed#[BC979C5AA13AC6F7]) [] 
o.a.s.s.SolrIndexSearcher Opening [Searcher@26c39adc[collection1] realtime]
26331 INFO  (TEST-TestRecovery.testCorruptLog-seed#[BC979C5AA13AC6F7]) [] 
o.a.s.u.p.LogUpdateProcessorFactory [collection1]  webapp=null path=null 
params={update.distrib=FROMLEADER=json=true}{add=[G4 (104)]} 0 40
26332 INFO  (TEST-TestRecovery.testCorruptLog-seed#[BC979C5AA13AC6F7]) [] 
o.a.s.u.DirectUpdateHandler2 Reordered DBQs detected.  
Update=add{_version_=105,id=G5} DBQs=[DBQ{version=1017,q=id:*}]
26349 INFO  (TEST-TestRecovery.testCorruptLog-seed#[BC979C5AA13AC6F7]) [] 
o.a.s.s.SolrIndexSearcher Opening [Searcher@17fd92d4[collection1] realtime]
26349 INFO  (TEST-TestRecovery.testCorruptLog-seed#[BC979C5AA13AC6F7]) [] 
o.a.s.u.p.LogUpdateProcessorFactory [collection1]  webapp=null path=null 
params={update.distrib=FROMLEADER=json=true}{add=[G5 (105)]} 0 17
26350 INFO  (TEST-TestRecovery.testCorruptLog-seed#[BC979C5AA13AC6F7]) [] 
o.a.s.u.DirectUpdateHandler2 Reordered DBQs detected.  
Update=add{_version_=106,id=G6} DBQs=[DBQ{version=1017,q=id:*}]
26374 INFO  (TEST-TestRecovery.testCorruptLog-seed#[BC979C5AA13AC6F7]) [] 
o.a.s.s.SolrIndexSearcher Opening [Searcher@6453c66a[collection1] realtime]
{{noformat}}

The {{id:*}} is from the newly added tests. SOLR-9941 was supposed to resolve 
this, but it does not, I am trying to work it out but any idea is welcome.

> Reordered delete-by-query can delete or omit child documents
> 
>
> Key: SOLR-10114
> URL: https://issues.apache.org/jira/browse/SOLR-10114
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 4.5
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: master (7.0)
>
> Attachments: SOLR-10114-2.patch, SOLR-10114-2.patch, 
> SOLR-10114.patch, SOLR-10114.patch, SOLR-10114-test-cleanup.patch, 
> SOLR-10114-validation.patch
>
>
> It looks like when a block of documents is indexed, child documents get no 
> \_version\_ field.  This means (among other potential issues) that a 
> delete-by-query that is reordered will cause matching child documents to be 
> deleted.  DBQ normally prevents deleting newer docs by including a 
> restriction on \_version\_, which doesn't work for anything lacking that 
> field.  Re-ordered delete-by-term of any child docs would also be affected 
> (although it should be a much rarer issue.)
> The leading candidate for a fix is to use the exact same \_version\_ for all 
> child docs.



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

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

[jira] [Commented] (LUCENE-7449) Add CROSSES query support to RangeField

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7449: Add CROSSES relation support to RangeFieldQuery.


> Add CROSSES query support to RangeField
> ---
>
> Key: LUCENE-7449
> URL: https://issues.apache.org/jira/browse/LUCENE-7449
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Nicholas Knize
> Attachments: LUCENE-7449.patch, LUCENE-7449.patch, LUCENE-7449.patch
>
>
> {{RangeField}} currently supports {{INTERSECTS}}, {{WITHIN}}, and 
> {{CONTAINS}} query behavior. This feature adds support for an explicit 
> {{CROSSES}} query. Unlike {{INTERSECT}} and {{OVERLAP}} queries the 
> {{CROSSES}} query finds any indexed ranges whose interior (within range) 
> intersect the interior AND exterior (outside range) of the query range.



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

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

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

[Policeman Jenkins Server]

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

1 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([72450B024F3DBBC3:DA7395DFD05C5099]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.getCollectionNames(CloudSolrClient.java:1376)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1072)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1042)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:160)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:232)
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 

[jira] [Commented] (SOLR-10130) Serious performance degradation in Solr 6.4.1 due to the new metrics collection

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-10130:
---

Ah, ok. I take it this is a replica with a bunch of data in it? Although this 
doesn't make sense, there shouldn't be that much work do fire up a core absent 
tlog replay and the like but it sounds like you're far beyond that so I'm 
missing something.

Is there any way you could pull/build a new version of Solr 6.4 (or apply the 
patch on this JIRA locally) and try? I'd hate to have the 6.4.2 release get out 
(coming soon, due to this) and not have fixed a different issue.

> Serious performance degradation in Solr 6.4.1 due to the new metrics 
> collection
> ---
>
> Key: SOLR-10130
> URL: https://issues.apache.org/jira/browse/SOLR-10130
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 6.4.1
> Environment: Centos 7, OpenJDK 1.8.0 update 111
>Reporter: Ere Maijala
>Assignee: Andrzej Bialecki 
>Priority: Blocker
>  Labels: perfomance
> Fix For: master (7.0), 6.4.2
>
> Attachments: SOLR-10130.patch, SOLR-10130.patch, 
> solr-8983-console-f1.log
>
>
> We've stumbled on serious performance issues after upgrading to Solr 6.4.1. 
> Looks like the new metrics collection system in MetricsDirectoryFactory is 
> causing a major slowdown. This happens with an index configuration that, as 
> far as I can see, has no metrics specific configuration and uses 
> luceneMatchVersion 5.5.0. In practice a moderate load will completely bog 
> down the server with Solr threads constantly using up all CPU (600% on 6 core 
> machine) capacity with a load that normally  where we normally see an average 
> load of < 50%.
> I took stack traces (I'll attach them) and noticed that the threads are 
> spending time in com.codahale.metrics.Meter.mark. I tested building Solr 
> 6.4.1 with the metrics collection disabled in MetricsDirectoryFactory getByte 
> and getBytes methods and was unable to reproduce the issue.
> As far as I can see there are several issues:
> 1. Collecting metrics on every single byte read is slow.
> 2. Having it enabled by default is not a good idea.
> 3. The comment "enable coarse-grained metrics by default" at 
> https://github.com/apache/lucene-solr/blob/branch_6x/solr/core/src/java/org/apache/solr/update/SolrIndexConfig.java#L104
>  implies that only coarse-grained metrics should be enabled by default, and 
> this contradicts with collecting metrics on every single byte read.



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

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

[jira] [Commented] (SOLR-9916) Add arithmetic operations to the SelectStream

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-9916:


With these operations, we should be able to support literal comparison literal? 
That should help on the SQL pushdown piece.

> Add arithmetic operations to the SelectStream
> -
>
> Key: SOLR-9916
> URL: https://issues.apache.org/jira/browse/SOLR-9916
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Dennis Gove
> Attachments: SOLR-9916.patch, SOLR-9916.patch, SOLR-9916.patch, 
> SOLR-9916-precommit.patch
>
>
> One of the things that will be needed as the SQL implementation matures is 
> the ability to do arithmetic operations. For example:
> select (a+b) from x;
> select sum(a)+sum(b) from x;
> We will need to support arithmetic operations within the Streaming API to 
> support these types of operations.
> It looks like adding arithmetic operations to the SelectStream is the best 
> place to add this functionality.



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

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

[jira] [Commented] (SOLR-10114) Reordered delete-by-query can delete or omit child documents

[Mano Kovacs (JIRA)]

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

Mano Kovacs commented on SOLR-10114:


[~steve_rowe], thanks for pointing it out. I just noticed that too locally. Its 
some interdependency between the tests that I am trying to work out.

> Reordered delete-by-query can delete or omit child documents
> 
>
> Key: SOLR-10114
> URL: https://issues.apache.org/jira/browse/SOLR-10114
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 4.5
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: master (7.0)
>
> Attachments: SOLR-10114-2.patch, SOLR-10114-2.patch, 
> SOLR-10114.patch, SOLR-10114.patch, SOLR-10114-test-cleanup.patch, 
> SOLR-10114-validation.patch
>
>
> It looks like when a block of documents is indexed, child documents get no 
> \_version\_ field.  This means (among other potential issues) that a 
> delete-by-query that is reordered will cause matching child documents to be 
> deleted.  DBQ normally prevents deleting newer docs by including a 
> restriction on \_version\_, which doesn't work for anything lacking that 
> field.  Re-ordered delete-by-term of any child docs would also be affected 
> (although it should be a much rarer issue.)
> The leading candidate for a fix is to use the exact same \_version\_ for all 
> child docs.



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

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

[jira] [Commented] (SOLR-10130) Serious performance degradation in Solr 6.4.1 due to the new metrics collection

[Walter Underwood (JIRA)]

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

Walter Underwood commented on SOLR-10130:
-

I'm looking at how long the core is marked "recovering" in the cloud view of 
the admin UI.

There shouldn't be any recovery. The server process is restarted hours after 
the most recent update. I think this is how long it takes to get the core 
loaded and ready for search. Startup time, really.

> Serious performance degradation in Solr 6.4.1 due to the new metrics 
> collection
> ---
>
> Key: SOLR-10130
> URL: https://issues.apache.org/jira/browse/SOLR-10130
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 6.4.1
> Environment: Centos 7, OpenJDK 1.8.0 update 111
>Reporter: Ere Maijala
>Assignee: Andrzej Bialecki 
>Priority: Blocker
>  Labels: perfomance
> Fix For: master (7.0), 6.4.2
>
> Attachments: SOLR-10130.patch, SOLR-10130.patch, 
> solr-8983-console-f1.log
>
>
> We've stumbled on serious performance issues after upgrading to Solr 6.4.1. 
> Looks like the new metrics collection system in MetricsDirectoryFactory is 
> causing a major slowdown. This happens with an index configuration that, as 
> far as I can see, has no metrics specific configuration and uses 
> luceneMatchVersion 5.5.0. In practice a moderate load will completely bog 
> down the server with Solr threads constantly using up all CPU (600% on 6 core 
> machine) capacity with a load that normally  where we normally see an average 
> load of < 50%.
> I took stack traces (I'll attach them) and noticed that the threads are 
> spending time in com.codahale.metrics.Meter.mark. I tested building Solr 
> 6.4.1 with the metrics collection disabled in MetricsDirectoryFactory getByte 
> and getBytes methods and was unable to reproduce the issue.
> As far as I can see there are several issues:
> 1. Collecting metrics on every single byte read is slow.
> 2. Having it enabled by default is not a good idea.
> 3. The comment "enable coarse-grained metrics by default" at 
> https://github.com/apache/lucene-solr/blob/branch_6x/solr/core/src/java/org/apache/solr/update/SolrIndexConfig.java#L104
>  implies that only coarse-grained metrics should be enabled by default, and 
> this contradicts with collecting metrics on every single byte read.



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

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

[jira] [Commented] (SOLR-10114) Reordered delete-by-query can delete or omit child documents

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10114:
---

FYI all three repro lines above still reproduce after commit 
{{d49edabf8992c2b2f9e2583e289cc58a4e71fd31}}.

> Reordered delete-by-query can delete or omit child documents
> 
>
> Key: SOLR-10114
> URL: https://issues.apache.org/jira/browse/SOLR-10114
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 4.5
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: master (7.0)
>
> Attachments: SOLR-10114-2.patch, SOLR-10114-2.patch, 
> SOLR-10114.patch, SOLR-10114.patch, SOLR-10114-test-cleanup.patch, 
> SOLR-10114-validation.patch
>
>
> It looks like when a block of documents is indexed, child documents get no 
> \_version\_ field.  This means (among other potential issues) that a 
> delete-by-query that is reordered will cause matching child documents to be 
> deleted.  DBQ normally prevents deleting newer docs by including a 
> restriction on \_version\_, which doesn't work for anything lacking that 
> field.  Re-ordered delete-by-term of any child docs would also be affected 
> (although it should be a much rarer issue.)
> The leading candidate for a fix is to use the exact same \_version\_ for all 
> child docs.



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

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

[jira] [Commented] (SOLR-10130) Serious performance degradation in Solr 6.4.1 due to the new metrics collection

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-10130:
---

[~wunder]: If it's easy, could you try a manual fetchindex? Which you can even 
do in cloud mode. See: 
https://cwiki.apache.org/confluence/display/solr/Index+Replication#IndexReplication-HTTPAPICommandsfortheReplicationHandler

Or maybe just see if the logs show that this very long recovery happens when 
you have a full recovery, i.e. you're copying the full index down from the 
leader/master...





> Serious performance degradation in Solr 6.4.1 due to the new metrics 
> collection
> ---
>
> Key: SOLR-10130
> URL: https://issues.apache.org/jira/browse/SOLR-10130
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 6.4.1
> Environment: Centos 7, OpenJDK 1.8.0 update 111
>Reporter: Ere Maijala
>Assignee: Andrzej Bialecki 
>Priority: Blocker
>  Labels: perfomance
> Fix For: master (7.0), 6.4.2
>
> Attachments: SOLR-10130.patch, SOLR-10130.patch, 
> solr-8983-console-f1.log
>
>
> We've stumbled on serious performance issues after upgrading to Solr 6.4.1. 
> Looks like the new metrics collection system in MetricsDirectoryFactory is 
> causing a major slowdown. This happens with an index configuration that, as 
> far as I can see, has no metrics specific configuration and uses 
> luceneMatchVersion 5.5.0. In practice a moderate load will completely bog 
> down the server with Solr threads constantly using up all CPU (600% on 6 core 
> machine) capacity with a load that normally  where we normally see an average 
> load of < 50%.
> I took stack traces (I'll attach them) and noticed that the threads are 
> spending time in com.codahale.metrics.Meter.mark. I tested building Solr 
> 6.4.1 with the metrics collection disabled in MetricsDirectoryFactory getByte 
> and getBytes methods and was unable to reproduce the issue.
> As far as I can see there are several issues:
> 1. Collecting metrics on every single byte read is slow.
> 2. Having it enabled by default is not a good idea.
> 3. The comment "enable coarse-grained metrics by default" at 
> https://github.com/apache/lucene-solr/blob/branch_6x/solr/core/src/java/org/apache/solr/update/SolrIndexConfig.java#L104
>  implies that only coarse-grained metrics should be enabled by default, and 
> this contradicts with collecting metrics on every single byte read.



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

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

[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+155) - Build # 18978 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18978/
Java: 32bit/jdk-9-ea+155 -server -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.handler.admin.TestApiFramework.testFramework

Error Message:


Stack Trace:
java.lang.ExceptionInInitializerError
at 
__randomizedtesting.SeedInfo.seed([F84ABA70062487EE:EF3C705700F06BD3]:0)
at 
net.sf.cglib.core.KeyFactory$Generator.generateClass(KeyFactory.java:166)
at 
net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25)
at 
net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:216)
at net.sf.cglib.core.KeyFactory$Generator.create(KeyFactory.java:144)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:116)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:108)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:104)
at net.sf.cglib.proxy.Enhancer.(Enhancer.java:69)
at 
org.easymock.internal.ClassProxyFactory.createEnhancer(ClassProxyFactory.java:259)
at 
org.easymock.internal.ClassProxyFactory.createProxy(ClassProxyFactory.java:174)
at org.easymock.internal.MocksControl.createMock(MocksControl.java:60)
at org.easymock.EasyMock.createMock(EasyMock.java:104)
at 
org.apache.solr.handler.admin.TestCoreAdminApis.getCoreContainerMock(TestCoreAdminApis.java:83)
at 
org.apache.solr.handler.admin.TestApiFramework.testFramework(TestApiFramework.java:59)
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:543)
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 

[jira] [Commented] (SOLR-8845) SolrJ JDBC - Ensure that Spark works with SolrJ JDBC

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-8845:


[~joel.bernstein] - Just an FYI with the calcite piece merged I did a test of 
this against master. It still fails for the 1=0 part. 

{code}
java.lang.AssertionError: cannot translate call =(1, 0)
{code}

> SolrJ JDBC - Ensure that Spark works with SolrJ JDBC
> 
>
> Key: SOLR-8845
> URL: https://issues.apache.org/jira/browse/SOLR-8845
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: 6.0
>Reporter: Trey Cahill
>
> Ensure that Spark is able work with SolrJ JDBC.  
> Currently, in Spark 1.6 there are 2 known issues:
> 1. SparkSQL query's via a "select *" query
> 2. SparkSQL query's via a select query with a 1=0 where clause



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

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

[jira] [Comment Edited] (SOLR-10114) Reordered delete-by-query can delete or omit child documents

[Steve Rowe (JIRA)]

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

Steve Rowe edited comment on SOLR-10114 at 2/16/17 5:54 PM:


{{git bisect}} points the finger at the 
{{99188ae00c0c46d9af47b9773d492de40de4aa83}} commit under this issue for 
reproducing {{TestRecovery}} failures - all three succeed just before this 
commit and fail after it.  I had to remove the 
{{-Dtests.method=testCorruptLog}} cmdline param to get these to reproduce, so 
maybe there's some method order dependence here?:

[https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18975/]:

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestRecovery 
-Dtests.method=testCorruptLog -Dtests.seed=87E0BD7E2E527DCE 
-Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=sah-RU 
-Dtests.timezone=America/North_Dakota/Center -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] ERROR   1.29s J1 | TestRecovery.testCorruptLog <<<
   [junit4]> Throwable #1: java.lang.RuntimeException: mismatch: '3'!='0' @ 
response/numFound
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([87E0BD7E2E527DCE:753D09ADD46A2C12]:0)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:1006)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:953)
   [junit4]>at 
org.apache.solr.search.TestRecovery.testCorruptLog(TestRecovery.java:1274)
   [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:543)
[...]
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
{val_i=Lucene50(blocksize=128), _root_=PostingsFormat(name=Direct), 
id=Lucene50(blocksize=128)}, 
docValues:{_version_=DocValuesFormat(name=Lucene70), 
val_i_dvo=DocValuesFormat(name=Lucene70)}, maxPointsInLeafNode=1693, 
maxMBSortInHeap=6.736398983719205, sim=RandomSimilarity(queryNorm=true): {}, 
locale=sah-RU, timezone=America/North_Dakota/Center
   [junit4]   2> NOTE: Linux 4.4.0-53-generic i386/Oracle Corporation 9-ea 
(32-bit)/cpus=12,threads=1,free=183244888,total=536870912
{noformat}

[https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1136/]:

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestRecovery 
-Dtests.method=testCorruptLog -Dtests.seed=79A0B057C8C8D5DB -Dtests.slow=true 
-Dtests.locale=ar-OM -Dtests.timezone=Asia/Krasnoyarsk -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] ERROR   0.45s J1 | TestRecovery.testCorruptLog <<<
   [junit4]> Throwable #1: java.lang.RuntimeException: mismatch: '3'!='0' @ 
response/numFound
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([79A0B057C8C8D5DB:8B7D048432F08407]:0)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:1006)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:953)
   [junit4]>at 
org.apache.solr.search.TestRecovery.testCorruptLog(TestRecovery.java:1274)
[...]
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
{val_i=BlockTreeOrds(blocksize=128), 
_root_=PostingsFormat(name=LuceneFixedGap), id=BlockTreeOrds(blocksize=128)}, 
docValues:{_version_=DocValuesFormat(name=Memory), 
val_i_dvo=DocValuesFormat(name=Direct)}, maxPointsInLeafNode=586, 
maxMBSortInHeap=6.1661193810062755, sim=RandomSimilarity(queryNorm=false): {}, 
locale=ar-OM, timezone=Asia/Krasnoyarsk
   [junit4]   2> NOTE: SunOS 5.11 amd64/Oracle Corporation 1.8.0_121 
(64-bit)/cpus=3,threads=1,free=163066016,total=536870912
{noformat}

[https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/3836/]:

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestRecovery 
-Dtests.method=testCorruptLog -Dtests.seed=A33AFB76746001BE -Dtests.slow=true 
-Dtests.locale=ar -Dtests.timezone=Universal -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] ERROR   0.66s J1 | TestRecovery.testCorruptLog <<<
   [junit4]> Throwable #1: java.lang.RuntimeException: mismatch: '3'!='0' @ 
response/numFound
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([A33AFB76746001BE:51E74FA58E585062]:0)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:1006)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:953)
   [junit4]>at 
org.apache.solr.search.TestRecovery.testCorruptLog(TestRecovery.java:1274)
[...]
   [junit4]   2> NOTE: test params are: 

[jira] [Resolved] (SOLR-10150) Solr 6.4 up to 10x slower than 6.3

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-10150.
---
Resolution: Duplicate

> Solr 6.4 up to 10x slower than 6.3
> --
>
> Key: SOLR-10150
> URL: https://issues.apache.org/jira/browse/SOLR-10150
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Fabrizio Fortino
>Priority: Critical
>  Labels: performance
> Attachments: Screen Shot 2017-02-16 at 17.31.02.png
>
>
> We noticed a considerable performance degradation (5x to 10x) using Solr 6.4 
> and huge increase of CPU utilization. Our use case is pretty simple: we have 
> a single Solr Core with around 600K small size documents. We just do lookups 
> by key (no full text searches) and use faceting capabilities.
> Using the Solr Admin Thread Dump utilities we noticed a lot of threads using 
> considerable cpuTime / userTime on codehale metrics (snapshot attached). The 
> metrics part has been drastically changed in 6.4 
> (https://issues.apache.org/jira/browse/SOLR-4735). Rolling back to Solr 6.3 
> has solved our performance problems.
> Is there any way to disable these metrics in version 6.4 ?
> Thanks!



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

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

[jira] [Commented] (SOLR-10114) Reordered delete-by-query can delete or omit child documents

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10114:
---

{{git bisect}} points the finger at the 
{{99188ae00c0c46d9af47b9773d492de40de4aa83}} commit under this issue for a 
reproducing {{TestRecovery}} failures - all three succeed just before this 
commit and fail after it.  I had to remove the 
{{-Dtests.method=testCorruptLog}} cmdline param to get these to reproduce, so 
maybe there's some method order dependence here?:

[https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18975/]:

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestRecovery 
-Dtests.method=testCorruptLog -Dtests.seed=87E0BD7E2E527DCE 
-Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=sah-RU 
-Dtests.timezone=America/North_Dakota/Center -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] ERROR   1.29s J1 | TestRecovery.testCorruptLog <<<
   [junit4]> Throwable #1: java.lang.RuntimeException: mismatch: '3'!='0' @ 
response/numFound
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([87E0BD7E2E527DCE:753D09ADD46A2C12]:0)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:1006)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:953)
   [junit4]>at 
org.apache.solr.search.TestRecovery.testCorruptLog(TestRecovery.java:1274)
   [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:543)
[...]
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
{val_i=Lucene50(blocksize=128), _root_=PostingsFormat(name=Direct), 
id=Lucene50(blocksize=128)}, 
docValues:{_version_=DocValuesFormat(name=Lucene70), 
val_i_dvo=DocValuesFormat(name=Lucene70)}, maxPointsInLeafNode=1693, 
maxMBSortInHeap=6.736398983719205, sim=RandomSimilarity(queryNorm=true): {}, 
locale=sah-RU, timezone=America/North_Dakota/Center
   [junit4]   2> NOTE: Linux 4.4.0-53-generic i386/Oracle Corporation 9-ea 
(32-bit)/cpus=12,threads=1,free=183244888,total=536870912
{noformat}

[https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1136/]:

{noformat]
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestRecovery 
-Dtests.method=testCorruptLog -Dtests.seed=79A0B057C8C8D5DB -Dtests.slow=true 
-Dtests.locale=ar-OM -Dtests.timezone=Asia/Krasnoyarsk -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] ERROR   0.45s J1 | TestRecovery.testCorruptLog <<<
   [junit4]> Throwable #1: java.lang.RuntimeException: mismatch: '3'!='0' @ 
response/numFound
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([79A0B057C8C8D5DB:8B7D048432F08407]:0)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:1006)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:953)
   [junit4]>at 
org.apache.solr.search.TestRecovery.testCorruptLog(TestRecovery.java:1274)
[...]
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
{val_i=BlockTreeOrds(blocksize=128), 
_root_=PostingsFormat(name=LuceneFixedGap), id=BlockTreeOrds(blocksize=128)}, 
docValues:{_version_=DocValuesFormat(name=Memory), 
val_i_dvo=DocValuesFormat(name=Direct)}, maxPointsInLeafNode=586, 
maxMBSortInHeap=6.1661193810062755, sim=RandomSimilarity(queryNorm=false): {}, 
locale=ar-OM, timezone=Asia/Krasnoyarsk
   [junit4]   2> NOTE: SunOS 5.11 amd64/Oracle Corporation 1.8.0_121 
(64-bit)/cpus=3,threads=1,free=163066016,total=536870912
{noformat}

[https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/3836/]:

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestRecovery 
-Dtests.method=testCorruptLog -Dtests.seed=A33AFB76746001BE -Dtests.slow=true 
-Dtests.locale=ar -Dtests.timezone=Universal -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] ERROR   0.66s J1 | TestRecovery.testCorruptLog <<<
   [junit4]> Throwable #1: java.lang.RuntimeException: mismatch: '3'!='0' @ 
response/numFound
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([A33AFB76746001BE:51E74FA58E585062]:0)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:1006)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:953)
   [junit4]>at 
org.apache.solr.search.TestRecovery.testCorruptLog(TestRecovery.java:1274)
[...]
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 

[jira] [Comment Edited] (SOLR-10114) Reordered delete-by-query can delete or omit child documents

[Steve Rowe (JIRA)]

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

Steve Rowe edited comment on SOLR-10114 at 2/16/17 5:53 PM:


{{git bisect}} points the finger at the 
{{99188ae00c0c46d9af47b9773d492de40de4aa83}} commit under this issue for 
reproducing {{TestRecovery}} failures - all three succeed just before this 
commit and fail after it.  I had to remove the 
{{-Dtests.method=testCorruptLog}} cmdline param to get these to reproduce, so 
maybe there's some method order dependence here?:

[https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18975/]:

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestRecovery 
-Dtests.method=testCorruptLog -Dtests.seed=87E0BD7E2E527DCE 
-Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=sah-RU 
-Dtests.timezone=America/North_Dakota/Center -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] ERROR   1.29s J1 | TestRecovery.testCorruptLog <<<
   [junit4]> Throwable #1: java.lang.RuntimeException: mismatch: '3'!='0' @ 
response/numFound
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([87E0BD7E2E527DCE:753D09ADD46A2C12]:0)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:1006)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:953)
   [junit4]>at 
org.apache.solr.search.TestRecovery.testCorruptLog(TestRecovery.java:1274)
   [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:543)
[...]
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
{val_i=Lucene50(blocksize=128), _root_=PostingsFormat(name=Direct), 
id=Lucene50(blocksize=128)}, 
docValues:{_version_=DocValuesFormat(name=Lucene70), 
val_i_dvo=DocValuesFormat(name=Lucene70)}, maxPointsInLeafNode=1693, 
maxMBSortInHeap=6.736398983719205, sim=RandomSimilarity(queryNorm=true): {}, 
locale=sah-RU, timezone=America/North_Dakota/Center
   [junit4]   2> NOTE: Linux 4.4.0-53-generic i386/Oracle Corporation 9-ea 
(32-bit)/cpus=12,threads=1,free=183244888,total=536870912
{noformat}

[https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1136/]:

{noformat]
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestRecovery 
-Dtests.method=testCorruptLog -Dtests.seed=79A0B057C8C8D5DB -Dtests.slow=true 
-Dtests.locale=ar-OM -Dtests.timezone=Asia/Krasnoyarsk -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] ERROR   0.45s J1 | TestRecovery.testCorruptLog <<<
   [junit4]> Throwable #1: java.lang.RuntimeException: mismatch: '3'!='0' @ 
response/numFound
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([79A0B057C8C8D5DB:8B7D048432F08407]:0)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:1006)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:953)
   [junit4]>at 
org.apache.solr.search.TestRecovery.testCorruptLog(TestRecovery.java:1274)
[...]
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
{val_i=BlockTreeOrds(blocksize=128), 
_root_=PostingsFormat(name=LuceneFixedGap), id=BlockTreeOrds(blocksize=128)}, 
docValues:{_version_=DocValuesFormat(name=Memory), 
val_i_dvo=DocValuesFormat(name=Direct)}, maxPointsInLeafNode=586, 
maxMBSortInHeap=6.1661193810062755, sim=RandomSimilarity(queryNorm=false): {}, 
locale=ar-OM, timezone=Asia/Krasnoyarsk
   [junit4]   2> NOTE: SunOS 5.11 amd64/Oracle Corporation 1.8.0_121 
(64-bit)/cpus=3,threads=1,free=163066016,total=536870912
{noformat}

[https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/3836/]:

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestRecovery 
-Dtests.method=testCorruptLog -Dtests.seed=A33AFB76746001BE -Dtests.slow=true 
-Dtests.locale=ar -Dtests.timezone=Universal -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] ERROR   0.66s J1 | TestRecovery.testCorruptLog <<<
   [junit4]> Throwable #1: java.lang.RuntimeException: mismatch: '3'!='0' @ 
response/numFound
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([A33AFB76746001BE:51E74FA58E585062]:0)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:1006)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:953)
   [junit4]>at 
org.apache.solr.search.TestRecovery.testCorruptLog(TestRecovery.java:1274)
[...]
   [junit4]   2> NOTE: test params are: 

[jira] [Commented] (SOLR-10150) Solr 6.4 up to 10x slower than 6.3

[Yago Riveiro (JIRA)]

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

Yago Riveiro commented on SOLR-10150:
-

I think this is a duplicate of SOLR-10130

> Solr 6.4 up to 10x slower than 6.3
> --
>
> Key: SOLR-10150
> URL: https://issues.apache.org/jira/browse/SOLR-10150
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Fabrizio Fortino
>Priority: Critical
>  Labels: performance
> Attachments: Screen Shot 2017-02-16 at 17.31.02.png
>
>
> We noticed a considerable performance degradation (5x to 10x) using Solr 6.4 
> and huge increase of CPU utilization. Our use case is pretty simple: we have 
> a single Solr Core with around 600K small size documents. We just do lookups 
> by key (no full text searches) and use faceting capabilities.
> Using the Solr Admin Thread Dump utilities we noticed a lot of threads using 
> considerable cpuTime / userTime on codehale metrics (snapshot attached). The 
> metrics part has been drastically changed in 6.4 
> (https://issues.apache.org/jira/browse/SOLR-4735). Rolling back to Solr 6.3 
> has solved our performance problems.
> Is there any way to disable these metrics in version 6.4 ?
> Thanks!



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

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

[jira] [Updated] (SOLR-10150) Solr 6.4 up to 10x slower than 6.3

[Fabrizio Fortino (JIRA)]

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

Fabrizio Fortino updated SOLR-10150:

Priority: Critical  (was: Major)

> Solr 6.4 up to 10x slower than 6.3
> --
>
> Key: SOLR-10150
> URL: https://issues.apache.org/jira/browse/SOLR-10150
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Fabrizio Fortino
>Priority: Critical
>  Labels: performance
> Attachments: Screen Shot 2017-02-16 at 17.31.02.png
>
>
> We noticed a considerable performance degradation (5x to 10x) using Solr 6.4 
> and huge increase of CPU utilization. Our use case is pretty simple: we have 
> a single Solr Core with around 600K small size documents. We just do lookups 
> by key (no full text searches) and use faceting capabilities.
> Using the Solr Admin Thread Dump utilities we noticed a lot of threads using 
> considerable cpuTime / userTime on codehale metrics (snapshot attached). The 
> metrics part has been drastically changed in 6.4 
> (https://issues.apache.org/jira/browse/SOLR-4735). Rolling back to Solr 6.3 
> has solved our performance problems.
> Is there any way to disable these metrics in version 6.4 ?
> Thanks!



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

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

[jira] [Commented] (SOLR-10114) Reordered delete-by-query can delete or omit child documents

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10114:


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

SOLR-10114: test cleanup


> Reordered delete-by-query can delete or omit child documents
> 
>
> Key: SOLR-10114
> URL: https://issues.apache.org/jira/browse/SOLR-10114
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 4.5
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: master (7.0)
>
> Attachments: SOLR-10114-2.patch, SOLR-10114-2.patch, 
> SOLR-10114.patch, SOLR-10114.patch, SOLR-10114-test-cleanup.patch, 
> SOLR-10114-validation.patch
>
>
> It looks like when a block of documents is indexed, child documents get no 
> \_version\_ field.  This means (among other potential issues) that a 
> delete-by-query that is reordered will cause matching child documents to be 
> deleted.  DBQ normally prevents deleting newer docs by including a 
> restriction on \_version\_, which doesn't work for anything lacking that 
> field.  Re-ordered delete-by-term of any child docs would also be affected 
> (although it should be a much rarer issue.)
> The leading candidate for a fix is to use the exact same \_version\_ for all 
> child docs.



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

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

[jira] [Updated] (SOLR-10150) Solr 6.4 up to 10x slower than 6.3

[Fabrizio Fortino (JIRA)]

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

Fabrizio Fortino updated SOLR-10150:

Attachment: Screen Shot 2017-02-16 at 17.31.02.png

> Solr 6.4 up to 10x slower than 6.3
> --
>
> Key: SOLR-10150
> URL: https://issues.apache.org/jira/browse/SOLR-10150
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Fabrizio Fortino
>  Labels: performance
> Attachments: Screen Shot 2017-02-16 at 17.31.02.png
>
>
> We noticed a considerable performance degradation (5x to 10x) using Solr 6.4 
> and huge increase of CPU utilization. Our use case is pretty simple: we have 
> a single Solr Core with around 600K small size documents. We just do lookups 
> by key (no full text searches) and use faceting capabilities.
> Using the Solr Admin Thread Dump utilities we noticed a lot of threads using 
> considerable cpuTime / userTime on codehale metrics (snapshot attached). The 
> metrics part has been drastically changed in 6.4 
> (https://issues.apache.org/jira/browse/SOLR-4735). Rolling back to Solr 6.3 
> has solved our performance problems.
> Is there any way to disable these metrics in version 6.4 ?
> Thanks!



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

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

[jira] [Created] (SOLR-10150) Solr 6.4 up to 10x slower than 6.3

[Fabrizio Fortino (JIRA)]

Fabrizio Fortino created SOLR-10150:
---

 Summary: Solr 6.4 up to 10x slower than 6.3
 Key: SOLR-10150
 URL: https://issues.apache.org/jira/browse/SOLR-10150
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Fabrizio Fortino


We noticed a considerable performance degradation (5x to 10x) using Solr 6.4 
and huge increase of CPU utilization. Our use case is pretty simple: we have a 
single Solr Core with around 600K small size documents. We just do lookups by 
key (no full text searches) and use faceting capabilities.

Using the Solr Admin Thread Dump utilities we noticed a lot of threads using 
considerable cpuTime / userTime on codehale metrics (snapshot attached). The 
metrics part has been drastically changed in 6.4 
(https://issues.apache.org/jira/browse/SOLR-4735). Rolling back to Solr 6.3 has 
solved our performance problems.

Is there any way to disable these metrics in version 6.4 ?

Thanks!





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

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

[jira] [Commented] (SOLR-10134) EmbeddedSolrServer does not support SchemaAPI

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-10134:
-

[~alero], can you also contribute a test? 

> EmbeddedSolrServer does not support SchemaAPI
> -
>
> Key: SOLR-10134
> URL: https://issues.apache.org/jira/browse/SOLR-10134
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Server, SolrJ
>Affects Versions: 6.4.1
>Reporter: Robert Alexandersson
>  Labels: test-driven
> Attachments: SOLR-10134.patch
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> The EmbeddedSolrServer server does not support calls to the POST methods of 
> SchemaAPI using SolRJ api. The reason is that the httpMethod param is never 
> set by the EmbeddedSolrServer#request(SolrRequest, String) and this is later 
> required by the SchemaHandler class that actually performs the call at 
> SchemaHandler#handleRequestBody(SolrQueryRequest, SolrQueryResponse). 
> Proposal is to enhance the EmbeddedSolrServer to forward the httpMethod at 
> aprox row 174 with the following: "req.getContext().put("httpMethod", 
> request.getMethod().name());". This change requires the Factory methods of 
> SolrJ to add the intended method to be used example : new 
> SchemaRequest.AddField() should append the POST method similar to how the 
> SchemaRequest.Field appends the GET method.
> I have written a separate EmbeddedSolrServer that replaces the one in SolR. 
> It works for now and fields can be created on the fly using the SchemaAPI of 
> the solrj client, but would like to be able to remove this workaround.



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

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

[jira] [Commented] (LUCENE-6819) Deprecate index-time boosts?

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-6819:
--

Index time boosts are valuable.  I've found that tuning index time boosts is 
the easiest way to boost documents that has the most predictable effect, 
relative to query time boosts.  Of course it's inflexible but it's a trade-off.

> Deprecate index-time boosts?
> 
>
> Key: LUCENE-6819
> URL: https://issues.apache.org/jira/browse/LUCENE-6819
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
>Priority: Minor
>
> Follow-up of this comment: 
> https://issues.apache.org/jira/browse/LUCENE-6818?focusedCommentId=14934801=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14934801
> Index-time boosts are a very expert feature whose behaviour is tight to the 
> Similarity impl. Additionally users have often be confused by the poor 
> precision due to the fact that we encode values on a single byte. But now we 
> have doc values that allow you to encode any values the way you want with as 
> much precision as you need so maybe we should deprecate index-time boosts and 
> recommend to encode index-time scoring factors into doc values fields instead.



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

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

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

[Policeman Jenkins Server]

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

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

Error Message:
timeout waiting to see all nodes active

Stack Trace:
java.lang.AssertionError: timeout waiting to see all nodes active
at 
__randomizedtesting.SeedInfo.seed([95AAC0766C0D9AED:1DFEFFACC2F1F715]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.waitTillNodesActive(PeerSyncReplicationTest.java:326)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.bringUpDeadNodeAndEnsureNoReplication(PeerSyncReplicationTest.java:277)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.forceNodeFailureAndDoPeerSync(PeerSyncReplicationTest.java:259)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:138)
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 

[jira] [Commented] (SOLR-10032) Create report to assess Solr test quality at a commit point.

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-10032:
---

Mark:

First of all, really appreciate the work you're doing here. I hope to address 
some of the tests I'm familiar with, honest. Real Soon Now.

Would it be convenient for you to publicly share the _folder_ these reports go 
into so I could bookmark that?

Erick

> Create report to assess Solr test quality at a commit point.
> 
>
> Key: SOLR-10032
> URL: https://issues.apache.org/jira/browse/SOLR-10032
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: Lucene-Solr Master Test Beast Results 
> 01-24-2017-9899cbd031dc3fc37a384b1f9e2b379e90a9a3a6 Level Medium- Running 30 
> iterations, 12 at a time .pdf, Lucene-Solr Master Test Beasults 
> 02-01-2017-bbc455de195c83d9f807980b510fa46018f33b1b Level Medium- Running 30 
> iterations, 10 at a time.pdf, Lucene-Solr Master Test Beasults 
> 02-08-2017-6696eafaae18948c2891ce758c7a2ec09873dab8 Level Medium+- Running 30 
> iterations, 10 at a time, 8 cores.pdf, Lucene-Solr Master Test Beasults 
> 02-14-2017- Level Medium+-a1f114f70f3800292c25be08213edf39b3e37f6a Running 30 
> iterations, 10 at a time, 8 cores.pdf
>
>
> We have many Jenkins instances blasting tests, some official, some policeman, 
> I and others have or had their own, and the email trail proves the power of 
> the Jenkins cluster to find test fails.
> However, I still have a very hard time with some basic questions:
> what tests are flakey right now? which test fails actually affect devs most? 
> did I break it? was that test already flakey? is that test still flakey? what 
> are our worst tests right now? is that test getting better or worse?
> We really need a way to see exactly what tests are the problem, not because 
> of OS or environmental issues, but more basic test quality issues. Which 
> tests are flakey and how flakey are they at any point in time.
> Reports:
> 01/24/2017 - 
> https://docs.google.com/spreadsheets/d/1JySta2j2s7A_p16wA1UO-l6c4GsUHBIb4FONS2EzW9k/edit?usp=sharing
> 02/01/2017 - 
> https://docs.google.com/spreadsheets/d/1FndoyHmihaOVL2o_Zns5alpNdAJlNsEwQVoJ4XDWj3c/edit?usp=sharing
> 02/08/2017 - 
> https://docs.google.com/spreadsheets/d/1N6RxH4Edd7ldRIaVfin0si-uSLGyowQi8-7mcux27S0/edit?usp=sharing
> 02/14/2017 - 
> https://docs.google.com/spreadsheets/d/1eZ9_ds_0XyqsKKp8xkmESrcMZRP85jTxSKkNwgtcUn0/edit?usp=sharing



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

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

Re: Solr JIRA: Merge components "web gui" and "UI"

[Alexandre Rafalovitch]

I thought I had a memory of being able to add a component before I got
committer access. But perhaps it would have been rejected when I
clicked submit. Or my memory is faulty.

Either way, that was the reason I thought maybe some permission got
perhaps assigned to 'Registered' users. I am happy to be wrong, it
will make things easier.

Regards,
   Alex.

http://www.solr-start.com/ - Resources for Solr users, new and experienced


On 16 February 2017 at 11:23, Cassandra Targett  wrote:
> On Thu, Feb 16, 2017 at 10:17 AM, Alexandre Rafalovitch
>  wrote:
>> Are we SURE that the role has not been relaxed by INFRA? Because if it
>> is just us, we could do a one-time cleanup and try to be neat.
>
> Relaxed in what way? That all users have project admin-level
> permissions? That seems unlikely.
>
> It's a default setting in JIRA that can't be changed. If you read the
> comments in that issue Jan pointed to, the situation becomes clear: If
> you have project admin permissions, you can edit components (by
> default, and unchangeable) because that's part of administering a
> project, and thus you have permission to create them on the fly in the
> UI (also by default, and unchangeable).
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

[jira] [Commented] (SOLR-10079) TestInPlaceUpdatesDistrib failure

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-10079:


{noformat}
   [junit4] FAILURE 86.8s | TestInPlaceUpdatesDistrib.test <<<
   [junit4]> Throwable #1: java.lang.AssertionError: Client: 
http://127.0.0.1:37761/collection1
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([E31EFF2ED958DB75:6B4AC0F477A4B68D]:0)
   [junit4]>at 
org.apache.solr.update.TestInPlaceUpdatesDistrib.reorderedDBQsWithInPlaceUpdatesShouldNotThrowReplicaInLIRTest(TestInPlaceUpdatesDistrib.java:726)
   [junit4]>at 
org.apache.solr.update.TestInPlaceUpdatesDistrib.test(TestInPlaceUpdatesDistrib.java:146)
   [junit4]>at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
   [junit4]>at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
   [junit4]>at java.lang.Thread.run(Thread.java:745)
{noformat}

> TestInPlaceUpdatesDistrib failure
> -
>
> Key: SOLR-10079
> URL: https://issues.apache.org/jira/browse/SOLR-10079
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Ishan Chattopadhyaya
> Attachments: SOLR-10079.patch, stdout
>
>
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18881/], 
> reproduces for me:
> {noformat}
> Checking out Revision d8d61ff61d1d798f5e3853ef66bc485d0d403f18 
> (refs/remotes/origin/master)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestInPlaceUpdatesDistrib -Dtests.method=test 
> -Dtests.seed=E1BB56269B8215B0 -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=sr-Latn-RS -Dtests.timezone=America/Grand_Turk 
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 77.7s J2 | TestInPlaceUpdatesDistrib.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Earlier: [79, 79, 
> 79], now: [78, 78, 78]
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([E1BB56269B8215B0:69EF69FC357E7848]:0)
>[junit4]>  at 
> org.apache.solr.update.TestInPlaceUpdatesDistrib.ensureRtgWorksWithPartialUpdatesTest(TestInPlaceUpdatesDistrib.java:425)
>[junit4]>  at 
> org.apache.solr.update.TestInPlaceUpdatesDistrib.test(TestInPlaceUpdatesDistrib.java:142)
>[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:543)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
>[junit4]>  at java.base/java.lang.Thread.run(Thread.java:844)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
> {id_i=PostingsFormat(name=LuceneFixedGap), title_s=FSTOrd50, 
> id=PostingsFormat(name=Asserting), 
> id_field_copy_that_does_not_support_in_place_update_s=FSTOrd50}, 
> docValues:{inplace_updatable_float=DocValuesFormat(name=Asserting), 
> id_i=DocValuesFormat(name=Direct), _version_=DocValuesFormat(name=Asserting), 
> title_s=DocValuesFormat(name=Lucene70), id=DocValuesFormat(name=Lucene70), 
> id_field_copy_that_does_not_support_in_place_update_s=DocValuesFormat(name=Lucene70),
>  inplace_updatable_int_with_default=DocValuesFormat(name=Asserting), 
> inplace_updatable_int=DocValuesFormat(name=Direct), 
> inplace_updatable_float_with_default=DocValuesFormat(name=Direct)}, 
> maxPointsInLeafNode=1342, maxMBSortInHeap=6.368734895089348, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=sr-Latn-RS, 
> timezone=America/Grand_Turk
>[junit4]   2> NOTE: Linux 4.4.0-53-generic i386/Oracle Corporation 9-ea 
> (32-bit)/cpus=12,threads=1,free=107734480,total=518979584
> {noformat}



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

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

[jira] [Updated] (SOLR-10079) TestInPlaceUpdatesDistrib failure

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-10079:
---
Attachment: stdout

> TestInPlaceUpdatesDistrib failure
> -
>
> Key: SOLR-10079
> URL: https://issues.apache.org/jira/browse/SOLR-10079
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Ishan Chattopadhyaya
> Attachments: SOLR-10079.patch, stdout
>
>
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18881/], 
> reproduces for me:
> {noformat}
> Checking out Revision d8d61ff61d1d798f5e3853ef66bc485d0d403f18 
> (refs/remotes/origin/master)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestInPlaceUpdatesDistrib -Dtests.method=test 
> -Dtests.seed=E1BB56269B8215B0 -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=sr-Latn-RS -Dtests.timezone=America/Grand_Turk 
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 77.7s J2 | TestInPlaceUpdatesDistrib.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Earlier: [79, 79, 
> 79], now: [78, 78, 78]
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([E1BB56269B8215B0:69EF69FC357E7848]:0)
>[junit4]>  at 
> org.apache.solr.update.TestInPlaceUpdatesDistrib.ensureRtgWorksWithPartialUpdatesTest(TestInPlaceUpdatesDistrib.java:425)
>[junit4]>  at 
> org.apache.solr.update.TestInPlaceUpdatesDistrib.test(TestInPlaceUpdatesDistrib.java:142)
>[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:543)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
>[junit4]>  at java.base/java.lang.Thread.run(Thread.java:844)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
> {id_i=PostingsFormat(name=LuceneFixedGap), title_s=FSTOrd50, 
> id=PostingsFormat(name=Asserting), 
> id_field_copy_that_does_not_support_in_place_update_s=FSTOrd50}, 
> docValues:{inplace_updatable_float=DocValuesFormat(name=Asserting), 
> id_i=DocValuesFormat(name=Direct), _version_=DocValuesFormat(name=Asserting), 
> title_s=DocValuesFormat(name=Lucene70), id=DocValuesFormat(name=Lucene70), 
> id_field_copy_that_does_not_support_in_place_update_s=DocValuesFormat(name=Lucene70),
>  inplace_updatable_int_with_default=DocValuesFormat(name=Asserting), 
> inplace_updatable_int=DocValuesFormat(name=Direct), 
> inplace_updatable_float_with_default=DocValuesFormat(name=Direct)}, 
> maxPointsInLeafNode=1342, maxMBSortInHeap=6.368734895089348, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=sr-Latn-RS, 
> timezone=America/Grand_Turk
>[junit4]   2> NOTE: Linux 4.4.0-53-generic i386/Oracle Corporation 9-ea 
> (32-bit)/cpus=12,threads=1,free=107734480,total=518979584
> {noformat}



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

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

[jira] [Commented] (SOLR-10079) TestInPlaceUpdatesDistrib failure

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-10079:


This test is flagged as the newest flakey test we have. Not sure if it's 
related to this issue or a new one? I'll attach a fail log.

> TestInPlaceUpdatesDistrib failure
> -
>
> Key: SOLR-10079
> URL: https://issues.apache.org/jira/browse/SOLR-10079
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Ishan Chattopadhyaya
> Attachments: SOLR-10079.patch, stdout
>
>
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18881/], 
> reproduces for me:
> {noformat}
> Checking out Revision d8d61ff61d1d798f5e3853ef66bc485d0d403f18 
> (refs/remotes/origin/master)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestInPlaceUpdatesDistrib -Dtests.method=test 
> -Dtests.seed=E1BB56269B8215B0 -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=sr-Latn-RS -Dtests.timezone=America/Grand_Turk 
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 77.7s J2 | TestInPlaceUpdatesDistrib.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Earlier: [79, 79, 
> 79], now: [78, 78, 78]
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([E1BB56269B8215B0:69EF69FC357E7848]:0)
>[junit4]>  at 
> org.apache.solr.update.TestInPlaceUpdatesDistrib.ensureRtgWorksWithPartialUpdatesTest(TestInPlaceUpdatesDistrib.java:425)
>[junit4]>  at 
> org.apache.solr.update.TestInPlaceUpdatesDistrib.test(TestInPlaceUpdatesDistrib.java:142)
>[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:543)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
>[junit4]>  at java.base/java.lang.Thread.run(Thread.java:844)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
> {id_i=PostingsFormat(name=LuceneFixedGap), title_s=FSTOrd50, 
> id=PostingsFormat(name=Asserting), 
> id_field_copy_that_does_not_support_in_place_update_s=FSTOrd50}, 
> docValues:{inplace_updatable_float=DocValuesFormat(name=Asserting), 
> id_i=DocValuesFormat(name=Direct), _version_=DocValuesFormat(name=Asserting), 
> title_s=DocValuesFormat(name=Lucene70), id=DocValuesFormat(name=Lucene70), 
> id_field_copy_that_does_not_support_in_place_update_s=DocValuesFormat(name=Lucene70),
>  inplace_updatable_int_with_default=DocValuesFormat(name=Asserting), 
> inplace_updatable_int=DocValuesFormat(name=Direct), 
> inplace_updatable_float_with_default=DocValuesFormat(name=Direct)}, 
> maxPointsInLeafNode=1342, maxMBSortInHeap=6.368734895089348, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=sr-Latn-RS, 
> timezone=America/Grand_Turk
>[junit4]   2> NOTE: Linux 4.4.0-53-generic i386/Oracle Corporation 9-ea 
> (32-bit)/cpus=12,threads=1,free=107734480,total=518979584
> {noformat}



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

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

Re: Solr JIRA: Merge components "web gui" and "UI"

[Cassandra Targett]

On Thu, Feb 16, 2017 at 10:17 AM, Alexandre Rafalovitch
 wrote:
> Are we SURE that the role has not been relaxed by INFRA? Because if it
> is just us, we could do a one-time cleanup and try to be neat.

Relaxed in what way? That all users have project admin-level
permissions? That seems unlikely.

It's a default setting in JIRA that can't be changed. If you read the
comments in that issue Jan pointed to, the situation becomes clear: If
you have project admin permissions, you can edit components (by
default, and unchangeable) because that's part of administering a
project, and thus you have permission to create them on the fly in the
UI (also by default, and unchangeable).

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

[jira] [Resolved] (SOLR-9890) factor out ShardResultTransformerUtils.[un]marshSortValue methods

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved SOLR-9890.
---
   Resolution: Fixed
Fix Version/s: master (7.0)
   6.x

> factor out ShardResultTransformerUtils.[un]marshSortValue methods
> -
>
> Key: SOLR-9890
> URL: https://issues.apache.org/jira/browse/SOLR-9890
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.x, master (7.0)
>
> Attachments: SOLR-9890.patch
>
>




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

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

[jira] [Resolved] (LUCENE-7693) revisit "org.apache." logic in GetMavenDependenciesTask.java

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved LUCENE-7693.
-
   Resolution: Fixed
Fix Version/s: master (7.0)
   6.x

Thanks for your input Steve.

> revisit "org.apache." logic in GetMavenDependenciesTask.java
> 
>
> Key: LUCENE-7693
> URL: https://issues.apache.org/jira/browse/LUCENE-7693
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.x, master (7.0)
>
> Attachments: LUCENE-7693.patch, LUCENE-7693-step1.patch, 
> LUCENE-7693-step2.patch
>
>
> Objective:
> * replace the {{... "org.apache." + ...}} logic in 
> GetMavenDependenciesTask.java at 
> [L399|https://github.com/apache/lucene-solr/blob/master/lucene/tools/src/java/org/apache/lucene/dependencies/GetMavenDependenciesTask.java#L399]
>  and 
> [L584|https://github.com/apache/lucene-solr/blob/master/lucene/tools/src/java/org/apache/lucene/dependencies/GetMavenDependenciesTask.java#L584]
> Motivation:
> * support for custom {{solr/contrib/...-myteam}} modules where the custom 
> modules have dependencies between them and the package structure is 
> _com.mycompany.myteam_ rather than _org.apache.solr_
> Approach:
> * step 1:
> ** in GetMavenDependenciesTask.java build a map out of all the ivy.xml files' 
> info elements e.g.
> {code}
> 
>   
> 
> {code}
> ** temporarily instrument GetMavenDependenciesTask.java to help determine how 
> the info element mappings differ from the current in-code logic
> * step 2:
> ** adjust selected ivy.xml files to minimise differences
> * step 3:
> ** switch over to 'new way' logic where this matches current in-code logic
> ** remove the temporary instrumentation



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

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

[jira] [Updated] (SOLR-10032) Create report to assess Solr test quality at a commit point.

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-10032:
---
Description: 
We have many Jenkins instances blasting tests, some official, some policeman, I 
and others have or had their own, and the email trail proves the power of the 
Jenkins cluster to find test fails.

However, I still have a very hard time with some basic questions:

what tests are flakey right now? which test fails actually affect devs most? 
did I break it? was that test already flakey? is that test still flakey? what 
are our worst tests right now? is that test getting better or worse?

We really need a way to see exactly what tests are the problem, not because of 
OS or environmental issues, but more basic test quality issues. Which tests are 
flakey and how flakey are they at any point in time.


Reports:
01/24/2017 - 
https://docs.google.com/spreadsheets/d/1JySta2j2s7A_p16wA1UO-l6c4GsUHBIb4FONS2EzW9k/edit?usp=sharing
02/01/2017 - 
https://docs.google.com/spreadsheets/d/1FndoyHmihaOVL2o_Zns5alpNdAJlNsEwQVoJ4XDWj3c/edit?usp=sharing
02/08/2017 - 
https://docs.google.com/spreadsheets/d/1N6RxH4Edd7ldRIaVfin0si-uSLGyowQi8-7mcux27S0/edit?usp=sharing
02/14/2017 - 
https://docs.google.com/spreadsheets/d/1eZ9_ds_0XyqsKKp8xkmESrcMZRP85jTxSKkNwgtcUn0/edit?usp=sharing


  was:
We have many Jenkins instances blasting tests, some official, some policeman, I 
and others have or had their own, and the email trail proves the power of the 
Jenkins cluster to find test fails.

However, I still have a very hard time with some basic questions:

what tests are flakey right now? which test fails actually affect devs most? 
did I break it? was that test already flakey? is that test still flakey? what 
are our worst tests right now? is that test getting better or worse?

We really need a way to see exactly what tests are the problem, not because of 
OS or environmental issues, but more basic test quality issues. Which tests are 
flakey and how flakey are they at any point in time.


Reports:
01/24/2017 - 
https://docs.google.com/spreadsheets/d/1JySta2j2s7A_p16wA1UO-l6c4GsUHBIb4FONS2EzW9k/edit?usp=sharing
02/01/2017 - 
https://docs.google.com/spreadsheets/d/1FndoyHmihaOVL2o_Zns5alpNdAJlNsEwQVoJ4XDWj3c/edit?usp=sharing
02/08/2017 - 
https://docs.google.com/spreadsheets/d/1N6RxH4Edd7ldRIaVfin0si-uSLGyowQi8-7mcux27S0/edit?usp=sharing




> Create report to assess Solr test quality at a commit point.
> 
>
> Key: SOLR-10032
> URL: https://issues.apache.org/jira/browse/SOLR-10032
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: Lucene-Solr Master Test Beast Results 
> 01-24-2017-9899cbd031dc3fc37a384b1f9e2b379e90a9a3a6 Level Medium- Running 30 
> iterations, 12 at a time .pdf, Lucene-Solr Master Test Beasults 
> 02-01-2017-bbc455de195c83d9f807980b510fa46018f33b1b Level Medium- Running 30 
> iterations, 10 at a time.pdf, Lucene-Solr Master Test Beasults 
> 02-08-2017-6696eafaae18948c2891ce758c7a2ec09873dab8 Level Medium+- Running 30 
> iterations, 10 at a time, 8 cores.pdf, Lucene-Solr Master Test Beasults 
> 02-14-2017- Level Medium+-a1f114f70f3800292c25be08213edf39b3e37f6a Running 30 
> iterations, 10 at a time, 8 cores.pdf
>
>
> We have many Jenkins instances blasting tests, some official, some policeman, 
> I and others have or had their own, and the email trail proves the power of 
> the Jenkins cluster to find test fails.
> However, I still have a very hard time with some basic questions:
> what tests are flakey right now? which test fails actually affect devs most? 
> did I break it? was that test already flakey? is that test still flakey? what 
> are our worst tests right now? is that test getting better or worse?
> We really need a way to see exactly what tests are the problem, not because 
> of OS or environmental issues, but more basic test quality issues. Which 
> tests are flakey and how flakey are they at any point in time.
> Reports:
> 01/24/2017 - 
> https://docs.google.com/spreadsheets/d/1JySta2j2s7A_p16wA1UO-l6c4GsUHBIb4FONS2EzW9k/edit?usp=sharing
> 02/01/2017 - 
> https://docs.google.com/spreadsheets/d/1FndoyHmihaOVL2o_Zns5alpNdAJlNsEwQVoJ4XDWj3c/edit?usp=sharing
> 02/08/2017 - 
> https://docs.google.com/spreadsheets/d/1N6RxH4Edd7ldRIaVfin0si-uSLGyowQi8-7mcux27S0/edit?usp=sharing
> 02/14/2017 - 
> https://docs.google.com/spreadsheets/d/1eZ9_ds_0XyqsKKp8xkmESrcMZRP85jTxSKkNwgtcUn0/edit?usp=sharing



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

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

Re: Solr JIRA: Merge components "web gui" and "UI"

[Alexandre Rafalovitch]

Are we SURE that the role has not been relaxed by INFRA? Because if it
is just us, we could do a one-time cleanup and try to be neat.

Could potentially also have a weekly alert for any component count
less than 3 or some such. Assuming JIRA metadata could be pulled into
facet-style info.

Regards,
   Alex.

http://www.solr-start.com/ - Resources for Solr users, new and experienced


On 16 February 2017 at 11:14, Jan Høydahl  wrote:
> Hmm, we’re not the only one having the challenge
> https://jira.atlassian.com/browse/JRA-42068
>
> However, it’s only Project Admins who can create new components on the fly:
>
> Adrien Grand
> Alan Woodward
> Alexandre Rafalovitch
> Andi Vajda
> Andrzej Bialecki
> Anshum Gupta
> Areek Zillur
> Benson Margulies
> Cassandra Targett
> Chris Male
> Christian Moen
> Christine Poerschke
> Daniel Naber
> David Smiley
> David Smiley
> Dawid Weiss
> Doug Cutting
> Erick Erickson
> Erick Erickson
> Erik Hatcher
> Grant Ingersoll
> hoschek
> Hoss Man
> James Dyer
> Jan Høydahl
> Joel Bernstein
> Karl Wettin
> Kevin Risden
> Koji Sekiguchi
> Mark Harwood
> Mark Miller
> Michael Busch
> Michael McCandless
> Mike Klaas
> Noble Paul
> Otis Gospodnetic
> Ramkumar Aiyengar
> Robert Muir
> Ryan Ernst
> Ryan McKinley
> Sami Siren
> Scott Blum
> Scott Ganyo
> Shai Erera
> Shalin Shekhar Mangar
> Shawn Heisey
> Simon Willnauer
> Stanislaw Osinski
> Stefan Matheis (steffkes)
> Steve Rowe
> Timothy Potter
> Tommaso Teofili
> Tomás Fernández Löbbe
> Upayavira
> Uwe Schindler
> Varun Thacker
> wolfgang hoschek
> Yonik Seeley
>
>
>
> So either all of us should be more thoughtful before creating new stuff
> (preferred), or we limit the Admin list?
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> 16. feb. 2017 kl. 17.03 skrev Jan Høydahl :
>
> Done.
>
> You are right that there are quite some overlap, we have “security” vs
> “Authentication” mm.
> The problem is that anyone can create new components just by typing some
> string in the field and selecting “new”. Could we disable that feature? I
> could not see how.
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> 16. feb. 2017 kl. 16.48 skrev Alexandre Rafalovitch :
>
> +1 (there might even be more than 2)
>
> +5 (if I had it) on general review of the component names, possibly
> with a page in a guide or JIRA somewhere to explain how to pick them.
> I think there are misspellings, synonyms and the other usual search
> problems.
>
> Regards,
>  Alex.
> 
> http://www.solr-start.com/ - Resources for Solr users, new and experienced
>
>
> On 16 February 2017 at 10:41, Stefan Matheis 
> wrote:
>
> +1
>
> -Stefan
>
> On Feb 16, 2017 1:34 PM, "Jan Høydahl"  wrote:
>
>
> We have two components for the same thing: "web gui" (55 issues) and UI
> (22 issues).
> We should merge them to one. Suggest we also rename it to “Admin UI” which
> is the most
> common term used.
>
> --
> Jan Høydahl
> Search Solution architect
> Cominvent AS
> www.cominvent.com
> +47 90125809
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>

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

[jira] [Commented] (SOLR-10132) Support facet.matches to cull facets returned with a regex

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-10132:


bq. ... still need to figure out what to do with the check for numeric facets 
...

Something like this might be hacky but should work:
{code}
public class RegexBytesRefFilter extends SubstringBytesRefFilter {

  final private String regex;
  final private Pattern compiled;

  public RegexBytesRefFilter(String regex) {
super(regex, false);
this.regex = regex;
this.compiled = Pattern.compile(regex);
  }

  @Override
  protected boolean includeString(String term) {
Matcher m = compiled.matcher(term);
return m.matches();
  }

}
{code}

In SOLR-9914 we were puzzled by the check also, perhaps its removal could be 
considered (outside the scope of this ticket) i.e. just disallow/throw if any 
_contains_ (or _matches_ or other string-matching) is used with numeric facets?

> Support facet.matches to cull facets returned with a regex
> --
>
> Key: SOLR-10132
> URL: https://issues.apache.org/jira/browse/SOLR-10132
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: faceting
>Affects Versions: 6.4.1
>Reporter: Gus Heck
> Attachments: SOLR-10132.patch
>
>
> I recently ran into a case where I really wanted to only return the next 
> level of a hierarchical facet, and while I was able to do that with a 
> coordinated set of dynamic fields, it occurred to me that this would have 
> been much much easier if I could have simply used PathHierarchyTokenizer and 
> written
> ="/my/current/prefix/[^/]+$"
> thereby limiting the returned facets to the next level down and not return 
> the  additional  N levels I didn't (yet) want to display (numbering in the 
> thousands near the top of the tree). I suspect there are other good use 
> cases, and the patch seemed relatively tractable.



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

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

Re: Solr JIRA: Merge components "web gui" and "UI"

[Jan Høydahl]

Hmm, we’re not the only one having the challenge 
https://jira.atlassian.com/browse/JRA-42068 


However, it’s only Project Admins who can create new components on the fly:

Adrien GrandAlan WoodwardAlexandre RafalovitchAndi VajdaAndrzej BialeckiAnshum 
GuptaAreek ZillurBenson MarguliesCassandra TargettChris MaleChristian 
MoenChristine PoerschkeDaniel NaberDavid SmileyDavid SmileyDawid WeissDoug 
CuttingErick EricksonErick EricksonErik HatcherGrant IngersollhoschekHoss 
ManJames DyerJan HøydahlJoel BernsteinKarl WettinKevin RisdenKoji SekiguchiMark 
HarwoodMark MillerMichael BuschMichael McCandlessMike KlaasNoble PaulOtis 
GospodneticRamkumar AiyengarRobert MuirRyan ErnstRyan McKinleySami SirenScott 
BlumScott GanyoShai EreraShalin Shekhar MangarShawn HeiseySimon 
WillnauerStanislaw OsinskiStefan Matheis (steffkes)Steve RoweTimothy 
PotterTommaso TeofiliTomás Fernández LöbbeUpayaviraUwe SchindlerVarun 
Thackerwolfgang hoschekYonik Seeley


So either all of us should be more thoughtful before creating new stuff 
(preferred), or we limit the Admin list?

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 16. feb. 2017 kl. 17.03 skrev Jan Høydahl :
> 
> Done.
> 
> You are right that there are quite some overlap, we have “security” vs 
> “Authentication” mm.
> The problem is that anyone can create new components just by typing some 
> string in the field and selecting “new”. Could we disable that feature? I 
> could not see how.
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
> 
>> 16. feb. 2017 kl. 16.48 skrev Alexandre Rafalovitch :
>> 
>> +1 (there might even be more than 2)
>> 
>> +5 (if I had it) on general review of the component names, possibly
>> with a page in a guide or JIRA somewhere to explain how to pick them.
>> I think there are misspellings, synonyms and the other usual search
>> problems.
>> 
>> Regards,
>>  Alex.
>> 
>> http://www.solr-start.com/ - Resources for Solr users, new and experienced
>> 
>> 
>> On 16 February 2017 at 10:41, Stefan Matheis  
>> wrote:
>>> +1
>>> 
>>> -Stefan
>>> 
>>> On Feb 16, 2017 1:34 PM, "Jan Høydahl"  wrote:
 
 We have two components for the same thing: "web gui" (55 issues) and UI
 (22 issues).
 We should merge them to one. Suggest we also rename it to “Admin UI” which
 is the most
 common term used.
 
 --
 Jan Høydahl
 Search Solution architect
 Cominvent AS
 www.cominvent.com
 +47 90125809
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 
>>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 
> 

[jira] [Commented] (SOLR-10130) Serious performance degradation in Solr 6.4.1 due to the new metrics collection

[Walter Underwood (JIRA)]

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

Walter Underwood commented on SOLR-10130:
-

Also, recovery is much, much slower in 6.4. Each core is about 8 GB. After a 
server process restart, the core is recovering for a few minutes in 6.3, but 
for about a half hour in 6.4.

> Serious performance degradation in Solr 6.4.1 due to the new metrics 
> collection
> ---
>
> Key: SOLR-10130
> URL: https://issues.apache.org/jira/browse/SOLR-10130
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 6.4.1
> Environment: Centos 7, OpenJDK 1.8.0 update 111
>Reporter: Ere Maijala
>Assignee: Andrzej Bialecki 
>Priority: Blocker
>  Labels: perfomance
> Fix For: master (7.0), 6.4.2
>
> Attachments: SOLR-10130.patch, SOLR-10130.patch, 
> solr-8983-console-f1.log
>
>
> We've stumbled on serious performance issues after upgrading to Solr 6.4.1. 
> Looks like the new metrics collection system in MetricsDirectoryFactory is 
> causing a major slowdown. This happens with an index configuration that, as 
> far as I can see, has no metrics specific configuration and uses 
> luceneMatchVersion 5.5.0. In practice a moderate load will completely bog 
> down the server with Solr threads constantly using up all CPU (600% on 6 core 
> machine) capacity with a load that normally  where we normally see an average 
> load of < 50%.
> I took stack traces (I'll attach them) and noticed that the threads are 
> spending time in com.codahale.metrics.Meter.mark. I tested building Solr 
> 6.4.1 with the metrics collection disabled in MetricsDirectoryFactory getByte 
> and getBytes methods and was unable to reproduce the issue.
> As far as I can see there are several issues:
> 1. Collecting metrics on every single byte read is slow.
> 2. Having it enabled by default is not a good idea.
> 3. The comment "enable coarse-grained metrics by default" at 
> https://github.com/apache/lucene-solr/blob/branch_6x/solr/core/src/java/org/apache/solr/update/SolrIndexConfig.java#L104
>  implies that only coarse-grained metrics should be enabled by default, and 
> this contradicts with collecting metrics on every single byte read.



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

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

[jira] [Closed] (SOLR-10148) content of dataimport.properties does not show in Tree

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch closed SOLR-10148.

Resolution: Duplicate

> content of dataimport.properties does not show in Tree
> --
>
> Key: SOLR-10148
> URL: https://issues.apache.org/jira/browse/SOLR-10148
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 6.4.1
> Environment: running with build-in Zookeeper. Tested on Windows 7, 
> Firefox 51.0.1 and IE11 
>Reporter: Marcel Berteler
>Priority: Critical
>  Labels: windows
>
> When selecting the various files in the Cloud Tree, the content of the 
> dataimport.properties files does not show. The metadata does show and 
> refreshes when selecting this or other files, but the content area stays 
> blank or continues to show the content of the previously selected files.
> This might be related to an issue whereby IE does not show the data-import 
> status when doing an import. 
> Both the above issues are not present in the 'original UI'



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

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

[jira] [Commented] (SOLR-10134) EmbeddedSolrServer does not support SchemaAPI

[Robert Alexandersson (JIRA)]

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

Robert Alexandersson commented on SOLR-10134:
-

Path uploaded and can be found here as well: 
https://github.com/alero/lucene-solr/commit/3603832e3d4fdb3bfe3fa9eb27202b71dda4e068

> EmbeddedSolrServer does not support SchemaAPI
> -
>
> Key: SOLR-10134
> URL: https://issues.apache.org/jira/browse/SOLR-10134
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Server, SolrJ
>Affects Versions: 6.4.1
>Reporter: Robert Alexandersson
>  Labels: test-driven
> Attachments: SOLR-10134.patch
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> The EmbeddedSolrServer server does not support calls to the POST methods of 
> SchemaAPI using SolRJ api. The reason is that the httpMethod param is never 
> set by the EmbeddedSolrServer#request(SolrRequest, String) and this is later 
> required by the SchemaHandler class that actually performs the call at 
> SchemaHandler#handleRequestBody(SolrQueryRequest, SolrQueryResponse). 
> Proposal is to enhance the EmbeddedSolrServer to forward the httpMethod at 
> aprox row 174 with the following: "req.getContext().put("httpMethod", 
> request.getMethod().name());". This change requires the Factory methods of 
> SolrJ to add the intended method to be used example : new 
> SchemaRequest.AddField() should append the POST method similar to how the 
> SchemaRequest.Field appends the GET method.
> I have written a separate EmbeddedSolrServer that replaces the one in SolR. 
> It works for now and fields can be created on the fly using the SchemaAPI of 
> the solrj client, but would like to be able to remove this workaround.



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

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

[jira] [Updated] (SOLR-10134) EmbeddedSolrServer does not support SchemaAPI

[Robert Alexandersson (JIRA)]

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

Robert Alexandersson updated SOLR-10134:

Attachment: SOLR-10134.patch

> EmbeddedSolrServer does not support SchemaAPI
> -
>
> Key: SOLR-10134
> URL: https://issues.apache.org/jira/browse/SOLR-10134
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Server, SolrJ
>Affects Versions: 6.4.1
>Reporter: Robert Alexandersson
>  Labels: test-driven
> Attachments: SOLR-10134.patch
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> The EmbeddedSolrServer server does not support calls to the POST methods of 
> SchemaAPI using SolRJ api. The reason is that the httpMethod param is never 
> set by the EmbeddedSolrServer#request(SolrRequest, String) and this is later 
> required by the SchemaHandler class that actually performs the call at 
> SchemaHandler#handleRequestBody(SolrQueryRequest, SolrQueryResponse). 
> Proposal is to enhance the EmbeddedSolrServer to forward the httpMethod at 
> aprox row 174 with the following: "req.getContext().put("httpMethod", 
> request.getMethod().name());". This change requires the Factory methods of 
> SolrJ to add the intended method to be used example : new 
> SchemaRequest.AddField() should append the POST method similar to how the 
> SchemaRequest.Field appends the GET method.
> I have written a separate EmbeddedSolrServer that replaces the one in SolR. 
> It works for now and fields can be created on the fly using the SchemaAPI of 
> the solrj client, but would like to be able to remove this workaround.



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

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

Re: Welcome Toke Eskildsen as a Lucene/Solr committer

[Erick Erickson]

Congrats Toke!

On Thu, Feb 16, 2017 at 6:37 AM, Dmitry Kan  wrote:
> Hi Toke, congrats! Glad for you and well deserved!
>
> P.S. Was awesome to test faceting module speed ups you did for high
> cardinality fields. Your skill to explain complex things very efficiently is
> unmatched.
>
> Dmitry
> --
> Dmitry Kan
> Luke Toolbox: http://github.com/DmitryKey/luke
> Blog: http://dmitrykan.blogspot.com
> Twitter: http://twitter.com/dmitrykan
>
> On 14 February 2017 at 20:11, Toke Eskildsen  wrote:
>>
>> Thank you for the invitation and the warm welcome.
>>
>>
>> I am a 43 year old Danish man, with a family and a job at the Royal Danish
>> Library, where I have been working mostly with search-related technology for
>> 10 years.
>>
>> I have done a fair bit of Lucene/Solr hacking during the years, with focus
>> on speed- and memory-optimizations. Implementing bit-packing structures,
>> eliminating steps in calculations and in general making more things possible
>> on less hardware is a bit of an obsession. I hope to continue in that
>> direction as a committer and am looking forward to a more controlled and
>> community-oriented way of writing code: The one-man-show is a lot of fun and
>> can work well for specific use cases, but it tends to get a bit out of
>> control and the result might not be that usable elsewhere.
>>
>> Happy to be here,
>> Toke
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>

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

Re: Solr JIRA: Merge components "web gui" and "UI"

[Jan Høydahl]

Done.

You are right that there are quite some overlap, we have “security” vs 
“Authentication” mm.
The problem is that anyone can create new components just by typing some string 
in the field and selecting “new”. Could we disable that feature? I could not 
see how.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 16. feb. 2017 kl. 16.48 skrev Alexandre Rafalovitch :
> 
> +1 (there might even be more than 2)
> 
> +5 (if I had it) on general review of the component names, possibly
> with a page in a guide or JIRA somewhere to explain how to pick them.
> I think there are misspellings, synonyms and the other usual search
> problems.
> 
> Regards,
>   Alex.
> 
> http://www.solr-start.com/ - Resources for Solr users, new and experienced
> 
> 
> On 16 February 2017 at 10:41, Stefan Matheis  wrote:
>> +1
>> 
>> -Stefan
>> 
>> On Feb 16, 2017 1:34 PM, "Jan Høydahl"  wrote:
>>> 
>>> We have two components for the same thing: "web gui" (55 issues) and UI
>>> (22 issues).
>>> We should merge them to one. Suggest we also rename it to “Admin UI” which
>>> is the most
>>> common term used.
>>> 
>>> --
>>> Jan Høydahl
>>> Search Solution architect
>>> Cominvent AS
>>> www.cominvent.com
>>> +47 90125809
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>> 
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

[jira] [Updated] (SOLR-10148) content of dataimport.properties does not show in Tree

[Marcel Berteler (JIRA)]

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

Marcel Berteler updated SOLR-10148:
---

Indeed. Sorry for the duplication. One can be closed as a duplicate.

On Thu, 16 Feb 2017, 17:36 Alexandre Rafalovitch (JIRA) 



> content of dataimport.properties does not show in Tree
> --
>
> Key: SOLR-10148
> URL: https://issues.apache.org/jira/browse/SOLR-10148
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 6.4.1
> Environment: running with build-in Zookeeper. Tested on Windows 7, 
> Firefox 51.0.1 and IE11 
>Reporter: Marcel Berteler
>Priority: Critical
>  Labels: windows
>
> When selecting the various files in the Cloud Tree, the content of the 
> dataimport.properties files does not show. The metadata does show and 
> refreshes when selecting this or other files, but the content area stays 
> blank or continues to show the content of the previously selected files.
> This might be related to an issue whereby IE does not show the data-import 
> status when doing an import. 
> Both the above issues are not present in the 'original UI'



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

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

[jira] [Updated] (SOLR-9120) o.a.s.h.a.LukeRequestHandler Error getting file length for [segments_NNN] -- NoSuchFileException

[Shawn Heisey (JIRA)]

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

Shawn Heisey updated SOLR-9120:
---
Summary: o.a.s.h.a.LukeRequestHandler Error getting file length for 
[segments_NNN] -- NoSuchFileException  (was: Luke NoSuchFileException)

> o.a.s.h.a.LukeRequestHandler Error getting file length for [segments_NNN] -- 
> NoSuchFileException
> 
>
> Key: SOLR-9120
> URL: https://issues.apache.org/jira/browse/SOLR-9120
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Markus Jelsma
>
> On Solr 6.0, we frequently see the following errors popping up:
> {code}
> java.nio.file.NoSuchFileException: 
> /var/lib/solr/logs_shard2_replica1/data/index/segments_2c5
>   at 
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
>   at 
> sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
>   at 
> sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:144)
>   at 
> sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
>   at java.nio.file.Files.readAttributes(Files.java:1737)
>   at java.nio.file.Files.size(Files.java:2332)
>   at org.apache.lucene.store.FSDirectory.fileLength(FSDirectory.java:243)
>   at 
> org.apache.lucene.store.NRTCachingDirectory.fileLength(NRTCachingDirectory.java:131)
>   at 
> org.apache.solr.handler.admin.LukeRequestHandler.getFileLength(LukeRequestHandler.java:597)
>   at 
> org.apache.solr.handler.admin.LukeRequestHandler.getIndexInfo(LukeRequestHandler.java:585)
>   at 
> org.apache.solr.handler.admin.LukeRequestHandler.handleRequestBody(LukeRequestHandler.java:137)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2033)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:652)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
>   at org.eclipse.jetty.server.Server.handle(Server.java:518)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
>   at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
>   at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
>   at 
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
>   at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)
>   at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
>   at java.lang.Thread.run(Thread.java:745)
> {code}



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

-
To unsubscribe, e-mail: 

[jira] [Commented] (SOLR-9120) Luke NoSuchFileException

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-9120:


Confirmed that this is still happening in the wild on 6.4. Doesn't seem to 
cause any actual issues other than a surplus of log messages.

Here's the full transcript of what can be found in the log on 6.3.0:

{noformat}
2017-02-16 15:56:00.122 WARN  (qtp895947612-44262) [   x:inclive] 
o.a.s.h.a.LukeRequestHandler Error getting file length
for [segments_cr3]
java.nio.file.NoSuchFileException: 
/index/solr6/data/data/inc_1/index/segments_cr3
at 
sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at 
sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
at 
sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:144)
at 
sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
at java.nio.file.Files.readAttributes(Files.java:1737)
at java.nio.file.Files.size(Files.java:2332)
at org.apache.lucene.store.FSDirectory.fileLength(FSDirectory.java:243)
at 
org.apache.lucene.store.NRTCachingDirectory.fileLength(NRTCachingDirectory.java:128)
at 
org.apache.solr.handler.admin.LukeRequestHandler.getFileLength(LukeRequestHandler.java:598)
at 
org.apache.solr.handler.admin.LukeRequestHandler.getIndexInfo(LukeRequestHandler.java:586)
at 
org.apache.solr.handler.admin.LukeRequestHandler.handleRequestBody(LukeRequestHandler.java:137)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:153)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2213)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:303)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:254)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at org.eclipse.jetty.server.Server.handle(Server.java:518)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
at 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
at java.lang.Thread.run(Thread.java:745)
{noformat}


> Luke NoSuchFileException
> 
>
> Key: SOLR-9120
> URL: https://issues.apache.org/jira/browse/SOLR-9120
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Markus Jelsma
>
> On Solr 6.0, we frequently see the following errors popping up:
> {code}
> java.nio.file.NoSuchFileException: 
> /var/lib/solr/logs_shard2_replica1/data/index/segments_2c5
>   at 
> 

[jira] [Commented] (SOLR-10130) Serious performance degradation in Solr 6.4.1 due to the new metrics collection

[Walter Underwood (JIRA)]

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

Walter Underwood commented on SOLR-10130:
-

The slowdown is impressive under heavy query load. Here are two load benchmarks 
with a 16 node cluster, c4.8xlarge instances (36 CPUs, 60 GB RAM), 15.7 million 
docs, 4 shards, replication factor 4 using production query logs. These are 
very long text queries, up to 40 words. Benchmark runs for two or three hours, 
depending on my patience. Java 8u121, G1 collector.

6.4.0 with 1000 requests/minute is running out of CPU. Median and 95th 
percentile response times for an ngram/prefix match are 7.5 and 9.8 seconds. 
For a word match, they are 11 and 25.4 seconds.

6.3.0 with 6000 rpm, the times are 0.4 and 2.7 seconds, and 0.7 and 4.3 
seconds, respectively. CPU usage is under 50%.

Short version, 6.4 is 10X slower than 6.3 handling 1/6 the load. 

> Serious performance degradation in Solr 6.4.1 due to the new metrics 
> collection
> ---
>
> Key: SOLR-10130
> URL: https://issues.apache.org/jira/browse/SOLR-10130
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 6.4.1
> Environment: Centos 7, OpenJDK 1.8.0 update 111
>Reporter: Ere Maijala
>Assignee: Andrzej Bialecki 
>Priority: Blocker
>  Labels: perfomance
> Fix For: master (7.0), 6.4.2
>
> Attachments: SOLR-10130.patch, SOLR-10130.patch, 
> solr-8983-console-f1.log
>
>
> We've stumbled on serious performance issues after upgrading to Solr 6.4.1. 
> Looks like the new metrics collection system in MetricsDirectoryFactory is 
> causing a major slowdown. This happens with an index configuration that, as 
> far as I can see, has no metrics specific configuration and uses 
> luceneMatchVersion 5.5.0. In practice a moderate load will completely bog 
> down the server with Solr threads constantly using up all CPU (600% on 6 core 
> machine) capacity with a load that normally  where we normally see an average 
> load of < 50%.
> I took stack traces (I'll attach them) and noticed that the threads are 
> spending time in com.codahale.metrics.Meter.mark. I tested building Solr 
> 6.4.1 with the metrics collection disabled in MetricsDirectoryFactory getByte 
> and getBytes methods and was unable to reproduce the issue.
> As far as I can see there are several issues:
> 1. Collecting metrics on every single byte read is slow.
> 2. Having it enabled by default is not a good idea.
> 3. The comment "enable coarse-grained metrics by default" at 
> https://github.com/apache/lucene-solr/blob/branch_6x/solr/core/src/java/org/apache/solr/update/SolrIndexConfig.java#L104
>  implies that only coarse-grained metrics should be enabled by default, and 
> this contradicts with collecting metrics on every single byte read.



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

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

Re: Solr JIRA: Merge components "web gui" and "UI"

[Alexandre Rafalovitch]

+1 (there might even be more than 2)

+5 (if I had it) on general review of the component names, possibly
with a page in a guide or JIRA somewhere to explain how to pick them.
I think there are misspellings, synonyms and the other usual search
problems.

Regards,
   Alex.

http://www.solr-start.com/ - Resources for Solr users, new and experienced


On 16 February 2017 at 10:41, Stefan Matheis  wrote:
> +1
>
> -Stefan
>
> On Feb 16, 2017 1:34 PM, "Jan Høydahl"  wrote:
>>
>> We have two components for the same thing: "web gui" (55 issues) and UI
>> (22 issues).
>> We should merge them to one. Suggest we also rename it to “Admin UI” which
>> is the most
>> common term used.
>>
>> --
>> Jan Høydahl
>> Search Solution architect
>> Cominvent AS
>> www.cominvent.com
>> +47 90125809
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>

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

Re: Solr JIRA: Merge components "web gui" and "UI"

[Stefan Matheis]

+1

-Stefan

On Feb 16, 2017 1:34 PM, "Jan Høydahl"  wrote:

> We have two components for the same thing: "web gui" (55 issues) and UI
> (22 issues).
> We should merge them to one. Suggest we also rename it to “Admin UI” which
> is the most
> common term used.
>
> --
> Jan Høydahl
> Search Solution architect
> Cominvent AS
> www.cominvent.com
> +47 90125809
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Commented] (SOLR-10145) Alphanumeric text getting indexed separately for WhitespaceTokenizerFactory

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-10145:
--

Please ask this question on the Solr User mailing list. Most likely it is 
misconfiguration/misunderstanding of your schema. JIRA is for the bugs to be 
fixed in Solr. If there is an actual bug - and it is not fixed in later 
versions of Solr - then an issue can be opened.

> Alphanumeric text getting indexed separately for WhitespaceTokenizerFactory 
> 
>
> Key: SOLR-10145
> URL: https://issues.apache.org/jira/browse/SOLR-10145
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Lakshmi Kanta Nandi
>
> Alphanumeric text is getting indexed separately for the 
> WhitespaceTokenizerFactory. I have tried tokenizer class 
> solr.KeywordTokenizerFactory too but still my text getting splitted and 
> indexed.
> Scenario
> Input string: ABCD1234EFGH
> Generated index: ABCD, 1234, EFGH
> Expected index: ABCD1234EFGH
> Search
> Input: ABC* returns success 
> Input: ABCD123* returns fail (success expected)
> Inout: ABCD1234 returns success
> Configuration
> {code}
> 
>   
> 
> 
>  words="stopwords.txt"/>
>  generateNumberParts="0" catenateWords="1" catenateNumbers="1" 
> catenateAll="0"/>
> 
>  protected="protwords.txt"/>
> 
>   
>   
> 
>  ignoreCase="true" expand="true"/>
>  words="stopwords.txt"/>
>  generateNumberParts="1" catenateWords="0" catenateNumbers="0" 
> catenateAll="0"/>
> 
>  protected="protwords.txt"/>
> 
>   
> 
> {code}
> Solr version: 4.3



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

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

[jira] [Closed] (SOLR-10145) Alphanumeric text getting indexed separately for WhitespaceTokenizerFactory

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch closed SOLR-10145.

Resolution: Information Provided

> Alphanumeric text getting indexed separately for WhitespaceTokenizerFactory 
> 
>
> Key: SOLR-10145
> URL: https://issues.apache.org/jira/browse/SOLR-10145
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Lakshmi Kanta Nandi
>
> Alphanumeric text is getting indexed separately for the 
> WhitespaceTokenizerFactory. I have tried tokenizer class 
> solr.KeywordTokenizerFactory too but still my text getting splitted and 
> indexed.
> Scenario
> Input string: ABCD1234EFGH
> Generated index: ABCD, 1234, EFGH
> Expected index: ABCD1234EFGH
> Search
> Input: ABC* returns success 
> Input: ABCD123* returns fail (success expected)
> Inout: ABCD1234 returns success
> Configuration
> {code}
> 
>   
> 
> 
>  words="stopwords.txt"/>
>  generateNumberParts="0" catenateWords="1" catenateNumbers="1" 
> catenateAll="0"/>
> 
>  protected="protwords.txt"/>
> 
>   
>   
> 
>  ignoreCase="true" expand="true"/>
>  words="stopwords.txt"/>
>  generateNumberParts="1" catenateWords="0" catenateNumbers="0" 
> catenateAll="0"/>
> 
>  protected="protwords.txt"/>
> 
>   
> 
> {code}
> Solr version: 4.3



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

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

[jira] [Commented] (SOLR-10148) content of dataimport.properties does not show in Tree

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-10148:
--

This and the SOLR-10149 seem to be the identical issue. Must be a technical 
glitch. Please confirm and I can close this case as accidental duplicate.

> content of dataimport.properties does not show in Tree
> --
>
> Key: SOLR-10148
> URL: https://issues.apache.org/jira/browse/SOLR-10148
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UI
>Affects Versions: 6.4.1
> Environment: running with build-in Zookeeper. Tested on Windows 7, 
> Firefox 51.0.1 and IE11 
>Reporter: Marcel Berteler
>Priority: Critical
>  Labels: windows
>
> When selecting the various files in the Cloud Tree, the content of the 
> dataimport.properties files does not show. The metadata does show and 
> refreshes when selecting this or other files, but the content area stays 
> blank or continues to show the content of the previously selected files.
> This might be related to an issue whereby IE does not show the data-import 
> status when doing an import. 
> Both the above issues are not present in the 'original UI'



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

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

[jira] [Updated] (SOLR-10149) content of dataimport.properties does not show in Tree

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch updated SOLR-10149:
-
Labels: regression windows  (was: windows)

> content of dataimport.properties does not show in Tree
> --
>
> Key: SOLR-10149
> URL: https://issues.apache.org/jira/browse/SOLR-10149
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UI
>Affects Versions: 6.4.1
> Environment: build in zookeeper, windows 7, IE11, Firefox 51
>Reporter: Marcel Berteler
>Priority: Critical
>  Labels: regression, windows
> Attachments: ff new UI.jpg, ff original UI.jpg, ie data import 
> new.jpg, ie data import original.jpg, ie new UI.jpg, ie original UI.jpg
>
>
> When selecting the dataimport.properties file in the cloud tree, it does not 
> show the content of the file in the new UI. It does in the original UI.
> This might be related to the problem where IE does not show the import status 
> when importing new data and continues to show 'Last Update: unknown'



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

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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.handler.admin.TestApiFramework.testFramework

Error Message:


Stack Trace:
java.lang.ExceptionInInitializerError
at 
__randomizedtesting.SeedInfo.seed([2239D2D703761B05:354F18F005A2F738]:0)
at 
net.sf.cglib.core.KeyFactory$Generator.generateClass(KeyFactory.java:166)
at 
net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25)
at 
net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:216)
at net.sf.cglib.core.KeyFactory$Generator.create(KeyFactory.java:144)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:116)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:108)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:104)
at net.sf.cglib.proxy.Enhancer.(Enhancer.java:69)
at 
org.easymock.internal.ClassProxyFactory.createEnhancer(ClassProxyFactory.java:259)
at 
org.easymock.internal.ClassProxyFactory.createProxy(ClassProxyFactory.java:174)
at org.easymock.internal.MocksControl.createMock(MocksControl.java:60)
at org.easymock.EasyMock.createMock(EasyMock.java:104)
at 
org.apache.solr.handler.admin.TestCoreAdminApis.getCoreContainerMock(TestCoreAdminApis.java:83)
at 
org.apache.solr.handler.admin.TestApiFramework.testFramework(TestApiFramework.java:59)
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:543)
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 

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

[Apache Jenkins Server]

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

2 tests failed.
FAILED:  
org.apache.solr.cloud.hdfs.HdfsCollectionsAPIDistributedZkTest.testCollectionsAPI

Error Message:
Expected to see collection awhollynewcollection_0 null Last available state: 
DocCollection(awhollynewcollection_0//collections/awhollynewcollection_0/state.json/8)={
   "replicationFactor":"3",   "shards":{ "shard1":{   
"range":"8000-b332",   "state":"active",   "replicas":{}}, 
"shard2":{   "range":"b333-e665",   "state":"active",   
"replicas":{}}, "shard3":{   "range":"e666-1998",   
"state":"active",   "replicas":{}}, "shard4":{   
"range":"1999-4ccb",   "state":"active",   "replicas":{}}, 
"shard5":{   "range":"4ccc-7fff",   "state":"active",   
"replicas":{}}},   "router":{"name":"compositeId"},   "maxShardsPerNode":"4",   
"autoAddReplicas":"false"}

Stack Trace:
java.lang.AssertionError: Expected to see collection awhollynewcollection_0
null
Last available state: 
DocCollection(awhollynewcollection_0//collections/awhollynewcollection_0/state.json/8)={
  "replicationFactor":"3",
  "shards":{
"shard1":{
  "range":"8000-b332",
  "state":"active",
  "replicas":{}},
"shard2":{
  "range":"b333-e665",
  "state":"active",
  "replicas":{}},
"shard3":{
  "range":"e666-1998",
  "state":"active",
  "replicas":{}},
"shard4":{
  "range":"1999-4ccb",
  "state":"active",
  "replicas":{}},
"shard5":{
  "range":"4ccc-7fff",
  "state":"active",
  "replicas":{}}},
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"4",
  "autoAddReplicas":"false"}
at 
__randomizedtesting.SeedInfo.seed([D11027C0F5C87423:99655374F3FB5BB6]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:265)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:502)
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 

[jira] [Updated] (SOLR-10149) content of dataimport.properties does not show in Tree

[Marcel Berteler (JIRA)]

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

Marcel Berteler updated SOLR-10149:
---
Attachment: ie original UI.jpg
ie new UI.jpg
ie data import original.jpg
ie data import new.jpg
ff original UI.jpg
ff new UI.jpg

Screenshots showing the same files / screens in original and new UI

> content of dataimport.properties does not show in Tree
> --
>
> Key: SOLR-10149
> URL: https://issues.apache.org/jira/browse/SOLR-10149
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UI
>Affects Versions: 6.4.1
> Environment: build in zookeeper, windows 7, IE11, Firefox 51
>Reporter: Marcel Berteler
>Priority: Critical
>  Labels: windows
> Attachments: ff new UI.jpg, ff original UI.jpg, ie data import 
> new.jpg, ie data import original.jpg, ie new UI.jpg, ie original UI.jpg
>
>
> When selecting the dataimport.properties file in the cloud tree, it does not 
> show the content of the file in the new UI. It does in the original UI.
> This might be related to the problem where IE does not show the import status 
> when importing new data and continues to show 'Last Update: unknown'



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

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

[jira] [Created] (SOLR-10149) content of dataimport.properties does not show in Tree

[Marcel Berteler (JIRA)]

Marcel Berteler created SOLR-10149:
--

 Summary: content of dataimport.properties does not show in Tree
 Key: SOLR-10149
 URL: https://issues.apache.org/jira/browse/SOLR-10149
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: UI
Affects Versions: 6.4.1
 Environment: build in zookeeper, windows 7, IE11, Firefox 51
Reporter: Marcel Berteler
Priority: Critical


When selecting the dataimport.properties file in the cloud tree, it does not 
show the content of the file in the new UI. It does in the original UI.

This might be related to the problem where IE does not show the import status 
when importing new data and continues to show 'Last Update: unknown'



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

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

Re: Welcome Toke Eskildsen as a Lucene/Solr committer

[Dmitry Kan]

Hi Toke, congrats! Glad for you and well deserved!

P.S. Was awesome to test faceting module speed ups you did for high
cardinality fields. Your skill to explain complex things very efficiently
is unmatched.

Dmitry
-- 
Dmitry Kan
Luke Toolbox: http://github.com/DmitryKey/luke
Blog: http://dmitrykan.blogspot.com
Twitter: http://twitter.com/dmitrykan

On 14 February 2017 at 20:11, Toke Eskildsen  wrote:

> Thank you for the invitation and the warm welcome.
>
>
> I am a 43 year old Danish man, with a family and a job at the Royal Danish
> Library, where I have been working mostly with search-related technology
> for 10 years.
>
> I have done a fair bit of Lucene/Solr hacking during the years, with focus
> on speed- and memory-optimizations. Implementing bit-packing structures,
> eliminating steps in calculations and in general making more things
> possible on less hardware is a bit of an obsession. I hope to continue in
> that direction as a committer and am looking forward to a more controlled
> and community-oriented way of writing code: The one-man-show is a lot of
> fun and can work well for specific use cases, but it tends to get a bit out
> of control and the result might not be that usable elsewhere.
>
> Happy to be here,
> Toke
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Solr JIRA: Merge components "web gui" and "UI"

[Adrien Grand]

+1

Le jeu. 16 févr. 2017 à 15:28, David Smiley  a
écrit :

> +1
> On Thu, Feb 16, 2017 at 4:34 AM Jan Høydahl  wrote:
>
> We have two components for the same thing: "web gui" (55 issues) and UI
> (22 issues).
> We should merge them to one. Suggest we also rename it to “Admin UI” which
> is the most
> common term used.
>
> --
> Jan Høydahl
> Search Solution architect
> Cominvent AS
> www.cominvent.com
> +47 90125809 <+47%20901%2025%20809>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>

[jira] [Resolved] (LUCENE-7685) Remove equals/rewrite hacks from block join queries

[Adrien Grand (JIRA)]

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

Adrien Grand resolved LUCENE-7685.
--
   Resolution: Fixed
Fix Version/s: 6.5
   master (7.0)

> Remove equals/rewrite hacks from block join queries
> ---
>
> Key: LUCENE-7685
> URL: https://issues.apache.org/jira/browse/LUCENE-7685
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: master (7.0), 6.5
>
> Attachments: LUCENE-7685.patch
>
>
> These queries try to ensure that rewritten queries are equal to the original 
> query by keeping around the original query that was used to instantiate the 
> join query. However this does not buy anything, and could even prevent two 
> queries that rewrite to the same form to be considered equals.



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

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

[jira] [Resolved] (LUCENE-7677) Cache compound filters earlier than regular queries

[Adrien Grand (JIRA)]

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

Adrien Grand resolved LUCENE-7677.
--
   Resolution: Fixed
Fix Version/s: 6.5
   master (7.0)

> Cache compound filters earlier than regular queries
> ---
>
> Key: LUCENE-7677
> URL: https://issues.apache.org/jira/browse/LUCENE-7677
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: master (7.0), 6.5
>
> Attachments: LUCENE-7677.patch
>
>
> Say you keep reusing a boolean filter that looks like "A OR B" and never use 
> the A and B queries out of that boolean query. Currently, after this filter 
> has been used 5 times, we would cache both A, B and "A OR B", which means 
> that cache entries for A and B would only be built for the purpose of 
> building a cache entry for "A OR B", which is wasteful.
> By caching compound queries a bit earlier, we could make it less likely to 
> happen since:
>  - we only consider queries as consumed if a scorer is pulled
>  - once the boolean query is cached, we stop pulling scorers on the A and B 
> queries



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

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

[jira] [Created] (SOLR-10148) content of dataimport.properties does not show in Tree

[Marcel Berteler (JIRA)]

Marcel Berteler created SOLR-10148:
--

 Summary: content of dataimport.properties does not show in Tree
 Key: SOLR-10148
 URL: https://issues.apache.org/jira/browse/SOLR-10148
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: UI
Affects Versions: 6.4.1
 Environment: running with build-in Zookeeper. Tested on Windows 7, 
Firefox 51.0.1 and IE11 
Reporter: Marcel Berteler
Priority: Critical


When selecting the various files in the Cloud Tree, the content of the 
dataimport.properties files does not show. The metadata does show and refreshes 
when selecting this or other files, but the content area stays blank or 
continues to show the content of the previously selected files.

This might be related to an issue whereby IE does not show the data-import 
status when doing an import. 

Both the above issues are not present in the 'original UI'



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

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

[jira] [Resolved] (LUCENE-7680) Never cache term filters

[Adrien Grand (JIRA)]

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

Adrien Grand resolved LUCENE-7680.
--
   Resolution: Fixed
Fix Version/s: 6.5
   master (7.0)

> Never cache term filters
> 
>
> Key: LUCENE-7680
> URL: https://issues.apache.org/jira/browse/LUCENE-7680
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: master (7.0), 6.5
>
> Attachments: LUCENE-7680.patch, LUCENE-7680.patch
>
>
> Currently we just require term filters to be used a lot in order to cache 
> them. Maybe instead we should look into never caching them. This should not 
> hurt performance since term filters are plenty fast, and would make other 
> filters more likely to be cached since we would not "pollute" the history 
> with filters that are not worth caching.



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

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

[jira] [Resolved] (LUCENE-7692) PatternReplaceCharFilterFactory should implement MultiTermAware

[Adrien Grand (JIRA)]

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

Adrien Grand resolved LUCENE-7692.
--
   Resolution: Fixed
Fix Version/s: 6.5
   master (7.0)

> PatternReplaceCharFilterFactory should implement MultiTermAware
> ---
>
> Key: LUCENE-7692
> URL: https://issues.apache.org/jira/browse/LUCENE-7692
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: master (7.0), 6.5
>
>
> The multi-term aware marker API is useful to know which analysis components 
> to apply when analyzing prefix or wildcard queries. I think 
> PatternReplaceCharFilterFactory qualifies?
> For the record, we have MappingCharFilterFactory that does a similar job 
> (except that it takes an explicit map of replacements  rather than regular 
> expressions) and implements MultiTermAware.



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

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

[jira] [Commented] (LUCENE-7685) Remove equals/rewrite hacks from block join queries

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7685: Remove equals/rewrite hacks from block join queries.


> Remove equals/rewrite hacks from block join queries
> ---
>
> Key: LUCENE-7685
> URL: https://issues.apache.org/jira/browse/LUCENE-7685
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7685.patch
>
>
> These queries try to ensure that rewritten queries are equal to the original 
> query by keeping around the original query that was used to instantiate the 
> join query. However this does not buy anything, and could even prevent two 
> queries that rewrite to the same form to be considered equals.



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

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