[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-13-ea+shipilev-fastdebug) - Build # 23814 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23814/
Java: 64bit/jdk-13-ea+shipilev-fastdebug -XX:+UseCompressedOops
-XX:+UseConcMarkSweepGC
1 tests failed.
FAILED: org.apache.solr.metrics.rrd.SolrRrdBackendFactoryTest.testBasic
Error Message:
{} expected:<1> but was:<0>
Stack Trace:
java.lang.AssertionError: {} expected:<1> but was:<0>
at
__randomizedtesting.SeedInfo.seed([44B8D0219DB20DE4:EF42CD34426E8BCA]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at
org.apache.solr.metrics.rrd.SolrRrdBackendFactoryTest.testBasic(SolrRrdBackendFactoryTest.java:92)
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
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:835)
Build Log:
[...truncated 2075 lines...]
[junit4] JVM J1: stderr was not empty, see:
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/core/test/temp/junit4-J1-20190323_023243_58717118959541886603108.syserr
[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-12) - Build # 7821 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7821/ Java: 64bit/jdk-12 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.client.solrj.impl.CloudHttp2SolrClientTest Error Message: ObjectTracker found 5 object(s) that were not released!!! [MockDirectoryWrapper, SolrCore, MockDirectoryWrapper, MockDirectoryWrapper, MockDirectoryWrapper] org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.lucene.store.MockDirectoryWrapper at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348) at org.apache.solr.core.SolrCore.initSnapshotMetaDataManager(SolrCore.java:517) at org.apache.solr.core.SolrCore.(SolrCore.java:968) at org.apache.solr.core.SolrCore.(SolrCore.java:883) at org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1193) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1103) at org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:92) at org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:360) at org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:396) at org.apache.solr.handler.admin.CoreAdminHandler.lambda$handleRequestBody$0(CoreAdminHandler.java:188) at com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:835) org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.solr.core.SolrCore at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.core.SolrCore.(SolrCore.java:1063) at org.apache.solr.core.SolrCore.(SolrCore.java:883) at org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1193) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1103) at org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:92) at org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:360) at org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:396) at org.apache.solr.handler.admin.CoreAdminHandler.lambda$handleRequestBody$0(CoreAdminHandler.java:188) at com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:835) org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.lucene.store.MockDirectoryWrapper at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348) at org.apache.solr.core.SolrCore.getNewIndexDir(SolrCore.java:368) at org.apache.solr.core.SolrCore.initIndex(SolrCore.java:747) at org.apache.solr.core.SolrCore.(SolrCore.java:976) at org.apache.solr.core.SolrCore.(SolrCore.java:883) at org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1193) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1103) at org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:92) at org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:360) at org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:396) at org.apache.solr.handler.admin.CoreAdminHandler.lambda$handleRequestBody$0(CoreAdminHandler.java:188) at com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:835) org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.lucene.store.MockDirectoryWrapper at org.apache.solr.common.util.
[jira] [Commented] (SOLR-13342) Remove dom4j from Solr
[ https://issues.apache.org/jira/browse/SOLR-13342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16799512#comment-16799512 ] Christopher Schultz commented on SOLR-13342: FWIW, Velocity Tools only has a runtime dependency on dom4j if you actually try to use the XML DOM-navigation tools – specifically, the `XmlTool` class. If that's not being used by Solr, then you are safe to drop the dependency even if it's advertised as a dependency for velocity-tools 2.0. Something tells me Solr isn't using XML DOM for *anything* given its memory requirements. > Remove dom4j from Solr > -- > > Key: SOLR-13342 > URL: https://issues.apache.org/jira/browse/SOLR-13342 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Kevin Risden >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: SOLR-13342.patch, SOLR-13342.patch > > Time Spent: 20m > Remaining Estimate: 0h > > dom4j is used in exactly one file in Solr, and it's a test: > AddBlockUpdateTest > It seems like overkill to bloat the distro with that jar for one test, can we > change the test to use something else and remove dom4j from our distro? > IDK whether there are transitive dependencies though. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13342) Remove dom4j from Solr
[ https://issues.apache.org/jira/browse/SOLR-13342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16799509#comment-16799509 ] Erick Erickson commented on SOLR-13342: --- Looks good to me. Precommit passes, I can "ant package". The exploded package only has the dom jars in contrib (pending veolcity I think?). I'm running the full test suite now, but don't anticipate any troubles, if I don't get back with another message tonight, assume success > Remove dom4j from Solr > -- > > Key: SOLR-13342 > URL: https://issues.apache.org/jira/browse/SOLR-13342 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Kevin Risden >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: SOLR-13342.patch, SOLR-13342.patch > > Time Spent: 20m > Remaining Estimate: 0h > > dom4j is used in exactly one file in Solr, and it's a test: > AddBlockUpdateTest > It seems like overkill to bloat the distro with that jar for one test, can we > change the test to use something else and remove dom4j from our distro? > IDK whether there are transitive dependencies though. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-8.x-Linux (64bit/jdk-13-ea+shipilev-fastdebug) - Build # 294 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/294/
Java: 64bit/jdk-13-ea+shipilev-fastdebug -XX:+UseCompressedOops -XX:+UseG1GC
1 tests failed.
FAILED: org.apache.solr.metrics.rrd.SolrRrdBackendFactoryTest.testBasic
Error Message:
{} expected:<1> but was:<0>
Stack Trace:
java.lang.AssertionError: {} expected:<1> but was:<0>
at
__randomizedtesting.SeedInfo.seed([EE845BD56640A95A:457E46C0B99C2F74]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at
org.apache.solr.metrics.rrd.SolrRrdBackendFactoryTest.testBasic(SolrRrdBackendFactoryTest.java:92)
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
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:835)
Build Log:
[...truncated 14169 lines...]
[junit4] Suite: org.apache.solr.metrics.rrd.SolrRrdBackendFactoryTest
[junit4] 2> Creating dataDir:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/build/solr-core/test/J2/temp/solr.metri
[JENKINS] Lucene-Solr-NightlyTests-8.x - Build # 51 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/51/ 7 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest Error Message: ObjectTracker found 6 object(s) that were not released!!! [MMapDirectory, MMapDirectory, MMapDirectory, MMapDirectory, InternalHttpClient, SolrCore] org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.lucene.store.MMapDirectory at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348) at org.apache.solr.core.SolrCore.initSnapshotMetaDataManager(SolrCore.java:517) at org.apache.solr.core.SolrCore.(SolrCore.java:968) at org.apache.solr.core.SolrCore.(SolrCore.java:883) at org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1193) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1103) at org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:92) at org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:360) at org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:396) at org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:180) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199) at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:744) at org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:717) at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:394) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610) at org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:165) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588) at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:703) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) at org.eclipse.jetty.server.Server.handle(Server.java:502) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364) at org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:305) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765) at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683) at java.lang.Thread.run(Thread.java:748) org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.lucene.store.MMapDirectory at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348) at org.apache.solr.core.SolrCore.getNewIndexDir(SolrCore.java:368) at org.apache.solr.core.SolrCore.initIndex(SolrCore.java:747) at org.apache.solr.core.SolrCore.(SolrCore.java:976) at org.apache.solr.core.SolrCore.(SolrCore.java:883) at org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1193) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1103) at org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:92) at org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:360) at org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:396) at org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:180) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199) at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:744) at org.apache.solr.servlet.HttpSolrCall.handl
[JENKINS] Lucene-Solr-8.x-Windows (64bit/jdk-10.0.1) - Build # 135 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/135/ Java: 64bit/jdk-10.0.1 -XX:-UseCompressedOops -XX:+UseParallelGC All tests passed Build Log: [...truncated 15702 lines...] [junit4] JVM J1: stdout was not empty, see: C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\build\solr-core\test\temp\junit4-J1-20190322_234711_1097262703637198137996.sysout [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] java.lang.OutOfMemoryError: GC overhead limit exceeded [junit4] Dumping heap to C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\heapdumps\java_pid7516.hprof ... [junit4] Heap dump file created [482291388 bytes in 10.985 secs] [junit4] <<< JVM J1: EOF [junit4] JVM J1: stderr was not empty, see: C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\build\solr-core\test\temp\junit4-J1-20190322_234711_10911021923670757245011.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] WARN: Unhandled exception in event serialization. -> java.lang.OutOfMemoryError: GC overhead limit exceeded [junit4] <<< JVM J1: EOF [...truncated 2 lines...] [junit4] ERROR: JVM J1 ended with an exception, command line: C:\Users\jenkins\tools\java\64bit\jdk-10.0.1\bin\java.exe -XX:-UseCompressedOops -XX:+UseParallelGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\heapdumps -ea -esa --illegal-access=deny -Dtests.prefix=tests -Dtests.seed=1C0DF3280160AA28 -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.1.0 -Dtests.cleanthreads=perClass -Djava.util.logging.config.file=C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\lucene\tools\junit4\logging.properties -Dtests.nightly=false -Dtests.weekly=false -Dtests.monster=false -Dtests.slow=true -Dtests.asserts=true -Dtests.multiplier=1 -DtempDir=./temp -Djava.io.tmpdir=./temp -Dcommon.dir=C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\lucene -Dclover.db.dir=C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\lucene\build\clover\db -Djava.security.policy=C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\lucene\tools\junit4\solr-tests.policy -Dtests.LUCENE_VERSION=8.1.0 -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=C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows -Djava.security.egd=file:/dev/./urandom -Djunit4.childvm.cwd=C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\build\solr-core\test\J1 -Djunit4.tempDir=C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\build\solr-core\test\temp -Djunit4.childvm.id=1 -Djunit4.childvm.count=2 -Dfile.encoding=US-ASCII -Dtests.disableHdfs=true -Djava.security.manager=org.apache.lucene.util.TestSecurityManager -Dtests.filterstacks=true -Dtests.leaveTemporary=false -Dtests.badapples=false -classpath C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\build\solr-core\classes\test;C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\build\solr-test-framework\classes\java;C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\test-framework\lib\hamcrest-core-1.3.jar;C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\test-framework\lib\junit4-ant-2.7.2.jar;C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\core\src\test-files;C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\lucene\build\test-framework\classes\java;C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\lucene\build\codecs\classes\java;C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\build\solr-solrj\classes\java;C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\build\solr-core\classes\java;C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\lucene\build\analysis\common\lucene-analyzers-common-8.1.0-SNAPSHOT.jar;C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\lucene\build\analysis\kuromoji\lucene-analyzers-kuromoji-8.1.0-SNAPSHOT.jar;C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\lucene\build\analysis\nori\lucene-analyzers-nori-8.1.0-SNAPSHOT.jar;C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\lucene\build\analysis\phonetic\lucene-analyzers-phonetic-8.1.0-SNAPSHOT.jar;C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\lucene\build\codecs\lucene-codecs-8.1.0-SNAPSHOT.jar;C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\lucene\build\backward-codecs\lucene-backward-codecs-8.1.0-SNAPSHOT.jar;C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\lucene\build\highlighter\lucene-highlighter-8.1.0-SNAPSHOT.jar;C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\lucene\build\memory\lucene-memory-8.1.0-SNAPSHOT.jar;C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\lucene\build\m
[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_172) - Build # 7820 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7820/ Java: 32bit/jdk1.8.0_172 -server -XX:+UseParallelGC 6 tests failed. FAILED: org.apache.solr.cloud.TestCloudRecovery.leaderRecoverFromLogOnStartupTest Error Message: expected:<4> but was:<3> Stack Trace: java.lang.AssertionError: expected:<4> but was:<3> at __randomizedtesting.SeedInfo.seed([FDD7DDFF3EEFFF1A:89273CBA7ACBB895]:0) at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:834) at org.junit.Assert.assertEquals(Assert.java:645) at org.junit.Assert.assertEquals(Assert.java:631) at org.apache.solr.cloud.TestCloudRecovery.leaderRecoverFromLogOnStartupTest(TestCloudRecovery.java:134) 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) FAILED: org.apache.solr.handler.TestSQLHandler.doTest Error Message: --> http://127.0.0.1:58443/collection1_shard2_replica_n1:Failed to execute sqlQuery 'select id,
[jira] [Updated] (SOLR-13342) Remove dom4j fromj Solr
[ https://issues.apache.org/jira/browse/SOLR-13342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-13342: Description: dom4j is used in exactly one file in Solr, and it's a test: AddBlockUpdateTest It seems like overkill to bloat the distro with that jar for one test, can we change the test to use something else and remove dom4j from our distro? IDK whether there are transitive dependencies though. was: dom4j is used in exactly one file in Solr, and it's a test: AddBlockUpdateTest It seems like overkill to bloat the distro with that jar for one test, can we change the test to use something else and remove dom4j from our distro? Assigning to myself to track, but if anyone has the bandwidth, _please_ take it away ;) IDK whether there are transitive dependencies though. > Remove dom4j fromj Solr > --- > > Key: SOLR-13342 > URL: https://issues.apache.org/jira/browse/SOLR-13342 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Kevin Risden >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: SOLR-13342.patch, SOLR-13342.patch > > Time Spent: 20m > Remaining Estimate: 0h > > dom4j is used in exactly one file in Solr, and it's a test: > AddBlockUpdateTest > It seems like overkill to bloat the distro with that jar for one test, can we > change the test to use something else and remove dom4j from our distro? > IDK whether there are transitive dependencies though. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13335) Upgrade to velocity 2.0 and velocity-tools 3.0
[ https://issues.apache.org/jira/browse/SOLR-13335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16799382#comment-16799382 ] Kevin Risden commented on SOLR-13335: - Velocity upgrade also removes the need for dom4j. See SOLR-13342 > Upgrade to velocity 2.0 and velocity-tools 3.0 > -- > > Key: SOLR-13335 > URL: https://issues.apache.org/jira/browse/SOLR-13335 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: SOLR-13335.patch, SOLR-13335.patch, SOLR-13335.patch, > SOLR-13335.patch, SOLR-13335.patch > > Time Spent: 10m > Remaining Estimate: 0h > > As part of looking to remove old commons-lang in SOLR-9079, found that > velocity depends on it. Upgrading Velocity would allow completely removing > commons-lang > Copy some detail from SOLR-9079 investigation: > * solr/contrib/velocity/ivy.xml doesn't even reference commons-lang > * velocity 1.7 was released - 2010-11-29 > * LUCENE-5249 from 2013 was the last time velocity was changed in > lucene/ivy-versions.properties > * velocity-tools 2.0 has an optional dependency on commons-lang > * velocity 1.7 has a hard dependency on commons-lang. > Upgrading velocity 1.7 -> 2.0 > * http://velocity.apache.org/engine/2.0/upgrading.html > * Change velocity to velocity-engine-core > * upgrades commons-lang to commons-lang3 > So if we want to finish removing commons-lang, we need to upgrade velocity. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13342) Remove dom4j from Solr
[ https://issues.apache.org/jira/browse/SOLR-13342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-13342: Summary: Remove dom4j from Solr (was: Remove dom4j fromj Solr) > Remove dom4j from Solr > -- > > Key: SOLR-13342 > URL: https://issues.apache.org/jira/browse/SOLR-13342 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Kevin Risden >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: SOLR-13342.patch, SOLR-13342.patch > > Time Spent: 20m > Remaining Estimate: 0h > > dom4j is used in exactly one file in Solr, and it's a test: > AddBlockUpdateTest > It seems like overkill to bloat the distro with that jar for one test, can we > change the test to use something else and remove dom4j from our distro? > IDK whether there are transitive dependencies though. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13342) Remove dom4j fromj Solr
[ https://issues.apache.org/jira/browse/SOLR-13342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-13342: Attachment: SOLR-13342.patch > Remove dom4j fromj Solr > --- > > Key: SOLR-13342 > URL: https://issues.apache.org/jira/browse/SOLR-13342 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Kevin Risden >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: SOLR-13342.patch, SOLR-13342.patch > > Time Spent: 20m > Remaining Estimate: 0h > > dom4j is used in exactly one file in Solr, and it's a test: > AddBlockUpdateTest > It seems like overkill to bloat the distro with that jar for one test, can we > change the test to use something else and remove dom4j from our distro? > Assigning to myself to track, but if anyone has the bandwidth, _please_ take > it away ;) > IDK whether there are transitive dependencies though. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13342) Remove dom4j fromj Solr
[ https://issues.apache.org/jira/browse/SOLR-13342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16799380#comment-16799380 ] Kevin Risden commented on SOLR-13342: - Fixed precommit about license for dom4j. Had removed it but has to be there since dependency for velocity still exists for the patch. > Remove dom4j fromj Solr > --- > > Key: SOLR-13342 > URL: https://issues.apache.org/jira/browse/SOLR-13342 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Kevin Risden >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: SOLR-13342.patch, SOLR-13342.patch > > Time Spent: 20m > Remaining Estimate: 0h > > dom4j is used in exactly one file in Solr, and it's a test: > AddBlockUpdateTest > It seems like overkill to bloat the distro with that jar for one test, can we > change the test to use something else and remove dom4j from our distro? > Assigning to myself to track, but if anyone has the bandwidth, _please_ take > it away ;) > IDK whether there are transitive dependencies though. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_172) - Build # 23813 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23813/ Java: 32bit/jdk1.8.0_172 -client -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.cloud.ReindexCollectionTest.testSameTargetReindexing Error Message: copied num docs expected:<200> but was:<171> Stack Trace: java.lang.AssertionError: copied num docs expected:<200> but was:<171> at __randomizedtesting.SeedInfo.seed([77FCDCA1CA337DA9:C2853776CD55E5ED]:0) at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:834) at org.junit.Assert.assertEquals(Assert.java:645) at org.apache.solr.cloud.ReindexCollectionTest.testSameTargetReindexing(ReindexCollectionTest.java:180) 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 14387 lines...] [junit4] Suite: org.apache.solr.cloud.ReindexCollectionTest [junit4] 2> Creating dataDir: /home/jenkins/workspace/Lucene-Solr-master-Linux/sol
[GitHub] [lucene-solr] risdenk commented on issue #617: SOLR-13342: Remove dom4j fromj Solr
risdenk commented on issue #617: SOLR-13342: Remove dom4j fromj Solr URL: https://github.com/apache/lucene-solr/pull/617#issuecomment-475787526 Depending if `SOLR-13335 - Upgrade to velocity 2.0 and velocity-tools 3.0` or this goes in first, will need to fix the other one since they both touch Velocity dependencies. 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] risdenk opened a new pull request #617: SOLR-13342: Remove dom4j fromj Solr
risdenk opened a new pull request #617: SOLR-13342: Remove dom4j fromj Solr URL: https://github.com/apache/lucene-solr/pull/617 * Removes dom4j from core dependencies * Adds to it velocity contrib * Replaces dom4j in test with Java xml handling * Updates licenses/notices that had referenced dom4j historically to their new versions. 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-13342) Remove dom4j fromj Solr
[ https://issues.apache.org/jira/browse/SOLR-13342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16799363#comment-16799363 ] Kevin Risden commented on SOLR-13342: - Depending if SOLR-13335 or this goes in first, will need to update the other one since they both touch Velocity dependencies. > Remove dom4j fromj Solr > --- > > Key: SOLR-13342 > URL: https://issues.apache.org/jira/browse/SOLR-13342 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Kevin Risden >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: SOLR-13342.patch > > > dom4j is used in exactly one file in Solr, and it's a test: > AddBlockUpdateTest > It seems like overkill to bloat the distro with that jar for one test, can we > change the test to use something else and remove dom4j from our distro? > Assigning to myself to track, but if anyone has the bandwidth, _please_ take > it away ;) > IDK whether there are transitive dependencies though. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13342) Remove dom4j fromj Solr
[ https://issues.apache.org/jira/browse/SOLR-13342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16799361#comment-16799361 ] Kevin Risden commented on SOLR-13342: - Attached a patch that: * Removes dom4j from core dependencies * Adds to it velocity contrib * Replaces dom4j in test with Java xml handling * Updates licenses/notices that had referenced dom4j historically to their new versions. > Remove dom4j fromj Solr > --- > > Key: SOLR-13342 > URL: https://issues.apache.org/jira/browse/SOLR-13342 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Kevin Risden >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: SOLR-13342.patch > > > dom4j is used in exactly one file in Solr, and it's a test: > AddBlockUpdateTest > It seems like overkill to bloat the distro with that jar for one test, can we > change the test to use something else and remove dom4j from our distro? > Assigning to myself to track, but if anyone has the bandwidth, _please_ take > it away ;) > IDK whether there are transitive dependencies though. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13342) Remove dom4j fromj Solr
[ https://issues.apache.org/jira/browse/SOLR-13342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-13342: Attachment: SOLR-13342.patch > Remove dom4j fromj Solr > --- > > Key: SOLR-13342 > URL: https://issues.apache.org/jira/browse/SOLR-13342 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Kevin Risden >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: SOLR-13342.patch > > > dom4j is used in exactly one file in Solr, and it's a test: > AddBlockUpdateTest > It seems like overkill to bloat the distro with that jar for one test, can we > change the test to use something else and remove dom4j from our distro? > Assigning to myself to track, but if anyone has the bandwidth, _please_ take > it away ;) > IDK whether there are transitive dependencies though. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13342) Remove dom4j fromj Solr
[ https://issues.apache.org/jira/browse/SOLR-13342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden reassigned SOLR-13342: --- Assignee: Kevin Risden (was: Erick Erickson) > Remove dom4j fromj Solr > --- > > Key: SOLR-13342 > URL: https://issues.apache.org/jira/browse/SOLR-13342 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Kevin Risden >Priority: Major > > dom4j is used in exactly one file in Solr, and it's a test: > AddBlockUpdateTest > It seems like overkill to bloat the distro with that jar for one test, can we > change the test to use something else and remove dom4j from our distro? > Assigning to myself to track, but if anyone has the bandwidth, _please_ take > it away ;) > IDK whether there are transitive dependencies though. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13342) Remove dom4j fromj Solr
[ https://issues.apache.org/jira/browse/SOLR-13342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-13342: Fix Version/s: master (9.0) 8.1 > Remove dom4j fromj Solr > --- > > Key: SOLR-13342 > URL: https://issues.apache.org/jira/browse/SOLR-13342 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Kevin Risden >Priority: Major > Fix For: 8.1, master (9.0) > > > dom4j is used in exactly one file in Solr, and it's a test: > AddBlockUpdateTest > It seems like overkill to bloat the distro with that jar for one test, can we > change the test to use something else and remove dom4j from our distro? > Assigning to myself to track, but if anyone has the bandwidth, _please_ take > it away ;) > IDK whether there are transitive dependencies though. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12860) MetricsHistoryHandler does not work with BasicAuth
[
https://issues.apache.org/jira/browse/SOLR-12860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16799359#comment-16799359
]
Lorenzo commented on SOLR-12860:
I have reached in the *PKIAuthenticationPlugin*
{code:java}
private class HttpHeaderClientInterceptor implements HttpRequestInterceptor {
public HttpHeaderClientInterceptor() {
}
@Override
public void process(HttpRequest httpRequest, HttpContext httpContext) throws
HttpException, IOException {
if (cores.getAuthenticationPlugin() == null) {
return;
}
if (!cores.getAuthenticationPlugin().interceptInternodeRequest(httpRequest,
httpContext)) {
log.debug("{} secures this internode request",
this.getClass().getSimpleName());
setHeader(httpRequest);
} else {
log.debug("{} secures this internode request",
cores.getAuthenticationPlugin().getClass().getSimpleName());
}
}{code}
this actually is going through the BasicAuthPlugin on every requests but
forwardCredentials is false.
{code:java}
@Override
protected boolean interceptInternodeRequest(HttpRequest httpRequest,
HttpContext httpContext) {
if (forwardCredentials) {
if (httpContext instanceof HttpClientContext) {
HttpClientContext httpClientContext = (HttpClientContext) httpContext;
if (httpClientContext.getUserToken() instanceof BasicAuthUserPrincipal) {
BasicAuthUserPrincipal principal = (BasicAuthUserPrincipal)
httpClientContext.getUserToken();
String userPassBase64 = Base64.encodeBase64String((principal.getName()
+ ":" + principal.getPassword()).getBytes(StandardCharsets.UTF_8));
httpRequest.setHeader(HttpHeaders.AUTHORIZATION, "Basic " +
userPassBase64);
return true;
}
}
}
return false;
}
{code}
Anyway, the issue is that the credentials are in the context, but the password
is encrypted, so it is not valid for http requests with the header
"authorization: basic user:pwd" as it expects the _original_ ( unencrypted )
password.
> MetricsHistoryHandler does not work with BasicAuth
> --
>
> Key: SOLR-12860
> URL: https://issues.apache.org/jira/browse/SOLR-12860
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Priority: Critical
>
> I setup a 2 node cluster ( bin/solr start -e cloud -noprompt ) and then
> uploaded the default security.json from
> [http://lucene.apache.org/solr/guide/7_5/basic-authentication-plugin.html] .
>
> I'm seeing errors like these in the logs which would indicate that the
> metrics history handler would not work with basic auth enabled?
> {code:java}
> 2018-10-12 22:06:43.496 WARN (MetricsHistoryHandler-12-thread-1) [ ]
> o.a.s.c.s.i.SolrClientNodeStateProvider could not get tags from node
> 192.168.0.8:7574_solr
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
> from server at http://192.168.0.8:7574/solr: Expected mime type
> application/octet-stream but got text/html.
>
>
> Error 401 require authentication
>
> HTTP ERROR 401
> Problem accessing /solr/admin/metrics. Reason:
> require authentication
>
>
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:607)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$ClientSnitchCtx.invoke(SolrClientNodeStateProvider.java:342)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchReplicaMetrics(SolrClientNodeStateProvider.java:195)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$AutoScalingSnitch.getRemoteInfo(SolrClientNodeStateProvider.java:241)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.common.cloud.rule.ImplicitSnitch.getTags(ImplicitSnitch.java:76)
> ~[solr
[jira] [Updated] (SOLR-13343) Diagnostic Browser Log Spacing issues.
[ https://issues.apache.org/jira/browse/SOLR-13343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eagan updated SOLR-13343: Priority: Trivial (was: Minor) > Diagnostic Browser Log Spacing issues. > -- > > Key: SOLR-13343 > URL: https://issues.apache.org/jira/browse/SOLR-13343 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 7.4, 7.5, 7.6, 7.7.1 >Reporter: Marcus Eagan >Priority: Trivial > > There is a small issue with the browser log for the count of how long Solr > has been alive. It affects all versions since the library was added to Solr. > Here is the pull request: > [https://github.com/apache/lucene-solr/pull/592] -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13343) Diagnostic Browser Log Spacing issues.
Marcus Eagan created SOLR-13343: --- Summary: Diagnostic Browser Log Spacing issues. Key: SOLR-13343 URL: https://issues.apache.org/jira/browse/SOLR-13343 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: Admin UI Affects Versions: 7.7.1, 7.6, 7.5, 7.4 Reporter: Marcus Eagan There is a small issue with the browser log for the count of how long Solr has been alive. It affects all versions since the library was added to Solr. Here is the pull request: [https://github.com/apache/lucene-solr/pull/592] -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13342) Remove dom4j fromj Solr
[ https://issues.apache.org/jira/browse/SOLR-13342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16799318#comment-16799318 ] Kevin Risden commented on SOLR-13342: - I think based on that file, only velocity-tools has a dependency on dom4j and confirmed via https://mvnrepository.com/artifact/org.apache.velocity/velocity-tools/2.0 The dom4j dependency goes away with Velocity upgrade - SOLR-13335 > Remove dom4j fromj Solr > --- > > Key: SOLR-13342 > URL: https://issues.apache.org/jira/browse/SOLR-13342 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > > dom4j is used in exactly one file in Solr, and it's a test: > AddBlockUpdateTest > It seems like overkill to bloat the distro with that jar for one test, can we > change the test to use something else and remove dom4j from our distro? > Assigning to myself to track, but if anyone has the bandwidth, _please_ take > it away ;) > IDK whether there are transitive dependencies though. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13342) Remove dom4j fromj Solr
[ https://issues.apache.org/jira/browse/SOLR-13342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16799317#comment-16799317 ] Erick Erickson commented on SOLR-13342: --- [~krisden]: Thanks for that research. Yeah, I suspect this is just leftover cruft. My plan would be to remove it from Solr, clean my Ivy cache and then see what was downloaded to start. > Remove dom4j fromj Solr > --- > > Key: SOLR-13342 > URL: https://issues.apache.org/jira/browse/SOLR-13342 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > > dom4j is used in exactly one file in Solr, and it's a test: > AddBlockUpdateTest > It seems like overkill to bloat the distro with that jar for one test, can we > change the test to use something else and remove dom4j from our distro? > Assigning to myself to track, but if anyone has the bandwidth, _please_ take > it away ;) > IDK whether there are transitive dependencies though. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13342) Remove dom4j fromj Solr
[ https://issues.apache.org/jira/browse/SOLR-13342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16799312#comment-16799312 ] Kevin Risden commented on SOLR-13342: - Might be able to pull from here: https://repo1.maven.org/maven2/org/apache/lucene/lucene-solr-grandparent/8.0.0/lucene-solr-grandparent-8.0.0.pom Since the exclusions would be where it could come up? > Remove dom4j fromj Solr > --- > > Key: SOLR-13342 > URL: https://issues.apache.org/jira/browse/SOLR-13342 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > > dom4j is used in exactly one file in Solr, and it's a test: > AddBlockUpdateTest > It seems like overkill to bloat the distro with that jar for one test, can we > change the test to use something else and remove dom4j from our distro? > Assigning to myself to track, but if anyone has the bandwidth, _please_ take > it away ;) > IDK whether there are transitive dependencies though. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13340) Typo on download page(s)
[ https://issues.apache.org/jira/browse/SOLR-13340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-13340. --- Resolution: Won't Fix This is actually correct, the title is 0.0 (zero.zero), it's just that the font is a bit odd. Changing this would require us to change the headings for the entire site. Thanks for pointing it out though, we'll note this for any future website revisions. > Typo on download page(s) > > > Key: SOLR-13340 > URL: https://issues.apache.org/jira/browse/SOLR-13340 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Sebb >Assignee: Erick Erickson >Priority: Minor > > The heading at: > [http://lucene.apache.org/solr/downloads.html#solr-800] > looks odd, it looks as though the release is 8.o.o (lower-case O) rather than > 8.0.0 (zero) > It's especially strange as the paragraph below looks fine. > [Tried in Firefox and Safari] > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-8.x-Windows (64bit/jdk-13-ea+12) - Build # 134 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/134/ Java: 64bit/jdk-13-ea+12 -XX:-UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.client.solrj.impl.CloudSolrClientTest Error Message: ObjectTracker found 5 object(s) that were not released!!! [MockDirectoryWrapper, MockDirectoryWrapper, SolrCore, MockDirectoryWrapper, MockDirectoryWrapper] org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.lucene.store.MockDirectoryWrapper at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348) at org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:509) at org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:351) at org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:424) at org.apache.solr.handler.ReplicationHandler.lambda$setupPolling$13(ReplicationHandler.java:1193) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:835) org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.lucene.store.MockDirectoryWrapper at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348) at org.apache.solr.update.SolrIndexWriter.create(SolrIndexWriter.java:99) at org.apache.solr.core.SolrCore.initIndex(SolrCore.java:779) at org.apache.solr.core.SolrCore.(SolrCore.java:976) at org.apache.solr.core.SolrCore.(SolrCore.java:883) at org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1193) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1103) at org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:92) at org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:360) at org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:396) at org.apache.solr.handler.admin.CoreAdminHandler.lambda$handleRequestBody$0(CoreAdminHandler.java:188) at com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:835) org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.solr.core.SolrCore at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.core.SolrCore.(SolrCore.java:1063) at org.apache.solr.core.SolrCore.(SolrCore.java:883) at org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1193) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1103) at org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:92) at org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:360) at org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:396) at org.apache.solr.handler.admin.CoreAdminHandler.lambda$handleRequestBody$0(CoreAdminHandler.java:188) at com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:835) org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.lucene.store.MockDirectoryWrapper at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348) at org.apache.solr.core.SolrCore.initSnapshotMetaDataManager(SolrCore.java:517) at org.apache.solr.core.SolrCore.(SolrCore.java:968) at org.apache.solr.core.SolrCore.(SolrCore.java
[jira] [Commented] (SOLR-13342) Remove dom4j fromj Solr
[ https://issues.apache.org/jira/browse/SOLR-13342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16799292#comment-16799292 ] Kevin Risden commented on SOLR-13342: - jackcess and jackcess-encrypt * Jackcess seems to have moved on from dom4j. Looks like we need to update the licenses. * https://github.com/jahlborn/jackcess/blob/master/LICENSE.txt * https://github.com/jahlborn/jackcessencrypt/blob/master/LICENSE.txt poi, poi-ooxml, poi-ooxml-schemas, and poi-scratchpad * poi, poi-ooxml, poi-ooxml-schemas, and poi-scratchpad all moved on. Might need to update licenses * https://github.com/apache/poi/tree/trunk/legal > Remove dom4j fromj Solr > --- > > Key: SOLR-13342 > URL: https://issues.apache.org/jira/browse/SOLR-13342 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > > dom4j is used in exactly one file in Solr, and it's a test: > AddBlockUpdateTest > It seems like overkill to bloat the distro with that jar for one test, can we > change the test to use something else and remove dom4j from our distro? > Assigning to myself to track, but if anyone has the bandwidth, _please_ take > it away ;) > IDK whether there are transitive dependencies though. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13342) Remove dom4j fromj Solr
[ https://issues.apache.org/jira/browse/SOLR-13342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16799293#comment-16799293 ] Kevin Risden commented on SOLR-13342: - So maybe we don't have any dependency on dom4j anymore. Would need to check. > Remove dom4j fromj Solr > --- > > Key: SOLR-13342 > URL: https://issues.apache.org/jira/browse/SOLR-13342 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > > dom4j is used in exactly one file in Solr, and it's a test: > AddBlockUpdateTest > It seems like overkill to bloat the distro with that jar for one test, can we > change the test to use something else and remove dom4j from our distro? > Assigning to myself to track, but if anyone has the bandwidth, _please_ take > it away ;) > IDK whether there are transitive dependencies though. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13342) Remove dom4j fromj Solr
[
https://issues.apache.org/jira/browse/SOLR-13342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16799290#comment-16799290
]
Kevin Risden commented on SOLR-13342:
-
I would bet its in transitive dependencies based on the following:
{code:java}
git grep dom4j | cat
lucene/ivy-versions.properties:/dom4j/dom4j = 1.6.1
solr/core/ivy.xml:
solr/core/src/test/org/apache/solr/update/AddBlockUpdateTest.java:import
org.dom4j.Document;
solr/core/src/test/org/apache/solr/update/AddBlockUpdateTest.java:import
org.dom4j.DocumentHelper;
solr/core/src/test/org/apache/solr/update/AddBlockUpdateTest.java:import
org.dom4j.Element;
solr/licenses/dom4j-LICENSE-BSD_LIKE.txt: please contact
dom4j-i...@metastuff.com.
solr/licenses/dom4j-LICENSE-BSD_LIKE.txt: http://www.dom4j.org
solr/licenses/jackcess-LICENSE-ASL.txt:DOM4J library (dom4j-1.6.1.jar)
solr/licenses/jackcess-LICENSE-ASL.txt: please contact
dom4j-i...@metastuff.com.
solr/licenses/jackcess-LICENSE-ASL.txt: http://www.dom4j.org
solr/licenses/jackcess-encrypt-LICENSE-ASL.txt:DOM4J library (dom4j-1.6.1.jar)
solr/licenses/jackcess-encrypt-LICENSE-ASL.txt: please contact
dom4j-i...@metastuff.com.
solr/licenses/jackcess-encrypt-LICENSE-ASL.txt: http://www.dom4j.org
solr/licenses/poi-LICENSE-ASL.txt:DOM4J library (dom4j-1.6.1.jar)
solr/licenses/poi-LICENSE-ASL.txt: please contact
dom4j-i...@metastuff.com.
solr/licenses/poi-LICENSE-ASL.txt: http://www.dom4j.org
solr/licenses/poi-NOTICE.txt:This product contains the DOM4J library
(http://www.dom4j.org).
solr/licenses/poi-ooxml-LICENSE-ASL.txt:DOM4J library (dom4j-1.6.1.jar)
solr/licenses/poi-ooxml-LICENSE-ASL.txt: please contact
dom4j-i...@metastuff.com.
solr/licenses/poi-ooxml-LICENSE-ASL.txt: http://www.dom4j.org
solr/licenses/poi-ooxml-NOTICE.txt:This product contains the DOM4J library
(http://www.dom4j.org).
solr/licenses/poi-ooxml-schemas-LICENSE-ASL.txt:DOM4J library (dom4j-1.6.1.jar)
solr/licenses/poi-ooxml-schemas-LICENSE-ASL.txt: please contact
dom4j-i...@metastuff.com.
solr/licenses/poi-ooxml-schemas-LICENSE-ASL.txt: http://www.dom4j.org
solr/licenses/poi-ooxml-schemas-NOTICE.txt:This product contains the DOM4J
library (http://www.dom4j.org).
solr/licenses/poi-scratchpad-LICENSE-ASL.txt:DOM4J library (dom4j-1.6.1.jar)
solr/licenses/poi-scratchpad-LICENSE-ASL.txt: please contact
dom4j-i...@metastuff.com.
solr/licenses/poi-scratchpad-LICENSE-ASL.txt: http://www.dom4j.org
solr/licenses/poi-scratchpad-NOTICE.txt:This product contains the DOM4J library
(http://www.dom4j.org).
{code}
> Remove dom4j fromj Solr
> ---
>
> Key: SOLR-13342
> URL: https://issues.apache.org/jira/browse/SOLR-13342
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> dom4j is used in exactly one file in Solr, and it's a test:
> AddBlockUpdateTest
> It seems like overkill to bloat the distro with that jar for one test, can we
> change the test to use something else and remove dom4j from our distro?
> Assigning to myself to track, but if anyone has the bandwidth, _please_ take
> it away ;)
> IDK whether there are transitive dependencies though.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13342) Remove dom4j fromj Solr
Erick Erickson created SOLR-13342: - Summary: Remove dom4j fromj Solr Key: SOLR-13342 URL: https://issues.apache.org/jira/browse/SOLR-13342 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Erick Erickson Assignee: Erick Erickson dom4j is used in exactly one file in Solr, and it's a test: AddBlockUpdateTest It seems like overkill to bloat the distro with that jar for one test, can we change the test to use something else and remove dom4j from our distro? Assigning to myself to track, but if anyone has the bandwidth, _please_ take it away ;) IDK whether there are transitive dependencies though. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13208) Update dom4j in solr package due to security vulnerability
[ https://issues.apache.org/jira/browse/SOLR-13208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-13208. --- Resolution: Won't Fix > Update dom4j in solr package due to security vulnerability > -- > > Key: SOLR-13208 > URL: https://issues.apache.org/jira/browse/SOLR-13208 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Server >Affects Versions: 7.6, 8.0 >Reporter: DW >Priority: Major > > The Solr package contains dom4j-1.6.1 in the server webapp component in > server/solr-webapp/webapp/WEB-INF/lib/dom4j-1.6.1.jar > Please can you upgrade dom4j-1.6.1 due to open security vulnerability to > 2.1.1+. > If you need the CVE number, let me know. > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13208) Update dom4j in solr package due to security vulnerability
[ https://issues.apache.org/jira/browse/SOLR-13208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16799275#comment-16799275 ] Erick Erickson commented on SOLR-13208: --- This is only used for tests, so a false positive. Given that it's used by exactly one test, though I'll raise a separate Jira about removing it entirely from Solr. > Update dom4j in solr package due to security vulnerability > -- > > Key: SOLR-13208 > URL: https://issues.apache.org/jira/browse/SOLR-13208 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Server >Affects Versions: 7.6, 8.0 >Reporter: DW >Priority: Major > > The Solr package contains dom4j-1.6.1 in the server webapp component in > server/solr-webapp/webapp/WEB-INF/lib/dom4j-1.6.1.jar > Please can you upgrade dom4j-1.6.1 due to open security vulnerability to > 2.1.1+. > If you need the CVE number, let me know. > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13340) Typo on download page(s)
[ https://issues.apache.org/jira/browse/SOLR-13340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16799242#comment-16799242 ] Erick Erickson commented on SOLR-13340: --- I need to learn how to edit the site anyway, so I thought I'd start with this. It turns out that the heading _is_ 0.0 (zero.zero), but apparently the style renders it to look like lower-case 'o'. I agree it does look odd, checking if there's a way to fix... At least when I searched the page for 0.0 it was highlighted... We'll see. > Typo on download page(s) > > > Key: SOLR-13340 > URL: https://issues.apache.org/jira/browse/SOLR-13340 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Sebb >Assignee: Erick Erickson >Priority: Minor > > The heading at: > [http://lucene.apache.org/solr/downloads.html#solr-800] > looks odd, it looks as though the release is 8.o.o (lower-case O) rather than > 8.0.0 (zero) > It's especially strange as the paragraph below looks fine. > [Tried in Firefox and Safari] > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13340) Typo on download page(s)
[ https://issues.apache.org/jira/browse/SOLR-13340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson reassigned SOLR-13340: - Assignee: Erick Erickson > Typo on download page(s) > > > Key: SOLR-13340 > URL: https://issues.apache.org/jira/browse/SOLR-13340 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Sebb >Assignee: Erick Erickson >Priority: Minor > > The heading at: > [http://lucene.apache.org/solr/downloads.html#solr-800] > looks odd, it looks as though the release is 8.o.o (lower-case O) rather than > 8.0.0 (zero) > It's especially strange as the paragraph below looks fine. > [Tried in Firefox and Safari] > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8736) LatLonShapePolygonQuery returning incorrect WITHIN results with shared boundaries
Nicholas Knize created LUCENE-8736:
--
Summary: LatLonShapePolygonQuery returning incorrect WITHIN
results with shared boundaries
Key: LUCENE-8736
URL: https://issues.apache.org/jira/browse/LUCENE-8736
Project: Lucene - Core
Issue Type: Bug
Reporter: Nicholas Knize
Triangles that are {{WITHIN}} a target polygon query that also share a boundary
with the polygon are incorrectly reported as {{CROSSES}} instead of {{INSIDE}}.
This leads to incorrect {{WITHIN}} query results as demonstrated in the
following test:
{code:java}
public void testWithinFailure() throws Exception {
Directory dir = newDirectory();
RandomIndexWriter w = new RandomIndexWriter(random(), dir);
// test polygons:
Polygon indexPoly1 = new Polygon(new double[] {4d, 4d, 3d, 3d, 4d}, new
double[] {3d, 4d, 4d, 3d, 3d});
Polygon indexPoly2 = new Polygon(new double[] {2d, 2d, 1d, 1d, 2d}, new
double[] {6d, 7d, 7d, 6d, 6d});
Polygon indexPoly3 = new Polygon(new double[] {1d, 1d, 0d, 0d, 1d}, new
double[] {3d, 4d, 4d, 3d, 3d});
Polygon indexPoly4 = new Polygon(new double[] {2d, 2d, 1d, 1d, 2d}, new
double[] {0d, 1d, 1d, 0d, 0d});
// index polygons:
Document doc;
addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly1);
w.addDocument(doc);
addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly2);
w.addDocument(doc);
addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly3);
w.addDocument(doc);
addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly4);
w.addDocument(doc);
/ search //
IndexReader reader = w.getReader();
w.close();
IndexSearcher searcher = newSearcher(reader);
Polygon[] searchPoly = new Polygon[] {new Polygon(new double[] {4d, 4d, 0d,
0d, 4d}, new double[] {0d, 7d, 7d, 0d, 0d})};
Query q = LatLonShape.newPolygonQuery(FIELDNAME, QueryRelation.WITHIN,
searchPoly);
assertEquals(4, searcher.count(q));
IOUtils.close(w, reader, dir);
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13341) CloudSolrClient on Solr 7.7.1 does not perform "remove" atomic updates
[ https://issues.apache.org/jira/browse/SOLR-13341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willy Solaligue resolved SOLR-13341. Resolution: Invalid > CloudSolrClient on Solr 7.7.1 does not perform "remove" atomic updates > -- > > Key: SOLR-13341 > URL: https://issues.apache.org/jira/browse/SOLR-13341 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Willy Solaligue >Priority: Blocker > > CloudSolrClient on Solr 7.7.1 does not perform "remove" atomic updates, I > tried with "add", "inc" and "set", and all of them worked fine. "remove" > atomic updates were properly performed when using the update handler. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13341) CloudSolrClient on Solr 7.7.1 does not perform "remove" atomic updates
Willy Solaligue created SOLR-13341: -- Summary: CloudSolrClient on Solr 7.7.1 does not perform "remove" atomic updates Key: SOLR-13341 URL: https://issues.apache.org/jira/browse/SOLR-13341 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Willy Solaligue CloudSolrClient on Solr 7.7.1 does not perform "remove" atomic updates, I tried with "add", "inc" and "set", and all of them worked fine. "remove" atomic updates were properly performed when using the update handler. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8733) retrospectively add @since javadocs for 'intervals' classes
[
https://issues.apache.org/jira/browse/LUCENE-8733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16799218#comment-16799218
]
Jason Gerlowski commented on LUCENE-8733:
-
bq. I don't really like having them on internal classes though, they're an
implementation detail, and users of intervals shouldn't need to know about them
at all.
True, but if the package-private Javadocs aren't published, is this really a
concern? If these internal Javadocs are only exposed to those browsing in an
IDE, users are only going to stumble across them if they've already decided
they want (or need) to look at Lucene's internals. They're going to see the
internals with or without the @since.
Am I missing something here? I don't see anything wrong with adding the tags
if it makes lives easier for some developers, but maybe I just don't understand
the argument against...
> retrospectively add @since javadocs for 'intervals' classes
> ---
>
> Key: LUCENE-8733
> URL: https://issues.apache.org/jira/browse/LUCENE-8733
> Project: Lucene - Core
> Issue Type: Wish
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: LUCENE-8733-branch-7-4.patch
>
>
> LUCENE-8196 started 'intervals' and subsequent tickets extended it.
> This ticket proposes to retrospectively add {{@since X.Y}} javadocs for all
> the classes (and to then going forward perhaps continue to add them).
> And perhaps we could have an 'intervals' or similar JIRA components choice
> too?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8735) FileAlreadyExistsException after opening old commit
Henning Andersen created LUCENE-8735: Summary: FileAlreadyExistsException after opening old commit Key: LUCENE-8735 URL: https://issues.apache.org/jira/browse/LUCENE-8735 Project: Lucene - Core Issue Type: Bug Components: core/store Affects Versions: 8.0 Reporter: Henning Andersen Fix For: master (9.0) FilterDirectory.getPendingDeletes() does not delegate calls. This in turn means that IndexFileDeleter does not consider those as relevant files. When opening an IndexWriter for an older commit, excess files are attempted deleted. If an IndexReader exists using one of the newer commits, the excess files may fail to delete (at least on windows or when using the mocking WindowsFS). If then closing and opening the IndexWriter, the information on the pending deletes are gone if a FilterDirectory derivate is used. At the same time, the pending deletes are filtered out of listAll. This leads to a risk of hitting an existing file name, causing a FileAlreadyExistsException. This issue likely only exists on windows. Will create pull request with fix. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12393) ExpandComponent only calculates the score of expanded docs when sorted by score
[ https://issues.apache.org/jira/browse/SOLR-12393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16799159#comment-16799159 ] Munendra S N commented on SOLR-12393: - [^SOLR-12393.patch] [~dsmiley] I didn't find a way to use ReturnFields.wantsScore() while creating Collector. So, handling at the last step where, documents are collected. Test case passes but I'm not sure if this is right approach. Let me know if there is a better way to handle this Also, refactored some code to throw SolrException when query/filterParsing fails > ExpandComponent only calculates the score of expanded docs when sorted by > score > --- > > Key: SOLR-12393 > URL: https://issues.apache.org/jira/browse/SOLR-12393 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SearchComponents - other >Reporter: David Smiley >Priority: Major > Attachments: SOLR-12393.patch, SOLR-12393.patch > > > If you use the ExpandComponent to show expanded docs and if you want the > score back (specified in "fl"), it will be NaN if the expanded docs are > sorted by anything other than the default score descending. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12393) ExpandComponent only calculates the score of expanded docs when sorted by score
[ https://issues.apache.org/jira/browse/SOLR-12393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Munendra S N updated SOLR-12393: Attachment: SOLR-12393.patch > ExpandComponent only calculates the score of expanded docs when sorted by > score > --- > > Key: SOLR-12393 > URL: https://issues.apache.org/jira/browse/SOLR-12393 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SearchComponents - other >Reporter: David Smiley >Priority: Major > Attachments: SOLR-12393.patch, SOLR-12393.patch > > > If you use the ExpandComponent to show expanded docs and if you want the > score back (specified in "fl"), it will be NaN if the expanded docs are > sorted by anything other than the default score descending. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12532) Slop specified in query string is not preserved for certain phrase searches
[
https://issues.apache.org/jira/browse/SOLR-12532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16799146#comment-16799146
]
Michael Gibney commented on SOLR-12532:
---
+1
This extends the fix from SOLR-12243 (which only applied to slop as set in
{{ps}}) to cover slop specified directly in the query string. It follows the
pattern established for {{(Multi)PhraseQuery}} in
{{ExtendedDismaxQParser.ExtendedSolrQueryParser.getQuery()}} (i.e., re-building
the query using the slop as parsed out of the query string).
> Slop specified in query string is not preserved for certain phrase searches
> ---
>
> Key: SOLR-12532
> URL: https://issues.apache.org/jira/browse/SOLR-12532
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: 7.4
>Reporter: Brad Sumersford
>Priority: Major
> Attachments: SOLR-12532.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Note: This only impacts specific settings for the WordDelimiterGraphFilter as
> detailed below.
> When a phrase search is parsed by the SolrQueryParser, and the phrase search
> results in a graph token stream, the resulting SpanNearQuery created does not
> have the slop correctly set.
> h4. Conditions
> - Slop provided in query string (ex: ~2")
> - WordDelimiterGraphFilterFactory with query time preserveOriginal and
> generateWordParts
> - query string includes a term that contains a word delimiter
> h4. Example
> Field: wdf_partspreserve
> – WordDelimiterGraphFilterFactory
> preserveOriginal="1"
> generateWordParts="1"
> Data: you just can't
> Search: wdf_partspreserve:"you can't"~2 -> 0 Results
> h4. Cause
> The slop supplied by the query string is applied in
> SolrQueryParserBase#getFieldQuery which will set the slop only for
> PhraseQuery and MultiPhaseQuery. Since "can't" will be broken down into
> multiple tokens analyzeGraphPhrase will be triggered when the Query is being
> constructed which will return a SpanNearQuery instead of a (Multi)PhraseQuery.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_172) - Build # 23812 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23812/ Java: 32bit/jdk1.8.0_172 -server -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.cloud.LeaderVoteWaitTimeoutTest.basicTest Error Message: Timeout occurred while waiting response from server at: http://127.0.0.1:32885/solr Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occurred while waiting response from server at: http://127.0.0.1:32885/solr at __randomizedtesting.SeedInfo.seed([FD4E7EDC6B3E896D:FBA69BE2F9B845E]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:660) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) 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:1055) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:830) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:763) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:224) at org.apache.solr.cloud.LeaderVoteWaitTimeoutTest.basicTest(LeaderVoteWaitTimeoutTest.java:155) 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)
[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 312 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/312/ 3 tests failed. FAILED: org.apache.solr.cloud.HttpPartitionTest.test Error Message: Timeout occurred while waiting response from server at: http://127.0.0.1:45704 Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occurred while waiting response from server at: http://127.0.0.1:45704 at __randomizedtesting.SeedInfo.seed([A977909FFAAE1F6A:2123AF4554527292]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:660) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) 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:1055) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:830) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:763) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:224) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:338) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1080) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054) 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.Stateme
[jira] [Commented] (SOLR-12860) MetricsHistoryHandler does not work with BasicAuth
[
https://issues.apache.org/jira/browse/SOLR-12860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16799085#comment-16799085
]
Lorenzo commented on SOLR-12860:
I am checking further... as I am a little lost
{code:java}
public class CoreContainer
...
private void setupHttpClientForAuthPlugin(Object authcPlugin) {
...
// Always register PKI auth interceptor, which will then delegate the
decision of who should secure
// each request to the configured authentication plugin.
if (pkiAuthenticationPlugin != null &&
!pkiAuthenticationPlugin.isInterceptorRegistered()) {
pkiAuthenticationPlugin.getHttpClientBuilder(HttpClientUtil.getHttpClientBuilder());
shardHandlerFactory.setSecurityBuilder(pkiAuthenticationPlugin);
updateShardHandler.setSecurityBuilder(pkiAuthenticationPlugin);
// to force PKI Auth for the Metrics history requests.
}
...{code}
{code:java}
public class PKIAuthenticationPlugin
...
public void setup(Http2SolrClient client) {
final HttpListenerFactory.RequestResponseListener listener = new
HttpListenerFactory.RequestResponseListener() {
@Override
public void onQueued(Request request) {
if (cores.getAuthenticationPlugin() == null) {
return;
}
if (!cores.getAuthenticationPlugin().interceptInternodeRequest(request)) {
log.debug("{} secures this internode request",
this.getClass().getSimpleName());
generateToken().ifPresent(s -> request.header(HEADER, myNodeName + " "
+ s));
} else {
log.debug("{} secures this internode request",
cores.getAuthenticationPlugin().getClass().getSimpleName());
}
}
};
client.addListenerFactory(() -> listener);
}
...{code}
{code:java}
public class BasicAuthPlugin
...
protected boolean interceptInternodeRequest(Request request) {
...{code}
I am a bit lost at the moment because *PKIAuthenticationPlugin* uses
*Http2SolrClient* and the ** class that gets the metrics is
*SolrClientNodeStateProvider* who has a *ClientSnitchCtx* that uses a
*CloudSolrClient.*
Also the interceptor is set only for *onQueued ?*
Should the flow work as Forwarded Credentials?
*// Comments*
What I did to check the HttpClient scope and gave me positive results is
* Make BasicAuthPlugin implement HttpClientBuilderPlugin
* Previous forced me to implement the following where I set the credentials
(only for testing, this is not the solution)
{code:java}
@Override
public SolrHttpClientBuilder getHttpClientBuilder(SolrHttpClientBuilder
builder) {
builder.setDefaultCredentialsProvider(() -> {
...{code}
Whit this setup the *ClientSnitchCtx* has the correct *HttpClient.*
Thanks for any input on this.
> MetricsHistoryHandler does not work with BasicAuth
> --
>
> Key: SOLR-12860
> URL: https://issues.apache.org/jira/browse/SOLR-12860
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Priority: Critical
>
> I setup a 2 node cluster ( bin/solr start -e cloud -noprompt ) and then
> uploaded the default security.json from
> [http://lucene.apache.org/solr/guide/7_5/basic-authentication-plugin.html] .
>
> I'm seeing errors like these in the logs which would indicate that the
> metrics history handler would not work with basic auth enabled?
> {code:java}
> 2018-10-12 22:06:43.496 WARN (MetricsHistoryHandler-12-thread-1) [ ]
> o.a.s.c.s.i.SolrClientNodeStateProvider could not get tags from node
> 192.168.0.8:7574_solr
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
> from server at http://192.168.0.8:7574/solr: Expected mime type
> application/octet-stream but got text/html.
>
>
> Error 401 require authentication
>
> HTTP ERROR 401
> Problem accessing /solr/admin/metrics. Reason:
> require authentication
>
>
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:607)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$ClientSnitchCtx.invoke(SolrClientNodeStateProvider.java:342)
> ~[solr-solrj-7.5.0.jar:
[GitHub] [lucene-solr] dnhatn closed pull request #616: LUCENE-8734: Record nextWriteGens in SegmentCommitInfo
dnhatn closed pull request #616: LUCENE-8734: Record nextWriteGens in SegmentCommitInfo URL: https://github.com/apache/lucene-solr/pull/616 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] dnhatn commented on issue #616: LUCENE-8734: Record nextWriteGens in SegmentCommitInfo
dnhatn commented on issue #616: LUCENE-8734: Record nextWriteGens in SegmentCommitInfo URL: https://github.com/apache/lucene-solr/pull/616#issuecomment-475648971 @s1monw Yeah, the fix from @henningandersen does fix the problem. I am happy to go with that change :). 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
[JENKINS] Lucene-Solr-8.x-Windows (64bit/jdk-11) - Build # 133 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/133/ Java: 64bit/jdk-11 -XX:-UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.response.TestRetrieveFieldsOptimizer Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\build\solr-core\test\J0\temp\solr.response.TestRetrieveFieldsOptimizer_7BB74E9ED7A39743-001\init-core-data-001: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\build\solr-core\test\J0\temp\solr.response.TestRetrieveFieldsOptimizer_7BB74E9ED7A39743-001\init-core-data-001 C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\build\solr-core\test\J0\temp\solr.response.TestRetrieveFieldsOptimizer_7BB74E9ED7A39743-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\build\solr-core\test\J0\temp\solr.response.TestRetrieveFieldsOptimizer_7BB74E9ED7A39743-001 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\build\solr-core\test\J0\temp\solr.response.TestRetrieveFieldsOptimizer_7BB74E9ED7A39743-001\init-core-data-001: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\build\solr-core\test\J0\temp\solr.response.TestRetrieveFieldsOptimizer_7BB74E9ED7A39743-001\init-core-data-001 C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\build\solr-core\test\J0\temp\solr.response.TestRetrieveFieldsOptimizer_7BB74E9ED7A39743-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\build\solr-core\test\J0\temp\solr.response.TestRetrieveFieldsOptimizer_7BB74E9ED7A39743-001 at __randomizedtesting.SeedInfo.seed([7BB74E9ED7A39743]:0) at org.apache.lucene.util.IOUtils.rm(IOUtils.java:318) at org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216) at com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:834) Build Log: [...truncated 13204 lines...] [junit4] Suite: org.apache.solr.response.TestRetrieveFieldsOptimizer [junit4] 2> 632953 INFO (SUITE-TestRetrieveFieldsOptimizer-seed#[7BB74E9ED7A39743]-worker) [] o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom [junit4] 2> Creating dataDir: C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\build\solr-core\test\J0\temp\solr.response.TestRetrieveFieldsOptimizer_7BB74E9ED7A39743-001\init-core-data-001 [junit4] 2> 632954 WARN (SUITE-TestRetrieveFieldsOptimizer-seed#[7BB74E9ED7A39743]-worker) [] o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=1 numCloses=1 [junit4] 2> 632954 INFO (SUITE-TestRetrieveFieldsOptimizer-seed#[7BB74E9ED7A39743]-worker) [] o.a.s.SolrTestCaseJ4 Using TrieFields (NUMERIC_POINTS_SYSPROP=false) w/NUMERIC_DOCVALUES_SYSPROP=false [junit4] 2> 632956 INFO (SUITE-TestRetrieveFieldsOptimizer-seed#[7BB74E9ED7A39743]-worker) [] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: @org.apache.solr.util.RandomizeSSL(reason="", value=0.0/0.0, ssl=0.0/0.0, clientAuth=0.0/0.0) [junit4] 2> 632956 INFO (SUITE-TestRetrieveFieldsOptimizer-seed#[7BB74E9ED7A39743]-worker) [] o.a.s.SolrTestCaseJ4 initCore [junit4] 2> 632960 INFO (SUITE-TestRetrieveFieldsOptimizer-seed#[7BB74E9ED7A39743]-worker) [] o.a.s.c.SolrResourceLoader [null] Added 2 libs to classloader, from paths: [/C:/Users/jenkins/workspace/Lucene-Solr-8.x-Windows/solr/core/src/test-files/solr/collection1/lib, /C:/Users/jenkins/workspace/Lucene-Solr-8.x-Windows/solr/core/src/test-files/solr/collection1/lib/classes] [junit4] 2> 632981 INFO (SUITE-TestRetrieveFieldsOptimizer-seed#[7BB74E9ED7A39743]-worker) [] o.a.s.c.SolrConfig Usin
[GitHub] [lucene-solr] s1monw commented on issue #616: LUCENE-8734: Record nextWriteGens in SegmentCommitInfo
s1monw commented on issue #616: LUCENE-8734: Record nextWriteGens in
SegmentCommitInfo
URL: https://github.com/apache/lucene-solr/pull/616#issuecomment-475646628
@dnhatn actually making this change:
```diff
diff --git
a/lucene/core/src/java/org/apache/lucene/store/FilterDirectory.java
b/lucene/core/src/java/org/apache/lucene/store/FilterDirectory.java
index 7b2a6c702d..c2faaf4d0c 100644
--- a/lucene/core/src/java/org/apache/lucene/store/FilterDirectory.java
+++ b/lucene/core/src/java/org/apache/lucene/store/FilterDirectory.java
@@ -117,6 +117,6 @@ public abstract class FilterDirectory extends Directory {
@Override
public Set getPendingDeletions() throws IOException {
-return super.getPendingDeletions();
+return in.getPendingDeletions();
}
}
```
seems to have fixed the issue since it should take the deleted files into
account. Maybe we should just fix the issue with FilterDirectory
@henningandersen found
[here](https://github.com/elastic/elasticsearch/pull/40345)
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] [Issue Comment Deleted] (SOLR-13331) Atomic Update Multivalue remove does not work
[ https://issues.apache.org/jira/browse/SOLR-13331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Wöckinger updated SOLR-13331: Comment: was deleted (was: Issue SOLR-13255 is related to this) > Atomic Update Multivalue remove does not work > - > > Key: SOLR-13331 > URL: https://issues.apache.org/jira/browse/SOLR-13331 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: UpdateRequestProcessors >Affects Versions: 7.7, 7.7.1, 8.0 > Environment: Standalone Solr Server >Reporter: Thomas Wöckinger >Priority: Critical > > When using JavaBinCodec the values of collections are of type > ByteArrayUtf8CharSequence, existing field values are Strings so the remove > Operation does not have any effect. > The relevant code is located in class AtomicUpdateDocumentMerger method > doRemove. > The method parameter fieldVal contains the collection values of type > ByteArrayUtf8CharSequence, the variable original contains the collection of > Strings -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8732) Allow ConstantScoreQuery to skip counting hits
[
https://issues.apache.org/jira/browse/LUCENE-8732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16798997#comment-16798997
]
Jim Ferenczi commented on LUCENE-8732:
--
{noformat}
Should we keep returning the sub scorer via getChildren()?
{noformat}
I removed it because we build the inner weight with COMPLETE_NO_SCORE so we
shouldn't allow to call score() on the inner scorer ?
> Allow ConstantScoreQuery to skip counting hits
> --
>
> Key: LUCENE-8732
> URL: https://issues.apache.org/jira/browse/LUCENE-8732
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Jim Ferenczi
>Priority: Minor
> Attachments: LUCENE-8732.patch
>
>
> We already have a ConstantScoreScorer that knows how to early terminate the
> collection but the ConstantScoreQuery uses a private scorer that doesn't take
> advantage of setMinCompetitiveScore. This issue is about reusing the
> ConstantScoreScorer in the ConstantScoreQuery in order to early terminate
> queries that don't need to compute the total number of hits.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13331) Atomic Update Multivalue remove does not work
[ https://issues.apache.org/jira/browse/SOLR-13331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16798982#comment-16798982 ] Thomas Wöckinger edited comment on SOLR-13331 at 3/22/19 12:50 PM: --- Issue SOLR-13255 is related to this was (Author: thomas.woeckinger): Issue 13255 is related to this > Atomic Update Multivalue remove does not work > - > > Key: SOLR-13331 > URL: https://issues.apache.org/jira/browse/SOLR-13331 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: UpdateRequestProcessors >Affects Versions: 7.7, 7.7.1, 8.0 > Environment: Standalone Solr Server >Reporter: Thomas Wöckinger >Priority: Critical > > When using JavaBinCodec the values of collections are of type > ByteArrayUtf8CharSequence, existing field values are Strings so the remove > Operation does not have any effect. > The relevant code is located in class AtomicUpdateDocumentMerger method > doRemove. > The method parameter fieldVal contains the collection values of type > ByteArrayUtf8CharSequence, the variable original contains the collection of > Strings -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13331) Atomic Update Multivalue remove does not work
[ https://issues.apache.org/jira/browse/SOLR-13331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16798982#comment-16798982 ] Thomas Wöckinger edited comment on SOLR-13331 at 3/22/19 12:49 PM: --- Issue 13255 is related to this was (Author: thomas.woeckinger): Issue [##13255] is related to this > Atomic Update Multivalue remove does not work > - > > Key: SOLR-13331 > URL: https://issues.apache.org/jira/browse/SOLR-13331 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: UpdateRequestProcessors >Affects Versions: 7.7, 7.7.1, 8.0 > Environment: Standalone Solr Server >Reporter: Thomas Wöckinger >Priority: Critical > > When using JavaBinCodec the values of collections are of type > ByteArrayUtf8CharSequence, existing field values are Strings so the remove > Operation does not have any effect. > The relevant code is located in class AtomicUpdateDocumentMerger method > doRemove. > The method parameter fieldVal contains the collection values of type > ByteArrayUtf8CharSequence, the variable original contains the collection of > Strings -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13331) Atomic Update Multivalue remove does not work
[ https://issues.apache.org/jira/browse/SOLR-13331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16798982#comment-16798982 ] Thomas Wöckinger commented on SOLR-13331: - Issue #13255 is related to this > Atomic Update Multivalue remove does not work > - > > Key: SOLR-13331 > URL: https://issues.apache.org/jira/browse/SOLR-13331 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: UpdateRequestProcessors >Affects Versions: 7.7, 7.7.1, 8.0 > Environment: Standalone Solr Server >Reporter: Thomas Wöckinger >Priority: Critical > > When using JavaBinCodec the values of collections are of type > ByteArrayUtf8CharSequence, existing field values are Strings so the remove > Operation does not have any effect. > The relevant code is located in class AtomicUpdateDocumentMerger method > doRemove. > The method parameter fieldVal contains the collection values of type > ByteArrayUtf8CharSequence, the variable original contains the collection of > Strings -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13331) Atomic Update Multivalue remove does not work
[ https://issues.apache.org/jira/browse/SOLR-13331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16798982#comment-16798982 ] Thomas Wöckinger edited comment on SOLR-13331 at 3/22/19 12:48 PM: --- Issue [##13255] is related to this was (Author: thomas.woeckinger): Issue #13255 is related to this > Atomic Update Multivalue remove does not work > - > > Key: SOLR-13331 > URL: https://issues.apache.org/jira/browse/SOLR-13331 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: UpdateRequestProcessors >Affects Versions: 7.7, 7.7.1, 8.0 > Environment: Standalone Solr Server >Reporter: Thomas Wöckinger >Priority: Critical > > When using JavaBinCodec the values of collections are of type > ByteArrayUtf8CharSequence, existing field values are Strings so the remove > Operation does not have any effect. > The relevant code is located in class AtomicUpdateDocumentMerger method > doRemove. > The method parameter fieldVal contains the collection values of type > ByteArrayUtf8CharSequence, the variable original contains the collection of > Strings -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] s1monw commented on a change in pull request #616: LUCENE-8734: Record nextWriteGens in SegmentCommitInfo
s1monw commented on a change in pull request #616: LUCENE-8734: Record
nextWriteGens in SegmentCommitInfo
URL: https://github.com/apache/lucene-solr/pull/616#discussion_r268151576
##
File path: lucene/core/src/java/org/apache/lucene/index/SegmentCommitInfo.java
##
@@ -91,16 +91,25 @@
* @param docValuesGen
* DocValues generation number (used to name doc-values updates
files)
*/
- public SegmentCommitInfo(SegmentInfo info, int delCount, int softDelCount,
long delGen, long fieldInfosGen, long docValuesGen) {
+ public SegmentCommitInfo(SegmentInfo info, int delCount, int softDelCount,
Review comment:
I think we should use the `setNext*Gen` setters instead of this. We need
them anyway and then we have only one way to set these values. It might also
make sense to assert that the next*Gen is > than the actual gen in these
setters.
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] s1monw commented on a change in pull request #616: LUCENE-8734: Record nextWriteGens in SegmentCommitInfo
s1monw commented on a change in pull request #616: LUCENE-8734: Record nextWriteGens in SegmentCommitInfo URL: https://github.com/apache/lucene-solr/pull/616#discussion_r268152186 ## File path: lucene/core/src/java/org/apache/lucene/index/SegmentInfos.java ## @@ -124,7 +124,10 @@ public static final int VERSION_72 = 8; /** The version that recorded softDelCount */ public static final int VERSION_74 = 9; - static final int VERSION_CURRENT = VERSION_74; + /** The version that recorded nextWriteDocValuesGen */ + public static final int VERSION_77 = 10; Review comment: hmm should this be `VERSION_81` instead? 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] s1monw commented on issue #616: LUCENE-8734: Record nextWriteGens in SegmentCommitInfo
s1monw commented on issue #616: LUCENE-8734: Record nextWriteGens in SegmentCommitInfo URL: https://github.com/apache/lucene-solr/pull/616#issuecomment-475606871 > Do we actually need to record these generations, That was my first reaction too. Yet, it's not enough in the scenario that the test case shows which I think is realistic in order to roll back to an existing commit point. Let me give you an example: ``` iw = new IW(keepAllCommits) iw.addDocument() iw. softUpdateDocument() -> writes _0.dvd iw.commit() iw. softUpdateDocument() -> writes _0_1.dvd iw.commit() iw.close(); iw = new IW() --> IFD updates SegmentCommitInfo to and deletes iw.close(); // now only one commit is available iw = new IW() --> IFD updates SegmentCommitInfo to iw. softUpdateDocument() -> writes _0_1.dvd and crashes since the file already exists. ``` I hope this makes sense? 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-13335) Upgrade to velocity 2.0 and velocity-tools 3.0
[ https://issues.apache.org/jira/browse/SOLR-13335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-13335: Attachment: SOLR-13335.patch > Upgrade to velocity 2.0 and velocity-tools 3.0 > -- > > Key: SOLR-13335 > URL: https://issues.apache.org/jira/browse/SOLR-13335 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: SOLR-13335.patch, SOLR-13335.patch, SOLR-13335.patch, > SOLR-13335.patch, SOLR-13335.patch > > Time Spent: 10m > Remaining Estimate: 0h > > As part of looking to remove old commons-lang in SOLR-9079, found that > velocity depends on it. Upgrading Velocity would allow completely removing > commons-lang > Copy some detail from SOLR-9079 investigation: > * solr/contrib/velocity/ivy.xml doesn't even reference commons-lang > * velocity 1.7 was released - 2010-11-29 > * LUCENE-5249 from 2013 was the last time velocity was changed in > lucene/ivy-versions.properties > * velocity-tools 2.0 has an optional dependency on commons-lang > * velocity 1.7 has a hard dependency on commons-lang. > Upgrading velocity 1.7 -> 2.0 > * http://velocity.apache.org/engine/2.0/upgrading.html > * Change velocity to velocity-engine-core > * upgrades commons-lang to commons-lang3 > So if we want to finish removing commons-lang, we need to upgrade velocity. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13335) Upgrade to velocity 2.0 and velocity-tools 3.0
[ https://issues.apache.org/jira/browse/SOLR-13335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16798930#comment-16798930 ] Kevin Risden commented on SOLR-13335: - Sorry I definitely missed that comment somehow. I'll revert the changes and return the StringReader in the SolrParamResourceLoader case. > Upgrade to velocity 2.0 and velocity-tools 3.0 > -- > > Key: SOLR-13335 > URL: https://issues.apache.org/jira/browse/SOLR-13335 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: SOLR-13335.patch, SOLR-13335.patch, SOLR-13335.patch, > SOLR-13335.patch > > Time Spent: 10m > Remaining Estimate: 0h > > As part of looking to remove old commons-lang in SOLR-9079, found that > velocity depends on it. Upgrading Velocity would allow completely removing > commons-lang > Copy some detail from SOLR-9079 investigation: > * solr/contrib/velocity/ivy.xml doesn't even reference commons-lang > * velocity 1.7 was released - 2010-11-29 > * LUCENE-5249 from 2013 was the last time velocity was changed in > lucene/ivy-versions.properties > * velocity-tools 2.0 has an optional dependency on commons-lang > * velocity 1.7 has a hard dependency on commons-lang. > Upgrading velocity 1.7 -> 2.0 > * http://velocity.apache.org/engine/2.0/upgrading.html > * Change velocity to velocity-engine-core > * upgrades commons-lang to commons-lang3 > So if we want to finish removing commons-lang, we need to upgrade velocity. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13337) TermsComponent sharded and terms.sort=index performance
[ https://issues.apache.org/jira/browse/SOLR-13337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated SOLR-13337: Attachment: SOLR-13337.patch > TermsComponent sharded and terms.sort=index performance > --- > > Key: SOLR-13337 > URL: https://issues.apache.org/jira/browse/SOLR-13337 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SearchComponents - other >Affects Versions: 7.7 > Environment: Linux 64bit debian > 20-node cluster >Reporter: Morten Bøgeskov >Priority: Minor > Attachments: > 0001-SOLR-13337-Avoid-requesting-unneeded-terms-from-shar.patch, > SOLR-13337.patch, SOLR-13337.patch > > > When the TermsComponet distributes across all shards, all (terms.limit=-1) > are returned. > This ought not to be needed when using terms.sort=index. > When using terms.lower=a in small test base (400k entries) it took 8.5-11.5s > to do a > /terms?terms.fl=register&terms.sort=index&terms.lower=a I did not try it on > production data (10x) > I do get the reason for getting all terms when sorting by count, however when > sorting by index, no more than the terms.limit number rows is required from > any shard. Most likely some will get discarded due to presence in more than > one shard. Given no term.min/maxcount (which definetely throws a spanner in > the works). > > I've attached what I think would do the trick. > I haven't actually tested the patch (it compiles, however some other files in > the checkout I have doesn't: ant compile, javac: "error: cannot find symbol") > > Might be somewhat related issue (SOLR-2908). I didn't quite get the more > subtle information in it. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12120) New plugin type AuditLoggerPlugin
[
https://issues.apache.org/jira/browse/SOLR-12120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16798889#comment-16798889
]
Jan Høydahl commented on SOLR-12120:
Pushed some new fixes
* More extensive integration tests, with end-to-end assertion of events from
error, auth etc
* Fixed several bugs and inconsistencies wrt type, status codes etc
* Fixed so that all ERRORs and when exception!=null causes type=ERROR, and
proper statusCode from exception.
> New plugin type AuditLoggerPlugin
> -
>
> Key: SOLR-12120
> URL: https://issues.apache.org/jira/browse/SOLR-12120
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: security
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Time Spent: 3h
> Remaining Estimate: 0h
>
> Solr needs a well defined plugin point to implement audit logging
> functionality, which is independent from whatever {{AuthenticationPlugin}} or
> {{AuthorizationPlugin}} are in use at the time.
> It seems reasonable to introduce a new plugin type {{AuditLoggerPlugin}}. It
> could be configured in solr.xml or it could be a third type of plugin defined
> in {{security.json}}, i.e.
> {code:java}
> {
> "authentication" : { "class" : ... },
> "authorization" : { "class" : ... },
> "auditlogging" : { "class" : "x.y.MyAuditLogger", ... }
> }
> {code}
> We could then instrument SolrDispatchFilter to the audit plugin with an
> AuditEvent at important points such as successful authentication:
> {code:java}
> auditLoggerPlugin.audit(new SolrAuditEvent(EventType.AUTHENTICATED,
> request));
> {code}
> We will mark the impl as {{@lucene.experimental}} in the first release to
> let it settle as people write their own plugin implementations.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] jpountz commented on issue #616: LUCENE-8734: Record nextWriteGens in SegmentCommitInfo
jpountz commented on issue #616: LUCENE-8734: Record nextWriteGens in SegmentCommitInfo URL: https://github.com/apache/lucene-solr/pull/616#issuecomment-475568863 Do we actually need to record these generations, or could we initialize them from existing commits at IndexWriter creation time, similarly to how we carry over generation numbers with `OpenMode.CREATE` (https://github.com/apache/lucene-solr/blob/bca22d58e2d126ec6d349d375d3ea028892104e1/lucene/core/src/java/org/apache/lucene/index/IndexWriter.java#L788-L789), and rely on `IndexFileDeleter` to handle the case that IndexWriter was not closed gracefully? 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
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-11) - Build # 23811 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23811/
Java: 64bit/jdk-11 -XX:-UseCompressedOops -XX:+UseParallelGC
1 tests failed.
FAILED: org.apache.solr.cloud.TestCloudRecovery2.test
Error Message:
Timeout waiting to see state for collection=collection1
:DocCollection(collection1//collections/collection1/state.json/17)={
"pullReplicas":"0", "replicationFactor":"2", "shards":{"shard1":{
"range":"8000-7fff", "state":"active", "replicas":{
"core_node3":{ "core":"collection1_shard1_replica_n1",
"base_url":"http://127.0.0.1:42657/solr";,
"node_name":"127.0.0.1:42657_solr", "state":"down",
"type":"NRT", "force_set_state":"false"}, "core_node4":{
"core":"collection1_shard1_replica_n2",
"base_url":"http://127.0.0.1:42803/solr";,
"node_name":"127.0.0.1:42803_solr", "state":"active",
"type":"NRT", "force_set_state":"false",
"leader":"true", "router":{"name":"compositeId"},
"maxShardsPerNode":"2", "autoAddReplicas":"false", "nrtReplicas":"2",
"tlogReplicas":"0"} Live Nodes: [127.0.0.1:42657_solr, 127.0.0.1:42803_solr]
Last available state:
DocCollection(collection1//collections/collection1/state.json/17)={
"pullReplicas":"0", "replicationFactor":"2", "shards":{"shard1":{
"range":"8000-7fff", "state":"active", "replicas":{
"core_node3":{ "core":"collection1_shard1_replica_n1",
"base_url":"http://127.0.0.1:42657/solr";,
"node_name":"127.0.0.1:42657_solr", "state":"down",
"type":"NRT", "force_set_state":"false"}, "core_node4":{
"core":"collection1_shard1_replica_n2",
"base_url":"http://127.0.0.1:42803/solr";,
"node_name":"127.0.0.1:42803_solr", "state":"active",
"type":"NRT", "force_set_state":"false",
"leader":"true", "router":{"name":"compositeId"},
"maxShardsPerNode":"2", "autoAddReplicas":"false", "nrtReplicas":"2",
"tlogReplicas":"0"}
Stack Trace:
java.lang.AssertionError:
Timeout waiting to see state for collection=collection1
:DocCollection(collection1//collections/collection1/state.json/17)={
"pullReplicas":"0",
"replicationFactor":"2",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{
"core_node3":{
"core":"collection1_shard1_replica_n1",
"base_url":"http://127.0.0.1:42657/solr";,
"node_name":"127.0.0.1:42657_solr",
"state":"down",
"type":"NRT",
"force_set_state":"false"},
"core_node4":{
"core":"collection1_shard1_replica_n2",
"base_url":"http://127.0.0.1:42803/solr";,
"node_name":"127.0.0.1:42803_solr",
"state":"active",
"type":"NRT",
"force_set_state":"false",
"leader":"true",
"router":{"name":"compositeId"},
"maxShardsPerNode":"2",
"autoAddReplicas":"false",
"nrtReplicas":"2",
"tlogReplicas":"0"}
Live Nodes: [127.0.0.1:42657_solr, 127.0.0.1:42803_solr]
Last available state:
DocCollection(collection1//collections/collection1/state.json/17)={
"pullReplicas":"0",
"replicationFactor":"2",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{
"core_node3":{
"core":"collection1_shard1_replica_n1",
"base_url":"http://127.0.0.1:42657/solr";,
"node_name":"127.0.0.1:42657_solr",
"state":"down",
"type":"NRT",
"force_set_state":"false"},
"core_node4":{
"core":"collection1_shard1_replica_n2",
"base_url":"http://127.0.0.1:42803/solr";,
"node_name":"127.0.0.1:42803_solr",
"state":"active",
"type":"NRT",
"force_set_state":"false",
"leader":"true",
"router":{"name":"compositeId"},
"maxShardsPerNode":"2",
"autoAddReplicas":"false",
"nrtReplicas":"2",
"tlogReplicas":"0"}
at
__randomizedtesting.SeedInfo.seed([320F4CE262143866:BA5B7338CCE8559E]:0)
at org.junit.Assert.fail(Assert.java:88)
at
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:310)
at
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:288)
at
org.apache.solr.cloud.TestCloudRecovery2.test(TestCloudRecovery2.java:106)
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:566)
at
com.carrotsearch
[jira] [Commented] (LUCENE-8732) Allow ConstantScoreQuery to skip counting hits
[ https://issues.apache.org/jira/browse/LUCENE-8732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16798867#comment-16798867 ] Adrien Grand commented on LUCENE-8732: -- +1 to the approach. Should we keep returning the sub scorer via getChildren()? > Allow ConstantScoreQuery to skip counting hits > -- > > Key: LUCENE-8732 > URL: https://issues.apache.org/jira/browse/LUCENE-8732 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Jim Ferenczi >Priority: Minor > Attachments: LUCENE-8732.patch > > > We already have a ConstantScoreScorer that knows how to early terminate the > collection but the ConstantScoreQuery uses a private scorer that doesn't take > advantage of setMinCompetitiveScore. This issue is about reusing the > ConstantScoreScorer in the ConstantScoreQuery in order to early terminate > queries that don't need to compute the total number of hits. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13276) Adding Http2 equivalent classes of CloudSolrClient and HttpClusterStateProvider
[
https://issues.apache.org/jira/browse/SOLR-13276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16798857#comment-16798857
]
Cao Manh Dat commented on SOLR-13276:
-
Thanks Hoss, I tried to reproduce the log but even on a Windows machine, it is
hard to reproduce it.
It seems that even SolrCloudTest do see the same failure, attached the log. So
this seems that the failure does not introduced by changes made by this issue.
Through the attached log, I suspect the cause of problem is IndexFetcher is
kicked off when CoreContainer is shutting down, so the core is not be able to
released.
from: {{thetaphi_Lucene-Solr-8.x-Windows_69.log.txt}}
Two nodes are shutting down
{code}
[junit4] 2> 126085 INFO (jetty-closer-1876-thread-3) []
o.a.s.c.CoreContainer Shutting down CoreContainer instance=1698101756
[junit4] 2> 126085 INFO (jetty-closer-1876-thread-3) []
o.a.s.c.ZkController Remove node as live in
ZooKeeper:/live_nodes/127.0.0.1:61571_solr
[junit4] 2> 126085 INFO (jetty-closer-1876-thread-2) []
o.a.s.c.CoreContainer Shutting down CoreContainer instance=1055741610
[junit4] 2> 126085 INFO (jetty-closer-1876-thread-2) []
o.a.s.c.ZkController Remove node as live in
ZooKeeper:/live_nodes/127.0.0.1:61566_solr
{code}
After that, indexFetcher failed to close a core which lead to the leak error.
{code}
[junit4] 2> 151088 ERROR (indexFetcher-1096-thread-1) []
o.a.s.c.CachingDirectoryFactory Error closing
directory:org.apache.solr.common.SolrException: Timeout waiting for all
directory ref counts to be released - gave up waiting on
CachedDir<>
{code}
Therefore I think that SOLR-13336 may be able to solve this failure.
> Adding Http2 equivalent classes of CloudSolrClient and
> HttpClusterStateProvider
>
>
> Key: SOLR-13276
> URL: https://issues.apache.org/jira/browse/SOLR-13276
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: 8.1
>
> Attachments: SOLR-13276.patch, SOLR-13276.patch, SOLR-13276.patch,
> thetaphi-Lucene-Solr-master-Windows-7810.txt,
> thetaphi_Lucene-Solr-8.x-Windows_69.log.txt,
> thetaphi_Lucene-Solr-master-Windows_7754.log.txt
>
>
> Before we can move on and wipe out the usage of apache httpclient inside
> Solr-core. We need to create Http/2 equivalent classes of CloudSolrClient and
> HttpClusterStateProvider
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13276) Adding Http2 equivalent classes of CloudSolrClient and HttpClusterStateProvider
[ https://issues.apache.org/jira/browse/SOLR-13276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cao Manh Dat updated SOLR-13276: Attachment: thetaphi-Lucene-Solr-master-Windows-7810.txt > Adding Http2 equivalent classes of CloudSolrClient and > HttpClusterStateProvider > > > Key: SOLR-13276 > URL: https://issues.apache.org/jira/browse/SOLR-13276 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Cao Manh Dat >Assignee: Cao Manh Dat >Priority: Major > Fix For: 8.1 > > Attachments: SOLR-13276.patch, SOLR-13276.patch, SOLR-13276.patch, > thetaphi-Lucene-Solr-master-Windows-7810.txt, > thetaphi_Lucene-Solr-8.x-Windows_69.log.txt, > thetaphi_Lucene-Solr-master-Windows_7754.log.txt > > > Before we can move on and wipe out the usage of apache httpclient inside > Solr-core. We need to create Http/2 equivalent classes of CloudSolrClient and > HttpClusterStateProvider -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8733) retrospectively add @since javadocs for 'intervals' classes
[
https://issues.apache.org/jira/browse/LUCENE-8733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16798833#comment-16798833
]
Alan Woodward commented on LUCENE-8733:
---
I think it's reasonable to have them on the public API, which in this case is
the Intervals class and its static factory methods, and IntervalQuery itself.
I don't really like having them on internal classes though, as they're an
implementation detail, and users of intervals shouldn't need to know about them
at all.
> retrospectively add @since javadocs for 'intervals' classes
> ---
>
> Key: LUCENE-8733
> URL: https://issues.apache.org/jira/browse/LUCENE-8733
> Project: Lucene - Core
> Issue Type: Wish
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: LUCENE-8733-branch-7-4.patch
>
>
> LUCENE-8196 started 'intervals' and subsequent tickets extended it.
> This ticket proposes to retrospectively add {{@since X.Y}} javadocs for all
> the classes (and to then going forward perhaps continue to add them).
> And perhaps we could have an 'intervals' or similar JIRA components choice
> too?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13335) Upgrade to velocity 2.0 and velocity-tools 3.0
[ https://issues.apache.org/jira/browse/SOLR-13335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16798832#comment-16798832 ] Uwe Schindler commented on SOLR-13335: -- Sorry, as said before: In SolrParamResourceLoader: If something is a String already, there is no reason to convert it to an InputStream and then convert it back to a reader again. Here the enocing supplied by Velocity is to be ignored. Just reurn a StringReader. Actually, in Velocity 1.x it was a hack! For the SolrResourceLoader case all is fine! Great! > Upgrade to velocity 2.0 and velocity-tools 3.0 > -- > > Key: SOLR-13335 > URL: https://issues.apache.org/jira/browse/SOLR-13335 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: SOLR-13335.patch, SOLR-13335.patch, SOLR-13335.patch, > SOLR-13335.patch > > Time Spent: 10m > Remaining Estimate: 0h > > As part of looking to remove old commons-lang in SOLR-9079, found that > velocity depends on it. Upgrading Velocity would allow completely removing > commons-lang > Copy some detail from SOLR-9079 investigation: > * solr/contrib/velocity/ivy.xml doesn't even reference commons-lang > * velocity 1.7 was released - 2010-11-29 > * LUCENE-5249 from 2013 was the last time velocity was changed in > lucene/ivy-versions.properties > * velocity-tools 2.0 has an optional dependency on commons-lang > * velocity 1.7 has a hard dependency on commons-lang. > Upgrading velocity 1.7 -> 2.0 > * http://velocity.apache.org/engine/2.0/upgrading.html > * Change velocity to velocity-engine-core > * upgrades commons-lang to commons-lang3 > So if we want to finish removing commons-lang, we need to upgrade velocity. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-10.0.1) - Build # 7817 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7817/ Java: 64bit/jdk-10.0.1 -XX:-UseCompressedOops -XX:+UseParallelGC 2 tests failed. FAILED: org.apache.solr.update.processor.CategoryRoutedAliasUpdateProcessorTest.testSliceRouting Error Message: Test abandoned because suite timeout was reached. Stack Trace: java.lang.Exception: Test abandoned because suite timeout was reached. at __randomizedtesting.SeedInfo.seed([84F31A3E83CE3F5B]:0) FAILED: junit.framework.TestSuite.org.apache.solr.update.processor.CategoryRoutedAliasUpdateProcessorTest Error Message: Suite timeout exceeded (>= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (>= 720 msec). at __randomizedtesting.SeedInfo.seed([84F31A3E83CE3F5B]:0) Build Log: [...truncated 15146 lines...] [junit4] Suite: org.apache.solr.update.processor.CategoryRoutedAliasUpdateProcessorTest [junit4] 2> Creating dataDir: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.update.processor.CategoryRoutedAliasUpdateProcessorTest_84F31A3E83CE3F5B-001\init-core-data-001 [junit4] 2> 391739 WARN (SUITE-CategoryRoutedAliasUpdateProcessorTest-seed#[84F31A3E83CE3F5B]-worker) [ ] o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=15 numCloses=15 [junit4] 2> 391739 INFO (SUITE-CategoryRoutedAliasUpdateProcessorTest-seed#[84F31A3E83CE3F5B]-worker) [ ] o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true) w/NUMERIC_DOCVALUES_SYSPROP=true [junit4] 2> 391742 INFO (SUITE-CategoryRoutedAliasUpdateProcessorTest-seed#[84F31A3E83CE3F5B]-worker) [ ] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: @org.apache.solr.util.RandomizeSSL(reason="", value=0.0/0.0, ssl=0.0/0.0, clientAuth=0.0/0.0) [junit4] 2> 391742 INFO (SUITE-CategoryRoutedAliasUpdateProcessorTest-seed#[84F31A3E83CE3F5B]-worker) [ ] o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom [junit4] 2> 391744 INFO (TEST-CategoryRoutedAliasUpdateProcessorTest.testSliceRouting-seed#[84F31A3E83CE3F5B]) [] o.a.s.SolrTestCaseJ4 ###Starting testSliceRouting [junit4] 2> 391745 INFO (TEST-CategoryRoutedAliasUpdateProcessorTest.testSliceRouting-seed#[84F31A3E83CE3F5B]) [] o.a.s.c.MiniSolrCloudCluster Starting cluster of 4 servers in C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.update.processor.CategoryRoutedAliasUpdateProcessorTest_84F31A3E83CE3F5B-001\tempDir-001 [junit4] 2> 391746 INFO (TEST-CategoryRoutedAliasUpdateProcessorTest.testSliceRouting-seed#[84F31A3E83CE3F5B]) [] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER [junit4] 2> 391748 INFO (ZkTestServer Run Thread) [] o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0 [junit4] 2> 391748 INFO (ZkTestServer Run Thread) [] o.a.s.c.ZkTestServer Starting server [junit4] 2> 391854 INFO (TEST-CategoryRoutedAliasUpdateProcessorTest.testSliceRouting-seed#[84F31A3E83CE3F5B]) [] o.a.s.c.ZkTestServer start zk server on port:53843 [junit4] 2> 391854 INFO (TEST-CategoryRoutedAliasUpdateProcessorTest.testSliceRouting-seed#[84F31A3E83CE3F5B]) [] o.a.s.c.ZkTestServer parse host and port list: 127.0.0.1:53843 [junit4] 2> 391854 INFO (TEST-CategoryRoutedAliasUpdateProcessorTest.testSliceRouting-seed#[84F31A3E83CE3F5B]) [] o.a.s.c.ZkTestServer connecting to 127.0.0.1 53843 [junit4] 2> 391865 INFO (zkConnectionManagerCallback-2431-thread-1) [ ] o.a.s.c.c.ConnectionManager zkClient has connected [junit4] 2> 391870 INFO (zkConnectionManagerCallback-2433-thread-1) [ ] o.a.s.c.c.ConnectionManager zkClient has connected [junit4] 2> 391893 INFO (zkConnectionManagerCallback-2435-thread-1) [ ] o.a.s.c.c.ConnectionManager zkClient has connected [junit4] 2> 391897 WARN (NIOServerCxn.Factory:0.0.0.0/0.0.0.0:0) [] o.a.z.s.NIOServerCnxn Unable to read additional data from client sessionid 0x1002ba819ca0002, likely client has closed socket [junit4] 2> 391903 WARN (jetty-launcher-2436-thread-1) [] o.e.j.s.AbstractConnector Ignoring deprecated socket close linger time [junit4] 2> 391903 INFO (jetty-launcher-2436-thread-1) [] o.a.s.c.s.e.JettySolrRunner Start Jetty (original configured port=0) [junit4] 2> 391903 INFO (jetty-launcher-2436-thread-1) [] o.a.s.c.s.e.JettySolrRunner Trying to start Jetty on port 0 try number 1 ... [junit4] 2> 391903 INFO (jetty-launcher-2436-thread-1) [] o.e.j.s.Server jetty-9.4.14.v20181114; built: 2018-11-14T21:20:31.478Z; git: c4550056e785fb5665914545889f21dc136ad9e6; jvm 10.0.1+10 [junit4] 2> 391903 INFO (jetty-launcher-2436-thread-1) [] o.e.j.s.session DefaultSessionIdManager workerName=node0 [junit4] 2> 391903 INFO (jetty-launcher-2436-thread-1) [] o.e.j.s.session
