[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-11.0.3) - Build # 24475 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24475/
Java: 64bit/jdk-11.0.3 -XX:-UseCompressedOops -XX:+UseParallelGC
All tests passed
Build Log:
[...truncated 53711 lines...]
-ecj-javadoc-lint-tests:
[mkdir] Created dir: /tmp/ecj303326937
[ecj-lint] Compiling 535 source files to /tmp/ecj303326937
[ecj-lint] --
[ecj-lint] 1. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/core/src/test/org/apache/lucene/TestAssertions.java
(at line 44)
[ecj-lint] new TestTokenStream1();
[ecj-lint] ^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] 2. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/core/src/test/org/apache/lucene/TestAssertions.java
(at line 45)
[ecj-lint] new TestTokenStream2();
[ecj-lint] ^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] 3. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/core/src/test/org/apache/lucene/TestAssertions.java
(at line 47)
[ecj-lint] new TestTokenStream3();
[ecj-lint] ^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 4. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/core/src/test/org/apache/lucene/TestMergeSchedulerExternal.java
(at line 130)
[ecj-lint] IndexWriter writer = new IndexWriter(dir, iwc);
[ecj-lint] ^^
[ecj-lint] Resource leak: 'writer' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 5. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/core/src/test/org/apache/lucene/analysis/TestCachingTokenFilter.java
(at line 120)
[ecj-lint] Analyzer analyzer = new MockAnalyzer(random());
[ecj-lint]
[ecj-lint] Resource leak: 'analyzer' is never closed
[ecj-lint] --
[ecj-lint] 6. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/core/src/test/org/apache/lucene/analysis/TestCachingTokenFilter.java
(at line 122)
[ecj-lint] CachingTokenFilter buffer = new CachingTokenFilter(input);
[ecj-lint]^^
[ecj-lint] Resource leak: 'buffer' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 7. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
(at line 29)
[ecj-lint] CharFilter cs = new CharFilter1(new StringReader(""));
[ecj-lint]^^
[ecj-lint] Resource leak: 'cs' is never closed
[ecj-lint] --
[ecj-lint] 8. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
(at line 34)
[ecj-lint] CharFilter cs = new CharFilter2(new StringReader(""));
[ecj-lint]^^
[ecj-lint] Resource leak: 'cs' is never closed
[ecj-lint] --
[ecj-lint] 9. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
(at line 39)
[ecj-lint] CharFilter cs = new CharFilter2(new CharFilter1(new
StringReader("")));
[ecj-lint]^^
[ecj-lint] Resource leak: 'cs' is never closed
[ecj-lint] --
[ecj-lint] 10. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
(at line 44)
[ecj-lint] CharFilter cs = new CharFilter1(new CharFilter1(new
StringReader("")));
[ecj-lint]^^
[ecj-lint] Resource leak: 'cs' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 11. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/core/src/test/org/apache/lucene/analysis/TestDelegatingAnalyzerWrapper.java
(at line 39)
[ecj-lint] DelegatingAnalyzerWrapper w2 = new
DelegatingAnalyzerWrapper(Analyzer.GLOBAL_REUSE_STRATEGY) {
[ecj-lint] ^^
[ecj-lint] Resource leak: 'w2' is never closed
[ecj-lint] --
[ecj-lint] 12. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/core/src/test/org/apache/lucene/analysis/TestDelegatingAnalyzerWrapper.java
(at line 50)
[ecj-lint] DelegatingAnalyzerWrapper w1 = new
DelegatingAnalyzerWrapper(Analyzer.GLOBAL_REUSE_STRATEGY) {
[ecj-lint] ^^
[ecj-lint] Resource leak: 'w1' is never closed
[ecj-lint] --
[ecj-lint] 13. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/core/src/test/org/apache/lucene/analysis/TestDelegatingAnalyzerWrapper.java
(at line 71)
[ecj-lint] DelegatingAnalyzerWrapper w1 = new
DelegatingAnalyzerWrapper(Analyzer.GLOBAL_REUSE_STRATEGY) {
[ecj-lint] ^^
[ecj-lint] Resource leak: 'w1' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 14. WARNING in
[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1915 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1915/ No tests ran. Build Log: [...truncated 25 lines...] ERROR: Failed to check out http://svn.apache.org/repos/asf/lucene/test-data org.tmatesoft.svn.core.SVNException: svn: E175002: connection refused by the server svn: E175002: OPTIONS request failed on '/repos/asf/lucene/test-data' at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:112) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:96) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:765) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:340) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:910) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:702) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:113) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1035) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:164) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:119) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:178) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:43) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:831) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:26) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:11) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1239) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at hudson.scm.subversion.CheckoutUpdater$SubversionUpdateTask.perform(CheckoutUpdater.java:133) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:176) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:134) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1041) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1017) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:990) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3086) at hudson.remoting.UserRequest.perform(UserRequest.java:212) at hudson.remoting.UserRequest.perform(UserRequest.java:54) at hudson.remoting.Request$2.run(Request.java:369) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:744) Caused by: java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:589) at org.tmatesoft.svn.core.internal.util.SVNSocketConnection.run(SVNSocketConnection.java:57) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ... 4 more java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
[JENKINS] Lucene-Solr-Tests-master - Build # 3467 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3467/
All tests passed
Build Log:
[...truncated 53579 lines...]
-ecj-javadoc-lint-tests:
[mkdir] Created dir: /tmp/ecj1993712709
[ecj-lint] Compiling 535 source files to /tmp/ecj1993712709
[ecj-lint] --
[ecj-lint] 1. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/TestAssertions.java
(at line 44)
[ecj-lint] new TestTokenStream1();
[ecj-lint] ^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] 2. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/TestAssertions.java
(at line 45)
[ecj-lint] new TestTokenStream2();
[ecj-lint] ^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] 3. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/TestAssertions.java
(at line 47)
[ecj-lint] new TestTokenStream3();
[ecj-lint] ^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 4. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/TestMergeSchedulerExternal.java
(at line 130)
[ecj-lint] IndexWriter writer = new IndexWriter(dir, iwc);
[ecj-lint] ^^
[ecj-lint] Resource leak: 'writer' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 5. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestCachingTokenFilter.java
(at line 120)
[ecj-lint] Analyzer analyzer = new MockAnalyzer(random());
[ecj-lint]
[ecj-lint] Resource leak: 'analyzer' is never closed
[ecj-lint] --
[ecj-lint] 6. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestCachingTokenFilter.java
(at line 122)
[ecj-lint] CachingTokenFilter buffer = new CachingTokenFilter(input);
[ecj-lint]^^
[ecj-lint] Resource leak: 'buffer' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 7. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
(at line 29)
[ecj-lint] CharFilter cs = new CharFilter1(new StringReader(""));
[ecj-lint]^^
[ecj-lint] Resource leak: 'cs' is never closed
[ecj-lint] --
[ecj-lint] 8. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
(at line 34)
[ecj-lint] CharFilter cs = new CharFilter2(new StringReader(""));
[ecj-lint]^^
[ecj-lint] Resource leak: 'cs' is never closed
[ecj-lint] --
[ecj-lint] 9. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
(at line 39)
[ecj-lint] CharFilter cs = new CharFilter2(new CharFilter1(new
StringReader("")));
[ecj-lint]^^
[ecj-lint] Resource leak: 'cs' is never closed
[ecj-lint] --
[ecj-lint] 10. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
(at line 44)
[ecj-lint] CharFilter cs = new CharFilter1(new CharFilter1(new
StringReader("")));
[ecj-lint]^^
[ecj-lint] Resource leak: 'cs' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 11. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestDelegatingAnalyzerWrapper.java
(at line 39)
[ecj-lint] DelegatingAnalyzerWrapper w2 = new
DelegatingAnalyzerWrapper(Analyzer.GLOBAL_REUSE_STRATEGY) {
[ecj-lint] ^^
[ecj-lint] Resource leak: 'w2' is never closed
[ecj-lint] --
[ecj-lint] 12. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestDelegatingAnalyzerWrapper.java
(at line 50)
[ecj-lint] DelegatingAnalyzerWrapper w1 = new
DelegatingAnalyzerWrapper(Analyzer.GLOBAL_REUSE_STRATEGY) {
[ecj-lint] ^^
[ecj-lint] Resource leak: 'w1' is never closed
[ecj-lint] --
[ecj-lint] 13. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestDelegatingAnalyzerWrapper.java
(at line 71)
[ecj-lint] DelegatingAnalyzerWrapper w1 = new
DelegatingAnalyzerWrapper(Analyzer.GLOBAL_REUSE_STRATEGY) {
[ecj-lint] ^^
[ecj-lint] Resource
[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 430 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/430/
All tests passed
Build Log:
[...truncated 53650 lines...]
-ecj-javadoc-lint-tests:
[mkdir] Created dir: /tmp/ecj1756921274
[ecj-lint] Compiling 535 source files to /tmp/ecj1756921274
[ecj-lint] --
[ecj-lint] 1. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/lucene/core/src/test/org/apache/lucene/TestAssertions.java
(at line 44)
[ecj-lint] new TestTokenStream1();
[ecj-lint] ^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] 2. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/lucene/core/src/test/org/apache/lucene/TestAssertions.java
(at line 45)
[ecj-lint] new TestTokenStream2();
[ecj-lint] ^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] 3. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/lucene/core/src/test/org/apache/lucene/TestAssertions.java
(at line 47)
[ecj-lint] new TestTokenStream3();
[ecj-lint] ^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 4. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/lucene/core/src/test/org/apache/lucene/TestMergeSchedulerExternal.java
(at line 130)
[ecj-lint] IndexWriter writer = new IndexWriter(dir, iwc);
[ecj-lint] ^^
[ecj-lint] Resource leak: 'writer' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 5. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestCachingTokenFilter.java
(at line 120)
[ecj-lint] Analyzer analyzer = new MockAnalyzer(random());
[ecj-lint]
[ecj-lint] Resource leak: 'analyzer' is never closed
[ecj-lint] --
[ecj-lint] 6. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestCachingTokenFilter.java
(at line 122)
[ecj-lint] CachingTokenFilter buffer = new CachingTokenFilter(input);
[ecj-lint]^^
[ecj-lint] Resource leak: 'buffer' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 7. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
(at line 29)
[ecj-lint] CharFilter cs = new CharFilter1(new StringReader(""));
[ecj-lint]^^
[ecj-lint] Resource leak: 'cs' is never closed
[ecj-lint] --
[ecj-lint] 8. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
(at line 34)
[ecj-lint] CharFilter cs = new CharFilter2(new StringReader(""));
[ecj-lint]^^
[ecj-lint] Resource leak: 'cs' is never closed
[ecj-lint] --
[ecj-lint] 9. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
(at line 39)
[ecj-lint] CharFilter cs = new CharFilter2(new CharFilter1(new
StringReader("")));
[ecj-lint]^^
[ecj-lint] Resource leak: 'cs' is never closed
[ecj-lint] --
[ecj-lint] 10. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
(at line 44)
[ecj-lint] CharFilter cs = new CharFilter1(new CharFilter1(new
StringReader("")));
[ecj-lint]^^
[ecj-lint] Resource leak: 'cs' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 11. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestDelegatingAnalyzerWrapper.java
(at line 39)
[ecj-lint] DelegatingAnalyzerWrapper w2 = new
DelegatingAnalyzerWrapper(Analyzer.GLOBAL_REUSE_STRATEGY) {
[ecj-lint] ^^
[ecj-lint] Resource leak: 'w2' is never closed
[ecj-lint] --
[ecj-lint] 12. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestDelegatingAnalyzerWrapper.java
(at line 50)
[ecj-lint] DelegatingAnalyzerWrapper w1 = new
DelegatingAnalyzerWrapper(Analyzer.GLOBAL_REUSE_STRATEGY) {
[ecj-lint] ^^
[ecj-lint] Resource leak: 'w1' is never closed
[ecj-lint] --
[ecj-lint] 13. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestDelegatingAnalyzerWrapper.java
(at line 71)
[ecj-lint] DelegatingAnalyzerWrapper
[JENKINS] Lucene-Solr-repro-Java11 - Build # 262 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro-Java11/262/ [...truncated 28 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1914/consoleText [repro] Revision: cb94eeb4919ff6484f186f534377d9ad9b24c33c [repro] Ant options: -Dtests.multiplier=2 -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt [repro] Repro line: ant test -Dtestcase=HdfsAutoAddReplicasIntegrationTest -Dtests.method=testSimple -Dtests.seed=62043A287453B5FB -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt -Dtests.locale=en-RW -Dtests.timezone=Europe/Vatican -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] Repro line: ant test -Dtestcase=CdcrReplicationHandlerTest -Dtests.method=testReplicationWithBufferedUpdates -Dtests.seed=62043A287453B5FB -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt -Dtests.locale=he -Dtests.timezone=Europe/Luxembourg -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] git rev-parse --abbrev-ref HEAD [repro] git rev-parse HEAD [repro] Initial local git branch/revision: 6dea203d11feb8c047da883131aacccb3a949042 [repro] git fetch [...truncated 7 lines...] [repro] git checkout cb94eeb4919ff6484f186f534377d9ad9b24c33c [...truncated 2 lines...] [repro] git merge --ff-only [...truncated 1 lines...] [repro] ant clean [...truncated 6 lines...] [repro] Test suites by module: [repro]solr/core [repro] HdfsAutoAddReplicasIntegrationTest [repro] CdcrReplicationHandlerTest [repro] ant compile-test [...truncated 3315 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=10 -Dtests.class="*.HdfsAutoAddReplicasIntegrationTest|*.CdcrReplicationHandlerTest" -Dtests.showOutput=onerror -Dtests.multiplier=2 -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt -Dtests.seed=62043A287453B5FB -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt -Dtests.locale=en-RW -Dtests.timezone=Europe/Vatican -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [...truncated 11077 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 1/5 failed: org.apache.solr.cloud.cdcr.CdcrReplicationHandlerTest [repro] 2/5 failed: org.apache.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest [repro] git checkout 6dea203d11feb8c047da883131aacccb3a949042 [...truncated 2 lines...] [repro] Exiting with code 256 [...truncated 6 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13663) XML Query Parser to Support SpanPositionRangeQuery
[
https://issues.apache.org/jira/browse/SOLR-13663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896608#comment-16896608
]
Lucene/Solr QA commented on SOLR-13663:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
51s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 1m 17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 1m 17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 1m 17s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m
4s{color} | {color:green} queryparser in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 5m 15s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-13663 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12976220/SOLR-13663.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP
Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / 6dea203 |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 20 2018 |
| Default Java | LTS |
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/517/testReport/ |
| modules | C: lucene/queryparser U: lucene/queryparser |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/517/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> XML Query Parser to Support SpanPositionRangeQuery
> --
>
> Key: SOLR-13663
> URL: https://issues.apache.org/jira/browse/SOLR-13663
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: 8.2
>Reporter: Alessandro Benedetti
>Priority: Major
> Attachments: SOLR-13663.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently the XML Query Parser support a vast array of span queries,
> including the SpanFirstQuery, but it doesn't support the generic
> SpanPositionRangeQuery.
> < SpanPositionRange start="2" end="3">
> prejudice
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 1406 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/1406/ No tests ran. Build Log: [...truncated 24456 lines...] [asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [java] Processed 2590 links (2119 relative) to 3409 anchors in 259 files [echo] Validated Links & Anchors via: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr-ref-guide/bare-bones-html/ -dist-changes: [copy] Copying 4 files to /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/changes package: -unpack-solr-tgz: -ensure-solr-tgz-exists: [mkdir] Created dir: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked [untar] Expanding: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/solr-9.0.0.tgz into /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked generate-maven-artifacts: resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.
[GitHub] [lucene-solr] noblepaul opened a new pull request #813: Refactor Cache config to lazily load the the class
noblepaul opened a new pull request #813: Refactor Cache config to lazily load the the class URL: https://github.com/apache/lucene-solr/pull/813 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13659) Refactor Cache config to lazily load the the class
[ https://issues.apache.org/jira/browse/SOLR-13659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-13659: -- Summary: Refactor Cache config to lazily load the the class (was: Cache implementations should be loadable/reloadable from runtime libraries) > Refactor Cache config to lazily load the the class > --- > > Key: SOLR-13659 > URL: https://issues.apache.org/jira/browse/SOLR-13659 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > > Cache implementation class is currently loaded from the SolrConfig > classloader -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13658) Discuss adding the new "var" construct to the forbidden API list.
[
https://issues.apache.org/jira/browse/SOLR-13658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896585#comment-16896585
]
Noble Paul commented on SOLR-13658:
---
+1
I'm not against the user of "var" keyword itself. But until we move to 9_x the
Cherry picks are going to be a problem.
> Discuss adding the new "var" construct to the forbidden API list.
> -
>
> Key: SOLR-13658
> URL: https://issues.apache.org/jira/browse/SOLR-13658
> Project: Solr
> Issue Type: Wish
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> Personally, I'm strongly against allowing the "var" construct in Lucene/Solr
> code. I think it's a wonderful opportunity to introduce bugs that won't be
> found until runtime as well as making maintainence significantly harder. I
> don't even think for a project like Solr it would save any time overall...
> So let's discuss this ahead of time and see if we can reach a consensus. I'll
> start the discussion off:
> My baseline argument is that for a large complex project, especially ones
> with many different people coding, I want the compiler to give me all the
> help possible. And the "var" construct takes away some of that help.
> I’ve seen this argument go around at least 4 times in my career. The argument
> that “it takes longer to write if you have to type all this stuff” is bogus.
> Last I knew, 80% of the time spent is in maintaining/reading it. So the
> argument “I can write faster” means I can save some fraction of the 20% of
> the time writing the original code but spend many times that figuring out
> what the code is actually doing the other 80% of the time.
> The IDE makes _writing_ this slightly faster, admittedly.
> {code:java}
> Whatever what = new Whatever();
> var kidding = what.getComplex();
> var blivet = kidding.get("stuff");
> {code}
> But once that’s done, if I’m reading the code again I don't have any clue what
> {code:java}
> kidding or blivet
> {code}
> are. Here's the signature for getComplex:
> {code:java}
> Map> getComplex()
> {code}
> I have to go over to the definition (which I admit is easier than it used to
> be in the bad old days, but still) to find out.
> HERE'S THE PART I REALLY OBJECT TO!
> The above I could probably live with, maybe we could get the InteliJ
> developers and see if they can make hover show the inference. What I will
> kick and scream about is introducing bugs that are not found until runtime.
> Even this obvious stupidity fails with a ClassCastException:
> {code:java}
> var corny = new TreeMap();
> corny.put("one", "two");
> corny.get(1);
> {code}
> But it's much worse when using classes from somewhere else. For instance,
> change the underlying class in the first example to return
> {code:java}
> Map>{code}
> .
> This code that used to work now throws an error, _but it compiles_.
> {code:java}
> var kidding = what.getComplex();
> var blivet = kidding.get("stuff");
> var blah = kidding.get("stuff").get(1); // generates ClassCastException:
> class java.lang.String cannot be cast to class java.lang.Integer
> {code}
> So in order to save some time writing (that I claim will be lost multiple
> times over when maintaining the code) we'll introduce run-time errors that
> will take a bunch _more_ time to figure out, and won’t be found during unit
> tests unless and until we have complete code coverage.
> If there's a way to insure that this kind of thing can't get into the code
> and we implement that, I could be persuaded, but let's make that an explicit
> requirement (and find a suitable task for the build system, precommit or
> whatever).
> The floor is open...
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13658) Discuss adding the new "var" construct to the forbidden API list.
[
https://issues.apache.org/jira/browse/SOLR-13658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896578#comment-16896578
]
David Smiley commented on SOLR-13658:
-
+1 to prevent use of "var" until Solr 8 is finished. The dubious benefit is
not worth the backport pain. I've had to fix this in one issue. After Solr 8
can be brought up at a future time but I'm hesitant.
> Discuss adding the new "var" construct to the forbidden API list.
> -
>
> Key: SOLR-13658
> URL: https://issues.apache.org/jira/browse/SOLR-13658
> Project: Solr
> Issue Type: Wish
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> Personally, I'm strongly against allowing the "var" construct in Lucene/Solr
> code. I think it's a wonderful opportunity to introduce bugs that won't be
> found until runtime as well as making maintainence significantly harder. I
> don't even think for a project like Solr it would save any time overall...
> So let's discuss this ahead of time and see if we can reach a consensus. I'll
> start the discussion off:
> My baseline argument is that for a large complex project, especially ones
> with many different people coding, I want the compiler to give me all the
> help possible. And the "var" construct takes away some of that help.
> I’ve seen this argument go around at least 4 times in my career. The argument
> that “it takes longer to write if you have to type all this stuff” is bogus.
> Last I knew, 80% of the time spent is in maintaining/reading it. So the
> argument “I can write faster” means I can save some fraction of the 20% of
> the time writing the original code but spend many times that figuring out
> what the code is actually doing the other 80% of the time.
> The IDE makes _writing_ this slightly faster, admittedly.
> {code:java}
> Whatever what = new Whatever();
> var kidding = what.getComplex();
> var blivet = kidding.get("stuff");
> {code}
> But once that’s done, if I’m reading the code again I don't have any clue what
> {code:java}
> kidding or blivet
> {code}
> are. Here's the signature for getComplex:
> {code:java}
> Map> getComplex()
> {code}
> I have to go over to the definition (which I admit is easier than it used to
> be in the bad old days, but still) to find out.
> HERE'S THE PART I REALLY OBJECT TO!
> The above I could probably live with, maybe we could get the InteliJ
> developers and see if they can make hover show the inference. What I will
> kick and scream about is introducing bugs that are not found until runtime.
> Even this obvious stupidity fails with a ClassCastException:
> {code:java}
> var corny = new TreeMap();
> corny.put("one", "two");
> corny.get(1);
> {code}
> But it's much worse when using classes from somewhere else. For instance,
> change the underlying class in the first example to return
> {code:java}
> Map>{code}
> .
> This code that used to work now throws an error, _but it compiles_.
> {code:java}
> var kidding = what.getComplex();
> var blivet = kidding.get("stuff");
> var blah = kidding.get("stuff").get(1); // generates ClassCastException:
> class java.lang.String cannot be cast to class java.lang.Integer
> {code}
> So in order to save some time writing (that I claim will be lost multiple
> times over when maintaining the code) we'll introduce run-time errors that
> will take a bunch _more_ time to figure out, and won’t be found during unit
> tests unless and until we have complete code coverage.
> If there's a way to insure that this kind of thing can't get into the code
> and we implement that, I could be persuaded, but let's make that an explicit
> requirement (and find a suitable task for the build system, precommit or
> whatever).
> The floor is open...
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-8.2-Linux (64bit/jdk-11.0.3) - Build # 496 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.2-Linux/496/ Java: 64bit/jdk-11.0.3 -XX:-UseCompressedOops -XX:+UseSerialGC All tests passed Build Log: [...truncated 5237 lines...] [junit4] JVM J1: stdout was not empty, see: /home/jenkins/workspace/Lucene-Solr-8.2-Linux/lucene/build/backward-codecs/test/temp/junit4-J1-20190730_221138_72310714084521140317863.sysout [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] # [junit4] # A fatal error has been detected by the Java Runtime Environment: [junit4] # [junit4] # SIGSEGV (0xb) at pc=0x7fc1d9cddc7c, pid=26155, tid=26599 [junit4] # [junit4] # JRE version: OpenJDK Runtime Environment (11.0.3+7) (build 11.0.3+7) [junit4] # Java VM: OpenJDK 64-Bit Server VM (11.0.3+7, mixed mode, tiered, serial gc, linux-amd64) [junit4] # Problematic frame: [junit4] # V [libjvm.so+0xd05c7c] PhaseIdealLoop::split_up(Node*, Node*, Node*) [clone .part.39]+0x47c [junit4] # [junit4] # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again [junit4] # [junit4] # An error report file with more information is saved as: [junit4] # /home/jenkins/workspace/Lucene-Solr-8.2-Linux/lucene/build/backward-codecs/test/J1/hs_err_pid26155.log [junit4] # [junit4] # Compiler replay data is saved as: [junit4] # /home/jenkins/workspace/Lucene-Solr-8.2-Linux/lucene/build/backward-codecs/test/J1/replay_pid26155.log [junit4] # [junit4] # If you would like to submit a bug report, please visit: [junit4] # https://github.com/AdoptOpenJDK/openjdk-build/issues [junit4] # [junit4] <<< JVM J1: EOF [...truncated 31 lines...] [junit4] ERROR: JVM J1 ended with an exception, command line: /home/jenkins/tools/java/64bit/jdk-11.0.3/bin/java -XX:-UseCompressedOops -XX:+UseSerialGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/jenkins/workspace/Lucene-Solr-8.2-Linux/heapdumps -ea -esa --illegal-access=deny -Dtests.prefix=tests -Dtests.seed=FD73254942392686 -Xmx512M -Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random -Dtests.postingsformat=random -Dtests.docvaluesformat=random -Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=8.2.1 -Dtests.cleanthreads=perMethod -Djava.util.logging.config.file=/home/jenkins/workspace/Lucene-Solr-8.2-Linux/lucene/tools/junit4/logging.properties -Dtests.nightly=false -Dtests.weekly=false -Dtests.monster=false -Dtests.slow=true -Dtests.asserts=true -Dtests.multiplier=3 -DtempDir=./temp -Djava.io.tmpdir=./temp -Dcommon.dir=/home/jenkins/workspace/Lucene-Solr-8.2-Linux/lucene -Dclover.db.dir=/home/jenkins/workspace/Lucene-Solr-8.2-Linux/lucene/build/clover/db -Djava.security.policy=/home/jenkins/workspace/Lucene-Solr-8.2-Linux/lucene/tools/junit4/tests.policy -Dtests.LUCENE_VERSION=8.2.1 -Djetty.testMode=1 -Djetty.insecurerandom=1 -Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory -Djava.awt.headless=true -Djdk.map.althashing.threshold=0 -Dtests.src.home=/home/jenkins/workspace/Lucene-Solr-8.2-Linux -Djava.security.egd=file:/dev/./urandom -Djunit4.childvm.cwd=/home/jenkins/workspace/Lucene-Solr-8.2-Linux/lucene/build/backward-codecs/test/J1 -Djunit4.tempDir=/home/jenkins/workspace/Lucene-Solr-8.2-Linux/lucene/build/backward-codecs/test/temp -Djunit4.childvm.id=1 -Djunit4.childvm.count=3 -Dfile.encoding=US-ASCII -Djava.security.manager=org.apache.lucene.util.TestSecurityManager -Dtests.filterstacks=true -Dtests.leaveTemporary=false -Dtests.badapples=false -classpath
[jira] [Commented] (SOLR-13659) Cache implementations should be loadable/reloadable from runtime libraries
[ https://issues.apache.org/jira/browse/SOLR-13659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896543#comment-16896543 ] ASF subversion and git services commented on SOLR-13659: Commit 0d76ab740ff9214c7ce4629aee7d18cda10553d9 in lucene-solr's branch refs/heads/jira/SOLR-13659 from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=0d76ab7 ] SOLR-13659: fixing tests > Cache implementations should be loadable/reloadable from runtime libraries > -- > > Key: SOLR-13659 > URL: https://issues.apache.org/jira/browse/SOLR-13659 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > > Cache implementation class is currently loaded from the SolrConfig > classloader -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13664) SolrTestCaseJ4.deleteCore() does not delete/clean dataDir
[
https://issues.apache.org/jira/browse/SOLR-13664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-13664:
Attachment: SOLR-13664.patch
Status: Open (was: Open)
Here's an updated patch with a fix that i _think_ is good, but i'm still in the
process of testing and I want spend some more time thinking through possible
ramifications on third party subclasses.
The basic idea is that {{deleteCore()}} now nulls out the {{initCoreDataDir}}
variable -- w/o doing any actual IO deletion. We still trust/rely on
{{TestRuleTemporaryFilesCleanup}} to do it's job of deleting these temp dirs if
the test succeeds. Any place in {{SolrTestCaseJ4}} that currently depends on
{{initCoreDataDir}} being set now uses a private helper method to ensure it's
initialized.
> SolrTestCaseJ4.deleteCore() does not delete/clean dataDir
> --
>
> Key: SOLR-13664
> URL: https://issues.apache.org/jira/browse/SOLR-13664
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13664.patch, SOLR-13664.patch
>
>
> In spite of what it's javadocs say, {{SolrTestCaseJ4.deleteCore()}} does
> nothing to delete the dataDir used by the TestHarness
> The git history is a bit murky, so i'm not entirely certain when this stoped
> working, but I suspect it happened as part of the overall cleanup regarding
> test temp dirs and the use of {{LuceneTestCase.createTempDir(...) ->
> TestRuleTemporaryFilesCleanup}}
> While this is not problematic in many test classes, where a single
> {{initCore(...) is called in a {{@BeforeClass}} and the test then re-uses
> that SolrCore for all test methods and relies on {{@AfterClass
> SolrTestCaseJ4.teardownTestCases()}} to call {{deleteCore()}}, it's
> problematic in test classes where {{deleteCore()}} is explicitly called in an
> {{@After}} method to ensure a unique core (w/unique dataDir) is used for each
> test method.
> (there are currently about 61 tests that call {{deleteCore()}} directly)
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-master - Build # 3466 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3466/
All tests passed
Build Log:
[...truncated 53669 lines...]
-ecj-javadoc-lint-tests:
[mkdir] Created dir: /tmp/ecj238168431
[ecj-lint] Compiling 535 source files to /tmp/ecj238168431
[ecj-lint] --
[ecj-lint] 1. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/TestAssertions.java
(at line 44)
[ecj-lint] new TestTokenStream1();
[ecj-lint] ^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] 2. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/TestAssertions.java
(at line 45)
[ecj-lint] new TestTokenStream2();
[ecj-lint] ^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] 3. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/TestAssertions.java
(at line 47)
[ecj-lint] new TestTokenStream3();
[ecj-lint] ^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 4. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/TestMergeSchedulerExternal.java
(at line 130)
[ecj-lint] IndexWriter writer = new IndexWriter(dir, iwc);
[ecj-lint] ^^
[ecj-lint] Resource leak: 'writer' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 5. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestCachingTokenFilter.java
(at line 120)
[ecj-lint] Analyzer analyzer = new MockAnalyzer(random());
[ecj-lint]
[ecj-lint] Resource leak: 'analyzer' is never closed
[ecj-lint] --
[ecj-lint] 6. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestCachingTokenFilter.java
(at line 122)
[ecj-lint] CachingTokenFilter buffer = new CachingTokenFilter(input);
[ecj-lint]^^
[ecj-lint] Resource leak: 'buffer' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 7. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
(at line 29)
[ecj-lint] CharFilter cs = new CharFilter1(new StringReader(""));
[ecj-lint]^^
[ecj-lint] Resource leak: 'cs' is never closed
[ecj-lint] --
[ecj-lint] 8. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
(at line 34)
[ecj-lint] CharFilter cs = new CharFilter2(new StringReader(""));
[ecj-lint]^^
[ecj-lint] Resource leak: 'cs' is never closed
[ecj-lint] --
[ecj-lint] 9. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
(at line 39)
[ecj-lint] CharFilter cs = new CharFilter2(new CharFilter1(new
StringReader("")));
[ecj-lint]^^
[ecj-lint] Resource leak: 'cs' is never closed
[ecj-lint] --
[ecj-lint] 10. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
(at line 44)
[ecj-lint] CharFilter cs = new CharFilter1(new CharFilter1(new
StringReader("")));
[ecj-lint]^^
[ecj-lint] Resource leak: 'cs' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 11. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestDelegatingAnalyzerWrapper.java
(at line 39)
[ecj-lint] DelegatingAnalyzerWrapper w2 = new
DelegatingAnalyzerWrapper(Analyzer.GLOBAL_REUSE_STRATEGY) {
[ecj-lint] ^^
[ecj-lint] Resource leak: 'w2' is never closed
[ecj-lint] --
[ecj-lint] 12. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestDelegatingAnalyzerWrapper.java
(at line 50)
[ecj-lint] DelegatingAnalyzerWrapper w1 = new
DelegatingAnalyzerWrapper(Analyzer.GLOBAL_REUSE_STRATEGY) {
[ecj-lint] ^^
[ecj-lint] Resource leak: 'w1' is never closed
[ecj-lint] --
[ecj-lint] 13. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestDelegatingAnalyzerWrapper.java
(at line 71)
[ecj-lint] DelegatingAnalyzerWrapper w1 = new
DelegatingAnalyzerWrapper(Analyzer.GLOBAL_REUSE_STRATEGY) {
[ecj-lint] ^^
[ecj-lint] Resource
[jira] [Commented] (LUCENE-8369) Remove the spatial module as it is obsolete
[
https://issues.apache.org/jira/browse/LUCENE-8369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896516#comment-16896516
]
Nicholas Knize commented on LUCENE-8369:
[~dsmiley] yeah, that seems to be the case more often than not. So under that
construct we would move {{LatLonPointInPolygonQuery}} to the spatial module
which even further fragments everything.
Seems this discussion gains some activity for a short bit, stalls for a year or
two, gains some more activity, then stalls again. I know it's no fun to engage
in the bikeshed activity, but it would be nice to figure out a path forward;
even if that means find a solution for the 9.0 release and just leave
{{LatLonShape}} and {{XYShape}} in sandbox for the rest of the 8.x releases.
> Remove the spatial module as it is obsolete
> ---
>
> Key: LUCENE-8369
> URL: https://issues.apache.org/jira/browse/LUCENE-8369
> Project: Lucene - Core
> Issue Type: Task
> Components: modules/spatial
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: LUCENE-8369.patch
>
>
> The "spatial" module is at this juncture nearly empty with only a couple
> utilities that aren't used by anything in the entire codebase --
> GeoRelationUtils, and MortonEncoder. Perhaps it should have been removed
> earlier in LUCENE-7664 which was the removal of GeoPointField which was
> essentially why the module existed. Better late than never.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13665) Connecting to ZK on SSL port (secureClient: ClassNotDef found error)
[ https://issues.apache.org/jira/browse/SOLR-13665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896499#comment-16896499 ] Jan Høydahl commented on SOLR-13665: Thanks for working on this. You may also see SOLR-7893 > Connecting to ZK on SSL port (secureClient: ClassNotDef found error) > > > Key: SOLR-13665 > URL: https://issues.apache.org/jira/browse/SOLR-13665 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 8.2 >Reporter: Jörn Franke >Priority: Major > > > I managed to setup Zookeeper 3.5.5 with secure Client enabled and configured > in solr.in.sh the zookeeper properties to use that port, which offers SSL. > However, I see the following error in the logfiles when starting up Solr: > 2019-07-30 14:59:09.704 INFO (main) [ ] o.a.z.c.X509Util Setting -D > jdk.tls.rejectClientInitiatedRenegotiation=true to disable client-initiated > TLS renegotiation > 2019-07-30 14:59:09.710 ERROR (main) [ ] o.a.s.s.SolrDispatchFilter Could > not start Solr. Check solr/home property and the logs > 2019-07-30 14:59:09.743 ERROR (main) [ ] o.a.s.c.SolrCore > null:java.lang.NoClassDefFoundError: io/netty/channel/ChannelHandler > at java.base/java.lang.Class.forName0(Native Method) > at java.base/java.lang.Class.forName(Class.java:315) > at > org.apache.zookeeper.ZooKeeper.getClientCnxnSocket(ZooKeeper.java:3063) > at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:883) > at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:801) > at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:950) > at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:688) > at > org.apache.solr.common.cloud.SolrZooKeeper.(SolrZooKeeper.java:43) > at > org.apache.solr.common.cloud.ZkClientConnectionStrategy.createSolrZooKeeper(ZkClientConnectionStrategy.java:105) > at > org.apache.solr.common.cloud.DefaultConnectionStrategy.connect(DefaultConnectionStrategy.java:37) > at > org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:166) > at > org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:125) > at > org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:120) > at > org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:107) > at > org.apache.solr.servlet.SolrDispatchFilter.loadNodeConfig(SolrDispatchFilter.java:282) > at > org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:259) > at > org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:181) > at > org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:136) > at > org.eclipse.jetty.servlet.ServletHandler.lambda$initialize$0(ServletHandler.java:750) > at > java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948) > at > java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734) > at > java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734) > at > java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658) > at > org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:744) > at > org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:369) > at > org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1497) > at > org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1459) > at > org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:854) > at > org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:278) > at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:545) > at > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) > at > org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:46) > at > org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:192) > at > org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:510) > at > org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:153) > at > org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:172) > at > org.eclipse.jetty.deploy.providers.WebAppProvider.fileAdded(WebAppProvider.java:436) > at > org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:65) > at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:610) > at
[jira] [Commented] (SOLR-13665) Connecting to ZK on SSL port (secureClient: ClassNotDef found error)
[ https://issues.apache.org/jira/browse/SOLR-13665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896476#comment-16896476 ] Jörn Franke commented on SOLR-13665: I will experiment a bit and see if a smaller library is possible. I may need a few days due to other tasks. I hope then I can come up with some example instructions as well. > Connecting to ZK on SSL port (secureClient: ClassNotDef found error) > > > Key: SOLR-13665 > URL: https://issues.apache.org/jira/browse/SOLR-13665 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 8.2 >Reporter: Jörn Franke >Priority: Major > > > I managed to setup Zookeeper 3.5.5 with secure Client enabled and configured > in solr.in.sh the zookeeper properties to use that port, which offers SSL. > However, I see the following error in the logfiles when starting up Solr: > 2019-07-30 14:59:09.704 INFO (main) [ ] o.a.z.c.X509Util Setting -D > jdk.tls.rejectClientInitiatedRenegotiation=true to disable client-initiated > TLS renegotiation > 2019-07-30 14:59:09.710 ERROR (main) [ ] o.a.s.s.SolrDispatchFilter Could > not start Solr. Check solr/home property and the logs > 2019-07-30 14:59:09.743 ERROR (main) [ ] o.a.s.c.SolrCore > null:java.lang.NoClassDefFoundError: io/netty/channel/ChannelHandler > at java.base/java.lang.Class.forName0(Native Method) > at java.base/java.lang.Class.forName(Class.java:315) > at > org.apache.zookeeper.ZooKeeper.getClientCnxnSocket(ZooKeeper.java:3063) > at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:883) > at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:801) > at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:950) > at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:688) > at > org.apache.solr.common.cloud.SolrZooKeeper.(SolrZooKeeper.java:43) > at > org.apache.solr.common.cloud.ZkClientConnectionStrategy.createSolrZooKeeper(ZkClientConnectionStrategy.java:105) > at > org.apache.solr.common.cloud.DefaultConnectionStrategy.connect(DefaultConnectionStrategy.java:37) > at > org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:166) > at > org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:125) > at > org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:120) > at > org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:107) > at > org.apache.solr.servlet.SolrDispatchFilter.loadNodeConfig(SolrDispatchFilter.java:282) > at > org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:259) > at > org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:181) > at > org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:136) > at > org.eclipse.jetty.servlet.ServletHandler.lambda$initialize$0(ServletHandler.java:750) > at > java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948) > at > java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734) > at > java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734) > at > java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658) > at > org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:744) > at > org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:369) > at > org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1497) > at > org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1459) > at > org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:854) > at > org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:278) > at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:545) > at > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) > at > org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:46) > at > org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:192) > at > org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:510) > at > org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:153) > at > org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:172) > at > org.eclipse.jetty.deploy.providers.WebAppProvider.fileAdded(WebAppProvider.java:436) > at >
[jira] [Commented] (SOLR-13665) Connecting to ZK on SSL port (secureClient: ClassNotDef found error)
[ https://issues.apache.org/jira/browse/SOLR-13665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896471#comment-16896471 ] Shawn Heisey commented on SOLR-13665: - Yes, the netty jar probably needs to be added to solrj-libs as well as the webapp. I wonder if the SSL functionality that ZK needs can be satisfied by a smaller jar than netty-all. The Solr download is already quite large. The specific class that was missing in the error above is in the netty-transport jar, but I have no idea whether that jar contains everything that ZK needs for SSL: https://mvnrepository.com/artifact/io.netty/netty-transport/4.1.38.Final > Connecting to ZK on SSL port (secureClient: ClassNotDef found error) > > > Key: SOLR-13665 > URL: https://issues.apache.org/jira/browse/SOLR-13665 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 8.2 >Reporter: Jörn Franke >Priority: Major > > > I managed to setup Zookeeper 3.5.5 with secure Client enabled and configured > in solr.in.sh the zookeeper properties to use that port, which offers SSL. > However, I see the following error in the logfiles when starting up Solr: > 2019-07-30 14:59:09.704 INFO (main) [ ] o.a.z.c.X509Util Setting -D > jdk.tls.rejectClientInitiatedRenegotiation=true to disable client-initiated > TLS renegotiation > 2019-07-30 14:59:09.710 ERROR (main) [ ] o.a.s.s.SolrDispatchFilter Could > not start Solr. Check solr/home property and the logs > 2019-07-30 14:59:09.743 ERROR (main) [ ] o.a.s.c.SolrCore > null:java.lang.NoClassDefFoundError: io/netty/channel/ChannelHandler > at java.base/java.lang.Class.forName0(Native Method) > at java.base/java.lang.Class.forName(Class.java:315) > at > org.apache.zookeeper.ZooKeeper.getClientCnxnSocket(ZooKeeper.java:3063) > at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:883) > at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:801) > at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:950) > at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:688) > at > org.apache.solr.common.cloud.SolrZooKeeper.(SolrZooKeeper.java:43) > at > org.apache.solr.common.cloud.ZkClientConnectionStrategy.createSolrZooKeeper(ZkClientConnectionStrategy.java:105) > at > org.apache.solr.common.cloud.DefaultConnectionStrategy.connect(DefaultConnectionStrategy.java:37) > at > org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:166) > at > org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:125) > at > org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:120) > at > org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:107) > at > org.apache.solr.servlet.SolrDispatchFilter.loadNodeConfig(SolrDispatchFilter.java:282) > at > org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:259) > at > org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:181) > at > org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:136) > at > org.eclipse.jetty.servlet.ServletHandler.lambda$initialize$0(ServletHandler.java:750) > at > java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948) > at > java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734) > at > java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734) > at > java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658) > at > org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:744) > at > org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:369) > at > org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1497) > at > org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1459) > at > org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:854) > at > org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:278) > at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:545) > at > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) > at > org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:46) > at > org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:192) > at > org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:510) > at > org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:153) >
[jira] [Commented] (SOLR-13659) Cache implementations should be loadable/reloadable from runtime libraries
[ https://issues.apache.org/jira/browse/SOLR-13659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896439#comment-16896439 ] ASF subversion and git services commented on SOLR-13659: Commit 0f0a7cd84523b2518dadfe986385f19ce00a3876 in lucene-solr's branch refs/heads/jira/SOLR-13659 from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=0f0a7cd ] SOLR-13659: initial commit > Cache implementations should be loadable/reloadable from runtime libraries > -- > > Key: SOLR-13659 > URL: https://issues.apache.org/jira/browse/SOLR-13659 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > > Cache implementation class is currently loaded from the SolrConfig > classloader -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13659) Cache implementations should be loadable/reloadable from runtime libraries
[ https://issues.apache.org/jira/browse/SOLR-13659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896437#comment-16896437 ] ASF subversion and git services commented on SOLR-13659: Commit 2159d23badd4276ba1a4f5e60a11a910980f4f86 in lucene-solr's branch refs/heads/jira/SOLR-13659 from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2159d23 ] SOLR-13659: initial commit > Cache implementations should be loadable/reloadable from runtime libraries > -- > > Key: SOLR-13659 > URL: https://issues.apache.org/jira/browse/SOLR-13659 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > > Cache implementation class is currently loaded from the SolrConfig > classloader -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13659) Cache implementations should be loadable/reloadable from runtime libraries
[ https://issues.apache.org/jira/browse/SOLR-13659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896425#comment-16896425 ] ASF subversion and git services commented on SOLR-13659: Commit 2bfb73a84d762c9786b65d1dc8bec20d3a67b2a4 in lucene-solr's branch refs/heads/jira/SOLR-13659 from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2bfb73a ] SOLR-13659: initial commit > Cache implementations should be loadable/reloadable from runtime libraries > -- > > Key: SOLR-13659 > URL: https://issues.apache.org/jira/browse/SOLR-13659 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > > Cache implementation class is currently loaded from the SolrConfig > classloader -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13659) Cache implementations should be loadable/reloadable from runtime libraries
[ https://issues.apache.org/jira/browse/SOLR-13659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896419#comment-16896419 ] ASF subversion and git services commented on SOLR-13659: Commit 89a45ea42ffe64637c24009b8bb42b5d5e6f6521 in lucene-solr's branch refs/heads/jira/SOLR-13659 from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=89a45ea ] SOLR-13659: initial commit > Cache implementations should be loadable/reloadable from runtime libraries > -- > > Key: SOLR-13659 > URL: https://issues.apache.org/jira/browse/SOLR-13659 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > > Cache implementation class is currently loaded from the SolrConfig > classloader -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1914 - Still unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1914/
2 tests failed.
FAILED:
org.apache.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest.testSimple
Error Message:
Waiting for collection testSimple2 Timeout waiting to see state for
collection=testSimple2
:DocCollection(testSimple2//collections/testSimple2/state.json/25)={
"pullReplicas":"0", "replicationFactor":"2", "shards":{ "shard1":{
"range":"8000-", "state":"active", "replicas":{
"core_node3":{
"dataDir":"hdfs://lucene2-us-west.apache.org:36413/solr_hdfs_home/testSimple2/core_node3/data/",
"base_url":"http://127.0.0.1:39903/solr;,
"node_name":"127.0.0.1:39903_solr", "type":"NRT",
"force_set_state":"false",
"ulogDir":"hdfs://lucene2-us-west.apache.org:36413/solr_hdfs_home/testSimple2/core_node3/data/tlog",
"core":"testSimple2_shard1_replica_n1",
"shared_storage":"true", "state":"down"}, "core_node5":{
"dataDir":"hdfs://lucene2-us-west.apache.org:36413/solr_hdfs_home/testSimple2/core_node5/data/",
"base_url":"http://127.0.0.1:33431/solr;,
"node_name":"127.0.0.1:33431_solr", "type":"NRT",
"force_set_state":"false",
"ulogDir":"hdfs://lucene2-us-west.apache.org:36413/solr_hdfs_home/testSimple2/core_node5/data/tlog",
"core":"testSimple2_shard1_replica_n2",
"shared_storage":"true", "state":"active",
"leader":"true"}}}, "shard2":{ "range":"0-7fff",
"state":"active", "replicas":{ "core_node7":{
"dataDir":"hdfs://lucene2-us-west.apache.org:36413/solr_hdfs_home/testSimple2/core_node7/data/",
"base_url":"http://127.0.0.1:39903/solr;,
"node_name":"127.0.0.1:39903_solr", "type":"NRT",
"force_set_state":"false",
"ulogDir":"hdfs://lucene2-us-west.apache.org:36413/solr_hdfs_home/testSimple2/core_node7/data/tlog",
"core":"testSimple2_shard2_replica_n4",
"shared_storage":"true", "state":"down"}, "core_node8":{
"dataDir":"hdfs://lucene2-us-west.apache.org:36413/solr_hdfs_home/testSimple2/core_node8/data/",
"base_url":"http://127.0.0.1:33431/solr;,
"node_name":"127.0.0.1:33431_solr", "type":"NRT",
"force_set_state":"false",
"ulogDir":"hdfs://lucene2-us-west.apache.org:36413/solr_hdfs_home/testSimple2/core_node8/data/tlog",
"core":"testSimple2_shard2_replica_n6",
"shared_storage":"true", "state":"active",
"leader":"true", "router":{"name":"compositeId"},
"maxShardsPerNode":"2", "autoAddReplicas":"true", "nrtReplicas":"2",
"tlogReplicas":"0"} Live Nodes: [127.0.0.1:33431_solr, 127.0.0.1:39917_solr]
Last available state:
DocCollection(testSimple2//collections/testSimple2/state.json/25)={
"pullReplicas":"0", "replicationFactor":"2", "shards":{ "shard1":{
"range":"8000-", "state":"active", "replicas":{
"core_node3":{
"dataDir":"hdfs://lucene2-us-west.apache.org:36413/solr_hdfs_home/testSimple2/core_node3/data/",
"base_url":"http://127.0.0.1:39903/solr;,
"node_name":"127.0.0.1:39903_solr", "type":"NRT",
"force_set_state":"false",
"ulogDir":"hdfs://lucene2-us-west.apache.org:36413/solr_hdfs_home/testSimple2/core_node3/data/tlog",
"core":"testSimple2_shard1_replica_n1",
"shared_storage":"true", "state":"down"}, "core_node5":{
"dataDir":"hdfs://lucene2-us-west.apache.org:36413/solr_hdfs_home/testSimple2/core_node5/data/",
"base_url":"http://127.0.0.1:33431/solr;,
"node_name":"127.0.0.1:33431_solr", "type":"NRT",
"force_set_state":"false",
"ulogDir":"hdfs://lucene2-us-west.apache.org:36413/solr_hdfs_home/testSimple2/core_node5/data/tlog",
"core":"testSimple2_shard1_replica_n2",
"shared_storage":"true", "state":"active",
"leader":"true"}}}, "shard2":{ "range":"0-7fff",
"state":"active", "replicas":{ "core_node7":{
"dataDir":"hdfs://lucene2-us-west.apache.org:36413/solr_hdfs_home/testSimple2/core_node7/data/",
"base_url":"http://127.0.0.1:39903/solr;,
"node_name":"127.0.0.1:39903_solr", "type":"NRT",
"force_set_state":"false",
"ulogDir":"hdfs://lucene2-us-west.apache.org:36413/solr_hdfs_home/testSimple2/core_node7/data/tlog",
"core":"testSimple2_shard2_replica_n4",
"shared_storage":"true", "state":"down"}, "core_node8":{
"dataDir":"hdfs://lucene2-us-west.apache.org:36413/solr_hdfs_home/testSimple2/core_node8/data/",
[jira] [Comment Edited] (SOLR-13665) Connecting to ZK on SSL port (secureClient: ClassNotDef found error)
[ https://issues.apache.org/jira/browse/SOLR-13665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896414#comment-16896414 ] Jörn Franke edited comment on SOLR-13665 at 7/30/19 7:05 PM: - Ok thanks, I will try. Would it make sense to include it in the Solr distribution? That being said, I can also describe in the reference guide some instructions on how to configure it, if wanted/needed. Just point me to some documents on how to update it. Probably the SolrCloud client (included via SolrJ) should also add the library in its classpath. was (Author: jornfranke): Ok thanks, I will try. Would it make sense to include it in the Solr distribution? That being said, I can also describe in the reference guide some instructions on how to configure it, if wanted/needed. Just point me to some documents on how to update it. > Connecting to ZK on SSL port (secureClient: ClassNotDef found error) > > > Key: SOLR-13665 > URL: https://issues.apache.org/jira/browse/SOLR-13665 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 8.2 >Reporter: Jörn Franke >Priority: Major > > > I managed to setup Zookeeper 3.5.5 with secure Client enabled and configured > in solr.in.sh the zookeeper properties to use that port, which offers SSL. > However, I see the following error in the logfiles when starting up Solr: > 2019-07-30 14:59:09.704 INFO (main) [ ] o.a.z.c.X509Util Setting -D > jdk.tls.rejectClientInitiatedRenegotiation=true to disable client-initiated > TLS renegotiation > 2019-07-30 14:59:09.710 ERROR (main) [ ] o.a.s.s.SolrDispatchFilter Could > not start Solr. Check solr/home property and the logs > 2019-07-30 14:59:09.743 ERROR (main) [ ] o.a.s.c.SolrCore > null:java.lang.NoClassDefFoundError: io/netty/channel/ChannelHandler > at java.base/java.lang.Class.forName0(Native Method) > at java.base/java.lang.Class.forName(Class.java:315) > at > org.apache.zookeeper.ZooKeeper.getClientCnxnSocket(ZooKeeper.java:3063) > at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:883) > at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:801) > at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:950) > at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:688) > at > org.apache.solr.common.cloud.SolrZooKeeper.(SolrZooKeeper.java:43) > at > org.apache.solr.common.cloud.ZkClientConnectionStrategy.createSolrZooKeeper(ZkClientConnectionStrategy.java:105) > at > org.apache.solr.common.cloud.DefaultConnectionStrategy.connect(DefaultConnectionStrategy.java:37) > at > org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:166) > at > org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:125) > at > org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:120) > at > org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:107) > at > org.apache.solr.servlet.SolrDispatchFilter.loadNodeConfig(SolrDispatchFilter.java:282) > at > org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:259) > at > org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:181) > at > org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:136) > at > org.eclipse.jetty.servlet.ServletHandler.lambda$initialize$0(ServletHandler.java:750) > at > java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948) > at > java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734) > at > java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734) > at > java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658) > at > org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:744) > at > org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:369) > at > org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1497) > at > org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1459) > at > org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:854) > at > org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:278) > at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:545) > at > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) > at > org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:46) > at >
[jira] [Comment Edited] (SOLR-13665) Connecting to ZK on SSL port (secureClient: ClassNotDef found error)
[ https://issues.apache.org/jira/browse/SOLR-13665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896414#comment-16896414 ] Jörn Franke edited comment on SOLR-13665 at 7/30/19 7:04 PM: - Ok thanks, I will try. Would it make sense to include it in the Solr distribution? That being said, I can also describe in the reference guide some instructions on how to configure it, if wanted/needed. Just point me to some documents on how to update it. was (Author: jornfranke): Ok thanks, I will try. I did not yet do it, because I saw some other netty libraries in the Solr directory and I did not want to mess it up. Would it make sense to include it in the Solr distribution? That being said, I can also describe in the reference guide some instructions on how to configure it, if wanted/needed. Just point me to some documents on how to update it. > Connecting to ZK on SSL port (secureClient: ClassNotDef found error) > > > Key: SOLR-13665 > URL: https://issues.apache.org/jira/browse/SOLR-13665 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 8.2 >Reporter: Jörn Franke >Priority: Major > > > I managed to setup Zookeeper 3.5.5 with secure Client enabled and configured > in solr.in.sh the zookeeper properties to use that port, which offers SSL. > However, I see the following error in the logfiles when starting up Solr: > 2019-07-30 14:59:09.704 INFO (main) [ ] o.a.z.c.X509Util Setting -D > jdk.tls.rejectClientInitiatedRenegotiation=true to disable client-initiated > TLS renegotiation > 2019-07-30 14:59:09.710 ERROR (main) [ ] o.a.s.s.SolrDispatchFilter Could > not start Solr. Check solr/home property and the logs > 2019-07-30 14:59:09.743 ERROR (main) [ ] o.a.s.c.SolrCore > null:java.lang.NoClassDefFoundError: io/netty/channel/ChannelHandler > at java.base/java.lang.Class.forName0(Native Method) > at java.base/java.lang.Class.forName(Class.java:315) > at > org.apache.zookeeper.ZooKeeper.getClientCnxnSocket(ZooKeeper.java:3063) > at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:883) > at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:801) > at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:950) > at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:688) > at > org.apache.solr.common.cloud.SolrZooKeeper.(SolrZooKeeper.java:43) > at > org.apache.solr.common.cloud.ZkClientConnectionStrategy.createSolrZooKeeper(ZkClientConnectionStrategy.java:105) > at > org.apache.solr.common.cloud.DefaultConnectionStrategy.connect(DefaultConnectionStrategy.java:37) > at > org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:166) > at > org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:125) > at > org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:120) > at > org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:107) > at > org.apache.solr.servlet.SolrDispatchFilter.loadNodeConfig(SolrDispatchFilter.java:282) > at > org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:259) > at > org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:181) > at > org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:136) > at > org.eclipse.jetty.servlet.ServletHandler.lambda$initialize$0(ServletHandler.java:750) > at > java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948) > at > java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734) > at > java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734) > at > java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658) > at > org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:744) > at > org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:369) > at > org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1497) > at > org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1459) > at > org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:854) > at > org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:278) > at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:545) > at > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) > at > org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:46) > at >
[jira] [Commented] (SOLR-13665) Connecting to ZK on SSL port (secureClient: ClassNotDef found error)
[ https://issues.apache.org/jira/browse/SOLR-13665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896414#comment-16896414 ] Jörn Franke commented on SOLR-13665: Ok thanks, I will try. I did not yet do it, because I saw some other netty libraries in the Solr directory and I did not want to mess it up. Would it make sense to include it in the Solr distribution? That being said, I can also describe in the reference guide some instructions on how to configure it, if wanted/needed. Just point me to some documents on how to update it. > Connecting to ZK on SSL port (secureClient: ClassNotDef found error) > > > Key: SOLR-13665 > URL: https://issues.apache.org/jira/browse/SOLR-13665 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 8.2 >Reporter: Jörn Franke >Priority: Major > > > I managed to setup Zookeeper 3.5.5 with secure Client enabled and configured > in solr.in.sh the zookeeper properties to use that port, which offers SSL. > However, I see the following error in the logfiles when starting up Solr: > 2019-07-30 14:59:09.704 INFO (main) [ ] o.a.z.c.X509Util Setting -D > jdk.tls.rejectClientInitiatedRenegotiation=true to disable client-initiated > TLS renegotiation > 2019-07-30 14:59:09.710 ERROR (main) [ ] o.a.s.s.SolrDispatchFilter Could > not start Solr. Check solr/home property and the logs > 2019-07-30 14:59:09.743 ERROR (main) [ ] o.a.s.c.SolrCore > null:java.lang.NoClassDefFoundError: io/netty/channel/ChannelHandler > at java.base/java.lang.Class.forName0(Native Method) > at java.base/java.lang.Class.forName(Class.java:315) > at > org.apache.zookeeper.ZooKeeper.getClientCnxnSocket(ZooKeeper.java:3063) > at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:883) > at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:801) > at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:950) > at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:688) > at > org.apache.solr.common.cloud.SolrZooKeeper.(SolrZooKeeper.java:43) > at > org.apache.solr.common.cloud.ZkClientConnectionStrategy.createSolrZooKeeper(ZkClientConnectionStrategy.java:105) > at > org.apache.solr.common.cloud.DefaultConnectionStrategy.connect(DefaultConnectionStrategy.java:37) > at > org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:166) > at > org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:125) > at > org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:120) > at > org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:107) > at > org.apache.solr.servlet.SolrDispatchFilter.loadNodeConfig(SolrDispatchFilter.java:282) > at > org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:259) > at > org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:181) > at > org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:136) > at > org.eclipse.jetty.servlet.ServletHandler.lambda$initialize$0(ServletHandler.java:750) > at > java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948) > at > java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734) > at > java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734) > at > java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658) > at > org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:744) > at > org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:369) > at > org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1497) > at > org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1459) > at > org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:854) > at > org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:278) > at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:545) > at > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) > at > org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:46) > at > org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:192) > at > org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:510) > at > org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:153) > at >
[jira] [Commented] (SOLR-13665) Connecting to ZK on SSL port (secureClient: ClassNotDef found error)
[ https://issues.apache.org/jira/browse/SOLR-13665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896411#comment-16896411 ] Shawn Heisey commented on SOLR-13665: - The ZK SSL guide says that Netty is required for SSL. https://cwiki.apache.org/confluence/display/ZOOKEEPER/ZooKeeper+SSL+User+Guide Solr has a dependency on netty for tests, but not for anything else -- it's not in the binary download. This requirement probably was not known when we upgraded ZK to 3.5.5. Manually adding the netty jar to WEB-INF/lib would most likely fix the problem. I can't guarantee that, but I think it should work. The binary ZK 3.5.5 download contains a file named netty-all-4.1.29.Final.jar that should work. > Connecting to ZK on SSL port (secureClient: ClassNotDef found error) > > > Key: SOLR-13665 > URL: https://issues.apache.org/jira/browse/SOLR-13665 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 8.2 >Reporter: Jörn Franke >Priority: Major > > > I managed to setup Zookeeper 3.5.5 with secure Client enabled and configured > in solr.in.sh the zookeeper properties to use that port, which offers SSL. > However, I see the following error in the logfiles when starting up Solr: > 2019-07-30 14:59:09.704 INFO (main) [ ] o.a.z.c.X509Util Setting -D > jdk.tls.rejectClientInitiatedRenegotiation=true to disable client-initiated > TLS renegotiation > 2019-07-30 14:59:09.710 ERROR (main) [ ] o.a.s.s.SolrDispatchFilter Could > not start Solr. Check solr/home property and the logs > 2019-07-30 14:59:09.743 ERROR (main) [ ] o.a.s.c.SolrCore > null:java.lang.NoClassDefFoundError: io/netty/channel/ChannelHandler > at java.base/java.lang.Class.forName0(Native Method) > at java.base/java.lang.Class.forName(Class.java:315) > at > org.apache.zookeeper.ZooKeeper.getClientCnxnSocket(ZooKeeper.java:3063) > at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:883) > at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:801) > at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:950) > at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:688) > at > org.apache.solr.common.cloud.SolrZooKeeper.(SolrZooKeeper.java:43) > at > org.apache.solr.common.cloud.ZkClientConnectionStrategy.createSolrZooKeeper(ZkClientConnectionStrategy.java:105) > at > org.apache.solr.common.cloud.DefaultConnectionStrategy.connect(DefaultConnectionStrategy.java:37) > at > org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:166) > at > org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:125) > at > org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:120) > at > org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:107) > at > org.apache.solr.servlet.SolrDispatchFilter.loadNodeConfig(SolrDispatchFilter.java:282) > at > org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:259) > at > org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:181) > at > org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:136) > at > org.eclipse.jetty.servlet.ServletHandler.lambda$initialize$0(ServletHandler.java:750) > at > java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948) > at > java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734) > at > java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734) > at > java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658) > at > org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:744) > at > org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:369) > at > org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1497) > at > org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1459) > at > org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:854) > at > org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:278) > at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:545) > at > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) > at > org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:46) > at > org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:192) > at > org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:510) > at >
[jira] [Commented] (SOLR-13659) Cache implementations should be loadable/reloadable from runtime libraries
[ https://issues.apache.org/jira/browse/SOLR-13659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896405#comment-16896405 ] ASF subversion and git services commented on SOLR-13659: Commit 8f35b79f79a112d3e531ba742a3ecf336a17933b in lucene-solr's branch refs/heads/jira/SOLR-13659 from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8f35b79 ] SOLR-13659: initial commit > Cache implementations should be loadable/reloadable from runtime libraries > -- > > Key: SOLR-13659 > URL: https://issues.apache.org/jira/browse/SOLR-13659 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > > Cache implementation class is currently loaded from the SolrConfig > classloader -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13433) Optionally track and expose ram usage for filter and query result caches
[
https://issues.apache.org/jira/browse/SOLR-13433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrzej Bialecki reassigned SOLR-13433:
Assignee: Andrzej Bialecki (was: Shalin Shekhar Mangar)
> Optionally track and expose ram usage for filter and query result caches
>
>
> Key: SOLR-13433
> URL: https://issues.apache.org/jira/browse/SOLR-13433
> Project: Solr
> Issue Type: Improvement
>Reporter: Shalin Shekhar Mangar
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: master (9.0), 8.2
>
>
> One can enable maxRamMB on filter and query result caches and in that case
> the ram usage of the caches is maintained and exposed as well as the entries
> are evicted according to overall ram usage. However, the two features need
> not be coupled together i.e. tracking and exposing ram usage can be a
> separate feature from evicting by ram usage.
> I propose to add an optional {{showRamUsage}} to filter and query result
> caches that can be enabled to expose ram size of the cache. The default will
> be off but if {{maxRamMB}} is set then {{showRamUsage}} is automatically set
> to true.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13665) Connecting to ZK on SSL port (secureClient: ClassNotDef found error)
Jörn Franke created SOLR-13665: -- Summary: Connecting to ZK on SSL port (secureClient: ClassNotDef found error) Key: SOLR-13665 URL: https://issues.apache.org/jira/browse/SOLR-13665 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: SolrCloud Affects Versions: 8.2 Reporter: Jörn Franke I managed to setup Zookeeper 3.5.5 with secure Client enabled and configured in solr.in.sh the zookeeper properties to use that port, which offers SSL. However, I see the following error in the logfiles when starting up Solr: 2019-07-30 14:59:09.704 INFO (main) [ ] o.a.z.c.X509Util Setting -D jdk.tls.rejectClientInitiatedRenegotiation=true to disable client-initiated TLS renegotiation 2019-07-30 14:59:09.710 ERROR (main) [ ] o.a.s.s.SolrDispatchFilter Could not start Solr. Check solr/home property and the logs 2019-07-30 14:59:09.743 ERROR (main) [ ] o.a.s.c.SolrCore null:java.lang.NoClassDefFoundError: io/netty/channel/ChannelHandler at java.base/java.lang.Class.forName0(Native Method) at java.base/java.lang.Class.forName(Class.java:315) at org.apache.zookeeper.ZooKeeper.getClientCnxnSocket(ZooKeeper.java:3063) at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:883) at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:801) at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:950) at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:688) at org.apache.solr.common.cloud.SolrZooKeeper.(SolrZooKeeper.java:43) at org.apache.solr.common.cloud.ZkClientConnectionStrategy.createSolrZooKeeper(ZkClientConnectionStrategy.java:105) at org.apache.solr.common.cloud.DefaultConnectionStrategy.connect(DefaultConnectionStrategy.java:37) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:166) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:125) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:120) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:107) at org.apache.solr.servlet.SolrDispatchFilter.loadNodeConfig(SolrDispatchFilter.java:282) at org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:259) at org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:181) at org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:136) at org.eclipse.jetty.servlet.ServletHandler.lambda$initialize$0(ServletHandler.java:750) at java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948) at java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734) at java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734) at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658) at org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:744) at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:369) at org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1497) at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1459) at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:854) at org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:278) at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:545) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) at org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:46) at org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:192) at org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:510) at org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:153) at org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:172) at org.eclipse.jetty.deploy.providers.WebAppProvider.fileAdded(WebAppProvider.java:436) at org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:65) at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:610) at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:529) at org.eclipse.jetty.util.Scanner.scan(Scanner.java:392) at org.eclipse.jetty.util.Scanner.doStart(Scanner.java:313) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) at org.eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(ScanningAppProvider.java:145) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) at
[jira] [Updated] (SOLR-13664) SolrTestCaseJ4.deleteCore() does not delete/clean dataDir
[
https://issues.apache.org/jira/browse/SOLR-13664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-13664:
Attachment: SOLR-13664.patch
Status: Open (was: Open)
The attached patch doesn't fix the problem – still thinking about the best
solution to move forward – but it does trivially demonstrates this problem in a
new test. It also updates {{TestUseDocValuesAsStored}} to include a sanity
check against this problem.
A weird {{TestUseDocValuesAsStored}} jenkins failure is how i discovered this
in the first place...
apache_Lucene-Solr-Tests-8.2_34.log.txt
{noformat}
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=TestUseDocValuesAsStored -Dtests.method=testDuplicateMultiValued
-Dtests.seed=69AC8730651B9CCD -Dtests.multiplier=2 -Dtests.slow=true
-Dtests.locale=ja -Dtests.timezone=America/Argentina/ComodRivadavia
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
[junit4] ERROR 1.13s J0 |
TestUseDocValuesAsStored.testDuplicateMultiValued <<<
[junit4]> Throwable #1: java.lang.RuntimeException: Exception during
query
[junit4]>at
__randomizedtesting.SeedInfo.seed([69AC8730651B9CCD:87719310ABAA6A71]:0)
[junit4]>at
org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:947)
[junit4]>at
org.apache.solr.schema.TestUseDocValuesAsStored.doTest(TestUseDocValuesAsStored.java:367)
[junit4]>at
org.apache.solr.schema.TestUseDocValuesAsStored.testDuplicateMultiValued(TestUseDocValuesAsStored.java:172)
[junit4]>at java.lang.Thread.run(Thread.java:748)
[junit4]> Caused by: java.lang.RuntimeException: REQUEST FAILED:
xpath=//arr[@name='enums_dvo']/str[.='Not Available']
[junit4]>xml response was:
[junit4]>
[junit4]> 00xyzmyid1XY2XXY3XY4-66642425-66.6664.24.26-6664204207-6.E-50.00420.004281999-12-31T23:59:59Z2016-07-04T03:02:01Z2016-07-04T03:02:01Z
[junit4]>
[junit4]>request was:q=*:*=*=xml
[junit4]>at
org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:940)
{noformat}
...what's happening here is that docs from previous test methods in this class
(that should have been using their own distinct cores + dataDirs) are bleeding
into this test, causing the doc the test is checking for in to be pushed out
past the {{rows=10}} results. (note the {{numFound="11"}})
> SolrTestCaseJ4.deleteCore() does not delete/clean dataDir
> --
>
> Key: SOLR-13664
> URL: https://issues.apache.org/jira/browse/SOLR-13664
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13664.patch
>
>
> In spite of what it's javadocs say, {{SolrTestCaseJ4.deleteCore()}} does
> nothing to delete the dataDir used by the TestHarness
> The git history is a bit murky, so i'm not entirely certain when this stoped
> working, but I suspect it happened as part of the overall cleanup regarding
> test temp dirs and the use of {{LuceneTestCase.createTempDir(...) ->
> TestRuleTemporaryFilesCleanup}}
> While this is not problematic in many test classes, where a single
> {{initCore(...) is called in a {{@BeforeClass}} and the test then re-uses
> that SolrCore for all test methods and relies on {{@AfterClass
> SolrTestCaseJ4.teardownTestCases()}} to call {{deleteCore()}}, it's
> problematic in test classes where {{deleteCore()}} is explicitly called in an
> {{@After}} method to ensure a unique core (w/unique dataDir) is used for each
> test method.
> (there are currently about 61 tests that call {{deleteCore()}} directly)
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13664) SolrTestCaseJ4.deleteCore() does not delete/clean dataDir
Hoss Man created SOLR-13664:
---
Summary: SolrTestCaseJ4.deleteCore() does not delete/clean dataDir
Key: SOLR-13664
URL: https://issues.apache.org/jira/browse/SOLR-13664
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man
Assignee: Hoss Man
In spite of what it's javadocs say, {{SolrTestCaseJ4.deleteCore()}} does
nothing to delete the dataDir used by the TestHarness
The git history is a bit murky, so i'm not entirely certain when this stoped
working, but I suspect it happened as part of the overall cleanup regarding
test temp dirs and the use of {{LuceneTestCase.createTempDir(...) ->
TestRuleTemporaryFilesCleanup}}
While this is not problematic in many test classes, where a single
{{initCore(...) is called in a {{@BeforeClass}} and the test then re-uses that
SolrCore for all test methods and relies on {{@AfterClass
SolrTestCaseJ4.teardownTestCases()}} to call {{deleteCore()}}, it's problematic
in test classes where {{deleteCore()}} is explicitly called in an {{@After}}
method to ensure a unique core (w/unique dataDir) is used for each test method.
(there are currently about 61 tests that call {{deleteCore()}} directly)
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13660) AbstractFullDistribZkTestBase.waitForActiveReplicaCount is broken
[
https://issues.apache.org/jira/browse/SOLR-13660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-13660:
Resolution: Fixed
Fix Version/s: 8.3
master (9.0)
Status: Resolved (was: Patch Available)
> AbstractFullDistribZkTestBase.waitForActiveReplicaCount is broken
> -
>
> Key: SOLR-13660
> URL: https://issues.apache.org/jira/browse/SOLR-13660
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Fix For: master (9.0), 8.3
>
> Attachments: SOLR-13660.patch
>
>
> {{AbstractFullDistribZkTestBase.waitForActiveReplicaCount(...)}} is broken,
> and does not actually check that the replicas are active.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13660) AbstractFullDistribZkTestBase.waitForActiveReplicaCount is broken
[
https://issues.apache.org/jira/browse/SOLR-13660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896378#comment-16896378
]
ASF subversion and git services commented on SOLR-13660:
Commit 3933047cd7db8a7fdd47a4ba3d6d8f916f3a6823 in lucene-solr's branch
refs/heads/branch_8x from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3933047 ]
SOLR-13660: Fixed AbstractFullDistribZkTestBase.waitForActiveReplicaCount() to
ensure replicas are active.
(cherry picked from commit 6dea203d11feb8c047da883131aacccb3a949042)
> AbstractFullDistribZkTestBase.waitForActiveReplicaCount is broken
> -
>
> Key: SOLR-13660
> URL: https://issues.apache.org/jira/browse/SOLR-13660
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13660.patch
>
>
> {{AbstractFullDistribZkTestBase.waitForActiveReplicaCount(...)}} is broken,
> and does not actually check that the replicas are active.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-8.2-Linux (64bit/jdk-12.0.1) - Build # 495 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.2-Linux/495/ Java: 64bit/jdk-12.0.1 -XX:-UseCompressedOops -XX:+UseParallelGC 12 tests failed. FAILED: org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica Error Message: Timeout occurred while waiting response from server at: https://127.0.0.1:35811/solr Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occurred while waiting response from server at: https://127.0.0.1:35811/solr at __randomizedtesting.SeedInfo.seed([A046006F6E259E34:CA5061BF06D7D4FE]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:667) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245) at org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368) at org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1128) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228) at org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica(DeleteReplicaTest.java:384) at org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica(DeleteReplicaTest.java:256) 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:567) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) 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:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) 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
[jira] [Commented] (SOLR-13658) Discuss adding the new "var" construct to the forbidden API list.
[
https://issues.apache.org/jira/browse/SOLR-13658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896342#comment-16896342
]
Erick Erickson commented on SOLR-13658:
---
Hmmm, I may have to take it all back then. I tried to repro and I think I was
confusing the class cast for the map.get() with the variable assignment. Blame
it on the heat ;).
And as far as method signatures are concerned, IntelliJ brings up the method
signature with cmd-P (mac) so even that objection is removed.
Maybe this isn't so bad after all. I might even get to like it. Not until we
stop working on Solr 8 though, since back-porting would be a pain. Add it to
the reasons I think the Solr 8x cycle will be relatively short.
I can adapt to most any convention, as long as we don't have the possibility of
using the "var" convention introduce runtime errors that would have been caught
at compile time.
Thanks for making me look more closely...
> Discuss adding the new "var" construct to the forbidden API list.
> -
>
> Key: SOLR-13658
> URL: https://issues.apache.org/jira/browse/SOLR-13658
> Project: Solr
> Issue Type: Wish
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> Personally, I'm strongly against allowing the "var" construct in Lucene/Solr
> code. I think it's a wonderful opportunity to introduce bugs that won't be
> found until runtime as well as making maintainence significantly harder. I
> don't even think for a project like Solr it would save any time overall...
> So let's discuss this ahead of time and see if we can reach a consensus. I'll
> start the discussion off:
> My baseline argument is that for a large complex project, especially ones
> with many different people coding, I want the compiler to give me all the
> help possible. And the "var" construct takes away some of that help.
> I’ve seen this argument go around at least 4 times in my career. The argument
> that “it takes longer to write if you have to type all this stuff” is bogus.
> Last I knew, 80% of the time spent is in maintaining/reading it. So the
> argument “I can write faster” means I can save some fraction of the 20% of
> the time writing the original code but spend many times that figuring out
> what the code is actually doing the other 80% of the time.
> The IDE makes _writing_ this slightly faster, admittedly.
> {code:java}
> Whatever what = new Whatever();
> var kidding = what.getComplex();
> var blivet = kidding.get("stuff");
> {code}
> But once that’s done, if I’m reading the code again I don't have any clue what
> {code:java}
> kidding or blivet
> {code}
> are. Here's the signature for getComplex:
> {code:java}
> Map> getComplex()
> {code}
> I have to go over to the definition (which I admit is easier than it used to
> be in the bad old days, but still) to find out.
> HERE'S THE PART I REALLY OBJECT TO!
> The above I could probably live with, maybe we could get the InteliJ
> developers and see if they can make hover show the inference. What I will
> kick and scream about is introducing bugs that are not found until runtime.
> Even this obvious stupidity fails with a ClassCastException:
> {code:java}
> var corny = new TreeMap();
> corny.put("one", "two");
> corny.get(1);
> {code}
> But it's much worse when using classes from somewhere else. For instance,
> change the underlying class in the first example to return
> {code:java}
> Map>{code}
> .
> This code that used to work now throws an error, _but it compiles_.
> {code:java}
> var kidding = what.getComplex();
> var blivet = kidding.get("stuff");
> var blah = kidding.get("stuff").get(1); // generates ClassCastException:
> class java.lang.String cannot be cast to class java.lang.Integer
> {code}
> So in order to save some time writing (that I claim will be lost multiple
> times over when maintaining the code) we'll introduce run-time errors that
> will take a bunch _more_ time to figure out, and won’t be found during unit
> tests unless and until we have complete code coverage.
> If there's a way to insure that this kind of thing can't get into the code
> and we implement that, I could be persuaded, but let's make that an explicit
> requirement (and find a suitable task for the build system, precommit or
> whatever).
> The floor is open...
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13660) AbstractFullDistribZkTestBase.waitForActiveReplicaCount is broken
[
https://issues.apache.org/jira/browse/SOLR-13660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896339#comment-16896339
]
ASF subversion and git services commented on SOLR-13660:
Commit 6dea203d11feb8c047da883131aacccb3a949042 in lucene-solr's branch
refs/heads/master from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6dea203 ]
SOLR-13660: Fixed AbstractFullDistribZkTestBase.waitForActiveReplicaCount() to
ensure replicas are active.
> AbstractFullDistribZkTestBase.waitForActiveReplicaCount is broken
> -
>
> Key: SOLR-13660
> URL: https://issues.apache.org/jira/browse/SOLR-13660
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13660.patch
>
>
> {{AbstractFullDistribZkTestBase.waitForActiveReplicaCount(...)}} is broken,
> and does not actually check that the replicas are active.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8934) Move Nori DictionaryBuilder tool from src/tools to src/
[
https://issues.apache.org/jira/browse/LUCENE-8934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896277#comment-16896277
]
ASF subversion and git services commented on LUCENE-8934:
-
Commit 2c0d8996cf98e5b5f78f4330eeb21837f2b70c93 in lucene-solr's branch
refs/heads/master from Namgyu Kim
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2c0d899 ]
LUCENE-8934: promote nori tools to main jar
> Move Nori DictionaryBuilder tool from src/tools to src/
> ---
>
> Key: LUCENE-8934
> URL: https://issues.apache.org/jira/browse/LUCENE-8934
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Namgyu Kim
>Assignee: Namgyu Kim
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> After LUCENE-8904 tests in Nori tools are not running in the normal test
> ({{ant test}}).
> As with Kuromoji(before LUCENE-8871), we need to run the {{ant test-tools}}
> to test Nori's tools.
> Like Kuromoji, we can proceed with the normality test after moving the tools
> of Nori to the main source tree.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] danmuzi merged pull request #808: LUCENE-8934: promote nori tools to main jar
danmuzi merged pull request #808: LUCENE-8934: promote nori tools to main jar URL: https://github.com/apache/lucene-solr/pull/808 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] danmuzi commented on issue #808: LUCENE-8934: promote nori tools to main jar
danmuzi commented on issue #808: LUCENE-8934: promote nori tools to main jar URL: https://github.com/apache/lucene-solr/pull/808#issuecomment-516488439 Thank you for your review! @jimczi I'll merge this PR and close. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13625) Add CsvStream, TsvStream Streaming Expressions and supporting Stream Evaluators
[ https://issues.apache.org/jira/browse/SOLR-13625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-13625: -- Fix Version/s: 8.3 > Add CsvStream, TsvStream Streaming Expressions and supporting Stream > Evaluators > --- > > Key: SOLR-13625 > URL: https://issues.apache.org/jira/browse/SOLR-13625 > Project: Solr > Issue Type: New Feature > Components: streaming expressions >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Major > Fix For: 8.3 > > Attachments: SOLR-13625.patch, SOLR-13625.patch, SOLR-13625.patch, > SOLR-13625.patch, SOLR-13625.patch > > > The CsvStream, TsvStream Streaming Expressions parse CSV and TSV files and > load fields into tuples for indexing into Solr Cloud collections. Other > Stream Evaluators were also added in this ticket to support various data > loading operations. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13625) Add CsvStream, TsvStream Streaming Expressions and supporting Stream Evaluators
[ https://issues.apache.org/jira/browse/SOLR-13625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896235#comment-16896235 ] ASF subversion and git services commented on SOLR-13625: Commit 6c7c21c574a4c59a45f37871c62ef3298131ab88 in lucene-solr's branch refs/heads/branch_8x from Joel Bernstein [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6c7c21c ] SOLR-13625: Fix precommit > Add CsvStream, TsvStream Streaming Expressions and supporting Stream > Evaluators > --- > > Key: SOLR-13625 > URL: https://issues.apache.org/jira/browse/SOLR-13625 > Project: Solr > Issue Type: New Feature > Components: streaming expressions >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Major > Attachments: SOLR-13625.patch, SOLR-13625.patch, SOLR-13625.patch, > SOLR-13625.patch, SOLR-13625.patch > > > The CsvStream, TsvStream Streaming Expressions parse CSV and TSV files and > load fields into tuples for indexing into Solr Cloud collections. Other > Stream Evaluators were also added in this ticket to support various data > loading operations. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13625) Add CsvStream, TsvStream Streaming Expressions and supporting Stream Evaluators
[ https://issues.apache.org/jira/browse/SOLR-13625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896234#comment-16896234 ] ASF subversion and git services commented on SOLR-13625: Commit f6992a3a3bd069b2926f613c021e9f4f39489ea8 in lucene-solr's branch refs/heads/branch_8x from Joel Bernstein [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f6992a3 ] SOLR-13625: Fix broken test cases > Add CsvStream, TsvStream Streaming Expressions and supporting Stream > Evaluators > --- > > Key: SOLR-13625 > URL: https://issues.apache.org/jira/browse/SOLR-13625 > Project: Solr > Issue Type: New Feature > Components: streaming expressions >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Major > Attachments: SOLR-13625.patch, SOLR-13625.patch, SOLR-13625.patch, > SOLR-13625.patch, SOLR-13625.patch > > > The CsvStream, TsvStream Streaming Expressions parse CSV and TSV files and > load fields into tuples for indexing into Solr Cloud collections. Other > Stream Evaluators were also added in this ticket to support various data > loading operations. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13625) Add CsvStream, TsvStream Streaming Expressions and supporting Stream Evaluators
[ https://issues.apache.org/jira/browse/SOLR-13625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896233#comment-16896233 ] ASF subversion and git services commented on SOLR-13625: Commit eb280c4808f587817cb0038c108d7fd5f7ea862c in lucene-solr's branch refs/heads/branch_8x from Joel Bernstein [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=eb280c4 ] SOLR-13625: Add CsvStream, TsvStream Streaming Expressions and supporting Stream Evaluators > Add CsvStream, TsvStream Streaming Expressions and supporting Stream > Evaluators > --- > > Key: SOLR-13625 > URL: https://issues.apache.org/jira/browse/SOLR-13625 > Project: Solr > Issue Type: New Feature > Components: streaming expressions >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Major > Attachments: SOLR-13625.patch, SOLR-13625.patch, SOLR-13625.patch, > SOLR-13625.patch, SOLR-13625.patch > > > The CsvStream, TsvStream Streaming Expressions parse CSV and TSV files and > load fields into tuples for indexing into Solr Cloud collections. Other > Stream Evaluators were also added in this ticket to support various data > loading operations. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13625) Add CsvStream, TsvStream Streaming Expressions and supporting Stream Evaluators
[ https://issues.apache.org/jira/browse/SOLR-13625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896209#comment-16896209 ] ASF subversion and git services commented on SOLR-13625: Commit d0674866edf109d5813cdf5c70968344373d9f77 in lucene-solr's branch refs/heads/master from Joel Bernstein [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d067486 ] SOLR-13625: Add CsvStream, TsvStream Streaming Expressions and supporting Stream Evaluators > Add CsvStream, TsvStream Streaming Expressions and supporting Stream > Evaluators > --- > > Key: SOLR-13625 > URL: https://issues.apache.org/jira/browse/SOLR-13625 > Project: Solr > Issue Type: New Feature > Components: streaming expressions >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Major > Attachments: SOLR-13625.patch, SOLR-13625.patch, SOLR-13625.patch, > SOLR-13625.patch, SOLR-13625.patch > > > The CsvStream, TsvStream Streaming Expressions parse CSV and TSV files and > load fields into tuples for indexing into Solr Cloud collections. Other > Stream Evaluators were also added in this ticket to support various data > loading operations. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13625) Add CsvStream, TsvStream Streaming Expressions and supporting Stream Evaluators
[ https://issues.apache.org/jira/browse/SOLR-13625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896210#comment-16896210 ] ASF subversion and git services commented on SOLR-13625: Commit 62955b1a4e98c4a583f9c6c5d71adc7947423b90 in lucene-solr's branch refs/heads/master from Joel Bernstein [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=62955b1 ] SOLR-13625: Fix broken test cases > Add CsvStream, TsvStream Streaming Expressions and supporting Stream > Evaluators > --- > > Key: SOLR-13625 > URL: https://issues.apache.org/jira/browse/SOLR-13625 > Project: Solr > Issue Type: New Feature > Components: streaming expressions >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Major > Attachments: SOLR-13625.patch, SOLR-13625.patch, SOLR-13625.patch, > SOLR-13625.patch, SOLR-13625.patch > > > The CsvStream, TsvStream Streaming Expressions parse CSV and TSV files and > load fields into tuples for indexing into Solr Cloud collections. Other > Stream Evaluators were also added in this ticket to support various data > loading operations. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13625) Add CsvStream, TsvStream Streaming Expressions and supporting Stream Evaluators
[ https://issues.apache.org/jira/browse/SOLR-13625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896211#comment-16896211 ] ASF subversion and git services commented on SOLR-13625: Commit 254a17b3b0df118a1317759c0be0ad20d489283e in lucene-solr's branch refs/heads/master from Joel Bernstein [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=254a17b ] SOLR-13625: Fix precommit > Add CsvStream, TsvStream Streaming Expressions and supporting Stream > Evaluators > --- > > Key: SOLR-13625 > URL: https://issues.apache.org/jira/browse/SOLR-13625 > Project: Solr > Issue Type: New Feature > Components: streaming expressions >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Major > Attachments: SOLR-13625.patch, SOLR-13625.patch, SOLR-13625.patch, > SOLR-13625.patch, SOLR-13625.patch > > > The CsvStream, TsvStream Streaming Expressions parse CSV and TSV files and > load fields into tuples for indexing into Solr Cloud collections. Other > Stream Evaluators were also added in this ticket to support various data > loading operations. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13579) Create resource management API
[
https://issues.apache.org/jira/browse/SOLR-13579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896204#comment-16896204
]
Andrzej Bialecki commented on SOLR-13579:
--
On the use cases:
bq. CacheManagerPlugin would only ever reduce the maxRamMB setting of some
caches at run time
Again, the current implementation of {{CacheManagerPlugin}} is a simplistic
draft.
Ultimately the controlled value of {{maxRamMB}} would be tied proportionally to
two main factors:
* the {{hitratio}} metric (i.e. caches with low hit rate don't need as much RAM
so their {{maxRamMB}} would be trimmed down). This is an optimization of
resource usage.
* and the total {{ramBytesUsed}} across all cores would be used as a hard
limit, proportionally applied to all caches' {{maxRamMB}}, overriding the above
optimization if necessary. This is a hard control limit, which indeed is
related to the current number of cores.
Initial value of {{maxRamMB}} would still come from the config, as it does
today, but then during runtime it would be modified both up and down from that
value depending on the situation.
bq. users who want to use these pools need to change the individual cache's
configured maxRamMB to be much higher then they are today. (potentially to the
same value as the maxRamMB of the pool?)
I think it would work the other way around - users can specify whatever they
want, but if the admin sets a total {{maxRamMB}} to a lower value than the
aggregate value that users requested, their requests will be proportionally
scaled down (see also above for a finer-grained optimization adjustment, not
just the hard limit).
So in reality the amount of RAM each core and each cache would get would be
determined as follows:
* initial value would be set from the config's {{maxRamMB}}, unless it would
already hit the global limit
* this value would be quickly trimmed down based on the {{hitratio}}, and
eventually scaled up as the {{hitratio}} increases. Some other metric could be
used here, too, to make this scale down/up process more efficient.
* if a bunch of other cores were suddenly allocated to the same node it's
likely that the aggregate {{ramBytesUsed}} would hit the global ceiling and the
plugin would start trimming down {{maxRamMB}} of each cache in each core
(possibly using some weighted scheme instead of purely proportional).
* if the number of cores were to decrease so that their aggregate
{{ramBytesUsed}} would fall below a percentage of the hard limit, say 80%, the
plugin could proportionally increase the {{maxRamMB}} so that they equal to eg.
80% of the hard limit.
bq. how/when can/should a CacheManagerPlugin assume/recognize that the memory
pressure has decreased?
Using the {{ramBytesUsed}} metric for the hard limit, and the {{hitratio}}
metric for optimization.
If {{hitratio}} is high then we need as much RAM as possible to expand the
cache, until we either hit the core's limit, or the global limit, OR the
{{hitratio}} falls below a threshold. If {{hitratio}} falls below a threshold
then we know the cache contains mostly useless items and we can trim down its
{{maxRamMB}}, which will lead to evictions, which in turn will lead to the
increased {{hitratio}}.
> Create resource management API
> --
>
> Key: SOLR-13579
> URL: https://issues.apache.org/jira/browse/SOLR-13579
> Project: Solr
> Issue Type: New Feature
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Attachments: SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch,
> SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch
>
>
> Resource management framework API supporting the goals outlined in SOLR-13578.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13625) Add CsvStream, TsvStream Streaming Expressions and supporting Stream Evaluators
[ https://issues.apache.org/jira/browse/SOLR-13625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein reassigned SOLR-13625: - Assignee: Joel Bernstein > Add CsvStream, TsvStream Streaming Expressions and supporting Stream > Evaluators > --- > > Key: SOLR-13625 > URL: https://issues.apache.org/jira/browse/SOLR-13625 > Project: Solr > Issue Type: New Feature > Components: streaming expressions >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Major > Attachments: SOLR-13625.patch, SOLR-13625.patch, SOLR-13625.patch, > SOLR-13625.patch, SOLR-13625.patch > > > The CsvStream, TsvStream Streaming Expressions parse CSV and TSV files and > load fields into tuples for indexing into Solr Cloud collections. Other > Stream Evaluators were also added in this ticket to support various data > loading operations. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13625) Add CsvStream, TsvStream Streaming Expressions and supporting Stream Evaluators
[ https://issues.apache.org/jira/browse/SOLR-13625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-13625: -- Description: The CsvStream, TsvStream Streaming Expressions parse CSV and TSV files and load fields into tuples for indexing into Solr Cloud collections. Other Stream Evaluators were also added in this ticket to support various data loading operations. (was: The CsvStream Streaming Expression parses CSV files and loads fields into tuples for indexing into Solr Cloud collections.) > Add CsvStream, TsvStream Streaming Expressions and supporting Stream > Evaluators > --- > > Key: SOLR-13625 > URL: https://issues.apache.org/jira/browse/SOLR-13625 > Project: Solr > Issue Type: New Feature > Components: streaming expressions >Reporter: Joel Bernstein >Priority: Major > Attachments: SOLR-13625.patch, SOLR-13625.patch, SOLR-13625.patch, > SOLR-13625.patch, SOLR-13625.patch > > > The CsvStream, TsvStream Streaming Expressions parse CSV and TSV files and > load fields into tuples for indexing into Solr Cloud collections. Other > Stream Evaluators were also added in this ticket to support various data > loading operations. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] AceHack commented on issue #508: Simplified JAVA_VER_NUM to utilize single expr execution
AceHack commented on issue #508: Simplified JAVA_VER_NUM to utilize single expr execution URL: https://github.com/apache/lucene-solr/pull/508#issuecomment-516441147 I am also having this issue, setting JAVA_TOOL_OPTIONS causes solr fail to start because it try to use -XLog java 9 options. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13579) Create resource management API
[
https://issues.apache.org/jira/browse/SOLR-13579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896177#comment-16896177
]
Andrzej Bialecki commented on SOLR-13579:
--
On the API itself:
bq. ...but the code in ResourceManagerPlugin is also independent of any
specific type of resource(s) that a pool can manage
{{ResourceManagerPlugin}} is an interface so it has no code of its own.
Subclasses implement the actual logic of what to monitor and how to control it,
so it made sense to make it a separate interface from a pool, which is
responsible for collecting and aggregating the data from components. As I
mentioned, I can easily foresee a future 1:N mapping between pool and plugins,
in order to manage different types of resource limits of a component in one
pool.
Concrete example of a component that consumes different types of resources that
we may want to manage is SolrIndexSearcher - here we have caches, merge IO,
update threads and query threads. We may want to manage all of these aspects by
registering SolrIndexSearcher in a single pool that supports these types of
mgmt plugins, instead of registering it in several pools, each managing one
aspect of the component.
bq. "loose coupling" that currently exists in the patch between the
ManagedComponent API and ResourceManagerPlugin
I agree, this is an important concern - please remember that this is just an
initial attempt to cover all bases, and I thought that using a very generic API
could protect us from the combinatoric explosion of the API between the
management framework and the different types of components. As you noted, the
unfortunate downside of this approach is the complexity of validating and
applying the modifications in the components...
We could perhaps call a type-safe and name-safe component API from a generic
management API by following a similar convention as the one used in
{{SolrPluginUtils.invokeSetters}}? Or use marker interfaces that also provide
validation / conversion. I'll look into this.
> Create resource management API
> --
>
> Key: SOLR-13579
> URL: https://issues.apache.org/jira/browse/SOLR-13579
> Project: Solr
> Issue Type: New Feature
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Attachments: SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch,
> SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch
>
>
> Resource management framework API supporting the goals outlined in SOLR-13578.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-8.x-Linux (64bit/jdk-12.0.1) - Build # 944 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/944/ Java: 64bit/jdk-12.0.1 -XX:-UseCompressedOops -XX:+UseSerialGC 2 tests failed. FAILED: org.apache.solr.cloud.rule.RulesTest.doIntegrationTest Error Message: Timeout occurred while waiting response from server at: https://127.0.0.1:34339/solr Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occurred while waiting response from server at: https://127.0.0.1:34339/solr at __randomizedtesting.SeedInfo.seed([94720E9207AFE29:EC7467683C0E0C2B]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:667) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245) at org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368) at org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1128) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228) at org.apache.solr.cloud.MiniSolrCloudCluster.deleteAllCollections(MiniSolrCloudCluster.java:547) at org.apache.solr.cloud.rule.RulesTest.removeCollections(RulesTest.java:69) 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:567) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:996) at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:239) 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:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) 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
[jira] [Commented] (SOLR-13663) XML Query Parser to Support SpanPositionRangeQuery
[ https://issues.apache.org/jira/browse/SOLR-13663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896141#comment-16896141 ] Alessandro Benedetti commented on SOLR-13663: - Ready for review > XML Query Parser to Support SpanPositionRangeQuery > -- > > Key: SOLR-13663 > URL: https://issues.apache.org/jira/browse/SOLR-13663 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: query parsers >Affects Versions: 8.2 >Reporter: Alessandro Benedetti >Priority: Major > Attachments: SOLR-13663.patch > > Time Spent: 10m > Remaining Estimate: 0h > > Currently the XML Query Parser support a vast array of span queries, > including the SpanFirstQuery, but it doesn't support the generic > SpanPositionRangeQuery. > < SpanPositionRange start="2" end="3"> > prejudice > -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13663) XML Query Parser to Support SpanPositionRangeQuery
[ https://issues.apache.org/jira/browse/SOLR-13663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alessandro Benedetti updated SOLR-13663: Attachment: SOLR-13663.patch > XML Query Parser to Support SpanPositionRangeQuery > -- > > Key: SOLR-13663 > URL: https://issues.apache.org/jira/browse/SOLR-13663 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: query parsers >Affects Versions: 8.2 >Reporter: Alessandro Benedetti >Priority: Major > Attachments: SOLR-13663.patch > > Time Spent: 10m > Remaining Estimate: 0h > > Currently the XML Query Parser support a vast array of span queries, > including the SpanFirstQuery, but it doesn't support the generic > SpanPositionRangeQuery. > < SpanPositionRange start="2" end="3"> > prejudice > -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13658) Discuss adding the new "var" construct to the forbidden API list.
[
https://issues.apache.org/jira/browse/SOLR-13658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896139#comment-16896139
]
Martin Grigorov commented on SOLR-13658:
Hi [~erickerickson],
You didn't provide full snippets so I might have done something in a different
way but the following code compiles and runs fine:
{code:java}
import java.util.Map;
public class Solr13658 {
public static void main(String[] args) {
// with var
var kidding = getComplex();
var blivet = kidding.get("one");
var blah = kidding.get("two").get(2);
blah = 55;
System.err.println("blah: " + blah);
// without var
Map> kidding1 = getComplex();
Map blivet1 = kidding1.get("one");
Integer blah1 = kidding1.get("two").get(2);
blah1 = 55;
System.err.println("blah1: " + blah1);
}
private static Map> getComplex() {
return Map.of(
"one", Map.of("1", 1, "11", 11, "111", 111),
"two", Map.of("2", 2, "22", 22, "222", 222)
);
}
}
{code}
and it prints :
{code:java}
blah: 55
blah1: 55
{code}
in both cases _blah_s types are java.lang.Integer
> Discuss adding the new "var" construct to the forbidden API list.
> -
>
> Key: SOLR-13658
> URL: https://issues.apache.org/jira/browse/SOLR-13658
> Project: Solr
> Issue Type: Wish
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> Personally, I'm strongly against allowing the "var" construct in Lucene/Solr
> code. I think it's a wonderful opportunity to introduce bugs that won't be
> found until runtime as well as making maintainence significantly harder. I
> don't even think for a project like Solr it would save any time overall...
> So let's discuss this ahead of time and see if we can reach a consensus. I'll
> start the discussion off:
> My baseline argument is that for a large complex project, especially ones
> with many different people coding, I want the compiler to give me all the
> help possible. And the "var" construct takes away some of that help.
> I’ve seen this argument go around at least 4 times in my career. The argument
> that “it takes longer to write if you have to type all this stuff” is bogus.
> Last I knew, 80% of the time spent is in maintaining/reading it. So the
> argument “I can write faster” means I can save some fraction of the 20% of
> the time writing the original code but spend many times that figuring out
> what the code is actually doing the other 80% of the time.
> The IDE makes _writing_ this slightly faster, admittedly.
> {code:java}
> Whatever what = new Whatever();
> var kidding = what.getComplex();
> var blivet = kidding.get("stuff");
> {code}
> But once that’s done, if I’m reading the code again I don't have any clue what
> {code:java}
> kidding or blivet
> {code}
> are. Here's the signature for getComplex:
> {code:java}
> Map> getComplex()
> {code}
> I have to go over to the definition (which I admit is easier than it used to
> be in the bad old days, but still) to find out.
> HERE'S THE PART I REALLY OBJECT TO!
> The above I could probably live with, maybe we could get the InteliJ
> developers and see if they can make hover show the inference. What I will
> kick and scream about is introducing bugs that are not found until runtime.
> Even this obvious stupidity fails with a ClassCastException:
> {code:java}
> var corny = new TreeMap();
> corny.put("one", "two");
> corny.get(1);
> {code}
> But it's much worse when using classes from somewhere else. For instance,
> change the underlying class in the first example to return
> {code:java}
> Map>{code}
> .
> This code that used to work now throws an error, _but it compiles_.
> {code:java}
> var kidding = what.getComplex();
> var blivet = kidding.get("stuff");
> var blah = kidding.get("stuff").get(1); // generates ClassCastException:
> class java.lang.String cannot be cast to class java.lang.Integer
> {code}
> So in order to save some time writing (that I claim will be lost multiple
> times over when maintaining the code) we'll introduce run-time errors that
> will take a bunch _more_ time to figure out, and won’t be found during unit
> tests unless and until we have complete code coverage.
> If there's a way to insure that this kind of thing can't get into the code
> and we implement that, I could be persuaded, but let's make that an explicit
> requirement (and find a suitable task for the build system, precommit or
> whatever).
> The floor is open...
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To
[jira] [Updated] (SOLR-13663) XML Query Parser to Support SpanPositionRangeQuery
[ https://issues.apache.org/jira/browse/SOLR-13663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alessandro Benedetti updated SOLR-13663: Status: Patch Available (was: Open) > XML Query Parser to Support SpanPositionRangeQuery > -- > > Key: SOLR-13663 > URL: https://issues.apache.org/jira/browse/SOLR-13663 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: query parsers >Affects Versions: 8.2 >Reporter: Alessandro Benedetti >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently the XML Query Parser support a vast array of span queries, > including the SpanFirstQuery, but it doesn't support the generic > SpanPositionRangeQuery. > < SpanPositionRange start="2" end="3"> > prejudice > -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] alessandrobenedetti opened a new pull request #812: [SOLR-13663] Span Positional Range Support in XML Query Parser + test
alessandrobenedetti opened a new pull request #812: [SOLR-13663] Span Positional Range Support in XML Query Parser + test URL: https://github.com/apache/lucene-solr/pull/812 # Description Please provide a short description of the changes you're making with this pull request. # Solution Please provide a short description of the approach taken to implement your solution. # Tests Please describe the tests you've developed or run to confirm this patch implements the feature or solves the problem. # Checklist Please review the following and check all that apply: - [ ] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [ ] I have created a Jira issue and added the issue ID to my pull request title. - [ ] I am authorized to contribute this code to the ASF and have removed any code I do not have a license to distribute. - [ ] I have developed this patch against the `master` branch. - [ ] I have run `ant precommit` and the appropriate test suite. - [ ] I have added tests for my changes. - [ ] I have added documentation for the Ref Guide (for Solr changes only). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8920) Reduce size of FSTs due to use of direct-addressing encoding
[ https://issues.apache.org/jira/browse/LUCENE-8920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896109#comment-16896109 ] ASF subversion and git services commented on LUCENE-8920: - Commit d1706b36babda2dc17fd82d3165607f5c44bd83e in lucene-solr's branch refs/heads/master from Michael Sokolov [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d1706b3 ] LUCENE-8920: Fix bug preventing FST duplicate tails from being shared when encoded as array-with-gaps > Reduce size of FSTs due to use of direct-addressing encoding > - > > Key: LUCENE-8920 > URL: https://issues.apache.org/jira/browse/LUCENE-8920 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Mike Sokolov >Priority: Blocker > Fix For: 8.3 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Some data can lead to worst-case ~4x RAM usage due to this optimization. > Several ideas were suggested to combat this on the mailing list: > bq. I think we can improve thesituation here by tracking, per-FST instance, > the size increase we're seeing while building (or perhaps do a preliminary > pass before building) in order to decide whether to apply the encoding. > bq. we could also make the encoding a bit more efficient. For instance I > noticed that arc metadata is pretty large in some cases (in the 10-20 bytes) > which make gaps very costly. Associating each label with a dense id and > having an intermediate lookup, ie. lookup label -> id and then id->arc offset > instead of doing label->arc directly could save a lot of space in some cases? > Also it seems that we are repeating the label in the arc metadata when > array-with-gaps is used, even though it shouldn't be necessary since the > label is implicit from the address? -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] msokolov merged pull request #811: LUCENE-8920: Fix bug preventing FST duplicate tails from being shared…
msokolov merged pull request #811: LUCENE-8920: Fix bug preventing FST duplicate tails from being shared… URL: https://github.com/apache/lucene-solr/pull/811 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8937) Avoid agressive stemming on numbers in the FrenchMinimalStemmer
[ https://issues.apache.org/jira/browse/LUCENE-8937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomoko Uchida updated LUCENE-8937: -- Component/s: modules/analysis > Avoid agressive stemming on numbers in the FrenchMinimalStemmer > --- > > Key: LUCENE-8937 > URL: https://issues.apache.org/jira/browse/LUCENE-8937 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Reporter: Adrien Gallou >Assignee: Tomoko Uchida >Priority: Minor > Fix For: master (9.0) > > Attachments: > 0001-LUCENE-8937-Avoid-agressive-stemming-on-numbers-in-t.patch, > LUCENE-8937.patch > > > Here is the discussion on the mailing list : > [http://mail-archives.apache.org/mod_mbox/lucene-java-user/201907.mbox/browser] > The light stemmer removes the last character of a word if the last two > characters are identical. > We can see that here: > > https://github.com/apache/lucene-solr/blob/813ca77/lucene/analysis/common/src/java/org/apache/lucene/analysis/fr/FrenchLightStemmer.java#L263 > In this light stemmer, there is a check to avoid altering the token if the > token is a number. > The minimal stemmer also removes the last character of a word if the last > two characters are identical. > We can see that here: > > https://github.com/apache/lucene-solr/blob/813ca77/lucene/analysis/common/src/java/org/apache/lucene/analysis/fr/FrenchMinimalStemmer.java#L77 > But in this minimal stemmer there is no check to see if the character is a > letter or not. > So when we have numeric tokens with the last two characters identical they > are altered. > For example "1234567899" will be stemmed as "123456789". > It could be great of it's not altered. > Here is the same issue for the LightStemmer : > https://issues.apache.org/jira/browse/LUCENE-4063 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-8937) Avoid agressive stemming on numbers in the FrenchMinimalStemmer
[ https://issues.apache.org/jira/browse/LUCENE-8937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomoko Uchida resolved LUCENE-8937. --- Resolution: Fixed Assignee: Tomoko Uchida Fix Version/s: master (9.0) > Avoid agressive stemming on numbers in the FrenchMinimalStemmer > --- > > Key: LUCENE-8937 > URL: https://issues.apache.org/jira/browse/LUCENE-8937 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Gallou >Assignee: Tomoko Uchida >Priority: Minor > Fix For: master (9.0) > > Attachments: > 0001-LUCENE-8937-Avoid-agressive-stemming-on-numbers-in-t.patch, > LUCENE-8937.patch > > > Here is the discussion on the mailing list : > [http://mail-archives.apache.org/mod_mbox/lucene-java-user/201907.mbox/browser] > The light stemmer removes the last character of a word if the last two > characters are identical. > We can see that here: > > https://github.com/apache/lucene-solr/blob/813ca77/lucene/analysis/common/src/java/org/apache/lucene/analysis/fr/FrenchLightStemmer.java#L263 > In this light stemmer, there is a check to avoid altering the token if the > token is a number. > The minimal stemmer also removes the last character of a word if the last > two characters are identical. > We can see that here: > > https://github.com/apache/lucene-solr/blob/813ca77/lucene/analysis/common/src/java/org/apache/lucene/analysis/fr/FrenchMinimalStemmer.java#L77 > But in this minimal stemmer there is no check to see if the character is a > letter or not. > So when we have numeric tokens with the last two characters identical they > are altered. > For example "1234567899" will be stemmed as "123456789". > It could be great of it's not altered. > Here is the same issue for the LightStemmer : > https://issues.apache.org/jira/browse/LUCENE-4063 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8937) Avoid agressive stemming on numbers in the FrenchMinimalStemmer
[ https://issues.apache.org/jira/browse/LUCENE-8937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896097#comment-16896097 ] Tomoko Uchida commented on LUCENE-8937: --- Committed to the master. Thank you [~agallou]! > Avoid agressive stemming on numbers in the FrenchMinimalStemmer > --- > > Key: LUCENE-8937 > URL: https://issues.apache.org/jira/browse/LUCENE-8937 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Gallou >Priority: Minor > Attachments: > 0001-LUCENE-8937-Avoid-agressive-stemming-on-numbers-in-t.patch, > LUCENE-8937.patch > > > Here is the discussion on the mailing list : > [http://mail-archives.apache.org/mod_mbox/lucene-java-user/201907.mbox/browser] > The light stemmer removes the last character of a word if the last two > characters are identical. > We can see that here: > > https://github.com/apache/lucene-solr/blob/813ca77/lucene/analysis/common/src/java/org/apache/lucene/analysis/fr/FrenchLightStemmer.java#L263 > In this light stemmer, there is a check to avoid altering the token if the > token is a number. > The minimal stemmer also removes the last character of a word if the last > two characters are identical. > We can see that here: > > https://github.com/apache/lucene-solr/blob/813ca77/lucene/analysis/common/src/java/org/apache/lucene/analysis/fr/FrenchMinimalStemmer.java#L77 > But in this minimal stemmer there is no check to see if the character is a > letter or not. > So when we have numeric tokens with the last two characters identical they > are altered. > For example "1234567899" will be stemmed as "123456789". > It could be great of it's not altered. > Here is the same issue for the LightStemmer : > https://issues.apache.org/jira/browse/LUCENE-4063 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8937) Avoid agressive stemming on numbers in the FrenchMinimalStemmer
[ https://issues.apache.org/jira/browse/LUCENE-8937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896092#comment-16896092 ] ASF subversion and git services commented on LUCENE-8937: - Commit d9d16eec95bf294ecf2b73a73f9310e967f4d03c in lucene-solr's branch refs/heads/master from Adrien Gallou [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d9d16ee ] LUCENE-8937: Avoid agressive stemming on numbers in the FrenchMinimalStemmer > Avoid agressive stemming on numbers in the FrenchMinimalStemmer > --- > > Key: LUCENE-8937 > URL: https://issues.apache.org/jira/browse/LUCENE-8937 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Gallou >Priority: Minor > Attachments: > 0001-LUCENE-8937-Avoid-agressive-stemming-on-numbers-in-t.patch, > LUCENE-8937.patch > > > Here is the discussion on the mailing list : > [http://mail-archives.apache.org/mod_mbox/lucene-java-user/201907.mbox/browser] > The light stemmer removes the last character of a word if the last two > characters are identical. > We can see that here: > > https://github.com/apache/lucene-solr/blob/813ca77/lucene/analysis/common/src/java/org/apache/lucene/analysis/fr/FrenchLightStemmer.java#L263 > In this light stemmer, there is a check to avoid altering the token if the > token is a number. > The minimal stemmer also removes the last character of a word if the last > two characters are identical. > We can see that here: > > https://github.com/apache/lucene-solr/blob/813ca77/lucene/analysis/common/src/java/org/apache/lucene/analysis/fr/FrenchMinimalStemmer.java#L77 > But in this minimal stemmer there is no check to see if the character is a > letter or not. > So when we have numeric tokens with the last two characters identical they > are altered. > For example "1234567899" will be stemmed as "123456789". > It could be great of it's not altered. > Here is the same issue for the LightStemmer : > https://issues.apache.org/jira/browse/LUCENE-4063 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13663) XML Query Parser to Support SpanPositionRangeQuery
Alessandro Benedetti created SOLR-13663: --- Summary: XML Query Parser to Support SpanPositionRangeQuery Key: SOLR-13663 URL: https://issues.apache.org/jira/browse/SOLR-13663 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: query parsers Affects Versions: 8.2 Reporter: Alessandro Benedetti Currently the XML Query Parser support a vast array of span queries, including the SpanFirstQuery, but it doesn't support the generic SpanPositionRangeQuery. < SpanPositionRange start="2" end="3"> prejudice -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-10913) Incosistent function query results inside conditional
[ https://issues.apache.org/jira/browse/SOLR-10913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Munendra S N resolved SOLR-10913. - Resolution: Fixed This is fixed in SOLR-11758 > Incosistent function query results inside conditional > - > > Key: SOLR-10913 > URL: https://issues.apache.org/jira/browse/SOLR-10913 > Project: Solr > Issue Type: Bug >Affects Versions: 6.4.1 >Reporter: Mykhailo Kozik >Priority: Major > > Hey, I was trying to simulate gt function on old version of solr (5.5.0) > using sub and max > (afaik, gt is not available on 5.5.0) > I found strange inconsistency for function queries (reproducible on 6.4.1 as > well) > For simplest usecase, have at least 1 doc in solr collection and provide > addition fl parameter: > fl=*,max(0, 0.9), if(0, 1, 0), if(0.9, 1, 0), if(max(0, 0.9), 1, 0), > if(max(0, 1.1), 1, 0) > The output is following: > "max(0, 0.9)":0.9, > "if(0, 1, 0)":0, > "if(0.9, 1, 0)":1, > "if(max(0, 0.9), 1, 0)":0, > "if(max(0, 1.1), 1, 0)":1 > 4th usecase seems strange to me and inconsistent to previous expressions as > well. > Could you clarify if it's a bug or I am doing something wrong. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-8.x - Build # 165 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/165/ 1 tests failed. FAILED: org.apache.solr.cloud.AliasIntegrationTest.testClusterStateProviderAPI Error Message: should be a routed alias Stack Trace: java.lang.AssertionError: should be a routed alias at __randomizedtesting.SeedInfo.seed([D1FEFD814D87287B:CE2961AD3E8CD130]:0) at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.assertTrue(Assert.java:41) at org.apache.solr.cloud.AliasIntegrationTest.testClusterStateProviderAPI(AliasIntegrationTest.java:315) 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:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) 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:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) 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 15162 lines...] [junit4] Suite: org.apache.solr.cloud.AliasIntegrationTest [junit4] 2> 3785077 INFO (SUITE-AliasIntegrationTest-seed#[D1FEFD814D87287B]-worker) [ ] o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom [junit4]
[jira] [Updated] (LUCENE-8941) Build wildcard matches more lazily
[ https://issues.apache.org/jira/browse/LUCENE-8941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward updated LUCENE-8941: -- Attachment: LUCENE-8941.patch > Build wildcard matches more lazily > -- > > Key: LUCENE-8941 > URL: https://issues.apache.org/jira/browse/LUCENE-8941 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Attachments: LUCENE-8941.patch > > > When retrieving a Matches object from a multi-term query, such as an > AutomatonQuery or TermInSetQuery, we currently find all matching term > iterators up-front, to return a disjunction over all of them. This can be > inefficient if we're only interested in finding out if anything matched, and > are iterating over a different field to retrieve offsets. > We can improve this by returning immediately when the first matching term is > found, and only collecting other matching terms when we start iterating. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8941) Build wildcard matches more lazily
Alan Woodward created LUCENE-8941: - Summary: Build wildcard matches more lazily Key: LUCENE-8941 URL: https://issues.apache.org/jira/browse/LUCENE-8941 Project: Lucene - Core Issue Type: Improvement Reporter: Alan Woodward Assignee: Alan Woodward When retrieving a Matches object from a multi-term query, such as an AutomatonQuery or TermInSetQuery, we currently find all matching term iterators up-front, to return a disjunction over all of them. This can be inefficient if we're only interested in finding out if anything matched, and are iterating over a different field to retrieve offsets. We can improve this by returning immediately when the first matching term is found, and only collecting other matching terms when we start iterating. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13660) AbstractFullDistribZkTestBase.waitForActiveReplicaCount is broken
[
https://issues.apache.org/jira/browse/SOLR-13660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895994#comment-16895994
]
Lucene/Solr QA commented on SOLR-13660:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
49s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
38s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
38s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 1m 38s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 1m 38s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 1m 38s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
35s{color} | {color:green} test-framework in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 7m 51s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-13660 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12976151/SOLR-13660.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene1-us-west 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24
10:55:24 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / cb94eeb491 |
| ant | version: Apache Ant(TM) version 1.10.5 compiled on March 28 2019 |
| Default Java | LTS |
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/516/testReport/ |
| modules | C: solr/test-framework U: solr/test-framework |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/516/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> AbstractFullDistribZkTestBase.waitForActiveReplicaCount is broken
> -
>
> Key: SOLR-13660
> URL: https://issues.apache.org/jira/browse/SOLR-13660
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13660.patch
>
>
> {{AbstractFullDistribZkTestBase.waitForActiveReplicaCount(...)}} is broken,
> and does not actually check that the replicas are active.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13661) A package management system for Solr
[
https://issues.apache.org/jira/browse/SOLR-13661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895961#comment-16895961
]
Noble Paul edited comment on SOLR-13661 at 7/30/19 9:55 AM:
The objective of this is to ensure that we install/update packages without
restarting Solr or reloading cores. It should also be possible to load/reload
packages independent of each other.
for example: Say I have 1000's of nodes and a few dozen collections and I have
a different collections using different packages and each collection may use
more than one package. when I issue a command to
{code}
bin/solr update-package
{code}
It should just reload the objects loaded from this package in those nodes alone
without disrupting any requests in flight. If {{pkg1}} contains a cache
implementation & {{pkg2}} contains a SearchComponent, and I update {{pkg2}} the
caches should not be cleared , only the searchcomponent instances should be
reloaded
was (Author: noble.paul):
The objective of this is to ensure that we install/update packages without
restarting Solr or reloading cores. It should also be possible to load/reload
packages independent of each other.
> A package management system for Solr
>
>
> Key: SOLR-13661
> URL: https://issues.apache.org/jira/browse/SOLR-13661
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Priority: Major
>
> Solr needs a unified cohesive package management system so that users can
> deploy/redeploy plugins in a safe manner. This is an umbrella issue to
> eventually build that solution
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13661) A package management system for Solr
[ https://issues.apache.org/jira/browse/SOLR-13661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895961#comment-16895961 ] Noble Paul commented on SOLR-13661: --- The objective of this is to ensure that we install/update packages without restarting Solr or reloading cores. It should also be possible to load/reload packages independent of each other. > A package management system for Solr > > > Key: SOLR-13661 > URL: https://issues.apache.org/jira/browse/SOLR-13661 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Priority: Major > > Solr needs a unified cohesive package management system so that users can > deploy/redeploy plugins in a safe manner. This is an umbrella issue to > eventually build that solution -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13661) A package management system for Solr
[ https://issues.apache.org/jira/browse/SOLR-13661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895935#comment-16895935 ] Jan Høydahl commented on SOLR-13661: [~noble.paul], please see SOLR-10665 for prior work on package system, no need to start from scratch. In particular I did lots of work defining a plugin package unit and how to discover, download and install those. > A package management system for Solr > > > Key: SOLR-13661 > URL: https://issues.apache.org/jira/browse/SOLR-13661 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Priority: Major > > Solr needs a unified cohesive package management system so that users can > deploy/redeploy plugins in a safe manner. This is an umbrella issue to > eventually build that solution -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8937) Avoid agressive stemming on numbers in the FrenchMinimalStemmer
[ https://issues.apache.org/jira/browse/LUCENE-8937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895916#comment-16895916 ] Tomoko Uchida commented on LUCENE-8937: --- +1 I will commit it to the master in shortly. This changes the behaviour of the stemmer, so I won't backport to 8.x. (Since it's not a bug, but design change - see the discussion on LUCENE-4063.) > Avoid agressive stemming on numbers in the FrenchMinimalStemmer > --- > > Key: LUCENE-8937 > URL: https://issues.apache.org/jira/browse/LUCENE-8937 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Gallou >Priority: Minor > Attachments: > 0001-LUCENE-8937-Avoid-agressive-stemming-on-numbers-in-t.patch, > LUCENE-8937.patch > > > Here is the discussion on the mailing list : > [http://mail-archives.apache.org/mod_mbox/lucene-java-user/201907.mbox/browser] > The light stemmer removes the last character of a word if the last two > characters are identical. > We can see that here: > > https://github.com/apache/lucene-solr/blob/813ca77/lucene/analysis/common/src/java/org/apache/lucene/analysis/fr/FrenchLightStemmer.java#L263 > In this light stemmer, there is a check to avoid altering the token if the > token is a number. > The minimal stemmer also removes the last character of a word if the last > two characters are identical. > We can see that here: > > https://github.com/apache/lucene-solr/blob/813ca77/lucene/analysis/common/src/java/org/apache/lucene/analysis/fr/FrenchMinimalStemmer.java#L77 > But in this minimal stemmer there is no check to see if the character is a > letter or not. > So when we have numeric tokens with the last two characters identical they > are altered. > For example "1234567899" will be stemmed as "123456789". > It could be great of it's not altered. > Here is the same issue for the LightStemmer : > https://issues.apache.org/jira/browse/LUCENE-4063 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - 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-11.0.3) - Build # 24470 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24470/
Java: 64bit/jdk-11.0.3 -XX:+UseCompressedOops -XX:+UseG1GC
All tests passed
Build Log:
[...truncated 64198 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj1207839879
[ecj-lint] Compiling 1283 source files to /tmp/ecj1207839879
[ecj-lint] Processing annotations
[ecj-lint] Annotations processed
[ecj-lint] Processing annotations
[ecj-lint] No elements to process
[ecj-lint] invalid Class-Path header in manifest of jar file:
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
[ecj-lint] invalid Class-Path header in manifest of jar file:
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
[ecj-lint] --
[ecj-lint] 1. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java
(at line 219)
[ecj-lint] return (NamedList) new
JavaBinCodec(resolver).unmarshal(in);
[ecj-lint]^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 2. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
(at line 788)
[ecj-lint] throw new UnsupportedOperationException("must add at least 1
node first");
[ecj-lint]
^^
[ecj-lint] Resource leak: 'queryRequest' is not closed at this location
[ecj-lint] --
[ecj-lint] 3. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
(at line 794)
[ecj-lint] throw new UnsupportedOperationException("must add at least 1
node first");
[ecj-lint]
^^
[ecj-lint] Resource leak: 'queryRequest' is not closed at this location
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 4. ERROR in
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 19)
[ecj-lint] import javax.naming.Context;
[ecj-lint]
[ecj-lint] The type javax.naming.Context is not accessible
[ecj-lint] --
[ecj-lint] 5. ERROR in
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 20)
[ecj-lint] import javax.naming.InitialContext;
[ecj-lint]^^^
[ecj-lint] The type javax.naming.InitialContext is not accessible
[ecj-lint] --
[ecj-lint] 6. ERROR in
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 21)
[ecj-lint] import javax.naming.NamingException;
[ecj-lint]
[ecj-lint] The type javax.naming.NamingException is not accessible
[ecj-lint] --
[ecj-lint] 7. ERROR in
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 22)
[ecj-lint] import javax.naming.NoInitialContextException;
[ecj-lint]^^
[ecj-lint] The type javax.naming.NoInitialContextException is not accessible
[ecj-lint] --
[ecj-lint] 8. ERROR in
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 776)
[ecj-lint] Context c = new InitialContext();
[ecj-lint] ^^^
[ecj-lint] Context cannot be resolved to a type
[ecj-lint] --
[ecj-lint] 9. ERROR in
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 776)
[ecj-lint] Context c = new InitialContext();
[ecj-lint] ^^
[ecj-lint] InitialContext cannot be resolved to a type
[ecj-lint] --
[ecj-lint] 10. ERROR in
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 779)
[ecj-lint] } catch (NoInitialContextException e) {
[ecj-lint] ^
[ecj-lint] NoInitialContextException cannot be resolved to a type
[ecj-lint] --
[ecj-lint] 11. ERROR in
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 781)
[ecj-lint] } catch (NamingException e) {
[ecj-lint] ^^^
[ecj-lint] NamingException cannot be resolved to a type
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 12. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/handler/SolrConfigHandler.java
(at line
[jira] [Commented] (LUCENE-8937) Avoid agressive stemming on numbers in the FrenchMinimalStemmer
[ https://issues.apache.org/jira/browse/LUCENE-8937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895815#comment-16895815 ] Adrien Gallou commented on LUCENE-8937: --- I've updated the attachments with the new version of the patch. > Avoid agressive stemming on numbers in the FrenchMinimalStemmer > --- > > Key: LUCENE-8937 > URL: https://issues.apache.org/jira/browse/LUCENE-8937 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Gallou >Priority: Minor > Attachments: > 0001-LUCENE-8937-Avoid-agressive-stemming-on-numbers-in-t.patch, > LUCENE-8937.patch > > > Here is the discussion on the mailing list : > [http://mail-archives.apache.org/mod_mbox/lucene-java-user/201907.mbox/browser] > The light stemmer removes the last character of a word if the last two > characters are identical. > We can see that here: > > https://github.com/apache/lucene-solr/blob/813ca77/lucene/analysis/common/src/java/org/apache/lucene/analysis/fr/FrenchLightStemmer.java#L263 > In this light stemmer, there is a check to avoid altering the token if the > token is a number. > The minimal stemmer also removes the last character of a word if the last > two characters are identical. > We can see that here: > > https://github.com/apache/lucene-solr/blob/813ca77/lucene/analysis/common/src/java/org/apache/lucene/analysis/fr/FrenchMinimalStemmer.java#L77 > But in this minimal stemmer there is no check to see if the character is a > letter or not. > So when we have numeric tokens with the last two characters identical they > are altered. > For example "1234567899" will be stemmed as "123456789". > It could be great of it's not altered. > Here is the same issue for the LightStemmer : > https://issues.apache.org/jira/browse/LUCENE-4063 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8937) Avoid agressive stemming on numbers in the FrenchMinimalStemmer
[ https://issues.apache.org/jira/browse/LUCENE-8937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Gallou updated LUCENE-8937: -- Attachment: (was: 0002-check-if-the-last-character-is-a-letter-before-remov.patch) > Avoid agressive stemming on numbers in the FrenchMinimalStemmer > --- > > Key: LUCENE-8937 > URL: https://issues.apache.org/jira/browse/LUCENE-8937 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Gallou >Priority: Minor > Attachments: > 0001-LUCENE-8937-Avoid-agressive-stemming-on-numbers-in-t.patch, > LUCENE-8937.patch > > > Here is the discussion on the mailing list : > [http://mail-archives.apache.org/mod_mbox/lucene-java-user/201907.mbox/browser] > The light stemmer removes the last character of a word if the last two > characters are identical. > We can see that here: > > https://github.com/apache/lucene-solr/blob/813ca77/lucene/analysis/common/src/java/org/apache/lucene/analysis/fr/FrenchLightStemmer.java#L263 > In this light stemmer, there is a check to avoid altering the token if the > token is a number. > The minimal stemmer also removes the last character of a word if the last > two characters are identical. > We can see that here: > > https://github.com/apache/lucene-solr/blob/813ca77/lucene/analysis/common/src/java/org/apache/lucene/analysis/fr/FrenchMinimalStemmer.java#L77 > But in this minimal stemmer there is no check to see if the character is a > letter or not. > So when we have numeric tokens with the last two characters identical they > are altered. > For example "1234567899" will be stemmed as "123456789". > It could be great of it's not altered. > Here is the same issue for the LightStemmer : > https://issues.apache.org/jira/browse/LUCENE-4063 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8937) Avoid agressive stemming on numbers in the FrenchMinimalStemmer
[ https://issues.apache.org/jira/browse/LUCENE-8937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Gallou updated LUCENE-8937: -- Attachment: (was: SOLR-8937.patch) > Avoid agressive stemming on numbers in the FrenchMinimalStemmer > --- > > Key: LUCENE-8937 > URL: https://issues.apache.org/jira/browse/LUCENE-8937 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Gallou >Priority: Minor > Attachments: > 0001-LUCENE-8937-Avoid-agressive-stemming-on-numbers-in-t.patch, > LUCENE-8937.patch > > > Here is the discussion on the mailing list : > [http://mail-archives.apache.org/mod_mbox/lucene-java-user/201907.mbox/browser] > The light stemmer removes the last character of a word if the last two > characters are identical. > We can see that here: > > https://github.com/apache/lucene-solr/blob/813ca77/lucene/analysis/common/src/java/org/apache/lucene/analysis/fr/FrenchLightStemmer.java#L263 > In this light stemmer, there is a check to avoid altering the token if the > token is a number. > The minimal stemmer also removes the last character of a word if the last > two characters are identical. > We can see that here: > > https://github.com/apache/lucene-solr/blob/813ca77/lucene/analysis/common/src/java/org/apache/lucene/analysis/fr/FrenchMinimalStemmer.java#L77 > But in this minimal stemmer there is no check to see if the character is a > letter or not. > So when we have numeric tokens with the last two characters identical they > are altered. > For example "1234567899" will be stemmed as "123456789". > It could be great of it's not altered. > Here is the same issue for the LightStemmer : > https://issues.apache.org/jira/browse/LUCENE-4063 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8937) Avoid agressive stemming on numbers in the FrenchMinimalStemmer
[ https://issues.apache.org/jira/browse/LUCENE-8937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Gallou updated LUCENE-8937: -- Attachment: LUCENE-8937.patch 0001-LUCENE-8937-Avoid-agressive-stemming-on-numbers-in-t.patch > Avoid agressive stemming on numbers in the FrenchMinimalStemmer > --- > > Key: LUCENE-8937 > URL: https://issues.apache.org/jira/browse/LUCENE-8937 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Gallou >Priority: Minor > Attachments: > 0001-LUCENE-8937-Avoid-agressive-stemming-on-numbers-in-t.patch, > LUCENE-8937.patch > > > Here is the discussion on the mailing list : > [http://mail-archives.apache.org/mod_mbox/lucene-java-user/201907.mbox/browser] > The light stemmer removes the last character of a word if the last two > characters are identical. > We can see that here: > > https://github.com/apache/lucene-solr/blob/813ca77/lucene/analysis/common/src/java/org/apache/lucene/analysis/fr/FrenchLightStemmer.java#L263 > In this light stemmer, there is a check to avoid altering the token if the > token is a number. > The minimal stemmer also removes the last character of a word if the last > two characters are identical. > We can see that here: > > https://github.com/apache/lucene-solr/blob/813ca77/lucene/analysis/common/src/java/org/apache/lucene/analysis/fr/FrenchMinimalStemmer.java#L77 > But in this minimal stemmer there is no check to see if the character is a > letter or not. > So when we have numeric tokens with the last two characters identical they > are altered. > For example "1234567899" will be stemmed as "123456789". > It could be great of it's not altered. > Here is the same issue for the LightStemmer : > https://issues.apache.org/jira/browse/LUCENE-4063 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8937) Avoid agressive stemming on numbers in the FrenchMinimalStemmer
[ https://issues.apache.org/jira/browse/LUCENE-8937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Gallou updated LUCENE-8937: -- Attachment: (was: 0001-adds-test-cases-on-french-minimal-stemmer.patch) > Avoid agressive stemming on numbers in the FrenchMinimalStemmer > --- > > Key: LUCENE-8937 > URL: https://issues.apache.org/jira/browse/LUCENE-8937 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Gallou >Priority: Minor > Attachments: > 0002-check-if-the-last-character-is-a-letter-before-remov.patch, > SOLR-8937.patch > > > Here is the discussion on the mailing list : > [http://mail-archives.apache.org/mod_mbox/lucene-java-user/201907.mbox/browser] > The light stemmer removes the last character of a word if the last two > characters are identical. > We can see that here: > > https://github.com/apache/lucene-solr/blob/813ca77/lucene/analysis/common/src/java/org/apache/lucene/analysis/fr/FrenchLightStemmer.java#L263 > In this light stemmer, there is a check to avoid altering the token if the > token is a number. > The minimal stemmer also removes the last character of a word if the last > two characters are identical. > We can see that here: > > https://github.com/apache/lucene-solr/blob/813ca77/lucene/analysis/common/src/java/org/apache/lucene/analysis/fr/FrenchMinimalStemmer.java#L77 > But in this minimal stemmer there is no check to see if the character is a > letter or not. > So when we have numeric tokens with the last two characters identical they > are altered. > For example "1234567899" will be stemmed as "123456789". > It could be great of it's not altered. > Here is the same issue for the LightStemmer : > https://issues.apache.org/jira/browse/LUCENE-4063 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8937) Avoid agressive stemming on numbers in the FrenchMinimalStemmer
[ https://issues.apache.org/jira/browse/LUCENE-8937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Gallou updated LUCENE-8937: -- Description: Here is the discussion on the mailing list : [http://mail-archives.apache.org/mod_mbox/lucene-java-user/201907.mbox/browser] The light stemmer removes the last character of a word if the last two characters are identical. We can see that here: https://github.com/apache/lucene-solr/blob/813ca77/lucene/analysis/common/src/java/org/apache/lucene/analysis/fr/FrenchLightStemmer.java#L263 In this light stemmer, there is a check to avoid altering the token if the token is a number. The minimal stemmer also removes the last character of a word if the last two characters are identical. We can see that here: https://github.com/apache/lucene-solr/blob/813ca77/lucene/analysis/common/src/java/org/apache/lucene/analysis/fr/FrenchMinimalStemmer.java#L77 But in this minimal stemmer there is no check to see if the character is a letter or not. So when we have numeric tokens with the last two characters identical they are altered. For example "1234567899" will be stemmed as "123456789". It could be great of it's not altered. Here is the same issue for the LightStemmer : https://issues.apache.org/jira/browse/LUCENE-4063 was: Here is the discussion on the mailing list : [http://mail-archives.apache.org/mod_mbox/lucene-java-user/201907.mbox/browser] The light stemmer removes the last character of a word if the last two characters are identical. We can see that here: [https://github.com/apache/lucene-solr/blob/master/lucene/analysis/common/src/java/org/apache/lucene/analysis/fr/FrenchLightStemmer.java#L263] In this light stemmer, there is a check to avoid altering the token if the token is a number. The minimal stemmer also removes the last character of a word if the last two characters are identical. We can see that here: [https://github.com/apache/lucene-solr/blob/master/lucene/analysis/common/src/java/org/apache/lucene/analysis/fr/FrenchMinimalStemmer.java#L77] But in this minimal stemmer there is no check to see if the character is a letter or not. So when we have numeric tokens with the last two characters identical they are altered. For example "1234567899" will be stemmed as "123456789". It could be great of it's not altered. Here is the same issue for the LightStemmer : https://issues.apache.org/jira/browse/LUCENE-4063 > Avoid agressive stemming on numbers in the FrenchMinimalStemmer > --- > > Key: LUCENE-8937 > URL: https://issues.apache.org/jira/browse/LUCENE-8937 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Gallou >Priority: Minor > Attachments: 0001-adds-test-cases-on-french-minimal-stemmer.patch, > 0002-check-if-the-last-character-is-a-letter-before-remov.patch, > SOLR-8937.patch > > > Here is the discussion on the mailing list : > [http://mail-archives.apache.org/mod_mbox/lucene-java-user/201907.mbox/browser] > The light stemmer removes the last character of a word if the last two > characters are identical. > We can see that here: > > https://github.com/apache/lucene-solr/blob/813ca77/lucene/analysis/common/src/java/org/apache/lucene/analysis/fr/FrenchLightStemmer.java#L263 > In this light stemmer, there is a check to avoid altering the token if the > token is a number. > The minimal stemmer also removes the last character of a word if the last > two characters are identical. > We can see that here: > > https://github.com/apache/lucene-solr/blob/813ca77/lucene/analysis/common/src/java/org/apache/lucene/analysis/fr/FrenchMinimalStemmer.java#L77 > But in this minimal stemmer there is no check to see if the character is a > letter or not. > So when we have numeric tokens with the last two characters identical they > are altered. > For example "1234567899" will be stemmed as "123456789". > It could be great of it's not altered. > Here is the same issue for the LightStemmer : > https://issues.apache.org/jira/browse/LUCENE-4063 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
