[jira] [Commented] (LUCENE-8291) Possible security issue when parsing XML documents containing external entity references
[ https://issues.apache.org/jira/browse/LUCENE-8291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476891#comment-16476891 ] ASF subversion and git services commented on LUCENE-8291: - Commit 09a789f535007c907c8dc55f3ae4e4e9ca9c8ee3 in lucene-solr's branch refs/heads/master from [~mkhludnev] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=09a789f ] LUCENE-8291: Build Fix. Removing Demo Servlet. > Possible security issue when parsing XML documents containing external entity > references > > > Key: LUCENE-8291 > URL: https://issues.apache.org/jira/browse/LUCENE-8291 > Project: Lucene - Core > Issue Type: Bug > Components: modules/queryparser >Affects Versions: 7.2.1 >Reporter: Hendrik Saly >Assignee: Uwe Schindler >Priority: Major > Fix For: 7.4, master (8.0) > > Attachments: LUCENE-8291.patch > > > It appears that in QueryTemplateManager.java lines 149 and 198 and in > DOMUtils.java line 204 XML is parsed without disabling external entity > references (XXE). This is described in > [http://cwe.mitre.org/data/definitions/611.html] and possible mitigations are > listed here: > [https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet] > All recent versions of lucene are affected. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 1870 - Still Failing!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1870/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 7200 lines...] [javac] Compiling 13 source files to /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/build/demo/classes/java [javac] /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:46: error: cannot find symbol [javac] import org.apache.lucene.queryparser.xml.QueryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: package org.apache.lucene.queryparser.xml [javac] /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:61: error: cannot find symbol [javac] private QueryTemplateManager queryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:81: error: cannot find symbol [javac] queryTemplateManager = new QueryTemplateManager( [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] 3 errors BUILD FAILED /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/build.xml:633: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/build.xml:577: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/build.xml:59: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/build.xml:493: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/common-build.xml:2264: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/module-build.xml:67: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/module-build.xml:64: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/common-build.xml:551: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/common-build.xml:2052: Compile failed; see the compiler error output for details. Total time: 12 minutes 14 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 [WARNINGS] Skipping publisher since build result is FAILURE Recording test results Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-7.3 - Build # 71 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.3/71/ 1 tests failed. FAILED: org.apache.solr.cloud.AddReplicaTest.test Error Message: core_node6:{"core":"addreplicatest_coll_shard1_replica_n5","base_url":"http://127.0.0.1:52783/solr","node_name":"127.0.0.1:52783_solr","state":"active","type":"NRT"} Stack Trace: java.lang.AssertionError: core_node6:{"core":"addreplicatest_coll_shard1_replica_n5","base_url":"http://127.0.0.1:52783/solr","node_name":"127.0.0.1:52783_solr","state":"active","type":"NRT"} at __randomizedtesting.SeedInfo.seed([8279B101EE7DB9E0:A2D8EDB4081D418]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.cloud.AddReplicaTest.test(AddReplicaTest.java:84) 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:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) 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:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Build Log: [...truncated 13881 lines...] [junit4] Suite: org.apache.solr.cloud.AddReplicaTest [junit4] 2> Creating dataDir:
[JENKINS] Lucene-Solr-7.x-MacOSX (64bit/jdk-9) - Build # 645 - Still Failing!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/645/ Java: 64bit/jdk-9 -XX:-UseCompressedOops -XX:+UseG1GC All tests passed Build Log: [...truncated 7225 lines...] [javac] Compiling 13 source files to /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/build/demo/classes/java [javac] /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:46: error: cannot find symbol [javac] import org.apache.lucene.queryparser.xml.QueryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: package org.apache.lucene.queryparser.xml [javac] /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:61: error: cannot find symbol [javac] private QueryTemplateManager queryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:81: error: cannot find symbol [javac] queryTemplateManager = new QueryTemplateManager( [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] 3 errors BUILD FAILED /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/build.xml:633: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/build.xml:577: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/build.xml:59: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/build.xml:493: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/common-build.xml:2264: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/module-build.xml:67: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/module-build.xml:64: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/common-build.xml:551: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/common-build.xml:2052: Compile failed; see the compiler error output for details. Total time: 14 minutes 15 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 [WARNINGS] Skipping publisher since build result is FAILURE Recording test results Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.3-Linux (32bit/jdk1.8.0_162) - Build # 234 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.3-Linux/234/ Java: 32bit/jdk1.8.0_162 -server -XX:+UseSerialGC 4 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.client.solrj.io.stream.StreamExpressionTest Error Message: Error starting up MiniSolrCloudCluster Stack Trace: java.lang.Exception: Error starting up MiniSolrCloudCluster at __randomizedtesting.SeedInfo.seed([BEA5E54946DE17B5]:0) at org.apache.solr.cloud.MiniSolrCloudCluster.checkForExceptions(MiniSolrCloudCluster.java:513) at org.apache.solr.cloud.MiniSolrCloudCluster.(MiniSolrCloudCluster.java:251) at org.apache.solr.cloud.SolrCloudTestCase$Builder.configure(SolrCloudTestCase.java:190) at org.apache.solr.client.solrj.io.stream.StreamExpressionTest.setupCluster(StreamExpressionTest.java:92) 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:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Suppressed: java.lang.AssertionError at sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.getUpperBoundASTs(WildcardTypeImpl.java:86) at sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.getUpperBounds(WildcardTypeImpl.java:122) at sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.toString(WildcardTypeImpl.java:190) at java.lang.reflect.Type.getTypeName(Type.java:46) at sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl.toString(ParameterizedTypeImpl.java:234) at java.lang.reflect.Type.getTypeName(Type.java:46) at java.lang.reflect.Method.specificToGenericStringHeader(Method.java:421) at java.lang.reflect.Executable.sharedToGenericString(Executable.java:163) at java.lang.reflect.Method.toGenericString(Method.java:415) at java.beans.MethodRef.set(MethodRef.java:46) at java.beans.MethodDescriptor.setMethod(MethodDescriptor.java:117) at java.beans.MethodDescriptor.(MethodDescriptor.java:72) at java.beans.MethodDescriptor.(MethodDescriptor.java:56) at java.beans.Introspector.getTargetMethodInfo(Introspector.java:1205) at java.beans.Introspector.getBeanInfo(Introspector.java:426) at java.beans.Introspector.getBeanInfo(Introspector.java:173) at java.beans.Introspector.getBeanInfo(Introspector.java:260) at java.beans.Introspector.(Introspector.java:407) at java.beans.Introspector.getBeanInfo(Introspector.java:173) at
[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk-9) - Build # 4635 - Still Failing!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4635/ Java: 64bit/jdk-9 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 1874 lines...] [junit4] JVM J0: stderr was not empty, see: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/core/test/temp/junit4-J0-20180516_051331_73311204493349982883112.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [...truncated 3 lines...] [junit4] JVM J1: stderr was not empty, see: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/core/test/temp/junit4-J1-20180516_051331_72817332342290655315550.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [...truncated 287 lines...] [junit4] JVM J1: stderr was not empty, see: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/test-framework/test/temp/junit4-J1-20180516_052132_2417044313924457418719.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [...truncated 3 lines...] [junit4] JVM J0: stderr was not empty, see: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/test-framework/test/temp/junit4-J0-20180516_052132_24115165089008905954209.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [...truncated 1075 lines...] [junit4] JVM J0: stderr was not empty, see: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/analysis/common/test/temp/junit4-J0-20180516_052255_29215759673496372190709.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [...truncated 3 lines...] [junit4] JVM J1: stderr was not empty, see: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/analysis/common/test/temp/junit4-J1-20180516_052255_2942905559953734614995.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [...truncated 259 lines...] [junit4] JVM J1: stderr was not empty, see: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/analysis/icu/test/temp/junit4-J1-20180516_052533_66318372523448890491573.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [junit4] JVM J0: stderr was not empty, see: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/analysis/icu/test/temp/junit4-J0-20180516_052533_6601157092919349943802.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [...truncated 244 lines...] [junit4] JVM J0: stderr was not empty, see: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/analysis/kuromoji/test/temp/junit4-J0-20180516_052545_76812321550131061805810.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [...truncated 12 lines...] [junit4] JVM J1: stderr was not empty, see: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/analysis/kuromoji/test/temp/junit4-J1-20180516_052545_7682957409671991683938.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [...truncated 162 lines...] [junit4] JVM J1: stderr was not
[JENKINS] Lucene-Solr-Tests-master - Build # 2527 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/2527/ All tests passed Build Log: [...truncated 7272 lines...] [javac] Compiling 13 source files to /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/demo/classes/java [javac] /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:46: error: cannot find symbol [javac] import org.apache.lucene.queryparser.xml.QueryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: package org.apache.lucene.queryparser.xml [javac] /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:61: error: cannot find symbol [javac] private QueryTemplateManager queryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:81: error: cannot find symbol [javac] queryTemplateManager = new QueryTemplateManager( [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] 3 errors BUILD FAILED /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/build.xml:633: The following error occurred while executing this line: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/build.xml:577: The following error occurred while executing this line: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/build.xml:59: The following error occurred while executing this line: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build.xml:493: The following error occurred while executing this line: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/common-build.xml:2264: The following error occurred while executing this line: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/module-build.xml:67: The following error occurred while executing this line: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/module-build.xml:64: The following error occurred while executing this line: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/common-build.xml:551: The following error occurred while executing this line: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/common-build.xml:2052: Compile failed; see the compiler error output for details. Total time: 85 minutes 45 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7960) NGram filters -- preserve the original token when it is outside the min/max size range
[ https://issues.apache.org/jira/browse/LUCENE-7960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476817#comment-16476817 ] Robert Muir commented on LUCENE-7960: - {quote} *) Even though I'm watching this issue, I'm not getting mails from Jira. Is this intentional for non-commiters? {quote} As far as I know, JIRA doesn't consider any roles. This is what the configuration says: |Issue Commented| * All Watchers * Current Assignee * Reporter * Single Email Address (dev at lucene.apache.org)| I added you to Contributors group so you can assign issues: maybe it helps. But it could be something SMTP-related or some other problem. Did you get any notifications when Shawn mentioned you on this issue? > NGram filters -- preserve the original token when it is outside the min/max > size range > -- > > Key: LUCENE-7960 > URL: https://issues.apache.org/jira/browse/LUCENE-7960 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Reporter: Shawn Heisey >Priority: Major > Attachments: LUCENE-7960.patch, LUCENE-7960.patch, LUCENE-7960.patch > > Time Spent: 0.5h > Remaining Estimate: 0h > > When ngram or edgengram filters are used, any terms that are shorter than the > minGramSize are completely removed from the token stream. > This is probably 100% what was intended, but I've seen it cause a lot of > problems for users. I am not suggesting that the default behavior be > changed. That would be far too disruptive to the existing user base. > I do think there should be a new boolean option, with a name like > keepShortTerms, that defaults to false, to allow the short terms to be > preserved. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk-10) - Build # 1909 - Still Failing!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1909/ Java: 64bit/jdk-10 -XX:-UseCompressedOops -XX:+UseSerialGC All tests passed Build Log: [...truncated 7264 lines...] [javac] Compiling 13 source files to /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/demo/classes/java [javac] /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:46: error: cannot find symbol [javac] import org.apache.lucene.queryparser.xml.QueryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: package org.apache.lucene.queryparser.xml [javac] /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:61: error: cannot find symbol [javac] private QueryTemplateManager queryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:81: error: cannot find symbol [javac] queryTemplateManager = new QueryTemplateManager( [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] 3 errors BUILD FAILED /home/jenkins/workspace/Lucene-Solr-7.x-Linux/build.xml:633: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/build.xml:577: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/build.xml:59: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build.xml:493: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/common-build.xml:2264: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/module-build.xml:67: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/module-build.xml:64: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/common-build.xml:551: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/common-build.xml:2052: Compile failed; see the compiler error output for details. Total time: 17 minutes 0 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 [WARNINGS] Skipping publisher since build result is FAILURE Recording test results Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-10) - Build # 22017 - Still Failing!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/22017/ Java: 64bit/jdk-10 -XX:+UseCompressedOops -XX:+UseG1GC All tests passed Build Log: [...truncated 7250 lines...] [javac] Compiling 13 source files to /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/demo/classes/java [javac] /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:46: error: cannot find symbol [javac] import org.apache.lucene.queryparser.xml.QueryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: package org.apache.lucene.queryparser.xml [javac] /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:61: error: cannot find symbol [javac] private QueryTemplateManager queryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:81: error: cannot find symbol [javac] queryTemplateManager = new QueryTemplateManager( [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] 3 errors BUILD FAILED /home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:633: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:577: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:59: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build.xml:493: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/common-build.xml:2264: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/module-build.xml:67: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/module-build.xml:64: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/common-build.xml:551: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/common-build.xml:2052: Compile failed; see the compiler error output for details. Total time: 23 minutes 19 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 [WARNINGS] Skipping publisher since build result is FAILURE Recording test results Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-9.0.4) - Build # 7317 - Still Failing!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7317/ Java: 64bit/jdk-9.0.4 -XX:+UseCompressedOops -XX:+UseParallelGC All tests passed Build Log: [...truncated 7253 lines...] [javac] Compiling 13 source files to C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\demo\classes\java [javac] C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\demo\src\java\org\apache\lucene\demo\xmlparser\FormBasedXmlQueryDemo.java:46: error: cannot find symbol [javac] import org.apache.lucene.queryparser.xml.QueryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: package org.apache.lucene.queryparser.xml [javac] C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\demo\src\java\org\apache\lucene\demo\xmlparser\FormBasedXmlQueryDemo.java:61: error: cannot find symbol [javac] private QueryTemplateManager queryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\demo\src\java\org\apache\lucene\demo\xmlparser\FormBasedXmlQueryDemo.java:81: error: cannot find symbol [javac] queryTemplateManager = new QueryTemplateManager( [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] 3 errors BUILD FAILED C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\build.xml:633: The following error occurred while executing this line: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\build.xml:577: The following error occurred while executing this line: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\build.xml:59: The following error occurred while executing this line: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build.xml:493: The following error occurred while executing this line: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\common-build.xml:2264: The following error occurred while executing this line: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\module-build.xml:67: The following error occurred while executing this line: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\module-build.xml:64: The following error occurred while executing this line: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\common-build.xml:551: The following error occurred while executing this line: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\common-build.xml:2052: Compile failed; see the compiler error output for details. Total time: 12 minutes 38 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Setting ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2 [WARNINGS] Skipping publisher since build result is FAILURE Recording test results Setting ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any Setting ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2 Setting ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2 Setting ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2 Setting ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-BadApples-7.x-Linux (64bit/jdk-9.0.4) - Build # 37 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-7.x-Linux/37/ Java: 64bit/jdk-9.0.4 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 1809 lines...] [junit4] JVM J2: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-BadApples-7.x-Linux/lucene/build/core/test/temp/junit4-J2-20180516_025016_457709195438340551970.syserr [junit4] >>> JVM J2 emitted unexpected output (verbatim) [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J2: EOF [...truncated 3 lines...] [junit4] JVM J0: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-BadApples-7.x-Linux/lucene/build/core/test/temp/junit4-J0-20180516_025016_45515472862549252371370.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [...truncated 3 lines...] [junit4] JVM J1: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-BadApples-7.x-Linux/lucene/build/core/test/temp/junit4-J1-20180516_025016_45713014644300883597524.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [...truncated 295 lines...] [junit4] JVM J0: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-BadApples-7.x-Linux/lucene/build/test-framework/test/temp/junit4-J0-20180516_025533_4246660678585464796955.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [...truncated 6 lines...] [junit4] JVM J1: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-BadApples-7.x-Linux/lucene/build/test-framework/test/temp/junit4-J1-20180516_025533_4241363484868251727641.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [junit4] JVM J2: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-BadApples-7.x-Linux/lucene/build/test-framework/test/temp/junit4-J2-20180516_025533_4242355200695445415624.syserr [junit4] >>> JVM J2 emitted unexpected output (verbatim) [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J2: EOF [...truncated 1075 lines...] [junit4] JVM J2: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-BadApples-7.x-Linux/lucene/build/analysis/common/test/temp/junit4-J2-20180516_025642_83511669479631096808731.syserr [junit4] >>> JVM J2 emitted unexpected output (verbatim) [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J2: EOF [...truncated 3 lines...] [junit4] JVM J0: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-BadApples-7.x-Linux/lucene/build/analysis/common/test/temp/junit4-J0-20180516_025642_83514473295086673092907.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [...truncated 3 lines...] [junit4] JVM J1: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-BadApples-7.x-Linux/lucene/build/analysis/common/test/temp/junit4-J1-20180516_025642_83518297475497425541755.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [...truncated 261 lines...] [junit4] JVM J2: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-BadApples-7.x-Linux/lucene/build/analysis/icu/test/temp/junit4-J2-20180516_025809_89715872878883994530572.syserr [junit4] >>> JVM J2 emitted unexpected output (verbatim) [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J2: EOF [junit4] JVM J1:
[JENKINS] Lucene-Solr-BadApples-master-Linux (64bit/jdk-9.0.4) - Build # 37 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-master-Linux/37/ Java: 64bit/jdk-9.0.4 -XX:+UseCompressedOops -XX:+UseSerialGC All tests passed Build Log: [...truncated 7245 lines...] [javac] Compiling 13 source files to /home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/lucene/build/demo/classes/java [javac] /home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:46: error: cannot find symbol [javac] import org.apache.lucene.queryparser.xml.QueryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: package org.apache.lucene.queryparser.xml [javac] /home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:61: error: cannot find symbol [javac] private QueryTemplateManager queryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] /home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:81: error: cannot find symbol [javac] queryTemplateManager = new QueryTemplateManager( [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] 3 errors BUILD FAILED /home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/build.xml:642: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/build.xml:577: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/build.xml:59: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/lucene/build.xml:493: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/lucene/common-build.xml:2264: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/lucene/module-build.xml:67: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/lucene/module-build.xml:64: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/lucene/common-build.xml:551: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/lucene/common-build.xml:2052: Compile failed; see the compiler error output for details. Total time: 14 minutes 26 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 [WARNINGS] Skipping publisher since build result is FAILURE Recording test results Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-Solaris (64bit/jdk1.8.0) - Build # 625 - Still Failing!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/625/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC All tests passed Build Log: [...truncated 7222 lines...] [javac] Compiling 13 source files to /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/build/demo/classes/java [javac] /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:46: error: cannot find symbol [javac] import org.apache.lucene.queryparser.xml.QueryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: package org.apache.lucene.queryparser.xml [javac] /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:61: error: cannot find symbol [javac] private QueryTemplateManager queryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:81: error: cannot find symbol [javac] queryTemplateManager = new QueryTemplateManager( [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] 3 errors BUILD FAILED /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/build.xml:633: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/build.xml:577: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/build.xml:59: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/build.xml:493: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/common-build.xml:2264: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/module-build.xml:67: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/module-build.xml:64: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/common-build.xml:551: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/common-build.xml:2052: Compile failed; see the compiler error output for details. Total time: 11 minutes 51 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 [WARNINGS] Skipping publisher since build result is FAILURE Recording test results Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 1869 - Still Failing!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1869/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC All tests passed Build Log: [...truncated 7204 lines...] [javac] Compiling 13 source files to /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/build/demo/classes/java [javac] /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:46: error: cannot find symbol [javac] import org.apache.lucene.queryparser.xml.QueryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: package org.apache.lucene.queryparser.xml [javac] /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:61: error: cannot find symbol [javac] private QueryTemplateManager queryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:81: error: cannot find symbol [javac] queryTemplateManager = new QueryTemplateManager( [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] 3 errors BUILD FAILED /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/build.xml:633: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/build.xml:577: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/build.xml:59: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/build.xml:493: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/common-build.xml:2264: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/module-build.xml:67: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/module-build.xml:64: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/common-build.xml:551: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/common-build.xml:2052: Compile failed; see the compiler error output for details. Total time: 13 minutes 2 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 [WARNINGS] Skipping publisher since build result is FAILURE Recording test results Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-MacOSX (64bit/jdk-9) - Build # 644 - Still Failing!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/644/ Java: 64bit/jdk-9 -XX:-UseCompressedOops -XX:+UseParallelGC All tests passed Build Log: [...truncated 7231 lines...] [javac] Compiling 13 source files to /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/build/demo/classes/java [javac] /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:46: error: cannot find symbol [javac] import org.apache.lucene.queryparser.xml.QueryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: package org.apache.lucene.queryparser.xml [javac] /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:61: error: cannot find symbol [javac] private QueryTemplateManager queryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:81: error: cannot find symbol [javac] queryTemplateManager = new QueryTemplateManager( [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] 3 errors BUILD FAILED /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/build.xml:633: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/build.xml:577: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/build.xml:59: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/build.xml:493: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/common-build.xml:2264: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/module-build.xml:67: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/module-build.xml:64: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/common-build.xml:551: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/common-build.xml:2052: Compile failed; see the compiler error output for details. Total time: 16 minutes 53 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 [WARNINGS] Skipping publisher since build result is FAILURE Recording test results Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 - 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/jdk-9) - Build # 4634 - Still Failing!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4634/ Java: 64bit/jdk-9 -XX:-UseCompressedOops -XX:+UseG1GC All tests passed Build Log: [...truncated 7207 lines...] [javac] Compiling 13 source files to /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/demo/classes/java [javac] /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:46: error: cannot find symbol [javac] import org.apache.lucene.queryparser.xml.QueryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: package org.apache.lucene.queryparser.xml [javac] /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:61: error: cannot find symbol [javac] private QueryTemplateManager queryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:81: error: cannot find symbol [javac] queryTemplateManager = new QueryTemplateManager( [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] 3 errors BUILD FAILED /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/build.xml:633: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/build.xml:577: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/build.xml:59: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build.xml:493: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/common-build.xml:2264: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/module-build.xml:67: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/module-build.xml:64: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/common-build.xml:551: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/common-build.xml:2052: Compile failed; see the compiler error output for details. Total time: 20 minutes 58 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 [WARNINGS] Skipping publisher since build result is FAILURE Recording test results Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6733) Umbrella issue - Solr as a standalone application
[ https://issues.apache.org/jira/browse/SOLR-6733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476715#comment-16476715 ] Shawn Heisey commented on SOLR-6733: [~dsmiley], most of that is covered in the discussion on the WhyNoWar wiki page: https://wiki.apache.org/solr/WhyNoWar The more of the server config that we can control in our own code and not leave up to other people's code and configuration, the better off we'll be. At the moment, we can't implement much of anything at the server/container level, because Solr is self-contained within its webapp. With an embedded container, we would be able to do almost anything. I'm still very enamored by the idea in the subtask on this issue -- SOLR-6734. I think it would be a lot easier to implement that idea if Solr were its own self-contained application, instead of being started as a stripped-down but otherwise unmodified Jetty. I'm aware that there's a significant amount of work required to implement this issue. It is my hope that a lot of the work would fall on my shoulders, but I also know that I will need help, and might find myself very much out of my depth. [~arafalov], Solr's code, especially the tests, is already pretty well attached to Jetty. Switching to another container (undertow, tomcat, etc) or a completely different framework (Netty, Spring Boot, etc) would require a lot more work than embedding Jetty. If there are tangible and easily-realized benefits to a switch, then I'm not opposed to it ... but those benefits would have to be pretty significant and difficult/impossible with Jetty. > Umbrella issue - Solr as a standalone application > - > > Key: SOLR-6733 > URL: https://issues.apache.org/jira/browse/SOLR-6733 > Project: Solr > Issue Type: New Feature >Reporter: Shawn Heisey >Priority: Major > > Umbrella issue. > Solr should be a standalone application, where the main method is provided by > Solr source code. > Here are the major tasks I envision, if we choose to embed Jetty: > * Create org.apache.solr.start.Main (and possibly other classes in the same > package), to be placed in solr-start.jar. The Main class will contain the > main method that starts the embedded Jetty and Solr. I do not know how to > adjust the build system to do this successfully. > * Handle central configurations in code -- TCP port, SSL, and things like > web.xml. > * For each of these steps, clean up any test fallout. > * Handle cloud-related configurations in code -- port, hostname, protocol, > etc. Use the same information as the central configurations. > * Consider whether things like authentication need changes. > * Handle any remaining container configurations. > I am currently imagining this work happening in a new branch and ultimately > being applied only to master, not the stable branch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-SmokeRelease-7.3 - Build # 27 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.3/27/ No tests ran. Build Log: [...truncated 30127 lines...] prepare-release-no-sign: [mkdir] Created dir: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.3/lucene/build/smokeTestRelease/dist [copy] Copying 491 files to /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.3/lucene/build/smokeTestRelease/dist/lucene [copy] Copying 230 files to /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.3/lucene/build/smokeTestRelease/dist/solr [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8 [smoker] Java 9 JAVA_HOME=/home/jenkins/tools/java/latest1.9 [smoker] NOTE: output encoding is UTF-8 [smoker] [smoker] Load release URL "file:/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.3/lucene/build/smokeTestRelease/dist/"... [smoker] [smoker] Test Lucene... [smoker] test basics... [smoker] get KEYS [smoker] 0.3 MB in 0.02 sec (13.1 MB/sec) [smoker] check changes HTML... [smoker] download lucene-7.3.1-src.tgz... [smoker] 32.0 MB in 0.08 sec (391.7 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-7.3.1.tgz... [smoker] 73.4 MB in 0.16 sec (473.1 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-7.3.1.zip... [smoker] 83.9 MB in 0.22 sec (390.2 MB/sec) [smoker] verify md5/sha1 digests [smoker] unpack lucene-7.3.1.tgz... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] test demo with 1.8... [smoker] got 6300 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] test demo with 9... [smoker] got 6300 hits for query "lucene" [smoker] checkindex with 9... [smoker] check Lucene's javadoc JAR [smoker] unpack lucene-7.3.1.zip... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] test demo with 1.8... [smoker] got 6300 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] test demo with 9... [smoker] got 6300 hits for query "lucene" [smoker] checkindex with 9... [smoker] check Lucene's javadoc JAR [smoker] unpack lucene-7.3.1-src.tgz... [smoker] make sure no JARs/WARs in src dist... [smoker] run "ant validate" [smoker] run tests w/ Java 8 and testArgs='-Dtests.badapples=false -Dtests.slow=false'... [smoker] test demo with 1.8... [smoker] got 217 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] generate javadocs w/ Java 8... [smoker] [smoker] Crawl/parse... [smoker] [smoker] Verify... [smoker] run tests w/ Java 9 and testArgs='-Dtests.badapples=false -Dtests.slow=false'... [smoker] [smoker] command "export JAVA_HOME="/home/jenkins/tools/java/latest1.9" PATH="/home/jenkins/tools/java/latest1.9/bin:$PATH" JAVACMD="/home/jenkins/tools/java/latest1.9/bin/java"; ant clean test -Dtests.badapples=false -Dtests.slow=false" failed: [smoker] Buildfile: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.3/lucene/build/smokeTestRelease/tmp/unpack/lucene-7.3.1/build.xml [smoker] [smoker] clean: [smoker][delete] Deleting directory /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.3/lucene/build/smokeTestRelease/tmp/unpack/lucene-7.3.1/build [smoker] [smoker] ivy-availability-check: [smoker] [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. [smoker] [smoker] -ivy-fail-disallowed-ivy-version: [smoker] [smoker] ivy-fail: [smoker] [smoker] ivy-configure: [smoker] [ivy:configure] :: Apache Ivy 2.4.0 - 20141213170938 :: http://ant.apache.org/ivy/ :: [smoker] [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.3/lucene/build/smokeTestRelease/tmp/unpack/lucene-7.3.1/top-level-ivy-settings.xml [smoker] [smoker] -clover.load: [smoker] [smoker] resolve-groovy: [smoker] [ivy:cachepath] :: resolving dependencies :: org.codehaus.groovy#groovy-all-caller;working [smoker] [ivy:cachepath] confs: [default] [smoker] [ivy:cachepath] found org.codehaus.groovy#groovy-all;2.4.13 in public [smoker] [ivy:cachepath] :: resolution report :: resolve 942ms :: artifacts dl 2ms [smoker] - [smoker] | |modules|| artifacts | [smoker] | conf | number| search|dwnlded|evicted|| number|dwnlded| [smoker] - [smoker] | default | 1 | 0 | 0 | 0 || 1 | 0 | [smoker]
[JENKINS-EA] Lucene-Solr-7.x-Windows (64bit/jdk-11-ea+5) - Build # 591 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/591/ Java: 64bit/jdk-11-ea+5 -XX:+UseCompressedOops -XX:+UseG1GC All tests passed Build Log: [...truncated 7271 lines...] [javac] Compiling 13 source files to C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\demo\classes\java [javac] C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\demo\src\java\org\apache\lucene\demo\xmlparser\FormBasedXmlQueryDemo.java:46: error: cannot find symbol [javac] import org.apache.lucene.queryparser.xml.QueryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: package org.apache.lucene.queryparser.xml [javac] C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\demo\src\java\org\apache\lucene\demo\xmlparser\FormBasedXmlQueryDemo.java:61: error: cannot find symbol [javac] private QueryTemplateManager queryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\demo\src\java\org\apache\lucene\demo\xmlparser\FormBasedXmlQueryDemo.java:81: error: cannot find symbol [javac] queryTemplateManager = new QueryTemplateManager( [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] 3 errors BUILD FAILED C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\build.xml:633: The following error occurred while executing this line: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\build.xml:577: The following error occurred while executing this line: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\build.xml:59: The following error occurred while executing this line: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build.xml:493: The following error occurred while executing this line: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\common-build.xml:2264: The following error occurred while executing this line: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\module-build.xml:67: The following error occurred while executing this line: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\module-build.xml:64: The following error occurred while executing this line: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\common-build.xml:551: The following error occurred while executing this line: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\common-build.xml:2052: Compile failed; see the compiler error output for details. Total time: 20 minutes 35 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Setting ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2 [WARNINGS] Skipping publisher since build result is FAILURE Recording test results Setting ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any Setting ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2 Setting ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2 Setting ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2 Setting ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk1.8.0_162) - Build # 1908 - Still Failing!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1908/ Java: 64bit/jdk1.8.0_162 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 7249 lines...] [javac] Compiling 13 source files to /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/demo/classes/java [javac] /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:46: error: cannot find symbol [javac] import org.apache.lucene.queryparser.xml.QueryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: package org.apache.lucene.queryparser.xml [javac] /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:61: error: cannot find symbol [javac] private QueryTemplateManager queryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:81: error: cannot find symbol [javac] queryTemplateManager = new QueryTemplateManager( [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] 3 errors BUILD FAILED /home/jenkins/workspace/Lucene-Solr-7.x-Linux/build.xml:633: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/build.xml:577: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/build.xml:59: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build.xml:493: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/common-build.xml:2264: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/module-build.xml:67: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/module-build.xml:64: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/common-build.xml:551: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/common-build.xml:2052: Compile failed; see the compiler error output for details. Total time: 17 minutes 47 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 [WARNINGS] Skipping publisher since build result is FAILURE Recording test results Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-Solaris (64bit/jdk1.8.0) - Build # 624 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/624/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC All tests passed Build Log: [...truncated 7224 lines...] [javac] Compiling 13 source files to /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/build/demo/classes/java [javac] /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:46: error: cannot find symbol [javac] import org.apache.lucene.queryparser.xml.QueryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: package org.apache.lucene.queryparser.xml [javac] /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:61: error: cannot find symbol [javac] private QueryTemplateManager queryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:81: error: cannot find symbol [javac] queryTemplateManager = new QueryTemplateManager( [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] 3 errors BUILD FAILED /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/build.xml:633: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/build.xml:577: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/build.xml:59: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/build.xml:493: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/common-build.xml:2264: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/module-build.xml:67: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/module-build.xml:64: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/common-build.xml:551: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/common-build.xml:2052: Compile failed; see the compiler error output for details. Total time: 16 minutes 19 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 [WARNINGS] Skipping publisher since build result is FAILURE Recording test results Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12360) ImplicitSnitchTest.testGetTags_with_wrong_ipv4_format_ip_returns_nothing sometimes fails
Tomás Fernández Löbbe created SOLR-12360: Summary: ImplicitSnitchTest.testGetTags_with_wrong_ipv4_format_ip_returns_nothing sometimes fails Key: SOLR-12360 URL: https://issues.apache.org/jira/browse/SOLR-12360 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: Tests Reporter: Tomás Fernández Löbbe {noformat} [junit4]> Throwable #1: java.lang.AssertionError: [junit4]> Expected: is <0> [junit4]> got: <1> [junit4]>at org.apache.solr.cloud.rule.ImplicitSnitchTest.testGetTags_with_wrong_ipv4_format_ip_returns_nothing(ImplicitSnitchTest.java:104) {noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_162) - Build # 22016 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/22016/ Java: 32bit/jdk1.8.0_162 -client -XX:+UseG1GC All tests passed Build Log: [...truncated 7242 lines...] [javac] Compiling 13 source files to /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/demo/classes/java [javac] /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:46: error: cannot find symbol [javac] import org.apache.lucene.queryparser.xml.QueryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: package org.apache.lucene.queryparser.xml [javac] /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:61: error: cannot find symbol [javac] private QueryTemplateManager queryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:81: error: cannot find symbol [javac] queryTemplateManager = new QueryTemplateManager( [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] 3 errors BUILD FAILED /home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:633: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:577: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:59: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build.xml:493: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/common-build.xml:2264: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/module-build.xml:67: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/module-build.xml:64: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/common-build.xml:551: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/common-build.xml:2052: Compile failed; see the compiler error output for details. Total time: 22 minutes 29 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 [WARNINGS] Skipping publisher since build result is FAILURE Recording test results Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 1868 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1868/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC All tests passed Build Log: [...truncated 7204 lines...] [javac] Compiling 13 source files to /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/build/demo/classes/java [javac] /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:46: error: cannot find symbol [javac] import org.apache.lucene.queryparser.xml.QueryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: package org.apache.lucene.queryparser.xml [javac] /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:61: error: cannot find symbol [javac] private QueryTemplateManager queryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:81: error: cannot find symbol [javac] queryTemplateManager = new QueryTemplateManager( [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] 3 errors BUILD FAILED /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/build.xml:633: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/build.xml:577: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/build.xml:59: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/build.xml:493: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/common-build.xml:2264: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/module-build.xml:67: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/module-build.xml:64: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/common-build.xml:551: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/common-build.xml:2052: Compile failed; see the compiler error output for details. Total time: 14 minutes 51 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 [WARNINGS] Skipping publisher since build result is FAILURE Recording test results Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-MacOSX (64bit/jdk1.8.0) - Build # 643 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/643/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC All tests passed Build Log: [...truncated 7218 lines...] [javac] Compiling 13 source files to /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/build/demo/classes/java [javac] /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:46: error: cannot find symbol [javac] import org.apache.lucene.queryparser.xml.QueryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: package org.apache.lucene.queryparser.xml [javac] /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:61: error: cannot find symbol [javac] private QueryTemplateManager queryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:81: error: cannot find symbol [javac] queryTemplateManager = new QueryTemplateManager( [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] 3 errors BUILD FAILED /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/build.xml:633: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/build.xml:577: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/build.xml:59: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/build.xml:493: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/common-build.xml:2264: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/module-build.xml:67: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/module-build.xml:64: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/common-build.xml:551: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/common-build.xml:2052: Compile failed; see the compiler error output for details. Total time: 14 minutes 43 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 [WARNINGS] Skipping publisher since build result is FAILURE Recording test results Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.3-Linux (64bit/jdk-10) - Build # 232 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.3-Linux/232/ Java: 64bit/jdk-10 -XX:-UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.cloud.TestPullReplica.testKillLeader Error Message: Replica core_node4 not up to date after 10 seconds expected:<1> but was:<0> Stack Trace: java.lang.AssertionError: Replica core_node4 not up to date after 10 seconds expected:<1> but was:<0> at __randomizedtesting.SeedInfo.seed([1E066924BF884ED9:57109D90DD33DA8F]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.apache.solr.cloud.TestPullReplica.waitForNumDocsInAllReplicas(TestPullReplica.java:538) at org.apache.solr.cloud.TestPullReplica.waitForNumDocsInAllReplicas(TestPullReplica.java:529) at org.apache.solr.cloud.TestPullReplica.doTestNoLeader(TestPullReplica.java:399) at org.apache.solr.cloud.TestPullReplica.testKillLeader(TestPullReplica.java:305) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) 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:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 4633 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4633/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC All tests passed Build Log: [...truncated 7204 lines...] [javac] Compiling 13 source files to /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/demo/classes/java [javac] /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:46: error: cannot find symbol [javac] import org.apache.lucene.queryparser.xml.QueryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: package org.apache.lucene.queryparser.xml [javac] /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:61: error: cannot find symbol [javac] private QueryTemplateManager queryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:81: error: cannot find symbol [javac] queryTemplateManager = new QueryTemplateManager( [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] 3 errors BUILD FAILED /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/build.xml:633: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/build.xml:577: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/build.xml:59: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build.xml:493: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/common-build.xml:2264: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/module-build.xml:67: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/module-build.xml:64: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/common-build.xml:551: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/common-build.xml:2052: Compile failed; see the compiler error output for details. Total time: 17 minutes 9 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 [WARNINGS] Skipping publisher since build result is FAILURE Recording test results Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12358) Autoscaling suggestions fail randomly and for certain policies
[ https://issues.apache.org/jira/browse/SOLR-12358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry Bao updated SOLR-12358: - Priority: Critical (was: Major) > Autoscaling suggestions fail randomly and for certain policies > -- > > Key: SOLR-12358 > URL: https://issues.apache.org/jira/browse/SOLR-12358 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.3.1 >Reporter: Jerry Bao >Priority: Critical > > For the following policy > {code:java} > {"replica": "<3", "node": "#ANY", "collection": "collection"}{code} > the suggestions endpoint fails > {code:java} > "error": {"msg": "Comparison method violates its general contract!","trace": > "java.lang.IllegalArgumentException: Comparison method violates its general > contract!\n\tat java.util.TimSort.mergeHi(TimSort.java:899)\n\tat > java.util.TimSort.mergeAt(TimSort.java:516)\n\tat > java.util.TimSort.mergeCollapse(TimSort.java:441)\n\tat > java.util.TimSort.sort(TimSort.java:245)\n\tat > java.util.Arrays.sort(Arrays.java:1512)\n\tat > java.util.ArrayList.sort(ArrayList.java:1462)\n\tat > java.util.Collections.sort(Collections.java:175)\n\tat > org.apache.solr.client.solrj.cloud.autoscaling.Policy.setApproxValuesAndSortNodes(Policy.java:363)\n\tat > > org.apache.solr.client.solrj.cloud.autoscaling.Policy$Session.applyRules(Policy.java:310)\n\tat > > org.apache.solr.client.solrj.cloud.autoscaling.Policy$Session.(Policy.java:272)\n\tat > > org.apache.solr.client.solrj.cloud.autoscaling.Policy.createSession(Policy.java:376)\n\tat > > org.apache.solr.client.solrj.cloud.autoscaling.PolicyHelper.getSuggestions(PolicyHelper.java:214)\n\tat > > org.apache.solr.cloud.autoscaling.AutoScalingHandler.handleSuggestions(AutoScalingHandler.java:158)\n\tat > > org.apache.solr.cloud.autoscaling.AutoScalingHandler.handleRequestBody(AutoScalingHandler.java:133)\n\tat > > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:195)\n\tat > org.apache.solr.api.ApiBag$ReqHandlerToApi.call(ApiBag.java:242)\n\tat > org.apache.solr.api.V2HttpCall.handleAdmin(V2HttpCall.java:311)\n\tat > org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:717)\n\tat > org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:498)\n\tat > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:384)\n\tat > > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:330)\n\tat > > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1629)\n\tat > > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat > > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n\tat > > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat > > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat > > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:190)\n\tat > > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)\n\tat > > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)\n\tat > > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253)\n\tat > > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168)\n\tat > > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)\n\tat > > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)\n\tat > > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:166)\n\tat > > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1155)\n\tat > > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\n\tat > > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)\n\tat > > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat > > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat > > org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat > > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat > org.eclipse.jetty.server.Server.handle(Server.java:530)\n\tat > org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:347)\n\tat > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:256)\n\tat > > org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)\n\tat > org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)\n\tat
[JENKINS] Lucene-Solr-7.3-Windows (64bit/jdk-9.0.4) - Build # 55 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.3-Windows/55/ Java: 64bit/jdk-9.0.4 -XX:+UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestCloudRecovery Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_79938376EF6BFE62-001\tempDir-001\node1\collection1_shard1_replica_n2\data\tlog\tlog.001: java.nio.file.FileSystemException: C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_79938376EF6BFE62-001\tempDir-001\node1\collection1_shard1_replica_n2\data\tlog\tlog.001: The process cannot access the file because it is being used by another process. C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_79938376EF6BFE62-001\tempDir-001\node1\collection1_shard1_replica_n2\data\tlog: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_79938376EF6BFE62-001\tempDir-001\node1\collection1_shard1_replica_n2\data\tlog C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_79938376EF6BFE62-001\tempDir-001\node1\collection1_shard1_replica_n2\data: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_79938376EF6BFE62-001\tempDir-001\node1\collection1_shard1_replica_n2\data C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_79938376EF6BFE62-001\tempDir-001\node1\collection1_shard1_replica_n2: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_79938376EF6BFE62-001\tempDir-001\node1\collection1_shard1_replica_n2 C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_79938376EF6BFE62-001\tempDir-001\node1\collection1_shard2_replica_n4\data\tlog\tlog.001: java.nio.file.FileSystemException: C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_79938376EF6BFE62-001\tempDir-001\node1\collection1_shard2_replica_n4\data\tlog\tlog.001: The process cannot access the file because it is being used by another process. C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_79938376EF6BFE62-001\tempDir-001\node1\collection1_shard2_replica_n4\data\tlog: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_79938376EF6BFE62-001\tempDir-001\node1\collection1_shard2_replica_n4\data\tlog C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_79938376EF6BFE62-001\tempDir-001\node1\collection1_shard2_replica_n4\data: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_79938376EF6BFE62-001\tempDir-001\node1\collection1_shard2_replica_n4\data C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_79938376EF6BFE62-001\tempDir-001\node1\collection1_shard2_replica_n4: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_79938376EF6BFE62-001\tempDir-001\node1\collection1_shard2_replica_n4 C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_79938376EF6BFE62-001\tempDir-001\node1: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_79938376EF6BFE62-001\tempDir-001\node1 C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_79938376EF6BFE62-001\tempDir-001\node2\collection1_shard1_replica_n1\data\tlog\tlog.001: java.nio.file.FileSystemException: C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_79938376EF6BFE62-001\tempDir-001\node2\collection1_shard1_replica_n1\data\tlog\tlog.001: The process cannot access the file because it is being used by another process.
[jira] [Commented] (SOLR-6733) Umbrella issue - Solr as a standalone application
[ https://issues.apache.org/jira/browse/SOLR-6733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476607#comment-16476607 ] David Smiley commented on SOLR-6733: What is the point of this issue? (Why) What positive benefit? > Umbrella issue - Solr as a standalone application > - > > Key: SOLR-6733 > URL: https://issues.apache.org/jira/browse/SOLR-6733 > Project: Solr > Issue Type: New Feature >Reporter: Shawn Heisey >Priority: Major > > Umbrella issue. > Solr should be a standalone application, where the main method is provided by > Solr source code. > Here are the major tasks I envision, if we choose to embed Jetty: > * Create org.apache.solr.start.Main (and possibly other classes in the same > package), to be placed in solr-start.jar. The Main class will contain the > main method that starts the embedded Jetty and Solr. I do not know how to > adjust the build system to do this successfully. > * Handle central configurations in code -- TCP port, SSL, and things like > web.xml. > * For each of these steps, clean up any test fallout. > * Handle cloud-related configurations in code -- port, hostname, protocol, > etc. Use the same information as the central configurations. > * Consider whether things like authentication need changes. > * Handle any remaining container configurations. > I am currently imagining this work happening in a new branch and ultimately > being applied only to master, not the stable branch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12356) Always auto-create ".system" collection when in SolrCloud mode
[ https://issues.apache.org/jira/browse/SOLR-12356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476603#comment-16476603 ] Noble Paul commented on SOLR-12356: --- I would say we should create it only during first-use. if a POST request is made to the {{.system}} collection, the collection is created, if not present. Similarly, even if a GET request is performed on {{.system}} collection, we can auto create it > Always auto-create ".system" collection when in SolrCloud mode > -- > > Key: SOLR-12356 > URL: https://issues.apache.org/jira/browse/SOLR-12356 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Andrzej Bialecki >Priority: Major > > The {{.system}} collection is currently used for blobs, and in SolrCloud mode > it's also used for autoscaling history and as a metrics history store > (SOLR-11779). It should be automatically created on Overseer start if it's > missing. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12359) LIR requests fail when basic auth is used
Noble Paul created SOLR-12359: - Summary: LIR requests fail when basic auth is used Key: SOLR-12359 URL: https://issues.apache.org/jira/browse/SOLR-12359 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: security Reporter: Noble Paul Assignee: Noble Paul -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk-10) - Build # 1907 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1907/ Java: 64bit/jdk-10 -XX:+UseCompressedOops -XX:+UseParallelGC All tests passed Build Log: [...truncated 7264 lines...] [javac] Compiling 13 source files to /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/demo/classes/java [javac] /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:46: error: cannot find symbol [javac] import org.apache.lucene.queryparser.xml.QueryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: package org.apache.lucene.queryparser.xml [javac] /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:61: error: cannot find symbol [javac] private QueryTemplateManager queryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/demo/src/java/org/apache/lucene/demo/xmlparser/FormBasedXmlQueryDemo.java:81: error: cannot find symbol [javac] queryTemplateManager = new QueryTemplateManager( [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] 3 errors BUILD FAILED /home/jenkins/workspace/Lucene-Solr-7.x-Linux/build.xml:633: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/build.xml:577: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/build.xml:59: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build.xml:493: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/common-build.xml:2264: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/module-build.xml:67: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/module-build.xml:64: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/common-build.xml:551: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/common-build.xml:2052: Compile failed; see the compiler error output for details. Total time: 16 minutes 6 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 [WARNINGS] Skipping publisher since build result is FAILURE Recording test results Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12356) Always auto-create ".system" collection when in SolrCloud mode
[ https://issues.apache.org/jira/browse/SOLR-12356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476575#comment-16476575 ] Tomás Fernández Löbbe commented on SOLR-12356: -- Even if this is the default, can there be an opt out? (i.e. a solr.xml config option)? I imagine people upgrading from older versions of Solr that have built their own metrics/scaling may not want this collection around. Features requiring .system collection then should have graceful failures in case of the collection not being there. > Always auto-create ".system" collection when in SolrCloud mode > -- > > Key: SOLR-12356 > URL: https://issues.apache.org/jira/browse/SOLR-12356 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Andrzej Bialecki >Priority: Major > > The {{.system}} collection is currently used for blobs, and in SolrCloud mode > it's also used for autoscaling history and as a metrics history store > (SOLR-11779). It should be automatically created on Overseer start if it's > missing. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-9.0.4) - Build # 7316 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7316/ Java: 64bit/jdk-9.0.4 -XX:+UseCompressedOops -XX:+UseSerialGC All tests passed Build Log: [...truncated 7253 lines...] [javac] Compiling 13 source files to C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\demo\classes\java [javac] C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\demo\src\java\org\apache\lucene\demo\xmlparser\FormBasedXmlQueryDemo.java:46: error: cannot find symbol [javac] import org.apache.lucene.queryparser.xml.QueryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: package org.apache.lucene.queryparser.xml [javac] C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\demo\src\java\org\apache\lucene\demo\xmlparser\FormBasedXmlQueryDemo.java:61: error: cannot find symbol [javac] private QueryTemplateManager queryTemplateManager; [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\demo\src\java\org\apache\lucene\demo\xmlparser\FormBasedXmlQueryDemo.java:81: error: cannot find symbol [javac] queryTemplateManager = new QueryTemplateManager( [javac] ^ [javac] symbol: class QueryTemplateManager [javac] location: class FormBasedXmlQueryDemo [javac] 3 errors BUILD FAILED C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\build.xml:633: The following error occurred while executing this line: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\build.xml:577: The following error occurred while executing this line: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\build.xml:59: The following error occurred while executing this line: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build.xml:493: The following error occurred while executing this line: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\common-build.xml:2264: The following error occurred while executing this line: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\module-build.xml:67: The following error occurred while executing this line: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\module-build.xml:64: The following error occurred while executing this line: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\common-build.xml:551: The following error occurred while executing this line: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\common-build.xml:2052: Compile failed; see the compiler error output for details. Total time: 14 minutes 35 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Setting ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2 [WARNINGS] Skipping publisher since build result is FAILURE Recording test results Setting ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any Setting ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2 Setting ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2 Setting ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2 Setting ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12200) ZkControllerTest failure. Leaking Overseer
[ https://issues.apache.org/jira/browse/SOLR-12200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476538#comment-16476538 ] Tomás Fernández Löbbe commented on SOLR-12200: -- I missed your comment [~mkhludnev]. Patch looks correct to me. Thanks for investigating this > ZkControllerTest failure. Leaking Overseer > -- > > Key: SOLR-12200 > URL: https://issues.apache.org/jira/browse/SOLR-12200 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Major > Attachments: SOLR-12200.patch, SOLR-12200.patch, SOLR-12200.patch, > SOLR-12200.patch, patch-unit-solr_core.zip, tests-failures.txt, > tests-failures.txt.gz, zk.fail.txt.gz > > > Failure seems suspiciously the same. >[junit4] 2> 499919 INFO > (TEST-ZkControllerTest.testReadConfigName-seed#[BC856CC565039E77]) > [n:127.0.0.1:8983_solr] o.a.s.c.Overseer Overseer > (id=73578760132362243-127.0.0.1:8983_solr-n_00) closing >[junit4] 2> 499920 INFO > (OverseerStateUpdate-73578760132362243-127.0.0.1:8983_solr-n_00) [ > ] o.a.s.c.Overseer Overseer Loop exiting : 127.0.0.1:8983_solr >[junit4] 2> 499920 ERROR > (OverseerCollectionConfigSetProcessor-73578760132362243-127.0.0.1:8983_solr-n_00) > [] o.a.s.c.OverseerTaskProcessor Unable to prioritize overseer >[junit4] 2> java.lang.InterruptedException: null >[junit4] 2>at java.lang.Object.wait(Native Method) ~[?:1.8.0_152] >[junit4] 2>at java.lang.Object.wait(Object.java:502) > ~[?:1.8.0_152] >[junit4] 2>at > org.apache.zookeeper.ClientCnxn.submitRequest(ClientCnxn.java:1409) > ~[zookeeper-3.4.11.jar:3.4 > then it spins in SessionExpiredException, all tests pass but suite fails due > to leaking Overseer. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8310) Relax IWs check on pending deletes
[ https://issues.apache.org/jira/browse/LUCENE-8310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476524#comment-16476524 ] Michael McCandless commented on LUCENE-8310: +1 > Relax IWs check on pending deletes > -- > > Key: LUCENE-8310 > URL: https://issues.apache.org/jira/browse/LUCENE-8310 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 7.4, master (8.0) >Reporter: Simon Willnauer >Priority: Major > Fix For: 7.4, master (8.0) > > Attachments: LUCENE-8310.patch, LUCENE-8310.patch, LUCENE-8310.patch, > LUCENE-8310.patch > > > I recently fixed the check in IW to fail if there are pending deletes. After > upgrading to a snapshot I realized the consequences of this check. It made > most of our usage of IW to for instance prepare commit metadata, rollback to > safe commit-points etc. impossible since we have to now busy wait on top of > directory util all deletes are actually gone even though that we can > guarantee that our history always goes forward. ie we are truly append-only > in the sense of never reusing segment generations. The fix that I made was > basically return false from a _checkPendingDeletions_ in a directory wrapper > to work around it. > I do expect this to happen to a lot of lucene users even if they use IW > correctly. My proposal is to make the check in IW a bit more sophisticated > and only fail if there are pending deletes that are in the future from a > generation perspective. We really don't care about files from the past. My > patch checks the segment generation of each pending file which is safe since > that is the same procedure we apply in IndexFileDeleter to inc reference etc. > and only fail if the pending delete is in the future. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12358) Autoscaling suggestions fail randomly and for certain policies
Jerry Bao created SOLR-12358: Summary: Autoscaling suggestions fail randomly and for certain policies Key: SOLR-12358 URL: https://issues.apache.org/jira/browse/SOLR-12358 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 7.3.1 Reporter: Jerry Bao For the following policy {code:java} {"replica": "<3", "node": "#ANY", "collection": "collection"}{code} the suggestions endpoint fails {code:java} "error": {"msg": "Comparison method violates its general contract!","trace": "java.lang.IllegalArgumentException: Comparison method violates its general contract!\n\tat java.util.TimSort.mergeHi(TimSort.java:899)\n\tat java.util.TimSort.mergeAt(TimSort.java:516)\n\tat java.util.TimSort.mergeCollapse(TimSort.java:441)\n\tat java.util.TimSort.sort(TimSort.java:245)\n\tat java.util.Arrays.sort(Arrays.java:1512)\n\tat java.util.ArrayList.sort(ArrayList.java:1462)\n\tat java.util.Collections.sort(Collections.java:175)\n\tat org.apache.solr.client.solrj.cloud.autoscaling.Policy.setApproxValuesAndSortNodes(Policy.java:363)\n\tat org.apache.solr.client.solrj.cloud.autoscaling.Policy$Session.applyRules(Policy.java:310)\n\tat org.apache.solr.client.solrj.cloud.autoscaling.Policy$Session.(Policy.java:272)\n\tat org.apache.solr.client.solrj.cloud.autoscaling.Policy.createSession(Policy.java:376)\n\tat org.apache.solr.client.solrj.cloud.autoscaling.PolicyHelper.getSuggestions(PolicyHelper.java:214)\n\tat org.apache.solr.cloud.autoscaling.AutoScalingHandler.handleSuggestions(AutoScalingHandler.java:158)\n\tat org.apache.solr.cloud.autoscaling.AutoScalingHandler.handleRequestBody(AutoScalingHandler.java:133)\n\tat org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:195)\n\tat org.apache.solr.api.ApiBag$ReqHandlerToApi.call(ApiBag.java:242)\n\tat org.apache.solr.api.V2HttpCall.handleAdmin(V2HttpCall.java:311)\n\tat org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:717)\n\tat org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:498)\n\tat org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:384)\n\tat org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:330)\n\tat org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1629)\n\tat org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n\tat org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:190)\n\tat org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)\n\tat org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)\n\tat org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253)\n\tat org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168)\n\tat org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)\n\tat org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)\n\tat org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:166)\n\tat org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1155)\n\tat org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\n\tat org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)\n\tat org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat org.eclipse.jetty.server.Server.handle(Server.java:530)\n\tat org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:347)\n\tat org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:256)\n\tat org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)\n\tat org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)\n\tat org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124)\n\tat org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:247)\n\tat org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:140)\n\tat org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)\n\tat
[jira] [Resolved] (LUCENE-8291) Possible security issue when parsing XML documents containing external entity references
[ https://issues.apache.org/jira/browse/LUCENE-8291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-8291. --- Resolution: Fixed Removed this utility class. Thanks for reporting! > Possible security issue when parsing XML documents containing external entity > references > > > Key: LUCENE-8291 > URL: https://issues.apache.org/jira/browse/LUCENE-8291 > Project: Lucene - Core > Issue Type: Bug > Components: modules/queryparser >Affects Versions: 7.2.1 >Reporter: Hendrik Saly >Assignee: Uwe Schindler >Priority: Major > Fix For: 7.4, master (8.0) > > Attachments: LUCENE-8291.patch > > > It appears that in QueryTemplateManager.java lines 149 and 198 and in > DOMUtils.java line 204 XML is parsed without disabling external entity > references (XXE). This is described in > [http://cwe.mitre.org/data/definitions/611.html] and possible mitigations are > listed here: > [https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet] > All recent versions of lucene are affected. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8291) Possible security issue when parsing XML documents containing external entity references
[ https://issues.apache.org/jira/browse/LUCENE-8291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476508#comment-16476508 ] ASF subversion and git services commented on LUCENE-8291: - Commit f4fae49f0e6363b38b8898079dd904a364ce332a in lucene-solr's branch refs/heads/branch_7x from [~thetaphi] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f4fae49 ] LUCENE-8291: Remove QueryTemplateManager utility class from XML queryparser > Possible security issue when parsing XML documents containing external entity > references > > > Key: LUCENE-8291 > URL: https://issues.apache.org/jira/browse/LUCENE-8291 > Project: Lucene - Core > Issue Type: Bug > Components: modules/queryparser >Affects Versions: 7.2.1 >Reporter: Hendrik Saly >Assignee: Uwe Schindler >Priority: Major > Fix For: 7.4, master (8.0) > > Attachments: LUCENE-8291.patch > > > It appears that in QueryTemplateManager.java lines 149 and 198 and in > DOMUtils.java line 204 XML is parsed without disabling external entity > references (XXE). This is described in > [http://cwe.mitre.org/data/definitions/611.html] and possible mitigations are > listed here: > [https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet] > All recent versions of lucene are affected. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8291) Possible security issue when parsing XML documents containing external entity references
[ https://issues.apache.org/jira/browse/LUCENE-8291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476507#comment-16476507 ] ASF subversion and git services commented on LUCENE-8291: - Commit 11c6a7ad8824f54fdf61d30579ef9689172253e9 in lucene-solr's branch refs/heads/master from [~thetaphi] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=11c6a7a ] LUCENE-8291: Remove QueryTemplateManager utility class from XML queryparser > Possible security issue when parsing XML documents containing external entity > references > > > Key: LUCENE-8291 > URL: https://issues.apache.org/jira/browse/LUCENE-8291 > Project: Lucene - Core > Issue Type: Bug > Components: modules/queryparser >Affects Versions: 7.2.1 >Reporter: Hendrik Saly >Assignee: Uwe Schindler >Priority: Major > Fix For: 7.4, master (8.0) > > Attachments: LUCENE-8291.patch > > > It appears that in QueryTemplateManager.java lines 149 and 198 and in > DOMUtils.java line 204 XML is parsed without disabling external entity > references (XXE). This is described in > [http://cwe.mitre.org/data/definitions/611.html] and possible mitigations are > listed here: > [https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet] > All recent versions of lucene are affected. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12200) ZkControllerTest failure. Leaking Overseer
[ https://issues.apache.org/jira/browse/SOLR-12200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476474#comment-16476474 ] Mikhail Khludnev commented on SOLR-12200: - https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-7.x/59/testReport/junit/junit.framework/TestSuite/org_apache_solr_cloud_ZkControllerTest/ > ZkControllerTest failure. Leaking Overseer > -- > > Key: SOLR-12200 > URL: https://issues.apache.org/jira/browse/SOLR-12200 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Major > Attachments: SOLR-12200.patch, SOLR-12200.patch, SOLR-12200.patch, > SOLR-12200.patch, patch-unit-solr_core.zip, tests-failures.txt, > tests-failures.txt.gz, zk.fail.txt.gz > > > Failure seems suspiciously the same. >[junit4] 2> 499919 INFO > (TEST-ZkControllerTest.testReadConfigName-seed#[BC856CC565039E77]) > [n:127.0.0.1:8983_solr] o.a.s.c.Overseer Overseer > (id=73578760132362243-127.0.0.1:8983_solr-n_00) closing >[junit4] 2> 499920 INFO > (OverseerStateUpdate-73578760132362243-127.0.0.1:8983_solr-n_00) [ > ] o.a.s.c.Overseer Overseer Loop exiting : 127.0.0.1:8983_solr >[junit4] 2> 499920 ERROR > (OverseerCollectionConfigSetProcessor-73578760132362243-127.0.0.1:8983_solr-n_00) > [] o.a.s.c.OverseerTaskProcessor Unable to prioritize overseer >[junit4] 2> java.lang.InterruptedException: null >[junit4] 2>at java.lang.Object.wait(Native Method) ~[?:1.8.0_152] >[junit4] 2>at java.lang.Object.wait(Object.java:502) > ~[?:1.8.0_152] >[junit4] 2>at > org.apache.zookeeper.ClientCnxn.submitRequest(ClientCnxn.java:1409) > ~[zookeeper-3.4.11.jar:3.4 > then it spins in SessionExpiredException, all tests pass but suite fails due > to leaking Overseer. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6734) Standalone solr as *two* applications -- Solr and a controlling agent
[ https://issues.apache.org/jira/browse/SOLR-6734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476466#comment-16476466 ] Shawn Heisey commented on SOLR-6734: The dynamic reconfig capability in ZK 3.5 could perhaps be used by an agent process to help build ensembles in a way that's better automated than can happen currently. Have to look into it and ask dumb questions on the ZK mailing list! > Standalone solr as *two* applications -- Solr and a controlling agent > - > > Key: SOLR-6734 > URL: https://issues.apache.org/jira/browse/SOLR-6734 > Project: Solr > Issue Type: Sub-task >Reporter: Shawn Heisey >Priority: Major > > In a message to the dev list outlining reasons to switch from a webapp to a > standalone app, Mark Miller included the idea of making Solr into two > applications, rather than just one. There would be Solr itself, and an agent > to control Solr. > http://mail-archives.apache.org/mod_mbox/lucene-dev/201305.mbox/%3C807476C6-E4C3-4E7E-9F67-2BECB63990DE%40gmail.com%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.3-Linux (64bit/jdk-9.0.4) - Build # 231 - Unstable!
Error processing tokens: Error while parsing action 'Text/ZeroOrMore/FirstOf/Token/DelimitedToken/DelimitedToken_Action3' at input position (line 79, pos 4): )"} ^ java.lang.OutOfMemoryError: Java heap space - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 1867 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1867/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC 8 tests failed. FAILED: org.apache.solr.cloud.api.collections.TestCollectionAPI.test Error Message: Aliases should not be null Stack Trace: java.lang.AssertionError: Aliases should not be null at __randomizedtesting.SeedInfo.seed([D81F5E37101E2E9B:504B61EDBEE24363]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNotNull(Assert.java:526) at org.apache.solr.cloud.api.collections.TestCollectionAPI.clusterStatusAliasTest(TestCollectionAPI.java:320) at org.apache.solr.cloud.api.collections.TestCollectionAPI.test(TestCollectionAPI.java:88) 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:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968) 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:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at
[jira] [Commented] (SOLR-6733) Umbrella issue - Solr as a standalone application
[ https://issues.apache.org/jira/browse/SOLR-6733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476422#comment-16476422 ] Alexandre Rafalovitch commented on SOLR-6733: - What about that Undertow work already done before? [https://github.com/kohesive/solr-undertow] Seems like worth at least a fresh look to see if there were lessons learned in the parallel 2.5 years. [~jayson.minard]? > Umbrella issue - Solr as a standalone application > - > > Key: SOLR-6733 > URL: https://issues.apache.org/jira/browse/SOLR-6733 > Project: Solr > Issue Type: New Feature >Reporter: Shawn Heisey >Priority: Major > > Umbrella issue. > Solr should be a standalone application, where the main method is provided by > Solr source code. > Here are the major tasks I envision, if we choose to embed Jetty: > * Create org.apache.solr.start.Main (and possibly other classes in the same > package), to be placed in solr-start.jar. The Main class will contain the > main method that starts the embedded Jetty and Solr. I do not know how to > adjust the build system to do this successfully. > * Handle central configurations in code -- TCP port, SSL, and things like > web.xml. > * For each of these steps, clean up any test fallout. > * Handle cloud-related configurations in code -- port, hostname, protocol, > etc. Use the same information as the central configurations. > * Consider whether things like authentication need changes. > * Handle any remaining container configurations. > I am currently imagining this work happening in a new branch and ultimately > being applied only to master, not the stable branch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-11779) Basic long-term collection of aggregated metrics
[ https://issues.apache.org/jira/browse/SOLR-11779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16475818#comment-16475818 ] Andrzej Bialecki edited comment on SOLR-11779 at 5/15/18 8:08 PM: --- Each RRD database takes ~36kB (edit: 11kB per metric, 3 related metrics in a db) in the configuration proposed in the patch, which consists of 5 time-series: * 240 samples 60 sec apart (4 hours) * 288 samples 600 sec apart (48 hours) * 336 samples 1h apart (2 weeks) * 180 samples 4h apart (2 months) * 365 samples 1 day apart (1 year) I'll attach example screenshots of graphs generated using {{/admin/metrics/history}} handler. Graphs are sent as base64-encoded PNG data, so they could be directly used by the UI in a data URI like this: {{data:image/png;base64,iVBORw0KG...}}. was (Author: ab): Each RRD database takes ~30kB (edit: 8kB per metric, 3 related metrics in a db) in the configuration proposed in the patch, which consists of 5 time-series: * 240 samples 60 sec apart (4 hours) * 288 samples 600 sec apart (48 hours) * 336 samples 1h apart (2 weeks) * 180 samples 4h apart (2 months) * 365 samples 1 day apart (1 year) I'll attach example screenshots of graphs generated using {{/admin/metrics/history}} handler. Graphs are sent as base64-encoded PNG data, so they could be directly used by the UI in a data URI like this: {{data:image/png;base64,iVBORw0KG...}}. > Basic long-term collection of aggregated metrics > > > Key: SOLR-11779 > URL: https://issues.apache.org/jira/browse/SOLR-11779 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Affects Versions: 7.3, master (8.0) >Reporter: Andrzej Bialecki >Assignee: Andrzej Bialecki >Priority: Major > Attachments: SOLR-11779.patch, SOLR-11779.patch, c1.png, c2.png, > core.json, d1.png, d2.png, d3.png, jvm-list.json, jvm-string.json, jvm.json, > o1.png, u1.png > > > Tracking the key metrics over time is very helpful in understanding the > cluster and user behavior. > Currently even basic metrics tracking requires setting up an external system > and either polling {{/admin/metrics}} or using {{SolrMetricReporter}}-s. The > advantage of this setup is that these external tools usually provide a lot of > sophisticated functionality. The downside is that they don't ship out of the > box with Solr and require additional admin effort to set up. > Solr could collect some of the key metrics and keep their historical values > in a round-robin database (eg. using RRD4j) to keep the size of the historic > data constant (eg. ~64kB per metric), but at the same providing out of the > box useful insights into the basic system behavior over time. This data could > be persisted to the {{.system}} collection as blobs, and it could be also > presented in the Admin UI as graphs. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-11779) Basic long-term collection of aggregated metrics
[ https://issues.apache.org/jira/browse/SOLR-11779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16475818#comment-16475818 ] Andrzej Bialecki edited comment on SOLR-11779 at 5/15/18 8:07 PM: --- Each RRD database takes ~30kB (edit: 8kB per metric, 3 related metrics in a db) in the configuration proposed in the patch, which consists of 5 time-series: * 240 samples 60 sec apart (4 hours) * 288 samples 600 sec apart (48 hours) * 336 samples 1h apart (2 weeks) * 180 samples 4h apart (2 months) * 365 samples 1 day apart (1 year) I'll attach example screenshots of graphs generated using {{/admin/metrics/history}} handler. Graphs are sent as base64-encoded PNG data, so they could be directly used by the UI in a data URI like this: {{data:image/png;base64,iVBORw0KG...}}. was (Author: ab): Each RRD database takes ~30kB (edit: 8kB per metric, 3 related metrics in a db) in the configuration proposed in the patch, which consists of 4 time-series: * 240 samples 60 sec apart (4 hours) * 288 samples 600 sec apart (48 hours) * 336 samples 1h apart (2 weeks) * 180 samples 4h apart (2 months) I'll attach example screenshots of graphs generated using {{/admin/metrics/history}} handler. Graphs are sent as base64-encoded PNG data, so they could be directly used by the UI in a data URI like this: {{data:image/png;base64,iVBORw0KG...}}. > Basic long-term collection of aggregated metrics > > > Key: SOLR-11779 > URL: https://issues.apache.org/jira/browse/SOLR-11779 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Affects Versions: 7.3, master (8.0) >Reporter: Andrzej Bialecki >Assignee: Andrzej Bialecki >Priority: Major > Attachments: SOLR-11779.patch, SOLR-11779.patch, c1.png, c2.png, > core.json, d1.png, d2.png, d3.png, jvm-list.json, jvm-string.json, jvm.json, > o1.png, u1.png > > > Tracking the key metrics over time is very helpful in understanding the > cluster and user behavior. > Currently even basic metrics tracking requires setting up an external system > and either polling {{/admin/metrics}} or using {{SolrMetricReporter}}-s. The > advantage of this setup is that these external tools usually provide a lot of > sophisticated functionality. The downside is that they don't ship out of the > box with Solr and require additional admin effort to set up. > Solr could collect some of the key metrics and keep their historical values > in a round-robin database (eg. using RRD4j) to keep the size of the historic > data constant (eg. ~64kB per metric), but at the same providing out of the > box useful insights into the basic system behavior over time. This data could > be persisted to the {{.system}} collection as blobs, and it could be also > presented in the Admin UI as graphs. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-11779) Basic long-term collection of aggregated metrics
[ https://issues.apache.org/jira/browse/SOLR-11779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16475818#comment-16475818 ] Andrzej Bialecki edited comment on SOLR-11779 at 5/15/18 8:06 PM: --- Each RRD database takes ~30kB (edit: 8kB per metric, 3 related metrics in a db) in the configuration proposed in the patch, which consists of 4 time-series: * 240 samples 60 sec apart (4 hours) * 288 samples 600 sec apart (48 hours) * 336 samples 1h apart (2 weeks) * 180 samples 4h apart (2 months) I'll attach example screenshots of graphs generated using {{/admin/metrics/history}} handler. Graphs are sent as base64-encoded PNG data, so they could be directly used by the UI in a data URI like this: {{data:image/png;base64,iVBORw0KG...}}. was (Author: ab): Each RRD database takes ~30kB in the configuration proposed in the patch, which consists of 4 time-series: * 240 samples 60 sec apart (4 hours) * 288 samples 600 sec apart (48 hours) * 336 samples 1h apart (2 weeks) * 180 samples 4h apart (2 months) I'll attach example screenshots of graphs generated using {{/admin/metrics/history}} handler. Graphs are sent as base64-encoded PNG data, so they could be directly used by the UI in a data URI like this: {{data:image/png;base64,iVBORw0KG...}}. > Basic long-term collection of aggregated metrics > > > Key: SOLR-11779 > URL: https://issues.apache.org/jira/browse/SOLR-11779 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Affects Versions: 7.3, master (8.0) >Reporter: Andrzej Bialecki >Assignee: Andrzej Bialecki >Priority: Major > Attachments: SOLR-11779.patch, SOLR-11779.patch, c1.png, c2.png, > core.json, d1.png, d2.png, d3.png, jvm-list.json, jvm-string.json, jvm.json, > o1.png, u1.png > > > Tracking the key metrics over time is very helpful in understanding the > cluster and user behavior. > Currently even basic metrics tracking requires setting up an external system > and either polling {{/admin/metrics}} or using {{SolrMetricReporter}}-s. The > advantage of this setup is that these external tools usually provide a lot of > sophisticated functionality. The downside is that they don't ship out of the > box with Solr and require additional admin effort to set up. > Solr could collect some of the key metrics and keep their historical values > in a round-robin database (eg. using RRD4j) to keep the size of the historic > data constant (eg. ~64kB per metric), but at the same providing out of the > box useful insights into the basic system behavior over time. This data could > be persisted to the {{.system}} collection as blobs, and it could be also > presented in the Admin UI as graphs. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11779) Basic long-term collection of aggregated metrics
[ https://issues.apache.org/jira/browse/SOLR-11779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476406#comment-16476406 ] Andrzej Bialecki commented on SOLR-11779: -- Updated patch with unit and integration tests. > Basic long-term collection of aggregated metrics > > > Key: SOLR-11779 > URL: https://issues.apache.org/jira/browse/SOLR-11779 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Affects Versions: 7.3, master (8.0) >Reporter: Andrzej Bialecki >Assignee: Andrzej Bialecki >Priority: Major > Attachments: SOLR-11779.patch, SOLR-11779.patch, c1.png, c2.png, > core.json, d1.png, d2.png, d3.png, jvm-list.json, jvm-string.json, jvm.json, > o1.png, u1.png > > > Tracking the key metrics over time is very helpful in understanding the > cluster and user behavior. > Currently even basic metrics tracking requires setting up an external system > and either polling {{/admin/metrics}} or using {{SolrMetricReporter}}-s. The > advantage of this setup is that these external tools usually provide a lot of > sophisticated functionality. The downside is that they don't ship out of the > box with Solr and require additional admin effort to set up. > Solr could collect some of the key metrics and keep their historical values > in a round-robin database (eg. using RRD4j) to keep the size of the historic > data constant (eg. ~64kB per metric), but at the same providing out of the > box useful insights into the basic system behavior over time. This data could > be persisted to the {{.system}} collection as blobs, and it could be also > presented in the Admin UI as graphs. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11779) Basic long-term collection of aggregated metrics
[ https://issues.apache.org/jira/browse/SOLR-11779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrzej Bialecki updated SOLR-11779: - Attachment: SOLR-11779.patch > Basic long-term collection of aggregated metrics > > > Key: SOLR-11779 > URL: https://issues.apache.org/jira/browse/SOLR-11779 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Affects Versions: 7.3, master (8.0) >Reporter: Andrzej Bialecki >Assignee: Andrzej Bialecki >Priority: Major > Attachments: SOLR-11779.patch, SOLR-11779.patch, c1.png, c2.png, > core.json, d1.png, d2.png, d3.png, jvm-list.json, jvm-string.json, jvm.json, > o1.png, u1.png > > > Tracking the key metrics over time is very helpful in understanding the > cluster and user behavior. > Currently even basic metrics tracking requires setting up an external system > and either polling {{/admin/metrics}} or using {{SolrMetricReporter}}-s. The > advantage of this setup is that these external tools usually provide a lot of > sophisticated functionality. The downside is that they don't ship out of the > box with Solr and require additional admin effort to set up. > Solr could collect some of the key metrics and keep their historical values > in a round-robin database (eg. using RRD4j) to keep the size of the historic > data constant (eg. ~64kB per metric), but at the same providing out of the > box useful insights into the basic system behavior over time. This data could > be persisted to the {{.system}} collection as blobs, and it could be also > presented in the Admin UI as graphs. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-12223) Document 'Initial Startup' for bidirectional approach in CDCR
[ https://issues.apache.org/jira/browse/SOLR-12223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett reassigned SOLR-12223: Assignee: Cassandra Targett > Document 'Initial Startup' for bidirectional approach in CDCR > - > > Key: SOLR-12223 > URL: https://issues.apache.org/jira/browse/SOLR-12223 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: CDCR, documentation >Affects Versions: 7.3 >Reporter: Amrit Sarkar >Assignee: Cassandra Targett >Priority: Minor > Fix For: 7.4 > > Attachments: SOLR-12223.patch > > > Add {{Initial Startup}} for bidirectional approach to {{cdcr-config.html}}. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12223) Document 'Initial Startup' for bidirectional approach in CDCR
[ https://issues.apache.org/jira/browse/SOLR-12223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett updated SOLR-12223: - Fix Version/s: 7.4 > Document 'Initial Startup' for bidirectional approach in CDCR > - > > Key: SOLR-12223 > URL: https://issues.apache.org/jira/browse/SOLR-12223 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: CDCR, documentation >Affects Versions: 7.3 >Reporter: Amrit Sarkar >Assignee: Cassandra Targett >Priority: Minor > Fix For: 7.4 > > Attachments: SOLR-12223.patch > > > Add {{Initial Startup}} for bidirectional approach to {{cdcr-config.html}}. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6733) Umbrella issue - Solr as a standalone application
[ https://issues.apache.org/jira/browse/SOLR-6733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476392#comment-16476392 ] Shawn Heisey commented on SOLR-6733: I think that embedding Jetty is the path of least resistance, and least likely to cause heartburn. If there is any desire to switch to some other way of providing http services, it would be best to decide that before doing any work on this. Pluses to embedding Jetty: A lot of the code is already written, and more importantly, debugged. The Jetty community has been really awesome. They respond quickly to requests on their mailing list and IRC channel, with helpful answers. > Umbrella issue - Solr as a standalone application > - > > Key: SOLR-6733 > URL: https://issues.apache.org/jira/browse/SOLR-6733 > Project: Solr > Issue Type: New Feature >Reporter: Shawn Heisey >Priority: Major > > Umbrella issue. > Solr should be a standalone application, where the main method is provided by > Solr source code. > Here are the major tasks I envision, if we choose to embed Jetty: > * Create org.apache.solr.start.Main (and possibly other classes in the same > package), to be placed in solr-start.jar. The Main class will contain the > main method that starts the embedded Jetty and Solr. I do not know how to > adjust the build system to do this successfully. > * Handle central configurations in code -- TCP port, SSL, and things like > web.xml. > * For each of these steps, clean up any test fallout. > * Handle cloud-related configurations in code -- port, hostname, protocol, > etc. Use the same information as the central configurations. > * Consider whether things like authentication need changes. > * Handle any remaining container configurations. > I am currently imagining this work happening in a new branch and ultimately > being applied only to master, not the stable branch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-7960) NGram filters -- preserve the original token when it is outside the min/max size range
[ https://issues.apache.org/jira/browse/LUCENE-7960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476383#comment-16476383 ] Ingomar Wesp edited comment on LUCENE-7960 at 5/15/18 7:40 PM: --- Sorry for not responding earlier*. Looks good to me; however, the logic can be simplified further, now that we don't care about differentiating between the two cases anymore. Unless someone else wants to address this and Robert's other suggestions, I would like to further refine the patch and submit a new one this weekend. *) Even though I'm watching this issue, I'm not getting mails from Jira. Is this intentional for non-commiters? was (Author: iwesp): Sorry for not responding earlier*. Looks good to me; however, the logic can be simplified further, now that we don't care about differentiating between the two cases anymore. Unless someone else wants to address this and Robert's other suggestions, I would like to further refine the patch and submit a new one this weekend. *) Even though I'm watching this issue, I'm not getting mails from Jira. Is this intentional for non-commiters? > NGram filters -- preserve the original token when it is outside the min/max > size range > -- > > Key: LUCENE-7960 > URL: https://issues.apache.org/jira/browse/LUCENE-7960 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Reporter: Shawn Heisey >Priority: Major > Attachments: LUCENE-7960.patch, LUCENE-7960.patch, LUCENE-7960.patch > > Time Spent: 0.5h > Remaining Estimate: 0h > > When ngram or edgengram filters are used, any terms that are shorter than the > minGramSize are completely removed from the token stream. > This is probably 100% what was intended, but I've seen it cause a lot of > problems for users. I am not suggesting that the default behavior be > changed. That would be far too disruptive to the existing user base. > I do think there should be a new boolean option, with a name like > keepShortTerms, that defaults to false, to allow the short terms to be > preserved. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7960) NGram filters -- preserve the original token when it is outside the min/max size range
[ https://issues.apache.org/jira/browse/LUCENE-7960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476383#comment-16476383 ] Ingomar Wesp commented on LUCENE-7960: -- Sorry for not responding earlier*. Looks good to me; however, the logic can be simplified further, now that we don't care about differentiating between the two cases anymore. Unless someone else wants to address this and Robert's other suggestions, I would like to further refine the patch and submit a new one this weekend. *) Even though I'm watching this issue, I'm not getting mails from Jira. Is this intentional for non-commiters? > NGram filters -- preserve the original token when it is outside the min/max > size range > -- > > Key: LUCENE-7960 > URL: https://issues.apache.org/jira/browse/LUCENE-7960 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Reporter: Shawn Heisey >Priority: Major > Attachments: LUCENE-7960.patch, LUCENE-7960.patch, LUCENE-7960.patch > > Time Spent: 0.5h > Remaining Estimate: 0h > > When ngram or edgengram filters are used, any terms that are shorter than the > minGramSize are completely removed from the token stream. > This is probably 100% what was intended, but I've seen it cause a lot of > problems for users. I am not suggesting that the default behavior be > changed. That would be far too disruptive to the existing user base. > I do think there should be a new boolean option, with a name like > keepShortTerms, that defaults to false, to allow the short terms to be > preserved. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6733) Umbrella issue - Solr as a standalone application
[ https://issues.apache.org/jira/browse/SOLR-6733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Heisey updated SOLR-6733: --- Description: Umbrella issue. Solr should be a standalone application, where the main method is provided by Solr source code. Here are the major tasks I envision, if we choose to embed Jetty: * Create org.apache.solr.start.Main (and possibly other classes in the same package), to be placed in solr-start.jar. The Main class will contain the main method that starts the embedded Jetty and Solr. I do not know how to adjust the build system to do this successfully. * Handle central configurations in code -- TCP port, SSL, and things like web.xml. * For each of these steps, clean up any test fallout. * Handle cloud-related configurations in code -- port, hostname, protocol, etc. Use the same information as the central configurations. * Consider whether things like authentication need changes. * Handle any remaining container configurations. I am currently imagining this work happening in a new branch and ultimately being applied only to master, not the stable branch. was:Umbrella issue, for gathering issues relating to smaller pieces required to implement the larger feature where Solr can be run as a completely standalone application, without a servlet container. > Umbrella issue - Solr as a standalone application > - > > Key: SOLR-6733 > URL: https://issues.apache.org/jira/browse/SOLR-6733 > Project: Solr > Issue Type: New Feature >Reporter: Shawn Heisey >Priority: Major > > Umbrella issue. > Solr should be a standalone application, where the main method is provided by > Solr source code. > Here are the major tasks I envision, if we choose to embed Jetty: > * Create org.apache.solr.start.Main (and possibly other classes in the same > package), to be placed in solr-start.jar. The Main class will contain the > main method that starts the embedded Jetty and Solr. I do not know how to > adjust the build system to do this successfully. > * Handle central configurations in code -- TCP port, SSL, and things like > web.xml. > * For each of these steps, clean up any test fallout. > * Handle cloud-related configurations in code -- port, hostname, protocol, > etc. Use the same information as the central configurations. > * Consider whether things like authentication need changes. > * Handle any remaining container configurations. > I am currently imagining this work happening in a new branch and ultimately > being applied only to master, not the stable branch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11752) add gzip to jetty
[ https://issues.apache.org/jira/browse/SOLR-11752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew Sporleder updated SOLR-11752: - Description: with a little bit of typing I am able to add gzip to my solr's jetty, which is a big help for WAN access and completely out-of-band to solr, *and* only happens if the client requests it so I think it is is a good default. I will just inline my code to this ticket: {code:java} #server/etc/jetty-gzip.xml #just download it from here: http://grepcode.com/file/repo1.maven.org/maven2/org.eclipse.jetty/jetty-server/9.3.0.v20150612/etc/jetty-gzip.xml?av=f {code} {code:java} #server/modules/gzip.mod [depend] server [xml] etc/jetty-gzip.xml {code} This is where you might want to add an option, but the result should look like this: {code:java} #bin/solr else SOLR_JETTY_CONFIG+=("--module=http,gzip") fi {code} I can now do this: {code:java} curl -vvv --compressed localhost:8983/solr/ > /dev/null {code} With: {code:java} < Content-Encoding: gzip < Content-Length: 2890 {code} Without: {code:java} < Content-Length: 13349 {code} — A regular query: With: {code:java} < Content-Encoding: gzip < Content-Length: 2876 {code} Without: {code:java} < Content-Length: 17761 {code} was: with a little bit of typing I am able to add gzip to my solr's jetty, which is a big help for SAN access and completely out-of-band to solr, *and* only happens if the client requests it so I think it is is a good default. I will just inline my code to this ticket: {code} #server/etc/jetty-gzip.xml #just download it from here: http://grepcode.com/file/repo1.maven.org/maven2/org.eclipse.jetty/jetty-server/9.3.0.v20150612/etc/jetty-gzip.xml?av=f {code} {code} #server/modules/gzip.mod [depend] server [xml] etc/jetty-gzip.xml {code} This is where you might want to add an option, but the result should look like this: {code} #bin/solr else SOLR_JETTY_CONFIG+=("--module=http,gzip") fi {code} I can now do this: {code} curl -vvv --compressed localhost:8983/solr/ > /dev/null {code} With: {code} < Content-Encoding: gzip < Content-Length: 2890 {code} Without: {code} < Content-Length: 13349 {code} --- A regular query: With: {code} < Content-Encoding: gzip < Content-Length: 2876 {code} Without: {code} < Content-Length: 17761 {code} > add gzip to jetty > - > > Key: SOLR-11752 > URL: https://issues.apache.org/jira/browse/SOLR-11752 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Server >Affects Versions: master (8.0) >Reporter: Matthew Sporleder >Priority: Trivial > Labels: jetty > Attachments: SOLR-11752.patch, SOLR-11752.patch > > > with a little bit of typing I am able to add gzip to my solr's jetty, which > is a big help for WAN access and completely out-of-band to solr, *and* only > happens if the client requests it so I think it is is a good default. > I will just inline my code to this ticket: > {code:java} > #server/etc/jetty-gzip.xml > #just download it from here: > http://grepcode.com/file/repo1.maven.org/maven2/org.eclipse.jetty/jetty-server/9.3.0.v20150612/etc/jetty-gzip.xml?av=f > {code} > {code:java} > #server/modules/gzip.mod > [depend] > server > [xml] > etc/jetty-gzip.xml > {code} > This is where you might want to add an option, but the result should look > like this: > {code:java} > #bin/solr > else > SOLR_JETTY_CONFIG+=("--module=http,gzip") > fi > {code} > I can now do this: > {code:java} > curl -vvv --compressed localhost:8983/solr/ > /dev/null > {code} > With: > {code:java} > < Content-Encoding: gzip > < Content-Length: 2890 > {code} > Without: > {code:java} > < Content-Length: 13349 > {code} > — > A regular query: > With: > {code:java} > < Content-Encoding: gzip > < Content-Length: 2876 > {code} > Without: > {code:java} > < Content-Length: 17761 > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12357) TRA: Pre-emptively create next collection
David Smiley created SOLR-12357: --- Summary: TRA: Pre-emptively create next collection Key: SOLR-12357 URL: https://issues.apache.org/jira/browse/SOLR-12357 Project: Solr Issue Type: Sub-task Security Level: Public (Default Security Level. Issues are Public) Components: SolrCloud Reporter: David Smiley When adding data to a Time Routed Alias (TRA), we sometimes need to create new collections. Today we only do this synchronously – on-demand when a document is coming in. But this can add delays as the documents inbound are held up for a collection to be created. And, there may be a problem like a lack of resources (e.g. ample SolrCloud nodes with space) that the policy framework defines. Such problems could be rectified sooner rather than later assume there is log alerting in place (definitely out of scope here). Pre-emptive TRA collection needs a time window configuration parameter, perhaps named something like "preemptiveCreateWindowMs". If a document's timestamp is within this time window _from the end time of the head/lead collection_ then the collection can be created pre-eptively. If no data is being sent to the TRA, no collections will be auto created, nor will it happen if older data is being added. It may be convenient to effectively limit this time setting to the _smaller_ of this value and the TRA interval window, which I think is a fine limitation. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-11-ea+5) - Build # 22014 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/22014/ Java: 64bit/jdk-11-ea+5 -XX:-UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.lucene.index.TestIndexWriterExceptions.testDocumentsWriterExceptionThreads Error Message: i=1 expected:<900> but was:<899> Stack Trace: java.lang.AssertionError: i=1 expected:<900> but was:<899> at __randomizedtesting.SeedInfo.seed([4A3F8EFA843EB671:723C61EC6EED8F03]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.apache.lucene.index.TestIndexWriterExceptions.testDocumentsWriterExceptionThreads(TestIndexWriterExceptions.java:779) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) 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:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:841) Build Log: [...truncated 1369 lines...] [junit4] Suite: org.apache.lucene.index.TestIndexWriterExceptions [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestIndexWriterExceptions -Dtests.method=testDocumentsWriterExceptionThreads -Dtests.seed=4A3F8EFA843EB671 -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=mzn -Dtests.timezone=America/Antigua -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [junit4] FAILURE 0.42s J0 |
[jira] [Updated] (SOLR-11779) Basic long-term collection of aggregated metrics
[ https://issues.apache.org/jira/browse/SOLR-11779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrzej Bialecki updated SOLR-11779: - Attachment: jvm.json jvm-string.json jvm-list.json core.json > Basic long-term collection of aggregated metrics > > > Key: SOLR-11779 > URL: https://issues.apache.org/jira/browse/SOLR-11779 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Affects Versions: 7.3, master (8.0) >Reporter: Andrzej Bialecki >Assignee: Andrzej Bialecki >Priority: Major > Attachments: SOLR-11779.patch, c1.png, c2.png, core.json, d1.png, > d2.png, d3.png, jvm-list.json, jvm-string.json, jvm.json, o1.png, u1.png > > > Tracking the key metrics over time is very helpful in understanding the > cluster and user behavior. > Currently even basic metrics tracking requires setting up an external system > and either polling {{/admin/metrics}} or using {{SolrMetricReporter}}-s. The > advantage of this setup is that these external tools usually provide a lot of > sophisticated functionality. The downside is that they don't ship out of the > box with Solr and require additional admin effort to set up. > Solr could collect some of the key metrics and keep their historical values > in a round-robin database (eg. using RRD4j) to keep the size of the historic > data constant (eg. ~64kB per metric), but at the same providing out of the > box useful insights into the basic system behavior over time. This data could > be persisted to the {{.system}} collection as blobs, and it could be also > presented in the Admin UI as graphs. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11779) Basic long-term collection of aggregated metrics
[ https://issues.apache.org/jira/browse/SOLR-11779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476307#comment-16476307 ] Andrzej Bialecki commented on SOLR-11779: -- I attached also example responses for GRAPH, LIST and STRING formats. > Basic long-term collection of aggregated metrics > > > Key: SOLR-11779 > URL: https://issues.apache.org/jira/browse/SOLR-11779 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Affects Versions: 7.3, master (8.0) >Reporter: Andrzej Bialecki >Assignee: Andrzej Bialecki >Priority: Major > Attachments: SOLR-11779.patch, c1.png, c2.png, core.json, d1.png, > d2.png, d3.png, jvm-list.json, jvm-string.json, jvm.json, o1.png, u1.png > > > Tracking the key metrics over time is very helpful in understanding the > cluster and user behavior. > Currently even basic metrics tracking requires setting up an external system > and either polling {{/admin/metrics}} or using {{SolrMetricReporter}}-s. The > advantage of this setup is that these external tools usually provide a lot of > sophisticated functionality. The downside is that they don't ship out of the > box with Solr and require additional admin effort to set up. > Solr could collect some of the key metrics and keep their historical values > in a round-robin database (eg. using RRD4j) to keep the size of the historic > data constant (eg. ~64kB per metric), but at the same providing out of the > box useful insights into the basic system behavior over time. This data could > be persisted to the {{.system}} collection as blobs, and it could be also > presented in the Admin UI as graphs. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12345) indicate correctly spelt words and add to collation for search
[ https://issues.apache.org/jira/browse/SOLR-12345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476271#comment-16476271 ] James Dyer commented on SOLR-12345: --- [~rosher] maybe then a first good step here would be if you could write a failing unit test that demonstrates that "alternateTermCount" does not work as intended with FileBasedSpellChecker. The second step would be to fix this existing feature to work and thus make the new unit test pass. If you can start with the unit test, I might be able to help with fixing the bug it demonstrates. > indicate correctly spelt words and add to collation for search > -- > > Key: SOLR-12345 > URL: https://issues.apache.org/jira/browse/SOLR-12345 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: spellchecker >Affects Versions: 7.2 >Reporter: Dan Rosher >Priority: Minor > Attachments: SOLR-12345.patch, docs.xml, solrconfig.xml, spellings.txt > > > Add 'correctlySpelled' boolean for each suggestion + add correctly spelt > words to collation possibilities -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6733) Umbrella issue - Solr as a standalone application
[ https://issues.apache.org/jira/browse/SOLR-6733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476234#comment-16476234 ] Uwe Schindler commented on SOLR-6733: - I think this issue is fine, we should reopen it. Not sure why it was closed. > Umbrella issue - Solr as a standalone application > - > > Key: SOLR-6733 > URL: https://issues.apache.org/jira/browse/SOLR-6733 > Project: Solr > Issue Type: New Feature >Reporter: Shawn Heisey >Priority: Major > > Umbrella issue, for gathering issues relating to smaller pieces required to > implement the larger feature where Solr can be run as a completely standalone > application, without a servlet container. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6733) Umbrella issue - Solr as a standalone application
[ https://issues.apache.org/jira/browse/SOLR-6733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476204#comment-16476204 ] Shawn Heisey commented on SOLR-6733: I'm not sure why this issue was closed. No work was ever done, Solr is still a webapp that requires a container. Should I open a new issue, or re-open this one? > Umbrella issue - Solr as a standalone application > - > > Key: SOLR-6733 > URL: https://issues.apache.org/jira/browse/SOLR-6733 > Project: Solr > Issue Type: New Feature >Reporter: Shawn Heisey >Priority: Major > > Umbrella issue, for gathering issues relating to smaller pieces required to > implement the larger feature where Solr can be run as a completely standalone > application, without a servlet container. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-11752) add gzip to jetty
[ https://issues.apache.org/jira/browse/SOLR-11752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476098#comment-16476098 ] Matthew Sporleder edited comment on SOLR-11752 at 5/15/18 5:05 PM: --- the solr web app gui runs faster with compression working as well. There is no reason to limit usage of gzip since it only occurs when a client explicitly asks for it. was (Author: msporleder): the solr web app gui runs faster with compression working as well. There is no reason to limit usage of gzip on the streams since it only occurs when a client explicitly asks for it. > add gzip to jetty > - > > Key: SOLR-11752 > URL: https://issues.apache.org/jira/browse/SOLR-11752 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Server >Affects Versions: master (8.0) >Reporter: Matthew Sporleder >Priority: Trivial > Labels: jetty > Attachments: SOLR-11752.patch, SOLR-11752.patch > > > with a little bit of typing I am able to add gzip to my solr's jetty, which > is a big help for SAN access and completely out-of-band to solr, *and* only > happens if the client requests it so I think it is is a good default. > I will just inline my code to this ticket: > {code} > #server/etc/jetty-gzip.xml > #just download it from here: > http://grepcode.com/file/repo1.maven.org/maven2/org.eclipse.jetty/jetty-server/9.3.0.v20150612/etc/jetty-gzip.xml?av=f > {code} > {code} > #server/modules/gzip.mod > [depend] > server > [xml] > etc/jetty-gzip.xml > {code} > This is where you might want to add an option, but the result should look > like this: > {code} > #bin/solr > else > SOLR_JETTY_CONFIG+=("--module=http,gzip") > fi > {code} > I can now do this: > {code} > curl -vvv --compressed localhost:8983/solr/ > /dev/null > {code} > With: > {code} > < Content-Encoding: gzip > < Content-Length: 2890 > {code} > Without: > {code} > < Content-Length: 13349 > {code} > --- > A regular query: > With: > {code} > < Content-Encoding: gzip > < Content-Length: 2876 > {code} > Without: > {code} > < Content-Length: 17761 > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 56 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/56/ 6 tests failed. FAILED: org.apache.solr.cloud.LegacyCloudClusterPropTest.testCreateCollectionSwitchLegacyCloud Error Message: Could not find collection : legacyFalse Stack Trace: org.apache.solr.common.SolrException: Could not find collection : legacyFalse at __randomizedtesting.SeedInfo.seed([94D5D4FD5D59120C:45D22678F956993E]:0) at org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:118) at org.apache.solr.cloud.SolrCloudTestCase.getCollectionState(SolrCloudTestCase.java:256) at org.apache.solr.cloud.LegacyCloudClusterPropTest.checkMandatoryProps(LegacyCloudClusterPropTest.java:154) at org.apache.solr.cloud.LegacyCloudClusterPropTest.createAndTest(LegacyCloudClusterPropTest.java:91) at org.apache.solr.cloud.LegacyCloudClusterPropTest.testCreateCollectionSwitchLegacyCloud(LegacyCloudClusterPropTest.java:71) 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:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) 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:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) 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-11752) add gzip to jetty
[ https://issues.apache.org/jira/browse/SOLR-11752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476098#comment-16476098 ] Matthew Sporleder commented on SOLR-11752: -- the solr web app gui runs faster with compression working as well. There is no reason to limit usage of gzip on the streams since it only occurs when a client explicitly asks for it. > add gzip to jetty > - > > Key: SOLR-11752 > URL: https://issues.apache.org/jira/browse/SOLR-11752 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Server >Affects Versions: master (8.0) >Reporter: Matthew Sporleder >Priority: Trivial > Labels: jetty > Attachments: SOLR-11752.patch, SOLR-11752.patch > > > with a little bit of typing I am able to add gzip to my solr's jetty, which > is a big help for SAN access and completely out-of-band to solr, *and* only > happens if the client requests it so I think it is is a good default. > I will just inline my code to this ticket: > {code} > #server/etc/jetty-gzip.xml > #just download it from here: > http://grepcode.com/file/repo1.maven.org/maven2/org.eclipse.jetty/jetty-server/9.3.0.v20150612/etc/jetty-gzip.xml?av=f > {code} > {code} > #server/modules/gzip.mod > [depend] > server > [xml] > etc/jetty-gzip.xml > {code} > This is where you might want to add an option, but the result should look > like this: > {code} > #bin/solr > else > SOLR_JETTY_CONFIG+=("--module=http,gzip") > fi > {code} > I can now do this: > {code} > curl -vvv --compressed localhost:8983/solr/ > /dev/null > {code} > With: > {code} > < Content-Encoding: gzip > < Content-Length: 2890 > {code} > Without: > {code} > < Content-Length: 13349 > {code} > --- > A regular query: > With: > {code} > < Content-Encoding: gzip > < Content-Length: 2876 > {code} > Without: > {code} > < Content-Length: 17761 > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8312) Leverage impacts for SynonymQuery
Adrien Grand created LUCENE-8312: Summary: Leverage impacts for SynonymQuery Key: LUCENE-8312 URL: https://issues.apache.org/jira/browse/LUCENE-8312 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Now that we expose raw impacts, we could leverage them for synonym queries. It would be a matter of summing up term frequencies for each unique norm value. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8311) Leverage impacts for phrase queries
Adrien Grand created LUCENE-8311: Summary: Leverage impacts for phrase queries Key: LUCENE-8311 URL: https://issues.apache.org/jira/browse/LUCENE-8311 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Now that we expose raw impacts, we could leverage them for phrase queries. For instance for exact phrases, we could take the minimum term frequency for each unique norm value in order to get upper bounds of the score for the phrase. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11752) add gzip to jetty
[ https://issues.apache.org/jira/browse/SOLR-11752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476047#comment-16476047 ] Mark Miller commented on SOLR-11752: {quote}While it's true that we don't recommend installing any other apps, users may choose to do so, and might want gzip support for anything they add. {quote} We are not a webapp, we don't ship a container. That shouldn't influence our decisions at all. > add gzip to jetty > - > > Key: SOLR-11752 > URL: https://issues.apache.org/jira/browse/SOLR-11752 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Server >Affects Versions: master (8.0) >Reporter: Matthew Sporleder >Priority: Trivial > Labels: jetty > Attachments: SOLR-11752.patch, SOLR-11752.patch > > > with a little bit of typing I am able to add gzip to my solr's jetty, which > is a big help for SAN access and completely out-of-band to solr, *and* only > happens if the client requests it so I think it is is a good default. > I will just inline my code to this ticket: > {code} > #server/etc/jetty-gzip.xml > #just download it from here: > http://grepcode.com/file/repo1.maven.org/maven2/org.eclipse.jetty/jetty-server/9.3.0.v20150612/etc/jetty-gzip.xml?av=f > {code} > {code} > #server/modules/gzip.mod > [depend] > server > [xml] > etc/jetty-gzip.xml > {code} > This is where you might want to add an option, but the result should look > like this: > {code} > #bin/solr > else > SOLR_JETTY_CONFIG+=("--module=http,gzip") > fi > {code} > I can now do this: > {code} > curl -vvv --compressed localhost:8983/solr/ > /dev/null > {code} > With: > {code} > < Content-Encoding: gzip > < Content-Length: 2890 > {code} > Without: > {code} > < Content-Length: 13349 > {code} > --- > A regular query: > With: > {code} > < Content-Encoding: gzip > < Content-Length: 2876 > {code} > Without: > {code} > < Content-Length: 17761 > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11865) Refactor QueryElevationComponent to prepare query subset matching
[ https://issues.apache.org/jira/browse/SOLR-11865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476032#comment-16476032 ] Bruno Roustant commented on SOLR-11865: --- Great! I agree with all your points [~dsmiley]. Indeed the String IDs in Elevation would be clearer as BytesRefs. And I vote to apply the key String => indexed form as early as possible, if the code remains small. > Refactor QueryElevationComponent to prepare query subset matching > - > > Key: SOLR-11865 > URL: https://issues.apache.org/jira/browse/SOLR-11865 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SearchComponents - other >Affects Versions: master (8.0) >Reporter: Bruno Roustant >Priority: Minor > Labels: QueryComponent > Fix For: master (8.0) > > Attachments: > 0001-Refactor-QueryElevationComponent-to-introduce-Elevat.patch, > 0002-Refactor-QueryElevationComponent-after-review.patch, > 0003-Remove-exception-handlers-and-refactor-getBoostDocs.patch, > SOLR-11865.patch > > > The goal is to prepare a second improvement to support query terms subset > matching or query elevation rules. > Before that, we need to refactor the QueryElevationComponent. We make it > extendible. We introduce the ElevationProvider interface which will be > implemented later in a second patch to support subset matching. The current > full-query match policy becomes a default simple MapElevationProvider. > - Add overridable methods to handle exceptions during the component > initialization. > - Add overridable methods to provide the default values for config properties. > - No functional change beyond refactoring. > - Adapt unit test. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8310) Relax IWs check on pending deletes
[ https://issues.apache.org/jira/browse/LUCENE-8310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-8310: Attachment: LUCENE-8310.patch > Relax IWs check on pending deletes > -- > > Key: LUCENE-8310 > URL: https://issues.apache.org/jira/browse/LUCENE-8310 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 7.4, master (8.0) >Reporter: Simon Willnauer >Priority: Major > Fix For: 7.4, master (8.0) > > Attachments: LUCENE-8310.patch, LUCENE-8310.patch, LUCENE-8310.patch, > LUCENE-8310.patch > > > I recently fixed the check in IW to fail if there are pending deletes. After > upgrading to a snapshot I realized the consequences of this check. It made > most of our usage of IW to for instance prepare commit metadata, rollback to > safe commit-points etc. impossible since we have to now busy wait on top of > directory util all deletes are actually gone even though that we can > guarantee that our history always goes forward. ie we are truly append-only > in the sense of never reusing segment generations. The fix that I made was > basically return false from a _checkPendingDeletions_ in a directory wrapper > to work around it. > I do expect this to happen to a lot of lucene users even if they use IW > correctly. My proposal is to make the check in IW a bit more sophisticated > and only fail if there are pending deletes that are in the future from a > generation perspective. We really don't care about files from the past. My > patch checks the segment generation of each pending file which is safe since > that is the same procedure we apply in IndexFileDeleter to inc reference etc. > and only fail if the pending delete is in the future. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8310) Relax IWs check on pending deletes
[ https://issues.apache.org/jira/browse/LUCENE-8310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476015#comment-16476015 ] Simon Willnauer commented on LUCENE-8310: - done! > Relax IWs check on pending deletes > -- > > Key: LUCENE-8310 > URL: https://issues.apache.org/jira/browse/LUCENE-8310 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 7.4, master (8.0) >Reporter: Simon Willnauer >Priority: Major > Fix For: 7.4, master (8.0) > > Attachments: LUCENE-8310.patch, LUCENE-8310.patch, LUCENE-8310.patch, > LUCENE-8310.patch > > > I recently fixed the check in IW to fail if there are pending deletes. After > upgrading to a snapshot I realized the consequences of this check. It made > most of our usage of IW to for instance prepare commit metadata, rollback to > safe commit-points etc. impossible since we have to now busy wait on top of > directory util all deletes are actually gone even though that we can > guarantee that our history always goes forward. ie we are truly append-only > in the sense of never reusing segment generations. The fix that I made was > basically return false from a _checkPendingDeletions_ in a directory wrapper > to work around it. > I do expect this to happen to a lot of lucene users even if they use IW > correctly. My proposal is to make the check in IW a bit more sophisticated > and only fail if there are pending deletes that are in the future from a > generation perspective. We really don't care about files from the past. My > patch checks the segment generation of each pending file which is safe since > that is the same procedure we apply in IndexFileDeleter to inc reference etc. > and only fail if the pending delete is in the future. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr issue #374: [SOLR-12334] Improve detection of recreated lockfile...
Github user pgerber commented on the issue: https://github.com/apache/lucene-solr/pull/374 I made the pull request since I figured it would make sense to use fileKey upstream too, independent of filesystem. However, I have to agree that it would make more sense to use both, timestamp and key. Also, I can see how the added complexity and different code path for different platforms isn't desirable. I'll update the pull request to have, both, key and timestamp checked. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11779) Basic long-term collection of aggregated metrics
[ https://issues.apache.org/jira/browse/SOLR-11779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrzej Bialecki updated SOLR-11779: - Attachment: o1.png > Basic long-term collection of aggregated metrics > > > Key: SOLR-11779 > URL: https://issues.apache.org/jira/browse/SOLR-11779 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Affects Versions: 7.3, master (8.0) >Reporter: Andrzej Bialecki >Assignee: Andrzej Bialecki >Priority: Major > Attachments: SOLR-11779.patch, c1.png, c2.png, d1.png, d2.png, > d3.png, o1.png, u1.png > > > Tracking the key metrics over time is very helpful in understanding the > cluster and user behavior. > Currently even basic metrics tracking requires setting up an external system > and either polling {{/admin/metrics}} or using {{SolrMetricReporter}}-s. The > advantage of this setup is that these external tools usually provide a lot of > sophisticated functionality. The downside is that they don't ship out of the > box with Solr and require additional admin effort to set up. > Solr could collect some of the key metrics and keep their historical values > in a round-robin database (eg. using RRD4j) to keep the size of the historic > data constant (eg. ~64kB per metric), but at the same providing out of the > box useful insights into the basic system behavior over time. This data could > be persisted to the {{.system}} collection as blobs, and it could be also > presented in the Admin UI as graphs. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11779) Basic long-term collection of aggregated metrics
[ https://issues.apache.org/jira/browse/SOLR-11779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrzej Bialecki updated SOLR-11779: - Attachment: c2.png > Basic long-term collection of aggregated metrics > > > Key: SOLR-11779 > URL: https://issues.apache.org/jira/browse/SOLR-11779 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Affects Versions: 7.3, master (8.0) >Reporter: Andrzej Bialecki >Assignee: Andrzej Bialecki >Priority: Major > Attachments: SOLR-11779.patch, c1.png, c2.png, d1.png, d2.png, > d3.png, o1.png, u1.png > > > Tracking the key metrics over time is very helpful in understanding the > cluster and user behavior. > Currently even basic metrics tracking requires setting up an external system > and either polling {{/admin/metrics}} or using {{SolrMetricReporter}}-s. The > advantage of this setup is that these external tools usually provide a lot of > sophisticated functionality. The downside is that they don't ship out of the > box with Solr and require additional admin effort to set up. > Solr could collect some of the key metrics and keep their historical values > in a round-robin database (eg. using RRD4j) to keep the size of the historic > data constant (eg. ~64kB per metric), but at the same providing out of the > box useful insights into the basic system behavior over time. This data could > be persisted to the {{.system}} collection as blobs, and it could be also > presented in the Admin UI as graphs. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11779) Basic long-term collection of aggregated metrics
[ https://issues.apache.org/jira/browse/SOLR-11779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrzej Bialecki updated SOLR-11779: - Attachment: c1.png > Basic long-term collection of aggregated metrics > > > Key: SOLR-11779 > URL: https://issues.apache.org/jira/browse/SOLR-11779 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Affects Versions: 7.3, master (8.0) >Reporter: Andrzej Bialecki >Assignee: Andrzej Bialecki >Priority: Major > Attachments: SOLR-11779.patch, c1.png, c2.png, d1.png, d2.png, > d3.png, o1.png, u1.png > > > Tracking the key metrics over time is very helpful in understanding the > cluster and user behavior. > Currently even basic metrics tracking requires setting up an external system > and either polling {{/admin/metrics}} or using {{SolrMetricReporter}}-s. The > advantage of this setup is that these external tools usually provide a lot of > sophisticated functionality. The downside is that they don't ship out of the > box with Solr and require additional admin effort to set up. > Solr could collect some of the key metrics and keep their historical values > in a round-robin database (eg. using RRD4j) to keep the size of the historic > data constant (eg. ~64kB per metric), but at the same providing out of the > box useful insights into the basic system behavior over time. This data could > be persisted to the {{.system}} collection as blobs, and it could be also > presented in the Admin UI as graphs. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-Windows (64bit/jdk-10) - Build # 590 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/590/ Java: 64bit/jdk-10 -XX:-UseCompressedOops -XX:+UseSerialGC 37 tests failed. FAILED: org.apache.solr.handler.TestSQLHandler.doTest Error Message: --> http://127.0.0.1:54077/psx/lg/collection1_shard2_replica_n41:Failed to execute sqlQuery 'select id, field_i, str_s from collection1 where (text='()' OR text='') AND text='' order by field_i desc' against JDBC connection 'jdbc:calcitesolr:'. Error while executing SQL "select id, field_i, str_s from collection1 where (text='()' OR text='') AND text='' order by field_i desc": java.io.IOException: java.util.concurrent.ExecutionException: java.io.IOException: --> http://127.0.0.1:54149/psx/lg/collection1_shard2_replica_n45/:id must have DocValues to use this feature. Stack Trace: java.io.IOException: --> http://127.0.0.1:54077/psx/lg/collection1_shard2_replica_n41:Failed to execute sqlQuery 'select id, field_i, str_s from collection1 where (text='()' OR text='') AND text='' order by field_i desc' against JDBC connection 'jdbc:calcitesolr:'. Error while executing SQL "select id, field_i, str_s from collection1 where (text='()' OR text='') AND text='' order by field_i desc": java.io.IOException: java.util.concurrent.ExecutionException: java.io.IOException: --> http://127.0.0.1:54149/psx/lg/collection1_shard2_replica_n45/:id must have DocValues to use this feature. at __randomizedtesting.SeedInfo.seed([D8E173E948021B:A79C59D784F311A2]:0) at org.apache.solr.client.solrj.io.stream.SolrStream.read(SolrStream.java:222) at org.apache.solr.handler.TestSQLHandler.getTuples(TestSQLHandler.java:2522) at org.apache.solr.handler.TestSQLHandler.testBasicSelect(TestSQLHandler.java:124) at org.apache.solr.handler.TestSQLHandler.doTest(TestSQLHandler.java:82) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968) 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:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) 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
[jira] [Updated] (SOLR-11779) Basic long-term collection of aggregated metrics
[ https://issues.apache.org/jira/browse/SOLR-11779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrzej Bialecki updated SOLR-11779: - Attachment: u1.png d3.png d2.png d1.png > Basic long-term collection of aggregated metrics > > > Key: SOLR-11779 > URL: https://issues.apache.org/jira/browse/SOLR-11779 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Affects Versions: 7.3, master (8.0) >Reporter: Andrzej Bialecki >Assignee: Andrzej Bialecki >Priority: Major > Attachments: SOLR-11779.patch, d1.png, d2.png, d3.png, u1.png > > > Tracking the key metrics over time is very helpful in understanding the > cluster and user behavior. > Currently even basic metrics tracking requires setting up an external system > and either polling {{/admin/metrics}} or using {{SolrMetricReporter}}-s. The > advantage of this setup is that these external tools usually provide a lot of > sophisticated functionality. The downside is that they don't ship out of the > box with Solr and require additional admin effort to set up. > Solr could collect some of the key metrics and keep their historical values > in a round-robin database (eg. using RRD4j) to keep the size of the historic > data constant (eg. ~64kB per metric), but at the same providing out of the > box useful insights into the basic system behavior over time. This data could > be persisted to the {{.system}} collection as blobs, and it could be also > presented in the Admin UI as graphs. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8310) Relax IWs check on pending deletes
[ https://issues.apache.org/jira/browse/LUCENE-8310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16475993#comment-16475993 ] Michael McCandless commented on LUCENE-8310: +1, much cleaner! You can make {{SegmentInfos.getNextPendingGeneration}} private again? > Relax IWs check on pending deletes > -- > > Key: LUCENE-8310 > URL: https://issues.apache.org/jira/browse/LUCENE-8310 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 7.4, master (8.0) >Reporter: Simon Willnauer >Priority: Major > Fix For: 7.4, master (8.0) > > Attachments: LUCENE-8310.patch, LUCENE-8310.patch, LUCENE-8310.patch > > > I recently fixed the check in IW to fail if there are pending deletes. After > upgrading to a snapshot I realized the consequences of this check. It made > most of our usage of IW to for instance prepare commit metadata, rollback to > safe commit-points etc. impossible since we have to now busy wait on top of > directory util all deletes are actually gone even though that we can > guarantee that our history always goes forward. ie we are truly append-only > in the sense of never reusing segment generations. The fix that I made was > basically return false from a _checkPendingDeletions_ in a directory wrapper > to work around it. > I do expect this to happen to a lot of lucene users even if they use IW > correctly. My proposal is to make the check in IW a bit more sophisticated > and only fail if there are pending deletes that are in the future from a > generation perspective. We really don't care about files from the past. My > patch checks the segment generation of each pending file which is safe since > that is the same procedure we apply in IndexFileDeleter to inc reference etc. > and only fail if the pending delete is in the future. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11779) Basic long-term collection of aggregated metrics
[ https://issues.apache.org/jira/browse/SOLR-11779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrzej Bialecki updated SOLR-11779: - Attachment: d1.png > Basic long-term collection of aggregated metrics > > > Key: SOLR-11779 > URL: https://issues.apache.org/jira/browse/SOLR-11779 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Affects Versions: 7.3, master (8.0) >Reporter: Andrzej Bialecki >Assignee: Andrzej Bialecki >Priority: Major > Attachments: SOLR-11779.patch > > > Tracking the key metrics over time is very helpful in understanding the > cluster and user behavior. > Currently even basic metrics tracking requires setting up an external system > and either polling {{/admin/metrics}} or using {{SolrMetricReporter}}-s. The > advantage of this setup is that these external tools usually provide a lot of > sophisticated functionality. The downside is that they don't ship out of the > box with Solr and require additional admin effort to set up. > Solr could collect some of the key metrics and keep their historical values > in a round-robin database (eg. using RRD4j) to keep the size of the historic > data constant (eg. ~64kB per metric), but at the same providing out of the > box useful insights into the basic system behavior over time. This data could > be persisted to the {{.system}} collection as blobs, and it could be also > presented in the Admin UI as graphs. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11779) Basic long-term collection of aggregated metrics
[ https://issues.apache.org/jira/browse/SOLR-11779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrzej Bialecki updated SOLR-11779: - Attachment: (was: d1.png) > Basic long-term collection of aggregated metrics > > > Key: SOLR-11779 > URL: https://issues.apache.org/jira/browse/SOLR-11779 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Affects Versions: 7.3, master (8.0) >Reporter: Andrzej Bialecki >Assignee: Andrzej Bialecki >Priority: Major > Attachments: SOLR-11779.patch > > > Tracking the key metrics over time is very helpful in understanding the > cluster and user behavior. > Currently even basic metrics tracking requires setting up an external system > and either polling {{/admin/metrics}} or using {{SolrMetricReporter}}-s. The > advantage of this setup is that these external tools usually provide a lot of > sophisticated functionality. The downside is that they don't ship out of the > box with Solr and require additional admin effort to set up. > Solr could collect some of the key metrics and keep their historical values > in a round-robin database (eg. using RRD4j) to keep the size of the historic > data constant (eg. ~64kB per metric), but at the same providing out of the > box useful insights into the basic system behavior over time. This data could > be persisted to the {{.system}} collection as blobs, and it could be also > presented in the Admin UI as graphs. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12345) indicate correctly spelt words and add to collation for search
[ https://issues.apache.org/jira/browse/SOLR-12345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16475990#comment-16475990 ] Dan Rosher commented on SOLR-12345: --- The original term only gets added if alternativeTermCount >0 and docFreq > 0 but for e.g. FileBasedSpellChecker [what we're using] the determineReader() returns null and so docFreq set to zero, hence orig term not added. But in the collator should this not depend on whether the word is correctly spelt rather than docFreq >0 ? as the best candidates are done by the collator. > indicate correctly spelt words and add to collation for search > -- > > Key: SOLR-12345 > URL: https://issues.apache.org/jira/browse/SOLR-12345 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: spellchecker >Affects Versions: 7.2 >Reporter: Dan Rosher >Priority: Minor > Attachments: SOLR-12345.patch, docs.xml, solrconfig.xml, spellings.txt > > > Add 'correctlySpelled' boolean for each suggestion + add correctly spelt > words to collation possibilities -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Solr Ref Guide builds, precommit, and a plea
Just to close the loop (I was out for a couple days)I hear you that linking is a bit confusing, let me try to explain a bit and hopefully it will help. Nearly all the rules are there because of the PDF version which is the only official release of the Ref Guide. To generate the PDF, every page of the Guide is assembled into one massive page and then converted to PDF. If you think about an online corollary to that - if we put the whole Guide into one single HTML page - then it should become clear why every single link between pages needs to be unique. If you want to link to another page, the pattern is <>. Someday we hopefully won't have to do the repetition there (the "page-name.adoc#page-name" part), but since it's unintuitive, one of the validation rules checks to catch cases where people may have missed doing it. Here again if we think about one single massive page of the whole Ref Guide as the paradigm, "page-name.adoc" doesn't exist in that scenario - only "SolrRefGuide-all.adoc" does - so the only thing left to reference a link is the anchor. So, you must have an anchor in the link definition or the one single page won't know where within itself to link. It would be nice if the PDF could be smarter about it without the unintuitive pattern, but it's not yet. The other issue you ran into was that one page was an orphan (had no parent). We don't allow that because pages shouldn't be added until they have a place in the overall page hierarchy. The assumption is that it only happens accidentally and an orphan should be corrected as soon as possible, so build/precommit fails on that case. All these validation rules are in place to try to find common mistakes with the Ref Guide pages and ensure what comes out of the builds is as close to release-able as possible without human page-by-page review (which we used to need to do). I have no doubt there is room for improvement to all these processes, so contributions are welcome if there's a way to make it easier/clearer. On Thu, May 10, 2018 at 1:46 PM Joel Bernstein wrote: > I see that the ref-guide build was also failing. When I made the first fix > to ref-guide build I didn't see any errors for a while figured that build > was now working. But then a new set of errors were generated. I didn't > realize that the ref-guide fails in stages. > > I think in general I'm finding all the strictness in the refguide hard > figure out. Things like internal linking have taken a long time to get > right even though they work fine when viewed on github, the build often > still fails due to the links > > > > Joel Bernstein > http://joelsolr.blogspot.com/ > > On Thu, May 10, 2018 at 2:33 PM, Joel Bernstein > wrote: > >> Ah, just saw all the errors caused by the refguide change that I made. I >> hadn't realized that precommit had been setup for refguide changes. I >> apologize for the noise this caused. I originally got one error reported >> for the ref guide build and fixed that one, and figured I was done. Next >> time I'll run precommit before pushing out ref guide changes. >> >> Joel Bernstein >> http://joelsolr.blogspot.com/ >> >> On Thu, May 10, 2018 at 10:30 AM, Cassandra Targett >> wrote: >> >>> There were some recent changes to the way the Solr Ref Guide gets built >>> made about a month ago, but stuff moves fast throughout the project so I >>> suspect it's likely a few have missed some details. >>> >>> The first, and most important, change is now when you run "ant >>> precommit", internal (page to page) & javadoc links in the Ref Guide are >>> checked and validated. This used to only run when you specifically built >>> the Ref Guide - now it happens with precommit. This was all done with >>> SOLR-12134. >>> >>> This means that if you didn't set up your env to build the HTML and you >>> don't want to build the PDF before editing docs, you don't have to. Run >>> precommit like you're already supposed to for every commit. It will fail if >>> your doc edits are messed up. >>> >>> This was one step in the process of merging the Ref Guide build with the >>> main build. There's more to do, but I don't have a concrete plan in mind. >>> >>> The second new thing that's worth mentioning is that the Ref Guide now >>> uses variables in place of "hard coded" version numbers for 3rd party >>> components. These variables pull their values from ivy-versions.properties >>> so they are accurate for each release without human intervention. This >>> includes the versions of Tika, ZooKeeper, Log4J, OpenNLP, Velocity, Commons >>> Codec, and Dropwizard today - more can be added if they are needed. >>> >>> Finally - and this likely applies to more than just the Ref Guide - >>> let's try to use branches for big stuff [1]. Branches are cheap and if >>> things go awry you don't stall everyone trying to use precommit for 12-18 >>> hours or more. We can set up Jenkins jobs for a
[jira] [Commented] (SOLR-12355) HashJoinStream's use of String::hashCode results in non-matching tuples being considered matches
[ https://issues.apache.org/jira/browse/SOLR-12355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16475973#comment-16475973 ] Dennis Gove commented on SOLR-12355: Initial patch attached. I have not yet run the full suite of tests against this. > HashJoinStream's use of String::hashCode results in non-matching tuples being > considered matches > > > Key: SOLR-12355 > URL: https://issues.apache.org/jira/browse/SOLR-12355 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Affects Versions: 6.0 >Reporter: Dennis Gove >Assignee: Dennis Gove >Priority: Major > Attachments: SOLR-12355.patch > > > The following strings have been found to have hashCode conflicts and as such > can result in HashJoinStream considering two tuples with fields of these > values to be considered the same. > {code:java} > "MG!!00TNGP::Mtge::".hashCode() == "MG!!00TNH1::Mtge::".hashCode() {code} > This means these two tuples are the same if we're comparing on field "foo" > {code:java} > { > "foo":"MG!!00TNGP::Mtge::" > } > { > "foo":"MG!!00TNH1::Mtge::" > } > {code} > and these two tuples are the same if we're comparing on fields "foo,bar" > {code:java} > { > "foo":"MG!!00TNGP" > "bar":"Mtge" > } > { > "foo":"MG!!00TNH1" > "bar":"Mtge" > }{code} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12355) HashJoinStream's use of String::hashCode results in non-matching tuples being considered matches
[ https://issues.apache.org/jira/browse/SOLR-12355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Gove updated SOLR-12355: --- Attachment: SOLR-12355.patch > HashJoinStream's use of String::hashCode results in non-matching tuples being > considered matches > > > Key: SOLR-12355 > URL: https://issues.apache.org/jira/browse/SOLR-12355 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Affects Versions: 6.0 >Reporter: Dennis Gove >Assignee: Dennis Gove >Priority: Major > Attachments: SOLR-12355.patch > > > The following strings have been found to have hashCode conflicts and as such > can result in HashJoinStream considering two tuples with fields of these > values to be considered the same. > {code:java} > "MG!!00TNGP::Mtge::".hashCode() == "MG!!00TNH1::Mtge::".hashCode() {code} > This means these two tuples are the same if we're comparing on field "foo" > {code:java} > { > "foo":"MG!!00TNGP::Mtge::" > } > { > "foo":"MG!!00TNH1::Mtge::" > } > {code} > and these two tuples are the same if we're comparing on fields "foo,bar" > {code:java} > { > "foo":"MG!!00TNGP" > "bar":"Mtge" > } > { > "foo":"MG!!00TNH1" > "bar":"Mtge" > }{code} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12338) Replay buffering tlog in parallel
[ https://issues.apache.org/jira/browse/SOLR-12338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16475965#comment-16475965 ] Cao Manh Dat commented on SOLR-12338: - Interesting result, when I change from {{SetBlockingQueue}} to guava Striped class (its implementation is like an array of lock). The performance is decreased (from 4341ms to 8227ms), if I increase the number of stripes (size of the lock array) to {{numThreads * 1000}}, they will eventually run in the same amount of time. It is a sign that collision does affect the performance! > Replay buffering tlog in parallel > - > > Key: SOLR-12338 > URL: https://issues.apache.org/jira/browse/SOLR-12338 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Cao Manh Dat >Assignee: Cao Manh Dat >Priority: Major > Attachments: SOLR-12338.patch, SOLR-12338.patch, SOLR-12338.patch > > > Since updates with different id are independent, therefore it is safe to > replay them in parallel. This will significantly reduce recovering time of > replicas in high load indexing environment. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12328) Adding graph json facet domain change
[ https://issues.apache.org/jira/browse/SOLR-12328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16475938#comment-16475938 ] Kevin Watters commented on SOLR-12328: -- Hey Dan , this looks pretty awesome. One comment, If the traversal filter is null/empty, I don't think the default match all query is needed. So, in the GraphField class, I think you can probably get rid of that null check and default value for the traversal filter. > Adding graph json facet domain change > - > > Key: SOLR-12328 > URL: https://issues.apache.org/jira/browse/SOLR-12328 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Facet Module >Affects Versions: 7.3 >Reporter: Daniel Meehl >Priority: Major > Attachments: SOLR-12328.patch > > > Json facets now support join queries via domain change. I've made a > relatively small enhancement to add graph to the mix. I'll attach a patch for > your viewing. I'm hoping this can be merged into solr proper. Please let me > know if there are any problems/changes/requirements. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9685) tag a query in JSON syntax
[ https://issues.apache.org/jira/browse/SOLR-9685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16475935#comment-16475935 ] Mikhail Khludnev commented on SOLR-9685: How long you need to review this? Is this week enough? > tag a query in JSON syntax > -- > > Key: SOLR-9685 > URL: https://issues.apache.org/jira/browse/SOLR-9685 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Facet Module, JSON Request API >Reporter: Yonik Seeley >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > There should be a way to tag a query/filter in JSON syntax. > Perhaps these two forms could be equivalent: > {code} > "{!tag=COLOR}color:blue" > { tagged : { COLOR : "color:blue" } > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12356) Always auto-create ".system" collection when in SolrCloud mode
[ https://issues.apache.org/jira/browse/SOLR-12356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16475926#comment-16475926 ] Shawn Heisey commented on SOLR-12356: - The only issues I can see related to doing this automatically is how replicationFactor is decided, and how to prevent multiple replicas from ending up on the same node. When somebody decides to run multiple nodes per host, ensuring proper replica placement is particularly important. The first time an overseer starts in a cloud, there's probably only going to be one Solr node, so it won't be possible to create the collection with a replicationFactor higher than 1. How do we handle that? When nodes are added, how do we decide whether to automatically add a replica? My preference would be to do the add, but users may disagree, especially if they add a node in a location with limited bandwidth. > Always auto-create ".system" collection when in SolrCloud mode > -- > > Key: SOLR-12356 > URL: https://issues.apache.org/jira/browse/SOLR-12356 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Andrzej Bialecki >Priority: Major > > The {{.system}} collection is currently used for blobs, and in SolrCloud mode > it's also used for autoscaling history and as a metrics history store > (SOLR-11779). It should be automatically created on Overseer start if it's > missing. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8310) Relax IWs check on pending deletes
[ https://issues.apache.org/jira/browse/LUCENE-8310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-8310: Attachment: LUCENE-8310.patch > Relax IWs check on pending deletes > -- > > Key: LUCENE-8310 > URL: https://issues.apache.org/jira/browse/LUCENE-8310 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 7.4, master (8.0) >Reporter: Simon Willnauer >Priority: Major > Fix For: 7.4, master (8.0) > > Attachments: LUCENE-8310.patch, LUCENE-8310.patch, LUCENE-8310.patch > > > I recently fixed the check in IW to fail if there are pending deletes. After > upgrading to a snapshot I realized the consequences of this check. It made > most of our usage of IW to for instance prepare commit metadata, rollback to > safe commit-points etc. impossible since we have to now busy wait on top of > directory util all deletes are actually gone even though that we can > guarantee that our history always goes forward. ie we are truly append-only > in the sense of never reusing segment generations. The fix that I made was > basically return false from a _checkPendingDeletions_ in a directory wrapper > to work around it. > I do expect this to happen to a lot of lucene users even if they use IW > correctly. My proposal is to make the check in IW a bit more sophisticated > and only fail if there are pending deletes that are in the future from a > generation perspective. We really don't care about files from the past. My > patch checks the segment generation of each pending file which is safe since > that is the same procedure we apply in IndexFileDeleter to inc reference etc. > and only fail if the pending delete is in the future. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8310) Relax IWs check on pending deletes
[ https://issues.apache.org/jira/browse/LUCENE-8310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16475921#comment-16475921 ] Simon Willnauer commented on LUCENE-8310: - new patch, I think it's ready! I also removed checkPendingDeletions entirely > Relax IWs check on pending deletes > -- > > Key: LUCENE-8310 > URL: https://issues.apache.org/jira/browse/LUCENE-8310 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 7.4, master (8.0) >Reporter: Simon Willnauer >Priority: Major > Fix For: 7.4, master (8.0) > > Attachments: LUCENE-8310.patch, LUCENE-8310.patch, LUCENE-8310.patch > > > I recently fixed the check in IW to fail if there are pending deletes. After > upgrading to a snapshot I realized the consequences of this check. It made > most of our usage of IW to for instance prepare commit metadata, rollback to > safe commit-points etc. impossible since we have to now busy wait on top of > directory util all deletes are actually gone even though that we can > guarantee that our history always goes forward. ie we are truly append-only > in the sense of never reusing segment generations. The fix that I made was > basically return false from a _checkPendingDeletions_ in a directory wrapper > to work around it. > I do expect this to happen to a lot of lucene users even if they use IW > correctly. My proposal is to make the check in IW a bit more sophisticated > and only fail if there are pending deletes that are in the future from a > generation perspective. We really don't care about files from the past. My > patch checks the segment generation of each pending file which is safe since > that is the same procedure we apply in IndexFileDeleter to inc reference etc. > and only fail if the pending delete is in the future. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11752) add gzip to jetty
[ https://issues.apache.org/jira/browse/SOLR-11752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16475913#comment-16475913 ] Shawn Heisey commented on SOLR-11752: - It appears that all the config information related to mime types is commented, so not actually active. I think that all files from Jetty should be included as-is, with any modifications that we require. No modifications should be required for gzip-related files. As I indicated on 26/Feb/18, I prefer the approach in this issue to the one in SOLR-10999. It enables gzip for the entire server, while the other only enables it for the Solr webapp. While it's true that we don't recommend installing any other apps, users may choose to do so, and might want gzip support for anything they add. > add gzip to jetty > - > > Key: SOLR-11752 > URL: https://issues.apache.org/jira/browse/SOLR-11752 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Server >Affects Versions: master (8.0) >Reporter: Matthew Sporleder >Priority: Trivial > Labels: jetty > Attachments: SOLR-11752.patch, SOLR-11752.patch > > > with a little bit of typing I am able to add gzip to my solr's jetty, which > is a big help for SAN access and completely out-of-band to solr, *and* only > happens if the client requests it so I think it is is a good default. > I will just inline my code to this ticket: > {code} > #server/etc/jetty-gzip.xml > #just download it from here: > http://grepcode.com/file/repo1.maven.org/maven2/org.eclipse.jetty/jetty-server/9.3.0.v20150612/etc/jetty-gzip.xml?av=f > {code} > {code} > #server/modules/gzip.mod > [depend] > server > [xml] > etc/jetty-gzip.xml > {code} > This is where you might want to add an option, but the result should look > like this: > {code} > #bin/solr > else > SOLR_JETTY_CONFIG+=("--module=http,gzip") > fi > {code} > I can now do this: > {code} > curl -vvv --compressed localhost:8983/solr/ > /dev/null > {code} > With: > {code} > < Content-Encoding: gzip > < Content-Length: 2890 > {code} > Without: > {code} > < Content-Length: 13349 > {code} > --- > A regular query: > With: > {code} > < Content-Encoding: gzip > < Content-Length: 2876 > {code} > Without: > {code} > < Content-Length: 17761 > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8310) Relax IWs check on pending deletes
[ https://issues.apache.org/jira/browse/LUCENE-8310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16475907#comment-16475907 ] Adrien Grand commented on LUCENE-8310: -- Much nicer. +1 > Relax IWs check on pending deletes > -- > > Key: LUCENE-8310 > URL: https://issues.apache.org/jira/browse/LUCENE-8310 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 7.4, master (8.0) >Reporter: Simon Willnauer >Priority: Major > Fix For: 7.4, master (8.0) > > Attachments: LUCENE-8310.patch, LUCENE-8310.patch > > > I recently fixed the check in IW to fail if there are pending deletes. After > upgrading to a snapshot I realized the consequences of this check. It made > most of our usage of IW to for instance prepare commit metadata, rollback to > safe commit-points etc. impossible since we have to now busy wait on top of > directory util all deletes are actually gone even though that we can > guarantee that our history always goes forward. ie we are truly append-only > in the sense of never reusing segment generations. The fix that I made was > basically return false from a _checkPendingDeletions_ in a directory wrapper > to work around it. > I do expect this to happen to a lot of lucene users even if they use IW > correctly. My proposal is to make the check in IW a bit more sophisticated > and only fail if there are pending deletes that are in the future from a > generation perspective. We really don't care about files from the past. My > patch checks the segment generation of each pending file which is safe since > that is the same procedure we apply in IndexFileDeleter to inc reference etc. > and only fail if the pending delete is in the future. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12345) indicate correctly spelt words and add to collation for search
[ https://issues.apache.org/jira/browse/SOLR-12345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16475906#comment-16475906 ] James Dyer commented on SOLR-12345: --- I think we can close this as invalid, and in the future we should use the user-list for discussions like this. Unless I am misunderstanding what is desired here, everything desired is already supported. See the documentation for "spellcheck.alternativeTermCount" for information on how to consider that only some of the words are misspelled. See the documentation for "spellcheck.collateExtendedResults" for information on how to get details as to which words replace others in collations. If after reviewing the documentation you still feel there is a need for a new feature, help us understand why the existing functionality is not adequate. Otherwise, we can close this issue. > indicate correctly spelt words and add to collation for search > -- > > Key: SOLR-12345 > URL: https://issues.apache.org/jira/browse/SOLR-12345 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: spellchecker >Affects Versions: 7.2 >Reporter: Dan Rosher >Priority: Minor > Attachments: SOLR-12345.patch, docs.xml, solrconfig.xml, spellings.txt > > > Add 'correctlySpelled' boolean for each suggestion + add correctly spelt > words to collation possibilities -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8309) Don't use mutable FixedBitSets as live docs Bits
[ https://issues.apache.org/jira/browse/LUCENE-8309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16475891#comment-16475891 ] Simon Willnauer commented on LUCENE-8309: - this looks great LGTM > Don't use mutable FixedBitSets as live docs Bits > > > Key: LUCENE-8309 > URL: https://issues.apache.org/jira/browse/LUCENE-8309 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Priority: Minor > Attachments: LUCENE-8309.patch > > > Simon mentioned this idea first: it would be nice to not expose mutable > fixedbitsets as live docs, which makes it easy for consumers of live docs to > resurrect some documents by casting to a FixedBitSet and potentially corrupt > the index. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8310) Relax IWs check on pending deletes
[ https://issues.apache.org/jira/browse/LUCENE-8310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16475887#comment-16475887 ] Adrien Grand commented on LUCENE-8310: -- Maybe we can get rid of checkPendingDeletions now that we have getPendingDeletions? > Relax IWs check on pending deletes > -- > > Key: LUCENE-8310 > URL: https://issues.apache.org/jira/browse/LUCENE-8310 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 7.4, master (8.0) >Reporter: Simon Willnauer >Priority: Major > Fix For: 7.4, master (8.0) > > Attachments: LUCENE-8310.patch, LUCENE-8310.patch > > > I recently fixed the check in IW to fail if there are pending deletes. After > upgrading to a snapshot I realized the consequences of this check. It made > most of our usage of IW to for instance prepare commit metadata, rollback to > safe commit-points etc. impossible since we have to now busy wait on top of > directory util all deletes are actually gone even though that we can > guarantee that our history always goes forward. ie we are truly append-only > in the sense of never reusing segment generations. The fix that I made was > basically return false from a _checkPendingDeletions_ in a directory wrapper > to work around it. > I do expect this to happen to a lot of lucene users even if they use IW > correctly. My proposal is to make the check in IW a bit more sophisticated > and only fail if there are pending deletes that are in the future from a > generation perspective. We really don't care about files from the past. My > patch checks the segment generation of each pending file which is safe since > that is the same procedure we apply in IndexFileDeleter to inc reference etc. > and only fail if the pending delete is in the future. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8310) Relax IWs check on pending deletes
[ https://issues.apache.org/jira/browse/LUCENE-8310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16475885#comment-16475885 ] Simon Willnauer commented on LUCENE-8310: - [~mikemccand] I had a better Idea and I managed to remove the exception altogether and configure IW to adopt it's gens to pending deletes. > Relax IWs check on pending deletes > -- > > Key: LUCENE-8310 > URL: https://issues.apache.org/jira/browse/LUCENE-8310 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 7.4, master (8.0) >Reporter: Simon Willnauer >Priority: Major > Fix For: 7.4, master (8.0) > > Attachments: LUCENE-8310.patch, LUCENE-8310.patch > > > I recently fixed the check in IW to fail if there are pending deletes. After > upgrading to a snapshot I realized the consequences of this check. It made > most of our usage of IW to for instance prepare commit metadata, rollback to > safe commit-points etc. impossible since we have to now busy wait on top of > directory util all deletes are actually gone even though that we can > guarantee that our history always goes forward. ie we are truly append-only > in the sense of never reusing segment generations. The fix that I made was > basically return false from a _checkPendingDeletions_ in a directory wrapper > to work around it. > I do expect this to happen to a lot of lucene users even if they use IW > correctly. My proposal is to make the check in IW a bit more sophisticated > and only fail if there are pending deletes that are in the future from a > generation perspective. We really don't care about files from the past. My > patch checks the segment generation of each pending file which is safe since > that is the same procedure we apply in IndexFileDeleter to inc reference etc. > and only fail if the pending delete is in the future. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org