[jira] [Commented] (LUCENE-8291) Possible security issue when parsing XML documents containing external entity references

[ASF subversion and git services (JIRA)]

[ 
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!

[Policeman Jenkins Server]

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

[Apache Jenkins Server]

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!

[Policeman Jenkins Server]

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!

[Policeman Jenkins Server]

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!

[Policeman Jenkins Server]

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

[Apache Jenkins Server]

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

[Robert Muir (JIRA)]

[ 
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!

[Policeman Jenkins Server]

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!

[Policeman Jenkins Server]

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!

[Policeman Jenkins Server]

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!

[Policeman Jenkins Server]

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!

[Policeman Jenkins Server]

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!

[Policeman Jenkins Server]

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!

[Policeman Jenkins Server]

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!

[Policeman Jenkins Server]

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!

[Policeman Jenkins Server]

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

[Shawn Heisey (JIRA)]

[ 
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

[Apache Jenkins Server]

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!

[Policeman Jenkins Server]

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!

[Policeman Jenkins Server]

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!

[Policeman Jenkins Server]

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

[JIRA]

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!

[Policeman Jenkins Server]

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!

[Policeman Jenkins Server]

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!

[Policeman Jenkins Server]

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!

[Policeman Jenkins Server]

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!

[Policeman Jenkins Server]

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

[Jerry Bao (JIRA)]

 [ 
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!

[Policeman Jenkins Server]

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

[David Smiley (JIRA)]

[ 
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

[Noble Paul (JIRA)]

[ 
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 (JIRA)]

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!

[Policeman Jenkins Server]

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

[JIRA]

[ 
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!

[Policeman Jenkins Server]

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

[JIRA]

[ 
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

[Michael McCandless (JIRA)]

[ 
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 (JIRA)]

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

[Uwe Schindler (JIRA)]

 [ 
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

[ASF subversion and git services (JIRA)]

[ 
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

[ASF subversion and git services (JIRA)]

[ 
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

[Mikhail Khludnev (JIRA)]

[ 
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

[Shawn Heisey (JIRA)]

[ 
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!

[Policeman Jenkins Server]

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!

[Policeman Jenkins Server]

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

[Alexandre Rafalovitch (JIRA)]

[ 
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

[Andrzej Bialecki (JIRA)]

[ 
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

[Andrzej Bialecki (JIRA)]

[ 
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

[Andrzej Bialecki (JIRA)]

[ 
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

[Andrzej Bialecki (JIRA)]

[ 
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

[Andrzej Bialecki (JIRA)]

 [ 
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

[Cassandra Targett (JIRA)]

 [ 
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

[Cassandra Targett (JIRA)]

 [ 
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

[Shawn Heisey (JIRA)]

[ 
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

[Ingomar Wesp (JIRA)]

[ 
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

[Ingomar Wesp (JIRA)]

[ 
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

[Shawn Heisey (JIRA)]

 [ 
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

[Matthew Sporleder (JIRA)]

 [ 
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 (JIRA)]

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!

[Policeman Jenkins Server]

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

[Andrzej Bialecki (JIRA)]

 [ 
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

[Andrzej Bialecki (JIRA)]

[ 
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

[James Dyer (JIRA)]

[ 
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

[Uwe Schindler (JIRA)]

[ 
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

[Shawn Heisey (JIRA)]

[ 
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

[Matthew Sporleder (JIRA)]

[ 
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

[Apache Jenkins Server]

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

[Matthew Sporleder (JIRA)]

[ 
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 (JIRA)]

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 (JIRA)]

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

[Mark Miller (JIRA)]

[ 
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

[Bruno Roustant (JIRA)]

[ 
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

[Simon Willnauer (JIRA)]

 [ 
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

[Simon Willnauer (JIRA)]

[ 
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...

[pgerber]

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

[Andrzej Bialecki (JIRA)]

 [ 
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

[Andrzej Bialecki (JIRA)]

 [ 
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

[Andrzej Bialecki (JIRA)]

 [ 
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!

[Policeman Jenkins Server]

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

[Andrzej Bialecki (JIRA)]

 [ 
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

[Michael McCandless (JIRA)]

[ 
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

[Andrzej Bialecki (JIRA)]

 [ 
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

[Andrzej Bialecki (JIRA)]

 [ 
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

[Dan Rosher (JIRA)]

[ 
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

[Cassandra Targett]

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

[Dennis Gove (JIRA)]

[ 
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

[Dennis Gove (JIRA)]

 [ 
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

[Cao Manh Dat (JIRA)]

[ 
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

[Kevin Watters (JIRA)]

[ 
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

[Mikhail Khludnev (JIRA)]

[ 
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

[Shawn Heisey (JIRA)]

[ 
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

[Simon Willnauer (JIRA)]

 [ 
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

[Simon Willnauer (JIRA)]

[ 
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

[Shawn Heisey (JIRA)]

[ 
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

[Adrien Grand (JIRA)]

[ 
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

[James Dyer (JIRA)]

[ 
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

[Simon Willnauer (JIRA)]

[ 
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

[Adrien Grand (JIRA)]

[ 
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

[Simon Willnauer (JIRA)]

[ 
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