[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 ] Morten Bøgeskov updated SOLR-13337: --- Attachment: (was: 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 > > > 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=index=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] [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 ] Morten Bøgeskov updated SOLR-13337: --- Attachment: (was: 0001-SOLR-13337-Avoid-requesting-unneeded-terms-from-shar.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 > > > 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=index=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] [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 ] Morten Bøgeskov updated SOLR-13337: --- Attachment: SOLR-13337.patch 0001-SOLR-13337-Avoid-requesting-unneeded-terms-from-shar.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 > > > 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=index=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-8346) Upgrade Zookeeper to version 3.5.x
[ https://issues.apache.org/jira/browse/SOLR-8346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16797910#comment-16797910 ] Jan Høydahl commented on SOLR-8346: --- The ZK project is about to release v3.5.5 ([https://lists.apache.org/thread.html/febb768fd0312fd57f71c543ad3d757546f3630b39e2d81c785b3274@%3Cuser.zookeeper.apache.org%3E)] meaning we could move on with this. > Upgrade Zookeeper to version 3.5.x > -- > > Key: SOLR-8346 > URL: https://issues.apache.org/jira/browse/SOLR-8346 > Project: Solr > Issue Type: Task > Components: SolrCloud >Reporter: Jan Høydahl >Priority: Major > Labels: security, zookeeper > Attachments: SOLR_8346.patch > > > Investigate upgrading ZooKeeper to 3.5.x, once released. Primary motivation > for this is SSL support. Currently a 3.5.4-beta is released (2018-05-17). -- 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-NightlyTests-8.x - Build # 50 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/50/ 4 tests failed. FAILED: org.apache.solr.cloud.hdfs.HdfsChaosMonkeyNothingIsSafeTest.test Error Message: There were too many update fails (107 > 100) - we expect it can happen, but shouldn't easily Stack Trace: java.lang.AssertionError: There were too many update fails (107 > 100) - we expect it can happen, but shouldn't easily at __randomizedtesting.SeedInfo.seed([F4603E9F8EF3069D:7C340145200F6B65]:0) at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.assertTrue(Assert.java:41) at org.junit.Assert.assertFalse(Assert.java:64) at org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:252) 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 org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082) 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.StatementAdapter.evaluate(StatementAdapter.java:36) at
Re: [JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_172) - Build # 7812 - Still Unstable!
Ping. Jenkins builds fail on an assertion related to the recent changes in fst off-heap? D. On Thu, Mar 21, 2019 at 6:46 AM Policeman Jenkins Server wrote: > > Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7812/ > Java: 32bit/jdk1.8.0_172 -client -XX:+UseG1GC > > 5 tests failed. > FAILED: > org.apache.lucene.codecs.lucene50.TestBlockPostingsFormat.testFstOffHeap > > Error Message: > > > Stack Trace: > java.lang.AssertionError > at > __randomizedtesting.SeedInfo.seed([4086033C7FFFE0F2:5FC7DE43004D80CC]:0) > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertTrue(Assert.java:52) > at > org.apache.lucene.codecs.lucene50.TestBlockPostingsFormat.testFstOffHeap(TestBlockPostingsFormat.java:90) > 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 > 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 > 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.lucene.codecs.lucene50.TestBlockPostingsFormat.testFstOffHeap > > Error Message: > > > Stack Trace: > java.lang.AssertionError > at > __randomizedtesting.SeedInfo.seed([4086033C7FFFE0F2:5FC7DE43004D80CC]:0) > at org.junit.Assert.fail(Assert.java:86) > at
[jira] [Updated] (SOLR-13281) NullPointerException processing expired documents
[
https://issues.apache.org/jira/browse/SOLR-13281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N updated SOLR-13281:
Attachment: SOLR-13281.patch
> NullPointerException processing expired documents
> -
>
> Key: SOLR-13281
> URL: https://issues.apache.org/jira/browse/SOLR-13281
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: update
>Affects Versions: 7.6, 7.7, 7.7.1
> Environment: OS:
> Linux redhatje2 2.6.32-431.el6.x86_64 #1 SMP Sun Nov 10 22:19:54 EST 2013
> x86_64 x86_64 x86_64 GNU/Linux
>
> JVM:
> java version "1.8.0_131"
> Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
>
>Reporter: Gerald Bonfiglio
>Priority: Critical
> Attachments: SOLR-13281.patch
>
>
> Getting following error in log:
> {code:java}
> 2019-02-28 04:06:34.824 INFO (autoExpireDocs-30-thread-1) [ ]
> o.a.s.u.p.DocExpirationUpdateProcessorFactory Beginning periodic deletion of
> expired docs
> 2019-02-28 04:06:34.848 INFO (autoExpireDocs-30-thread-1) [ ]
> o.a.s.u.DirectUpdateHandler2 start
> commit{_version_=1626684045233487872,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true,prepareCommit=false}
> 2019-02-28 04:06:34.849 INFO (autoExpireDocs-30-thread-1) [ ]
> o.a.s.u.DirectUpdateHandler2 end_commit_flush
> 2019-02-28 04:06:34.849 ERROR (autoExpireDocs-30-thread-1) [ ]
> o.a.s.u.p.DocExpirationUpdateProcessorFactory Runtime error in periodic
> deletion of expired docs: null
> java.lang.NullPointerException: null
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.handleReplicationFactor(DistributedUpdateProcessor.java:992)
> ~[solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 -
> jimczi - 2019-02-04 23:23:46]
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.doFinish(DistributedUpdateProcessor.java:960)
> ~[solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 -
> jimczi - 2019-02-04 23:23:46]
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.finish(DistributedUpdateProcessor.java:2057)
> ~[solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 -
> jimczi - 2019-02-04 23:23:46]
> at
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.finish(LogUpdateProcessorFactory.java:182)
> ~[solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 -
> jimczi - 2019-02-04 23:23:46]
> at
> org.apache.solr.update.processor.DocExpirationUpdateProcessorFactory$DeleteExpiredDocsRunnable.run(DocExpirationUpdateProcessorFactory.java:419)
> [solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 - jimczi
> - 2019-02-04 23:23:46]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [?:1.8.0_131]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [?:1.8.0_131]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [?:1.8.0_131]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [?:1.8.0_131]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [?:1.8.0_131]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [?:1.8.0_131]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_131]
> {code}
> Processing chain definition from solr_config:
> {code:java}
>
>
>43200
>_ttl_
>
>_expire_at_
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-8.x - Build # 78 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/78/ 1 tests failed. FAILED: org.apache.solr.client.solrj.io.stream.MathExpressionTest.testGammaDistribution Error Message: 0.8348931363183273 0.853832318891295 Stack Trace: java.lang.AssertionError: 0.8348931363183273 0.853832318891295 at __randomizedtesting.SeedInfo.seed([A7C8F5386F34F3C1:9AB2DE964C4C59D6]:0) at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.assertTrue(Assert.java:41) at org.apache.solr.client.solrj.io.stream.MathExpressionTest.testGammaDistribution(MathExpressionTest.java:4572) 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 16164 lines...] [junit4] Suite: org.apache.solr.client.solrj.io.stream.MathExpressionTest [junit4] 2> Creating dataDir:
[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=16798067#comment-16798067 ] Kevin Risden commented on SOLR-13335: - Ah yea you are right. I took the previous version which didn't pass encoding and copy/pasted to new version with minor tweaks. Previous version assumed UTF-8. I'll fix this. > 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 > > 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=16798075#comment-16798075 ] Uwe Schindler commented on SOLR-13335: -- Of course for the one reading it from a String using StringReader, the encoding passed must be ignored. But the one (as above) from the ResourceLoader should use the passed encoding. > 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 > > 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-Tests-master - Build # 3221 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3221/ 4 tests failed. FAILED: org.apache.solr.cloud.TestPrepRecovery.testLeaderUnloaded Error Message: Error from server at http://127.0.0.1:36631/solr: ADDREPLICA failed to create replica Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:36631/solr: ADDREPLICA failed to create replica at __randomizedtesting.SeedInfo.seed([CD25E355458B65ED:9E82F0A3B8A78BEF]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:649) 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.TestPrepRecovery.testLeaderUnloaded(TestPrepRecovery.java:84) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java: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
[JENKINS] Lucene-Solr-8.x-Linux (32bit/jdk1.8.0_172) - Build # 288 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/288/ Java: 32bit/jdk1.8.0_172 -client -XX:+UseSerialGC 6 tests failed. FAILED: org.apache.lucene.codecs.lucene50.TestBlockPostingsFormat.testFstOffHeap Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([418BE33A6217D2DD:5ECA3E451DA5B2E3]:0) at org.junit.Assert.fail(Assert.java:86) at org.junit.Assert.assertTrue(Assert.java:41) at org.junit.Assert.assertTrue(Assert.java:52) at org.apache.lucene.codecs.lucene50.TestBlockPostingsFormat.testFstOffHeap(TestBlockPostingsFormat.java:90) 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 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 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.lucene.codecs.lucene50.TestBlockPostingsFormat.testFstOffHeap Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([418BE33A6217D2DD:5ECA3E451DA5B2E3]:0) at org.junit.Assert.fail(Assert.java:86) at org.junit.Assert.assertTrue(Assert.java:41) at org.junit.Assert.assertTrue(Assert.java:52) at org.apache.lucene.codecs.lucene50.TestBlockPostingsFormat.testFstOffHeap(TestBlockPostingsFormat.java:90) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
[JENKINS-EA] Lucene-Solr-master-Windows (64bit/jdk-13-ea+12) - Build # 7813 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7813/ Java: 64bit/jdk-13-ea+12 -XX:-UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.search.TestSearcherReuse Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.search.TestSearcherReuse_8FF5372BFFE01800-001\init-core-data-001: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.search.TestSearcherReuse_8FF5372BFFE01800-001\init-core-data-001 C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.search.TestSearcherReuse_8FF5372BFFE01800-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.search.TestSearcherReuse_8FF5372BFFE01800-001 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.search.TestSearcherReuse_8FF5372BFFE01800-001\init-core-data-001: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.search.TestSearcherReuse_8FF5372BFFE01800-001\init-core-data-001 C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.search.TestSearcherReuse_8FF5372BFFE01800-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.search.TestSearcherReuse_8FF5372BFFE01800-001 at __randomizedtesting.SeedInfo.seed([8FF5372BFFE01800]: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:835) Build Log: [...truncated 12687 lines...] [junit4] Suite: org.apache.solr.search.TestSearcherReuse [junit4] 2> Creating dataDir: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.search.TestSearcherReuse_8FF5372BFFE01800-001\init-core-data-001 [junit4] 2> 87999 WARN (SUITE-TestSearcherReuse-seed#[8FF5372BFFE01800]-worker) [] o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=2 numCloses=2 [junit4] 2> 87999 INFO (SUITE-TestSearcherReuse-seed#[8FF5372BFFE01800]-worker) [] o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true) w/NUMERIC_DOCVALUES_SYSPROP=false [junit4] 2> 88003 INFO (SUITE-TestSearcherReuse-seed#[8FF5372BFFE01800]-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> 88003 INFO (SUITE-TestSearcherReuse-seed#[8FF5372BFFE01800]-worker) [] o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom [junit4] 2> 88018 INFO (SUITE-TestSearcherReuse-seed#[8FF5372BFFE01800]-worker) [] o.a.s.SolrTestCaseJ4 initCore [junit4] 2> 88036 INFO (SUITE-TestSearcherReuse-seed#[8FF5372BFFE01800]-worker) [] o.a.s.c.SolrConfig Using Lucene MatchVersion: 9.0.0 [junit4] 2> 88052 INFO (SUITE-TestSearcherReuse-seed#[8FF5372BFFE01800]-worker) [] o.a.s.s.ManagedIndexSchemaFactory The schema is configured as managed, but managed schema resource managed-schema not found - loading non-managed schema schema-id-and-version-fields-only.xml instead [junit4] 2> 88057 INFO (SUITE-TestSearcherReuse-seed#[8FF5372BFFE01800]-worker) [] o.a.s.s.IndexSchema [null] Schema name=id-and-version-fields-only [junit4] 2> 88060 INFO
[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=16797995#comment-16797995
]
Lucene/Solr QA commented on SOLR-13335:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
16s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 1m 25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 1m 25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check licenses {color} | {color:green}
1m 42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 1m 25s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
26s{color} | {color:green} velocity in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 6m 27s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-13335 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12963199/SOLR-13335.patch |
| Optional Tests | checklicenses validatesourcepatterns ratsources compile
javac unit checkforbiddenapis |
| uname | Linux lucene1-us-west 4.4.0-137-generic #163~14.04.1-Ubuntu SMP Mon
Sep 24 17:14:57 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / 6222abf |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on July 24 2018 |
| Default Java | 1.8.0_191 |
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/346/testReport/ |
| modules | C: lucene solr solr/contrib/velocity U: . |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/346/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> 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
>
> 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-13281) NullPointerException processing expired documents
[
https://issues.apache.org/jira/browse/SOLR-13281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16797936#comment-16797936
]
Munendra S N commented on SOLR-13281:
-
[^SOLR-13281.patch]
[~jbnas] [~cpoerschke]
This was happening because of responseHeader not being initialized. It appeared
only logs as no exception is thrown from DocExpirationUpdateProcessorFactory.
This is due to make sure ScheduledExecutor executes subsequent executions.
Also, this is reason why it wasn't caught in tests but appeared in logs.
With this fix, there won't be any more above exception logs. I don't know how
to validate this through test
> NullPointerException processing expired documents
> -
>
> Key: SOLR-13281
> URL: https://issues.apache.org/jira/browse/SOLR-13281
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: update
>Affects Versions: 7.6, 7.7, 7.7.1
> Environment: OS:
> Linux redhatje2 2.6.32-431.el6.x86_64 #1 SMP Sun Nov 10 22:19:54 EST 2013
> x86_64 x86_64 x86_64 GNU/Linux
>
> JVM:
> java version "1.8.0_131"
> Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
>
>Reporter: Gerald Bonfiglio
>Priority: Critical
> Attachments: SOLR-13281.patch
>
>
> Getting following error in log:
> {code:java}
> 2019-02-28 04:06:34.824 INFO (autoExpireDocs-30-thread-1) [ ]
> o.a.s.u.p.DocExpirationUpdateProcessorFactory Beginning periodic deletion of
> expired docs
> 2019-02-28 04:06:34.848 INFO (autoExpireDocs-30-thread-1) [ ]
> o.a.s.u.DirectUpdateHandler2 start
> commit{_version_=1626684045233487872,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true,prepareCommit=false}
> 2019-02-28 04:06:34.849 INFO (autoExpireDocs-30-thread-1) [ ]
> o.a.s.u.DirectUpdateHandler2 end_commit_flush
> 2019-02-28 04:06:34.849 ERROR (autoExpireDocs-30-thread-1) [ ]
> o.a.s.u.p.DocExpirationUpdateProcessorFactory Runtime error in periodic
> deletion of expired docs: null
> java.lang.NullPointerException: null
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.handleReplicationFactor(DistributedUpdateProcessor.java:992)
> ~[solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 -
> jimczi - 2019-02-04 23:23:46]
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.doFinish(DistributedUpdateProcessor.java:960)
> ~[solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 -
> jimczi - 2019-02-04 23:23:46]
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.finish(DistributedUpdateProcessor.java:2057)
> ~[solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 -
> jimczi - 2019-02-04 23:23:46]
> at
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.finish(LogUpdateProcessorFactory.java:182)
> ~[solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 -
> jimczi - 2019-02-04 23:23:46]
> at
> org.apache.solr.update.processor.DocExpirationUpdateProcessorFactory$DeleteExpiredDocsRunnable.run(DocExpirationUpdateProcessorFactory.java:419)
> [solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 - jimczi
> - 2019-02-04 23:23:46]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [?:1.8.0_131]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [?:1.8.0_131]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [?:1.8.0_131]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [?:1.8.0_131]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [?:1.8.0_131]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [?:1.8.0_131]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_131]
> {code}
> Processing chain definition from solr_config:
> {code:java}
>
>
>43200
>_ttl_
>
>_expire_at_
>
>
> {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] [Comment Edited] (SOLR-13281) NullPointerException processing expired documents
[
https://issues.apache.org/jira/browse/SOLR-13281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16797936#comment-16797936
]
Munendra S N edited comment on SOLR-13281 at 3/21/19 9:32 AM:
--
[^SOLR-13281.patch]
[~jbnas] [~cpoerschke]
This was happening because of responseHeader not being initialized. It appeared
only logs as no exception is thrown from DocExpirationUpdateProcessorFactory.
This is to make sure ScheduledExecutor executes subsequent executions. Also,
this is reason why it wasn't caught in tests but appeared in logs.
With this fix, there won't be any more above exception logs. I don't know how
to validate this through test
was (Author: munendrasn):
[^SOLR-13281.patch]
[~jbnas] [~cpoerschke]
This was happening because of responseHeader not being initialized. It appeared
only logs as no exception is thrown from DocExpirationUpdateProcessorFactory.
This is due to make sure ScheduledExecutor executes subsequent executions.
Also, this is reason why it wasn't caught in tests but appeared in logs.
With this fix, there won't be any more above exception logs. I don't know how
to validate this through test
> NullPointerException processing expired documents
> -
>
> Key: SOLR-13281
> URL: https://issues.apache.org/jira/browse/SOLR-13281
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: update
>Affects Versions: 7.6, 7.7, 7.7.1
> Environment: OS:
> Linux redhatje2 2.6.32-431.el6.x86_64 #1 SMP Sun Nov 10 22:19:54 EST 2013
> x86_64 x86_64 x86_64 GNU/Linux
>
> JVM:
> java version "1.8.0_131"
> Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
>
>Reporter: Gerald Bonfiglio
>Priority: Critical
> Attachments: SOLR-13281.patch
>
>
> Getting following error in log:
> {code:java}
> 2019-02-28 04:06:34.824 INFO (autoExpireDocs-30-thread-1) [ ]
> o.a.s.u.p.DocExpirationUpdateProcessorFactory Beginning periodic deletion of
> expired docs
> 2019-02-28 04:06:34.848 INFO (autoExpireDocs-30-thread-1) [ ]
> o.a.s.u.DirectUpdateHandler2 start
> commit{_version_=1626684045233487872,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true,prepareCommit=false}
> 2019-02-28 04:06:34.849 INFO (autoExpireDocs-30-thread-1) [ ]
> o.a.s.u.DirectUpdateHandler2 end_commit_flush
> 2019-02-28 04:06:34.849 ERROR (autoExpireDocs-30-thread-1) [ ]
> o.a.s.u.p.DocExpirationUpdateProcessorFactory Runtime error in periodic
> deletion of expired docs: null
> java.lang.NullPointerException: null
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.handleReplicationFactor(DistributedUpdateProcessor.java:992)
> ~[solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 -
> jimczi - 2019-02-04 23:23:46]
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.doFinish(DistributedUpdateProcessor.java:960)
> ~[solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 -
> jimczi - 2019-02-04 23:23:46]
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.finish(DistributedUpdateProcessor.java:2057)
> ~[solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 -
> jimczi - 2019-02-04 23:23:46]
> at
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.finish(LogUpdateProcessorFactory.java:182)
> ~[solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 -
> jimczi - 2019-02-04 23:23:46]
> at
> org.apache.solr.update.processor.DocExpirationUpdateProcessorFactory$DeleteExpiredDocsRunnable.run(DocExpirationUpdateProcessorFactory.java:419)
> [solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 - jimczi
> - 2019-02-04 23:23:46]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [?:1.8.0_131]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [?:1.8.0_131]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [?:1.8.0_131]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [?:1.8.0_131]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [?:1.8.0_131]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [?:1.8.0_131]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_131]
> {code}
> Processing chain definition from solr_config:
> {code:java}
>
>
>43200
>_ttl_
>
>_expire_at_
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[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=16797974#comment-16797974 ] Erik Hatcher commented on SOLR-13335: - +1 to upgrading Velocity and removing commons-lang. > 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 > > 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-Linux (64bit/jdk-12) - Build # 23808 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23808/
Java: 64bit/jdk-12 -XX:-UseCompressedOops -XX:+UseSerialGC
1 tests failed.
FAILED: org.apache.solr.handler.TestSolrConfigHandlerCloud.test
Error Message:
Could not get expected value 'A val' for path 'response/params/x/a' full
output: { "responseHeader":{ "status":0, "QTime":0},
"response":{"znodeVersion":-1}}, from server:
http://127.0.0.1:44857/collection1_shard2_replica_n2
Stack Trace:
java.lang.AssertionError: Could not get expected value 'A val' for path
'response/params/x/a' full output: {
"responseHeader":{
"status":0,
"QTime":0},
"response":{"znodeVersion":-1}}, from server:
http://127.0.0.1:44857/collection1_shard2_replica_n2
at
__randomizedtesting.SeedInfo.seed([FCC771680697E8A8:74934EB2A86B8550]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:590)
at
org.apache.solr.handler.TestSolrConfigHandlerCloud.testReqParams(TestSolrConfigHandlerCloud.java:112)
at
org.apache.solr.handler.TestSolrConfigHandlerCloud.test(TestSolrConfigHandlerCloud.java:51)
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
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
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
[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=16798061#comment-16798061
]
Uwe Schindler commented on SOLR-13335:
--
One thing:
{noformat}
+ public Reader getResourceReader(String source, String encoding) throws
ResourceNotFoundException {
try {
- return loader.openResource("velocity/" + template_name);
+ return new InputStreamReader(loader.openResource("velocity/" + source),
StandardCharsets.UTF_8);
} catch (IOException ioe) {
throw new ResourceNotFoundException(ioe);
}
{noformat}
Should this not use the charset as passed in the parameter to
getResourceReader()? This hardcodes to UTF-8, but this looks wrong, at least
because velocity passes a charset as parameter!
> 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
>
> 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
Re: [JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_172) - Build # 7812 - Still Unstable!
I pushed a fix for this, sorry for the noise. test-bug On Thu, Mar 21, 2019 at 9:38 AM Dawid Weiss wrote: > Ping. Jenkins builds fail on an assertion related to the recent > changes in fst off-heap? > > D. > > On Thu, Mar 21, 2019 at 6:46 AM Policeman Jenkins Server > wrote: > > > > Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7812/ > > Java: 32bit/jdk1.8.0_172 -client -XX:+UseG1GC > > > > 5 tests failed. > > FAILED: > org.apache.lucene.codecs.lucene50.TestBlockPostingsFormat.testFstOffHeap > > > > Error Message: > > > > > > Stack Trace: > > java.lang.AssertionError > > at > __randomizedtesting.SeedInfo.seed([4086033C7FFFE0F2:5FC7DE43004D80CC]:0) > > at org.junit.Assert.fail(Assert.java:86) > > at org.junit.Assert.assertTrue(Assert.java:41) > > at org.junit.Assert.assertTrue(Assert.java:52) > > at > org.apache.lucene.codecs.lucene50.TestBlockPostingsFormat.testFstOffHeap(TestBlockPostingsFormat.java:90) > > 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 > 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 > 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.lucene.codecs.lucene50.TestBlockPostingsFormat.testFstOffHeap > > > > Error Message: > > > > >
[jira] [Created] (SOLR-13339) ZkController.preClose() prevent recovery, indexfetcher being kicked off after SolrCores already closed
Cao Manh Dat created SOLR-13339: --- Summary: ZkController.preClose() prevent recovery, indexfetcher being kicked off after SolrCores already closed Key: SOLR-13339 URL: https://issues.apache.org/jira/browse/SOLR-13339 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Cao Manh Dat Assignee: Cao Manh Dat Right now, recovery can be kicked off when SolrCore is already closed or duing closing a SolrCore. It will be more safer to close all event listeners that can kick off recovery or indexfetcher (replicateFromLeader) before we close SolrCores. I think it will fix the problem of SOLR-13276 test failures recently. -- 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=16798141#comment-16798141
]
Kevin Risden commented on SOLR-13335:
-
Velocity UI testing:
{code:java}
./bin/solr start -e techproducts
open http://localhost:8983/solr/techproducts/browse
# Clicked around a bunch
#checked logs for errors
grep -F ERROR ./example/techproducts/logs/solr.log
./example/techproducts/logs/solr-8983-console.log
./bin/solr stop -all
{code}
Here are the errors that occurred with the attached patch.
{code:java}
./example/techproducts/logs/solr.log:2019-03-21 14:23:56.052 ERROR
(qtp776700275-22) [ x:techproducts] o.a.v.rendering Left side
($list.size($request.params.getParams('fq'))) of comparison operation has null
value at VM_global_library.vm[line 36, column 102]
./example/techproducts/logs/solr.log:2019-03-21 14:23:56.049 ERROR
(qtp776700275-22) [ x:techproducts] o.a.v.rendering Left side
($list.size($p)) of comparison operation has null value at
VM_global_library.vm[line 44, column 88]
./example/techproducts/logs/solr.log:2019-03-21 14:23:56.050 ERROR
(qtp776700275-22) [ x:techproducts] o.a.v.rendering Left side
($collations.size()) of comparison operation has null value at
did_you_mean.vm[line 6, column 25]
{code}
For reference here are the errors from Solr 8.0 using the same test.
{code:java}
./example/techproducts/logs/solr.log:2019-03-21 14:32:54.262 ERROR
(qtp572593338-15) [ x:techproducts] o.a.s.r.VelocityResponseWriter Left side
($collations.size()) of '>' operation has null value at did_you_mean.vm[line 6,
column 25]
{code}
So there are 2 new errors. I'll see what it takes to fix all 3 though. Look
like they are of the same flavor.
> 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
>
> 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=16798175#comment-16798175 ] Kevin Risden commented on SOLR-13335: - Thanks for keeping me honest [~thetaphi]. I'll make sure to reread the javadocs and fix the reader. I have been testing the Velocity UI to make sure that "real" templates are loading. > 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 > > 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-13281) NullPointerException processing expired documents
[
https://issues.apache.org/jira/browse/SOLR-13281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16798256#comment-16798256
]
Tomás Fernández Löbbe commented on SOLR-13281:
--
Thanks for the ping [~krisden],and for the patch [~munendrasn], I'll take a look
> NullPointerException processing expired documents
> -
>
> Key: SOLR-13281
> URL: https://issues.apache.org/jira/browse/SOLR-13281
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: update
>Affects Versions: 7.6, 7.7, 7.7.1
> Environment: OS:
> Linux redhatje2 2.6.32-431.el6.x86_64 #1 SMP Sun Nov 10 22:19:54 EST 2013
> x86_64 x86_64 x86_64 GNU/Linux
>
> JVM:
> java version "1.8.0_131"
> Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
>
>Reporter: Gerald Bonfiglio
>Priority: Critical
> Attachments: SOLR-13281.patch
>
>
> Getting following error in log:
> {code:java}
> 2019-02-28 04:06:34.824 INFO (autoExpireDocs-30-thread-1) [ ]
> o.a.s.u.p.DocExpirationUpdateProcessorFactory Beginning periodic deletion of
> expired docs
> 2019-02-28 04:06:34.848 INFO (autoExpireDocs-30-thread-1) [ ]
> o.a.s.u.DirectUpdateHandler2 start
> commit{_version_=1626684045233487872,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true,prepareCommit=false}
> 2019-02-28 04:06:34.849 INFO (autoExpireDocs-30-thread-1) [ ]
> o.a.s.u.DirectUpdateHandler2 end_commit_flush
> 2019-02-28 04:06:34.849 ERROR (autoExpireDocs-30-thread-1) [ ]
> o.a.s.u.p.DocExpirationUpdateProcessorFactory Runtime error in periodic
> deletion of expired docs: null
> java.lang.NullPointerException: null
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.handleReplicationFactor(DistributedUpdateProcessor.java:992)
> ~[solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 -
> jimczi - 2019-02-04 23:23:46]
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.doFinish(DistributedUpdateProcessor.java:960)
> ~[solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 -
> jimczi - 2019-02-04 23:23:46]
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.finish(DistributedUpdateProcessor.java:2057)
> ~[solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 -
> jimczi - 2019-02-04 23:23:46]
> at
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.finish(LogUpdateProcessorFactory.java:182)
> ~[solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 -
> jimczi - 2019-02-04 23:23:46]
> at
> org.apache.solr.update.processor.DocExpirationUpdateProcessorFactory$DeleteExpiredDocsRunnable.run(DocExpirationUpdateProcessorFactory.java:419)
> [solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 - jimczi
> - 2019-02-04 23:23:46]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [?:1.8.0_131]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [?:1.8.0_131]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [?:1.8.0_131]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [?:1.8.0_131]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [?:1.8.0_131]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [?:1.8.0_131]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_131]
> {code}
> Processing chain definition from solr_config:
> {code:java}
>
>
>43200
>_ttl_
>
>_expire_at_
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13281) NullPointerException processing expired documents
[
https://issues.apache.org/jira/browse/SOLR-13281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomás Fernández Löbbe updated SOLR-13281:
-
Fix Version/s: 8.1
7.7.2
> NullPointerException processing expired documents
> -
>
> Key: SOLR-13281
> URL: https://issues.apache.org/jira/browse/SOLR-13281
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: update
>Affects Versions: 7.6, 7.7, 7.7.1
> Environment: OS:
> Linux redhatje2 2.6.32-431.el6.x86_64 #1 SMP Sun Nov 10 22:19:54 EST 2013
> x86_64 x86_64 x86_64 GNU/Linux
>
> JVM:
> java version "1.8.0_131"
> Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
>
>Reporter: Gerald Bonfiglio
>Priority: Critical
> Fix For: 7.7.2, 8.1
>
> Attachments: SOLR-13281.patch
>
>
> Getting following error in log:
> {code:java}
> 2019-02-28 04:06:34.824 INFO (autoExpireDocs-30-thread-1) [ ]
> o.a.s.u.p.DocExpirationUpdateProcessorFactory Beginning periodic deletion of
> expired docs
> 2019-02-28 04:06:34.848 INFO (autoExpireDocs-30-thread-1) [ ]
> o.a.s.u.DirectUpdateHandler2 start
> commit{_version_=1626684045233487872,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true,prepareCommit=false}
> 2019-02-28 04:06:34.849 INFO (autoExpireDocs-30-thread-1) [ ]
> o.a.s.u.DirectUpdateHandler2 end_commit_flush
> 2019-02-28 04:06:34.849 ERROR (autoExpireDocs-30-thread-1) [ ]
> o.a.s.u.p.DocExpirationUpdateProcessorFactory Runtime error in periodic
> deletion of expired docs: null
> java.lang.NullPointerException: null
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.handleReplicationFactor(DistributedUpdateProcessor.java:992)
> ~[solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 -
> jimczi - 2019-02-04 23:23:46]
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.doFinish(DistributedUpdateProcessor.java:960)
> ~[solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 -
> jimczi - 2019-02-04 23:23:46]
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.finish(DistributedUpdateProcessor.java:2057)
> ~[solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 -
> jimczi - 2019-02-04 23:23:46]
> at
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.finish(LogUpdateProcessorFactory.java:182)
> ~[solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 -
> jimczi - 2019-02-04 23:23:46]
> at
> org.apache.solr.update.processor.DocExpirationUpdateProcessorFactory$DeleteExpiredDocsRunnable.run(DocExpirationUpdateProcessorFactory.java:419)
> [solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 - jimczi
> - 2019-02-04 23:23:46]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [?:1.8.0_131]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [?:1.8.0_131]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [?:1.8.0_131]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [?:1.8.0_131]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [?:1.8.0_131]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [?:1.8.0_131]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_131]
> {code}
> Processing chain definition from solr_config:
> {code:java}
>
>
>43200
>_ttl_
>
>_expire_at_
>
>
> {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] [Assigned] (SOLR-13281) NullPointerException processing expired documents
[
https://issues.apache.org/jira/browse/SOLR-13281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomás Fernández Löbbe reassigned SOLR-13281:
Assignee: Tomás Fernández Löbbe
> NullPointerException processing expired documents
> -
>
> Key: SOLR-13281
> URL: https://issues.apache.org/jira/browse/SOLR-13281
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: update
>Affects Versions: 7.6, 7.7, 7.7.1
> Environment: OS:
> Linux redhatje2 2.6.32-431.el6.x86_64 #1 SMP Sun Nov 10 22:19:54 EST 2013
> x86_64 x86_64 x86_64 GNU/Linux
>
> JVM:
> java version "1.8.0_131"
> Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
>
>Reporter: Gerald Bonfiglio
>Assignee: Tomás Fernández Löbbe
>Priority: Critical
> Fix For: 7.7.2, 8.1
>
> Attachments: SOLR-13281.patch
>
>
> Getting following error in log:
> {code:java}
> 2019-02-28 04:06:34.824 INFO (autoExpireDocs-30-thread-1) [ ]
> o.a.s.u.p.DocExpirationUpdateProcessorFactory Beginning periodic deletion of
> expired docs
> 2019-02-28 04:06:34.848 INFO (autoExpireDocs-30-thread-1) [ ]
> o.a.s.u.DirectUpdateHandler2 start
> commit{_version_=1626684045233487872,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true,prepareCommit=false}
> 2019-02-28 04:06:34.849 INFO (autoExpireDocs-30-thread-1) [ ]
> o.a.s.u.DirectUpdateHandler2 end_commit_flush
> 2019-02-28 04:06:34.849 ERROR (autoExpireDocs-30-thread-1) [ ]
> o.a.s.u.p.DocExpirationUpdateProcessorFactory Runtime error in periodic
> deletion of expired docs: null
> java.lang.NullPointerException: null
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.handleReplicationFactor(DistributedUpdateProcessor.java:992)
> ~[solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 -
> jimczi - 2019-02-04 23:23:46]
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.doFinish(DistributedUpdateProcessor.java:960)
> ~[solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 -
> jimczi - 2019-02-04 23:23:46]
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.finish(DistributedUpdateProcessor.java:2057)
> ~[solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 -
> jimczi - 2019-02-04 23:23:46]
> at
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.finish(LogUpdateProcessorFactory.java:182)
> ~[solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 -
> jimczi - 2019-02-04 23:23:46]
> at
> org.apache.solr.update.processor.DocExpirationUpdateProcessorFactory$DeleteExpiredDocsRunnable.run(DocExpirationUpdateProcessorFactory.java:419)
> [solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 - jimczi
> - 2019-02-04 23:23:46]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [?:1.8.0_131]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [?:1.8.0_131]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [?:1.8.0_131]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [?:1.8.0_131]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [?:1.8.0_131]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [?:1.8.0_131]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_131]
> {code}
> Processing chain definition from solr_config:
> {code:java}
>
>
>43200
>_ttl_
>
>_expire_at_
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-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 > > 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=16798124#comment-16798124 ] Kevin Risden commented on SOLR-13335: - Latest patch fixes charset issue brought up by [~thetaphi] and fixes ref guide links to Velocity version. I think this needs one more pass - build, test, check velocity UI but it is getting close. > 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 > > 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] [Comment Edited] (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=16798157#comment-16798157
]
Uwe Schindler edited comment on SOLR-13335 at 3/21/19 2:56 PM:
---
Hi Kevin,
according to Javadocs, you should not build your reader that way. To do it
correctly, the base class of ResoureLoader has a protected method that takes an
input stream and the encoding to build a reader. So actually after you have the
InputStream from our SolrResourceLoader, you should call: {{return
buildReader(reader, encoding);}} (see
[https://velocity.apache.org/engine/2.0/apidocs/org/apache/velocity/runtime/resource/loader/ResourceLoader.html#buildReader-java.io.InputStream-java.lang.String-])
The reason for that is: the parameter {{encoding}} might be {{null}}, and then
it will use the property passed in the Velocity runtime.
A good way to check how a ResourceLoader for velocity should be build is to
read its source code. I had similar problems the last time I touched Velocity.
The test suite is not so helpful, because it uses the special StringReader for
tests to pass in String-templates. In real life, it will load the files from
ResourceLoader, Maybe we should add a real test for this.
was (Author: thetaphi):
Hi Kevin,
according to Javadocs, you should not build your reader that way. To do it
correctly, the base class of ResoureLoader has a protected method that takes an
input stream and the encoding to build a reader. So actually after you have the
InputStream from our SolrResourceLoader, you should call: {{return
buildReader(reader, encoding);}} (see
[https://velocity.apache.org/engine/2.0/apidocs/org/apache/velocity/runtime/resource/loader/ResourceLoader.html#buildReader-java.io.InputStream-java.lang.String-])
> 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
>
> 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=16798157#comment-16798157
]
Uwe Schindler commented on SOLR-13335:
--
Hi Kevin,
according to Javadocs, you should not build your reader that way. To do it
correctly, the base class of ResoureLoader has a protected method that takes an
input stream and the encoding to build a reader. So actually after you have the
InputStream from our SolrResourceLoader, you should call: {{return
buildReader(reader, encoding);}} (see
[https://velocity.apache.org/engine/2.0/apidocs/org/apache/velocity/runtime/resource/loader/ResourceLoader.html#buildReader-java.io.InputStream-java.lang.String-])
> 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
>
> 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-13339) ZkController.preClose() prevent recovery, indexfetcher being kicked off after SolrCores already closed
[ https://issues.apache.org/jira/browse/SOLR-13339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cao Manh Dat updated SOLR-13339: Attachment: SOLR-13339.patch > ZkController.preClose() prevent recovery, indexfetcher being kicked off after > SolrCores already closed > -- > > Key: SOLR-13339 > URL: https://issues.apache.org/jira/browse/SOLR-13339 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Cao Manh Dat >Assignee: Cao Manh Dat >Priority: Major > Attachments: SOLR-13339.patch > > > Right now, recovery can be kicked off when SolrCore is already closed or > duing closing a SolrCore. It will be more safer to close all event listeners > that can kick off recovery or indexfetcher (replicateFromLeader) before we > close SolrCores. > I think it will fix the problem of SOLR-13276 test failures recently. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-8.x-Linux (32bit/jdk1.8.0_172) - Build # 288 - Still Unstable!
I pushed a fix for this, sorry for the noise On Thu, Mar 21, 2019 at 10:27 AM Policeman Jenkins Server < jenk...@thetaphi.de> wrote: > Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/288/ > Java: 32bit/jdk1.8.0_172 -client -XX:+UseSerialGC > > 6 tests failed. > FAILED: > org.apache.lucene.codecs.lucene50.TestBlockPostingsFormat.testFstOffHeap > > Error Message: > > > Stack Trace: > java.lang.AssertionError > at > __randomizedtesting.SeedInfo.seed([418BE33A6217D2DD:5ECA3E451DA5B2E3]:0) > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertTrue(Assert.java:52) > at > org.apache.lucene.codecs.lucene50.TestBlockPostingsFormat.testFstOffHeap(TestBlockPostingsFormat.java:90) > 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 > 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 > 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.lucene.codecs.lucene50.TestBlockPostingsFormat.testFstOffHeap > > Error Message: > > > Stack Trace: > java.lang.AssertionError > at > __randomizedtesting.SeedInfo.seed([418BE33A6217D2DD:5ECA3E451DA5B2E3]:0) > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at
[jira] [Commented] (SOLR-13281) NullPointerException processing expired documents
[
https://issues.apache.org/jira/browse/SOLR-13281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16798120#comment-16798120
]
Kevin Risden commented on SOLR-13281:
-
Looks like this is caused by the changes in SOLR-12767.
Ping [~tomasflobbe] since you committed SOLR-12767
> NullPointerException processing expired documents
> -
>
> Key: SOLR-13281
> URL: https://issues.apache.org/jira/browse/SOLR-13281
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: update
>Affects Versions: 7.6, 7.7, 7.7.1
> Environment: OS:
> Linux redhatje2 2.6.32-431.el6.x86_64 #1 SMP Sun Nov 10 22:19:54 EST 2013
> x86_64 x86_64 x86_64 GNU/Linux
>
> JVM:
> java version "1.8.0_131"
> Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
>
>Reporter: Gerald Bonfiglio
>Priority: Critical
> Attachments: SOLR-13281.patch
>
>
> Getting following error in log:
> {code:java}
> 2019-02-28 04:06:34.824 INFO (autoExpireDocs-30-thread-1) [ ]
> o.a.s.u.p.DocExpirationUpdateProcessorFactory Beginning periodic deletion of
> expired docs
> 2019-02-28 04:06:34.848 INFO (autoExpireDocs-30-thread-1) [ ]
> o.a.s.u.DirectUpdateHandler2 start
> commit{_version_=1626684045233487872,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true,prepareCommit=false}
> 2019-02-28 04:06:34.849 INFO (autoExpireDocs-30-thread-1) [ ]
> o.a.s.u.DirectUpdateHandler2 end_commit_flush
> 2019-02-28 04:06:34.849 ERROR (autoExpireDocs-30-thread-1) [ ]
> o.a.s.u.p.DocExpirationUpdateProcessorFactory Runtime error in periodic
> deletion of expired docs: null
> java.lang.NullPointerException: null
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.handleReplicationFactor(DistributedUpdateProcessor.java:992)
> ~[solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 -
> jimczi - 2019-02-04 23:23:46]
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.doFinish(DistributedUpdateProcessor.java:960)
> ~[solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 -
> jimczi - 2019-02-04 23:23:46]
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.finish(DistributedUpdateProcessor.java:2057)
> ~[solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 -
> jimczi - 2019-02-04 23:23:46]
> at
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.finish(LogUpdateProcessorFactory.java:182)
> ~[solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 -
> jimczi - 2019-02-04 23:23:46]
> at
> org.apache.solr.update.processor.DocExpirationUpdateProcessorFactory$DeleteExpiredDocsRunnable.run(DocExpirationUpdateProcessorFactory.java:419)
> [solr-core-7.7.0.jar:7.7.0 8c831daf4eb41153c25ddb152501ab5bae3ea3d5 - jimczi
> - 2019-02-04 23:23:46]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [?:1.8.0_131]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [?:1.8.0_131]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [?:1.8.0_131]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [?:1.8.0_131]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [?:1.8.0_131]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [?:1.8.0_131]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_131]
> {code}
> Processing chain definition from solr_config:
> {code:java}
>
>
>43200
>_ttl_
>
>_expire_at_
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13340) Typo on download page(s)
Sebb created SOLR-13340: --- Summary: 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 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] [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=16798202#comment-16798202 ] Kevin Risden commented on SOLR-13335: - Latest patch uses buildReader for both SolrParamResourceLoader and SolrVelocityResourceLoader. Fixes the null issues in the Solr templates identified above. Tested and there were no velocity errors in the logs from the Velocity UI. > 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-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 > > 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-13337) TermsComponent sharded and terms.sort=index performance
[
https://issues.apache.org/jira/browse/SOLR-13337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16798223#comment-16798223
]
Lucene/Solr QA commented on SOLR-13337:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 6s{color}
| {color:red} SOLR-13337 does not apply to master. Rebase required? Wrong
Branch? See
https://wiki.apache.org/solr/HowToContribute#Creating_the_patch_file for help.
{color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-13337 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12963221/SOLR-13337.patch |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/347/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> 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
>
>
> 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=index=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-13339) ZkController.preClose() prevent recovery, indexfetcher being kicked off after SolrCores already closed
[
https://issues.apache.org/jira/browse/SOLR-13339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16798152#comment-16798152
]
Cao Manh Dat commented on SOLR-13339:
-
I attached a patch that introduce the {{ZkController.preClose()}} which is
called on start of CC.shutdown() this include
* removeEphemeralLiveNode
* publishNodeAsDown
* ZkCollectionTerms::close
* ReplicateFromLeader::stopReplication
* close electionContexts
> ZkController.preClose() prevent recovery, indexfetcher being kicked off after
> SolrCores already closed
> --
>
> Key: SOLR-13339
> URL: https://issues.apache.org/jira/browse/SOLR-13339
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Attachments: SOLR-13339.patch
>
>
> Right now, recovery can be kicked off when SolrCore is already closed or
> duing closing a SolrCore. It will be more safer to close all event listeners
> that can kick off recovery or indexfetcher (replicateFromLeader) before we
> close SolrCores.
> I think it will fix the problem of SOLR-13276 test failures recently.
--
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-12040) HdfsBasicDistributedZkTest & HdfsBasicDistributedZk2 fail on virtually every jenkins run
[
https://issues.apache.org/jira/browse/SOLR-12040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16798268#comment-16798268
]
Kevin Risden commented on SOLR-12040:
-
Well this definitely doesn't happen on every run anymore. In the last 7 days in
~19 runs there was 1 failure. I do see these tests fail locally periodically.
Will try to figure it out.
> HdfsBasicDistributedZkTest & HdfsBasicDistributedZk2 fail on virtually every
> jenkins run
>
>
> Key: SOLR-12040
> URL: https://issues.apache.org/jira/browse/SOLR-12040
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Hadoop Integration, hdfs, Tests
>Reporter: Hoss Man
>Assignee: Kevin Risden
>Priority: Major
>
> HdfsBasicDistributedZkTest & HdfsBasicDistributedZk2 are thin subclasses of
> BasicDistributedZkTest & BasicDistributedZk2 that just tweak the setup to use
> HDFS, and only run @Nightly.
> These tests are failing virtually every time they are run by jenkins - either
> at a method level, or at a suite level (due to threadleaks, timeouts, etc...)
> yet their non-HDFS superclasss virtually never fail.
> Per the jenkins failure rates reports i've setup, here's the failure rates of
> all tests matching "BasicDistributed" for the past 7days (note that the
> non-HDFS tests aren't even listed, because they haven't failed at all even
> though they are non-nightly and have cumulatively run ~750 times in the past
> 7 days)
> http://fucit.org/solr-jenkins-reports/failure-report.html
> {noformat}
> "Suite?","Class","Method","Rate","Runs","Fails"
> "true","org.apache.solr.cloud.hdfs.HdfsBasicDistributedZk2Test","","53.3","15","8"
> "false","org.apache.solr.cloud.hdfs.HdfsBasicDistributedZk2Test","test","18.75","16","3"
> "true","org.apache.solr.cloud.hdfs.HdfsBasicDistributedZkTest","","46.1538461538462","13","6"
> "false","org.apache.solr.cloud.hdfs.HdfsBasicDistributedZkTest","test","7.69230769230769","13","1"
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8733) retrospectively add @since javadocs for 'intervals' classes
Christine Poerschke created LUCENE-8733:
---
Summary: 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
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] (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=16798295#comment-16798295
]
Adrien Grand commented on LUCENE-8733:
--
Most of the classes whose documentation is updated are package-private, so this
will never show up in javadocs?
> 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] (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=16798299#comment-16798299
]
Christine Poerschke commented on LUCENE-8733:
-
bq. Most of the classes whose documentation is updated are package-private ...
Understood. It seems easier though to just add it for all the classes in the
package rather than consider on each one if it's required or not?
bq. ... so this will never show up in javadocs?
Yes and no. It will not show up in the https://lucene.apache.org/core published
javadocs, yes. However it would still be visible in developers' IDE (perhaps
there's a different way to obtain visibility there too, haven't looked into)
and also it's possible to re-generate more extended javadocs locally e.g. via
{code}
ant javadocs -Djavadoc.access=private
{code}
(something I learnt 'way back when' on LUCENE-6571 ticket).
> 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
[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1798 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1798/
4 tests failed.
FAILED: org.apache.solr.cloud.LeaderVoteWaitTimeoutTest.basicTest
Error Message:
Timeout waiting to see state for collection=basicTest
:DocCollection(basicTest//collections/basicTest/state.json/5)={
"pullReplicas":"0", "replicationFactor":"1", "shards":{"shard1":{
"range":"8000-7fff", "state":"active",
"replicas":{"core_node2":{ "core":"basicTest_shard1_replica_n1",
"base_url":"https://127.0.0.1:45510/solr;,
"node_name":"127.0.0.1:45510_solr", "state":"down",
"type":"NRT", "force_set_state":"false",
"leader":"true", "router":{"name":"compositeId"},
"maxShardsPerNode":"1", "autoAddReplicas":"false", "nrtReplicas":"1",
"tlogReplicas":"0"}
Stack Trace:
java.util.concurrent.TimeoutException: Timeout waiting to see state for
collection=basicTest
:DocCollection(basicTest//collections/basicTest/state.json/5)={
"pullReplicas":"0",
"replicationFactor":"1",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{"core_node2":{
"core":"basicTest_shard1_replica_n1",
"base_url":"https://127.0.0.1:45510/solr;,
"node_name":"127.0.0.1:45510_solr",
"state":"down",
"type":"NRT",
"force_set_state":"false",
"leader":"true",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",
"nrtReplicas":"1",
"tlogReplicas":"0"}
at
__randomizedtesting.SeedInfo.seed([8CDB08CE738CB04:FA39A7EEA39DC637]:0)
at
org.apache.solr.common.cloud.ZkStateReader.waitForState(ZkStateReader.java:1526)
at
org.apache.solr.cloud.LeaderVoteWaitTimeoutTest.basicTest(LeaderVoteWaitTimeoutTest.java:132)
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
[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-9.0.4) - Build # 7814 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7814/ Java: 64bit/jdk-9.0.4 -XX:-UseCompressedOops -XX:+UseParallelGC 4 tests failed. FAILED: org.apache.solr.cloud.BasicDistributedZkTest.test Error Message: Captured an uncaught exception in thread: Thread[id=31261, name=Connection evictor, state=RUNNABLE, group=TGRP-BasicDistributedZkTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=31261, name=Connection evictor, state=RUNNABLE, group=TGRP-BasicDistributedZkTest] at __randomizedtesting.SeedInfo.seed([BED534CD9C0E6086:36810B1732F20D7E]:0) Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded FAILED: org.apache.solr.update.processor.CategoryRoutedAliasUpdateProcessorTest.testMaxCardinality Error Message: Error from server at http://127.0.0.1:51010/solr: no core retrieved for testMaxCardinality Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException: Error from server at http://127.0.0.1:51010/solr: no core retrieved for testMaxCardinality at __randomizedtesting.SeedInfo.seed([BED534CD9C0E6086:CF14D642ED284C00]:0) at org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteExecutionException.create(BaseHttpSolrClient.java:66) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:626) 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.SolrClient.request(SolrClient.java:1274) at org.apache.solr.update.processor.RoutedAliasUpdateProcessorTest.createConfigSet(RoutedAliasUpdateProcessorTest.java:115) at org.apache.solr.update.processor.CategoryRoutedAliasUpdateProcessorTest.testMaxCardinality(CategoryRoutedAliasUpdateProcessorTest.java:300) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java: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
[jira] [Resolved] (LUCENE-8731) mark MultiTermAwareComponent as deprecated (7.x and 7.7 only)
[
https://issues.apache.org/jira/browse/LUCENE-8731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke resolved LUCENE-8731.
-
Resolution: Fixed
> mark MultiTermAwareComponent as deprecated (7.x and 7.7 only)
> -
>
> Key: LUCENE-8731
> URL: https://issues.apache.org/jira/browse/LUCENE-8731
> Project: Lucene - Core
> Issue Type: Wish
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Trivial
> Fix For: 7.7.2
>
> Attachments: LUCENE-8731.patch, LUCENE-8731.patch
>
>
> {{MultiTermAwareComponent}} is one of several hundred classes tagged as
> {{@lucene.experimental}} i.e. it is understood that it might change in
> incompatible ways in the next release. Since in this case it is specifically
> known from LUCENE-8497 that the class is removed in 8.0 onwards I think it
> would be nice to mark it as deprecated, sign-posting readers to replacement
> details. Proposed patch to follow.
--
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-5007) TestRecoveryHdfs seems to be leaking a thread occasionally that ends up failing a completely different test.
[ https://issues.apache.org/jira/browse/SOLR-5007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16798304#comment-16798304 ] Kevin Risden commented on SOLR-5007: Putting some notes here as I looked into this a bit more. Hadoop `FileSystem` vs `FileContext`. `FileContext` seems to be the preferred HDFS interaction tool. but `FileContext` doesn’t have a `close()` method so can’t clean up any usages. In the Solr HDFS stuff, there is a mix of `FileSystem` and `FileContext`. and it is weird from a resource usage as to what should be used. I know all the `FileContext` stuff leaks threads in Solr testing, but moving to `FileSystem` isn’t an option since not all the required methods are on `FileSystem`. I plan to try to follow up with the Hadoop ecosystem about `FileContext` and how to properly clean up. Since right now there is no easy way :( > TestRecoveryHdfs seems to be leaking a thread occasionally that ends up > failing a completely different test. > > > Key: SOLR-5007 > URL: https://issues.apache.org/jira/browse/SOLR-5007 > Project: Solr > Issue Type: Test > Components: Hadoop Integration, hdfs, Tests >Reporter: Mark Miller >Assignee: Kevin Risden >Priority: Major > Attachments: SOLR-5007.patch > > -- 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 (64bit/jdk1.8.0_172) - Build # 23809 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23809/ Java: 64bit/jdk1.8.0_172 -XX:-UseCompressedOops -XX:+UseG1GC 5 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.ShardRoutingTest Error Message: Suite timeout exceeded (>= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (>= 720 msec). at __randomizedtesting.SeedInfo.seed([151DF4100A8705B1]:0) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.ShardRoutingTest Error Message: Captured an uncaught exception in thread: Thread[id=19069, name=Connection evictor, state=RUNNABLE, group=TGRP-ShardRoutingTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=19069, name=Connection evictor, state=RUNNABLE, group=TGRP-ShardRoutingTest] Caused by: java.lang.OutOfMemoryError: Java heap space FAILED: junit.framework.TestSuite.org.apache.solr.cloud.ShardRoutingTest Error Message: Captured an uncaught exception in thread: Thread[id=19051, name=SolrRrdBackendFactory-6820-thread-1, state=RUNNABLE, group=TGRP-ShardRoutingTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=19051, name=SolrRrdBackendFactory-6820-thread-1, state=RUNNABLE, group=TGRP-ShardRoutingTest] Caused by: java.lang.OutOfMemoryError: Java heap space FAILED: junit.framework.TestSuite.org.apache.solr.cloud.ShardRoutingTest Error Message: Captured an uncaught exception in thread: Thread[id=18923, name=Connection evictor, state=RUNNABLE, group=TGRP-ShardRoutingTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=18923, name=Connection evictor, state=RUNNABLE, group=TGRP-ShardRoutingTest] Caused by: java.lang.OutOfMemoryError: Java heap space FAILED: org.apache.solr.cloud.ShardRoutingTest.test 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([151DF4100A8705B1]:0) Build Log: [...truncated 15529 lines...] [junit4] Suite: org.apache.solr.cloud.ShardRoutingTest [junit4] 2> 1211346 INFO (SUITE-ShardRoutingTest-seed#[151DF4100A8705B1]-worker) [] o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom [junit4] 2> Creating dataDir: /home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J0/temp/solr.cloud.ShardRoutingTest_151DF4100A8705B1-001/init-core-data-001 [junit4] 2> 1211346 WARN (SUITE-ShardRoutingTest-seed#[151DF4100A8705B1]-worker) [] o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=2722 numCloses=2722 [junit4] 2> 1211346 INFO (SUITE-ShardRoutingTest-seed#[151DF4100A8705B1]-worker) [] o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true) w/NUMERIC_DOCVALUES_SYSPROP=false [junit4] 2> 1211348 INFO (SUITE-ShardRoutingTest-seed#[151DF4100A8705B1]-worker) [] o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (false) via: @org.apache.solr.util.RandomizeSSL(reason=, value=NaN, ssl=NaN, clientAuth=NaN) [junit4] 2> 1211348 INFO (SUITE-ShardRoutingTest-seed#[151DF4100A8705B1]-worker) [] o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: / [junit4] 2> 1211351 INFO (TEST-ShardRoutingTest.test-seed#[151DF4100A8705B1]) [] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER [junit4] 2> 1211351 INFO (ZkTestServer Run Thread) [] o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0 [junit4] 2> 1211351 INFO (ZkTestServer Run Thread) [] o.a.s.c.ZkTestServer Starting server [junit4] 2> 1211451 INFO (TEST-ShardRoutingTest.test-seed#[151DF4100A8705B1]) [] o.a.s.c.ZkTestServer start zk server on port:36813 [junit4] 2> 1211451 INFO (TEST-ShardRoutingTest.test-seed#[151DF4100A8705B1]) [] o.a.s.c.ZkTestServer parse host and port list: 127.0.0.1:36813 [junit4] 2> 1211451 INFO (TEST-ShardRoutingTest.test-seed#[151DF4100A8705B1]) [] o.a.s.c.ZkTestServer connecting to 127.0.0.1 36813 [junit4] 2> 1211470 INFO (zkConnectionManagerCallback-6430-thread-1) [ ] o.a.s.c.c.ConnectionManager zkClient has connected [junit4] 2> 1211482 INFO (zkConnectionManagerCallback-6432-thread-1) [ ] o.a.s.c.c.ConnectionManager zkClient has connected [junit4] 2> 1211483 INFO (TEST-ShardRoutingTest.test-seed#[151DF4100A8705B1]) [] o.a.s.c.ZkTestServer put /home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/test-files/solr/collection1/conf/solrconfig-tlog.xml to /configs/conf1/solrconfig.xml [junit4] 2> 1211484 INFO (TEST-ShardRoutingTest.test-seed#[151DF4100A8705B1]) [] o.a.s.c.ZkTestServer put
[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=16798329#comment-16798329
]
Christine Poerschke commented on LUCENE-8733:
-
{quote}... curious to better understand your motivation?
{quote}
The use case I guess is to be able to 'browse' (probably more likely in IDE
than via re-generated javadocs) on a 'current' branch of the repo i.e.
currently branch_8x (or possibly master) and to easily see for the brand-new
stuff in sandbox if it was already available in the version of the software
that one is currently running and if not from what version onwards it is
available. Of course the info would also be available in other ways e.g.
CHANGES.txt and JIRA tickets but 'with the code' seems quite helpful
specifically in the sandbox scenario. And I'm _not_ suggesting we move towards
having "@since" tags all over the place or in an automatically enforced way,
it's just here specifically with intervals in the sandbox I would find the
presence of such tags helpful :)
> 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] (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=16798313#comment-16798313
]
Adrien Grand commented on LUCENE-8733:
--
I have mixed feelings. I have never found the "@since" tag very helpful, though
I can understand how some users could find it useful on important APIs, eg.
maybe things like BooleanQuery, FeatureField, LongPoint. However here we are
updating javadocs of package-private classes in the sandbox, so it's unclear to
me to whom it is going to be helpful? I'm not opposed to adding those, but a
bit surprised. I'd be curious to better understand your motivation?
> 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-12860) MetricsHistoryHandler does not work with BasicAuth
[
https://issues.apache.org/jira/browse/SOLR-12860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16798439#comment-16798439
]
Lorenzo commented on SOLR-12860:
Hi [~janhoy], I don't understand what you mean. What I see is PKI and Basic
Auth as different plugins. Metrics History fails now on Basic auth.
I am pretty new to this code, so perhaps I am very mistaken. Please advise me
in other case.
>From what I saw in the method *setupHttpClientForAuthPlugin*
I have to
* build the correct HttpClientBuilderPlugin
* set this new object to updateShardHandler
* set the new object to HttpClientUtil.setHttpClientRequestContextBuilder
Otherwise future usages will not work either as the httpclient would be
outdated.
> 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-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchTagValues(SolrClientNodeStateProvider.java:139)
> ~[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.getNodeValues(SolrClientNodeStateProvider.java:128)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectGlobalMetrics(MetricsHistoryHandler.java:498)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectMetrics(MetricsHistoryHandler.java:371)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.lambda$new$0(MetricsHistoryHandler.java:231)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
>
[jira] [Commented] (SOLR-13322) Enable checking for System.out references in Solr codebase
[
https://issues.apache.org/jira/browse/SOLR-13322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16798446#comment-16798446
]
ASF subversion and git services commented on SOLR-13322:
Commit 62c6e8d5d9f8a490c47947940fc6cc6a8dd6fa26 in lucene-solr's branch
refs/heads/branch_8x from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=62c6e8d ]
SOLR-13322: Properly log exceptions.
> Enable checking for System.out references in Solr codebase
> --
>
> Key: SOLR-13322
> URL: https://issues.apache.org/jira/browse/SOLR-13322
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build
>Affects Versions: master (9.0)
>Reporter: Gus Heck
>Priority: Minor
> Attachments: SOLR-13322.patch, sysout-forbidden.txt
>
>
> This is almost trivial (just delete this line from the solr build.xml):
> {code:java}
> {code}
> What that line is doing is overriding the top level target that does the
> checking and makes it do nothing.
> BUT unfortunately the "almost" of this is that that instantly detects a
> large number of things, many of which are valid usages because they are in
> command line tools that really do want to report information to system out
> (I'll attach the output)
> This leaves us with two possibilities:
> # Add @ SuppressForbidden (though there seem to be two of these)
> # Convert the CLI oriented code to use logging (probably a custom logging
> config for this use case with no leading date stamp etc...)
> In the first case there's the additional question of whether or not we can
> suppress just the one bundle (jdk-system-out) or if we have to suppress all
> forbidden apis checks (which is a worrisome thought).
> Also it's worth noting that a there are a couple of other detections relating
> to eclipse generated try/catch blocks that are triggered by removing the
> above line from the build.
> Conversation on Slack indicates that [~thetaphi] will likely have some
> thoughts on this.
--
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-13322) Enable checking for System.out references in Solr codebase
[
https://issues.apache.org/jira/browse/SOLR-13322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16798444#comment-16798444
]
ASF subversion and git services commented on SOLR-13322:
Commit 863d34bff5ce8449c9bfae35acf1ab5746ace35d in lucene-solr's branch
refs/heads/master from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=863d34b ]
SOLR-13322: Properly log exceptions.
> Enable checking for System.out references in Solr codebase
> --
>
> Key: SOLR-13322
> URL: https://issues.apache.org/jira/browse/SOLR-13322
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build
>Affects Versions: master (9.0)
>Reporter: Gus Heck
>Priority: Minor
> Attachments: SOLR-13322.patch, sysout-forbidden.txt
>
>
> This is almost trivial (just delete this line from the solr build.xml):
> {code:java}
> {code}
> What that line is doing is overriding the top level target that does the
> checking and makes it do nothing.
> BUT unfortunately the "almost" of this is that that instantly detects a
> large number of things, many of which are valid usages because they are in
> command line tools that really do want to report information to system out
> (I'll attach the output)
> This leaves us with two possibilities:
> # Add @ SuppressForbidden (though there seem to be two of these)
> # Convert the CLI oriented code to use logging (probably a custom logging
> config for this use case with no leading date stamp etc...)
> In the first case there's the additional question of whether or not we can
> suppress just the one bundle (jdk-system-out) or if we have to suppress all
> forbidden apis checks (which is a worrisome thought).
> Also it's worth noting that a there are a couple of other detections relating
> to eclipse generated try/catch blocks that are triggered by removing the
> above line from the build.
> Conversation on Slack indicates that [~thetaphi] will likely have some
> thoughts on this.
--
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=16798466#comment-16798466
]
Jan Høydahl commented on SOLR-12860:
PKI is always active and will be used for inter node communications if the
chosen auth is not explicitly configured to handle it. Question is why does not
PKI kick in for the metrics history calls?
> 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-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchTagValues(SolrClientNodeStateProvider.java:139)
> ~[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.getNodeValues(SolrClientNodeStateProvider.java:128)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectGlobalMetrics(MetricsHistoryHandler.java:498)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectMetrics(MetricsHistoryHandler.java:371)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.lambda$new$0(MetricsHistoryHandler.java:231)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [?:1.8.0_112]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [?:1.8.0_112]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [?:1.8.0_112]
> at
>
[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=16798371#comment-16798371
]
Lorenzo commented on SOLR-12860:
BasicAuthPlugin is not implementing HttpClientBuilderPlugin as the others,
therefore when reaching this code
{code:java}
setupHttpClientForAuthPlugin(Object authcPlugin)
{code}
in CoreContainer, the HttpClient is not refreshed and the Object that contains
the client is
updateShardHandler that gets updated with the PKI and this does not contain the
credentials that the authcPlugin does. So, I am working on a patch.
> 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-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchTagValues(SolrClientNodeStateProvider.java:139)
> ~[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.getNodeValues(SolrClientNodeStateProvider.java:128)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectGlobalMetrics(MetricsHistoryHandler.java:498)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectMetrics(MetricsHistoryHandler.java:371)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.lambda$new$0(MetricsHistoryHandler.java:231)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [?:1.8.0_112]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [?:1.8.0_112]
> at
>
[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=16798405#comment-16798405
]
Jan Høydahl commented on SOLR-12860:
A better solution is to force PKI Auth for the Metrics history requests.
> 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-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchTagValues(SolrClientNodeStateProvider.java:139)
> ~[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.getNodeValues(SolrClientNodeStateProvider.java:128)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectGlobalMetrics(MetricsHistoryHandler.java:498)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectMetrics(MetricsHistoryHandler.java:371)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.lambda$new$0(MetricsHistoryHandler.java:231)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [?:1.8.0_112]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [?:1.8.0_112]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [?:1.8.0_112]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [?:1.8.0_112]
> at
>
[JENKINS] Lucene-Solr-8.x-Linux (64bit/jdk-11) - Build # 290 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/290/ Java: 64bit/jdk-11 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitShardWithRuleLink Error Message: Error from server at http://127.0.0.1:35265: Could not find collection : shardSplitWithRule_link Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:35265: Could not find collection : shardSplitWithRule_link at __randomizedtesting.SeedInfo.seed([6CBC4B2E9E3CA036:66A0FEB514A0C693]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:649) 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.api.collections.ShardSplitTest.doSplitShardWithRule(ShardSplitTest.java:661) at org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitShardWithRuleLink(ShardSplitTest.java:633) 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.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 org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082) 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
Re: [JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_172) - Build # 7812 - Still Unstable!
> I pushed a fix for this, sorry for the noise. test-bug That's not noise to me - it's what the CI is for. Thanks Simon. D. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8733) retrospectively add @since javadocs for 'intervals' classes
[
https://issues.apache.org/jira/browse/LUCENE-8733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated LUCENE-8733:
Attachment: LUCENE-8733-branch-7-4.patch
> 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] (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=16798290#comment-16798290
]
Christine Poerschke commented on LUCENE-8733:
-
Attached LUCENE-8733-branch-7-4.patch and would propose to commit that to
branch_7_4 and then from there cherry-pick it 'upwards' to branch_7_5,
branch_7_6, branch_7_7, branch_8_0 and master branches. And then to repeat the
process i.e. LUCENE-8733-branch-7-5.patch (not yet created) would go to
branch_7_5 first and then upwards. How does that sound?
> 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-11126) Node-level health check handler
[ https://issues.apache.org/jira/browse/SOLR-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16798633#comment-16798633 ] ASF subversion and git services commented on SOLR-11126: Commit f220a511b981975a02ebbcef9c559eb9a39f7efb in lucene-solr's branch refs/heads/branch_8x from Shalin Shekhar Mangar [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f220a51 ] SOLR-11126: Move change log entry under 8.0 > Node-level health check handler > --- > > Key: SOLR-11126 > URL: https://issues.apache.org/jira/browse/SOLR-11126 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Anshum Gupta >Assignee: Shalin Shekhar Mangar >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: SOLR-11126-v2.patch, SOLR-11126.patch, SOLR-11126.patch, > SOLR-11126.patch, SOLR-11126.patch, SOLR-11126.patch > > > Solr used to have the PING handler at core level, but with SolrCloud, we are > missing a node level health check handler. It would be good to have. The API > would look like: > * solr/admin/health (v1 API) > * solr/node/health (v2 API) -- 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-11126) Node-level health check handler
[ https://issues.apache.org/jira/browse/SOLR-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16798632#comment-16798632 ] ASF subversion and git services commented on SOLR-11126: Commit bca22d58e2d126ec6d349d375d3ea028892104e1 in lucene-solr's branch refs/heads/master from Shalin Shekhar Mangar [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=bca22d5 ] SOLR-11126: Move change log entry under 8.0 > Node-level health check handler > --- > > Key: SOLR-11126 > URL: https://issues.apache.org/jira/browse/SOLR-11126 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Anshum Gupta >Assignee: Shalin Shekhar Mangar >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: SOLR-11126-v2.patch, SOLR-11126.patch, SOLR-11126.patch, > SOLR-11126.patch, SOLR-11126.patch, SOLR-11126.patch > > > Solr used to have the PING handler at core level, but with SolrCloud, we are > missing a node level health check handler. It would be good to have. The API > would look like: > * solr/admin/health (v1 API) > * solr/node/health (v2 API) -- 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] 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-475475014 @s1monw Can you please have a look? 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 opened a new pull request #616: LUCENE-8734: Record nextWriteGens in SegmentCommitInfo
dnhatn opened a new pull request #616: LUCENE-8734: Record nextWriteGens in SegmentCommitInfo URL: https://github.com/apache/lucene-solr/pull/616 When opening an IndexWriter, we will set nextWriteDelGen, nextWriteFieldInfosGen, and nextWriteDocValuesGen beyond what we have in the directory to avoid double writes in cases where the previous IW was not closed gracefully or the new IW is opened with a previous commit (not the latest commit). We need to persist these values; otherwise, they will be lost when the current IW is closed. 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] [Created] (LUCENE-8734) nextWriteDelGen of SegmentCommitInfo should be persisted
Nhat Nguyen created LUCENE-8734: --- Summary: nextWriteDelGen of SegmentCommitInfo should be persisted Key: LUCENE-8734 URL: https://issues.apache.org/jira/browse/LUCENE-8734 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 8.0, 7.7.1 Reporter: Nhat Nguyen Assignee: Nhat Nguyen When opening an IndexWriter, we will set nextWriteDelGen, nextWriteFieldInfosGen, and nextWriteDocValuesGen beyond what we have in the directory to avoid double writes in cases where the previous IW was not closed gracefully or the new IW is opened with a previous commit (not the latest commit). We need to persist these values; otherwise, they will be lost when the current IW is closed. -- 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-11126) Node-level health check handler
[ https://issues.apache.org/jira/browse/SOLR-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16798630#comment-16798630 ] Shalin Shekhar Mangar commented on SOLR-11126: -- This issue was only committed for 8.0 but I mentioned it in version 7.7. I'll fix that and then resolve it. > Node-level health check handler > --- > > Key: SOLR-11126 > URL: https://issues.apache.org/jira/browse/SOLR-11126 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Anshum Gupta >Assignee: Shalin Shekhar Mangar >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: SOLR-11126-v2.patch, SOLR-11126.patch, SOLR-11126.patch, > SOLR-11126.patch, SOLR-11126.patch, SOLR-11126.patch > > > Solr used to have the PING handler at core level, but with SolrCloud, we are > missing a node level health check handler. It would be good to have. The API > would look like: > * solr/admin/health (v1 API) > * solr/node/health (v2 API) -- 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-11126) Node-level health check handler
[ https://issues.apache.org/jira/browse/SOLR-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16798634#comment-16798634 ] ASF subversion and git services commented on SOLR-11126: Commit 91778c5de8768ca1648e9dc00c47cc75b36cd339 in lucene-solr's branch refs/heads/branch_8_0 from Shalin Shekhar Mangar [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=91778c5 ] SOLR-11126: Move change log entry under 8.0 > Node-level health check handler > --- > > Key: SOLR-11126 > URL: https://issues.apache.org/jira/browse/SOLR-11126 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Anshum Gupta >Assignee: Shalin Shekhar Mangar >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: SOLR-11126-v2.patch, SOLR-11126.patch, SOLR-11126.patch, > SOLR-11126.patch, SOLR-11126.patch, SOLR-11126.patch > > > Solr used to have the PING handler at core level, but with SolrCloud, we are > missing a node level health check handler. It would be good to have. The API > would look like: > * solr/admin/health (v1 API) > * solr/node/health (v2 API) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8734) nextWriteDelGen of SegmentCommitInfo should be persisted
[ https://issues.apache.org/jira/browse/LUCENE-8734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nhat Nguyen updated LUCENE-8734: Labels: pull-request-available (was: ) > nextWriteDelGen of SegmentCommitInfo should be persisted > > > Key: LUCENE-8734 > URL: https://issues.apache.org/jira/browse/LUCENE-8734 > Project: Lucene - Core > Issue Type: Bug > Components: core/index >Affects Versions: 7.7.1, 8.0 >Reporter: Nhat Nguyen >Assignee: Nhat Nguyen >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > When opening an IndexWriter, we will set nextWriteDelGen, > nextWriteFieldInfosGen, and nextWriteDocValuesGen beyond what we have in the > directory to avoid double writes in cases where the previous IW was not > closed gracefully or the new IW is opened with a previous commit (not the > latest commit). We need to persist these values; otherwise, they will be lost > when the current IW is closed. -- 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-13306) Add a request parameter to execute a streaming expression locally
[ https://issues.apache.org/jira/browse/SOLR-13306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16798535#comment-16798535 ] Gus Heck commented on SOLR-13306: - Just used the attached patch to join/denormalize 5146620 documents to 1377364 other documents in 45 seconds, which is about 4-5x as fast as without it, so I'm feeling pretty good about it now. Will likely commit this weekend. > Add a request parameter to execute a streaming expression locally > - > > Key: SOLR-13306 > URL: https://issues.apache.org/jira/browse/SOLR-13306 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: streaming expressions >Affects Versions: 8.0 >Reporter: Gus Heck >Assignee: Gus Heck >Priority: Minor > Attachments: SOLR-13306.patch > > > In some cases it is known (due to routing configuration) that all documents > required for a streaming expression are co-located on the same server. In > this case it is inefficient to send JSON over the wire, and it would be more > efficient to issue the same expression to N servers, thereby saving transport > and merge costs. Details, Patch and example to follow -- 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-10105) JDBCStream should be able to load driver from runtime lib
[ https://issues.apache.org/jira/browse/SOLR-10105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden reassigned SOLR-10105: --- Assignee: (was: Kevin Risden) > JDBCStream should be able to load driver from runtime lib > - > > Key: SOLR-10105 > URL: https://issues.apache.org/jira/browse/SOLR-10105 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Parallel SQL >Reporter: Noble Paul >Priority: Minor > Attachments: SOLR-10105.patch > > > Currently the JDBCStream uses Class.forName() to load the driver class. This > should be improved to try to use the classloader from runtimeLib and the blob > store API like SOLR-10087. It may be possible to do something like > Class.forName(driverClassName, true, core.getMemClassLoader()) just need to > figure out how to get a reference to the core. > The relevant code is here: > https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/JDBCStream.java#L180 -- 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-9963) Add Apache Calcite Avatica handler to Solr
[
https://issues.apache.org/jira/browse/SOLR-9963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16798562#comment-16798562
]
Kevin Risden commented on SOLR-9963:
Switched this over to SolrCloudTestCase and found an interesting error that
reproduces. I haven't tracked down why yet but it has something to do with
multiple shards/replicas on the same node.
{code:java}
NOTE: reproduce with: ant test -Dtestcase=TestAvaticaHandler
-Dtests.method=doTest -Dtests.seed=EADB93F28F2F3CA7 -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=ar-QA -Dtests.timezone=HST
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
AvaticaClientRuntimeException: Remote driver error: RuntimeException:
Connection already exists: bb2eefbb-9f71-4594-894e-5265dd1b72b8
. Error -1 (0) UNKNOWN
java.lang.RuntimeException: Connection already exists:
bb2eefbb-9f71-4594-894e-5265dd1b72b8
at org.apache.calcite.avatica.jdbc.JdbcMeta.openConnection(JdbcMeta.java:621)
at org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:285)
at
org.apache.calcite.avatica.remote.Service$OpenConnectionRequest.accept(Service.java:1770)
at
org.apache.calcite.avatica.remote.Service$OpenConnectionRequest.accept(Service.java:1750)
at
org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:94)
at org.apache.calcite.avatica.remote.JsonHandler.apply(JsonHandler.java:52)
at
org.apache.solr.handler.AvaticaHandler.handleRequestBody(AvaticaHandler.java:76)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2566)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516)
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.HttpConnection.onFillable(HttpConnection.java:260)
at
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)
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)
{code}
> Add Apache Calcite Avatica handler to Solr
> --
>
> Key: SOLR-9963
> URL: https://issues.apache.org/jira/browse/SOLR-9963
> Project: Solr
> Issue Type: Improvement
> Components: Parallel SQL
>Reporter: Kevin Risden
>Assignee: Kevin Risden
>Priority: Major
> Attachments: SOLR-9963.patch, SOLR-9963.patch, SOLR-9963.patch,
> SOLR-9963.patch, test_avatica_solr.sh
>
>
> Apache Calcite Avatica has an http endpoint which allows Avatica drivers to
> connect to the server. This can be wired in as a handler to Solr. This would
> allow Solr to be used by any Avatica JDBC/ODBC driver. This depends on the
> Calcite work from SOLR-8593.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail:
[jira] [Assigned] (SOLR-9779) Streaming Expressions should have better support for basic auth
[
https://issues.apache.org/jira/browse/SOLR-9779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden reassigned SOLR-9779:
--
Assignee: (was: Kevin Risden)
> Streaming Expressions should have better support for basic auth
>
>
> Key: SOLR-9779
> URL: https://issues.apache.org/jira/browse/SOLR-9779
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: clients - java, security
>Affects Versions: 6.0
>Reporter: Sandeep Mukherjee
>Priority: Major
> Labels: features, security
>
> I'm creating a StreamFactory object like the following code:
> {code}
> new StreamFactory().withDefaultZkHost(solrConfig.getConnectString())
> .withFunctionName("gatherNodes", GatherNodesStream.class);
> {code}
> However once I create the StreamFactory there is no way provided to set the
> CloudSolrClient object which can be used to set Basic Auth headers.
> In StreamContext object there is a way to set the SolrClientCache object
> which keep reference to all the CloudSolrClient where I can set a reference
> to HttpClient which sets the Basic Auth header. However the problem is,
> inside the SolrClientCache there is no way to set your own version of
> CloudSolrClient with BasicAuth enabled.
> I think we should expose method in StreamContext where I can specify
> basic-auth enabled CloudSolrClient to use.
--
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-repro - Build # 3056 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/3056/ [...truncated 39 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-Tests-master/3221/consoleText [repro] Revision: 6222abf4480ee15bad2e67942263f563ce5ee434 [repro] Repro line: ant test -Dtestcase=TestPrepRecovery -Dtests.method=testLeaderUnloaded -Dtests.seed=CD25E355458B65ED -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=vi -Dtests.timezone=Europe/Dublin -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] Repro line: ant test -Dtestcase=AutoscalingHistoryHandlerTest -Dtests.seed=CD25E355458B65ED -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=es-PR -Dtests.timezone=Etc/GMT-10 -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] Repro line: ant test -Dtestcase=TestCollectionStateWatchers -Dtests.method=testWatchesWorkForStateFormat1 -Dtests.seed=5CAF3ABB13212935 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=de-CH -Dtests.timezone=US/Aleutian -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] git rev-parse --abbrev-ref HEAD [repro] git rev-parse HEAD [repro] Initial local git branch/revision: 863d34bff5ce8449c9bfae35acf1ab5746ace35d [repro] git fetch [repro] git checkout 6222abf4480ee15bad2e67942263f563ce5ee434 [...truncated 2 lines...] [repro] git merge --ff-only [...truncated 1 lines...] [repro] ant clean [...truncated 6 lines...] [repro] Test suites by module: [repro]solr/solrj [repro] TestCollectionStateWatchers [repro]solr/core [repro] AutoscalingHistoryHandlerTest [repro] TestPrepRecovery [repro] ant compile-test [...truncated 2703 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.TestCollectionStateWatchers" -Dtests.showOutput=onerror -Dtests.seed=5CAF3ABB13212935 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=de-CH -Dtests.timezone=US/Aleutian -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [...truncated 4737 lines...] [repro] Setting last failure code to 256 [repro] ant compile-test [...truncated 1350 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=10 -Dtests.class="*.AutoscalingHistoryHandlerTest|*.TestPrepRecovery" -Dtests.showOutput=onerror -Dtests.seed=CD25E355458B65ED -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=es-PR -Dtests.timezone=Etc/GMT-10 -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [...truncated 3098 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 0/5 failed: org.apache.solr.cloud.TestPrepRecovery [repro] 1/5 failed: org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest [repro] 2/5 failed: org.apache.solr.common.cloud.TestCollectionStateWatchers [repro] git checkout 863d34bff5ce8449c9bfae35acf1ab5746ace35d [...truncated 2 lines...] [repro] Exiting with code 256 [...truncated 5 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9963) Add Apache Calcite Avatica handler to Solr
[ https://issues.apache.org/jira/browse/SOLR-9963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-9963: --- Attachment: SOLR-9963.patch > Add Apache Calcite Avatica handler to Solr > -- > > Key: SOLR-9963 > URL: https://issues.apache.org/jira/browse/SOLR-9963 > Project: Solr > Issue Type: Improvement > Components: Parallel SQL >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Attachments: SOLR-9963.patch, SOLR-9963.patch, SOLR-9963.patch, > SOLR-9963.patch, SOLR-9963.patch, test_avatica_solr.sh > > > Apache Calcite Avatica has an http endpoint which allows Avatica drivers to > connect to the server. This can be wired in as a handler to Solr. This would > allow Solr to be used by any Avatica JDBC/ODBC driver. This depends on the > Calcite work from SOLR-8593. -- 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-9963) Add Apache Calcite Avatica handler to Solr
[ https://issues.apache.org/jira/browse/SOLR-9963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16798591#comment-16798591 ] Kevin Risden commented on SOLR-9963: Updated patch that should handle this case so there aren't multiple JdbcMeta in use. > Add Apache Calcite Avatica handler to Solr > -- > > Key: SOLR-9963 > URL: https://issues.apache.org/jira/browse/SOLR-9963 > Project: Solr > Issue Type: Improvement > Components: Parallel SQL >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Attachments: SOLR-9963.patch, SOLR-9963.patch, SOLR-9963.patch, > SOLR-9963.patch, SOLR-9963.patch, test_avatica_solr.sh > > > Apache Calcite Avatica has an http endpoint which allows Avatica drivers to > connect to the server. This can be wired in as a handler to Solr. This would > allow Solr to be used by any Avatica JDBC/ODBC driver. This depends on the > Calcite work from SOLR-8593. -- 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-9963) Add Apache Calcite Avatica handler to Solr
[ https://issues.apache.org/jira/browse/SOLR-9963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-9963: --- Attachment: (was: SOLR-9963.patch) > Add Apache Calcite Avatica handler to Solr > -- > > Key: SOLR-9963 > URL: https://issues.apache.org/jira/browse/SOLR-9963 > Project: Solr > Issue Type: Improvement > Components: Parallel SQL >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Attachments: SOLR-9963.patch, SOLR-9963.patch, SOLR-9963.patch, > SOLR-9963.patch, SOLR-9963.patch, test_avatica_solr.sh > > > Apache Calcite Avatica has an http endpoint which allows Avatica drivers to > connect to the server. This can be wired in as a handler to Solr. This would > allow Solr to be used by any Avatica JDBC/ODBC driver. This depends on the > Calcite work from SOLR-8593. -- 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-8845) SolrJ JDBC - Ensure that Spark works with SolrJ JDBC
[ https://issues.apache.org/jira/browse/SOLR-8845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-8845: --- Fix Version/s: (was: 7.0) > SolrJ JDBC - Ensure that Spark works with SolrJ JDBC > > > Key: SOLR-8845 > URL: https://issues.apache.org/jira/browse/SOLR-8845 > Project: Solr > Issue Type: Sub-task > Components: SolrJ >Affects Versions: 6.0 >Reporter: Trey Cahill >Assignee: Kevin Risden >Priority: Major > > Ensure that Spark is able work with SolrJ JDBC. > Currently, in Spark 1.6 and 2.x there are 3 known issues: > 1. SparkSQL query via a "select *" query - SOLR-8847 > 2. SparkSQL query via a select query with a 1=0 where clause - SOLR-10171 > 3. SparkSQL query via a prepared statement - SOLR-9017 -- 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-13322) Enable checking for System.out references in Solr codebase
[
https://issues.apache.org/jira/browse/SOLR-13322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16798534#comment-16798534
]
Gus Heck commented on SOLR-13322:
-
Thanks [~ab]:) I'll adjust the patch for the remainder of this to match that
> Enable checking for System.out references in Solr codebase
> --
>
> Key: SOLR-13322
> URL: https://issues.apache.org/jira/browse/SOLR-13322
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build
>Affects Versions: master (9.0)
>Reporter: Gus Heck
>Priority: Minor
> Attachments: SOLR-13322.patch, sysout-forbidden.txt
>
>
> This is almost trivial (just delete this line from the solr build.xml):
> {code:java}
> {code}
> What that line is doing is overriding the top level target that does the
> checking and makes it do nothing.
> BUT unfortunately the "almost" of this is that that instantly detects a
> large number of things, many of which are valid usages because they are in
> command line tools that really do want to report information to system out
> (I'll attach the output)
> This leaves us with two possibilities:
> # Add @ SuppressForbidden (though there seem to be two of these)
> # Convert the CLI oriented code to use logging (probably a custom logging
> config for this use case with no leading date stamp etc...)
> In the first case there's the additional question of whether or not we can
> suppress just the one bundle (jdk-system-out) or if we have to suppress all
> forbidden apis checks (which is a worrisome thought).
> Also it's worth noting that a there are a couple of other detections relating
> to eclipse generated try/catch blocks that are triggered by removing the
> above line from the build.
> Conversation on Slack indicates that [~thetaphi] will likely have some
> thoughts on this.
--
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 (64bit/jdk-11) - Build # 23810 - Still unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23810/ Java: 64bit/jdk-11 -XX:+UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.cloud.SystemCollectionCompatTest.testBackCompat Error Message: re-indexing warning not found Stack Trace: java.lang.AssertionError: re-indexing warning not found at __randomizedtesting.SeedInfo.seed([27C68166B9631E49:573322CFD9ABB73F]:0) at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.assertTrue(Assert.java:41) at org.apache.solr.cloud.SystemCollectionCompatTest.testBackCompat(SystemCollectionCompatTest.java:203) 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.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:834) Build Log: [...truncated 14361 lines...] [junit4] Suite: org.apache.solr.cloud.SystemCollectionCompatTest [junit4] 2> Creating dataDir: /home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J2/temp/solr.cloud.SystemCollectionCompatTest_27C68166B9631E49-001/init-core-data-001
[jira] [Updated] (SOLR-9963) Add Apache Calcite Avatica handler to Solr
[ https://issues.apache.org/jira/browse/SOLR-9963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-9963: --- Attachment: SOLR-9963.patch > Add Apache Calcite Avatica handler to Solr > -- > > Key: SOLR-9963 > URL: https://issues.apache.org/jira/browse/SOLR-9963 > Project: Solr > Issue Type: Improvement > Components: Parallel SQL >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Attachments: SOLR-9963.patch, SOLR-9963.patch, SOLR-9963.patch, > SOLR-9963.patch, SOLR-9963.patch, test_avatica_solr.sh > > > Apache Calcite Avatica has an http endpoint which allows Avatica drivers to > connect to the server. This can be wired in as a handler to Solr. This would > allow Solr to be used by any Avatica JDBC/ODBC driver. This depends on the > Calcite work from SOLR-8593. -- 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=16798694#comment-16798694
]
Lucene/Solr QA commented on SOLR-13335:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
44s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
3s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
3s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check configsets' lucene version
{color} | {color:green} 2m 3s{color} | {color:green} the patch passed {color}
|
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 2m 8s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 2m 3s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check licenses {color} | {color:green}
2m 15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 2m 3s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate ref guide {color} |
{color:green} 2m 3s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
48s{color} | {color:green} velocity in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 14m 38s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-13335 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12963286/SOLR-13335.patch |
| Optional Tests | checklicenses validatesourcepatterns ratsources compile
javac unit checkforbiddenapis checkluceneversion validaterefguide |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP
Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / bca22d5 |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 20 2018 |
| Default Java | 1.8.0_191 |
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/348/testReport/ |
| modules | C: lucene solr solr/contrib/velocity solr/server
solr/solr-ref-guide U: . |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/348/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> 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:
[JENKINS-EA] Lucene-Solr-8.x-Windows (64bit/jdk-13-ea+12) - Build # 131 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/131/ Java: 64bit/jdk-13-ea+12 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 4 tests failed. FAILED: org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly Error Message: Should be exactly one group with 1 entry of 10 for null for field intGSF expected:<1> but was:<0> Stack Trace: java.lang.AssertionError: Should be exactly one group with 1 entry of 10 for null for field intGSF expected:<1> but was:<0> at __randomizedtesting.SeedInfo.seed([F74D461CB1F79FA1:6CF62844FCAFADFF]: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.DocValuesNotIndexedTest.doGroupingDvOnly(DocValuesNotIndexedTest.java:395) at org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly(DocValuesNotIndexedTest.java:321) 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
