[JENKINS] Lucene-Solr-Tests-master - Build # 3570 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3570/

All tests passed

Build Log:
[...truncated 63951 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj1145306906
 [ecj-lint] Compiling 1285 source files to /tmp/ecj1145306906
 [ecj-lint] Processing annotations
 [ecj-lint] Annotations processed
 [ecj-lint] Processing annotations
 [ecj-lint] No elements to process
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
 [ecj-lint] --
 [ecj-lint] 1. WARNING in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java
 (at line 219)
 [ecj-lint] return (NamedList) new 
JavaBinCodec(resolver).unmarshal(in);
 [ecj-lint]^^
 [ecj-lint] Resource leak: '' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 2. WARNING in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
 (at line 788)
 [ecj-lint] throw new UnsupportedOperationException("must add at least 1 
node first");
 [ecj-lint] 
^^
 [ecj-lint] Resource leak: 'queryRequest' is not closed at this location
 [ecj-lint] --
 [ecj-lint] 3. WARNING in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
 (at line 794)
 [ecj-lint] throw new UnsupportedOperationException("must add at least 1 
node first");
 [ecj-lint] 
^^
 [ecj-lint] Resource leak: 'queryRequest' is not closed at this location
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 4. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 19)
 [ecj-lint] import javax.naming.Context;
 [ecj-lint]
 [ecj-lint] The type javax.naming.Context is not accessible
 [ecj-lint] --
 [ecj-lint] 5. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 20)
 [ecj-lint] import javax.naming.InitialContext;
 [ecj-lint]^^^
 [ecj-lint] The type javax.naming.InitialContext is not accessible
 [ecj-lint] --
 [ecj-lint] 6. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 21)
 [ecj-lint] import javax.naming.NamingException;
 [ecj-lint]
 [ecj-lint] The type javax.naming.NamingException is not accessible
 [ecj-lint] --
 [ecj-lint] 7. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 22)
 [ecj-lint] import javax.naming.NoInitialContextException;
 [ecj-lint]^^
 [ecj-lint] The type javax.naming.NoInitialContextException is not accessible
 [ecj-lint] --
 [ecj-lint] 8. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 776)
 [ecj-lint] Context c = new InitialContext();
 [ecj-lint] ^^^
 [ecj-lint] Context cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 9. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 776)
 [ecj-lint] Context c = new InitialContext();
 [ecj-lint] ^^
 [ecj-lint] InitialContext cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 10. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 779)
 [ecj-lint] } catch (NoInitialContextException e) {
 [ecj-lint]  ^
 [ecj-lint] NoInitialContextException cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 11. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 781)
 [ecj-lint] } catch (NamingException e) {
 [ecj-lint]  ^^^
 [ecj-lint] NamingException cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 12. WARNING in 
/home/jenkins/jenkins-slave/works

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk-12.0.1) - Build # 5295 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/5295/
Java: 64bit/jdk-12.0.1 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.testTimeCat

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([BA8AB8C9476E16AE:8372F97A074F5AC5]: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.DimensionalRoutedAliasUpdateProcessorTest.testTimeCat(DimensionalRoutedAliasUpdateProcessorTest.java:219)
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 2045 lines...]
   [junit4] JVM J1: stderr was not empty, see: 

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1932 - Still Failing

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 25 lines...]
ERROR: Failed to check out http://svn.apache.org/repos/asf/lucene/test-data
org.tmatesoft.svn.core.SVNException: svn: E175002: connection refused by the 
server
svn: E175002: OPTIONS request failed on '/repos/asf/lucene/test-data'
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:112)
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:96)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:765)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:340)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:910)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:702)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:113)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1035)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:164)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:119)
at 
org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:178)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:43)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:831)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:26)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:11)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20)
at 
org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
at 
org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1239)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
at 
hudson.scm.subversion.CheckoutUpdater$SubversionUpdateTask.perform(CheckoutUpdater.java:133)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:176)
at 
hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:134)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168)
at 
hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1041)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1017)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:990)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3086)
at hudson.remoting.UserRequest.perform(UserRequest.java:212)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:369)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at 
org.tmatesoft.svn.core.internal.util.SVNSocketConnection.run(SVNSocketConnection.java:57)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
... 4 more
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)

[GitHub] [lucene-solr] mocobeta closed pull request #835: Add LICENSE

[GitBox]

mocobeta closed pull request #835: Add LICENSE
URL: https://github.com/apache/lucene-solr/pull/835
 
 
   


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] mocobeta commented on issue #835: Add LICENSE

[GitBox]

mocobeta commented on issue #835: Add LICENSE
URL: https://github.com/apache/lucene-solr/pull/835#issuecomment-522200242
 
 
   We already have `lucene/LICENSE.txt` and `solr/LICENSE.txt`.


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


With regards,
Apache Git Services

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

[JENKINS] Lucene-Solr-8.x-Windows (64bit/jdk-12.0.1) - Build # 404 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/404/
Java: 64bit/jdk-12.0.1 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

4 tests failed.
FAILED:  
org.apache.solr.cloud.LegacyCloudClusterPropTest.testCreateCollectionSwitchLegacyCloud

Error Message:
IOException occurred when talking to server at: https://127.0.0.1:59504/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occurred when 
talking to server at: https://127.0.0.1:59504/solr
at 
__randomizedtesting.SeedInfo.seed([C656B7704573CB0F:175145F5E17C403D]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:670)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1128)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228)
at 
org.apache.solr.cloud.LegacyCloudClusterPropTest.createAndTest(LegacyCloudClusterPropTest.java:87)
at 
org.apache.solr.cloud.LegacyCloudClusterPropTest.testCreateCollectionSwitchLegacyCloud(LegacyCloudClusterPropTest.java:79)
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.ev

[JENKINS] Lucene-Solr-repro-Java11 - Build # 327 - Unstable

[Apache Jenkins Server]

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

[...truncated 28 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-BadApples-NightlyTests-master/75/consoleText

[repro] Revision: 54ab07718a016c888e69ff4a8070c24cf34d3a51

[repro] Ant options: -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-master/test-data/enwiki.random.lines.txt
[repro] Repro line:  ant test  -Dtestcase=ShardSplitTest 
-Dtests.method=testSplitWithChaosMonkey -Dtests.seed=A22CBA8C52AB3E26 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.badapples=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-master/test-data/enwiki.random.lines.txt
 -Dtests.locale=pt-CV -Dtests.timezone=PRT -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=ShardSplitTest 
-Dtests.seed=A22CBA8C52AB3E26 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true -Dtests.badapples=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-master/test-data/enwiki.random.lines.txt
 -Dtests.locale=pt-CV -Dtests.timezone=PRT -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: 
54ab07718a016c888e69ff4a8070c24cf34d3a51
[repro] git fetch
[repro] git checkout 54ab07718a016c888e69ff4a8070c24cf34d3a51

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

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

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]solr/core
[repro]   ShardSplitTest
[repro] ant compile-test

[...truncated 3315 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.ShardSplitTest" -Dtests.showOutput=onerror 
-Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-master/test-data/enwiki.random.lines.txt
 -Dtests.seed=A22CBA8C52AB3E26 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true -Dtests.badapples=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-master/test-data/enwiki.random.lines.txt
 -Dtests.locale=pt-CV -Dtests.timezone=PRT -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

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

[repro] Failures:
[repro]   2/5 failed: org.apache.solr.cloud.api.collections.ShardSplitTest
[repro] git checkout 54ab07718a016c888e69ff4a8070c24cf34d3a51

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

[GitHub] [lucene-solr] xlzheng021 opened a new pull request #835: Add LICENSE

[GitBox]

xlzheng021 opened a new pull request #835: Add LICENSE
URL: https://github.com/apache/lucene-solr/pull/835
 
 
   
   
   
   # Description
   
   Please provide a short description of the changes you're making with this 
pull request.
   
   # Solution
   
   Please provide a short description of the approach taken to implement your 
solution.
   
   # Tests
   
   Please describe the tests you've developed or run to confirm this patch 
implements the feature or solves the problem.
   
   # Checklist
   
   Please review the following and check all that apply:
   
   - [ *] I have reviewed the guidelines for [How to 
Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms 
to the standards described there to the best of my ability.
   - [ ] I have created a Jira issue and added the issue ID to my pull request 
title.
   - [ ] I am authorized to contribute this code to the ASF and have removed 
any code I do not have a license to distribute.
   - [ ] I have developed this patch against the `master` branch.
   - [ ] I have run `ant precommit` and the appropriate test suite.
   - [ ] I have added tests for my changes.
   - [ ] I have added documentation for the [Ref 
Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) 
(for Solr changes only).
   


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


With regards,
Apache Git Services

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

[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 447 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/447/

All tests passed

Build Log:
[...truncated 64605 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj786828077
 [ecj-lint] Compiling 69 source files to /tmp/ecj786828077
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
 [ecj-lint] --
 [ecj-lint] 1. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
 (at line 28)
 [ecj-lint] import javax.naming.InitialContext;
 [ecj-lint]^^^
 [ecj-lint] The type javax.naming.InitialContext is not accessible
 [ecj-lint] --
 [ecj-lint] 2. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
 (at line 29)
 [ecj-lint] import javax.naming.NamingException;
 [ecj-lint]
 [ecj-lint] The type javax.naming.NamingException is not accessible
 [ecj-lint] --
 [ecj-lint] 3. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
 (at line 182)
 [ecj-lint] c = getFromJndi(initProps, jndiName);
 [ecj-lint] ^^^
 [ecj-lint] The method getFromJndi(Properties, String) from the type new 
Callable(){} refers to the missing type NamingException
 [ecj-lint] --
 [ecj-lint] 4. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
 (at line 245)
 [ecj-lint] private Connection getFromJndi(final Properties initProps, 
final String jndiName) throws NamingException,
 [ecj-lint] 
 ^^^
 [ecj-lint] NamingException cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 5. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
 (at line 249)
 [ecj-lint] InitialContext ctx =  new InitialContext();
 [ecj-lint] ^^
 [ecj-lint] InitialContext cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 6. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
 (at line 249)
 [ecj-lint] InitialContext ctx =  new InitialContext();
 [ecj-lint]   ^^
 [ecj-lint] InitialContext cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 6 problems (6 errors)

BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/build.xml:643:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/build.xml:101:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/build.xml:651:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/common-build.xml:479:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/lucene/common-build.xml:2009:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/lucene/common-build.xml:2048:
 Compile failed; see the compiler error output for details.

Total time: 149 minutes 0 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[jira] [Commented] (LUCENE-8566) Deprecate methods in CustomAnalyzer.Builder which take factory classes

[Tomoko Uchida (JIRA)]

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

Tomoko Uchida commented on LUCENE-8566:
---

Hi
 would it be a good time to change all {{CustomAnalyzer}} Javadoc examples to 
ones with SPI names to encourage users to use those instead of class names?
 I mean, now we can change this
{code:java}
Analyzer ana = CustomAnalyzer.builder(Paths.get("/path/to/config/dir"))
   .withTokenizer(StandardTokenizerFactory.class)
   .addTokenFilter(StandardFilterFactory.class)
   .addTokenFilter(LowerCaseFilterFactory.class)
   .addTokenFilter(StopFilterFactory.class, "ignoreCase", "false", "words", 
"stopwords.txt", "format", "wordset")
   .build();
{code}
to
{code:java}
Analyzer ana = CustomAnalyzer.builder(Paths.get("/path/to/config/dir"))
   .withTokenizer(StandardTokenizerFactory.NAME)
   .addTokenFilter(StandardFilterFactory.NAME)
   .addTokenFilter(LowerCaseFilterFactory.NAME)
   .addTokenFilter(StopFilterFactory.NAME, "ignoreCase", "false", "words", 
"stopwords.txt", "format", "wordset")
   .build();
{code}

> Deprecate methods in CustomAnalyzer.Builder which take factory classes
> --
>
> Key: LUCENE-8566
> URL: https://issues.apache.org/jira/browse/LUCENE-8566
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Uwe Schindler
>Priority: Minor
>
> CustomAnalyzer.Builder has methods which take implementation classes as 
> follows.
>  - withTokenizer(Class factory, String... params)
>  - withTokenizer(Class factory, 
> Map params)
>  - addTokenFilter(Class factory, String... 
> params)
>  - addTokenFilter(Class factory, 
> Map params)
>  - addCharFilter(Class factory, String... params)
>  - addCharFilter(Class factory, 
> Map params)
> Since the builder also has methods which take service names, it seems like 
> that above methods are unnecessary and a little bit misleading. Giving 
> symbolic names is preferable to implementation factory classes, but for now, 
> users can write code depending on implementation classes.
> What do you think about deprecating those methods (adding {{@Deprecated}} 
> annotations) and deleting them in the future releases? Those are called by 
> only test cases so deleting them should have no impact on current lucene/solr 
> codebase.
> If this proposal gains your consent, I will create a patch. (Let me know if I 
> missed some point. I'll close it.)



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Comment Edited] (SOLR-13699) maxChars no longer working as designed on CopyField

[Noble Paul (JIRA)]

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

Noble Paul edited comment on SOLR-13699 at 8/16/19 11:51 PM:
-

Let's limit all the changes to DocumentBuilder. Eventually, we have to convert 
our tests to run on all the 3 formats
* JSON
* XML
* javabin
Sticking to XML alone in tests can lead to many unforseen problems.


was (Author: noble.paul):
Let's limit all the changes to DocumentBuilder

> maxChars no longer working as designed on CopyField
> ---
>
> Key: SOLR-13699
> URL: https://issues.apache.org/jira/browse/SOLR-13699
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.0.1, 8.1, 8.2, 7.7.3, 8.1.1, 
> 8.1.2
>Reporter: Chris Troullis
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-13699.patch, SOLR-13699.patch
>
>
> We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars 
> property on a copy field is no longer functioning as designed, while indexing 
> via SolrJ. Per the most recent documentation it looks like there have been no 
> intentional changes as to the functionality of this property, so I assume 
> this is a bug.
>   
>  In debugging the issue, it looks like the bug was caused by SOLR-12992. In 
> DocumentBuilder where the maxChar limit is applied, it first checks if the 
> value is instanceof String. As of SOLR-12992, string values are now coming in 
> as ByteArrayUtf8CharSequence (unless they are above a certain size as defined 
> by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String 
> check, and the maxChar truncation is not being applied. I am currently not 
> sure if this issue is limited to indexing via SolrJ or if it applies to 
> documents indexed via any means



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13699) maxChars no longer working as designed on CopyField

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-13699:
---

Let's limit all the changes to DocumentBuilder

> maxChars no longer working as designed on CopyField
> ---
>
> Key: SOLR-13699
> URL: https://issues.apache.org/jira/browse/SOLR-13699
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.0.1, 8.1, 8.2, 7.7.3, 8.1.1, 
> 8.1.2
>Reporter: Chris Troullis
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-13699.patch, SOLR-13699.patch
>
>
> We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars 
> property on a copy field is no longer functioning as designed, while indexing 
> via SolrJ. Per the most recent documentation it looks like there have been no 
> intentional changes as to the functionality of this property, so I assume 
> this is a bug.
>   
>  In debugging the issue, it looks like the bug was caused by SOLR-12992. In 
> DocumentBuilder where the maxChar limit is applied, it first checks if the 
> value is instanceof String. As of SOLR-12992, string values are now coming in 
> as ByteArrayUtf8CharSequence (unless they are above a certain size as defined 
> by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String 
> check, and the maxChar truncation is not being applied. I am currently not 
> sure if this issue is limited to indexing via SolrJ or if it applies to 
> documents indexed via any means



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-13699) maxChars no longer working as designed on CopyField

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-13699:
--
Attachment: SOLR-13699.patch

> maxChars no longer working as designed on CopyField
> ---
>
> Key: SOLR-13699
> URL: https://issues.apache.org/jira/browse/SOLR-13699
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.0.1, 8.1, 8.2, 7.7.3, 8.1.1, 
> 8.1.2
>Reporter: Chris Troullis
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-13699.patch, SOLR-13699.patch
>
>
> We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars 
> property on a copy field is no longer functioning as designed, while indexing 
> via SolrJ. Per the most recent documentation it looks like there have been no 
> intentional changes as to the functionality of this property, so I assume 
> this is a bug.
>   
>  In debugging the issue, it looks like the bug was caused by SOLR-12992. In 
> DocumentBuilder where the maxChar limit is applied, it first checks if the 
> value is instanceof String. As of SOLR-12992, string values are now coming in 
> as ByteArrayUtf8CharSequence (unless they are above a certain size as defined 
> by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String 
> check, and the maxChar truncation is not being applied. I am currently not 
> sure if this issue is limited to indexing via SolrJ or if it applies to 
> documents indexed via any means



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-14-ea+9) - Build # 24556 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24556/
Java: 64bit/jdk-14-ea+9 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

4 tests failed.
FAILED:  
org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest.testCompareSmallPolygons 
{seed=[51061D6D94ECAD1F:87BD07D904BB472D]}

Error Message:
Polygon failed to build: [[lat=-1.5707962517119922, 
lon=1.2560290525702094([X=2.3193289697833527E-8, Y=7.12342064908316E-8, 
Z=-0.9977622920221022])], [lat=-1.5707963267948952, 
lon=-0.49334464366140196([X=1.224584056624391E-15, Y=-6.5844910610317735E-16, 
Z=-0.997762292022105])], [lat=-1.5707960448202014, 
lon=-1.7354960798022683([X=-4.6128034111355476E-8, Y=-2.7753647009208115E-7, 
Z=-0.9977622920220658])], [lat=-1.5707962938537916, 
lon=-2.2777399492915524([X=-2.1347795049584172E-8, Y=-2.499074093536226E-8, 
Z=-0.9977622920221044])], [lat=-1.5707962940331004, 
lon=-0.9355382236015028([X=1.9396865962915953E-8, Y=-2.6311568471603645E-8, 
Z=-0.9977622920221044])], [lat=-1.570796044820202, 
lon=1.2191592700144334([X=9.6904041746E-8, Y=2.6412832672490545E-7, 
Z=-0.9977622920220658])]] WKT:POLYGON((69.85268072607737 
-89.8384404007,-53.60239178553242 -89.9812288735,69.85268072607737 
-89.8384404007)) 

Stack Trace:
java.lang.AssertionError: Polygon failed to build:
[[lat=-1.5707962517119922, lon=1.2560290525702094([X=2.3193289697833527E-8, 
Y=7.12342064908316E-8, Z=-0.9977622920221022])], [lat=-1.5707963267948952, 
lon=-0.49334464366140196([X=1.224584056624391E-15, Y=-6.5844910610317735E-16, 
Z=-0.997762292022105])], [lat=-1.5707960448202014, 
lon=-1.7354960798022683([X=-4.6128034111355476E-8, Y=-2.7753647009208115E-7, 
Z=-0.9977622920220658])], [lat=-1.5707962938537916, 
lon=-2.2777399492915524([X=-2.1347795049584172E-8, Y=-2.499074093536226E-8, 
Z=-0.9977622920221044])], [lat=-1.5707962940331004, 
lon=-0.9355382236015028([X=1.9396865962915953E-8, Y=-2.6311568471603645E-8, 
Z=-0.9977622920221044])], [lat=-1.570796044820202, 
lon=1.2191592700144334([X=9.6904041746E-8, Y=2.6412832672490545E-7, 
Z=-0.9977622920220658])]]
WKT:POLYGON((69.85268072607737 -89.8384404007,-53.60239178553242 
-89.9812288735,69.85268072607737 -89.8384404007))

at 
__randomizedtesting.SeedInfo.seed([51061D6D94ECAD1F:87BD07D904BB472D]:0)
at org.junit.Assert.fail(Assert.java:88)
at 
org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest.testComparePolygons(RandomGeoPolygonTest.java:169)
at 
org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest.testCompareSmallPolygons(RandomGeoPolygonTest.java:109)
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:565)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRu

[JENKINS] Lucene-Solr-BadApples-NightlyTests-master - Build # 75 - Unstable

[Apache Jenkins Server]

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

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([A22CBA8C52AB3E26:290B695D13AD95A2]:0)
at java.base/sun.nio.ch.Net.bind0(Native Method)
at java.base/sun.nio.ch.Net.bind(Net.java:461)
at java.base/sun.nio.ch.Net.bind(Net.java:453)
at 
java.base/sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:227)
at 
java.base/sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:80)
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:396)
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 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet

Re: The Gradle train.

[Anshum Gupta]

Thanks for doing this Mark!

+1 on merging this in soon.

On Thu, Aug 15, 2019 at 2:24 PM Mark Miller  wrote:

> https://issues.apache.org/jira/projects/SOLR/issues/SOLR-13452 Update the
> lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
>
> Okay, we are at the point where either this thing lands soon and gains
> some contributors to help finish or it  overwhelms me and crashes & burns.
> That almost sounds negative, but it was actually the plan so far and I'm
> pretty excited after all this time invested. I need to punt this over to
> the community though - the final implications and ramifications of moving
> fully to gradle are just too big for me individually regardless of the time
> frame.
>
> I've done about 95%+ of what I wanted to do before trying to land
> something - a few more hoops to jump around. We pull in more deps than we
> should right now, I'll deal with that shortly, and mvn publishing needs
> work (mostly around solr-server, but dist and publishing both prob need
> edge work at least). Those are the main things on my mind. There are
> probably a ton of other little things, but I'm thinking those that are
> important will rise up quickly and the rest can be handled over time.
>
> This will be a large change. Some things will still take time to get up to
> par with what we have now. Many things will need to be sorted out (jenkins,
> releases, smoke tester type things, docs, etc).
>
> I've also made all the decisions and trade-offs and what not. I'm pretty
> happy about that, but I'm sure some will want to discuss and debate some
> choices once things are in their face. I've spent a lot of time in my
> recent life on this stuff and I'm ready to battle for some of it :) And to
> be mistaken, ignorant, or convinced of other paths for some other parts of
> it. I'll only say, every time I go from working with the gradle build back
> to ant+ivy+mvn, it feels like a big backslide.
>
> I'm thinking maybe in September/October? And only on master, hopefully
> living side by side with ant+ivy+mvn, but the goal would be for that period
> to be brief. They can't live in complete harmony - someone has to own the
> dependency view of the world for example, the one that actually gets
> committed (license, checksums, etc). Otherwise, I've done my best to do
> this in a way that doesn't break the current build. Will need to inspect
> that closer before landing though.
>
> This is just another heads up. Once we are in a main branch, I'm hoping a
> few of you will either have to jump in and help this land or we will have
> to pull it back out I think. Be prepared :)
>
> --
> - Mark
>
> http://about.me/markrmiller
>


-- 
Anshum Gupta

[JENKINS] Lucene-Solr-8.x-Linux (64bit/jdk-12.0.1) - Build # 1028 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/1028/
Java: 64bit/jdk-12.0.1 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

9 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.update.TestInPlaceUpdatesDistrib

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([84C507F963E80C35]:0)


FAILED:  
junit.framework.TestSuite.org.apache.solr.update.TestInPlaceUpdatesDistrib

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([84C507F963E80C35]:0)


FAILED:  
junit.framework.TestSuite.org.apache.solr.update.TestInPlaceUpdatesDistrib

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([84C507F963E80C35]:0)


FAILED:  
junit.framework.TestSuite.org.apache.solr.update.TestInPlaceUpdatesDistrib

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([84C507F963E80C35]:0)


FAILED:  org.apache.solr.cloud.LeaderVoteWaitTimeoutTest.basicTest

Error Message:
Timeout occurred while waiting response from server at: 
https://127.0.0.1:33761/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occurred while 
waiting response from server at: https://127.0.0.1:33761/solr
at 
__randomizedtesting.SeedInfo.seed([84C507F963E80C35:7631109B274D0106]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:667)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1128)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228)
at 
org.apache.solr.cloud.LeaderVoteWaitTimeoutTest.basicTest(LeaderVoteWaitTimeoutTest.java:157)
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)
 

Re: Issues with fixVersion = 8.1.2

[David Smiley]

Perhaps... but shouldn't we do likewise with CHANGES.txt (consistency)?
Regardless, I think branch_8_1's CHANGES.txt can be untouched since after
all the code was committed there.

At least http://lucene.apache.org/solr/8_2_0/changes/Changes.html includes
8.1.2

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Fri, Aug 16, 2019 at 4:03 PM Cassandra Targett 
wrote:

> There are 7 resolved/closed issues with the fixVersion 8.1.2. Since that
> version was never released, it’s misleading to leave only a fixVersion that
> was never released. We know we can assume 8.2, but the average user may
> not.
>
> Shouldn’t these all be changed to 8.2?
>
> Cassandra
>

Re: The Gradle train.

[Tomás Fernández Löbbe]

+1 to merge soon Mark. Thanks for working on this.

On Fri, Aug 16, 2019 at 10:03 AM Eric Pugh 
wrote:

> Hack-a-thon is a great thought…. We haven’t had a chance to publicize it
> widely yet, but Charlie Hull has set up another “pre Activate” hack-a-thon,
> similar to others he has organized.
>
> We have a conference room for 20 at the American Geophysical Union
> building that is literally 5 minute walk from where Activate is being held
> on Tuesday September 10th.
>
> Getting lots of folks to try out the new build tools on various laptops
> and environments would be a great theme for the hack-a-thon.
>
>
> https://www.meetup.com/Apache-Lucene-Solr-London-User-Group/events/263993681/
>
> Eric
>
>
> On Aug 16, 2019, at 11:57 AM, Erick Erickson 
> wrote:
>
> Focus, Mark, focus ;)
>
> I fully sympathize, I catch myself repeatedly thinking “Well, since I’m in
> this code already, why don’t I just change this completely unrelated thing
> that’s been bothering me for a long time”…..
>
> Not to mention merge issues…..
>
> Random thought: maybe a hack-a-thon on this at Activate? (he says but
> can’t help since he’ll be teaching Mon and Tue)...
>
> On Aug 16, 2019, at 8:30 AM, Mark Miller  wrote:
>
> Perhaps better for me as well (I couldn’t help myself and started
> addressing compiler warnings to clean up build output since gradle keeps
> the output so compact when its not dumping warning output), my main hold
> off is that I want to be available and engaged when it goes in. I’d like to
> target early sept, but I don’t want to commit and then delay, so I gave a
> little room.
>
> Mark
>
> On Fri, Aug 16, 2019 at 6:54 AM Eric Pugh 
> wrote:
> Sooner is better!  I’m reading up on Gradle now ;-)
>
>
> On Aug 16, 2019, at 5:33 AM, Jan Høydahl  wrote:
>
> +1
>
> Better to jump in now and have a few weeks of frustration and bug fixing
> from all of us than keeping this amazing improvement it a dark branch much
> longer :)
> I'll probably also try to adapt releaseWidard.py on master to work with
> the new build..
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> 15. aug. 2019 kl. 23:23 skrev Mark Miller :
>
> https://issues.apache.org/jira/projects/SOLR/issues/SOLR-13452 Update the
> lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
>
> Okay, we are at the point where either this thing lands soon and gains
> some contributors to help finish or it  overwhelms me and crashes & burns.
> That almost sounds negative, but it was actually the plan so far and I'm
> pretty excited after all this time invested. I need to punt this over to
> the community though - the final implications and ramifications of moving
> fully to gradle are just too big for me individually regardless of the time
> frame.
>
> I've done about 95%+ of what I wanted to do before trying to land
> something - a few more hoops to jump around. We pull in more deps than we
> should right now, I'll deal with that shortly, and mvn publishing needs
> work (mostly around solr-server, but dist and publishing both prob need
> edge work at least). Those are the main things on my mind. There are
> probably a ton of other little things, but I'm thinking those that are
> important will rise up quickly and the rest can be handled over time.
>
> This will be a large change. Some things will still take time to get up to
> par with what we have now. Many things will need to be sorted out (jenkins,
> releases, smoke tester type things, docs, etc).
>
> I've also made all the decisions and trade-offs and what not. I'm pretty
> happy about that, but I'm sure some will want to discuss and debate some
> choices once things are in their face. I've spent a lot of time in my
> recent life on this stuff and I'm ready to battle for some of it :) And to
> be mistaken, ignorant, or convinced of other paths for some other parts of
> it. I'll only say, every time I go from working with the gradle build back
> to ant+ivy+mvn, it feels like a big backslide.
>
> I'm thinking maybe in September/October? And only on master, hopefully
> living side by side with ant+ivy+mvn, but the goal would be for that period
> to be brief. They can't live in complete harmony - someone has to own the
> dependency view of the world for example, the one that actually gets
> committed (license, checksums, etc). Otherwise, I've done my best to do
> this in a way that doesn't break the current build. Will need to inspect
> that closer before landing though.
>
> This is just another heads up. Once we are in a main branch, I'm hoping a
> few of you will either have to jump in and help this land or we will have
> to pull it back out I think. Be prepared :)
>
> --
> - Mark
>
> http://about.me/markrmiller
>
>
>
> ___
> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 |
> http://www.opensourceconnections.com | My Free/Busy
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> This e-mail and all contents, including attachm

[jira] [Commented] (SOLR-13257) Enable replica routing affinity for better cache usage

[JIRA]

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

Tomás Fernández Löbbe commented on SOLR-13257:
--

Is this ready to merge? or are you doing more changes [~mgibney]?

> Enable replica routing affinity for better cache usage
> --
>
> Key: SOLR-13257
> URL: https://issues.apache.org/jira/browse/SOLR-13257
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Reporter: Michael Gibney
>Assignee: Tomás Fernández Löbbe
>Priority: Minor
> Attachments: AffinityShardHandlerFactory.java, SOLR-13257.patch, 
> SOLR-13257.patch
>
>  Time Spent: 4h 10m
>  Remaining Estimate: 0h
>
> For each shard in a distributed request, Solr currently routes each request 
> randomly via 
> [ShufflingReplicaListTransformer|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/handler/component/ShufflingReplicaListTransformer.java]
>  to a particular replica. In setups with replication factor >1, this normally 
> results in a situation where subsequent requests (which one would hope/expect 
> to leverage cached results from previous related requests) end up getting 
> routed to a replica that hasn't seen any related requests.
> The problem can be replicated by issuing a relatively expensive query (maybe 
> containing common terms?). The first request initializes the 
> {{queryResultCache}} on the consulted replicas. If replication factor >1 and 
> there are a sufficient number of shards, subsequent requests will likely be 
> routed to at least one replica that _hasn't_ seen the query before. The 
> replicas with uninitialized caches become a bottleneck, and from the client's 
> perspective, many subsequent requests appear not to benefit from caching at 
> all.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13700) Race condition in initializing metrics for new security plugins when security.json is modified

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-13700:
--

+1.

> Race condition in initializing metrics for new security plugins when 
> security.json is modified
> --
>
> Key: SOLR-13700
> URL: https://issues.apache.org/jira/browse/SOLR-13700
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13700.patch, SOLR-13700.patch
>
>
> When new security plugins are initialized due to remote API requetss, there 
> is a delay between "registering" the new plugins for use in methods like 
> {{initializeAuthenticationPlugin()}} (by assigning them to CoreContainer's 
> volatile {{this.authenticationPlugin}} variable) and when the 
> {{initializeMetrics(..)}} method is called on these plugins, so that they 
> continue to use the existing {{Metric}} instances as the plugins they are 
> replacing.
> Because these security plugins maintain local refrences to these Metrics (and 
> don't "get" them from the MetricRegisty everytime they need to {{inc()}} 
> them) this means that there is short race condition situation such that 
> during the window of time after a new plugin instance is put into use, but 
> before  {{initializeMetrics(..)}} is called on them, at these plugins are 
> responsible for accepting/rejecting requests, and decisions in {{Metric}} 
> instances that are not registered and subsequently get thrown away (and GCed) 
> once the CoreContainer gets around to calling {{initializeMetrics(..)}} (and 
> the plugin starts using the pre-existing metric objects)
> 
> This has some noticible impacts on auth tests on CPU constrained jenkins 
> machines (even after putting in place SOLR-13464 work arounds) that make 
> assertions about the metrics recorded.
> In real world situations, the impact of this bug on users is minor: for a few 
> micro/milli-seconds, requests may come in w/o being counted in the auth 
> metrics -- which may also result in descrepencies between the auth metrics 
> totals and the overall request metrics.  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13700) Race condition in initializing metrics for new security plugins when security.json is modified

[JIRA]

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

Jan Høydahl commented on SOLR-13700:


Forget my comment, I now see what happened in the first patch. And the newest 
patch makes the code easier to read, I like it!

> Race condition in initializing metrics for new security plugins when 
> security.json is modified
> --
>
> Key: SOLR-13700
> URL: https://issues.apache.org/jira/browse/SOLR-13700
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13700.patch, SOLR-13700.patch
>
>
> When new security plugins are initialized due to remote API requetss, there 
> is a delay between "registering" the new plugins for use in methods like 
> {{initializeAuthenticationPlugin()}} (by assigning them to CoreContainer's 
> volatile {{this.authenticationPlugin}} variable) and when the 
> {{initializeMetrics(..)}} method is called on these plugins, so that they 
> continue to use the existing {{Metric}} instances as the plugins they are 
> replacing.
> Because these security plugins maintain local refrences to these Metrics (and 
> don't "get" them from the MetricRegisty everytime they need to {{inc()}} 
> them) this means that there is short race condition situation such that 
> during the window of time after a new plugin instance is put into use, but 
> before  {{initializeMetrics(..)}} is called on them, at these plugins are 
> responsible for accepting/rejecting requests, and decisions in {{Metric}} 
> instances that are not registered and subsequently get thrown away (and GCed) 
> once the CoreContainer gets around to calling {{initializeMetrics(..)}} (and 
> the plugin starts using the pre-existing metric objects)
> 
> This has some noticible impacts on auth tests on CPU constrained jenkins 
> machines (even after putting in place SOLR-13464 work arounds) that make 
> assertions about the metrics recorded.
> In real world situations, the impact of this bug on users is minor: for a few 
> micro/milli-seconds, requests may come in w/o being counted in the auth 
> metrics -- which may also result in descrepencies between the auth metrics 
> totals and the overall request metrics.  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13699) maxChars no longer working as designed on CopyField

[Chris Troullis (JIRA)]

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

Chris Troullis commented on SOLR-13699:
---

Indeed. There appear to be a lot of "Instanceof String" in the codebase, so 
there could potentially be a lot of other places that are affected by this same 
issue. I went ahead an uploaded my patch with some unit tests, just so it's 
there if we decide to move forward with the change. Please let me know if I can 
help at all further.

> maxChars no longer working as designed on CopyField
> ---
>
> Key: SOLR-13699
> URL: https://issues.apache.org/jira/browse/SOLR-13699
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.0.1, 8.1, 8.2, 7.7.3, 8.1.1, 
> 8.1.2
>Reporter: Chris Troullis
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-13699.patch
>
>
> We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars 
> property on a copy field is no longer functioning as designed, while indexing 
> via SolrJ. Per the most recent documentation it looks like there have been no 
> intentional changes as to the functionality of this property, so I assume 
> this is a bug.
>   
>  In debugging the issue, it looks like the bug was caused by SOLR-12992. In 
> DocumentBuilder where the maxChar limit is applied, it first checks if the 
> value is instanceof String. As of SOLR-12992, string values are now coming in 
> as ByteArrayUtf8CharSequence (unless they are above a certain size as defined 
> by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String 
> check, and the maxChar truncation is not being applied. I am currently not 
> sure if this issue is limited to indexing via SolrJ or if it applies to 
> documents indexed via any means



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Comment Edited] (SOLR-13699) maxChars no longer working as designed on CopyField

[Chris Troullis (JIRA)]

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

Chris Troullis edited comment on SOLR-13699 at 8/16/19 6:44 PM:


Indeed. There appears to be a lot of "Instanceof String" in the codebase, so 
there could potentially be a lot of other places that are affected by this same 
issue. I went ahead an uploaded my patch with some unit tests, just so it's 
there if we decide to move forward with the change. Please let me know if I can 
help at all further.


was (Author: ctroullis):
Indeed. There appear to be a lot of "Instanceof String" in the codebase, so 
there could potentially be a lot of other places that are affected by this same 
issue. I went ahead an uploaded my patch with some unit tests, just so it's 
there if we decide to move forward with the change. Please let me know if I can 
help at all further.

> maxChars no longer working as designed on CopyField
> ---
>
> Key: SOLR-13699
> URL: https://issues.apache.org/jira/browse/SOLR-13699
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.0.1, 8.1, 8.2, 7.7.3, 8.1.1, 
> 8.1.2
>Reporter: Chris Troullis
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-13699.patch
>
>
> We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars 
> property on a copy field is no longer functioning as designed, while indexing 
> via SolrJ. Per the most recent documentation it looks like there have been no 
> intentional changes as to the functionality of this property, so I assume 
> this is a bug.
>   
>  In debugging the issue, it looks like the bug was caused by SOLR-12992. In 
> DocumentBuilder where the maxChar limit is applied, it first checks if the 
> value is instanceof String. As of SOLR-12992, string values are now coming in 
> as ByteArrayUtf8CharSequence (unless they are above a certain size as defined 
> by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String 
> check, and the maxChar truncation is not being applied. I am currently not 
> sure if this issue is limited to indexing via SolrJ or if it applies to 
> documents indexed via any means



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-13699) maxChars no longer working as designed on CopyField

[Chris Troullis (JIRA)]

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

Chris Troullis updated SOLR-13699:
--
Attachment: SOLR-13699.patch

> maxChars no longer working as designed on CopyField
> ---
>
> Key: SOLR-13699
> URL: https://issues.apache.org/jira/browse/SOLR-13699
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.0.1, 8.1, 8.2, 7.7.3, 8.1.1, 
> 8.1.2
>Reporter: Chris Troullis
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-13699.patch
>
>
> We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars 
> property on a copy field is no longer functioning as designed, while indexing 
> via SolrJ. Per the most recent documentation it looks like there have been no 
> intentional changes as to the functionality of this property, so I assume 
> this is a bug.
>   
>  In debugging the issue, it looks like the bug was caused by SOLR-12992. In 
> DocumentBuilder where the maxChar limit is applied, it first checks if the 
> value is instanceof String. As of SOLR-12992, string values are now coming in 
> as ByteArrayUtf8CharSequence (unless they are above a certain size as defined 
> by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String 
> check, and the maxChar truncation is not being applied. I am currently not 
> sure if this issue is limited to indexing via SolrJ or if it applies to 
> documents indexed via any means



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (LUCENE-8884) Add Directory wrapper to track per-query IO counters

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-8884:


Thanks for the review [~rcmuir].

We need the thread locals because we pass {{ExecutorService}} to 
{{IndexSearcher}} to keep our long-pole query latencies down.  So we need some 
way to associate searcher thread with the query it's handling, but maybe we can 
make that less invasive, e.g. default better for the more common 
single-threaded query case?
{quote}must you call get on every op vs once in the ctor? after all thats why 
we have clone? ( should not have thread issues )
{quote}
Ahh that's a good point – once the {{IndexInput}} is created, only one thread 
will use it – I'll fix that!  This should reduce overhead substantially, maybe 
enough to run in production by default.
{quote}readint has a second spurious call.
{quote}
Woops, I'll fix that too.

> Add Directory wrapper to track per-query IO counters
> 
>
> Key: LUCENE-8884
> URL: https://issues.apache.org/jira/browse/LUCENE-8884
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/store
>Reporter: Michael McCandless
>Assignee: Michael McCandless
>Priority: Minor
> Attachments: LUCENE-8884.patch
>
>
> Lucene's IO abstractions ({{Directory, IndexInput/Output}}) make it really 
> easy to track counters of how many IOPs and net bytes are read for each 
> query, which is a useful metric to track/aggregate/alarm on in production or 
> dev benchmarks.
> At my day job we use these wrappers in our nightly benchmarks to catch any 
> accidental performance regressions.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13606) DateTimeFormatter Exception on Create Core

[Jonathan Santy (JIRA)]

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

Jonathan Santy commented on SOLR-13606:
---

This Jira ticket really helped me!  I'm running jdk 11.0.4+11-LTS on rhel 7.   
I simply added 
SOLR_OPTS="$SOLR_OPTS -Djava.locale.providers=JRE,SPI"
to my solr-8.2.0/bin/solr.in.sh file

It feels hackish though... 

Thanks [~dsmiley] and [~joekrauss]!  You've saved me what would have been a day 
of agony :P

I miss Java8...  *sigh*...

> DateTimeFormatter Exception on Create Core
> --
>
> Key: SOLR-13606
> URL: https://issues.apache.org/jira/browse/SOLR-13606
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 8.1.1
> Environment: Red Hat 8.0
> Java 11
> Solr 8.1.1
>Reporter: Joseph Krauss
>Priority: Critical
>  Labels: newbie
>
> I have a fresh install of RH 8.0 with Java 11 JDK and I've run into an issue 
> with Solr 8.0.0 and 8.1.1 when attempting to create a core. I'm guessing 
> here, but the error appears to be an issue with the date format. From what 
> I've read Java date parser is expecting a period between seconds and 
> milliseconds? Hopefully, there's something simple I overlooked when I 
> configured the environment for solr. 
> Caused by: java.time.format.DateTimeParseException: Text 
> '2019-07-03T20:00:{color:#FF}00.050Z{color}'
> Oracle Corporation OpenJDK 64-Bit Server VM 11.0.3 11.0.3+7-LTS
> org.apache.solr.common.SolrException: Error CREATEing SolrCore 'testarms': 
> Unable to create core [testarms] Caused by: null
>   at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1187)
>   at 
> org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:92)
>   at 
> org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:360)
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:396)
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:180)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
>   at 
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:796)
>   at 
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:762)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:522)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>   at 
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>   at org.eclipse.jetty.server.Server.handle(Server.java:502)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)
>   at 
> org.ecli

[jira] [Commented] (SOLR-13701) JWTAuthPlugin calls authenticationFailure (which calls HttpServletResponsesendError) before updating metrics - breaks tests

[JIRA]

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

Jan Høydahl commented on SOLR-13701:


Ok, go ahead, it's easy enough to put in again should we need it.

> JWTAuthPlugin calls authenticationFailure (which calls 
> HttpServletResponsesendError) before updating metrics - breaks tests
> ---
>
> Key: SOLR-13701
> URL: https://issues.apache.org/jira/browse/SOLR-13701
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13701.patch
>
>
> The way JWTAuthPlugin is currently implemented, any failures are sent to the 
> remote client (via {{authenticationFailure(...)}} which calls 
> {{HttpServletResponsesendError(...)}}) *before* 
> {{JWTAuthPlugin.doAuthenticate(...)}} has a chance to update it's metrics 
> (like {{numErrors}} and {{numWrongCredentials}})
> This causes a race condition in tests where test threads can:
>  * see an error response/Exception before the server thread has updated 
> metrics (like {{numErrors}} and {{numWrongCredentials}})
>  * call white box methods like 
> {{SolrCloudAuthTestCase.assertAuthMetricsMinimums(...)}} to assert expected 
> metrics
> ...all before the server thread has ever gotten around to being able to 
> update the metrics in question.
> {{SolrCloudAuthTestCase.assertAuthMetricsMinimums(...)}} currently has some 
> {{"First metrics count assert failed, pausing 2s before re-attempt"}} 
> evidently to try and work around this bug, but it's still no garuntee that 
> the server thread will be scheduled before the retry happens.
> We can/should just fix JWTAuthPlugin to ensure the metrics are updated before 
> {{authenticationFailure(...)}} is called, and then remove the "pausing 2s 
> before re-attempt" logic from {{SolrCloudAuthTestCase}} - between this bug 
> fix, and the existing work around for SOLR-13464, there should be absolutely 
> no reason to "retry" reading hte metrics.
> (NOTE: BasicAuthPlugin has a similar {{authenticationFailure(...)}} method 
> that also calls {{HttpServletResponse.sendError(...)}} - but it already 
> (correctly) updates the error/failure metrics *before* calling that method.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-13700) Race condition in initializing metrics for new security plugins when security.json is modified

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-13700:

Attachment: SOLR-13700.patch
Status: Open  (was: Open)


I've updated the patch to move 
{{pkiAuthenticationPlugin.initializeMetrics((...)}} so that it is called 
exactly once immediately after {{new PKIAuthenticationPlugin(...)}}.

precommit now passes, i'm still beasting.



[~janhoy]: I don't understand this part of your comment...

bq. ... Re point 2, your patch deletes the wrong lines for auditloggerPlugin 
metrics. ...

The only lines modified in my patch(es) that mention {{auditloggerPlugin}} is 
to move the {{auditloggerPlugin.plugin.initializeMetrics(...)}} call into the 
existing {{initializeAuditloggerPlugin(...)}} as per the point of this jira.

Can you please elaborate on what lines you think were wrong to be deleted/moved 
?  ... ideally with a counter-patch, or suggested new case demonstrating the 
problem, so there's no ambiguity as to what you mean?


> Race condition in initializing metrics for new security plugins when 
> security.json is modified
> --
>
> Key: SOLR-13700
> URL: https://issues.apache.org/jira/browse/SOLR-13700
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13700.patch, SOLR-13700.patch
>
>
> When new security plugins are initialized due to remote API requetss, there 
> is a delay between "registering" the new plugins for use in methods like 
> {{initializeAuthenticationPlugin()}} (by assigning them to CoreContainer's 
> volatile {{this.authenticationPlugin}} variable) and when the 
> {{initializeMetrics(..)}} method is called on these plugins, so that they 
> continue to use the existing {{Metric}} instances as the plugins they are 
> replacing.
> Because these security plugins maintain local refrences to these Metrics (and 
> don't "get" them from the MetricRegisty everytime they need to {{inc()}} 
> them) this means that there is short race condition situation such that 
> during the window of time after a new plugin instance is put into use, but 
> before  {{initializeMetrics(..)}} is called on them, at these plugins are 
> responsible for accepting/rejecting requests, and decisions in {{Metric}} 
> instances that are not registered and subsequently get thrown away (and GCed) 
> once the CoreContainer gets around to calling {{initializeMetrics(..)}} (and 
> the plugin starts using the pre-existing metric objects)
> 
> This has some noticible impacts on auth tests on CPU constrained jenkins 
> machines (even after putting in place SOLR-13464 work arounds) that make 
> assertions about the metrics recorded.
> In real world situations, the impact of this bug on users is minor: for a few 
> micro/milli-seconds, requests may come in w/o being counted in the auth 
> metrics -- which may also result in descrepencies between the auth metrics 
> totals and the overall request metrics.  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

Re: [GitHub] [lucene-solr] atris commented on issue #815: LUCENE-8213: Introduce Asynchronous Caching in LRUQueryCache

[Michael Sokolov]

OK; I guess I was confusing taskRepeatCount  (within a JVM), but you
can also have jvmCount

On Tue, Aug 13, 2019 at 6:16 AM GitBox  wrote:
>
> atris commented on issue #815: LUCENE-8213: Introduce Asynchronous Caching in 
> LRUQueryCache
> URL: https://github.com/apache/lucene-solr/pull/815#issuecomment-520776996
>
>
>> It should be enough to report the stats after the last iteration - it is 
> cumulative, so the previous ones just add noise? I agree QPS looks pretty 
> noisy, probably no real change.
>
>I dont think thats true, since each run is its own JVM?
>
>
>
> 
> 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
>

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

[jira] [Updated] (SOLR-13566) REINDEXCOLLECTION does not work with (basic) authentication

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated SOLR-13566:
-
Fix Version/s: (was: 8.1.2)
   8.2

> REINDEXCOLLECTION does not work with (basic) authentication
> ---
>
> Key: SOLR-13566
> URL: https://issues.apache.org/jira/browse/SOLR-13566
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 8.1.1
>Reporter: Colvin Cowie
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 8.2
>
> Attachments: SOLR-13566.patch, SOLR-13566.patch, SOLR-13566.patch, 
> responses.txt, security.json, solr.log
>
>
> I'm on the Solr 8.1 branch off commit 
> f26388d034fe5eadca7416aa63b509b8db2c7688 so I have the authentication fixes 
> from SOLR-13510 (intermittent 401s for internode requests)
>   
>  When trying to use the new REINDEXCOLLECTION command introduced in 
> SOLR-11127 with basic auth enabled, the daemon stream fails with repeated 
> 401s when trying to access the target collection.
>   
>  This might be the same problem as SOLR-13472, except it applies even with a 
> single node, and this doesn't require role based configuration.
>   
>  Repro: I added a reindex request in BasicAuthIntegrationTest and it is 
> reproducible in there... I don't know what effect it should have on the auth 
> metrics, if it were working correctly, so I don't know how to update the test 
> properly. But you can add the request towards the end of 
> org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth()
>   
>        _CollectionAdminRequest.ReindexCollection reindexReq = 
> CollectionAdminRequest.reindexCollection(COLLECTION);_
>        _reindexReq.setBasicAuthCredentials("harry", "HarryIsUberCool");_
>        _cluster.getSolrClient().request(reindexReq, COLLECTION);_
>   
>  Manual Repro:
>  run bin/solr -e cloud
>  Choose 1 node / 1 shard / 1 replica
>  In browser GET 
> [http://localhost:8983/solr/admin/collections?action=REINDEXCOLLECTION&name=gettingstarted]
>  will succeed
>  Enable security: server\scripts\cloud-scripts\zkcli -zkhost localhost:9983 
> -cmd putfile /security.json 
>   
>  {
>      "authentication": {
>          "blockUnknown": true,
>          "class": "solr.BasicAuthPlugin",
>          "credentials":
> {             "solradmin": "fskh17INKrOTSRCJ8HkamA0L6Uiq1dSMgn4OVy8htME= 
> /Q4VgOkwVlP6AMVY+ML+IuodbfV81WEfZ3lFb390bws="         }
>     }
>  }
>   
>   
>  In browser authenticate (as solradmin : solradmin) and GET 
> [http://localhost:8983/solr/admin/collections?action=REINDEXCOLLECTION&name=gettingstarted]
>  will time out after 180 seconds
>   
>  The solr log will show repeated 401s
>   
>  Setting "forwardCredentials" : true in the security.json does not appear to 
> change the outcome.
>   
>   
>  The daemon stream should probably be using PKI auth for the internal request.
>   



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13701) JWTAuthPlugin calls authenticationFailure (which calls HttpServletResponsesendError) before updating metrics - breaks tests

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-13701:
-

the beasting i've done locally so far indicates that between the SOLR-13464 
work arounds and this fix in this patch there is no need for the 2s retry...

but until we actually remove it will be hard to know if it's hiding other bugs 
- because we have very little visibility in to how often jenkins builds are 
passing *only* because of that retry (test logs aren't kept of tests that PASS, 
so we can't grep for that log message to try and find other situations/bugs we 
don't currently know about.

> JWTAuthPlugin calls authenticationFailure (which calls 
> HttpServletResponsesendError) before updating metrics - breaks tests
> ---
>
> Key: SOLR-13701
> URL: https://issues.apache.org/jira/browse/SOLR-13701
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13701.patch
>
>
> The way JWTAuthPlugin is currently implemented, any failures are sent to the 
> remote client (via {{authenticationFailure(...)}} which calls 
> {{HttpServletResponsesendError(...)}}) *before* 
> {{JWTAuthPlugin.doAuthenticate(...)}} has a chance to update it's metrics 
> (like {{numErrors}} and {{numWrongCredentials}})
> This causes a race condition in tests where test threads can:
>  * see an error response/Exception before the server thread has updated 
> metrics (like {{numErrors}} and {{numWrongCredentials}})
>  * call white box methods like 
> {{SolrCloudAuthTestCase.assertAuthMetricsMinimums(...)}} to assert expected 
> metrics
> ...all before the server thread has ever gotten around to being able to 
> update the metrics in question.
> {{SolrCloudAuthTestCase.assertAuthMetricsMinimums(...)}} currently has some 
> {{"First metrics count assert failed, pausing 2s before re-attempt"}} 
> evidently to try and work around this bug, but it's still no garuntee that 
> the server thread will be scheduled before the retry happens.
> We can/should just fix JWTAuthPlugin to ensure the metrics are updated before 
> {{authenticationFailure(...)}} is called, and then remove the "pausing 2s 
> before re-attempt" logic from {{SolrCloudAuthTestCase}} - between this bug 
> fix, and the existing work around for SOLR-13464, there should be absolutely 
> no reason to "retry" reading hte metrics.
> (NOTE: BasicAuthPlugin has a similar {{authenticationFailure(...)}} method 
> that also calls {{HttpServletResponse.sendError(...)}} - but it already 
> (correctly) updates the error/failure metrics *before* calling that method.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-13583) Impossible to delete a collection with the same name as an existing alias

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated SOLR-13583:
-
Fix Version/s: (was: 8.1.2)

> Impossible to delete a collection with the same name as an existing alias
> -
>
> Key: SOLR-13583
> URL: https://issues.apache.org/jira/browse/SOLR-13583
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 8.1, 8.1.1
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Blocker
> Fix For: 8.2
>
> Attachments: SOLR-13583.patch, SOLR-13583.patch
>
>
> SOLR-13262 changed the behavior of most collection admin commands so that 
> they always resolve aliases by default. In most cases this is desireable 
> behavior but it also prevents executing commands on the collections that have 
> the same name as an existing alias (which usually points to a different 
> collection).
> This behavior also breaks the REINDEXCOLLECTION command with 
> {{removeSource=true,}} which can also lead to data loss.
> This issue can be resolved by adding either an opt-in or opt-out flag to the 
> collection admin commands that specifies whether the command should attempt 
> resolving the provided name as an alias first. From the point of view of ease 
> of use this could be an opt-out option, from the point of view of data safety 
> this could be an opt-in option.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk-11.0.3) - Build # 5294 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/5294/
Java: 64bit/jdk-11.0.3 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.PeerSyncReplicationTest.test

Error Message:
expected:<154> but was:<152>

Stack Trace:
java.lang.AssertionError: expected:<154> but was:<152>
at 
__randomizedtesting.SeedInfo.seed([4A58971CA06D3127:C20CA8C60E915CDF]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:631)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:154)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
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.j

Re: The Gradle train.

[Eric Pugh]

Hack-a-thon is a great thought…. We haven’t had a chance to publicize it widely 
yet, but Charlie Hull has set up another “pre Activate” hack-a-thon, similar to 
others he has organized.

We have a conference room for 20 at the American Geophysical Union building 
that is literally 5 minute walk from where Activate is being held on Tuesday 
September 10th.   

Getting lots of folks to try out the new build tools on various laptops and 
environments would be a great theme for the hack-a-thon.

https://www.meetup.com/Apache-Lucene-Solr-London-User-Group/events/263993681/

Eric


> On Aug 16, 2019, at 11:57 AM, Erick Erickson  wrote:
> 
> Focus, Mark, focus ;)
> 
> I fully sympathize, I catch myself repeatedly thinking “Well, since I’m in 
> this code already, why don’t I just change this completely unrelated thing 
> that’s been bothering me for a long time”…..
> 
> Not to mention merge issues…..
> 
> Random thought: maybe a hack-a-thon on this at Activate? (he says but can’t 
> help since he’ll be teaching Mon and Tue)...
> 
>> On Aug 16, 2019, at 8:30 AM, Mark Miller  wrote:
>> 
>> Perhaps better for me as well (I couldn’t help myself and started addressing 
>> compiler warnings to clean up build output since gradle keeps the output so 
>> compact when its not dumping warning output), my main hold off is that I 
>> want to be available and engaged when it goes in. I’d like to target early 
>> sept, but I don’t want to commit and then delay, so I gave a little room.
>> 
>> Mark
>> 
>> On Fri, Aug 16, 2019 at 6:54 AM Eric Pugh  
>> wrote:
>> Sooner is better!  I’m reading up on Gradle now ;-)
>> 
>> 
>>> On Aug 16, 2019, at 5:33 AM, Jan Høydahl  wrote:
>>> 
>>> +1
>>> 
>>> Better to jump in now and have a few weeks of frustration and bug fixing 
>>> from all of us than keeping this amazing improvement it a dark branch much 
>>> longer :)
>>> I'll probably also try to adapt releaseWidard.py on master to work with the 
>>> new build..
>>> 
>>> --
>>> Jan Høydahl, search solution architect
>>> Cominvent AS - www.cominvent.com
>>> 
 15. aug. 2019 kl. 23:23 skrev Mark Miller :
 
 https://issues.apache.org/jira/projects/SOLR/issues/SOLR-13452 Update the 
 lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
 
 Okay, we are at the point where either this thing lands soon and gains 
 some contributors to help finish or it  overwhelms me and crashes & burns. 
 That almost sounds negative, but it was actually the plan so far and I'm 
 pretty excited after all this time invested. I need to punt this over to 
 the community though - the final implications and ramifications of moving 
 fully to gradle are just too big for me individually regardless of the 
 time frame.
 
 I've done about 95%+ of what I wanted to do before trying to land 
 something - a few more hoops to jump around. We pull in more deps than we 
 should right now, I'll deal with that shortly, and mvn publishing needs 
 work (mostly around solr-server, but dist and publishing both prob need 
 edge work at least). Those are the main things on my mind. There are 
 probably a ton of other little things, but I'm thinking those that are 
 important will rise up quickly and the rest can be handled over time.
 
 This will be a large change. Some things will still take time to get up to 
 par with what we have now. Many things will need to be sorted out 
 (jenkins, releases, smoke tester type things, docs, etc).
 
 I've also made all the decisions and trade-offs and what not. I'm pretty 
 happy about that, but I'm sure some will want to discuss and debate some 
 choices once things are in their face. I've spent a lot of time in my 
 recent life on this stuff and I'm ready to battle for some of it :) And to 
 be mistaken, ignorant, or convinced of other paths for some other parts of 
 it. I'll only say, every time I go from working with the gradle build back 
 to ant+ivy+mvn, it feels like a big backslide.
 
 I'm thinking maybe in September/October? And only on master, hopefully 
 living side by side with ant+ivy+mvn, but the goal would be for that 
 period to be brief. They can't live in complete harmony - someone has to 
 own the dependency view of the world for example, the one that actually 
 gets committed (license, checksums, etc). Otherwise, I've done my best to 
 do this in a way that doesn't break the current build. Will need to 
 inspect that closer before landing though.
 
 This is just another heads up. Once we are in a main branch, I'm hoping a 
 few of you will either have to jump in and help this land or we will have 
 to pull it back out I think. Be prepared :)
 
 -- 
 - Mark
 
 http://about.me/markrmiller
>>> 
>> 
>> ___
>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
>> http://www.opensourceconne

[jira] [Commented] (SOLR-13699) maxChars no longer working as designed on CopyField

[JIRA]

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

Jan Høydahl commented on SOLR-13699:


In this particular case I guess we can replace 
{code:java}
if( val instanceof String && cf.getMaxChars() > 0 ) {{code}
with
{code:java}
if( val instanceof CharSequence && cf.getMaxChars() > 0 ) {{code}
But how do we guard against other code locations expecting {{String}} 
explicitly? @[~noble.paul] any suggestions? 

> maxChars no longer working as designed on CopyField
> ---
>
> Key: SOLR-13699
> URL: https://issues.apache.org/jira/browse/SOLR-13699
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.0.1, 8.1, 8.2, 7.7.3, 8.1.1, 
> 8.1.2
>Reporter: Chris Troullis
>Assignee: Erick Erickson
>Priority: Major
>
> We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars 
> property on a copy field is no longer functioning as designed, while indexing 
> via SolrJ. Per the most recent documentation it looks like there have been no 
> intentional changes as to the functionality of this property, so I assume 
> this is a bug.
>   
>  In debugging the issue, it looks like the bug was caused by SOLR-12992. In 
> DocumentBuilder where the maxChar limit is applied, it first checks if the 
> value is instanceof String. As of SOLR-12992, string values are now coming in 
> as ByteArrayUtf8CharSequence (unless they are above a certain size as defined 
> by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String 
> check, and the maxChar truncation is not being applied. I am currently not 
> sure if this issue is limited to indexing via SolrJ or if it applies to 
> documents indexed via any means



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

Re: Use of JIRA fixVersion

[Jan Høydahl]

> "I'm less sure about requiring that the fix version is not set before 
> resolving the issue"   Yeah, this aspect I don't think is particularly 
> important either way.  We can establish a preference to leave blank until 
> release time, but say Blocker issues are a good exception.

> It'd be nice to have internal dev docs for us to write these down in so we 
> can refer to them, particularly to share with new committers as well.  Were 
> you planning to do this Jan?

If we can avoid adding another Jira field that would be best. Jira is complex 
enough as is. PS: One day I think I'll start a vote to move to GitHub issues 
for the entire project :)

> It'd be nice to have internal dev docs for us to write these down in so we 
> can refer to them, particularly to share with new committers as well.  Were 
> you planning to do this Jan?

Exactly. I just revived the email thread "Lucene/Solr Developer content" to try 
to get such dev docs started.
Part of that new DevGuide should probably be a Project Policies chapter such as 
Git branch policy, Jira FixVersion policy, commit policy (CTR) etc

> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley 
> 
> 
> On Wed, Jun 19, 2019 at 12:22 PM Mark Miller  > wrote:
> Can we address this in JIRA? In the past I've seen this handled in JIRA by 
> also having a 'target' version field - this is the intended version you want 
> to land in and you set it right away. Things were configured so you could 
> only set the fix version when you resolved I think. Then you would use target 
> for release blockers and such. Fix would just tell you what it's actually in.
> 
> On Mon, Jun 17, 2019 at 4:49 AM Adrien Grand  > wrote:
> +1 to Jan's proposal about not adding master when changes are also pushed to 
> the previous major, I like the additional consistency with our CHANGES.txt.
> 
> I'm less sure about requiring that the fix version is not set before 
> resolving the issue, I have used this in combination with the blocker label 
> to mean that an issue needs to be addressed before releasing, sometimes it 
> will be the next minor, sometimes the next major. For the record, the 
> ReleaseTodo[1] recommends to check for blockers by filtering by priority and 
> fixVersion.
> 
> [1] https://wiki.apache.org/lucene-java/ReleaseTodo 
> 
> On Fri, Jun 14, 2019 at 11:30 PM Gus Heck  > wrote:
> FWIW I tend to agree with Erick here on both his points, but the second one 
> more strongly than the first. The first I can live with either way really so 
> long as it's clearly documented somewhere (besides this thread). 
> 
> If we don't update the changes in master for bug fixes when we're committing, 
> who's going to go collect and add them later? I'm not sure I'm that big a fan 
> of generating changes... I haven't looked at Yetus specifically but I suspect 
> that this will just leave us with the title from the Jira, and often some 
> additional detail for changes is worthwhile beyond what the title says. So if 
> we create a field in Jira that is the Changes text, and make it required in 
> the resolution screen fine to generate from that, but I think there's real 
> value in the current system because you wind up writing a final short 1-4 
> line summary focused on "what the user needs to know" 
> 
> Also line 3, the feature only in 8x (but not master) is a very odd case in 
> that table, I'm not sure when that would happen? could happen for a bug that 
> is fixed by other changes in master, but for a feature? 
> 
> Also if we aren't marking branches explicitly maybe the 9.0 (master) tag 
> should say 9.0 (unreleased)? Sure most developers know master is typically 
> unreleased, but why add that mental leap. It's possible that someone less 
> technical, or who is a student will stumble in from a link on SO...
> 
> -Gus
> 
> On Thu, Jun 13, 2019 at 3:23 PM David Smiley  > wrote:
> +1 to your plan Jan.
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley 
> 
> 
> On Thu, Jun 13, 2019 at 8:40 AM Jan Høydahl  > wrote:
> Trying to reach a conclusion (or perhaps a vote) on this.
> 
> Here is a table that sums up my proposal. Basically it means in most cases 
> stop adding master as fixVersion.
> 
> Type  Committed tofixVersion  CHANGES.txt section
> Feature   master  master (9.0)9.0
> Feature   master, branch_8x   8.2 8.2
> Feature   branch_8x   8.2 8.2
> Bugfixmaster  master (9.0)none (unreleased bug)
> Bugfixmaster, branch_8x   8.2 8.2
> Bugfixmaster, branch_8x, branch_8_1   8.1.2, 8.2  8.1.2, 8.2
> Bugfixbranch_8x   8.2 8.2
> Bugfix  

Re: The Gradle train.

[Erick Erickson]

Focus, Mark, focus ;)

I fully sympathize, I catch myself repeatedly thinking “Well, since I’m in this 
code already, why don’t I just change this completely unrelated thing that’s 
been bothering me for a long time”…..

Not to mention merge issues…..

Random thought: maybe a hack-a-thon on this at Activate? (he says but can’t 
help since he’ll be teaching Mon and Tue)...

> On Aug 16, 2019, at 8:30 AM, Mark Miller  wrote:
> 
> Perhaps better for me as well (I couldn’t help myself and started addressing 
> compiler warnings to clean up build output since gradle keeps the output so 
> compact when its not dumping warning output), my main hold off is that I want 
> to be available and engaged when it goes in. I’d like to target early sept, 
> but I don’t want to commit and then delay, so I gave a little room.
> 
> Mark
> 
> On Fri, Aug 16, 2019 at 6:54 AM Eric Pugh  
> wrote:
> Sooner is better!  I’m reading up on Gradle now ;-)
> 
> 
>> On Aug 16, 2019, at 5:33 AM, Jan Høydahl  wrote:
>> 
>> +1
>> 
>> Better to jump in now and have a few weeks of frustration and bug fixing 
>> from all of us than keeping this amazing improvement it a dark branch much 
>> longer :)
>> I'll probably also try to adapt releaseWidard.py on master to work with the 
>> new build..
>> 
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com
>> 
>>> 15. aug. 2019 kl. 23:23 skrev Mark Miller :
>>> 
>>> https://issues.apache.org/jira/projects/SOLR/issues/SOLR-13452 Update the 
>>> lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
>>> 
>>> Okay, we are at the point where either this thing lands soon and gains some 
>>> contributors to help finish or it  overwhelms me and crashes & burns. That 
>>> almost sounds negative, but it was actually the plan so far and I'm pretty 
>>> excited after all this time invested. I need to punt this over to the 
>>> community though - the final implications and ramifications of moving fully 
>>> to gradle are just too big for me individually regardless of the time frame.
>>> 
>>> I've done about 95%+ of what I wanted to do before trying to land something 
>>> - a few more hoops to jump around. We pull in more deps than we should 
>>> right now, I'll deal with that shortly, and mvn publishing needs work 
>>> (mostly around solr-server, but dist and publishing both prob need edge 
>>> work at least). Those are the main things on my mind. There are probably a 
>>> ton of other little things, but I'm thinking those that are important will 
>>> rise up quickly and the rest can be handled over time.
>>> 
>>> This will be a large change. Some things will still take time to get up to 
>>> par with what we have now. Many things will need to be sorted out (jenkins, 
>>> releases, smoke tester type things, docs, etc).
>>> 
>>> I've also made all the decisions and trade-offs and what not. I'm pretty 
>>> happy about that, but I'm sure some will want to discuss and debate some 
>>> choices once things are in their face. I've spent a lot of time in my 
>>> recent life on this stuff and I'm ready to battle for some of it :) And to 
>>> be mistaken, ignorant, or convinced of other paths for some other parts of 
>>> it. I'll only say, every time I go from working with the gradle build back 
>>> to ant+ivy+mvn, it feels like a big backslide.
>>> 
>>> I'm thinking maybe in September/October? And only on master, hopefully 
>>> living side by side with ant+ivy+mvn, but the goal would be for that period 
>>> to be brief. They can't live in complete harmony - someone has to own the 
>>> dependency view of the world for example, the one that actually gets 
>>> committed (license, checksums, etc). Otherwise, I've done my best to do 
>>> this in a way that doesn't break the current build. Will need to inspect 
>>> that closer before landing though.
>>> 
>>> This is just another heads up. Once we are in a main branch, I'm hoping a 
>>> few of you will either have to jump in and help this land or we will have 
>>> to pull it back out I think. Be prepared :)
>>> 
>>> -- 
>>> - Mark
>>> 
>>> http://about.me/markrmiller
>> 
> 
> ___
> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
> http://www.opensourceconnections.com | My Free/Busy  
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed   
> This e-mail and all contents, including attachments, is considered to be 
> Company Confidential unless explicitly stated otherwise, regardless of 
> whether attachments are marked as such.
> 
> -- 
> - Mark
> 
> http://about.me/markrmiller


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

RE: The Gradle train.

[Uwe Schindler]

Hi,

 

I was talking with several people on berlinbuzzwords and we all agreed on one 
thing: Don’t keep the Ant, Maven and Gradle builds in parallel. IMHO, we should 
get rid of the Ant build ASAP, because it’s impossible to keep all three 
systems up to date at the same time.

 

I think the reason for the parallel builds was to have it easier to merge when 
the new branch was created. In addition, I think Mark was afraid that some 
people will complain. But I think people will complain more, iff they have to 
maintain 3 build systems in parallel.

 

In short: I’d like to get rid of the Ant/Maven build as soon as possible! I 
will also port over the Multirelease-JAR stuff in branch_8x, no worries!

 

I am on vacation the next 2 weeks, so if you switch now, I can’t help with 
changing Jenkins.

 

Uwe

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

https://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Jan Høydahl  
Sent: Friday, August 16, 2019 11:34 AM
To: dev@lucene.apache.org; markrmil...@gmail.com
Subject: Re: The Gradle train.

 

+1

 

Better to jump in now and have a few weeks of frustration and bug fixing from 
all of us than keeping this amazing improvement it a dark branch much longer :)

I'll probably also try to adapt releaseWidard.py on master to work with the new 
build..

 

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com  





15. aug. 2019 kl. 23:23 skrev Mark Miller mailto:markrmil...@gmail.com> >:

 

https://issues.apache.org/jira/projects/SOLR/issues/SOLR-13452 Update the 
lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

 

Okay, we are at the point where either this thing lands soon and gains some 
contributors to help finish or it  overwhelms me and crashes & burns. That 
almost sounds negative, but it was actually the plan so far and I'm pretty 
excited after all this time invested. I need to punt this over to the community 
though - the final implications and ramifications of moving fully to gradle are 
just too big for me individually regardless of the time frame.

 

I've done about 95%+ of what I wanted to do before trying to land something - a 
few more hoops to jump around. We pull in more deps than we should right now, 
I'll deal with that shortly, and mvn publishing needs work (mostly around 
solr-server, but dist and publishing both prob need edge work at least). Those 
are the main things on my mind. There are probably a ton of other little 
things, but I'm thinking those that are important will rise up quickly and the 
rest can be handled over time.

 

This will be a large change. Some things will still take time to get up to par 
with what we have now. Many things will need to be sorted out (jenkins, 
releases, smoke tester type things, docs, etc).

 

I've also made all the decisions and trade-offs and what not. I'm pretty happy 
about that, but I'm sure some will want to discuss and debate some choices once 
things are in their face. I've spent a lot of time in my recent life on this 
stuff and I'm ready to battle for some of it :) And to be mistaken, ignorant, 
or convinced of other paths for some other parts of it. I'll only say, every 
time I go from working with the gradle build back to ant+ivy+mvn, it feels like 
a big backslide.

 

I'm thinking maybe in September/October? And only on master, hopefully living 
side by side with ant+ivy+mvn, but the goal would be for that period to be 
brief. They can't live in complete harmony - someone has to own the dependency 
view of the world for example, the one that actually gets committed (license, 
checksums, etc). Otherwise, I've done my best to do this in a way that doesn't 
break the current build. Will need to inspect that closer before landing though.

 

This is just another heads up. Once we are in a main branch, I'm hoping a few 
of you will either have to jump in and help this land or we will have to pull 
it back out I think. Be prepared :)


 

-- 

- Mark

 

http://about.me/markrmiller

 

[jira] [Commented] (LUCENE-8565) SimpleQueryParser to support field filtering (aka Add field:text operator)

[Itamar Syn-Hershko (JIRA)]

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

Itamar Syn-Hershko commented on LUCENE-8565:


Heya - is this waiting for anything in particular that I can help in 
finalizing? Would really like to see this merged in. Thanks

> SimpleQueryParser to support field filtering (aka Add field:text operator)
> --
>
> Key: LUCENE-8565
> URL: https://issues.apache.org/jira/browse/LUCENE-8565
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/queryparser
>Reporter: Itamar Syn-Hershko
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> SimpleQueryParser lacks support for the `field:` operator for creating 
> queries which operate on fields other than the default field. Seems like one 
> can either get the parsed query to operate on a single field, or on ALL 
> defined fields (+ weights). No support for specifying `field:value` in the 
> query.
> It probably wasn't forgotten, but rather left out for simplicity, but since 
> we are using this QP implementation more and more (mostly through 
> Elasticsearch) we thought it would be useful to have it in.
> Seems like this is not too hard to pull off and I'll be happy to contribute a 
> patch for it.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

Re: Lucene/Solr Developer content

[Jan Høydahl]

Continuing the discussion about our new dev-docs. Seems to be consensus of 
using Asciidoc.

I proposed three separate guides:

> * /dev-docs : Common info i.e. Git, Pull requests, building, doing releases 
> etc. Publish in TLP site
> * /lucene/dev-guide : Lucene-specific developer content. Publish in Lucene 
> web site
> * /solr/dev-guide : Solr-specific developer content. Publish in Solr web site


It is obvious that Lucene and Solr needs separate guides, but could we instead 
of adding a third TLP guide use asciidoc  for a few common .adoc in 
both the Lucene and Solr guides to avoid duplication?

Don't yet know how the adoc -> html build would look like, there are several 
such tools out there and it is not given that we need to use the same tool as 
we do for the Solr RefGuide? Any thoughts?

If we can conclude on the framework we could create JIRAs and start adding the 
skeleton…
I also hope we can get some assistance from a Technical Writer in organizing 
the content, so we don't end up with one huge page or a random structure.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 17. jun. 2019 kl. 22:17 skrev Jan Høydahl :
> 
> Hi devs,
> 
> Today we have mainly two sources of developer documentation (apart from 
> Javadoc and refGuide):
> 
> * The websites. Very short instructions and linking to WIKI for in-depth
> * The old Moin wikis at wiki.apache.org with more details
> 
> Soon the old Moin wiki is being discontinued and I plan to migrate that 
> content to Confluence this week, see 
> https://issues.apache.org/jira/browse/LUCENE-8858 and 
> https://issues.apache.org/jira/browse/SOLR-13548
> 
> So the first step will be to just start using Confluence instead of Moin. 
> Help appreciated with the cleanup once the first migration is done in the two 
> JIRAs above. A LOT of the content in old WIKIs is outdated and a big cleanup 
> once this is in Confluence is highly needed!
> 
> 
> Someone has also suggested to move most developer resources found in the WIKI 
> into the main GIT code tree, so you have it right there with your git clone. 
> What I want to discuss here is more detailed how that would look like and 
> what info to move over.
> 
> One idea is to create one or more Asciidoc guides in the source tree, e.g
> 
> * /dev-docs : Common info i.e. Git, Pull requests, building, doing releases 
> etc. Publish in TLP site
> * /lucene/dev-guide : Lucene-specific developer content. Publish in Lucene 
> web site
> * /solr/dev-guide : Solr-specific developer content. Publish in Solr web site
> 
> These will be built with Jekyll by Jenkins, into nice HTML guides and 
> published to the web sites.
> 
> There may be other ways to do this as well, such as creating a new git repo 
> for dev docs, but I think people have good experience from Solr's ref-guide 
> with keeping code and docs in sync. What do you think?
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
> 

[jira] [Created] (SOLR-13703) LFUCache should support maxRamMB limit

[Andrzej Bialecki (JIRA)]

Andrzej Bialecki  created SOLR-13703:


 Summary: LFUCache should support maxRamMB limit
 Key: SOLR-13703
 URL: https://issues.apache.org/jira/browse/SOLR-13703
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Andrzej Bialecki 
Assignee: Andrzej Bialecki 


All other cache implementations in Solr support this limit, which is important 
from the operational point of view for limiting the overall resource 
consumption.

ConcurrentLFUCache already tracks memory usage so the implementation should be 
easy, and analogical to ConcurrentLRUCache.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13702) Some components register twice their metric names

[JIRA]

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

Jan Høydahl commented on SOLR-13702:


Did not find any other than these two. Will commit soon, trivial patch.

> Some components register twice their metric names
> -
>
> Key: SOLR-13702
> URL: https://issues.apache.org/jira/browse/SOLR-13702
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Andrzej Bialecki 
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Spin-off from SOLR-13700.
> Both {{AuditLoggerPlugin.initializeMetrics}} and 
> {{AuthenticationPlugin.initializeMetrics}} needlessly add metrics names to 
> {{metricNames}} - this is already done as a part of each respective metric 
> registration by using {{SolrInfoBean.this.registerName(name)}}.
> There may be other components that do this, too.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-13702) Some components register twice their metric names

[JIRA]

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

Jan Høydahl updated SOLR-13702:
---
Fix Version/s: 8.3

> Some components register twice their metric names
> -
>
> Key: SOLR-13702
> URL: https://issues.apache.org/jira/browse/SOLR-13702
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Andrzej Bialecki 
>Assignee: Jan Høydahl
>Priority: Minor
> Fix For: 8.3
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Spin-off from SOLR-13700.
> Both {{AuditLoggerPlugin.initializeMetrics}} and 
> {{AuthenticationPlugin.initializeMetrics}} needlessly add metrics names to 
> {{metricNames}} - this is already done as a part of each respective metric 
> registration by using {{SolrInfoBean.this.registerName(name)}}.
> There may be other components that do this, too.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Assigned] (SOLR-13702) Some components register twice their metric names

[JIRA]

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

Jan Høydahl reassigned SOLR-13702:
--

Assignee: Jan Høydahl

> Some components register twice their metric names
> -
>
> Key: SOLR-13702
> URL: https://issues.apache.org/jira/browse/SOLR-13702
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Andrzej Bialecki 
>Assignee: Jan Høydahl
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Spin-off from SOLR-13700.
> Both {{AuditLoggerPlugin.initializeMetrics}} and 
> {{AuthenticationPlugin.initializeMetrics}} needlessly add metrics names to 
> {{metricNames}} - this is already done as a part of each respective metric 
> registration by using {{SolrInfoBean.this.registerName(name)}}.
> There may be other components that do this, too.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

[Steve Davids (JIRA)]

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

Steve Davids commented on SOLR-13452:
-

I just noticed that this was being worked on via the mailing list and am glad 
that the build system is being modernized. I have been working with Gradle for 
quite some time now and have found that moving to gradle's kotlin script to be 
very nice for code completion + static analysis (IntelliJ support is 
fantastic). I wanted to provide an example of two files of what a build.gradle 
vs build.gradle.kts file would like like here:

[https://github.com/apache/lucene-solr/compare/jira/SOLR-13452_gradle_5...sdavids13:jira/SOLR-13452_gradle_5]

If you would like to move towards adopting Kotlin script I can help out (I have 
migrated all of my work builds over to kts so have some experience doing so). 
The nice thing being is that you can migrate one file at a time as both the 
older style `build.gradle` and newer style `build.gradle.kts` can co-exist in 
the same repository as migrations take place.

> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13699) maxChars no longer working as designed on CopyField

[Chris Troullis (JIRA)]

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

Chris Troullis commented on SOLR-13699:
---

The fix I have was just to basically add another instanceOf check to handle the 
ByteArrayUtf8CharSequence, which I agree is not the best solution. It does seem 
like there have been a number of regressions created by the optimization. I'm 
not sure I understand enough about the intent of the original change to make 
any kind of larger scale refactor.

Let me know if you still think it's worth submitting my patch, or if you'd 
prefer to revisit the design of the original optimization.

> maxChars no longer working as designed on CopyField
> ---
>
> Key: SOLR-13699
> URL: https://issues.apache.org/jira/browse/SOLR-13699
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.0.1, 8.1, 8.2, 7.7.3, 8.1.1, 
> 8.1.2
>Reporter: Chris Troullis
>Assignee: Erick Erickson
>Priority: Major
>
> We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars 
> property on a copy field is no longer functioning as designed, while indexing 
> via SolrJ. Per the most recent documentation it looks like there have been no 
> intentional changes as to the functionality of this property, so I assume 
> this is a bug.
>   
>  In debugging the issue, it looks like the bug was caused by SOLR-12992. In 
> DocumentBuilder where the maxChar limit is applied, it first checks if the 
> value is instanceof String. As of SOLR-12992, string values are now coming in 
> as ByteArrayUtf8CharSequence (unless they are above a certain size as defined 
> by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String 
> check, and the maxChar truncation is not being applied. I am currently not 
> sure if this issue is limited to indexing via SolrJ or if it applies to 
> documents indexed via any means



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[GitHub] [lucene-solr] janhoy opened a new pull request #834: SOLR-13702: Some components register twice their metric names

[GitBox]

janhoy opened a new pull request #834: SOLR-13702: Some components register 
twice their metric names
URL: https://github.com/apache/lucene-solr/pull/834
 
 
   # Description
   
   See https://issues.apache.org/jira/browse/SOLR-13702
   
   # Solution
   
   Remove explicit name registration.
   
   # Tests
   
   No tests failed, existing tests still pass after patch.
   
   # Checklist
   
   Please review the following and check all that apply:
   
   - [x] I have reviewed the guidelines for [How to 
Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms 
to the standards described there to the best of my ability.
   - [x] I have created a Jira issue and added the issue ID to my pull request 
title.
   - [x] I am authorized to contribute this code to the ASF and have removed 
any code I do not have a license to distribute.
   - [x] I have developed this patch against the `master` branch.
   - [x] I have run `ant precommit` and the appropriate test suite.
   - [x] I have added tests for my changes. (pre-existing)
   - [-] I have added documentation for the [Ref 
Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) 
(for Solr changes only).


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


With regards,
Apache Git Services

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

[jira] [Created] (SOLR-13702) Some components register twice their metric names

[Andrzej Bialecki (JIRA)]

Andrzej Bialecki  created SOLR-13702:


 Summary: Some components register twice their metric names
 Key: SOLR-13702
 URL: https://issues.apache.org/jira/browse/SOLR-13702
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Andrzej Bialecki 


Spin-off from SOLR-13700.

Both {{AuditLoggerPlugin.initializeMetrics}} and 
{{AuthenticationPlugin.initializeMetrics}} needlessly add metrics names to 
{{metricNames}} - this is already done as a part of each respective metric 
registration by using {{SolrInfoBean.this.registerName(name)}}.

There may be other components that do this, too.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13700) Race condition in initializing metrics for new security plugins when security.json is modified

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-13700:
--

[~janhoy] created SOLR-13702.

> Race condition in initializing metrics for new security plugins when 
> security.json is modified
> --
>
> Key: SOLR-13700
> URL: https://issues.apache.org/jira/browse/SOLR-13700
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13700.patch
>
>
> When new security plugins are initialized due to remote API requetss, there 
> is a delay between "registering" the new plugins for use in methods like 
> {{initializeAuthenticationPlugin()}} (by assigning them to CoreContainer's 
> volatile {{this.authenticationPlugin}} variable) and when the 
> {{initializeMetrics(..)}} method is called on these plugins, so that they 
> continue to use the existing {{Metric}} instances as the plugins they are 
> replacing.
> Because these security plugins maintain local refrences to these Metrics (and 
> don't "get" them from the MetricRegisty everytime they need to {{inc()}} 
> them) this means that there is short race condition situation such that 
> during the window of time after a new plugin instance is put into use, but 
> before  {{initializeMetrics(..)}} is called on them, at these plugins are 
> responsible for accepting/rejecting requests, and decisions in {{Metric}} 
> instances that are not registered and subsequently get thrown away (and GCed) 
> once the CoreContainer gets around to calling {{initializeMetrics(..)}} (and 
> the plugin starts using the pre-existing metric objects)
> 
> This has some noticible impacts on auth tests on CPU constrained jenkins 
> machines (even after putting in place SOLR-13464 work arounds) that make 
> assertions about the metrics recorded.
> In real world situations, the impact of this bug on users is minor: for a few 
> micro/milli-seconds, requests may come in w/o being counted in the auth 
> metrics -- which may also result in descrepencies between the auth metrics 
> totals and the overall request metrics.  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[JENKINS] Lucene-Solr-8.x-Windows (64bit/jdk-12.0.1) - Build # 403 - Still Unstable!

[Policeman Jenkins Server]

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

8 tests failed.
FAILED:  org.apache.solr.handler.TestReplicationHandlerBackup.doTestBackup

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([164C7F30E0996375]:0)


FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.TestReplicationHandlerBackup

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([164C7F30E0996375]:0)


FAILED:  
org.apache.solr.cloud.LegacyCloudClusterPropTest.testCreateCollectionSwitchLegacyCloud

Error Message:
IOException occurred when talking to server at: https://127.0.0.1:50917/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occurred when 
talking to server at: https://127.0.0.1:50917/solr
at 
__randomizedtesting.SeedInfo.seed([164C7F30E0996375:C74B8DB54496E847]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:670)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1128)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228)
at 
org.apache.solr.cloud.LegacyCloudClusterPropTest.createAndTest(LegacyCloudClusterPropTest.java:87)
at 
org.apache.solr.cloud.LegacyCloudClusterPropTest.testCreateCollectionSwitchLegacyCloud(LegacyCloudClusterPropTest.java:79)
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(AbstractBeforeAfterR

[jira] [Commented] (SOLR-13700) Race condition in initializing metrics for new security plugins when security.json is modified

[JIRA]

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

Jan Høydahl commented on SOLR-13700:


{quote}Also, I just spotted that both {{AuditLoggerPlugin.initializeMetrics}} 
and {{AuthenticationPlugin.initializeMetrics}}needlessly add metrics names to 
{{metricNames}} - this is already done as a part of each respective metric 
registration by using {{SolrInfoBean.this.registerName(name)}}.
{quote}
Can you file a new Jira for this one and I'll grab it? Don't remember which 
class I used as template back then, but there may be other places to clean up 
too.

> Race condition in initializing metrics for new security plugins when 
> security.json is modified
> --
>
> Key: SOLR-13700
> URL: https://issues.apache.org/jira/browse/SOLR-13700
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13700.patch
>
>
> When new security plugins are initialized due to remote API requetss, there 
> is a delay between "registering" the new plugins for use in methods like 
> {{initializeAuthenticationPlugin()}} (by assigning them to CoreContainer's 
> volatile {{this.authenticationPlugin}} variable) and when the 
> {{initializeMetrics(..)}} method is called on these plugins, so that they 
> continue to use the existing {{Metric}} instances as the plugins they are 
> replacing.
> Because these security plugins maintain local refrences to these Metrics (and 
> don't "get" them from the MetricRegisty everytime they need to {{inc()}} 
> them) this means that there is short race condition situation such that 
> during the window of time after a new plugin instance is put into use, but 
> before  {{initializeMetrics(..)}} is called on them, at these plugins are 
> responsible for accepting/rejecting requests, and decisions in {{Metric}} 
> instances that are not registered and subsequently get thrown away (and GCed) 
> once the CoreContainer gets around to calling {{initializeMetrics(..)}} (and 
> the plugin starts using the pre-existing metric objects)
> 
> This has some noticible impacts on auth tests on CPU constrained jenkins 
> machines (even after putting in place SOLR-13464 work arounds) that make 
> assertions about the metrics recorded.
> In real world situations, the impact of this bug on users is minor: for a few 
> micro/milli-seconds, requests may come in w/o being counted in the auth 
> metrics -- which may also result in descrepencies between the auth metrics 
> totals and the overall request metrics.  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

Issues with fixVersion = 8.1.2

[Cassandra Targett]

There are 7 resolved/closed issues with the fixVersion 8.1.2. Since that 
version was never released, it’s misleading to leave only a fixVersion that was 
never released. We know we can assume 8.2, but the average user may not.

Shouldn’t these all be changed to 8.2?

Cassandra

[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

[Tomoko Uchida (JIRA)]

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

Tomoko Uchida commented on SOLR-13452:
--

bq. probably not a bad time to start looking at support for intellij? I think 
from that perspective things are in fairly good shape.

Okay, I will try it out this weekend.

> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-13452:
--

For the docs, there is a plugin for Gradle from the Asciidoctor community 
(https://github.com/asciidoctor/asciidoctor-gradle-plugin), which is (IMO) 
better and more frequently maintained than the one currently we use for Ant. 
That would take care of the PDF. Since we use Jekyll for the HTML version, 
though, that's going to work a little differently and I'll start taking a look 
at what we might need to do there.

> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[JENKINS] Lucene-Solr-Tests-master - Build # 3567 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3567/

All tests passed

Build Log:
[...truncated 64527 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj57339970
 [ecj-lint] Compiling 69 source files to /tmp/ecj57339970
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
 [ecj-lint] --
 [ecj-lint] 1. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
 (at line 28)
 [ecj-lint] import javax.naming.InitialContext;
 [ecj-lint]^^^
 [ecj-lint] The type javax.naming.InitialContext is not accessible
 [ecj-lint] --
 [ecj-lint] 2. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
 (at line 29)
 [ecj-lint] import javax.naming.NamingException;
 [ecj-lint]
 [ecj-lint] The type javax.naming.NamingException is not accessible
 [ecj-lint] --
 [ecj-lint] 3. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
 (at line 182)
 [ecj-lint] c = getFromJndi(initProps, jndiName);
 [ecj-lint] ^^^
 [ecj-lint] The method getFromJndi(Properties, String) from the type new 
Callable(){} refers to the missing type NamingException
 [ecj-lint] --
 [ecj-lint] 4. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
 (at line 245)
 [ecj-lint] private Connection getFromJndi(final Properties initProps, 
final String jndiName) throws NamingException,
 [ecj-lint] 
 ^^^
 [ecj-lint] NamingException cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 5. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
 (at line 249)
 [ecj-lint] InitialContext ctx =  new InitialContext();
 [ecj-lint] ^^
 [ecj-lint] InitialContext cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 6. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
 (at line 249)
 [ecj-lint] InitialContext ctx =  new InitialContext();
 [ecj-lint]   ^^
 [ecj-lint] InitialContext cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 6 problems (6 errors)

BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/build.xml:634: 
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/build.xml:101: 
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/build.xml:651:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/common-build.xml:479:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/common-build.xml:2009:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/common-build.xml:2048:
 Compile failed; see the compiler error output for details.

Total time: 98 minutes 39 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

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

[Apache Jenkins Server]

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

[...truncated 28 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/182/consoleText

[repro] Revision: e6df368e533e1a41e6b988d19a0b3aa89538e208

[repro] Ant options: -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt
[repro] Repro line:  ant test  -Dtestcase=HdfsAutoAddReplicasIntegrationTest 
-Dtests.method=testSimple -Dtests.seed=681B2A16D2DFB4D4 -Dtests.multiplier=2 
-Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=es-CL -Dtests.timezone=Etc/GMT-1 -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
54ab07718a016c888e69ff4a8070c24cf34d3a51
[repro] git fetch
[repro] git checkout e6df368e533e1a41e6b988d19a0b3aa89538e208

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

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

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]solr/core
[repro]   HdfsAutoAddReplicasIntegrationTest
[repro] ant compile-test

[...truncated 3577 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.HdfsAutoAddReplicasIntegrationTest" -Dtests.showOutput=onerror 
-Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt
 -Dtests.seed=681B2A16D2DFB4D4 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=es-CL -Dtests.timezone=Etc/GMT-1 -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

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

[repro] Failures:
[repro]   2/5 failed: 
org.apache.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest
[repro] git checkout 54ab07718a016c888e69ff4a8070c24cf34d3a51

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

[JENKINS] Lucene-Solr-repro-Java11 - Build # 325 - Unstable

[Apache Jenkins Server]

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

[...truncated 32 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-Tests-master/3566/consoleText

[repro] Revision: 54ab07718a016c888e69ff4a8070c24cf34d3a51

[repro] Repro line:  ant test  -Dtestcase=SystemCollectionCompatTest 
-Dtests.method=testBackCompat -Dtests.seed=7BF195631B314E4A 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=kk 
-Dtests.timezone=America/Eirunepe -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=TestCloudJSONFacetSKG 
-Dtests.method=testRandom -Dtests.seed=7BF195631B314E4A -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=bs-Latn -Dtests.timezone=America/Santiago 
-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: 
54ab07718a016c888e69ff4a8070c24cf34d3a51
[repro] git fetch

[...truncated 7 lines...]
[repro] git checkout 54ab07718a016c888e69ff4a8070c24cf34d3a51

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

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

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]solr/core
[repro]   TestCloudJSONFacetSKG
[repro]   SystemCollectionCompatTest
[repro] ant compile-test

[...truncated 3315 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=10 
-Dtests.class="*.TestCloudJSONFacetSKG|*.SystemCollectionCompatTest" 
-Dtests.showOutput=onerror  -Dtests.seed=7BF195631B314E4A -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=bs-Latn -Dtests.timezone=America/Santiago 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8

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

[repro] Failures:
[repro]   0/5 failed: org.apache.solr.cloud.SystemCollectionCompatTest
[repro]   2/5 failed: org.apache.solr.search.facet.TestCloudJSONFacetSKG
[repro] git checkout 54ab07718a016c888e69ff4a8070c24cf34d3a51

[...truncated 1 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-13700) Race condition in initializing metrics for new security plugins when security.json is modified

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-13700:
--

ad 1: yes, it's correct - the instances of these metrics are reused by all 
instances of respective plugins, so if the "old" instance was still processing 
an in-flight request it will still be counted, while the new instance may 
already handle new requests and use the same counters. It's perfectly ok.

ad 2: this seems like a confusion between referring to 
{{pkiAuthenticationPlugin}} (which stays unchanged) and 
{{authenticationPlugin}} (which may have changed). It's correct we don't need 
this here.

Also, I think the call to {{initializeMetrics}} should be done in each of 
{{initializeAuditloggerPlugin}} and {{initializeAuthenticationPlugin}}, then 
it's easier to avoid confusion because within the scope of these methods it's 
obvious that a new instance is created which needs to be initialized.

Also, I just spotted that both {{AuditLoggerPlugin.initializeMetrics}} and 
{{AuthenticationPlugin.initializeMetrics}} needlessly add metrics names to 
{{metricNames}} - this is already done as a part of each respective metric 
registration by using {{SolrInfoBean.this.registerName(name)}}.

> Race condition in initializing metrics for new security plugins when 
> security.json is modified
> --
>
> Key: SOLR-13700
> URL: https://issues.apache.org/jira/browse/SOLR-13700
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13700.patch
>
>
> When new security plugins are initialized due to remote API requetss, there 
> is a delay between "registering" the new plugins for use in methods like 
> {{initializeAuthenticationPlugin()}} (by assigning them to CoreContainer's 
> volatile {{this.authenticationPlugin}} variable) and when the 
> {{initializeMetrics(..)}} method is called on these plugins, so that they 
> continue to use the existing {{Metric}} instances as the plugins they are 
> replacing.
> Because these security plugins maintain local refrences to these Metrics (and 
> don't "get" them from the MetricRegisty everytime they need to {{inc()}} 
> them) this means that there is short race condition situation such that 
> during the window of time after a new plugin instance is put into use, but 
> before  {{initializeMetrics(..)}} is called on them, at these plugins are 
> responsible for accepting/rejecting requests, and decisions in {{Metric}} 
> instances that are not registered and subsequently get thrown away (and GCed) 
> once the CoreContainer gets around to calling {{initializeMetrics(..)}} (and 
> the plugin starts using the pre-existing metric objects)
> 
> This has some noticible impacts on auth tests on CPU constrained jenkins 
> machines (even after putting in place SOLR-13464 work arounds) that make 
> assertions about the metrics recorded.
> In real world situations, the impact of this bug on users is minor: for a few 
> micro/milli-seconds, requests may come in w/o being counted in the auth 
> metrics -- which may also result in descrepencies between the auth metrics 
> totals and the overall request metrics.  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-11.0.3) - Build # 24554 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24554/
Java: 64bit/jdk-11.0.3 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.search.facet.TestCloudJSONFacetSKG.testRandom

Error Message:
Error from server at 
https://127.0.0.1:34165/solr/org.apache.solr.search.facet.TestCloudJSONFacetSKG_collection:
 Expected mime type application/octet-stream but got text/html.   
 
Error 500 Server Error  HTTP ERROR 500 
Problem accessing 
/solr/org.apache.solr.search.facet.TestCloudJSONFacetSKG_collection/select. 
Reason: Server ErrorCaused 
by:java.lang.AssertionError  at 
java.base/java.util.HashMap$TreeNode.moveRootToFront(HashMap.java:1896)  at 
java.base/java.util.HashMap$TreeNode.putTreeVal(HashMap.java:2061)  at 
java.base/java.util.HashMap.putVal(HashMap.java:633)  at 
java.base/java.util.HashMap.put(HashMap.java:607)  at 
org.apache.solr.search.LRUCache.put(LRUCache.java:196)  at 
org.apache.solr.search.SolrCacheHolder.put(SolrCacheHolder.java:46)  at 
org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1449)
  at 
org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:568)  at 
org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryComponent.java:1484)
  at 
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:398)
  at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:305)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:198)
  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2581)  at 
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:780)  at 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:423)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:350)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:165)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) 
 at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
  at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1711)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1347)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1678)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1249)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)  
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:753)  
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) 
 at org.eclipse.jetty.server.Server.handle(Server.java:505)  at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370)  at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267)  at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)  at 
org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:427)
  at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:321)  
at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159)  
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)  at 
org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)  at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:781)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:917)
  at java.base/java.lang.Thread.run(Thread.java:834)  http://eclipse.org/jetty";>Powered by Jetty:// 9.4.19.v20190610  
  

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at 
https://127.0.0.1:34165/solr/org.apache.solr.search.facet.TestCloudJSONFacetSKG_collection:
 Expected mime type application/octet-stream but got text/html. 


Error 500 Server Error

HTTP ERROR 500
Problem accessing 
/solr/org.apache.solr.search.facet.TestCloudJSONFacetSKG_collection/select. 
Reason:
Server ErrorCaused by:java.lang.AssertionError
at 
java.base/java.util.HashMap$TreeNode.moveRootToFront(HashMap.java:1896)
at j

Re: The Gradle train.

[Mark Miller]

Perhaps better for me as well (I couldn’t help myself and started
addressing compiler warnings to clean up build output since gradle keeps
the output so compact when its not dumping warning output), my main hold
off is that I want to be available and engaged when it goes in. I’d like to
target early sept, but I don’t want to commit and then delay, so I gave a
little room.

Mark

On Fri, Aug 16, 2019 at 6:54 AM Eric Pugh 
wrote:

> Sooner is better!  I’m reading up on Gradle now ;-)
>
>
> On Aug 16, 2019, at 5:33 AM, Jan Høydahl  wrote:
>
> +1
>
> Better to jump in now and have a few weeks of frustration and bug fixing
> from all of us than keeping this amazing improvement it a dark branch much
> longer :)
> I'll probably also try to adapt releaseWidard.py on master to work with
> the new build..
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> 15. aug. 2019 kl. 23:23 skrev Mark Miller :
>
> https://issues.apache.org/jira/projects/SOLR/issues/SOLR-13452 Update the
> lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
>
> Okay, we are at the point where either this thing lands soon and gains
> some contributors to help finish or it  overwhelms me and crashes & burns.
> That almost sounds negative, but it was actually the plan so far and I'm
> pretty excited after all this time invested. I need to punt this over to
> the community though - the final implications and ramifications of moving
> fully to gradle are just too big for me individually regardless of the time
> frame.
>
> I've done about 95%+ of what I wanted to do before trying to land
> something - a few more hoops to jump around. We pull in more deps than we
> should right now, I'll deal with that shortly, and mvn publishing needs
> work (mostly around solr-server, but dist and publishing both prob need
> edge work at least). Those are the main things on my mind. There are
> probably a ton of other little things, but I'm thinking those that are
> important will rise up quickly and the rest can be handled over time.
>
> This will be a large change. Some things will still take time to get up to
> par with what we have now. Many things will need to be sorted out (jenkins,
> releases, smoke tester type things, docs, etc).
>
> I've also made all the decisions and trade-offs and what not. I'm pretty
> happy about that, but I'm sure some will want to discuss and debate some
> choices once things are in their face. I've spent a lot of time in my
> recent life on this stuff and I'm ready to battle for some of it :) And to
> be mistaken, ignorant, or convinced of other paths for some other parts of
> it. I'll only say, every time I go from working with the gradle build back
> to ant+ivy+mvn, it feels like a big backslide.
>
> I'm thinking maybe in September/October? And only on master, hopefully
> living side by side with ant+ivy+mvn, but the goal would be for that period
> to be brief. They can't live in complete harmony - someone has to own the
> dependency view of the world for example, the one that actually gets
> committed (license, checksums, etc). Otherwise, I've done my best to do
> this in a way that doesn't break the current build. Will need to inspect
> that closer before landing though.
>
> This is just another heads up. Once we are in a main branch, I'm hoping a
> few of you will either have to jump in and help this land or we will have
> to pull it back out I think. Be prepared :)
>
> --
> - Mark
>
> http://about.me/markrmiller
>
>
>
> ___
> *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | 434.466.1467
> | http://www.opensourceconnections.com | My Free/Busy
> 
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> 
> This e-mail and all contents, including attachments, is considered to be
> Company Confidential unless explicitly stated otherwise, regardless
> of whether attachments are marked as such.
>
> --
- Mark

http://about.me/markrmiller

Re: The Gradle train.

[Eric Pugh]

Sooner is better!  I’m reading up on Gradle now ;-)


> On Aug 16, 2019, at 5:33 AM, Jan Høydahl  wrote:
> 
> +1
> 
> Better to jump in now and have a few weeks of frustration and bug fixing from 
> all of us than keeping this amazing improvement it a dark branch much longer 
> :)
> I'll probably also try to adapt releaseWidard.py on master to work with the 
> new build..
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com 
> 
>> 15. aug. 2019 kl. 23:23 skrev Mark Miller > >:
>> 
>> https://issues.apache.org/jira/projects/SOLR/issues/SOLR-13452 
>>  Update the 
>> lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
>> 
>> Okay, we are at the point where either this thing lands soon and gains some 
>> contributors to help finish or it  overwhelms me and crashes & burns. That 
>> almost sounds negative, but it was actually the plan so far and I'm pretty 
>> excited after all this time invested. I need to punt this over to the 
>> community though - the final implications and ramifications of moving fully 
>> to gradle are just too big for me individually regardless of the time frame.
>> 
>> I've done about 95%+ of what I wanted to do before trying to land something 
>> - a few more hoops to jump around. We pull in more deps than we should right 
>> now, I'll deal with that shortly, and mvn publishing needs work (mostly 
>> around solr-server, but dist and publishing both prob need edge work at 
>> least). Those are the main things on my mind. There are probably a ton of 
>> other little things, but I'm thinking those that are important will rise up 
>> quickly and the rest can be handled over time.
>> 
>> This will be a large change. Some things will still take time to get up to 
>> par with what we have now. Many things will need to be sorted out (jenkins, 
>> releases, smoke tester type things, docs, etc).
>> 
>> I've also made all the decisions and trade-offs and what not. I'm pretty 
>> happy about that, but I'm sure some will want to discuss and debate some 
>> choices once things are in their face. I've spent a lot of time in my recent 
>> life on this stuff and I'm ready to battle for some of it :) And to be 
>> mistaken, ignorant, or convinced of other paths for some other parts of it. 
>> I'll only say, every time I go from working with the gradle build back to 
>> ant+ivy+mvn, it feels like a big backslide.
>> 
>> I'm thinking maybe in September/October? And only on master, hopefully 
>> living side by side with ant+ivy+mvn, but the goal would be for that period 
>> to be brief. They can't live in complete harmony - someone has to own the 
>> dependency view of the world for example, the one that actually gets 
>> committed (license, checksums, etc). Otherwise, I've done my best to do this 
>> in a way that doesn't break the current build. Will need to inspect that 
>> closer before landing though.
>> 
>> This is just another heads up. Once we are in a main branch, I'm hoping a 
>> few of you will either have to jump in and help this land or we will have to 
>> pull it back out I think. Be prepared :)
>> 
>> -- 
>> - Mark
>> 
>> http://about.me/markrmiller 
> 

___
Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
http://www.opensourceconnections.com  | 
My Free/Busy   
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed 


This e-mail and all contents, including attachments, is considered to be 
Company Confidential unless explicitly stated otherwise, regardless of whether 
attachments are marked as such.

[JENKINS] Lucene-Solr-SmokeRelease-8.x - Build # 181 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/181/

No tests ran.

Build Log:
[...truncated 24869 lines...]
[asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: 
invalid part, must have at least one section (e.g., chapter, appendix, etc.)
[asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid 
part, must have at least one section (e.g., chapter, appendix, etc.)
 [java] Processed 2594 links (2120 relative) to 3410 anchors in 259 files
 [echo] Validated Links & Anchors via: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr-ref-guide/bare-bones-html/

-dist-changes:
 [copy] Copying 4 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/package/changes

package:

-unpack-solr-tgz:

-ensure-solr-tgz-exists:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr.tgz.unpacked
[untar] Expanding: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/package/solr-8.3.0.tgz
 into 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr.tgz.unpacked

generate-maven-artifacts:

resolve:

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml

resolve:

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:c

[jira] [Commented] (LUCENE-7379) Search word request on Chinese is not working properly

[Chongchen Chen (JIRA)]

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

Chongchen Chen commented on LUCENE-7379:


I think the tokenizer behaves as it should. if you want better Chinese 
tokenization.[Hanlp|https://github.com/hankcs/hanlp-lucene-plugin] is a better 
choice.

> Search word request on Chinese is not working properly
> --
>
> Key: LUCENE-7379
> URL: https://issues.apache.org/jira/browse/LUCENE-7379
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/queryparser
>Affects Versions: 5.0
>Reporter: Alex Simatov
>Priority: Major
>
> Originally we used Lucene 2.3 in the project for years.
> Some time ago we made an update to the 5.0.0 version of Lucene.
> After that Chinese analyzing stopped working normally (I did not test it on 
> Japanese or Korean)
> We have the following code to process the search request:
> 1. analyzer = new ClassicAnalyzer();
> 2. logger.Write2Log(queryString);
> 3. QueryParser qp = new QueryParser(fieldName, analyzer);
> 4. Query query = qp.parse(queryString);
> 5. logger.Write2Log(query.toString(fieldName));
> 6. int hits = searcher.search(query, 1).totalHits;
> Analyzer on line 1 could be changed by config.
> Line 2 is printing what we put to the Lucene.
> Line 5 is printing how the query modified in Lucene
> Normally we are using the string 打不开~0.7 for 70% or more accuracy and  打不开 to 
> find exact this word.
> ~0.7 functionality was marked as deprecated since 4.0 version, however it is 
> still worked on English at least.
> What was before (on Lucene 2.3):
> Line 2: 打不开~0.7 
> Line 5: 打不开~0.7
> If we provide the correct string for analysis, line 6 returns correct result
> The same for case of 打不开 without accuracy (without ~0.7)
> What is now (on Lucene 5.0):
> Line 2: 打不开~0.7 
> Line 5: 打不开~0
> As I understood it is modifying of deprecated parameter to newly supported 
> one with a little different meaning (at least it is working like I said on 
> English).
> The string for analysis contains the 打不开, however line 6 shows nothing is 
> found.
> Line 2: 打不开 
> Line 5: 打 不 开
> Lucene added spaces, which are interpreted as OR operator. As result Line 6 
> returns that keyword found even if it is only one 不 symbol in the string for 
> analysis.
> The same scenario was tested on the CJKAnalyzer, ClassicAnalyzer  and 
> SmartChineseAnalyzer. Results are the same: neither one of them has the same 
> functionality as analyzer on Lucene 2.3
> Is it known problem in the product? Could you please explain or provide any 
> docs about how the search should work for Chinese in mentioned cases.
> Thanks



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[JENKINS] Lucene-Solr-8.x-Linux (64bit/jdk-11.0.3) - Build # 1026 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/1026/
Java: 64bit/jdk-11.0.3 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.search.facet.TestCloudJSONFacetJoinDomain.testRandom

Error Message:
Error from server at 
https://127.0.0.1:44317/solr/org.apache.solr.search.facet.TestCloudJSONFacetJoinDomain_collection:
 Expected mime type application/octet-stream but got text/html.   
 
Error 500 Server Error  HTTP ERROR 500 
Problem accessing 
/solr/org.apache.solr.search.facet.TestCloudJSONFacetJoinDomain_collection/select.
 Reason: Server ErrorCaused 
by:java.lang.AssertionError  at 
java.base/java.util.HashMap$TreeNode.moveRootToFront(HashMap.java:1896)  at 
java.base/java.util.HashMap$TreeNode.putTreeVal(HashMap.java:2061)  at 
java.base/java.util.HashMap.putVal(HashMap.java:633)  at 
java.base/java.util.HashMap.put(HashMap.java:607)  at 
org.apache.solr.search.LRUCache.put(LRUCache.java:196)  at 
org.apache.solr.search.SolrCacheHolder.put(SolrCacheHolder.java:46)  at 
org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1449)
  at 
org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:568)  at 
org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryComponent.java:1484)
  at 
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:398)
  at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:305)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:198)
  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2592)  at 
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:780)  at 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:423)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:350)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:165)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) 
 at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
  at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1711)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1347)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1678)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1249)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)  
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:753)  
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) 
 at org.eclipse.jetty.server.Server.handle(Server.java:505)  at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370)  at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267)  at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)  at 
org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:427)
  at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:321)  
at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159)  
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)  at 
org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)  at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:781)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:917)
  at java.base/java.lang.Thread.run(Thread.java:834)  http://eclipse.org/jetty";>Powered by Jetty:// 9.4.19.v20190610  
  

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at 
https://127.0.0.1:44317/solr/org.apache.solr.search.facet.TestCloudJSONFacetJoinDomain_collection:
 Expected mime type application/octet-stream but got text/html. 


Error 500 Server Error

HTTP ERROR 500
Problem accessing 
/solr/org.apache.solr.search.facet.TestCloudJSONFacetJoinDomain_collection/select.
 Reason:
Server ErrorCaused by:java.lang.AssertionError
at 
java.base/java.util.HashMap$TreeNode.moveRootToFront(HashMap

[JENKINS-EA] Lucene-Solr-master-Windows (64bit/jdk-14-ea+9) - Build # 8090 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/8090/
Java: 64bit/jdk-14-ea+9 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

5 tests failed.
FAILED:  
org.apache.solr.cloud.LegacyCloudClusterPropTest.testCreateCollectionSwitchLegacyCloud

Error Message:
IOException occurred when talking to server at: https://127.0.0.1:61975/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occurred when 
talking to server at: https://127.0.0.1:61975/solr
at 
__randomizedtesting.SeedInfo.seed([1B70B88548FD8946:CA774A00ECF20274]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:670)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1128)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228)
at 
org.apache.solr.cloud.LegacyCloudClusterPropTest.createAndTest(LegacyCloudClusterPropTest.java:87)
at 
org.apache.solr.cloud.LegacyCloudClusterPropTest.testCreateCollectionSwitchLegacyCloud(LegacyCloudClusterPropTest.java:79)
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:565)
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.StatementAdapt

Re: The Gradle train.

[Jan Høydahl]

+1

Better to jump in now and have a few weeks of frustration and bug fixing from 
all of us than keeping this amazing improvement it a dark branch much longer :)
I'll probably also try to adapt releaseWidard.py on master to work with the new 
build..

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 15. aug. 2019 kl. 23:23 skrev Mark Miller :
> 
> https://issues.apache.org/jira/projects/SOLR/issues/SOLR-13452 
>  Update the 
> lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> 
> Okay, we are at the point where either this thing lands soon and gains some 
> contributors to help finish or it  overwhelms me and crashes & burns. That 
> almost sounds negative, but it was actually the plan so far and I'm pretty 
> excited after all this time invested. I need to punt this over to the 
> community though - the final implications and ramifications of moving fully 
> to gradle are just too big for me individually regardless of the time frame.
> 
> I've done about 95%+ of what I wanted to do before trying to land something - 
> a few more hoops to jump around. We pull in more deps than we should right 
> now, I'll deal with that shortly, and mvn publishing needs work (mostly 
> around solr-server, but dist and publishing both prob need edge work at 
> least). Those are the main things on my mind. There are probably a ton of 
> other little things, but I'm thinking those that are important will rise up 
> quickly and the rest can be handled over time.
> 
> This will be a large change. Some things will still take time to get up to 
> par with what we have now. Many things will need to be sorted out (jenkins, 
> releases, smoke tester type things, docs, etc).
> 
> I've also made all the decisions and trade-offs and what not. I'm pretty 
> happy about that, but I'm sure some will want to discuss and debate some 
> choices once things are in their face. I've spent a lot of time in my recent 
> life on this stuff and I'm ready to battle for some of it :) And to be 
> mistaken, ignorant, or convinced of other paths for some other parts of it. 
> I'll only say, every time I go from working with the gradle build back to 
> ant+ivy+mvn, it feels like a big backslide.
> 
> I'm thinking maybe in September/October? And only on master, hopefully living 
> side by side with ant+ivy+mvn, but the goal would be for that period to be 
> brief. They can't live in complete harmony - someone has to own the 
> dependency view of the world for example, the one that actually gets 
> committed (license, checksums, etc). Otherwise, I've done my best to do this 
> in a way that doesn't break the current build. Will need to inspect that 
> closer before landing though.
> 
> This is just another heads up. Once we are in a main branch, I'm hoping a few 
> of you will either have to jump in and help this land or we will have to pull 
> it back out I think. Be prepared :)
> 
> -- 
> - Mark
> 
> http://about.me/markrmiller 

[jira] [Commented] (SOLR-13701) JWTAuthPlugin calls authenticationFailure (which calls HttpServletResponsesendError) before updating metrics - breaks tests

[JIRA]

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

Jan Høydahl commented on SOLR-13701:


Updating metrics before returning sounds reasonable since we assert on those 
counts (which has proven fragile).

I don't see the motivation to remove the Test-code 2s retry yet, unless 
extensive beasting proves that it is no longer needed?

> JWTAuthPlugin calls authenticationFailure (which calls 
> HttpServletResponsesendError) before updating metrics - breaks tests
> ---
>
> Key: SOLR-13701
> URL: https://issues.apache.org/jira/browse/SOLR-13701
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13701.patch
>
>
> The way JWTAuthPlugin is currently implemented, any failures are sent to the 
> remote client (via {{authenticationFailure(...)}} which calls 
> {{HttpServletResponsesendError(...)}}) *before* 
> {{JWTAuthPlugin.doAuthenticate(...)}} has a chance to update it's metrics 
> (like {{numErrors}} and {{numWrongCredentials}})
> This causes a race condition in tests where test threads can:
>  * see an error response/Exception before the server thread has updated 
> metrics (like {{numErrors}} and {{numWrongCredentials}})
>  * call white box methods like 
> {{SolrCloudAuthTestCase.assertAuthMetricsMinimums(...)}} to assert expected 
> metrics
> ...all before the server thread has ever gotten around to being able to 
> update the metrics in question.
> {{SolrCloudAuthTestCase.assertAuthMetricsMinimums(...)}} currently has some 
> {{"First metrics count assert failed, pausing 2s before re-attempt"}} 
> evidently to try and work around this bug, but it's still no garuntee that 
> the server thread will be scheduled before the retry happens.
> We can/should just fix JWTAuthPlugin to ensure the metrics are updated before 
> {{authenticationFailure(...)}} is called, and then remove the "pausing 2s 
> before re-attempt" logic from {{SolrCloudAuthTestCase}} - between this bug 
> fix, and the existing work around for SOLR-13464, there should be absolutely 
> no reason to "retry" reading hte metrics.
> (NOTE: BasicAuthPlugin has a similar {{authenticationFailure(...)}} method 
> that also calls {{HttpServletResponse.sendError(...)}} - but it already 
> (correctly) updates the error/failure metrics *before* calling that method.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13700) Race condition in initializing metrics for new security plugins when security.json is modified

[JIRA]

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

Jan Høydahl commented on SOLR-13700:


Good catch.

Re point 2, your patch deletes the wrong lines for auditloggerPlugin metrics. I 
agree that the initialization of PKI metrics in [lines 
877-879|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/core/CoreContainer.java#L877-L879]
 should be moved to L631, right after initializing PKI first (only) time.

> Race condition in initializing metrics for new security plugins when 
> security.json is modified
> --
>
> Key: SOLR-13700
> URL: https://issues.apache.org/jira/browse/SOLR-13700
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13700.patch
>
>
> When new security plugins are initialized due to remote API requetss, there 
> is a delay between "registering" the new plugins for use in methods like 
> {{initializeAuthenticationPlugin()}} (by assigning them to CoreContainer's 
> volatile {{this.authenticationPlugin}} variable) and when the 
> {{initializeMetrics(..)}} method is called on these plugins, so that they 
> continue to use the existing {{Metric}} instances as the plugins they are 
> replacing.
> Because these security plugins maintain local refrences to these Metrics (and 
> don't "get" them from the MetricRegisty everytime they need to {{inc()}} 
> them) this means that there is short race condition situation such that 
> during the window of time after a new plugin instance is put into use, but 
> before  {{initializeMetrics(..)}} is called on them, at these plugins are 
> responsible for accepting/rejecting requests, and decisions in {{Metric}} 
> instances that are not registered and subsequently get thrown away (and GCed) 
> once the CoreContainer gets around to calling {{initializeMetrics(..)}} (and 
> the plugin starts using the pre-existing metric objects)
> 
> This has some noticible impacts on auth tests on CPU constrained jenkins 
> machines (even after putting in place SOLR-13464 work arounds) that make 
> assertions about the metrics recorded.
> In real world situations, the impact of this bug on users is minor: for a few 
> micro/milli-seconds, requests may come in w/o being counted in the auth 
> metrics -- which may also result in descrepencies between the auth metrics 
> totals and the overall request metrics.  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Resolved] (SOLR-13694) IndexSizeEstimator NullPointerException

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  resolved SOLR-13694.
--
Resolution: Fixed

> IndexSizeEstimator NullPointerException
> ---
>
> Key: SOLR-13694
> URL: https://issues.apache.org/jira/browse/SOLR-13694
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13694.patch
>
>
> Jenkins found a reproducible seed for trigging an NPE in 
> IndexSizeEstimatorTest
> Based on a little experimental tracing i did, this might be a real bug in 
> IndexSizeEstimator? ... it's calling close on StoredFieldsReader instances it 
> gets from the CodecReader -- but AFAICT from the docs/code i'm not certain if 
> it should be doing this.  It appears the expectation is that this is direct 
> access to the internal state, that will automatically be closed when the 
> CodecReader is closed.
> ie: IndexSizeEstimator is closing StoredFieldsReader pre-maturely, causing it 
> to be unusbale on the next iteration.
> (I didn't dig in far enough to guess if there are other places in the 
> IndexSizeEstimator code that are closing CodecReader internals prematurely as 
> well, or just in this situation ... it's also not clear if this only causes 
> failures because this seed uses SimpleTextCodec, and other codecs are more 
> forgiving -- or if something else about the index(es) generated for this seed 
> are what cause the problem to manifest)
> http://fucit.org/solr-jenkins-reports/job-data/apache/Lucene-Solr-NightlyTests-master/1928
> {noformat}
> hossman@tray:~/lucene/dev/solr/core [j11] [master] $ git rev-parse HEAD
> 0291db44bc8e092f7cb2f577f0ac8ab6fa6a5fd7
> hossman@tray:~/lucene/dev/solr/core [j11] [master] $ ant test  
> -Dtestcase=IndexSizeEstimatorTest -Dtests.method=testEstimator 
> -Dtests.seed=23F60434E13D8FD4 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true  -Dtests.locale=eo -Dtests.timezone=Atlantic/Madeira 
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
> ...
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=IndexSizeEstimatorTest -Dtests.method=testEstimator 
> -Dtests.seed=23F60434E13D8FD4 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=eo 
> -Dtests.timezone=Atlantic/Madeira -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR   0.88s | IndexSizeEstimatorTest.testEstimator <<<
>[junit4]> Throwable #1: java.lang.NullPointerException
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([23F60434E13D8FD4:EC2B6B666D451E64]:0)
>[junit4]>at 
> org.apache.lucene.codecs.simpletext.SimpleTextStoredFieldsReader.visitDocument(SimpleTextStoredFieldsReader.java:109)
>[junit4]>at 
> org.apache.solr.handler.admin.IndexSizeEstimator.estimateStoredFields(IndexSizeEstimator.java:513)
>[junit4]>at 
> org.apache.solr.handler.admin.IndexSizeEstimator.estimate(IndexSizeEstimator.java:198)
>[junit4]>at 
> org.apache.solr.handler.admin.IndexSizeEstimatorTest.testEstimator(IndexSizeEstimatorTest.java:117)
>[junit4]>at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]>at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]>at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]>at 
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
>[junit4]>at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13699) maxChars no longer working as designed on CopyField

[JIRA]

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

Jan Høydahl commented on SOLR-13699:


So this is yet another regression from the ByteArrayUtf8CharSequence 
"optimization"? If this surfaces a symptom of bad design, let's fix that rather 
than patch just the maxChars check for JavaBin with some instanceOf or 
something?

> maxChars no longer working as designed on CopyField
> ---
>
> Key: SOLR-13699
> URL: https://issues.apache.org/jira/browse/SOLR-13699
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.0.1, 8.1, 8.2, 7.7.3, 8.1.1, 
> 8.1.2
>Reporter: Chris Troullis
>Assignee: Erick Erickson
>Priority: Major
>
> We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars 
> property on a copy field is no longer functioning as designed, while indexing 
> via SolrJ. Per the most recent documentation it looks like there have been no 
> intentional changes as to the functionality of this property, so I assume 
> this is a bug.
>   
>  In debugging the issue, it looks like the bug was caused by SOLR-12992. In 
> DocumentBuilder where the maxChar limit is applied, it first checks if the 
> value is instanceof String. As of SOLR-12992, string values are now coming in 
> as ByteArrayUtf8CharSequence (unless they are above a certain size as defined 
> by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String 
> check, and the maxChar truncation is not being applied. I am currently not 
> sure if this issue is limited to indexing via SolrJ or if it applies to 
> documents indexed via any means



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-13694) IndexSizeEstimator NullPointerException

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated SOLR-13694:
-
Fix Version/s: 8.3

> IndexSizeEstimator NullPointerException
> ---
>
> Key: SOLR-13694
> URL: https://issues.apache.org/jira/browse/SOLR-13694
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13694.patch
>
>
> Jenkins found a reproducible seed for trigging an NPE in 
> IndexSizeEstimatorTest
> Based on a little experimental tracing i did, this might be a real bug in 
> IndexSizeEstimator? ... it's calling close on StoredFieldsReader instances it 
> gets from the CodecReader -- but AFAICT from the docs/code i'm not certain if 
> it should be doing this.  It appears the expectation is that this is direct 
> access to the internal state, that will automatically be closed when the 
> CodecReader is closed.
> ie: IndexSizeEstimator is closing StoredFieldsReader pre-maturely, causing it 
> to be unusbale on the next iteration.
> (I didn't dig in far enough to guess if there are other places in the 
> IndexSizeEstimator code that are closing CodecReader internals prematurely as 
> well, or just in this situation ... it's also not clear if this only causes 
> failures because this seed uses SimpleTextCodec, and other codecs are more 
> forgiving -- or if something else about the index(es) generated for this seed 
> are what cause the problem to manifest)
> http://fucit.org/solr-jenkins-reports/job-data/apache/Lucene-Solr-NightlyTests-master/1928
> {noformat}
> hossman@tray:~/lucene/dev/solr/core [j11] [master] $ git rev-parse HEAD
> 0291db44bc8e092f7cb2f577f0ac8ab6fa6a5fd7
> hossman@tray:~/lucene/dev/solr/core [j11] [master] $ ant test  
> -Dtestcase=IndexSizeEstimatorTest -Dtests.method=testEstimator 
> -Dtests.seed=23F60434E13D8FD4 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true  -Dtests.locale=eo -Dtests.timezone=Atlantic/Madeira 
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
> ...
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=IndexSizeEstimatorTest -Dtests.method=testEstimator 
> -Dtests.seed=23F60434E13D8FD4 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=eo 
> -Dtests.timezone=Atlantic/Madeira -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR   0.88s | IndexSizeEstimatorTest.testEstimator <<<
>[junit4]> Throwable #1: java.lang.NullPointerException
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([23F60434E13D8FD4:EC2B6B666D451E64]:0)
>[junit4]>at 
> org.apache.lucene.codecs.simpletext.SimpleTextStoredFieldsReader.visitDocument(SimpleTextStoredFieldsReader.java:109)
>[junit4]>at 
> org.apache.solr.handler.admin.IndexSizeEstimator.estimateStoredFields(IndexSizeEstimator.java:513)
>[junit4]>at 
> org.apache.solr.handler.admin.IndexSizeEstimator.estimate(IndexSizeEstimator.java:198)
>[junit4]>at 
> org.apache.solr.handler.admin.IndexSizeEstimatorTest.testEstimator(IndexSizeEstimatorTest.java:117)
>[junit4]>at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]>at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]>at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]>at 
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
>[junit4]>at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

Re: The Gradle train.

[Andrzej Białecki]

+1 for landing this in master soon. Thanks Mark for your relentless efforts to 
make this happen!

> On 15 Aug 2019, at 23:23, Mark Miller  wrote:
> 
> https://issues.apache.org/jira/projects/SOLR/issues/SOLR-13452 
>  Update the 
> lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> 
> Okay, we are at the point where either this thing lands soon and gains some 
> contributors to help finish or it  overwhelms me and crashes & burns. That 
> almost sounds negative, but it was actually the plan so far and I'm pretty 
> excited after all this time invested. I need to punt this over to the 
> community though - the final implications and ramifications of moving fully 
> to gradle are just too big for me individually regardless of the time frame.
> 
> I've done about 95%+ of what I wanted to do before trying to land something - 
> a few more hoops to jump around. We pull in more deps than we should right 
> now, I'll deal with that shortly, and mvn publishing needs work (mostly 
> around solr-server, but dist and publishing both prob need edge work at 
> least). Those are the main things on my mind. There are probably a ton of 
> other little things, but I'm thinking those that are important will rise up 
> quickly and the rest can be handled over time.
> 
> This will be a large change. Some things will still take time to get up to 
> par with what we have now. Many things will need to be sorted out (jenkins, 
> releases, smoke tester type things, docs, etc).
> 
> I've also made all the decisions and trade-offs and what not. I'm pretty 
> happy about that, but I'm sure some will want to discuss and debate some 
> choices once things are in their face. I've spent a lot of time in my recent 
> life on this stuff and I'm ready to battle for some of it :) And to be 
> mistaken, ignorant, or convinced of other paths for some other parts of it. 
> I'll only say, every time I go from working with the gradle build back to 
> ant+ivy+mvn, it feels like a big backslide.
> 
> I'm thinking maybe in September/October? And only on master, hopefully living 
> side by side with ant+ivy+mvn, but the goal would be for that period to be 
> brief. They can't live in complete harmony - someone has to own the 
> dependency view of the world for example, the one that actually gets 
> committed (license, checksums, etc). Otherwise, I've done my best to do this 
> in a way that doesn't break the current build. Will need to inspect that 
> closer before landing though.
> 
> This is just another heads up. Once we are in a main branch, I'm hoping a few 
> of you will either have to jump in and help this land or we will have to pull 
> it back out I think. Be prepared :)
> 
> -- 
> - Mark
> 
> http://about.me/markrmiller