[JENKINS-EA] Lucene-Solr-8.x-Linux (64bit/jdk-13-ea+shipilev-fastdebug) - Build # 283 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/283/
Java: 64bit/jdk-13-ea+shipilev-fastdebug -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.metrics.rrd.SolrRrdBackendFactoryTest.testBasic

Error Message:
{} expected:<1> but was:<0>

Stack Trace:
java.lang.AssertionError: {} expected:<1> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([C87731CAB6436655:638D2CDF699FE07B]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at 
org.apache.solr.metrics.rrd.SolrRrdBackendFactoryTest.testBasic(SolrRrdBackendFactoryTest.java:92)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:835)




Build Log:
[...truncated 13074 lines...]
   [junit4] Suite: org.apache.solr.metrics.rrd.SolrRrdBackendFactoryTest
   [junit4]   2> Creating dataDir: 

[jira] [Commented] (SOLR-13294) TestSQLHandler failures on windows jenkins machines

[Joel Bernstein (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796740#comment-16796740
 ] 

Joel Bernstein commented on SOLR-13294:
---

And I can confirm that I can reproduce the docvalues error on my Mac using the 
command line Kevin provided.

> TestSQLHandler failures on windows jenkins machines
> ---
>
> Key: SOLR-13294
> URL: https://issues.apache.org/jira/browse/SOLR-13294
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Joel Bernstein
>Priority: Major
>
> _Windows_ jenkins builds frequently - but _not always_ - fail on 
> {{TestSQLHandler}} @ L236
> In cases where a windows jenkins build finds a failing seed for 
> {{TestSQLHandler}}, and the same jenkins build attempts to reproduce using 
> that seed, it reliably encounters a *different* failure earlier in the test 
> (related to docValues being missing from a sort field).
> These seeds do not fail for me when attempted on a Linux machine, and my own 
> attempts @ beasting on linux hasn't turned up any similar failures.
> Here's an example from jenkins - the exact same pattern has occured in other 
> windows jenkins builds on other branches at the exact same asserts..
> [https://jenkins.thetaphi.de/view/Lucene-Solr/job/Lucene-Solr-8.0-Windows/57/]
> {noformat}
> Using Java: 32bit/jdk1.8.0_172 -server -XX:+UseConcMarkSweepGC
> ...
> Checking out Revision 0376bc0052a53480ecb2edea7dfe58298bda5deb 
> (refs/remotes/origin/branch_8_0)
> ...
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestSQLHandler 
> -Dtests.method=doTest -Dtests.seed=EEE2628F22F5C82A -Dtests.slow=true 
> -Dtests.locale=id -Dtests.timezone=BST -Dtests.asserts=true 
> -Dtests.file.encoding=ISO-8859-1
>[junit4] FAILURE 23.3s J0 | TestSQLHandler.doTest <<<
>[junit4]> Throwable #1: java.lang.AssertionError
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([EEE2628F22F5C82A:49A6DA2B4F4EDB93]:0)
>[junit4]>at 
> org.apache.solr.handler.TestSQLHandler.testBasicSelect(TestSQLHandler.java:236)
>[junit4]>at 
> org.apache.solr.handler.TestSQLHandler.doTest(TestSQLHandler.java:93)
>[junit4]>at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
>[junit4]>at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
>[junit4]>at java.lang.Thread.run(Thread.java:748)
> ...
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestSQLHandler 
> -Dtests.method=doTest -Dtests.seed=EEE2628F22F5C82A -Dtests.slow=true 
> -Dtests.badapples=true -Dtests.locale=id -Dtests.timezone=BST 
> -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
>[junit4] ERROR   20.8s J0 | TestSQLHandler.doTest <<<
>[junit4]> Throwable #1: java.io.IOException: --> 
> http://127.0.0.1:61309/collection1_shard2_replica_n1:Failed to execute 
> sqlQuery 'select id, field_i, str_s, field_i_p, field_f_p, field_d_p, 
> field_l_p from collection1 where (text='()' OR text='') AND 
> text='' order by field_i desc' against JDBC connection 
> 'jdbc:calcitesolr:'.
>[junit4]> Error while executing SQL "select id, field_i, str_s, 
> field_i_p, field_f_p, field_d_p, field_l_p from collection1 where 
> (text='()' OR text='') AND text='' order by field_i desc": 
> java.io.IOException: java.util.concurrent.ExecutionException: 
> java.io.IOException: --> 
> http://127.0.0.1:61309/collection1_shard2_replica_n1/:id{type=string,properties=indexed,stored,sortMissingLast,uninvertible}
>  must have DocValues to use this feature.
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([EEE2628F22F5C82A:49A6DA2B4F4EDB93]:0)
>[junit4]>at 
> org.apache.solr.client.solrj.io.stream.SolrStream.read(SolrStream.java:215)
>[junit4]>at 
> org.apache.solr.handler.TestSQLHandler.getTuples(TestSQLHandler.java:2617)
>[junit4]>at 
> org.apache.solr.handler.TestSQLHandler.testBasicSelect(TestSQLHandler.java:145)
>[junit4]>at 
> org.apache.solr.handler.TestSQLHandler.doTest(TestSQLHandler.java:93)
>[junit4]>at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
>[junit4]>at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
>[junit4]>at java.lang.Thread.run(Thread.java:748)
> ...
>[junit4]   2> NOTE: reproduce with: ant 

[jira] [Commented] (SOLR-13294) TestSQLHandler failures on windows jenkins machines

[Joel Bernstein (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796737#comment-16796737
 ] 

Joel Bernstein commented on SOLR-13294:
---

My first thought when I saw how this test was constructed was to switch it to 
use the mini-solrcloud cluster test framework rather than debugging the current 
test. Reading Kevins comments reinforces my belief that this is the best plan. 

> TestSQLHandler failures on windows jenkins machines
> ---
>
> Key: SOLR-13294
> URL: https://issues.apache.org/jira/browse/SOLR-13294
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Joel Bernstein
>Priority: Major
>
> _Windows_ jenkins builds frequently - but _not always_ - fail on 
> {{TestSQLHandler}} @ L236
> In cases where a windows jenkins build finds a failing seed for 
> {{TestSQLHandler}}, and the same jenkins build attempts to reproduce using 
> that seed, it reliably encounters a *different* failure earlier in the test 
> (related to docValues being missing from a sort field).
> These seeds do not fail for me when attempted on a Linux machine, and my own 
> attempts @ beasting on linux hasn't turned up any similar failures.
> Here's an example from jenkins - the exact same pattern has occured in other 
> windows jenkins builds on other branches at the exact same asserts..
> [https://jenkins.thetaphi.de/view/Lucene-Solr/job/Lucene-Solr-8.0-Windows/57/]
> {noformat}
> Using Java: 32bit/jdk1.8.0_172 -server -XX:+UseConcMarkSweepGC
> ...
> Checking out Revision 0376bc0052a53480ecb2edea7dfe58298bda5deb 
> (refs/remotes/origin/branch_8_0)
> ...
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestSQLHandler 
> -Dtests.method=doTest -Dtests.seed=EEE2628F22F5C82A -Dtests.slow=true 
> -Dtests.locale=id -Dtests.timezone=BST -Dtests.asserts=true 
> -Dtests.file.encoding=ISO-8859-1
>[junit4] FAILURE 23.3s J0 | TestSQLHandler.doTest <<<
>[junit4]> Throwable #1: java.lang.AssertionError
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([EEE2628F22F5C82A:49A6DA2B4F4EDB93]:0)
>[junit4]>at 
> org.apache.solr.handler.TestSQLHandler.testBasicSelect(TestSQLHandler.java:236)
>[junit4]>at 
> org.apache.solr.handler.TestSQLHandler.doTest(TestSQLHandler.java:93)
>[junit4]>at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
>[junit4]>at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
>[junit4]>at java.lang.Thread.run(Thread.java:748)
> ...
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestSQLHandler 
> -Dtests.method=doTest -Dtests.seed=EEE2628F22F5C82A -Dtests.slow=true 
> -Dtests.badapples=true -Dtests.locale=id -Dtests.timezone=BST 
> -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
>[junit4] ERROR   20.8s J0 | TestSQLHandler.doTest <<<
>[junit4]> Throwable #1: java.io.IOException: --> 
> http://127.0.0.1:61309/collection1_shard2_replica_n1:Failed to execute 
> sqlQuery 'select id, field_i, str_s, field_i_p, field_f_p, field_d_p, 
> field_l_p from collection1 where (text='()' OR text='') AND 
> text='' order by field_i desc' against JDBC connection 
> 'jdbc:calcitesolr:'.
>[junit4]> Error while executing SQL "select id, field_i, str_s, 
> field_i_p, field_f_p, field_d_p, field_l_p from collection1 where 
> (text='()' OR text='') AND text='' order by field_i desc": 
> java.io.IOException: java.util.concurrent.ExecutionException: 
> java.io.IOException: --> 
> http://127.0.0.1:61309/collection1_shard2_replica_n1/:id{type=string,properties=indexed,stored,sortMissingLast,uninvertible}
>  must have DocValues to use this feature.
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([EEE2628F22F5C82A:49A6DA2B4F4EDB93]:0)
>[junit4]>at 
> org.apache.solr.client.solrj.io.stream.SolrStream.read(SolrStream.java:215)
>[junit4]>at 
> org.apache.solr.handler.TestSQLHandler.getTuples(TestSQLHandler.java:2617)
>[junit4]>at 
> org.apache.solr.handler.TestSQLHandler.testBasicSelect(TestSQLHandler.java:145)
>[junit4]>at 
> org.apache.solr.handler.TestSQLHandler.doTest(TestSQLHandler.java:93)
>[junit4]>at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
>[junit4]>at 
> 

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-13-ea+shipilev-fastdebug) - Build # 23802 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23802/
Java: 64bit/jdk-13-ea+shipilev-fastdebug -XX:+UseCompressedOops -XX:+UseSerialGC

2 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.update.TransactionLogTest

Error Message:
The test or suite printed 88675 bytes to stdout and stderr, even though the 
limit was set to 8192 bytes. Increase the limit with @Limit, ignore it 
completely with @SuppressSysoutChecks or run with -Dtests.verbose=true

Stack Trace:
java.lang.AssertionError: The test or suite printed 88675 bytes to stdout and 
stderr, even though the limit was set to 8192 bytes. Increase the limit with 
@Limit, ignore it completely with @SuppressSysoutChecks or run with 
-Dtests.verbose=true
at __randomizedtesting.SeedInfo.seed([EDE8A3070B20CED8]:0)
at 
org.apache.lucene.util.TestRuleLimitSysouts.afterIfSuccessful(TestRuleLimitSysouts.java:282)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterIfSuccessful(TestRuleAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:37)
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)


FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.impl.CloudHttp2SolrClientTest

Error Message:
ObjectTracker found 3 object(s) that were not released!!! [SolrCore, 
MockDirectoryWrapper, MockDirectoryWrapper] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.core.SolrCore  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.core.SolrCore.(SolrCore.java:1063)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:883)  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1193)
  at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1103)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:92)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:360)
  at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:396)
  at 
org.apache.solr.handler.admin.CoreAdminHandler.lambda$handleRequestBody$0(CoreAdminHandler.java:188)
  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
  at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
  at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
  at java.base/java.lang.Thread.run(Thread.java:835)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348)
  at 
org.apache.solr.core.SolrCore.initSnapshotMetaDataManager(SolrCore.java:517)  
at org.apache.solr.core.SolrCore.(SolrCore.java:968)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:883)  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1193)
  at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1103)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:92)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:360)
  at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:396)
  at 
org.apache.solr.handler.admin.CoreAdminHandler.lambda$handleRequestBody$0(CoreAdminHandler.java:188)
  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
  at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
  at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
  at java.base/java.lang.Thread.run(Thread.java:835)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 

[jira] [Commented] (LUCENE-8150) Remove references to segments.gen.

[Lucene/Solr QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796692#comment-16796692
 ] 

Lucene/Solr QA commented on LUCENE-8150:


| (/) *{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  
0s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m 
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  1m 37s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  1m 33s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  1m 33s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 33m 
11s{color} | {color:green} core in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  1m 
27s{color} | {color:green} replicator in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 41m 49s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-8150 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12962952/LUCENE-8150.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP 
Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-LUCENE-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / 2a1ed6e |
| 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-LUCENE-Build/177/testReport/ |
| modules | C: lucene/core lucene/replicator U: lucene |
| Console output | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/177/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Remove references to segments.gen.
> --
>
> Key: LUCENE-8150
> URL: https://issues.apache.org/jira/browse/LUCENE-8150
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: 8.1, master (9.0)
>
> Attachments: LUCENE-8150.patch, LUCENE-8150.patch
>
>
> This was the way we wrote pending segment files before we switch to 
> {{pending_segments_N}} in LUCENE-5925.



--
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-12809) Document recommended Java/Solr combinations (JDK 11?)

[Aleck Kulabukhov (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796691#comment-16796691
 ] 

Aleck Kulabukhov commented on SOLR-12809:
-

A real-world case - Solr 6.6.2 works fine on Amazon Corretto 8 (no-cost 
supported until at least June 2023, which does matter in commercial 
deployments).

> Document recommended Java/Solr combinations (JDK 11?)
> -
>
> Key: SOLR-12809
> URL: https://issues.apache.org/jira/browse/SOLR-12809
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> JDK 8 will be EOL early next year (except for "premier support"). JDK 9, 10 
> and 11 all have issues for Solr and Lucene IIUC.
> Also IIUC Oracle will start requiring commercial licenses for 11.
> This Jira is to discuss what we want to do going forward. Among the topics:
>  * Skip straight to 11, skipping 9 and 10? If so how to resolve current 
> issues?
>  * How much emphasis on OpenJDK .vs. Oracle's version
>  * What to do about dependencies that don't work (for whatever reason) with 
> the version of Java we go with?
>  * ???
> This may turn into an umbrella Jira with sub-tasks of course. Since JDK 11 
> has had a GA release, I'd also like to have a record of where the current 
> issues are to refer people to.



--
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-8.x-Windows (32bit/jdk1.8.0_172) - Build # 121 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/121/
Java: 32bit/jdk1.8.0_172 -client -XX:+UseG1GC

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.impl.CloudSolrClientTest

Error Message:
ObjectTracker found 4 object(s) that were not released!!! [SolrCore, 
MockDirectoryWrapper, MockDirectoryWrapper, MockDirectoryWrapper] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.core.SolrCore  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.core.SolrCore.(SolrCore.java:1063)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:883)  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1193)
  at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1103)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:92)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:360)
  at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:396)
  at 
org.apache.solr.handler.admin.CoreAdminHandler.lambda$handleRequestBody$0(CoreAdminHandler.java:188)
  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348)
  at 
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:509)  
at org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:351) 
 at 
org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:424) 
 at 
org.apache.solr.handler.ReplicationHandler.lambda$setupPolling$13(ReplicationHandler.java:1193)
  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)  
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)  at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
  at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348)
  at org.apache.solr.update.SolrIndexWriter.create(SolrIndexWriter.java:99)  at 
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:779)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:976)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:883)  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1193)
  at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1103)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:92)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:360)
  at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:396)
  at 
org.apache.solr.handler.admin.CoreAdminHandler.lambda$handleRequestBody$0(CoreAdminHandler.java:188)
  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348)
  at 
org.apache.solr.core.SolrCore.initSnapshotMetaDataManager(SolrCore.java:517)  
at org.apache.solr.core.SolrCore.(SolrCore.java:968)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:883)  at 

[jira] [Updated] (SOLR-12809) Document recommended Java/Solr combinations (JDK 11?)

[Erick Erickson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erick Erickson updated SOLR-12809:
--
Summary: Document recommended Java/Solr combinations (JDK 11?)  (was: 
Upgrading to a more recent Java (JDK 11?))

> Document recommended Java/Solr combinations (JDK 11?)
> -
>
> Key: SOLR-12809
> URL: https://issues.apache.org/jira/browse/SOLR-12809
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> JDK 8 will be EOL early next year (except for "premier support"). JDK 9, 10 
> and 11 all have issues for Solr and Lucene IIUC.
> Also IIUC Oracle will start requiring commercial licenses for 11.
> This Jira is to discuss what we want to do going forward. Among the topics:
>  * Skip straight to 11, skipping 9 and 10? If so how to resolve current 
> issues?
>  * How much emphasis on OpenJDK .vs. Oracle's version
>  * What to do about dependencies that don't work (for whatever reason) with 
> the version of Java we go with?
>  * ???
> This may turn into an umbrella Jira with sub-tasks of course. Since JDK 11 
> has had a GA release, I'd also like to have a record of where the current 
> issues are to refer people to.



--
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: [VOTE] Master/9.0 to require Java 11

[Shawn Heisey]

On 3/19/2019 12:22 PM, Adrien Grand wrote:

Now that Lucene/Solr 8.0 has shipped I'd like us to consider requiring
Java 11 for 9.0, currently the master branch. We had 18 months between
7.0 and 8.0, so if we assume a similar interval between 8.0 and 9.0
that would mean releasing 9.0 about 2 years after Java 11, which
sounds like a conservative requirement to me.


What advantages to we get as developers with Java 11?  I haven't been 
following the advancements and don't know anything about what's new.  I 
knew a little bit of what Java 8 provided over Java 7, so I was more 
informed the last time we did this.


I see a short list of possible reasons we might want to adjust the minimum:

1) Java 11 makes life significantly better for us (committers, 
contributors, casual code watchers) or significantly improves the user 
experience at runtime.

2) Achieving compatibility with 11 breaks compat with Java 8.
3) If a functional OpenJDK 8 becomes significantly difficult to obtain.
4) If it becomes difficult to produce binaries compatible with 8.
5) Our dependencies increase their minimum Java version.

If none of those applies, then continuing to provide compatibility with 
Java 8 seems like a good idea.


It does seem likely that at least one of the things in the list above 
will occur in the next year or two ... and if it does, then I would be 
all for it.


Thanks,
Shawn

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-repro - Build # 3045 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-repro/3045/

[...truncated 29 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.0/24/consoleText

[repro] Revision: 209d71c08c9af8f32e47e29704d0bc7db4899f3f

[repro] Ant options: -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.0/test-data/enwiki.random.lines.txt
[repro] Repro line:  ant test  -Dtestcase=TestRandomChains 
-Dtests.method=testRandomChainsWithLargeStrings -Dtests.seed=920FA2A878492625 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.0/test-data/enwiki.random.lines.txt
 -Dtests.locale=ar-EG -Dtests.timezone=Europe/Riga -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
2a1ed6e4848abc6ab9bce27c170bce28a4c9691c
[repro] git fetch
[repro] git checkout 209d71c08c9af8f32e47e29704d0bc7db4899f3f

[...truncated 2 lines...]
[repro] git merge --ff-only

[...truncated 1 lines...]
[repro] ant clean

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]lucene/analysis/common
[repro]   TestRandomChains
[repro] ant compile-test

[...truncated 236 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.TestRandomChains" -Dtests.showOutput=onerror 
-Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.0/test-data/enwiki.random.lines.txt
 -Dtests.seed=920FA2A878492625 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.0/test-data/enwiki.random.lines.txt
 -Dtests.locale=ar-EG -Dtests.timezone=Europe/Riga -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[...truncated 203 lines...]
[repro] Setting last failure code to 256

[repro] Failures:
[repro]   4/5 failed: org.apache.lucene.analysis.core.TestRandomChains
[repro] git checkout 2a1ed6e4848abc6ab9bce27c170bce28a4c9691c

[...truncated 2 lines...]
[repro] Exiting with code 256

[...truncated 6 lines...]

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13294) TestSQLHandler failures on windows jenkins machines

[Chris Hostetter (Unused) (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796618#comment-16796618
 ] 

Chris Hostetter (Unused) commented on SOLR-13294:
-

I’m not near a computer, replying on my phone - feel free to paste into jira...

I suspect there are 2 bugs: the test flaw regarding strict order assumption 
that maybe is just a fluke only on windows - not sure the exact cause ther -  
and a test setup/tear down bug that causes the same directory to be used when 
tests.dups kicks in and the same jam runs both, but the field rAndomization 
picks a diff field type? that’s maybe exacerbated on windows by not being able 
to delete the directory while still open. 

-Hoss



> TestSQLHandler failures on windows jenkins machines
> ---
>
> Key: SOLR-13294
> URL: https://issues.apache.org/jira/browse/SOLR-13294
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Joel Bernstein
>Priority: Major
>
> _Windows_ jenkins builds frequently - but _not always_ - fail on 
> {{TestSQLHandler}} @ L236
> In cases where a windows jenkins build finds a failing seed for 
> {{TestSQLHandler}}, and the same jenkins build attempts to reproduce using 
> that seed, it reliably encounters a *different* failure earlier in the test 
> (related to docValues being missing from a sort field).
> These seeds do not fail for me when attempted on a Linux machine, and my own 
> attempts @ beasting on linux hasn't turned up any similar failures.
> Here's an example from jenkins - the exact same pattern has occured in other 
> windows jenkins builds on other branches at the exact same asserts..
> [https://jenkins.thetaphi.de/view/Lucene-Solr/job/Lucene-Solr-8.0-Windows/57/]
> {noformat}
> Using Java: 32bit/jdk1.8.0_172 -server -XX:+UseConcMarkSweepGC
> ...
> Checking out Revision 0376bc0052a53480ecb2edea7dfe58298bda5deb 
> (refs/remotes/origin/branch_8_0)
> ...
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestSQLHandler 
> -Dtests.method=doTest -Dtests.seed=EEE2628F22F5C82A -Dtests.slow=true 
> -Dtests.locale=id -Dtests.timezone=BST -Dtests.asserts=true 
> -Dtests.file.encoding=ISO-8859-1
>[junit4] FAILURE 23.3s J0 | TestSQLHandler.doTest <<<
>[junit4]> Throwable #1: java.lang.AssertionError
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([EEE2628F22F5C82A:49A6DA2B4F4EDB93]:0)
>[junit4]>at 
> org.apache.solr.handler.TestSQLHandler.testBasicSelect(TestSQLHandler.java:236)
>[junit4]>at 
> org.apache.solr.handler.TestSQLHandler.doTest(TestSQLHandler.java:93)
>[junit4]>at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
>[junit4]>at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
>[junit4]>at java.lang.Thread.run(Thread.java:748)
> ...
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestSQLHandler 
> -Dtests.method=doTest -Dtests.seed=EEE2628F22F5C82A -Dtests.slow=true 
> -Dtests.badapples=true -Dtests.locale=id -Dtests.timezone=BST 
> -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
>[junit4] ERROR   20.8s J0 | TestSQLHandler.doTest <<<
>[junit4]> Throwable #1: java.io.IOException: --> 
> http://127.0.0.1:61309/collection1_shard2_replica_n1:Failed to execute 
> sqlQuery 'select id, field_i, str_s, field_i_p, field_f_p, field_d_p, 
> field_l_p from collection1 where (text='()' OR text='') AND 
> text='' order by field_i desc' against JDBC connection 
> 'jdbc:calcitesolr:'.
>[junit4]> Error while executing SQL "select id, field_i, str_s, 
> field_i_p, field_f_p, field_d_p, field_l_p from collection1 where 
> (text='()' OR text='') AND text='' order by field_i desc": 
> java.io.IOException: java.util.concurrent.ExecutionException: 
> java.io.IOException: --> 
> http://127.0.0.1:61309/collection1_shard2_replica_n1/:id{type=string,properties=indexed,stored,sortMissingLast,uninvertible}
>  must have DocValues to use this feature.
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([EEE2628F22F5C82A:49A6DA2B4F4EDB93]:0)
>[junit4]>at 
> org.apache.solr.client.solrj.io.stream.SolrStream.read(SolrStream.java:215)
>[junit4]>at 
> org.apache.solr.handler.TestSQLHandler.getTuples(TestSQLHandler.java:2617)
>[junit4]>at 
> org.apache.solr.handler.TestSQLHandler.testBasicSelect(TestSQLHandler.java:145)
>[junit4]>at 
> org.apache.solr.handler.TestSQLHandler.doTest(TestSQLHandler.java:93)
>[junit4]

Re: [VOTE] Master/9.0 to require Java 11

[Shalin Shekhar Mangar]

+1

On Tue, Mar 19, 2019 at 11:53 PM Adrien Grand  wrote:

> Hello,
>
> Now that Lucene/Solr 8.0 has shipped I'd like us to consider requiring
> Java 11 for 9.0, currently the master branch. We had 18 months between
> 7.0 and 8.0, so if we assume a similar interval between 8.0 and 9.0
> that would mean releasing 9.0 about 2 years after Java 11, which
> sounds like a conservative requirement to me.
>
> What do you think?
>
> Here is my +1.
>
> --
> Adrien
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
Regards,
Shalin Shekhar Mangar.

[jira] [Commented] (SOLR-13040) Harden TestSQLHandler.

[Kevin Risden (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796599#comment-16796599
 ] 

Kevin Risden commented on SOLR-13040:
-

[~mkhludnev] figured out why we are seeing this in SOLR-13294 - no fix yet but 
reproducible.

> Harden TestSQLHandler.
> --
>
> Key: SOLR-13040
> URL: https://issues.apache.org/jira/browse/SOLR-13040
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Joel Bernstein
>Priority: Major
>




--
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-13312) write out responses without creating SolrDocument objects

[Noble Paul (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796581#comment-16796581
 ] 

Noble Paul commented on SOLR-13312:
---

bq.So pseudo code based on your response

yeah, pretty much, that is how it should work

bq.That might work if the codec/code for writing out responses only ever 
iterates linearly through the document anyway... 

That's what response writers do anyway. 

bq.One might even imagine a composition based strategy with an 
.optimizeFieldAccess() method that flips the map 

yeah, we can have a whitelist of methods which can be accessed without creating 
the Map. say, 

* {{forEach()}} 
* {{writeMap()}},
* {{getFieldValue())}}
* {{getFirstValue()}}

if any other method is invoked, we can lazily construct the Map based structure 
that we use today


> write out responses without creating SolrDocument objects
> -
>
> Key: SOLR-13312
> URL: https://issues.apache.org/jira/browse/SOLR-13312
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Priority: Major
>
> Once we get a document from lucene there is no need to create a SolrDocument 
> object to write out the response, if there are no transformers



--
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-13312) write out responses without creating SolrDocument objects

[Gus Heck (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796571#comment-16796571
 ] 

Gus Heck commented on SOLR-13312:
-

That interface sounds interesting. So pseudo code based on your response:
{code:java}
docInter = wrapOrConvert(luceneDoc, have_transformers)
for(transformers:t)
  t.transform(docInter)
sendResponse(convertDocToWt(wt, docInter){code}
That might work if the codec/code for writing out responses only ever iterates 
linearly through the document anyway... which seems likely for writing a 
response. If the interface provides direct field access, the performance of 
field access would vary depending on the impl behind it, one favoring memory at 
the expense of cpu the other favoring cpu at the expense of memory (for cases 
expecting lots of direct field access). Certain use cases (low mem systems) 
might want to force the tradeoff regardless.

One might even imagine a composition based strategy with an 
.optimizeFieldAccess() method that flips the map based backing implementation 
on by swapping in a SolrDocument as a new delegate on demand, so that 
transformers that do nothing but add one more field don't have to require the 
more memory expensive implementation either.

Maybe convert the current SolrDocument class to an inner class of a wrapper 
that takes it's name, and that wrapper that can delegate either to a lucene doc 
or the current impl. Then have an optimizeForFiledAccess() method that code in 
transfomrers (or elsewhere) can call to hint that a map based backing may be 
helpful for performance (I imagine perhaps allowing a sysprop or config setting 
to deny this request for memory constrained systems or systems handling 
documents with very few fields). A new constructor would create the lucene 
backed version, and the existing constructors create one backed by maps as 
before... 

Certain methods such as "getFieldValuesAsMap()" might automatically cause 
conversion...

Just a thought. 

 

> write out responses without creating SolrDocument objects
> -
>
> Key: SOLR-13312
> URL: https://issues.apache.org/jira/browse/SOLR-13312
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Priority: Major
>
> Once we get a document from lucene there is no need to create a SolrDocument 
> object to write out the response, if there are no transformers



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-12-ea+shipilev-fastdebug) - Build # 23801 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23801/
Java: 64bit/jdk-12-ea+shipilev-fastdebug -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.metrics.rrd.SolrRrdBackendFactoryTest.testBasic

Error Message:
{} expected:<1> but was:<0>

Stack Trace:
java.lang.AssertionError: {} expected:<1> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([394CB06F8AB152ED:92B6AD7A556DD4C3]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at 
org.apache.solr.metrics.rrd.SolrRrdBackendFactoryTest.testBasic(SolrRrdBackendFactoryTest.java:92)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:835)




Build Log:
[...truncated 15055 lines...]
   [junit4] Suite: org.apache.solr.metrics.rrd.SolrRrdBackendFactoryTest
   [junit4]   2> 3375178 INFO  
(SUITE-SolrRrdBackendFactoryTest-seed#[394CB06F8AB152ED]-worker) [] 

[jira] [Comment Edited] (SOLR-12809) Upgrading to a more recent Java (JDK 11?)

[Erick Erickson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796532#comment-16796532
 ] 

Erick Erickson edited comment on SOLR-12809 at 3/19/19 9:38 PM:


OK, we need some action on this, so I'll tread in where angels fear

What we need is a matrix, including both Oracle and OpenJDK. This feels like a 
Wiki page since people will have questions about various Solr versions so 
answering questions like "does Java 6 work with OpenJDK 11?" would be hard to 
put in all the reference guides.

Certainly some part of it could be transferred to the current ref guide as 
appropriate.

Here's my straw-man proposal. To get the discussion started, we'll assume it 
doesn't matter whether it's Oracle or OpenJDK

Java 8 is recommended and has had the most mileage.

Java 9,10 are not recommended

Java 11 is recommended from either Oracle or OpenJDK.

Java 12 ?

Java 13 use at own risk, it's not even released yet.

 Which gives us a matrix roughy like this:
|| ||Solr 5x||Solr 6x||Solr 7x||Solr 8x||Solr 9x||Notes||
|Java 7|OK|NO|NO|NO|NO|[1]|
|Java 8|OK|OK|OK|OK|OK| |
|Java 9|NO|NO|NO|NO|NO| |
|Java 10|NO|NO|NO|NO|NO| |
|Java 11| | |OK|OK [5]|OK|[2]|
|Java 12| NO|NO|NO|NO|NO|[3]|
|Java 13|NO|NO|NO|NO|NO|[4]|

[1] Java 8 is required starting with Solr 6.0

[2] What about Solr 5 or 6 and java 11? My straw-man statement is it should 
work but I don't know how much we've tested.

[3] Java 12 GA release was in mid March, 2019. Before recommending it for Solr 
we'd prefer to let the general release mature

[4] Java 13 only has early access builds available.

[5] Prior to Solr 8, using Solr/Lucene with Hadoop _will not work_ with any 
Java version 9 or greater.

So let's flesh this out so we have a position the community can stand behind. 


was (Author: erickerickson):
OK, we need some action on this, so I'll tread in where angels fear

What we need is a matrix, including both Oracle and OpenJDK. This feels like a 
Wiki page since people will have questions about various Solr versions so 
answering questions like "does Java 6 work with OpenJDK 11?" would be hard to 
put in all the reference guides.

Certainly some part of it could be transferred to the current ref guide as 
appropriate.

Here's my straw-man proposal. To get the discussion started, we'll assume it 
doesn't matter whether it's Oracle or OpenJDK

Java 8 is recommended and has had the most mileage.

Java 9,10 are not recommended

Java 11 is recommended from either Oracle or OpenJDK.

Java 12 ?

Java 13 use at own risk, it's not even released yet.

 Which gives us a matrix roughy like this:
|| ||Solr 5x||Solr 6x||Solr 7x||Solr 8x||Solr 9x||Notes||
|Java 7|OK|NO|NO|NO|NO|[1]|
|Java 8|OK|OK|OK|OK|OK| |
|Java 9|NO|NO|NO|NO|NO| |
|Java 10|NO|NO|NO|NO|NO| |
|Java 11| | |OK|OK|OK|[2]|
|Java 12| | | | | |[3]|
|Java 13|NO|NO|NO|NO|NO|[4]|

[1] Java 8 is required starting with Solr 6.0

[2] What about Solr 5 or 6 and java 11? My straw-man statement is it should 
work but I don't know how much we've tested.

[3] I really have no clue what to say here. Java 11 seems to be the one we're 
getting the most questions about, so maybe this can be deferred unless we have 
concrete answers.

[4] Java 13 only has early access builds available.

 

So let's flesh this out so we have a position the community can stand behind. 

> Upgrading to a more recent Java (JDK 11?)
> -
>
> Key: SOLR-12809
> URL: https://issues.apache.org/jira/browse/SOLR-12809
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> JDK 8 will be EOL early next year (except for "premier support"). JDK 9, 10 
> and 11 all have issues for Solr and Lucene IIUC.
> Also IIUC Oracle will start requiring commercial licenses for 11.
> This Jira is to discuss what we want to do going forward. Among the topics:
>  * Skip straight to 11, skipping 9 and 10? If so how to resolve current 
> issues?
>  * How much emphasis on OpenJDK .vs. Oracle's version
>  * What to do about dependencies that don't work (for whatever reason) with 
> the version of Java we go with?
>  * ???
> This may turn into an umbrella Jira with sub-tasks of course. Since JDK 11 
> has had a GA release, I'd also like to have a record of where the current 
> issues are to refer people to.



--
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-12809) Upgrading to a more recent Java (JDK 11?)

[Erick Erickson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796532#comment-16796532
 ] 

Erick Erickson commented on SOLR-12809:
---

OK, we need some action on this, so I'll tread in where angels fear

What we need is a matrix, including both Oracle and OpenJDK. This feels like a 
Wiki page since people will have questions about various Solr versions so 
answering questions like "does Java 6 work with OpenJDK 11?" would be hard to 
put in all the reference guides.

Certainly some part of it could be transferred to the current ref guide as 
appropriate.

Here's my straw-man proposal. To get the discussion started, we'll assume it 
doesn't matter whether it's Oracle or OpenJDK

Java 8 is recommended and has had the most mileage.

Java 9,10 are not recommended

Java 11 is recommended from either Oracle or OpenJDK.

Java 12 ?

Java 13 use at own risk, it's not even released yet.

 Which gives us a matrix roughy like this:
|| ||Solr 5x||Solr 6x||Solr 7x||Solr 8x||Solr 9x||Notes||
|Java 7|OK|NO|NO|NO|NO|[1]|
|Java 8|OK|OK|OK|OK|OK| |
|Java 9|NO|NO|NO|NO|NO| |
|Java 10|NO|NO|NO|NO|NO| |
|Java 11| | |OK|OK|OK|[2]|
|Java 12| | | | | |[3]|
|Java 13|NO|NO|NO|NO|NO|[4]|

[1] Java 8 is required starting with Solr 6.0

[2] What about Solr 5 or 6 and java 11? My straw-man statement is it should 
work but I don't know how much we've tested.

[3] I really have no clue what to say here. Java 11 seems to be the one we're 
getting the most questions about, so maybe this can be deferred unless we have 
concrete answers.

[4] Java 13 only has early access builds available.

 

So let's flesh this out so we have a position the community can stand behind. 

> Upgrading to a more recent Java (JDK 11?)
> -
>
> Key: SOLR-12809
> URL: https://issues.apache.org/jira/browse/SOLR-12809
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> JDK 8 will be EOL early next year (except for "premier support"). JDK 9, 10 
> and 11 all have issues for Solr and Lucene IIUC.
> Also IIUC Oracle will start requiring commercial licenses for 11.
> This Jira is to discuss what we want to do going forward. Among the topics:
>  * Skip straight to 11, skipping 9 and 10? If so how to resolve current 
> issues?
>  * How much emphasis on OpenJDK .vs. Oracle's version
>  * What to do about dependencies that don't work (for whatever reason) with 
> the version of Java we go with?
>  * ???
> This may turn into an umbrella Jira with sub-tasks of course. Since JDK 11 
> has had a GA release, I'd also like to have a record of where the current 
> issues are to refer people to.



--
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: [VOTE] Master/9.0 to require Java 11

[Erick Erickson]

I’d like to ask people to comment on SOLR-12809 (actually, maybe it should be a 
Lucene JIRA). It’s related in that we are getting more and more questions about 
whether Solr/Lucene version X works with Java Y….

We need to have a consistent story, inquiring minds want to know….



> On Mar 19, 2019, at 2:01 PM, Uwe Schindler  wrote:
> 
> +1, let's do it.
> 
> I can take care of commenting out the MR-JAR parts and migrating from 
> lucene.Future* to java.util.*  (but we should not remove it from build files, 
> so we can use MR-JARS in the same way in future).
> 
> Just open an issue once the vote has passed, I'l take care of removing the 
> Future* classes.
> 
> Uwe
> 
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
> 
>> -Original Message-
>> From: Adrien Grand 
>> Sent: Tuesday, March 19, 2019 7:23 PM
>> To: Lucene Dev 
>> Subject: [VOTE] Master/9.0 to require Java 11
>> 
>> Hello,
>> 
>> Now that Lucene/Solr 8.0 has shipped I'd like us to consider requiring
>> Java 11 for 9.0, currently the master branch. We had 18 months between
>> 7.0 and 8.0, so if we assume a similar interval between 8.0 and 9.0
>> that would mean releasing 9.0 about 2 years after Java 11, which
>> sounds like a conservative requirement to me.
>> 
>> What do you think?
>> 
>> Here is my +1.
>> 
>> --
>> Adrien
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12809) Upgrading to a more recent Java (JDK 11?)

[Kevin Risden (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796538#comment-16796538
 ] 

Kevin Risden commented on SOLR-12809:
-

Solr 8 is the first version that may work with Hadoop and JDK 9+. So might want 
to put that in the notes.

> Upgrading to a more recent Java (JDK 11?)
> -
>
> Key: SOLR-12809
> URL: https://issues.apache.org/jira/browse/SOLR-12809
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> JDK 8 will be EOL early next year (except for "premier support"). JDK 9, 10 
> and 11 all have issues for Solr and Lucene IIUC.
> Also IIUC Oracle will start requiring commercial licenses for 11.
> This Jira is to discuss what we want to do going forward. Among the topics:
>  * Skip straight to 11, skipping 9 and 10? If so how to resolve current 
> issues?
>  * How much emphasis on OpenJDK .vs. Oracle's version
>  * What to do about dependencies that don't work (for whatever reason) with 
> the version of Java we go with?
>  * ???
> This may turn into an umbrella Jira with sub-tasks of course. Since JDK 11 
> has had a GA release, I'd also like to have a record of where the current 
> issues are to refer people to.



--
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-12809) Upgrading to a more recent Java (JDK 11?)

[Kevin Risden (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796535#comment-16796535
 ] 

Kevin Risden commented on SOLR-12809:
-

JDK 12 went GA today 3/19/19 so thats probably why no questions :) Wouldn't 
recommend it on day one.

> Upgrading to a more recent Java (JDK 11?)
> -
>
> Key: SOLR-12809
> URL: https://issues.apache.org/jira/browse/SOLR-12809
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> JDK 8 will be EOL early next year (except for "premier support"). JDK 9, 10 
> and 11 all have issues for Solr and Lucene IIUC.
> Also IIUC Oracle will start requiring commercial licenses for 11.
> This Jira is to discuss what we want to do going forward. Among the topics:
>  * Skip straight to 11, skipping 9 and 10? If so how to resolve current 
> issues?
>  * How much emphasis on OpenJDK .vs. Oracle's version
>  * What to do about dependencies that don't work (for whatever reason) with 
> the version of Java we go with?
>  * ???
> This may turn into an umbrella Jira with sub-tasks of course. Since JDK 11 
> has had a GA release, I'd also like to have a record of where the current 
> issues are to refer people to.



--
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-13294) TestSQLHandler failures on windows jenkins machines

[Kevin Risden (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796527#comment-16796527
 ] 

Kevin Risden commented on SOLR-13294:
-

The reason we only see this on Windows is the first assertion failure is what 
kicks off the reproduction chain. The test looks to be flawed as far as 
checking the versions returned and assuming they will be in insertion order. It 
must be that on Linux/Mac we just never hit that case of versions in separate 
shards.

> TestSQLHandler failures on windows jenkins machines
> ---
>
> Key: SOLR-13294
> URL: https://issues.apache.org/jira/browse/SOLR-13294
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Joel Bernstein
>Priority: Major
>
> _Windows_ jenkins builds frequently - but _not always_ - fail on 
> {{TestSQLHandler}} @ L236
> In cases where a windows jenkins build finds a failing seed for 
> {{TestSQLHandler}}, and the same jenkins build attempts to reproduce using 
> that seed, it reliably encounters a *different* failure earlier in the test 
> (related to docValues being missing from a sort field).
> These seeds do not fail for me when attempted on a Linux machine, and my own 
> attempts @ beasting on linux hasn't turned up any similar failures.
> Here's an example from jenkins - the exact same pattern has occured in other 
> windows jenkins builds on other branches at the exact same asserts..
> [https://jenkins.thetaphi.de/view/Lucene-Solr/job/Lucene-Solr-8.0-Windows/57/]
> {noformat}
> Using Java: 32bit/jdk1.8.0_172 -server -XX:+UseConcMarkSweepGC
> ...
> Checking out Revision 0376bc0052a53480ecb2edea7dfe58298bda5deb 
> (refs/remotes/origin/branch_8_0)
> ...
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestSQLHandler 
> -Dtests.method=doTest -Dtests.seed=EEE2628F22F5C82A -Dtests.slow=true 
> -Dtests.locale=id -Dtests.timezone=BST -Dtests.asserts=true 
> -Dtests.file.encoding=ISO-8859-1
>[junit4] FAILURE 23.3s J0 | TestSQLHandler.doTest <<<
>[junit4]> Throwable #1: java.lang.AssertionError
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([EEE2628F22F5C82A:49A6DA2B4F4EDB93]:0)
>[junit4]>at 
> org.apache.solr.handler.TestSQLHandler.testBasicSelect(TestSQLHandler.java:236)
>[junit4]>at 
> org.apache.solr.handler.TestSQLHandler.doTest(TestSQLHandler.java:93)
>[junit4]>at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
>[junit4]>at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
>[junit4]>at java.lang.Thread.run(Thread.java:748)
> ...
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestSQLHandler 
> -Dtests.method=doTest -Dtests.seed=EEE2628F22F5C82A -Dtests.slow=true 
> -Dtests.badapples=true -Dtests.locale=id -Dtests.timezone=BST 
> -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
>[junit4] ERROR   20.8s J0 | TestSQLHandler.doTest <<<
>[junit4]> Throwable #1: java.io.IOException: --> 
> http://127.0.0.1:61309/collection1_shard2_replica_n1:Failed to execute 
> sqlQuery 'select id, field_i, str_s, field_i_p, field_f_p, field_d_p, 
> field_l_p from collection1 where (text='()' OR text='') AND 
> text='' order by field_i desc' against JDBC connection 
> 'jdbc:calcitesolr:'.
>[junit4]> Error while executing SQL "select id, field_i, str_s, 
> field_i_p, field_f_p, field_d_p, field_l_p from collection1 where 
> (text='()' OR text='') AND text='' order by field_i desc": 
> java.io.IOException: java.util.concurrent.ExecutionException: 
> java.io.IOException: --> 
> http://127.0.0.1:61309/collection1_shard2_replica_n1/:id{type=string,properties=indexed,stored,sortMissingLast,uninvertible}
>  must have DocValues to use this feature.
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([EEE2628F22F5C82A:49A6DA2B4F4EDB93]:0)
>[junit4]>at 
> org.apache.solr.client.solrj.io.stream.SolrStream.read(SolrStream.java:215)
>[junit4]>at 
> org.apache.solr.handler.TestSQLHandler.getTuples(TestSQLHandler.java:2617)
>[junit4]>at 
> org.apache.solr.handler.TestSQLHandler.testBasicSelect(TestSQLHandler.java:145)
>[junit4]>at 
> org.apache.solr.handler.TestSQLHandler.doTest(TestSQLHandler.java:93)
>[junit4]>at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
>[junit4]>at 
> 

[jira] [Commented] (SOLR-13294) TestSQLHandler failures on windows jenkins machines

[Kevin Risden (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796525#comment-16796525
 ] 

Kevin Risden commented on SOLR-13294:
-

[~hossman] / [~joel.bernstein] can either of you confirm you see the same no 
docvalues failure if you run the below?

{code:java}
ant test -Dtests.jvms=1 -Dtests.dups=2 -Dtests.class="*.TestSQLHandler" 
-Dtests.showOutput=onerror
{code}

> TestSQLHandler failures on windows jenkins machines
> ---
>
> Key: SOLR-13294
> URL: https://issues.apache.org/jira/browse/SOLR-13294
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Joel Bernstein
>Priority: Major
>
> _Windows_ jenkins builds frequently - but _not always_ - fail on 
> {{TestSQLHandler}} @ L236
> In cases where a windows jenkins build finds a failing seed for 
> {{TestSQLHandler}}, and the same jenkins build attempts to reproduce using 
> that seed, it reliably encounters a *different* failure earlier in the test 
> (related to docValues being missing from a sort field).
> These seeds do not fail for me when attempted on a Linux machine, and my own 
> attempts @ beasting on linux hasn't turned up any similar failures.
> Here's an example from jenkins - the exact same pattern has occured in other 
> windows jenkins builds on other branches at the exact same asserts..
> [https://jenkins.thetaphi.de/view/Lucene-Solr/job/Lucene-Solr-8.0-Windows/57/]
> {noformat}
> Using Java: 32bit/jdk1.8.0_172 -server -XX:+UseConcMarkSweepGC
> ...
> Checking out Revision 0376bc0052a53480ecb2edea7dfe58298bda5deb 
> (refs/remotes/origin/branch_8_0)
> ...
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestSQLHandler 
> -Dtests.method=doTest -Dtests.seed=EEE2628F22F5C82A -Dtests.slow=true 
> -Dtests.locale=id -Dtests.timezone=BST -Dtests.asserts=true 
> -Dtests.file.encoding=ISO-8859-1
>[junit4] FAILURE 23.3s J0 | TestSQLHandler.doTest <<<
>[junit4]> Throwable #1: java.lang.AssertionError
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([EEE2628F22F5C82A:49A6DA2B4F4EDB93]:0)
>[junit4]>at 
> org.apache.solr.handler.TestSQLHandler.testBasicSelect(TestSQLHandler.java:236)
>[junit4]>at 
> org.apache.solr.handler.TestSQLHandler.doTest(TestSQLHandler.java:93)
>[junit4]>at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
>[junit4]>at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
>[junit4]>at java.lang.Thread.run(Thread.java:748)
> ...
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestSQLHandler 
> -Dtests.method=doTest -Dtests.seed=EEE2628F22F5C82A -Dtests.slow=true 
> -Dtests.badapples=true -Dtests.locale=id -Dtests.timezone=BST 
> -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
>[junit4] ERROR   20.8s J0 | TestSQLHandler.doTest <<<
>[junit4]> Throwable #1: java.io.IOException: --> 
> http://127.0.0.1:61309/collection1_shard2_replica_n1:Failed to execute 
> sqlQuery 'select id, field_i, str_s, field_i_p, field_f_p, field_d_p, 
> field_l_p from collection1 where (text='()' OR text='') AND 
> text='' order by field_i desc' against JDBC connection 
> 'jdbc:calcitesolr:'.
>[junit4]> Error while executing SQL "select id, field_i, str_s, 
> field_i_p, field_f_p, field_d_p, field_l_p from collection1 where 
> (text='()' OR text='') AND text='' order by field_i desc": 
> java.io.IOException: java.util.concurrent.ExecutionException: 
> java.io.IOException: --> 
> http://127.0.0.1:61309/collection1_shard2_replica_n1/:id{type=string,properties=indexed,stored,sortMissingLast,uninvertible}
>  must have DocValues to use this feature.
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([EEE2628F22F5C82A:49A6DA2B4F4EDB93]:0)
>[junit4]>at 
> org.apache.solr.client.solrj.io.stream.SolrStream.read(SolrStream.java:215)
>[junit4]>at 
> org.apache.solr.handler.TestSQLHandler.getTuples(TestSQLHandler.java:2617)
>[junit4]>at 
> org.apache.solr.handler.TestSQLHandler.testBasicSelect(TestSQLHandler.java:145)
>[junit4]>at 
> org.apache.solr.handler.TestSQLHandler.doTest(TestSQLHandler.java:93)
>[junit4]>at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
>[junit4]>at 
> 

[jira] [Commented] (SOLR-13294) TestSQLHandler failures on windows jenkins machines

[Kevin Risden (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796523#comment-16796523
 ] 

Kevin Risden commented on SOLR-13294:
-

I was able to reproduce this on my Mac. I skipped the first part of the 
assertion error and skipped to the bottom:

{code:java}
ant test -Dtests.jvms=1 -Dtests.dups=2 -Dtests.class="*.TestSQLHandler" 
-Dtests.showOutput=onerror
{code}

The first test in the JVM always passes. The second run in the same JVM fails. 
The tests.jvms and tests.dups is minimum required to make this fail. This fails 
reliably on my Mac and Windows machines.

There is something not right about how the test framework or test is reusing 
things in the same JVM. The schema must not be setup properly a second time.

> TestSQLHandler failures on windows jenkins machines
> ---
>
> Key: SOLR-13294
> URL: https://issues.apache.org/jira/browse/SOLR-13294
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Joel Bernstein
>Priority: Major
>
> _Windows_ jenkins builds frequently - but _not always_ - fail on 
> {{TestSQLHandler}} @ L236
> In cases where a windows jenkins build finds a failing seed for 
> {{TestSQLHandler}}, and the same jenkins build attempts to reproduce using 
> that seed, it reliably encounters a *different* failure earlier in the test 
> (related to docValues being missing from a sort field).
> These seeds do not fail for me when attempted on a Linux machine, and my own 
> attempts @ beasting on linux hasn't turned up any similar failures.
> Here's an example from jenkins - the exact same pattern has occured in other 
> windows jenkins builds on other branches at the exact same asserts..
> [https://jenkins.thetaphi.de/view/Lucene-Solr/job/Lucene-Solr-8.0-Windows/57/]
> {noformat}
> Using Java: 32bit/jdk1.8.0_172 -server -XX:+UseConcMarkSweepGC
> ...
> Checking out Revision 0376bc0052a53480ecb2edea7dfe58298bda5deb 
> (refs/remotes/origin/branch_8_0)
> ...
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestSQLHandler 
> -Dtests.method=doTest -Dtests.seed=EEE2628F22F5C82A -Dtests.slow=true 
> -Dtests.locale=id -Dtests.timezone=BST -Dtests.asserts=true 
> -Dtests.file.encoding=ISO-8859-1
>[junit4] FAILURE 23.3s J0 | TestSQLHandler.doTest <<<
>[junit4]> Throwable #1: java.lang.AssertionError
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([EEE2628F22F5C82A:49A6DA2B4F4EDB93]:0)
>[junit4]>at 
> org.apache.solr.handler.TestSQLHandler.testBasicSelect(TestSQLHandler.java:236)
>[junit4]>at 
> org.apache.solr.handler.TestSQLHandler.doTest(TestSQLHandler.java:93)
>[junit4]>at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
>[junit4]>at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
>[junit4]>at java.lang.Thread.run(Thread.java:748)
> ...
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestSQLHandler 
> -Dtests.method=doTest -Dtests.seed=EEE2628F22F5C82A -Dtests.slow=true 
> -Dtests.badapples=true -Dtests.locale=id -Dtests.timezone=BST 
> -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
>[junit4] ERROR   20.8s J0 | TestSQLHandler.doTest <<<
>[junit4]> Throwable #1: java.io.IOException: --> 
> http://127.0.0.1:61309/collection1_shard2_replica_n1:Failed to execute 
> sqlQuery 'select id, field_i, str_s, field_i_p, field_f_p, field_d_p, 
> field_l_p from collection1 where (text='()' OR text='') AND 
> text='' order by field_i desc' against JDBC connection 
> 'jdbc:calcitesolr:'.
>[junit4]> Error while executing SQL "select id, field_i, str_s, 
> field_i_p, field_f_p, field_d_p, field_l_p from collection1 where 
> (text='()' OR text='') AND text='' order by field_i desc": 
> java.io.IOException: java.util.concurrent.ExecutionException: 
> java.io.IOException: --> 
> http://127.0.0.1:61309/collection1_shard2_replica_n1/:id{type=string,properties=indexed,stored,sortMissingLast,uninvertible}
>  must have DocValues to use this feature.
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([EEE2628F22F5C82A:49A6DA2B4F4EDB93]:0)
>[junit4]>at 
> org.apache.solr.client.solrj.io.stream.SolrStream.read(SolrStream.java:215)
>[junit4]>at 
> org.apache.solr.handler.TestSQLHandler.getTuples(TestSQLHandler.java:2617)
>[junit4]>at 
> org.apache.solr.handler.TestSQLHandler.testBasicSelect(TestSQLHandler.java:145)
>[junit4]>at 
> 

RE: [VOTE] Master/9.0 to require Java 11

[Uwe Schindler]

+1, let's do it.

I can take care of commenting out the MR-JAR parts and migrating from 
lucene.Future* to java.util.*  (but we should not remove it from build files, 
so we can use MR-JARS in the same way in future).

Just open an issue once the vote has passed, I'l take care of removing the 
Future* classes.

Uwe

-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Adrien Grand 
> Sent: Tuesday, March 19, 2019 7:23 PM
> To: Lucene Dev 
> Subject: [VOTE] Master/9.0 to require Java 11
> 
> Hello,
> 
> Now that Lucene/Solr 8.0 has shipped I'd like us to consider requiring
> Java 11 for 9.0, currently the master branch. We had 18 months between
> 7.0 and 8.0, so if we assume a similar interval between 8.0 and 9.0
> that would mean releasing 9.0 about 2 years after Java 11, which
> sounds like a conservative requirement to me.
> 
> What do you think?
> 
> Here is my +1.
> 
> --
> Adrien
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8616) Maven build: Simplify the way transitive dependency resolution is disabled, and increase the minimum supported Maven from 2.2.1 to 3.2.1

[Kevin Risden (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796492#comment-16796492
 ] 

Kevin Risden commented on LUCENE-8616:
--

Sounds good - came here from SOLR-11579 after the email about master 
potentially being JDK 11. We are going to have to upgrade plugins to make the 
maven build continue to work on master.

> Maven build: Simplify the way transitive dependency resolution is disabled, 
> and increase the minimum supported Maven from 2.2.1 to 3.2.1
> 
>
> Key: LUCENE-8616
> URL: https://issues.apache.org/jira/browse/LUCENE-8616
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: LUCENE-8616.patch
>
>
> Right now the Maven build disables transitive dependency resolution for all 
> dependencies by listing each dependency's dependencies in a nested 
> {{}} section in the grandparent POM's {{}} 
> section. 
> As of Maven 3.2.1, it's possible to use a wildcard syntax in nested 
> {{}} sections to exclude all transitive deps: MNG-2315. This 
> would make the grandparent POM much smaller and make the intent much clearer.
> We would have to increase our minimum supported Maven (currently 2.2.1), but 
> that seems reasonable, given that Maven 2.x has been EOL'd: 
> https://maven.apache.org/maven-2.x-eol.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13294) TestSQLHandler failures on windows jenkins machines

[Kevin Risden (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796498#comment-16796498
 ] 

Kevin Risden commented on SOLR-13294:
-

So I have no idea why this doesn't fail on Linux as well.

Reading TestSQLHandler, it looks like documents are indexed. The assertion 
looks like it fails since documents don't come back in the order the test 
thinks it does. The output shows id=7 being the first document instead of 8. 
Since there are 2 shards the different _version_ could be out of order I think. 
So I think that explains the first assertion error.

The reproduction later is puzzling though it is almost like the base class 
isn't setting up the schema correctly? Since the first query is the one that 
fails about docvalues.

> TestSQLHandler failures on windows jenkins machines
> ---
>
> Key: SOLR-13294
> URL: https://issues.apache.org/jira/browse/SOLR-13294
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Joel Bernstein
>Priority: Major
>
> _Windows_ jenkins builds frequently - but _not always_ - fail on 
> {{TestSQLHandler}} @ L236
> In cases where a windows jenkins build finds a failing seed for 
> {{TestSQLHandler}}, and the same jenkins build attempts to reproduce using 
> that seed, it reliably encounters a *different* failure earlier in the test 
> (related to docValues being missing from a sort field).
> These seeds do not fail for me when attempted on a Linux machine, and my own 
> attempts @ beasting on linux hasn't turned up any similar failures.
> Here's an example from jenkins - the exact same pattern has occured in other 
> windows jenkins builds on other branches at the exact same asserts..
> [https://jenkins.thetaphi.de/view/Lucene-Solr/job/Lucene-Solr-8.0-Windows/57/]
> {noformat}
> Using Java: 32bit/jdk1.8.0_172 -server -XX:+UseConcMarkSweepGC
> ...
> Checking out Revision 0376bc0052a53480ecb2edea7dfe58298bda5deb 
> (refs/remotes/origin/branch_8_0)
> ...
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestSQLHandler 
> -Dtests.method=doTest -Dtests.seed=EEE2628F22F5C82A -Dtests.slow=true 
> -Dtests.locale=id -Dtests.timezone=BST -Dtests.asserts=true 
> -Dtests.file.encoding=ISO-8859-1
>[junit4] FAILURE 23.3s J0 | TestSQLHandler.doTest <<<
>[junit4]> Throwable #1: java.lang.AssertionError
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([EEE2628F22F5C82A:49A6DA2B4F4EDB93]:0)
>[junit4]>at 
> org.apache.solr.handler.TestSQLHandler.testBasicSelect(TestSQLHandler.java:236)
>[junit4]>at 
> org.apache.solr.handler.TestSQLHandler.doTest(TestSQLHandler.java:93)
>[junit4]>at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
>[junit4]>at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
>[junit4]>at java.lang.Thread.run(Thread.java:748)
> ...
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestSQLHandler 
> -Dtests.method=doTest -Dtests.seed=EEE2628F22F5C82A -Dtests.slow=true 
> -Dtests.badapples=true -Dtests.locale=id -Dtests.timezone=BST 
> -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
>[junit4] ERROR   20.8s J0 | TestSQLHandler.doTest <<<
>[junit4]> Throwable #1: java.io.IOException: --> 
> http://127.0.0.1:61309/collection1_shard2_replica_n1:Failed to execute 
> sqlQuery 'select id, field_i, str_s, field_i_p, field_f_p, field_d_p, 
> field_l_p from collection1 where (text='()' OR text='') AND 
> text='' order by field_i desc' against JDBC connection 
> 'jdbc:calcitesolr:'.
>[junit4]> Error while executing SQL "select id, field_i, str_s, 
> field_i_p, field_f_p, field_d_p, field_l_p from collection1 where 
> (text='()' OR text='') AND text='' order by field_i desc": 
> java.io.IOException: java.util.concurrent.ExecutionException: 
> java.io.IOException: --> 
> http://127.0.0.1:61309/collection1_shard2_replica_n1/:id{type=string,properties=indexed,stored,sortMissingLast,uninvertible}
>  must have DocValues to use this feature.
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([EEE2628F22F5C82A:49A6DA2B4F4EDB93]:0)
>[junit4]>at 
> org.apache.solr.client.solrj.io.stream.SolrStream.read(SolrStream.java:215)
>[junit4]>at 
> org.apache.solr.handler.TestSQLHandler.getTuples(TestSQLHandler.java:2617)
>[junit4]>at 
> org.apache.solr.handler.TestSQLHandler.testBasicSelect(TestSQLHandler.java:145)
>[junit4]>at 
> 

[jira] [Commented] (LUCENE-8616) Maven build: Simplify the way transitive dependency resolution is disabled, and increase the minimum supported Maven from 2.2.1 to 3.2.1

[Steve Rowe (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796487#comment-16796487
 ] 

Steve Rowe commented on LUCENE-8616:


[~krisden]: it's ready to go (might have grown stale since...), but as I wrote 
in a post above:

{quote}I won't commit until I get other opinions about the wisdom of doing so, 
given the Ant support issues mentioned in my previous comment on this 
issue.{quote}

There has been no activity on IVY-1580 since then, and a 
[query|http://mail-archives.apache.org/mod_mbox/ant-dev/201903.mbox/%3ccak-d_hvwodnhqgctwhupa55dq9ypaoees_mrswlamcl3uiy...@mail.gmail.com%3e]
 about Ivy 2.5.0 release timing on the ant-dev list was [responded 
to|http://mail-archives.apache.org/mod_mbox/ant-dev/201903.mbox/%3cbb6f61de-b0fa-c9f1-d30b-3dcae070a...@apache.org%3e]
 two weeks ago:

{quote}
The only thing that's stopping me from
releasing 2.5.0 is IVY-1580 issue. I will send out a mail this week to
dev list to explain what that issue is and what are our options on
getting past it. Once we have a decision, I'll go ahead with a release
proposal.
{quote}

> Maven build: Simplify the way transitive dependency resolution is disabled, 
> and increase the minimum supported Maven from 2.2.1 to 3.2.1
> 
>
> Key: LUCENE-8616
> URL: https://issues.apache.org/jira/browse/LUCENE-8616
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: LUCENE-8616.patch
>
>
> Right now the Maven build disables transitive dependency resolution for all 
> dependencies by listing each dependency's dependencies in a nested 
> {{}} section in the grandparent POM's {{}} 
> section. 
> As of Maven 3.2.1, it's possible to use a wildcard syntax in nested 
> {{}} sections to exclude all transitive deps: MNG-2315. This 
> would make the grandparent POM much smaller and make the intent much clearer.
> We would have to increase our minimum supported Maven (currently 2.2.1), but 
> that seems reasonable, given that Maven 2.x has been EOL'd: 
> https://maven.apache.org/maven-2.x-eol.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-12860) MetricsHistoryHandler does not work with BasicAuth

[Lorenzo (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796463#comment-16796463
 ] 

Lorenzo edited comment on SOLR-12860 at 3/19/19 8:26 PM:
-

Just for info while I investigate.

 
{code:java}
MetricsHistoryHandler.collectGlobalMetrics()...
...
NodeStateProvider nodeStateProvider = this.cloudManager.getNodeStateProvider();
...
Map>> infos = 
nodeStateProvider.getReplicaInfo(node, collTags);
...
  Map tagValues = fetchReplicaMetrics(node, 
metricsKeyVsTagReplica);
  ... 
  fetchReplicaMetrics(node, ctx, collect);
  ...
 rsp = ctx.invoke(solrNode, CommonParams.METRICS_PATH, params);
 ...

public SimpleSolrResponse invoke(String solrNode, String path, SolrParams 
params)
  throws IOException, SolrServerException {
String url = 
zkClientClusterStateProvider.getZkStateReader().getBaseUrlForNodeName(solrNode);

GenericSolrRequest request = new 
GenericSolrRequest(SolrRequest.METHOD.POST, path, params);
try (HttpSolrClient client = new HttpSolrClient.Builder()
.withHttpClient(solrClient.getHttpClient())
.withBaseSolrUrl(url)
.withResponseParser(new BinaryResponseParser())
.build()) {
  NamedList rsp = client.request(request);
  request.response.nl = rsp;
  return request.response;
}
  }

}

{code}
The HTTPClient instance this handler uses is apparently pre-configured. 
HTTPClient comes from 
{{coreContainer.getUpdateShardHandler().getDefaultHTTPClient().}}

 


was (Author: yael.lorenzo):
Just for info while I investigate

 
{code:java}
MetricsHistoryHandler.collectGlobalMetrics()...
...
NodeStateProvider nodeStateProvider = this.cloudManager.getNodeStateProvider();
...
Map>> infos = 
nodeStateProvider.getReplicaInfo(node, collTags);
...
  Map tagValues = fetchReplicaMetrics(node, 
metricsKeyVsTagReplica);
  ... 
  fetchReplicaMetrics(node, ctx, collect);
  ...
 rsp = ctx.invoke(solrNode, CommonParams.METRICS_PATH, params);
 ...

public SimpleSolrResponse invoke(String solrNode, String path, SolrParams 
params)
  throws IOException, SolrServerException {
String url = 
zkClientClusterStateProvider.getZkStateReader().getBaseUrlForNodeName(solrNode);

GenericSolrRequest request = new 
GenericSolrRequest(SolrRequest.METHOD.POST, path, params);
try (HttpSolrClient client = new HttpSolrClient.Builder()
.withHttpClient(solrClient.getHttpClient())
.withBaseSolrUrl(url)
.withResponseParser(new BinaryResponseParser())
.build()) {
  NamedList rsp = client.request(request);
  request.response.nl = rsp;
  return request.response;
}
  }

}

{code}
 

 

> 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 

[jira] [Comment Edited] (SOLR-13312) write out responses without creating SolrDocument objects

[Noble Paul (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796466#comment-16796466
 ] 

Noble Paul edited comment on SOLR-13312 at 3/19/19 8:20 PM:


bq. By Transformer, you mean DocumentTransformer (e.g. fl=id,name,score,[shard] 
to add the shard info)?

Well, the problem is that we have the DocTransformers working on a concrete 
class called {{SolrDocument}} .
We can provide a new sub-class of {{SolrDocument}} that is backed by a reusable 
{{byte[]}} . So, even the existing transformers can work without a problem. 

bq. When you say "write it out" do you mean directly generating 
JSON/XML/javabin? I think javabin would requrie creating a SolrDocument If not, 
the client side changes too.

No. the output format remains same. There will be zero changes. So, even an 
older client should have no problem in communicating with a new Solr 

bq. but I it seems that javabin is shipping a serialized SolrDocument...

Javabin is a serialization/deserialization format. it is very well possible to 
construct that format without creating an Object.



was (Author: noble.paul):
bq. By Transformer, you mean DocumentTransformer (e.g. fl=id,name,score,[shard] 
to add the shard info)?

Well, the problem is that we have the DocTransformers working on a concrete 
class called {{SolrDocument}} . We should be able to make transformers work on 
an interface. So , any DocTransformer which implements the new interface can 
possibly work. The most common ones that we ship today can cut over to the 
interface.

bq. When you say "write it out" do you mean directly generating 
JSON/XML/javabin? I think javabin would requrie creating a SolrDocument If not, 
the client side changes too.

No. the output format remains same. There will be zero changes. So, even an 
older client should have no problem in communicating with a new Solr 

bq. but I it seems that javabin is shipping a serialized SolrDocument...

Javabin is a serialization/deserialization format. it is very well possible to 
construct that format without creating an Object.


> write out responses without creating SolrDocument objects
> -
>
> Key: SOLR-13312
> URL: https://issues.apache.org/jira/browse/SOLR-13312
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Priority: Major
>
> Once we get a document from lucene there is no need to create a SolrDocument 
> object to write out the response, if there are no transformers



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

[Kevin Risden (JIRA)]

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



--
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] risdenk opened a new pull request #612: SOLR-13335: Upgrade to velocity 2.0 and velocity-tools 3.0

[GitBox]

risdenk opened a new pull request #612: SOLR-13335: Upgrade to velocity 2.0 and 
velocity-tools 3.0
URL: https://github.com/apache/lucene-solr/pull/612
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13289) Support for BlockMax WAND

[Noble Paul (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796478#comment-16796478
 ] 

Noble Paul commented on SOLR-13289:
---

bq.We can let the user specify this limit (as in this patch via "minExactHits") 
or,

or is it {{maxExactHits}}? I mean this is the maximum no:of exact hits you may 
see . beyond this you get {{null}}

Anyway this is a better option

> Support for BlockMax WAND
> -
>
> Key: SOLR-13289
> URL: https://issues.apache.org/jira/browse/SOLR-13289
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Attachments: SOLR-13289.patch
>
>
> LUCENE-8135 introduced BlockMax WAND as a major speed improvement. Need to 
> expose this via Solr. When enabled, the numFound returned will not be exact.



--
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-8616) Maven build: Simplify the way transitive dependency resolution is disabled, and increase the minimum supported Maven from 2.2.1 to 3.2.1

[Kevin Risden (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796476#comment-16796476
 ] 

Kevin Risden commented on LUCENE-8616:
--

[~steve_rowe] anymore progress on this? What else is left?

> Maven build: Simplify the way transitive dependency resolution is disabled, 
> and increase the minimum supported Maven from 2.2.1 to 3.2.1
> 
>
> Key: LUCENE-8616
> URL: https://issues.apache.org/jira/browse/LUCENE-8616
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: LUCENE-8616.patch
>
>
> Right now the Maven build disables transitive dependency resolution for all 
> dependencies by listing each dependency's dependencies in a nested 
> {{}} section in the grandparent POM's {{}} 
> section. 
> As of Maven 3.2.1, it's possible to use a wildcard syntax in nested 
> {{}} sections to exclude all transitive deps: MNG-2315. This 
> would make the grandparent POM much smaller and make the intent much clearer.
> We would have to increase our minimum supported Maven (currently 2.2.1), but 
> that seems reasonable, given that Maven 2.x has been EOL'd: 
> https://maven.apache.org/maven-2.x-eol.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13312) write out responses without creating SolrDocument objects

[Noble Paul (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796466#comment-16796466
 ] 

Noble Paul commented on SOLR-13312:
---

bq. By Transformer, you mean DocumentTransformer (e.g. fl=id,name,score,[shard] 
to add the shard info)?

Well, the problem is that we have the DocTransformers working on a concrete 
class called {{SolrDocument}} . We should be able to make transformers work on 
an interface. So , any DocTransformer which implements the new interface can 
possibly work. The most common ones that we ship today can cut over to the 
interface.

bq. When you say "write it out" do you mean directly generating 
JSON/XML/javabin? I think javabin would requrie creating a SolrDocument If not, 
the client side changes too.

No. the output format remains same. There will be zero changes. So, even an 
older client should have no problem in communicating with a new Solr 

bq. but I it seems that javabin is shipping a serialized SolrDocument...

Javabin is a serialization/deserialization format. it is very well possible to 
construct that format without creating an Object.


> write out responses without creating SolrDocument objects
> -
>
> Key: SOLR-13312
> URL: https://issues.apache.org/jira/browse/SOLR-13312
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Priority: Major
>
> Once we get a document from lucene there is no need to create a SolrDocument 
> object to write out the response, if there are no transformers



--
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-9079) Remove commons-lang as a dependency

[Kevin Risden (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-9079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kevin Risden updated SOLR-9079:
---
Attachment: SOLR-9079.patch

> Remove commons-lang as a dependency
> ---
>
> Key: SOLR-9079
> URL: https://issues.apache.org/jira/browse/SOLR-9079
> Project: Solr
>  Issue Type: Improvement
>Reporter: Christine Poerschke
>Assignee: Kevin Risden
>Priority: Minor
> Fix For: 8.1, master (9.0)
>
> Attachments: SOLR-9079.patch, SOLR-9079.patch
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Current version used is [/commons-lang/commons-lang = 
> 2.6|https://github.com/apache/lucene-solr/blob/master/lucene/ivy-versions.properties#L68]
>  and a key motivation would be to have 
> [commons.lang3|http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/package-summary.html]
>  APIs available e.g. 
> [org.apache.commons.lang3.tuple.Pair|http://commons.apache.org/proper/commons-lang/apidocs/index.html?org/apache/commons/lang3/tuple/Pair.html]
>  as an alternative to 
> [org.apache.solr.common.util.Pair|https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/Pair.java]
>  variant.
> [This|http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e]
>  dev list posting reports on exploring use of 3.4 instead of 2.6 and 
> concludes with the discovery of an optional zookeeper dependency on 
> commons-lang-2.4 version.
> So upgrading commons-lang can't happen anytime soon but this ticket here to 
> track motivations and findings so far for future reference.
> selected links into other relevant dev list threads:
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CA9C1B04B-EA67-4F2F-A9F3-B24A2AFB8598%40gmail.com%3E
> *  
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdSrZXDJk7VwuVzxDeqdocagS33Fx%2BstYD3yTx5--WXiA%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdWmCDSzXV40-wz1sr766GSwONGFem7UutkdXnsy0%2BXrg%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13335) Upgrade to velocity 2.0 and velocity-tools 3.0

[Kevin Risden (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796465#comment-16796465
 ] 

Kevin Risden commented on SOLR-13335:
-

Need to make sure reference guide configs get updated too if we upgrade 
velocity.

> 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)
>
>
> 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



--
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-8.x-Windows (64bit/jdk-9.0.4) - Build # 120 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/120/
Java: 64bit/jdk-9.0.4 -XX:+UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.cloud.OverseerRolesTest.testOverseerRole

Error Message:
Timed out waiting for overseer state change

Stack Trace:
java.lang.AssertionError: Timed out waiting for overseer state change
at 
__randomizedtesting.SeedInfo.seed([966F62D530392A24:77A49F410B8A1CF5]:0)
at org.junit.Assert.fail(Assert.java:88)
at 
org.apache.solr.cloud.OverseerRolesTest.waitForNewOverseer(OverseerRolesTest.java:63)
at 
org.apache.solr.cloud.OverseerRolesTest.testOverseerRole(OverseerRolesTest.java:145)
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 
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:844)




Build Log:
[...truncated 12858 lines...]
   [junit4] Suite: org.apache.solr.cloud.OverseerRolesTest
   [junit4]   2> 150847 INFO  
(SUITE-OverseerRolesTest-seed#[966F62D530392A24]-worker) [] 
o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: 

[jira] [Commented] (SOLR-12860) MetricsHistoryHandler does not work with BasicAuth

[Lorenzo (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796463#comment-16796463
 ] 

Lorenzo commented on SOLR-12860:


Just for info while I investigate

 
{code:java}
MetricsHistoryHandler.collectGlobalMetrics()...
...
NodeStateProvider nodeStateProvider = this.cloudManager.getNodeStateProvider();
...
Map>> infos = 
nodeStateProvider.getReplicaInfo(node, collTags);
...
  Map tagValues = fetchReplicaMetrics(node, 
metricsKeyVsTagReplica);
  ... 
  fetchReplicaMetrics(node, ctx, collect);
  ...
 rsp = ctx.invoke(solrNode, CommonParams.METRICS_PATH, params);
 ...

public SimpleSolrResponse invoke(String solrNode, String path, SolrParams 
params)
  throws IOException, SolrServerException {
String url = 
zkClientClusterStateProvider.getZkStateReader().getBaseUrlForNodeName(solrNode);

GenericSolrRequest request = new 
GenericSolrRequest(SolrRequest.METHOD.POST, path, params);
try (HttpSolrClient client = new HttpSolrClient.Builder()
.withHttpClient(solrClient.getHttpClient())
.withBaseSolrUrl(url)
.withResponseParser(new BinaryResponseParser())
.build()) {
  NamedList rsp = client.request(request);
  request.response.nl = rsp;
  return request.response;
}
  }

}

{code}
 

 

> 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)
>  

[jira] [Commented] (SOLR-13312) write out responses without creating SolrDocument objects

[Gus Heck (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796454#comment-16796454
 ] 

Gus Heck commented on SOLR-13312:
-

By Transformer, you mean DocumentTransformer (e.g. fl=id,name,score,[shard] to 
add the shard info)? So most vanilla query use cases don't use those, including 
those underpinning streaming expression searches? When you say "write it out" 
do you mean directly generating JSON/XML/javabin? I think javabin would requrie 
creating a SolrDocument If not, the client side changes too... (though perhaps 
shipping the SolrDocument creation load to the solrj client will be of benefit)

I'm not an expert on the codec having never had cause to work with it directly, 
but I it seems that javabin is shipping a serialized SolrDocument 
(org.apache.solr.common.util.JavaBinCodec#readSolrDocument). If the binary wire 
format changes you probably are proposing javabin2? (or lucenebin?) in that 
case it becomes slightly confusing since adding ,[shard] could require the wt 
param to change. 

Perhaps I'm entirely misinterpreting what you said. A patch would probably 
clarify. I'm not for or against this yet, but the description seems short.

> write out responses without creating SolrDocument objects
> -
>
> Key: SOLR-13312
> URL: https://issues.apache.org/jira/browse/SOLR-13312
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Priority: Major
>
> Once we get a document from lucene there is no need to create a SolrDocument 
> object to write out the response, if there are no transformers



--
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 # 1796 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1796/

3 tests failed.
FAILED:  
org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitWithChaosMonkey

Error Message:
Address already in use

Stack Trace:
java.net.BindException: Address already in use
at 
__randomizedtesting.SeedInfo.seed([6043C2AAC80AFA2D:EB64117B890C51A9]:0)
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:433)
at sun.nio.ch.Net.bind(Net.java:425)
at 
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at 
org.eclipse.jetty.server.ServerConnector.openAcceptChannel(ServerConnector.java:342)
at 
org.eclipse.jetty.server.ServerConnector.open(ServerConnector.java:308)
at 
org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:80)
at 
org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:236)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.server.Server.doStart(Server.java:394)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at 
org.apache.solr.client.solrj.embedded.JettySolrRunner.retryOnPortBindFailure(JettySolrRunner.java:558)
at 
org.apache.solr.client.solrj.embedded.JettySolrRunner.start(JettySolrRunner.java:497)
at 
org.apache.solr.client.solrj.embedded.JettySolrRunner.start(JettySolrRunner.java:465)
at 
org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitWithChaosMonkey(ShardSplitTest.java:499)
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 

[jira] [Commented] (SOLR-12860) MetricsHistoryHandler does not work with BasicAuth

[Lorenzo (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796449#comment-16796449
 ] 

Lorenzo commented on SOLR-12860:


The same is happening here with BasiAuthPlugin Sor 7.7.0

 
{code:java}
/security.json
"authentication":{
   "blockUnknown":true,
   "class":"solr.BasicAuthPlugin", ...
{code}
 

 

> 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] [Assigned] (SOLR-12809) Upgrading to a more recent Java (JDK 11?)

[Erick Erickson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erick Erickson reassigned SOLR-12809:
-

Assignee: Erick Erickson

> Upgrading to a more recent Java (JDK 11?)
> -
>
> Key: SOLR-12809
> URL: https://issues.apache.org/jira/browse/SOLR-12809
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> JDK 8 will be EOL early next year (except for "premier support"). JDK 9, 10 
> and 11 all have issues for Solr and Lucene IIUC.
> Also IIUC Oracle will start requiring commercial licenses for 11.
> This Jira is to discuss what we want to do going forward. Among the topics:
>  * Skip straight to 11, skipping 9 and 10? If so how to resolve current 
> issues?
>  * How much emphasis on OpenJDK .vs. Oracle's version
>  * What to do about dependencies that don't work (for whatever reason) with 
> the version of Java we go with?
>  * ???
> This may turn into an umbrella Jira with sub-tasks of course. Since JDK 11 
> has had a GA release, I'd also like to have a record of where the current 
> issues are to refer people to.



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

[Kevin Risden (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796433#comment-16796433
 ] 

Kevin Risden commented on SOLR-13335:
-

Upgrading velocity will remove commons-lang as a dependency requirement.

> 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)
>
>
> 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



--
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-9079) Remove commons-lang as a dependency

[Kevin Risden (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796432#comment-16796432
 ] 

Kevin Risden commented on SOLR-9079:


created SOLR-13335 to upgrade velocity. Will leave the commons-lang dependency 
only in velocity contrib for now.

> Remove commons-lang as a dependency
> ---
>
> Key: SOLR-9079
> URL: https://issues.apache.org/jira/browse/SOLR-9079
> Project: Solr
>  Issue Type: Improvement
>Reporter: Christine Poerschke
>Assignee: Kevin Risden
>Priority: Minor
> Fix For: 8.1, master (9.0)
>
> Attachments: SOLR-9079.patch
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Current version used is [/commons-lang/commons-lang = 
> 2.6|https://github.com/apache/lucene-solr/blob/master/lucene/ivy-versions.properties#L68]
>  and a key motivation would be to have 
> [commons.lang3|http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/package-summary.html]
>  APIs available e.g. 
> [org.apache.commons.lang3.tuple.Pair|http://commons.apache.org/proper/commons-lang/apidocs/index.html?org/apache/commons/lang3/tuple/Pair.html]
>  as an alternative to 
> [org.apache.solr.common.util.Pair|https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/Pair.java]
>  variant.
> [This|http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e]
>  dev list posting reports on exploring use of 3.4 instead of 2.6 and 
> concludes with the discovery of an optional zookeeper dependency on 
> commons-lang-2.4 version.
> So upgrading commons-lang can't happen anytime soon but this ticket here to 
> track motivations and findings so far for future reference.
> selected links into other relevant dev list threads:
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CA9C1B04B-EA67-4F2F-A9F3-B24A2AFB8598%40gmail.com%3E
> *  
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdSrZXDJk7VwuVzxDeqdocagS33Fx%2BstYD3yTx5--WXiA%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdWmCDSzXV40-wz1sr766GSwONGFem7UutkdXnsy0%2BXrg%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [VOTE] Master/9.0 to require Java 11

[Alan Woodward]

+1

> On 19 Mar 2019, at 18:22, Adrien Grand  wrote:
> 
> Hello,
> 
> Now that Lucene/Solr 8.0 has shipped I'd like us to consider requiring
> Java 11 for 9.0, currently the master branch. We had 18 months between
> 7.0 and 8.0, so if we assume a similar interval between 8.0 and 9.0
> that would mean releasing 9.0 about 2 years after Java 11, which
> sounds like a conservative requirement to me.
> 
> What do you think?
> 
> Here is my +1.
> 
> -- 
> Adrien
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


-
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

[Kevin Risden (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796427#comment-16796427
 ] 

Kevin Risden commented on SOLR-13335:
-

upgraded velocity and velocity tools and checked 
https://lucene.apache.org/solr/guide/7_6/velocity-search-ui.html UI looked the 
same as with Solr 8.0.0.

> 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)
>
>
> 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



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re:SOLR-13240.patch

[Christine Poerschke (BLOOMBERG/ LONDON)]

Hi Richard,

welcome! May i suggest to attach the patch directly to the 
https://issues.apache.org/jira/browse/SOLR-13240 ticket? And, optionally, in 
case you haven't come across it yet, 
https://wiki.apache.org/solr/HowToContribute has more general information.

Thanks,
Christine

From: dev@lucene.apache.org At: 03/19/19 15:00:34To:  dev@lucene.apache.org
Subject: SOLR-13240.patch

Hi there,

I've commented on this ticket before witnessing the same kind of exception 
being thrown when using the Solr autoscaling api. I've got a patch that I have 
tested on my own local 5 box cluster, and no longer get the exception (as well 
as supplying a new unit test case). This is my first contirbution to Solr, so 
sorry if I haven't got the patch submission format properly.


-- 

Richard Goodman|Data Infrastructure Engineer
richa...@brandwatch.com


NEW YORK   |   BOSTON   |   BRIGHTON   |   LONDON   |   BERLIN   |   STUTTGART  
 |   SINGAPORE   |   SYDNEY   |   PARIS


 -
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org  



SOLR-13240.patch
Description: Binary data

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-13335) Upgrade to velocity 2.0 and velocity-tools 3.0

[Kevin Risden (JIRA)]

Kevin Risden created SOLR-13335:
---

 Summary: 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
 Fix For: 8.1, master (9.0)


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



--
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-9075) Look at using hdfs-client jar for smaller core dependency

[Kevin Risden (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796418#comment-16796418
 ] 

Kevin Risden commented on SOLR-9075:


FWIW checked 7.7 vs 8.0 - hadoop jars take up 2MB less with hadoop-hdfs-client 
(11MB vs 9MB). However the overall distribution size went up due to added 
dependencies outside of Hadoop related jars (http2 and jetty). 75 vs 88

> Look at using hdfs-client jar for smaller core dependency
> -
>
> Key: SOLR-9075
> URL: https://issues.apache.org/jira/browse/SOLR-9075
> Project: Solr
>  Issue Type: Improvement
>  Components: Hadoop Integration, hdfs
>Reporter: Mark Miller
>Priority: Major
>




--
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-8731) mark MultiTermAwareComponent as deprecated (7.x and 7.7 only)

[Christine Poerschke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christine Poerschke updated LUCENE-8731:

Attachment: LUCENE-8731.patch

> 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] (LUCENE-8731) mark MultiTermAwareComponent as deprecated (7.x and 7.7 only)

[Christine Poerschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796416#comment-16796416
 ] 

Christine Poerschke commented on LUCENE-8731:
-

bq. Let's use the "@Deprecated" annotation on the class in addition to the 
javadoc tag?

Good idea, will do. I'd also wondered about an {{@until}} javadoc equivalent to 
{{@since}} but that didn't seem to work.

> 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
>
>
> {{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] (LUCENE-8731) mark MultiTermAwareComponent as deprecated (7.x and 7.7 only)

[Adrien Grand (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796413#comment-16796413
 ] 

Adrien Grand commented on LUCENE-8731:
--

Let's use the "@Deprecated" annotation on the class in addition to the javadoc 
tag?

> 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
>
>
> {{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] [Updated] (LUCENE-8731) mark MultiTermAwareComponent as deprecated (7.x and 7.7 only)

[Christine Poerschke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christine Poerschke updated LUCENE-8731:

Attachment: LUCENE-8731.patch

> 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
>
>
> {{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] [Created] (LUCENE-8731) mark MultiTermAwareComponent as deprecated (7.x and 7.7 only)

[Christine Poerschke (JIRA)]

Christine Poerschke created LUCENE-8731:
---

 Summary: 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
 Fix For: 7.7.2


{{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] [Updated] (LUCENE-8729) Java 13: Fix Javadocs (accessibility) issues

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated LUCENE-8729:
--
Summary: Java 13: Fix Javadocs (accessibility) issues  (was: Java 13: Fix 
Javadocs issues)

> Java 13: Fix Javadocs (accessibility) issues
> 
>
> Key: LUCENE-8729
> URL: https://issues.apache.org/jira/browse/LUCENE-8729
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Reporter: Uwe Schindler
>Priority: Major
> Attachments: LUCENE-8729-workaround.patch
>
>
> On Policeman Jenkins I isntalled a preview release of JDK 13. The Oracle 
> supplied one does not yet have the issue, but nightly builds of Alexej 
> Shipilev contain a patch that does additional check on Javadocs comments when 
> doclint is enabled, so the next OpenJDK builds of Oracle will likely have the 
> same issue. It fails already in "javac". The output is: 
> https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/275/consoleText
> Problem is HTML headings (like "H1" inside javadocs comments clashing with 
> "H1" generated by Javadoc output, or "H3" without "H2"), in JDK-11 there is 
> already a comment in the Javadocs spec 
> (https://docs.oracle.com/en/java/javase/11/docs/specs/doc-comment-spec.html, 
> "When writing documentation comments for members, it is best not to use HTML 
> heading tags such as  and , because the standard doclet creates an 
> entire structured document, and these structural tags might interfere with 
> the formatting of the generated document.".
> The error is the following:
> {noformat}
> [mkdir] Created dir: 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/core/classes/java
> [javac] Compiling 868 source files to 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/core/classes/java
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/codecs/blocktree/BlockTreeTermsWriter.java:98:
>  error: heading used out of sequence: , compared to implicit preceding 
> heading: 
> [javac]  * Term Dictionary
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/codecs/lucene80/package-info.java:21:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Apache Lucene - Index File Formats
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/index/PointValues.java:41:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Basic Point Types
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/index/PointValues.java:68:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Geospatial Point Types
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/index/PointValues.java:78:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Advanced usage
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/search/Sort.java:37:
>  error: heading used out of sequence: , compared to implicit preceding 
> heading: 
> [javac]  * Valid Types of Values
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/util/packed/package-info.java:34:
>  error: heading used out of sequence: , compared to implicit preceding 
> heading: 
> [javac]  * In-memory structures
> [javac]^
> [javac] Note: Some input files use or override a deprecated API.
> [javac] Note: Recompile with -Xlint:deprecation for details.
> [javac] 7 errors
> {noformat}
> I think we should fix this and maybe don't use headings at all (as suggested 
> in the Spec), or fix them to be at lease correct. Some hints to issues in 
> latest JDK docs: https://bugs.openjdk.java.net/browse/JDK-8220379
> Not sure about doclint in general, I'l ask on maing lists, how this affects 
> 3rd party code!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8729) Java 13: Fix Javadocs issues

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796377#comment-16796377
 ] 

ASF subversion and git services commented on LUCENE-8729:
-

Commit e5a01e00c9d573f4c092e8be31fe119e7d52454a in lucene-solr's branch 
refs/heads/branch_8_0 from Uwe Schindler
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e5a01e0 ]

LUCENE-8729: Workaround to allow compile under JDK13+

# Conflicts:
#   lucene/CHANGES.txt


> Java 13: Fix Javadocs issues
> 
>
> Key: LUCENE-8729
> URL: https://issues.apache.org/jira/browse/LUCENE-8729
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Reporter: Uwe Schindler
>Priority: Major
> Attachments: LUCENE-8729-workaround.patch
>
>
> On Policeman Jenkins I isntalled a preview release of JDK 13. The Oracle 
> supplied one does not yet have the issue, but nightly builds of Alexej 
> Shipilev contain a patch that does additional check on Javadocs comments when 
> doclint is enabled, so the next OpenJDK builds of Oracle will likely have the 
> same issue. It fails already in "javac". The output is: 
> https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/275/consoleText
> Problem is HTML headings (like "H1" inside javadocs comments clashing with 
> "H1" generated by Javadoc output, or "H3" without "H2"), in JDK-11 there is 
> already a comment in the Javadocs spec 
> (https://docs.oracle.com/en/java/javase/11/docs/specs/doc-comment-spec.html, 
> "When writing documentation comments for members, it is best not to use HTML 
> heading tags such as  and , because the standard doclet creates an 
> entire structured document, and these structural tags might interfere with 
> the formatting of the generated document.".
> The error is the following:
> {noformat}
> [mkdir] Created dir: 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/core/classes/java
> [javac] Compiling 868 source files to 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/core/classes/java
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/codecs/blocktree/BlockTreeTermsWriter.java:98:
>  error: heading used out of sequence: , compared to implicit preceding 
> heading: 
> [javac]  * Term Dictionary
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/codecs/lucene80/package-info.java:21:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Apache Lucene - Index File Formats
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/index/PointValues.java:41:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Basic Point Types
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/index/PointValues.java:68:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Geospatial Point Types
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/index/PointValues.java:78:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Advanced usage
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/search/Sort.java:37:
>  error: heading used out of sequence: , compared to implicit preceding 
> heading: 
> [javac]  * Valid Types of Values
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/util/packed/package-info.java:34:
>  error: heading used out of sequence: , compared to implicit preceding 
> heading: 
> [javac]  * In-memory structures
> [javac]^
> [javac] Note: Some input files use or override a deprecated API.
> [javac] Note: Recompile with -Xlint:deprecation for details.
> [javac] 7 errors
> {noformat}
> I think we should fix this and maybe don't use headings at all (as suggested 
> in the Spec), or fix them to be at lease correct. Some hints to issues in 
> latest JDK docs: https://bugs.openjdk.java.net/browse/JDK-8220379
> Not sure about doclint in general, I'l ask on maing lists, how this affects 
> 3rd party 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

[VOTE] Master/9.0 to require Java 11

[Adrien Grand]

Hello,

Now that Lucene/Solr 8.0 has shipped I'd like us to consider requiring
Java 11 for 9.0, currently the master branch. We had 18 months between
7.0 and 8.0, so if we assume a similar interval between 8.0 and 9.0
that would mean releasing 9.0 about 2 years after Java 11, which
sounds like a conservative requirement to me.

What do you think?

Here is my +1.

-- 
Adrien

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8729) Java 13: Fix Javadocs issues

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796378#comment-16796378
 ] 

Uwe Schindler commented on LUCENE-8729:
---

OK, I leave this issue open, so we get the chance to fix our Javadocs to be 
accessible.

> Java 13: Fix Javadocs issues
> 
>
> Key: LUCENE-8729
> URL: https://issues.apache.org/jira/browse/LUCENE-8729
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Reporter: Uwe Schindler
>Priority: Major
> Attachments: LUCENE-8729-workaround.patch
>
>
> On Policeman Jenkins I isntalled a preview release of JDK 13. The Oracle 
> supplied one does not yet have the issue, but nightly builds of Alexej 
> Shipilev contain a patch that does additional check on Javadocs comments when 
> doclint is enabled, so the next OpenJDK builds of Oracle will likely have the 
> same issue. It fails already in "javac". The output is: 
> https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/275/consoleText
> Problem is HTML headings (like "H1" inside javadocs comments clashing with 
> "H1" generated by Javadoc output, or "H3" without "H2"), in JDK-11 there is 
> already a comment in the Javadocs spec 
> (https://docs.oracle.com/en/java/javase/11/docs/specs/doc-comment-spec.html, 
> "When writing documentation comments for members, it is best not to use HTML 
> heading tags such as  and , because the standard doclet creates an 
> entire structured document, and these structural tags might interfere with 
> the formatting of the generated document.".
> The error is the following:
> {noformat}
> [mkdir] Created dir: 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/core/classes/java
> [javac] Compiling 868 source files to 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/core/classes/java
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/codecs/blocktree/BlockTreeTermsWriter.java:98:
>  error: heading used out of sequence: , compared to implicit preceding 
> heading: 
> [javac]  * Term Dictionary
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/codecs/lucene80/package-info.java:21:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Apache Lucene - Index File Formats
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/index/PointValues.java:41:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Basic Point Types
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/index/PointValues.java:68:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Geospatial Point Types
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/index/PointValues.java:78:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Advanced usage
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/search/Sort.java:37:
>  error: heading used out of sequence: , compared to implicit preceding 
> heading: 
> [javac]  * Valid Types of Values
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/util/packed/package-info.java:34:
>  error: heading used out of sequence: , compared to implicit preceding 
> heading: 
> [javac]  * In-memory structures
> [javac]^
> [javac] Note: Some input files use or override a deprecated API.
> [javac] Note: Recompile with -Xlint:deprecation for details.
> [javac] 7 errors
> {noformat}
> I think we should fix this and maybe don't use headings at all (as suggested 
> in the Spec), or fix them to be at lease correct. Some hints to issues in 
> latest JDK docs: https://bugs.openjdk.java.net/browse/JDK-8220379
> Not sure about doclint in general, I'l ask on maing lists, how this affects 
> 3rd party 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-EA] Lucene-Solr-BadApples-8.x-Linux (64bit/jdk-12-ea+shipilev-fastdebug) - Build # 32 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-8.x-Linux/32/
Java: 64bit/jdk-12-ea+shipilev-fastdebug -XX:+UseCompressedOops 
-XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.metrics.rrd.SolrRrdBackendFactoryTest.testBasic

Error Message:
{} expected:<1> but was:<0>

Stack Trace:
java.lang.AssertionError: {} expected:<1> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([BDB9F83BDFC9E4CC:1643E52E001562E2]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at 
org.apache.solr.metrics.rrd.SolrRrdBackendFactoryTest.testBasic(SolrRrdBackendFactoryTest.java:92)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:835)




Build Log:
[...truncated 14987 lines...]
   [junit4] Suite: org.apache.solr.metrics.rrd.SolrRrdBackendFactoryTest
   [junit4]   2> Creating dataDir: 

[jira] [Commented] (LUCENE-8729) Java 13: Fix Javadocs issues

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796365#comment-16796365
 ] 

ASF subversion and git services commented on LUCENE-8729:
-

Commit c0781e9fc7771b6028f619c836ca79d1b93c998c in lucene-solr's branch 
refs/heads/branch_8x from Uwe Schindler
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c0781e9 ]

LUCENE-8729: Workaround to allow compile under JDK13+


> Java 13: Fix Javadocs issues
> 
>
> Key: LUCENE-8729
> URL: https://issues.apache.org/jira/browse/LUCENE-8729
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Reporter: Uwe Schindler
>Priority: Major
> Attachments: LUCENE-8729-workaround.patch
>
>
> On Policeman Jenkins I isntalled a preview release of JDK 13. The Oracle 
> supplied one does not yet have the issue, but nightly builds of Alexej 
> Shipilev contain a patch that does additional check on Javadocs comments when 
> doclint is enabled, so the next OpenJDK builds of Oracle will likely have the 
> same issue. It fails already in "javac". The output is: 
> https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/275/consoleText
> Problem is HTML headings (like "H1" inside javadocs comments clashing with 
> "H1" generated by Javadoc output, or "H3" without "H2"), in JDK-11 there is 
> already a comment in the Javadocs spec 
> (https://docs.oracle.com/en/java/javase/11/docs/specs/doc-comment-spec.html, 
> "When writing documentation comments for members, it is best not to use HTML 
> heading tags such as  and , because the standard doclet creates an 
> entire structured document, and these structural tags might interfere with 
> the formatting of the generated document.".
> The error is the following:
> {noformat}
> [mkdir] Created dir: 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/core/classes/java
> [javac] Compiling 868 source files to 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/core/classes/java
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/codecs/blocktree/BlockTreeTermsWriter.java:98:
>  error: heading used out of sequence: , compared to implicit preceding 
> heading: 
> [javac]  * Term Dictionary
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/codecs/lucene80/package-info.java:21:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Apache Lucene - Index File Formats
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/index/PointValues.java:41:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Basic Point Types
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/index/PointValues.java:68:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Geospatial Point Types
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/index/PointValues.java:78:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Advanced usage
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/search/Sort.java:37:
>  error: heading used out of sequence: , compared to implicit preceding 
> heading: 
> [javac]  * Valid Types of Values
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/util/packed/package-info.java:34:
>  error: heading used out of sequence: , compared to implicit preceding 
> heading: 
> [javac]  * In-memory structures
> [javac]^
> [javac] Note: Some input files use or override a deprecated API.
> [javac] Note: Recompile with -Xlint:deprecation for details.
> [javac] 7 errors
> {noformat}
> I think we should fix this and maybe don't use headings at all (as suggested 
> in the Spec), or fix them to be at lease correct. Some hints to issues in 
> latest JDK docs: https://bugs.openjdk.java.net/browse/JDK-8220379
> Not sure about doclint in general, I'l ask on maing lists, how this affects 
> 3rd party code!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8729) Java 13: Fix Javadocs issues

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796363#comment-16796363
 ] 

ASF subversion and git services commented on LUCENE-8729:
-

Commit 2a1ed6e4848abc6ab9bce27c170bce28a4c9691c in lucene-solr's branch 
refs/heads/master from Uwe Schindler
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2a1ed6e ]

LUCENE-8729: Workaround to allow compile under JDK13+


> Java 13: Fix Javadocs issues
> 
>
> Key: LUCENE-8729
> URL: https://issues.apache.org/jira/browse/LUCENE-8729
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Reporter: Uwe Schindler
>Priority: Major
> Attachments: LUCENE-8729-workaround.patch
>
>
> On Policeman Jenkins I isntalled a preview release of JDK 13. The Oracle 
> supplied one does not yet have the issue, but nightly builds of Alexej 
> Shipilev contain a patch that does additional check on Javadocs comments when 
> doclint is enabled, so the next OpenJDK builds of Oracle will likely have the 
> same issue. It fails already in "javac". The output is: 
> https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/275/consoleText
> Problem is HTML headings (like "H1" inside javadocs comments clashing with 
> "H1" generated by Javadoc output, or "H3" without "H2"), in JDK-11 there is 
> already a comment in the Javadocs spec 
> (https://docs.oracle.com/en/java/javase/11/docs/specs/doc-comment-spec.html, 
> "When writing documentation comments for members, it is best not to use HTML 
> heading tags such as  and , because the standard doclet creates an 
> entire structured document, and these structural tags might interfere with 
> the formatting of the generated document.".
> The error is the following:
> {noformat}
> [mkdir] Created dir: 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/core/classes/java
> [javac] Compiling 868 source files to 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/core/classes/java
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/codecs/blocktree/BlockTreeTermsWriter.java:98:
>  error: heading used out of sequence: , compared to implicit preceding 
> heading: 
> [javac]  * Term Dictionary
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/codecs/lucene80/package-info.java:21:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Apache Lucene - Index File Formats
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/index/PointValues.java:41:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Basic Point Types
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/index/PointValues.java:68:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Geospatial Point Types
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/index/PointValues.java:78:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Advanced usage
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/search/Sort.java:37:
>  error: heading used out of sequence: , compared to implicit preceding 
> heading: 
> [javac]  * Valid Types of Values
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/util/packed/package-info.java:34:
>  error: heading used out of sequence: , compared to implicit preceding 
> heading: 
> [javac]  * In-memory structures
> [javac]^
> [javac] Note: Some input files use or override a deprecated API.
> [javac] Note: Recompile with -Xlint:deprecation for details.
> [javac] 7 errors
> {noformat}
> I think we should fix this and maybe don't use headings at all (as suggested 
> in the Spec), or fix them to be at lease correct. Some hints to issues in 
> latest JDK docs: https://bugs.openjdk.java.net/browse/JDK-8220379
> Not sure about doclint in general, I'l ask on maing lists, how this affects 
> 3rd party 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-12955) Refactor DistributedUpdateProcessor

[David Smiley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley updated SOLR-12955:

Fix Version/s: 8.1

> Refactor DistributedUpdateProcessor
> ---
>
> Key: SOLR-12955
> URL: https://issues.apache.org/jira/browse/SOLR-12955
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Bar Rotstein
>Assignee: David Smiley
>Priority: Major
> Fix For: 8.1
>
> Attachments: SOLR-12955-no-commit.patch, SOLR-12955.patch, 
> SOLR-12955.patch, SOLR-12955.patch, SOLR-12955.patch
>
>  Time Spent: 9h 50m
>  Remaining Estimate: 0h
>
> Lately As I was skimming through Solr's code base I noticed that 
> DistributedUpdateProcessor has a lot of nested if else statements, which 
> hampers code readability.



--
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-8729) Java 13: Fix Javadocs issues

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796357#comment-16796357
 ] 

Uwe Schindler commented on LUCENE-8729:
---

Here is the workarund patch to allow JDK-13 builds with hotspot fixes to 
succeed:  [^LUCENE-8729-workaround.patch] 

> Java 13: Fix Javadocs issues
> 
>
> Key: LUCENE-8729
> URL: https://issues.apache.org/jira/browse/LUCENE-8729
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Reporter: Uwe Schindler
>Priority: Major
> Attachments: LUCENE-8729-workaround.patch
>
>
> On Policeman Jenkins I isntalled a preview release of JDK 13. The Oracle 
> supplied one does not yet have the issue, but nightly builds of Alexej 
> Shipilev contain a patch that does additional check on Javadocs comments when 
> doclint is enabled, so the next OpenJDK builds of Oracle will likely have the 
> same issue. It fails already in "javac". The output is: 
> https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/275/consoleText
> Problem is HTML headings (like "H1" inside javadocs comments clashing with 
> "H1" generated by Javadoc output, or "H3" without "H2"), in JDK-11 there is 
> already a comment in the Javadocs spec 
> (https://docs.oracle.com/en/java/javase/11/docs/specs/doc-comment-spec.html, 
> "When writing documentation comments for members, it is best not to use HTML 
> heading tags such as  and , because the standard doclet creates an 
> entire structured document, and these structural tags might interfere with 
> the formatting of the generated document.".
> The error is the following:
> {noformat}
> [mkdir] Created dir: 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/core/classes/java
> [javac] Compiling 868 source files to 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/core/classes/java
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/codecs/blocktree/BlockTreeTermsWriter.java:98:
>  error: heading used out of sequence: , compared to implicit preceding 
> heading: 
> [javac]  * Term Dictionary
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/codecs/lucene80/package-info.java:21:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Apache Lucene - Index File Formats
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/index/PointValues.java:41:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Basic Point Types
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/index/PointValues.java:68:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Geospatial Point Types
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/index/PointValues.java:78:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Advanced usage
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/search/Sort.java:37:
>  error: heading used out of sequence: , compared to implicit preceding 
> heading: 
> [javac]  * Valid Types of Values
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/util/packed/package-info.java:34:
>  error: heading used out of sequence: , compared to implicit preceding 
> heading: 
> [javac]  * In-memory structures
> [javac]^
> [javac] Note: Some input files use or override a deprecated API.
> [javac] Note: Recompile with -Xlint:deprecation for details.
> [javac] 7 errors
> {noformat}
> I think we should fix this and maybe don't use headings at all (as suggested 
> in the Spec), or fix them to be at lease correct. Some hints to issues in 
> latest JDK docs: https://bugs.openjdk.java.net/browse/JDK-8220379
> Not sure about doclint in general, I'l ask on maing lists, how this affects 
> 3rd party 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] (LUCENE-8729) Java 13: Fix Javadocs issues

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated LUCENE-8729:
--
Attachment: LUCENE-8729-workaround.patch

> Java 13: Fix Javadocs issues
> 
>
> Key: LUCENE-8729
> URL: https://issues.apache.org/jira/browse/LUCENE-8729
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Reporter: Uwe Schindler
>Priority: Major
> Attachments: LUCENE-8729-workaround.patch
>
>
> On Policeman Jenkins I isntalled a preview release of JDK 13. The Oracle 
> supplied one does not yet have the issue, but nightly builds of Alexej 
> Shipilev contain a patch that does additional check on Javadocs comments when 
> doclint is enabled, so the next OpenJDK builds of Oracle will likely have the 
> same issue. It fails already in "javac". The output is: 
> https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/275/consoleText
> Problem is HTML headings (like "H1" inside javadocs comments clashing with 
> "H1" generated by Javadoc output, or "H3" without "H2"), in JDK-11 there is 
> already a comment in the Javadocs spec 
> (https://docs.oracle.com/en/java/javase/11/docs/specs/doc-comment-spec.html, 
> "When writing documentation comments for members, it is best not to use HTML 
> heading tags such as  and , because the standard doclet creates an 
> entire structured document, and these structural tags might interfere with 
> the formatting of the generated document.".
> The error is the following:
> {noformat}
> [mkdir] Created dir: 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/core/classes/java
> [javac] Compiling 868 source files to 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/core/classes/java
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/codecs/blocktree/BlockTreeTermsWriter.java:98:
>  error: heading used out of sequence: , compared to implicit preceding 
> heading: 
> [javac]  * Term Dictionary
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/codecs/lucene80/package-info.java:21:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Apache Lucene - Index File Formats
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/index/PointValues.java:41:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Basic Point Types
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/index/PointValues.java:68:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Geospatial Point Types
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/index/PointValues.java:78:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Advanced usage
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/search/Sort.java:37:
>  error: heading used out of sequence: , compared to implicit preceding 
> heading: 
> [javac]  * Valid Types of Values
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/util/packed/package-info.java:34:
>  error: heading used out of sequence: , compared to implicit preceding 
> heading: 
> [javac]  * In-memory structures
> [javac]^
> [javac] Note: Some input files use or override a deprecated API.
> [javac] Note: Recompile with -Xlint:deprecation for details.
> [javac] 7 errors
> {noformat}
> I think we should fix this and maybe don't use headings at all (as suggested 
> in the Spec), or fix them to be at lease correct. Some hints to issues in 
> latest JDK docs: https://bugs.openjdk.java.net/browse/JDK-8220379
> Not sure about doclint in general, I'l ask on maing lists, how this affects 
> 3rd party code!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8729) Java 13: Fix Javadocs issues

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796360#comment-16796360
 ] 

Uwe Schindler commented on LUCENE-8729:
---

I will commit the workaround to master, 8.x and 8.0 branches.

> Java 13: Fix Javadocs issues
> 
>
> Key: LUCENE-8729
> URL: https://issues.apache.org/jira/browse/LUCENE-8729
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Reporter: Uwe Schindler
>Priority: Major
> Attachments: LUCENE-8729-workaround.patch
>
>
> On Policeman Jenkins I isntalled a preview release of JDK 13. The Oracle 
> supplied one does not yet have the issue, but nightly builds of Alexej 
> Shipilev contain a patch that does additional check on Javadocs comments when 
> doclint is enabled, so the next OpenJDK builds of Oracle will likely have the 
> same issue. It fails already in "javac". The output is: 
> https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/275/consoleText
> Problem is HTML headings (like "H1" inside javadocs comments clashing with 
> "H1" generated by Javadoc output, or "H3" without "H2"), in JDK-11 there is 
> already a comment in the Javadocs spec 
> (https://docs.oracle.com/en/java/javase/11/docs/specs/doc-comment-spec.html, 
> "When writing documentation comments for members, it is best not to use HTML 
> heading tags such as  and , because the standard doclet creates an 
> entire structured document, and these structural tags might interfere with 
> the formatting of the generated document.".
> The error is the following:
> {noformat}
> [mkdir] Created dir: 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/core/classes/java
> [javac] Compiling 868 source files to 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/core/classes/java
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/codecs/blocktree/BlockTreeTermsWriter.java:98:
>  error: heading used out of sequence: , compared to implicit preceding 
> heading: 
> [javac]  * Term Dictionary
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/codecs/lucene80/package-info.java:21:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Apache Lucene - Index File Formats
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/index/PointValues.java:41:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Basic Point Types
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/index/PointValues.java:68:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Geospatial Point Types
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/index/PointValues.java:78:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Advanced usage
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/search/Sort.java:37:
>  error: heading used out of sequence: , compared to implicit preceding 
> heading: 
> [javac]  * Valid Types of Values
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/util/packed/package-info.java:34:
>  error: heading used out of sequence: , compared to implicit preceding 
> heading: 
> [javac]  * In-memory structures
> [javac]^
> [javac] Note: Some input files use or override a deprecated API.
> [javac] Note: Recompile with -Xlint:deprecation for details.
> [javac] 7 errors
> {noformat}
> I think we should fix this and maybe don't use headings at all (as suggested 
> in the Spec), or fix them to be at lease correct. Some hints to issues in 
> latest JDK docs: https://bugs.openjdk.java.net/browse/JDK-8220379
> Not sure about doclint in general, I'l ask on maing lists, how this affects 
> 3rd party 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-NightlyTests-8.x - Build # 48 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/48/

4 tests failed.
FAILED:  
org.apache.solr.cloud.api.collections.HdfsCollectionsAPIDistributedZkTest.testCollectionsAPI

Error Message:
Failed while waiting for active collection Timeout waiting to see state for 
collection=awhollynewcollection_0 
:DocCollection(awhollynewcollection_0//collections/awhollynewcollection_0/state.json/3)={
   "pullReplicas":"0",   "replicationFactor":"2",   "shards":{ "shard1":{   
"range":"8000-bfff",   "state":"active",   "replicas":{ 
"core_node2":{   "core":"awhollynewcollection_0_shard1_replica_n1", 
  "base_url":"http://127.0.0.1:38795/solr;,   
"node_name":"127.0.0.1:38795_solr",   "state":"down",   
"type":"NRT",   "force_set_state":"false"}, "core_node6":{  
 "core":"awhollynewcollection_0_shard1_replica_n3",   
"base_url":"http://127.0.0.1:33233/solr;,   
"node_name":"127.0.0.1:33233_solr",   "state":"down",   
"type":"NRT",   "force_set_state":"false"}}}, "shard2":{   
"range":"c000-",   "state":"active",   "replicas":{ 
"core_node10":{   "core":"awhollynewcollection_0_shard2_replica_n4",
   "base_url":"http://127.0.0.1:38935/solr;,   
"node_name":"127.0.0.1:38935_solr",   "state":"down",   
"type":"NRT",   "force_set_state":"false"}, "core_node11":{ 
  "core":"awhollynewcollection_0_shard2_replica_n5",   
"base_url":"http://127.0.0.1:33930/solr;,   
"node_name":"127.0.0.1:33930_solr",   "state":"down",   
"type":"NRT",   "force_set_state":"false"}}}, "shard3":{   
"range":"0-3fff",   "state":"active",   "replicas":{ 
"core_node12":{   "core":"awhollynewcollection_0_shard3_replica_n7",
   "base_url":"http://127.0.0.1:38795/solr;,   
"node_name":"127.0.0.1:38795_solr",   "state":"down",   
"type":"NRT",   "force_set_state":"false"}, "core_node13":{ 
  "core":"awhollynewcollection_0_shard3_replica_n8",   
"base_url":"http://127.0.0.1:33233/solr;,   
"node_name":"127.0.0.1:33233_solr",   "state":"down",   
"type":"NRT",   "force_set_state":"false"}}}, "shard4":{   
"range":"4000-7fff",   "state":"active",   "replicas":{ 
"core_node15":{   "core":"awhollynewcollection_0_shard4_replica_n9",
   "base_url":"http://127.0.0.1:38935/solr;,   
"node_name":"127.0.0.1:38935_solr",   "state":"down",   
"type":"NRT",   "force_set_state":"false"}, "core_node16":{ 
  "core":"awhollynewcollection_0_shard4_replica_n14",   
"base_url":"http://127.0.0.1:33930/solr;,   
"node_name":"127.0.0.1:33930_solr",   "state":"down",   
"type":"NRT",   "force_set_state":"false",   
"router":{"name":"compositeId"},   "maxShardsPerNode":"3",   
"autoAddReplicas":"false",   "nrtReplicas":"2",   "tlogReplicas":"0"} Live 
Nodes: [127.0.0.1:33233_solr, 127.0.0.1:33930_solr, 127.0.0.1:38795_solr, 
127.0.0.1:38935_solr] Last available state: 
DocCollection(awhollynewcollection_0//collections/awhollynewcollection_0/state.json/3)={
   "pullReplicas":"0",   "replicationFactor":"2",   "shards":{ "shard1":{   
"range":"8000-bfff",   "state":"active",   "replicas":{ 
"core_node2":{   "core":"awhollynewcollection_0_shard1_replica_n1", 
  "base_url":"http://127.0.0.1:38795/solr;,   
"node_name":"127.0.0.1:38795_solr",   "state":"down",   
"type":"NRT",   "force_set_state":"false"}, "core_node6":{  
 "core":"awhollynewcollection_0_shard1_replica_n3",   
"base_url":"http://127.0.0.1:33233/solr;,   
"node_name":"127.0.0.1:33233_solr",   "state":"down",   
"type":"NRT",   "force_set_state":"false"}}}, "shard2":{   
"range":"c000-",   "state":"active",   "replicas":{ 
"core_node10":{   "core":"awhollynewcollection_0_shard2_replica_n4",
   "base_url":"http://127.0.0.1:38935/solr;,   
"node_name":"127.0.0.1:38935_solr",   "state":"down",   
"type":"NRT",   "force_set_state":"false"}, "core_node11":{ 
  "core":"awhollynewcollection_0_shard2_replica_n5",   
"base_url":"http://127.0.0.1:33930/solr;,   
"node_name":"127.0.0.1:33930_solr",   "state":"down",   
"type":"NRT",   "force_set_state":"false"}}}, "shard3":{   
"range":"0-3fff",   "state":"active",   "replicas":{ 
"core_node12":{   "core":"awhollynewcollection_0_shard3_replica_n7",
   "base_url":"http://127.0.0.1:38795/solr;,   

[jira] [Commented] (LUCENE-8729) Java 13: Fix Javadocs issues

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796348#comment-16796348
 ] 

Uwe Schindler commented on LUCENE-8729:
---

I got a response by Jonathan Gibbons 
(https://mail.openjdk.java.net/pipermail/javadoc-dev/2019-March/000977.html):

bq. ...and you can refine the set of checks that are applied. The checks on the 
 headings are covered by the "accessibility" group.  If you wish to disable the 
accessibility checks, you can use -Xdoclint:-accessibility. 

I will change the doclint settings to disable "accessibility" for now.

> Java 13: Fix Javadocs issues
> 
>
> Key: LUCENE-8729
> URL: https://issues.apache.org/jira/browse/LUCENE-8729
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Reporter: Uwe Schindler
>Priority: Major
>
> On Policeman Jenkins I isntalled a preview release of JDK 13. The Oracle 
> supplied one does not yet have the issue, but nightly builds of Alexej 
> Shipilev contain a patch that does additional check on Javadocs comments when 
> doclint is enabled, so the next OpenJDK builds of Oracle will likely have the 
> same issue. It fails already in "javac". The output is: 
> https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/275/consoleText
> Problem is HTML headings (like "H1" inside javadocs comments clashing with 
> "H1" generated by Javadoc output, or "H3" without "H2"), in JDK-11 there is 
> already a comment in the Javadocs spec 
> (https://docs.oracle.com/en/java/javase/11/docs/specs/doc-comment-spec.html, 
> "When writing documentation comments for members, it is best not to use HTML 
> heading tags such as  and , because the standard doclet creates an 
> entire structured document, and these structural tags might interfere with 
> the formatting of the generated document.".
> The error is the following:
> {noformat}
> [mkdir] Created dir: 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/core/classes/java
> [javac] Compiling 868 source files to 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/core/classes/java
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/codecs/blocktree/BlockTreeTermsWriter.java:98:
>  error: heading used out of sequence: , compared to implicit preceding 
> heading: 
> [javac]  * Term Dictionary
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/codecs/lucene80/package-info.java:21:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Apache Lucene - Index File Formats
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/index/PointValues.java:41:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Basic Point Types
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/index/PointValues.java:68:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Geospatial Point Types
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/index/PointValues.java:78:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [javac]  * Advanced usage
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/search/Sort.java:37:
>  error: heading used out of sequence: , compared to implicit preceding 
> heading: 
> [javac]  * Valid Types of Values
> [javac]^
> [javac] 
> /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/core/src/java/org/apache/lucene/util/packed/package-info.java:34:
>  error: heading used out of sequence: , compared to implicit preceding 
> heading: 
> [javac]  * In-memory structures
> [javac]^
> [javac] Note: Some input files use or override a deprecated API.
> [javac] Note: Recompile with -Xlint:deprecation for details.
> [javac] 7 errors
> {noformat}
> I think we should fix this and maybe don't use headings at all (as suggested 
> in the Spec), or fix them to be at lease correct. Some hints to issues in 
> latest JDK docs: https://bugs.openjdk.java.net/browse/JDK-8220379
> Not sure about doclint in general, I'l ask on maing lists, how this affects 
> 3rd party 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-13253) SolrResourceLoader of an IndexSchema should only be used for building the schema stuff

[David Smiley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley reassigned SOLR-13253:
---

   Resolution: Fixed
 Assignee: David Smiley
Fix Version/s: 8.1

> SolrResourceLoader of an IndexSchema should only be used for building the 
> schema stuff
> --
>
> Key: SOLR-13253
> URL: https://issues.apache.org/jira/browse/SOLR-13253
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 8.1
>
> Attachments: SOLR-13253.patch
>
>
> The IndexSchema has a SolrResourceLoader that's taken from a SolrConfig in 
> its constructor.  If this IndexSchema gets re-used across Solr cores (via 
> "shareSchema" being true in solr.xml), and if this resourceLoader is used in 
> the future from a core that differs from the core the schema was created 
> from, bad things can happen (like a memory leak in 
> SolrResourceLoader.waitingForResources).  The resourceLoader here is only 
> actually needed to help create the schema stuff, like analyzers.  Once it's 
> done, it isn't needed anymore. However our Solr code base is using this in 
> other places that are not appropriate.  It's a subtle problem as there's a 
> confluence of circumstances that need to occur to trigger 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-13253) SolrResourceLoader of an IndexSchema should only be used for building the schema stuff

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796343#comment-16796343
 ] 

ASF subversion and git services commented on SOLR-13253:


Commit 85a702cdff23a6352945dd78eb54ff6db68f6965 in lucene-solr's branch 
refs/heads/master from David Wayne Smiley
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=85a702c ]

SOLR-13253: avoid using IndexSchema.getResourceLoader for non-schema things.
Furthermore it's reference to SolrConfig was removed.


> SolrResourceLoader of an IndexSchema should only be used for building the 
> schema stuff
> --
>
> Key: SOLR-13253
> URL: https://issues.apache.org/jira/browse/SOLR-13253
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: David Smiley
>Priority: Minor
> Attachments: SOLR-13253.patch
>
>
> The IndexSchema has a SolrResourceLoader that's taken from a SolrConfig in 
> its constructor.  If this IndexSchema gets re-used across Solr cores (via 
> "shareSchema" being true in solr.xml), and if this resourceLoader is used in 
> the future from a core that differs from the core the schema was created 
> from, bad things can happen (like a memory leak in 
> SolrResourceLoader.waitingForResources).  The resourceLoader here is only 
> actually needed to help create the schema stuff, like analyzers.  Once it's 
> done, it isn't needed anymore. However our Solr code base is using this in 
> other places that are not appropriate.  It's a subtle problem as there's a 
> confluence of circumstances that need to occur to trigger 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-13253) SolrResourceLoader of an IndexSchema should only be used for building the schema stuff

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796346#comment-16796346
 ] 

ASF subversion and git services commented on SOLR-13253:


Commit 8f25ded16f190de22f0d0816e12cf2a40eb19a83 in lucene-solr's branch 
refs/heads/branch_8x from David Wayne Smiley
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8f25ded ]

SOLR-13253: avoid using IndexSchema.getResourceLoader for non-schema things.
Furthermore it's reference to SolrConfig was removed.

(cherry picked from commit 85a702cdff23a6352945dd78eb54ff6db68f6965)


> SolrResourceLoader of an IndexSchema should only be used for building the 
> schema stuff
> --
>
> Key: SOLR-13253
> URL: https://issues.apache.org/jira/browse/SOLR-13253
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: David Smiley
>Priority: Minor
> Attachments: SOLR-13253.patch
>
>
> The IndexSchema has a SolrResourceLoader that's taken from a SolrConfig in 
> its constructor.  If this IndexSchema gets re-used across Solr cores (via 
> "shareSchema" being true in solr.xml), and if this resourceLoader is used in 
> the future from a core that differs from the core the schema was created 
> from, bad things can happen (like a memory leak in 
> SolrResourceLoader.waitingForResources).  The resourceLoader here is only 
> actually needed to help create the schema stuff, like analyzers.  Once it's 
> done, it isn't needed anymore. However our Solr code base is using this in 
> other places that are not appropriate.  It's a subtle problem as there's a 
> confluence of circumstances that need to occur to trigger 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] [Resolved] (SOLR-9075) Look at using hdfs-client jar for smaller core dependency

[Kevin Risden (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-9075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kevin Risden resolved SOLR-9075.

Resolution: Fixed

hadoop-hdfs-client was used during the upgrade to Hadoop 3 in SOLR-9515

> Look at using hdfs-client jar for smaller core dependency
> -
>
> Key: SOLR-9075
> URL: https://issues.apache.org/jira/browse/SOLR-9075
> Project: Solr
>  Issue Type: Improvement
>  Components: Hadoop Integration, hdfs
>Reporter: Mark Miller
>Priority: Major
>




--
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] [Closed] (SOLR-9075) Look at using hdfs-client jar for smaller core dependency

[Kevin Risden (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-9075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kevin Risden closed SOLR-9075.
--

> Look at using hdfs-client jar for smaller core dependency
> -
>
> Key: SOLR-9075
> URL: https://issues.apache.org/jira/browse/SOLR-9075
> Project: Solr
>  Issue Type: Improvement
>  Components: Hadoop Integration, hdfs
>Reporter: Mark Miller
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] jpountz commented on a change in pull request #610: LUCENE-8671: Load FST off-heap if reader is not opened from an index writer

[GitBox]

jpountz commented on a change in pull request #610: LUCENE-8671: Load FST 
off-heap if reader is not opened from an index writer
URL: https://github.com/apache/lucene-solr/pull/610#discussion_r267016239
 
 

 ##
 File path: 
lucene/core/src/java/org/apache/lucene/codecs/blocktree/FieldReader.java
 ##
 @@ -91,7 +92,8 @@
   clone.seek(indexStartFP);
   // Initialize FST offheap if index is MMapDirectory and
   // docCount != sumDocFreq implying field is not primary key
-  if (clone instanceof ByteBufferIndexInput && this.docCount != 
this.sumDocFreq) {
+  isFSTOffHeap = clone instanceof ByteBufferIndexInput && ((this.docCount 
!= this.sumDocFreq) || openedFromWriter == false);
 
 Review comment:
   I guess some users need fast lookups on read-only indices, but this proposal 
looks like a good default to me.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12955) Refactor DistributedUpdateProcessor

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796312#comment-16796312
 ] 

ASF subversion and git services commented on SOLR-12955:


Commit de58717183d0690254daa56d7dad7692bb435c4a in lucene-solr's branch 
refs/heads/branch_8x from Bar Rotstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=de58717 ]

SOLR-12955: Refactored DistributedUpdateProcessor to put SolrCloud specifics 
into a subclass
Closes #528

(cherry picked from commit 5b7866b0851eff66cb7e929beef5249e3c72ac36)


> Refactor DistributedUpdateProcessor
> ---
>
> Key: SOLR-12955
> URL: https://issues.apache.org/jira/browse/SOLR-12955
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Bar Rotstein
>Assignee: David Smiley
>Priority: Major
> Attachments: SOLR-12955-no-commit.patch, SOLR-12955.patch, 
> SOLR-12955.patch, SOLR-12955.patch, SOLR-12955.patch
>
>  Time Spent: 9h 50m
>  Remaining Estimate: 0h
>
> Lately As I was skimming through Solr's code base I noticed that 
> DistributedUpdateProcessor has a lot of nested if else statements, which 
> hampers code readability.



--
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] asfgit closed pull request #528: SOLR-12955 2

[GitBox]

asfgit closed pull request #528: SOLR-12955 2
URL: https://github.com/apache/lucene-solr/pull/528
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12955) Refactor DistributedUpdateProcessor

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796310#comment-16796310
 ] 

ASF subversion and git services commented on SOLR-12955:


Commit 5b7866b0851eff66cb7e929beef5249e3c72ac36 in lucene-solr's branch 
refs/heads/master from Bar Rotstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=5b7866b ]

SOLR-12955: Refactored DistributedUpdateProcessor to put SolrCloud specifics 
into a subclass
Closes #528


> Refactor DistributedUpdateProcessor
> ---
>
> Key: SOLR-12955
> URL: https://issues.apache.org/jira/browse/SOLR-12955
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Bar Rotstein
>Assignee: David Smiley
>Priority: Major
> Attachments: SOLR-12955-no-commit.patch, SOLR-12955.patch, 
> SOLR-12955.patch, SOLR-12955.patch, SOLR-12955.patch
>
>  Time Spent: 9h 40m
>  Remaining Estimate: 0h
>
> Lately As I was skimming through Solr's code base I noticed that 
> DistributedUpdateProcessor has a lot of nested if else statements, which 
> hampers code readability.



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

autoGeneratePhraseQuery throws an error when added to a definition

[Erick Erickson]

Is this intended or should I create a JIRA?

If I put autoGeneratePhraseQuery on a , it works just fine. But 
putting it on a  generates an error on core load. Is this intentional?

If not I’ll raise a JIRA.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9079) Remove commons-lang as a dependency

[Kevin Risden (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796286#comment-16796286
 ] 

Kevin Risden commented on SOLR-9079:


SOLR-10705 is the only Jira I found with a quick search that even mentions 
upgrading/removing velocity.

> Remove commons-lang as a dependency
> ---
>
> Key: SOLR-9079
> URL: https://issues.apache.org/jira/browse/SOLR-9079
> Project: Solr
>  Issue Type: Improvement
>Reporter: Christine Poerschke
>Assignee: Kevin Risden
>Priority: Minor
> Fix For: 8.1, master (9.0)
>
> Attachments: SOLR-9079.patch
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Current version used is [/commons-lang/commons-lang = 
> 2.6|https://github.com/apache/lucene-solr/blob/master/lucene/ivy-versions.properties#L68]
>  and a key motivation would be to have 
> [commons.lang3|http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/package-summary.html]
>  APIs available e.g. 
> [org.apache.commons.lang3.tuple.Pair|http://commons.apache.org/proper/commons-lang/apidocs/index.html?org/apache/commons/lang3/tuple/Pair.html]
>  as an alternative to 
> [org.apache.solr.common.util.Pair|https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/Pair.java]
>  variant.
> [This|http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e]
>  dev list posting reports on exploring use of 3.4 instead of 2.6 and 
> concludes with the discovery of an optional zookeeper dependency on 
> commons-lang-2.4 version.
> So upgrading commons-lang can't happen anytime soon but this ticket here to 
> track motivations and findings so far for future reference.
> selected links into other relevant dev list threads:
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CA9C1B04B-EA67-4F2F-A9F3-B24A2AFB8598%40gmail.com%3E
> *  
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdSrZXDJk7VwuVzxDeqdocagS33Fx%2BstYD3yTx5--WXiA%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdWmCDSzXV40-wz1sr766GSwONGFem7UutkdXnsy0%2BXrg%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9079) Remove commons-lang as a dependency

[Kevin Risden (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796278#comment-16796278
 ] 

Kevin Risden commented on SOLR-9079:


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

> Remove commons-lang as a dependency
> ---
>
> Key: SOLR-9079
> URL: https://issues.apache.org/jira/browse/SOLR-9079
> Project: Solr
>  Issue Type: Improvement
>Reporter: Christine Poerschke
>Assignee: Kevin Risden
>Priority: Minor
> Fix For: 8.1, master (9.0)
>
> Attachments: SOLR-9079.patch
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Current version used is [/commons-lang/commons-lang = 
> 2.6|https://github.com/apache/lucene-solr/blob/master/lucene/ivy-versions.properties#L68]
>  and a key motivation would be to have 
> [commons.lang3|http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/package-summary.html]
>  APIs available e.g. 
> [org.apache.commons.lang3.tuple.Pair|http://commons.apache.org/proper/commons-lang/apidocs/index.html?org/apache/commons/lang3/tuple/Pair.html]
>  as an alternative to 
> [org.apache.solr.common.util.Pair|https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/Pair.java]
>  variant.
> [This|http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e]
>  dev list posting reports on exploring use of 3.4 instead of 2.6 and 
> concludes with the discovery of an optional zookeeper dependency on 
> commons-lang-2.4 version.
> So upgrading commons-lang can't happen anytime soon but this ticket here to 
> track motivations and findings so far for future reference.
> selected links into other relevant dev list threads:
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CA9C1B04B-EA67-4F2F-A9F3-B24A2AFB8598%40gmail.com%3E
> *  
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdSrZXDJk7VwuVzxDeqdocagS33Fx%2BstYD3yTx5--WXiA%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdWmCDSzXV40-wz1sr766GSwONGFem7UutkdXnsy0%2BXrg%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-9079) Remove commons-lang as a dependency

[Kevin Risden (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796278#comment-16796278
 ] 

Kevin Risden edited comment on SOLR-9079 at 3/19/19 4:57 PM:
-

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


was (Author: risdenk):
* 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.

> Remove commons-lang as a dependency
> ---
>
> Key: SOLR-9079
> URL: https://issues.apache.org/jira/browse/SOLR-9079
> Project: Solr
>  Issue Type: Improvement
>Reporter: Christine Poerschke
>Assignee: Kevin Risden
>Priority: Minor
> Fix For: 8.1, master (9.0)
>
> Attachments: SOLR-9079.patch
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Current version used is [/commons-lang/commons-lang = 
> 2.6|https://github.com/apache/lucene-solr/blob/master/lucene/ivy-versions.properties#L68]
>  and a key motivation would be to have 
> [commons.lang3|http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/package-summary.html]
>  APIs available e.g. 
> [org.apache.commons.lang3.tuple.Pair|http://commons.apache.org/proper/commons-lang/apidocs/index.html?org/apache/commons/lang3/tuple/Pair.html]
>  as an alternative to 
> [org.apache.solr.common.util.Pair|https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/Pair.java]
>  variant.
> [This|http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e]
>  dev list posting reports on exploring use of 3.4 instead of 2.6 and 
> concludes with the discovery of an optional zookeeper dependency on 
> commons-lang-2.4 version.
> So upgrading commons-lang can't happen anytime soon but this ticket here to 
> track motivations and findings so far for future reference.
> selected links into other relevant dev list threads:
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CA9C1B04B-EA67-4F2F-A9F3-B24A2AFB8598%40gmail.com%3E
> *  
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdSrZXDJk7VwuVzxDeqdocagS33Fx%2BstYD3yTx5--WXiA%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdWmCDSzXV40-wz1sr766GSwONGFem7UutkdXnsy0%2BXrg%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9079) Remove commons-lang as a dependency

[Kevin Risden (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796274#comment-16796274
 ] 

Kevin Risden commented on SOLR-9079:


So a few issues:
* 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

> Remove commons-lang as a dependency
> ---
>
> Key: SOLR-9079
> URL: https://issues.apache.org/jira/browse/SOLR-9079
> Project: Solr
>  Issue Type: Improvement
>Reporter: Christine Poerschke
>Assignee: Kevin Risden
>Priority: Minor
> Fix For: 8.1, master (9.0)
>
> Attachments: SOLR-9079.patch
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Current version used is [/commons-lang/commons-lang = 
> 2.6|https://github.com/apache/lucene-solr/blob/master/lucene/ivy-versions.properties#L68]
>  and a key motivation would be to have 
> [commons.lang3|http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/package-summary.html]
>  APIs available e.g. 
> [org.apache.commons.lang3.tuple.Pair|http://commons.apache.org/proper/commons-lang/apidocs/index.html?org/apache/commons/lang3/tuple/Pair.html]
>  as an alternative to 
> [org.apache.solr.common.util.Pair|https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/Pair.java]
>  variant.
> [This|http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e]
>  dev list posting reports on exploring use of 3.4 instead of 2.6 and 
> concludes with the discovery of an optional zookeeper dependency on 
> commons-lang-2.4 version.
> So upgrading commons-lang can't happen anytime soon but this ticket here to 
> track motivations and findings so far for future reference.
> selected links into other relevant dev list threads:
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CA9C1B04B-EA67-4F2F-A9F3-B24A2AFB8598%40gmail.com%3E
> *  
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdSrZXDJk7VwuVzxDeqdocagS33Fx%2BstYD3yTx5--WXiA%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdWmCDSzXV40-wz1sr766GSwONGFem7UutkdXnsy0%2BXrg%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9079) Remove commons-lang as a dependency

[Kevin Risden (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796268#comment-16796268
 ] 

Kevin Risden commented on SOLR-9079:


Sigh all went well except for the solr/contrib/velocity tests. 

{code:java}
   [junit4]> Throwable #1: java.lang.NoClassDefFoundError: 
org/apache/commons/lang/StringUtils
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([7014262216574C1B:AE369B21B26146B8]:0)
   [junit4]>at 
org.apache.velocity.runtime.resource.ResourceManagerImpl.initialize(ResourceManagerImpl.java:161)
   [junit4]>at 
org.apache.velocity.runtime.RuntimeInstance.initializeResourceManager(RuntimeInstance.java:730)
   [junit4]>at 
org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:263)
   [junit4]>at 
org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:646)
   [junit4]>at 
org.apache.velocity.app.VelocityEngine.init(VelocityEngine.java:116)
   [junit4]>at 
org.apache.solr.response.VelocityResponseWriter.createEngine(VelocityResponseWriter.java:345)
   [junit4]>at 
org.apache.solr.response.VelocityResponseWriter.write(VelocityResponseWriter.java:153)
   [junit4]>at 
org.apache.solr.velocity.VelocityResponseWriterTest.testCustomParamTemplate(VelocityResponseWriterTest.java:57)
   [junit4]>at java.lang.Thread.run(Thread.java:748)
{code}


> Remove commons-lang as a dependency
> ---
>
> Key: SOLR-9079
> URL: https://issues.apache.org/jira/browse/SOLR-9079
> Project: Solr
>  Issue Type: Improvement
>Reporter: Christine Poerschke
>Assignee: Kevin Risden
>Priority: Minor
> Fix For: 8.1, master (9.0)
>
> Attachments: SOLR-9079.patch
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Current version used is [/commons-lang/commons-lang = 
> 2.6|https://github.com/apache/lucene-solr/blob/master/lucene/ivy-versions.properties#L68]
>  and a key motivation would be to have 
> [commons.lang3|http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/package-summary.html]
>  APIs available e.g. 
> [org.apache.commons.lang3.tuple.Pair|http://commons.apache.org/proper/commons-lang/apidocs/index.html?org/apache/commons/lang3/tuple/Pair.html]
>  as an alternative to 
> [org.apache.solr.common.util.Pair|https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/Pair.java]
>  variant.
> [This|http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e]
>  dev list posting reports on exploring use of 3.4 instead of 2.6 and 
> concludes with the discovery of an optional zookeeper dependency on 
> commons-lang-2.4 version.
> So upgrading commons-lang can't happen anytime soon but this ticket here to 
> track motivations and findings so far for future reference.
> selected links into other relevant dev list threads:
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CA9C1B04B-EA67-4F2F-A9F3-B24A2AFB8598%40gmail.com%3E
> *  
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdSrZXDJk7VwuVzxDeqdocagS33Fx%2BstYD3yTx5--WXiA%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdWmCDSzXV40-wz1sr766GSwONGFem7UutkdXnsy0%2BXrg%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] risdenk commented on issue #611: SOLR-9079: Remove commons-lang as a dependency

[GitBox]

risdenk commented on issue #611: SOLR-9079: Remove commons-lang as a dependency
URL: https://github.com/apache/lucene-solr/pull/611#issuecomment-474466592
 
 
   Sigh all went well except for the solr/contrib/velocity tests. 
   
   ```
  [junit4]> Throwable #1: java.lang.NoClassDefFoundError: 
org/apache/commons/lang/StringUtils
  [junit4]> at 
__randomizedtesting.SeedInfo.seed([7014262216574C1B:AE369B21B26146B8]:0)
  [junit4]> at 
org.apache.velocity.runtime.resource.ResourceManagerImpl.initialize(ResourceManagerImpl.java:161)
  [junit4]> at 
org.apache.velocity.runtime.RuntimeInstance.initializeResourceManager(RuntimeInstance.java:730)
  [junit4]> at 
org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:263)
  [junit4]> at 
org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:646)
  [junit4]> at 
org.apache.velocity.app.VelocityEngine.init(VelocityEngine.java:116)
  [junit4]> at 
org.apache.solr.response.VelocityResponseWriter.createEngine(VelocityResponseWriter.java:345)
  [junit4]> at 
org.apache.solr.response.VelocityResponseWriter.write(VelocityResponseWriter.java:153)
  [junit4]> at 
org.apache.solr.velocity.VelocityResponseWriterTest.testCustomParamTemplate(VelocityResponseWriterTest.java:57)
  [junit4]> at java.lang.Thread.run(Thread.java:748)
   ```


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8150) Remove references to segments.gen.

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796250#comment-16796250
 ] 

Uwe Schindler commented on LUCENE-8150:
---

Hi, looks fine to me, the simple check in SegmentInfos is enough. Just because 
I am interested: Can't we throw exception earlier on opening index?

> Remove references to segments.gen.
> --
>
> Key: LUCENE-8150
> URL: https://issues.apache.org/jira/browse/LUCENE-8150
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: 8.1, master (9.0)
>
> Attachments: LUCENE-8150.patch, LUCENE-8150.patch
>
>
> This was the way we wrote pending segment files before we switch to 
> {{pending_segments_N}} in LUCENE-5925.



--
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] cpoerschke commented on a change in pull request #300: SOLR-11831: Skip second grouping step if group.limit is 1 (aka Las Vegas Patch)

[GitBox]

cpoerschke commented on a change in pull request #300: SOLR-11831: Skip second 
grouping step if group.limit is 1 (aka Las Vegas Patch)
URL: https://github.com/apache/lucene-solr/pull/300#discussion_r266972873
 
 

 ##
 File path: 
solr/core/src/java/org/apache/solr/handler/component/QueryComponent.java
 ##
 @@ -532,6 +578,12 @@ protected int groupedDistributedProcess(ResponseBuilder 
rb) {
   nextStage = ResponseBuilder.STAGE_DONE;
 }
 
+if (rb.stage == ResponseBuilder.STAGE_EXECUTE_QUERY && 
rb.getGroupingSpec().isSkipSecondGroupingStep()) {
+  shardRequestFactory = new StoredFieldsShardRequestFactory();
+  nextStage = ResponseBuilder.STAGE_DONE;
+  rb.stage = ResponseBuilder.STAGE_GET_FIELDS;
 
 Review comment:
   **Background re: existing code:**
   
   
[SearchHandler.handleRequestBody](https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.0.0/solr/core/src/java/org/apache/solr/handler/component/SearchHandler.java#L345-L349)
 calls `distributedProcess` on all configured components `c` and via the
   ```
   nextStage = Math.min(nextStage, c.distributedProcess(rb));
   ```
   formula each component thus gets a say in what `nextStage` is. The overall 
decision is then effected via the [rb.stage = 
nextStage;](https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.0.0/solr/core/src/java/org/apache/solr/handler/component/SearchHandler.java#L342)
 assignment.
   
   **Observation re: this proposed `QueryComponent.groupedDistributedProcess` 
change:**
   
   If `QueryComponent` also assigns to `rb.stage` then that could 'confuse' the 
`SearchHandler` logic e.g. specifically components running after the 
`QueryComponent` would not have an opportunity to do anything in the 
`ResponseBuilder.STAGE_EXECUTE_QUERY` stage.
   
   **Question/Suggestion:**
   
   Might an alternative be to turn the `ResponseBuilder.STAGE_EXECUTE_QUERY` 
stage into a 'no op' as far as the `QueryComponent` (in 
`isSkipSecondGroupingStep==true` circumstances) is concerned? 
https://github.com/bloomberg/lucene-solr/pull/229 aims to illustrate an 
alternative `QueryComponent.groupedDistributedProcess` modification, changes 
elsewhere might be needed too (haven't looked into that yet).


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] risdenk commented on issue #611: SOLR-9079: Remove commons-lang as a dependency

[GitBox]

risdenk commented on issue #611: SOLR-9079: Remove commons-lang as a dependency
URL: https://github.com/apache/lucene-solr/pull/611#issuecomment-474428275
 
 
   Compiles and precommit passed for me. Running tests locally. The Solr patch 
review (patch attached to the JIRA) should catch any egregious errors as well. 


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] janhoy commented on issue #611: SOLR-9079: Remove commons-lang as a dependency

[GitBox]

janhoy commented on issue #611: SOLR-9079: Remove commons-lang as a dependency
URL: https://github.com/apache/lucene-solr/pull/611#issuecomment-474427162
 
 
   Looks good, have not tried to compile...


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] mikemccand commented on a change in pull request #610: LUCENE-8671: Load FST off-heap if reader is not opened from an index writer

[GitBox]

mikemccand commented on a change in pull request #610: LUCENE-8671: Load FST 
off-heap if reader is not opened from an index writer
URL: https://github.com/apache/lucene-solr/pull/610#discussion_r266948427
 
 

 ##
 File path: lucene/core/src/java/org/apache/lucene/index/SegmentReadState.java
 ##
 @@ -49,23 +49,29 @@
*  {@link IndexFileNames#segmentFileName(String,String,String)}). */
   public final String segmentSuffix;
 
+  /**
+   * True iff this SegmentReadState is opened from an index writer.
 
 Review comment:
   s/`index writer`/`IndexWriter`


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] mikemccand commented on a change in pull request #610: LUCENE-8671: Load FST off-heap if reader is not opened from an index writer

[GitBox]

mikemccand commented on a change in pull request #610: LUCENE-8671: Load FST 
off-heap if reader is not opened from an index writer
URL: https://github.com/apache/lucene-solr/pull/610#discussion_r266947394
 
 

 ##
 File path: 
lucene/core/src/java/org/apache/lucene/codecs/blocktree/FieldReader.java
 ##
 @@ -91,7 +92,8 @@
   clone.seek(indexStartFP);
   // Initialize FST offheap if index is MMapDirectory and
   // docCount != sumDocFreq implying field is not primary key
-  if (clone instanceof ByteBufferIndexInput && this.docCount != 
this.sumDocFreq) {
+  isFSTOffHeap = clone instanceof ByteBufferIndexInput && ((this.docCount 
!= this.sumDocFreq) || openedFromWriter == false);
 
 Review comment:
   Is the idea here that it's only `IndexWriter` that needs fast ID lookups 
(since it uses this when deleting docs by ID field)?  E.g. apps that open 
`IndexReader` themselves (outside of `IndexWriter`) don't need fast ID lookups 
by default?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8150) Remove references to segments.gen.

[Michael McCandless (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796199#comment-16796199
 ] 

Michael McCandless commented on LUCENE-8150:


+1

> Remove references to segments.gen.
> --
>
> Key: LUCENE-8150
> URL: https://issues.apache.org/jira/browse/LUCENE-8150
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: 8.1, master (9.0)
>
> Attachments: LUCENE-8150.patch, LUCENE-8150.patch
>
>
> This was the way we wrote pending segment files before we switch to 
> {{pending_segments_N}} in LUCENE-5925.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-BadApples-master-Linux (64bit/jdk1.8.0_172) - Build # 179 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-master-Linux/179/
Java: 64bit/jdk1.8.0_172 -XX:-UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  
org.apache.solr.update.processor.TimeRoutedAliasUpdateProcessorTest.testPreemptiveCreation

Error Message:
took over 10 seconds after collection creation to update aliases

Stack Trace:
java.lang.AssertionError: took over 10 seconds after collection creation to 
update aliases
at 
__randomizedtesting.SeedInfo.seed([A787E64CF3B300E5:CAED63E7CBD1EDD1]:0)
at org.junit.Assert.fail(Assert.java:88)
at 
org.apache.solr.update.processor.RoutedAliasUpdateProcessorTest.waitColAndAlias(RoutedAliasUpdateProcessorTest.java:77)
at 
org.apache.solr.update.processor.TimeRoutedAliasUpdateProcessorTest.testPreemptiveCreation(TimeRoutedAliasUpdateProcessorTest.java:476)
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 15574 lines...]
   [junit4] 

[jira] [Commented] (SOLR-9079) Remove commons-lang as a dependency

[Kevin Risden (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796195#comment-16796195
 ] 

Kevin Risden commented on SOLR-9079:


ping [~janhoy] since you created the original commons-lang patch on SOLR-9459

> Remove commons-lang as a dependency
> ---
>
> Key: SOLR-9079
> URL: https://issues.apache.org/jira/browse/SOLR-9079
> Project: Solr
>  Issue Type: Improvement
>Reporter: Christine Poerschke
>Assignee: Kevin Risden
>Priority: Minor
> Fix For: 8.1, master (9.0)
>
> Attachments: SOLR-9079.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Current version used is [/commons-lang/commons-lang = 
> 2.6|https://github.com/apache/lucene-solr/blob/master/lucene/ivy-versions.properties#L68]
>  and a key motivation would be to have 
> [commons.lang3|http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/package-summary.html]
>  APIs available e.g. 
> [org.apache.commons.lang3.tuple.Pair|http://commons.apache.org/proper/commons-lang/apidocs/index.html?org/apache/commons/lang3/tuple/Pair.html]
>  as an alternative to 
> [org.apache.solr.common.util.Pair|https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/Pair.java]
>  variant.
> [This|http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e]
>  dev list posting reports on exploring use of 3.4 instead of 2.6 and 
> concludes with the discovery of an optional zookeeper dependency on 
> commons-lang-2.4 version.
> So upgrading commons-lang can't happen anytime soon but this ticket here to 
> track motivations and findings so far for future reference.
> selected links into other relevant dev list threads:
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CA9C1B04B-EA67-4F2F-A9F3-B24A2AFB8598%40gmail.com%3E
> *  
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdSrZXDJk7VwuVzxDeqdocagS33Fx%2BstYD3yTx5--WXiA%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdWmCDSzXV40-wz1sr766GSwONGFem7UutkdXnsy0%2BXrg%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-9079) Remove commons-lang as a dependency

[Kevin Risden (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-9079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kevin Risden updated SOLR-9079:
---
Summary: Remove commons-lang as a dependency  (was: Upgrade commons-lang to 
version 3.x)

> Remove commons-lang as a dependency
> ---
>
> Key: SOLR-9079
> URL: https://issues.apache.org/jira/browse/SOLR-9079
> Project: Solr
>  Issue Type: Improvement
>Reporter: Christine Poerschke
>Assignee: Kevin Risden
>Priority: Minor
> Fix For: 8.1, master (9.0)
>
> Attachments: SOLR-9079.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Current version used is [/commons-lang/commons-lang = 
> 2.6|https://github.com/apache/lucene-solr/blob/master/lucene/ivy-versions.properties#L68]
>  and a key motivation would be to have 
> [commons.lang3|http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/package-summary.html]
>  APIs available e.g. 
> [org.apache.commons.lang3.tuple.Pair|http://commons.apache.org/proper/commons-lang/apidocs/index.html?org/apache/commons/lang3/tuple/Pair.html]
>  as an alternative to 
> [org.apache.solr.common.util.Pair|https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/Pair.java]
>  variant.
> [This|http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e]
>  dev list posting reports on exploring use of 3.4 instead of 2.6 and 
> concludes with the discovery of an optional zookeeper dependency on 
> commons-lang-2.4 version.
> So upgrading commons-lang can't happen anytime soon but this ticket here to 
> track motivations and findings so far for future reference.
> selected links into other relevant dev list threads:
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CA9C1B04B-EA67-4F2F-A9F3-B24A2AFB8598%40gmail.com%3E
> *  
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdSrZXDJk7VwuVzxDeqdocagS33Fx%2BstYD3yTx5--WXiA%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdWmCDSzXV40-wz1sr766GSwONGFem7UutkdXnsy0%2BXrg%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9079) Remove commons-lang as a dependency

[Kevin Risden (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796193#comment-16796193
 ] 

Kevin Risden commented on SOLR-9079:


Replaced commons-lang with commons-lang3 where appropriate. Opened a PR 
https://github.com/apache/lucene-solr/pull/611 for easier review. Replaced 
deprecated usages as appropriate as well.

> Remove commons-lang as a dependency
> ---
>
> Key: SOLR-9079
> URL: https://issues.apache.org/jira/browse/SOLR-9079
> Project: Solr
>  Issue Type: Improvement
>Reporter: Christine Poerschke
>Assignee: Kevin Risden
>Priority: Minor
> Fix For: 8.1, master (9.0)
>
> Attachments: SOLR-9079.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Current version used is [/commons-lang/commons-lang = 
> 2.6|https://github.com/apache/lucene-solr/blob/master/lucene/ivy-versions.properties#L68]
>  and a key motivation would be to have 
> [commons.lang3|http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/package-summary.html]
>  APIs available e.g. 
> [org.apache.commons.lang3.tuple.Pair|http://commons.apache.org/proper/commons-lang/apidocs/index.html?org/apache/commons/lang3/tuple/Pair.html]
>  as an alternative to 
> [org.apache.solr.common.util.Pair|https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/Pair.java]
>  variant.
> [This|http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e]
>  dev list posting reports on exploring use of 3.4 instead of 2.6 and 
> concludes with the discovery of an optional zookeeper dependency on 
> commons-lang-2.4 version.
> So upgrading commons-lang can't happen anytime soon but this ticket here to 
> track motivations and findings so far for future reference.
> selected links into other relevant dev list threads:
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CA9C1B04B-EA67-4F2F-A9F3-B24A2AFB8598%40gmail.com%3E
> *  
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdSrZXDJk7VwuVzxDeqdocagS33Fx%2BstYD3yTx5--WXiA%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdWmCDSzXV40-wz1sr766GSwONGFem7UutkdXnsy0%2BXrg%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-9079) Upgrade commons-lang to version 3.x

[Kevin Risden (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-9079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kevin Risden updated SOLR-9079:
---
Issue Type: Improvement  (was: Wish)

> Upgrade commons-lang to version 3.x
> ---
>
> Key: SOLR-9079
> URL: https://issues.apache.org/jira/browse/SOLR-9079
> Project: Solr
>  Issue Type: Improvement
>Reporter: Christine Poerschke
>Assignee: Kevin Risden
>Priority: Minor
> Fix For: 8.1, master (9.0)
>
> Attachments: SOLR-9079.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Current version used is [/commons-lang/commons-lang = 
> 2.6|https://github.com/apache/lucene-solr/blob/master/lucene/ivy-versions.properties#L68]
>  and a key motivation would be to have 
> [commons.lang3|http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/package-summary.html]
>  APIs available e.g. 
> [org.apache.commons.lang3.tuple.Pair|http://commons.apache.org/proper/commons-lang/apidocs/index.html?org/apache/commons/lang3/tuple/Pair.html]
>  as an alternative to 
> [org.apache.solr.common.util.Pair|https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/Pair.java]
>  variant.
> [This|http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e]
>  dev list posting reports on exploring use of 3.4 instead of 2.6 and 
> concludes with the discovery of an optional zookeeper dependency on 
> commons-lang-2.4 version.
> So upgrading commons-lang can't happen anytime soon but this ticket here to 
> track motivations and findings so far for future reference.
> selected links into other relevant dev list threads:
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CA9C1B04B-EA67-4F2F-A9F3-B24A2AFB8598%40gmail.com%3E
> *  
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdSrZXDJk7VwuVzxDeqdocagS33Fx%2BstYD3yTx5--WXiA%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdWmCDSzXV40-wz1sr766GSwONGFem7UutkdXnsy0%2BXrg%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] risdenk opened a new pull request #611: SOLR-9079: Remove commons-lang as a dependency

[GitBox]

risdenk opened a new pull request #611: SOLR-9079: Remove commons-lang as a 
dependency
URL: https://github.com/apache/lucene-solr/pull/611
 
 
   Removes commons-lang as a dependency. Migrates to commons-lang3 where 
appropriate. Removes deprecated usages where appropriate as well.


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] [Assigned] (SOLR-9079) Upgrade commons-lang to version 3.x

[Kevin Risden (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-9079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kevin Risden reassigned SOLR-9079:
--

 Assignee: Kevin Risden
Fix Version/s: master (9.0)
   8.1
   Attachment: SOLR-9079.patch

> Upgrade commons-lang to version 3.x
> ---
>
> Key: SOLR-9079
> URL: https://issues.apache.org/jira/browse/SOLR-9079
> Project: Solr
>  Issue Type: Wish
>Reporter: Christine Poerschke
>Assignee: Kevin Risden
>Priority: Minor
> Fix For: 8.1, master (9.0)
>
> Attachments: SOLR-9079.patch
>
>
> Current version used is [/commons-lang/commons-lang = 
> 2.6|https://github.com/apache/lucene-solr/blob/master/lucene/ivy-versions.properties#L68]
>  and a key motivation would be to have 
> [commons.lang3|http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/package-summary.html]
>  APIs available e.g. 
> [org.apache.commons.lang3.tuple.Pair|http://commons.apache.org/proper/commons-lang/apidocs/index.html?org/apache/commons/lang3/tuple/Pair.html]
>  as an alternative to 
> [org.apache.solr.common.util.Pair|https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/Pair.java]
>  variant.
> [This|http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e]
>  dev list posting reports on exploring use of 3.4 instead of 2.6 and 
> concludes with the discovery of an optional zookeeper dependency on 
> commons-lang-2.4 version.
> So upgrading commons-lang can't happen anytime soon but this ticket here to 
> track motivations and findings so far for future reference.
> selected links into other relevant dev list threads:
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CA9C1B04B-EA67-4F2F-A9F3-B24A2AFB8598%40gmail.com%3E
> *  
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdSrZXDJk7VwuVzxDeqdocagS33Fx%2BstYD3yTx5--WXiA%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdWmCDSzXV40-wz1sr766GSwONGFem7UutkdXnsy0%2BXrg%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

SOLR-13240.patch

[Richard Goodman]

Hi there,

I've commented on this ticket before witnessing the same kind of exception
being thrown when using the Solr autoscaling api. I've got a patch that I
have tested on my own local 5 box cluster, and no longer get the exception *(as
well as supplying a new unit test case)*. This is my first contirbution to
Solr, so sorry if I haven't got the patch submission format properly.


-- 

Richard Goodman|Data Infrastructure Engineer

richa...@brandwatch.com


NEW YORK   | BOSTON  | BRIGHTON   | LONDON   | BERLIN   |   STUTTGART   |
SINGAPORE   | SYDNEY | PARIS





SOLR-13240.patch
Description: Binary data

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] s1monw commented on issue #610: LUCENE-8671: Load FST off-heap if reader is not opened from an index writer

[GitBox]

s1monw commented on issue #610: LUCENE-8671: Load FST off-heap if reader is not 
opened from an index writer
URL: https://github.com/apache/lucene-solr/pull/610#issuecomment-474409691
 
 
   @mikemccand FYI


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