[JENKINS] Lucene-Solr-BadApples-master-Linux (64bit/jdk-11.0.3) - Build # 226 - Unstable!

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testQuery

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([794528ADB993C82:8CE526F92A130657]:0)
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at 
org.apache.lucene.util.TestRamUsageEstimator.testQuery(TestRamUsageEstimator.java:168)
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.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:834)


FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testBytesRefHash

Error Message:
expected:<36104> but was:<36136>

Stack Trace:
java.lang.AssertionError: expected:<36104> but was:<36136>
at 
__randomizedtesting.SeedInfo.seed([794528ADB993C82:DE69A9B84D3C9E2A]: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.lucene.util.TestRamUsageEstimator.testBytesRefHash(TestRamUsageEstimator.java:119)
at 

[JENKINS] Lucene-Solr-8.x-MacOSX (64bit/jdk1.8.0) - Build # 210 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-MacOSX/210/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

13 tests failed.
FAILED:  org.apache.solr.core.TestDynamicLoadingUrl.testDynamicLoadingUrl

Error Message:
{   "responseHeader":{ "status":400, "QTime":46},   
"errorMessages":["error processing commands\n"],   "WARNING":"This response 
format is experimental.  It is likely to change in the future.",   "error":{
 "metadata":[   
"error-class","org.apache.solr.api.ApiBag$ExceptionWithErrObject",   
"root-error-class","org.apache.solr.api.ApiBag$ExceptionWithErrObject"], 
"details":[{ "add-runtimelib":{   "name":"urljar",   
"url":"http://127.0.0.1:54070/collection1/jarhandler?wt=filestream;,   
"sha512":"d01b51de67ae1680a84a813983b1de3b592fc32f1a22b662fc9057da5953abd1b72476388ba342cad21671cd0b805503c78ab9075ff2f3951fdf75fa16981420"},
 "errorMessages":["no such blob or version available: urljar"]}], 
"msg":"error processing commands", "code":400}}  expected null, but 
was:<[error processing commands ]>

Stack Trace:
java.lang.AssertionError: {
  "responseHeader":{
"status":400,
"QTime":46},
  "errorMessages":["error processing commands\n"],
  "WARNING":"This response format is experimental.  It is likely to change in 
the future.",
  "error":{
"metadata":[
  "error-class","org.apache.solr.api.ApiBag$ExceptionWithErrObject",
  "root-error-class","org.apache.solr.api.ApiBag$ExceptionWithErrObject"],
"details":[{
"add-runtimelib":{
  "name":"urljar",
  "url":"http://127.0.0.1:54070/collection1/jarhandler?wt=filestream;,
  
"sha512":"d01b51de67ae1680a84a813983b1de3b592fc32f1a22b662fc9057da5953abd1b72476388ba342cad21671cd0b805503c78ab9075ff2f3951fdf75fa16981420"},
"errorMessages":["no such blob or version available: urljar"]}],
"msg":"error processing commands",
"code":400}}
 expected null, but was:<[error processing commands
]>
at 
__randomizedtesting.SeedInfo.seed([753C2B214D1B3973:8EC5DCABE1B7B956]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotNull(Assert.java:755)
at org.junit.Assert.assertNull(Assert.java:737)
at 
org.apache.solr.core.TestSolrConfigHandler.runConfigCommand(TestSolrConfigHandler.java:179)
at 
org.apache.solr.core.TestDynamicLoadingUrl.testDynamicLoadingUrl(TestDynamicLoadingUrl.java:95)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 

[GitHub] [lucene-solr] iverase commented on a change in pull request #709: LUCENE-8850: Calculate the area of a polygon and throw error when values are invalid

[GitBox]

iverase commented on a change in pull request #709: LUCENE-8850: Calculate the 
area of a polygon and throw error when values are invalid
URL: https://github.com/apache/lucene-solr/pull/709#discussion_r298453900
 
 

 ##
 File path: lucene/core/src/java/org/apache/lucene/geo/Polygon.java
 ##
 @@ -96,34 +99,50 @@ public Polygon(double[] polyLats, double[] polyLons, 
Polygon... holes) {
 this.holes = holes.clone();
 
 // compute bounding box
-double minLat = polyLats[0];
-double maxLat = polyLats[0];
-double minLon = polyLons[0];
-double maxLon = polyLons[0];
+double minLat = Double.POSITIVE_INFINITY;
+double maxLat = Double.NEGATIVE_INFINITY;
+double minLon = Double.POSITIVE_INFINITY;
+double maxLon = Double.NEGATIVE_INFINITY;
 
 double windingSum = 0d;
 final int numPts = polyLats.length - 1;
-for (int i = 1, j = 0; i < numPts; j = i++) {
+for (int i = 0; i < numPts; i++) {
   minLat = Math.min(polyLats[i], minLat);
   maxLat = Math.max(polyLats[i], maxLat);
   minLon = Math.min(polyLons[i], minLon);
   maxLon = Math.max(polyLons[i], maxLon);
   // compute signed area
-  windingSum += (polyLons[j] - polyLons[numPts])*(polyLats[i] - 
polyLats[numPts])
-  - (polyLats[j] - polyLats[numPts])*(polyLons[i] - polyLons[numPts]);
+  windingSum += polyLons[i] * polyLats[i + 1] - polyLats[i] * polyLons[i + 
1];
+}
+if (windingSum == 0) {
+  throw new IllegalArgumentException("Cannot compute the polygon / hole 
orientation.");
 }
 this.minLat = minLat;
 this.maxLat = maxLat;
 this.minLon = minLon;
 this.maxLon = maxLon;
 this.windingOrder = (windingSum < 0) ? GeoUtils.WindingOrder.CCW : 
GeoUtils.WindingOrder.CW;
+double area = Math.abs(windingSum / 2d);
+for (Polygon hole : holes) {
+  area -= hole.area();
+}
+if (area <= 0) {
+  throw new IllegalArgumentException("Polygon has an invalid area (area = 
" + area + ").");
+}
+this.area = area;
+
   }
 
   /** returns the number of vertex points */
   public int numPoints() {
 return polyLats.length;
   }
 
+  /** returns the area of the polygon */
+  public double area() {
 
 Review comment:
   I agree we should not provide this info to the user, +1 not to offer the 
calculation to the user.
   
   The idea behind this change was validation of the polygon validation. The 
idea of this change came from the fact that I am using this calculation to 
check that a Polygon tessellation is correct and I realise that:
   
   - Currently we compute the signed area to check the orientation of a 
polygon, if the area is 0 the polygon is consider CW, should we fail instead?
   
   - I have seen polygons with one hole where the hole and polygon are the 
same, should we capture that situation and fail?
   


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


With regards,
Apache Git Services

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

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

[Policeman Jenkins Server]

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

3 tests failed.
FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testQuery

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([2DB9E679B8310F88:A6C8920A49BB355D]:0)
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at 
org.apache.lucene.util.TestRamUsageEstimator.testQuery(TestRamUsageEstimator.java:168)
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.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:834)


FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testBytesRefHash

Error Message:
expected:<36104> but was:<36136>

Stack Trace:
java.lang.AssertionError: expected:<36104> but was:<36136>
at 
__randomizedtesting.SeedInfo.seed([2DB9E679B8310F88:F4441D4B2E94AD20]: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.lucene.util.TestRamUsageEstimator.testBytesRefHash(TestRamUsageEstimator.java:119)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 

[jira] [Commented] (SOLR-12988) Known OpenJDK >= 11 SSL (TLSv1.3) bugs can cause problems with Solr

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12988:


Commit 01b303c2e54adfd84a7da22c988a42a7c6433304 in lucene-solr's branch 
refs/heads/branch_8x from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=01b303c ]

SOLR-12988: SSLTestConfig has been changed to throw AssumptionViolatedException 
when tests/seeds request SSL but the JVM appears to be an OpenJDK version known 
to have SSL bugs

SOLR-13574: Add CHANGES entry that was overlooked
(cherry picked from commit aaf20aefa4b29971dbbb16c9fe39e6272c7c9dd5)


> Known OpenJDK >= 11 SSL (TLSv1.3) bugs can cause problems with Solr
> ---
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
>  Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
>  Labels: Java11, Java12, Java13
> Attachments: SOLR-12988.patch, SOLR-12988.patch, SOLR-12988.patch, 
> SOLR-13413.patch
>
>
> There are several known OpenJDK JVM bugs (begining with Java11, when TLS v1.3 
> support was first added) that are known to affect Solr's SSL support, and 
> have caused numerous test failures -- notably early "testing" builds of 
> OpenJDK 11, 12, & 13, as well as the officially released OpenJDK 11, 11.0.1, 
> and 11.0.2.
> From the standpoint of the Solr project, there is very little we can do to 
> mitigate these bugs, and have taken steps to ensure any code using our 
> {{SSLTestConfig}} / {{RandomizeSSL}} test-framework classes will be "SKIPed" 
> with an {{AssumptionViolatedException}} when used on JVMs that are known to 
> be problematic.
> Users who encounter any of the types of failures described below, or 
> developers who encounter test runs that "SKIP" with a message refering to 
> this issue ID, are encouraged to Upgrade their JVM. (or as a last resort: try 
> disabling "TLSv1.3" in your JVM security properties)
> 
> Examples of known bugs as they have manifested in Solr tests...
> * https://bugs.openjdk.java.net/browse/JDK-8212885
> ** "TLS 1.3 resumed session does not retain peer certificate chain"
> ** affects users with {{checkPeerNames=true}} in your SSL configuration
> ** causes 100% failure rate in Solr's 
> {{TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName}}
> ** can result in exceptions for SolrJ users, or in solr cloud server logs 
> when making intra-node requests, with a root cause of 
> "javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated"
> ** {noformat}
>[junit4]   2> Caused by: javax.net.ssl.SSLPeerUnverifiedException: peer 
> not authenticated
>[junit4]   2>  at 
> java.base/sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:526)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.verifyHostname(SSLConnectionSocketFactory.java:464)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:397)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:355)
>[junit4]   2>  at 
> org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
>[junit4]   2>  at 
> org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:359)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:381)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:237)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111)
>[junit4]   2>  at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
>[junit4]   2>  at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
>[junit4]   2>  at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56)
>[junit4]   2>  at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:542)
> {noformat}
> * https://bugs.openjdk.java.net/browse/JDK-8213202
> ** "Possible race condition in TLS 1.3 session resumption"
> ** May affect any and all Solr SSL users, although noted only in tests when 
> "clientAuth" was configured to be false
> 

[jira] [Commented] (SOLR-13574) harden tests that fail (usually NPE) during After/AfterClas methods if there is an assumption violation in Before/BeforeClass methods

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13574:


Commit 01b303c2e54adfd84a7da22c988a42a7c6433304 in lucene-solr's branch 
refs/heads/branch_8x from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=01b303c ]

SOLR-12988: SSLTestConfig has been changed to throw AssumptionViolatedException 
when tests/seeds request SSL but the JVM appears to be an OpenJDK version known 
to have SSL bugs

SOLR-13574: Add CHANGES entry that was overlooked
(cherry picked from commit aaf20aefa4b29971dbbb16c9fe39e6272c7c9dd5)


> harden tests that fail (usually NPE) during After/AfterClas methods if there 
> is an assumption violation in Before/BeforeClass methods
> -
>
> Key: SOLR-13574
> URL: https://issues.apache.org/jira/browse/SOLR-13574
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13574.patch
>
>
> We have a bunch of tests that blindly try to call cleanup methods on objects 
> w/o sanity checking if the object exists and the cleanup is actually 
> neccessary -- which may not be true, particularly there was an Assumption 
> failure during a Before/BeforeClass method



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

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

[JENKINS] Lucene-Solr-8.x-Windows (64bit/jdk1.8.0_201) - Build # 335 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/335/
Java: 64bit/jdk1.8.0_201 -XX:+UseCompressedOops -XX:+UseG1GC

13 tests failed.
FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testCollection

Error Message:
expected:<280> but was:<256>

Stack Trace:
java.lang.AssertionError: expected:<280> but was:<256>
at 
__randomizedtesting.SeedInfo.seed([9E4E75B52BF39AA3:71675708006E2E27]: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.lucene.util.TestRamUsageEstimator.testCollection(TestRamUsageEstimator.java:147)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testMap

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([9E4E75B52BF39AA3:BE68C166310889D1]:0)
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at 
org.apache.lucene.util.TestRamUsageEstimator.testMap(TestRamUsageEstimator.java:128)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 

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

[Policeman Jenkins Server]

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

4 tests failed.
FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testBytesRefHash

Error Message:
expected:<35952> but was:<35936>

Stack Trace:
java.lang.AssertionError: expected:<35952> but was:<35936>
at 
__randomizedtesting.SeedInfo.seed([25D76282A6D639DF:FC2A99B030739B77]: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.lucene.util.TestRamUsageEstimator.testBytesRefHash(TestRamUsageEstimator.java:119)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:835)


FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testBytesRefHash

Error Message:
expected:<35952> but was:<35936>

Stack Trace:
java.lang.AssertionError: expected:<35952> but was:<35936>
at 
__randomizedtesting.SeedInfo.seed([25D76282A6D639DF:FC2A99B030739B77]: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 

Re: Welcome Kevin Risden to the PMC

[Varun Thacker]

Congratulations Kevin!

On Thu, Jun 27, 2019 at 5:04 AM Jan Høydahl  wrote:

> I am pleased to announce that Kevin Risden has accepted the PMC's
> invitation to join.
>
> Welcome Kevin!
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Commented] (LUCENE-8878) Provide alternative sorting utility from SortField other than FieldComparator

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-8878:


The recently added impacts have a similar use case, where we need to express to 
the {{ImpactsEnum}} what the "bottom" of our PQ is, I think?  Maybe we could 
take inspiration from that to simplify the comparator APIs or make them similar 
to how {{ImpactsEnum}} does it?

> Provide alternative sorting utility from SortField other than FieldComparator
> -
>
> Key: LUCENE-8878
> URL: https://issues.apache.org/jira/browse/LUCENE-8878
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Affects Versions: 8.1.1
>Reporter: Tony Xu
>Priority: Major
>
> The `FieldComparator` has many responsibilities and users get all of them at 
> once. At high level the main functionalities of `FieldComparator` are
>  * Provide LeafFieldComparator
>  * Allocate storage for requested number of hits
>  * Read the values from DocValues/Custom source etc.
>  * Compare two values
> There are two major areas for improvement
>  # The logic of reading values and storing them are coupled.
>  # User need to specify the size in order to create a `FieldComparator` but 
> sometimes the size is unknown upfront.
>  # From `FieldComparator`'s API, one can't reason about thread-safety so it 
> is not suitable for concurrent search.
>  E.g. Can two concurrent thread use the same `FieldComparator` to call 
> `getLeafComparator` for two different segments they are working on? In fact, 
> almost all existing implementations of `FieldComparator` are not thread-safe.
> The proposal is to enhance `SortField` with two APIs
>  # {color:#14892c}int compare(Object v1, Object v2){color} – this is to 
> compare two values from different docs for this field
>  # {color:#14892c}ValueAccessor newValueAccessor(LeafReaderContext 
> leaf){color} – This encapsulate the logic for obtaining the right 
> implementation in order to read the field values.
>  `ValueAccessor` should be accessed in a similar way as `DocValues` to 
> provide the sort value for a document in an advance & read fashion.
> With this API, hopefully we can reduce the memory usage when using 
> `FieldComparator` because the users either store the sort values or at least 
> the slot number besides the storage allocated by `FieldComparator` itself. 
> Ideally, only once copy of the values should be stored.
> The proposed API is also more friendly to concurrent search since it provides 
> the `ValueAccessor` per leaf. Although same `ValueAccessor` can't be shared 
> if there are more than one thread working on the same leaf, at least they can 
> initialize their own `ValueAccessor`.



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

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

[GitHub] [lucene-solr] mayya-sharipova commented on issue #595: Load freqs lazily in Postings

[GitBox]

mayya-sharipova commented on issue #595: Load freqs lazily in Postings
URL: https://github.com/apache/lucene-solr/pull/595#issuecomment-506546238
 
 
   @jpountz This PR is ready for another round of review. Sorry for a delay. I 
still need to run it through  luceneutil  though.


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-NightlyTests-master - Build # 1883 - Still Failing

[Apache Jenkins Server]

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

3 tests failed.
FAILED:  
org.apache.lucene.search.spans.TestSpanSearchEquivalence.testSpanTermVersusTerm

Error Message:
expected:<2524> but was:<2349>

Stack Trace:
java.lang.AssertionError: expected:<2524> but was:<2349>
at 
__randomizedtesting.SeedInfo.seed([BA01660E3D58A91B:DF3B6FD25F9E1876]: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.lucene.search.SearchEquivalenceTestBase.assertSameScores(SearchEquivalenceTestBase.java:255)
at 
org.apache.lucene.search.SearchEquivalenceTestBase.assertSameScores(SearchEquivalenceTestBase.java:228)
at 
org.apache.lucene.search.spans.TestSpanSearchEquivalence.testSpanTermVersusTerm(TestSpanSearchEquivalence.java:42)
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.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:834)


FAILED:  
org.apache.lucene.search.spans.TestSpanSearchEquivalence.testSpanNearVersusPhrase

Error Message:
expected:<3834> but was:<2361>

Stack Trace:
java.lang.AssertionError: expected:<3834> but was:<2361>
at 
__randomizedtesting.SeedInfo.seed([BA01660E3D58A91B:519086FFE79F5D05]:0)
at org.junit.Assert.fail(Assert.java:88)

[jira] [Commented] (SOLR-12988) Known OpenJDK >= 11 SSL (TLSv1.3) bugs can cause problems with Solr

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12988:


Commit aaf20aefa4b29971dbbb16c9fe39e6272c7c9dd5 in lucene-solr's branch 
refs/heads/master from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=aaf20ae ]

SOLR-12988: SSLTestConfig has been changed to throw AssumptionViolatedException 
when tests/seeds request SSL but the JVM appears to be an OpenJDK version known 
to have SSL bugs

SOLR-13574: Add CHANGES entry that was overlooked


> Known OpenJDK >= 11 SSL (TLSv1.3) bugs can cause problems with Solr
> ---
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
>  Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
>  Labels: Java11, Java12, Java13
> Attachments: SOLR-12988.patch, SOLR-12988.patch, SOLR-12988.patch, 
> SOLR-13413.patch
>
>
> There are several known OpenJDK JVM bugs (begining with Java11, when TLS v1.3 
> support was first added) that are known to affect Solr's SSL support, and 
> have caused numerous test failures -- notably early "testing" builds of 
> OpenJDK 11, 12, & 13, as well as the officially released OpenJDK 11, 11.0.1, 
> and 11.0.2.
> From the standpoint of the Solr project, there is very little we can do to 
> mitigate these bugs, and have taken steps to ensure any code using our 
> {{SSLTestConfig}} / {{RandomizeSSL}} test-framework classes will be "SKIPed" 
> with an {{AssumptionViolatedException}} when used on JVMs that are known to 
> be problematic.
> Users who encounter any of the types of failures described below, or 
> developers who encounter test runs that "SKIP" with a message refering to 
> this issue ID, are encouraged to Upgrade their JVM. (or as a last resort: try 
> disabling "TLSv1.3" in your JVM security properties)
> 
> Examples of known bugs as they have manifested in Solr tests...
> * https://bugs.openjdk.java.net/browse/JDK-8212885
> ** "TLS 1.3 resumed session does not retain peer certificate chain"
> ** affects users with {{checkPeerNames=true}} in your SSL configuration
> ** causes 100% failure rate in Solr's 
> {{TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName}}
> ** can result in exceptions for SolrJ users, or in solr cloud server logs 
> when making intra-node requests, with a root cause of 
> "javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated"
> ** {noformat}
>[junit4]   2> Caused by: javax.net.ssl.SSLPeerUnverifiedException: peer 
> not authenticated
>[junit4]   2>  at 
> java.base/sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:526)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.verifyHostname(SSLConnectionSocketFactory.java:464)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:397)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:355)
>[junit4]   2>  at 
> org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
>[junit4]   2>  at 
> org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:359)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:381)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:237)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111)
>[junit4]   2>  at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
>[junit4]   2>  at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
>[junit4]   2>  at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56)
>[junit4]   2>  at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:542)
> {noformat}
> * https://bugs.openjdk.java.net/browse/JDK-8213202
> ** "Possible race condition in TLS 1.3 session resumption"
> ** May affect any and all Solr SSL users, although noted only in tests when 
> "clientAuth" was configured to be false
> ** Causes non-reproducing test failures, and sporadic end user 

[jira] [Commented] (SOLR-13574) harden tests that fail (usually NPE) during After/AfterClas methods if there is an assumption violation in Before/BeforeClass methods

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13574:


Commit aaf20aefa4b29971dbbb16c9fe39e6272c7c9dd5 in lucene-solr's branch 
refs/heads/master from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=aaf20ae ]

SOLR-12988: SSLTestConfig has been changed to throw AssumptionViolatedException 
when tests/seeds request SSL but the JVM appears to be an OpenJDK version known 
to have SSL bugs

SOLR-13574: Add CHANGES entry that was overlooked


> harden tests that fail (usually NPE) during After/AfterClas methods if there 
> is an assumption violation in Before/BeforeClass methods
> -
>
> Key: SOLR-13574
> URL: https://issues.apache.org/jira/browse/SOLR-13574
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13574.patch
>
>
> We have a bunch of tests that blindly try to call cleanup methods on objects 
> w/o sanity checking if the object exists and the cleanup is actually 
> neccessary -- which may not be true, particularly there was an Assumption 
> failure during a Before/BeforeClass method



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

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

[jira] [Commented] (SOLR-13571) Make recent RefGuide rank well in Google

[JIRA]

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

Jan Høydahl commented on SOLR-13571:


{quote}I'm not totally against the idea of having a "latest", but I don't quite 
get why it can't be a redirect?
{quote}
Today the "latest" redirect hack is not a landing page of its own, and it uses 
302 redirect which I believe will not pass on page rank to the target.

Take [https://lucene.apache.org/solr/guide/about-this-guide.html] which now 
redirects to [https://lucene.apache.org/solr/guide/8_1/about-this-guide.html]. 
Now the user will start sharing the 8_1 link and in a few years we have the 
same issue that the 8_1 guide has a lot of credit. Since the URL in browser 
changes, it is hard to bookmark and copy, so it won't get much use in the wild.

If, on the other hand, we had a 
[https://lucene.apache.org/solr/guide/latest/about-this-guide.html] landing 
page, we could move the cwiki 301 redirect 
([https://cwiki.apache.org/confluence/display/solr/About+This+Guide)] to the 
new stable location. I'm not sure though if Google already has moved all the 
rank points to the 6_6 HTML url or if moving the redirects again will suddenly 
make the /latest/ urls rank high. If the 6_6 guide still has all the points we 
could of course redirect all 6_6 links to "latest" as well, but then the 6_6 
guide would be unreachable :). To fix that we could re-release the 6_6 guide 
under e.g. 6_6_0.

The extra effort if we choose such a model is
 * Copy the generated guide twice to release repo, to two different locations
 * Make sure page renames are handled, e.g. as I proposed above, to track when 
a page that existed before no longer exists in the to-be-published guide, and 
then add a redirect for it to the latest version that had that page, or add a 
dummy page with a link on it. This would be scripted as part of release process 
- make a tool comparing the page tree between two versions.

> Make recent RefGuide rank well in Google
> 
>
> Key: SOLR-13571
> URL: https://issues.apache.org/jira/browse/SOLR-13571
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Jan Høydahl
>Priority: Major
>
> Spinoff from SOLR-13548
> The old Confluence ref-guide has a lot of pages pointing to it, and all of 
> that link karma is delegated to the {{/solr/guide/6_6/}} html ref guide, 
> making it often rank top. However we'd want newer content to rank high. See 
> these comments for some first ideas.



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

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

[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-11.0.3) - Build # 8021 - Still unstable!

[Policeman Jenkins Server]

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

16 tests failed.
FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testQuery

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([B57A129845AF227A:3E0B66EBB42518AF]:0)
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at 
org.apache.lucene.util.TestRamUsageEstimator.testQuery(TestRamUsageEstimator.java:168)
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.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:834)


FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testQuery

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([B57A129845AF227A:3E0B66EBB42518AF]:0)
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at 
org.apache.lucene.util.TestRamUsageEstimator.testQuery(TestRamUsageEstimator.java:168)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 

[jira] [Commented] (SOLR-13122) Ability to query aliases in Solr Admin UI

[JIRA]

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

Jan Høydahl commented on SOLR-13122:


{quote}[~ab]It was an accidental change (mis-feature?) that slipped in into 
8.1.0, fixed in 8.1.1.
{quote}
Ok, so say a user has collection 'c1' lice and want to reindex into 'c2' in the 
background. Once that is ready, he creates an alias c1->c2. From that moment 
all updates and queries to c1 will actually go to c2, right? And then he wants 
to delete the real collection 'c1' to free up space. How to do that?

> Ability to query aliases in Solr Admin UI
> -
>
> Key: SOLR-13122
> URL: https://issues.apache.org/jira/browse/SOLR-13122
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Reporter: mosh
>Assignee: Jan Høydahl
>Priority: Major
>  Labels: UI
> Fix For: 8.2
>
> Attachments: alias-collection-menu-selected.png, 
> alias-collection-view.png, alias-collections-menu.png, 
> alias-collections-menu.png, alias-delete-dialogue.png, alias-dropdown.png, 
> alias-select-double.png, alias-view.png, new-collection-dropdown.png, 
> new-oll-overview.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> After having recently toyed with Time Routed Alias in SolrCloud,
> we have noticed there is no way to query an alias from the admin UI,
> since the combo box only contains the current collection in the cluster.
> Solr Admin UI ought to have a way to query these aliases, for better 
> convenience.



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

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

[jira] [Commented] (SOLR-9961) RestoreCore needs the option to download files in parallel.

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-9961:


Attached dirty draft. Really dirty. Turns out backup repos aren't closed in the 
code ever now.  I'm really surprised. 

> RestoreCore needs the option to download files in parallel.
> ---
>
> Key: SOLR-9961
> URL: https://issues.apache.org/jira/browse/SOLR-9961
> Project: Solr
>  Issue Type: Improvement
>  Components: Backup/Restore
>Affects Versions: 6.2.1
>Reporter: Timothy Potter
>Priority: Major
> Attachments: SOLR-9961.patch, SOLR-9961.patch, SOLR-9961.patch
>
>
> My backup to cloud storage (Google cloud storage in this case, but I think 
> this is a general problem) takes 8 minutes ... the restore of the same core 
> takes hours. The restore loop in RestoreCore is serial and doesn't allow me 
> to parallelize the expensive part of this operation (the IO from the remote 
> cloud storage service). We need the option to parallelize the download (like 
> distcp). 
> Also, I tried downloading the same directory using gsutil and it was very 
> fast, like 2 minutes. So I know it's not the pipe that's limiting perf here.
> Here's a very rough patch that does the parallelization. We may also want to 
> consider a two-step approach: 1) download in parallel to a temp dir, 2) 
> perform all the of the checksum validation against the local temp dir. That 
> will save round trips to the remote cloud storage.



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

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

[jira] [Updated] (SOLR-9961) RestoreCore needs the option to download files in parallel.

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-9961:
---
Attachment: SOLR-9961.patch

> RestoreCore needs the option to download files in parallel.
> ---
>
> Key: SOLR-9961
> URL: https://issues.apache.org/jira/browse/SOLR-9961
> Project: Solr
>  Issue Type: Improvement
>  Components: Backup/Restore
>Affects Versions: 6.2.1
>Reporter: Timothy Potter
>Priority: Major
> Attachments: SOLR-9961.patch, SOLR-9961.patch, SOLR-9961.patch
>
>
> My backup to cloud storage (Google cloud storage in this case, but I think 
> this is a general problem) takes 8 minutes ... the restore of the same core 
> takes hours. The restore loop in RestoreCore is serial and doesn't allow me 
> to parallelize the expensive part of this operation (the IO from the remote 
> cloud storage service). We need the option to parallelize the download (like 
> distcp). 
> Also, I tried downloading the same directory using gsutil and it was very 
> fast, like 2 minutes. So I know it's not the pipe that's limiting perf here.
> Here's a very rough patch that does the parallelization. We may also want to 
> consider a two-step approach: 1) download in parallel to a temp dir, 2) 
> perform all the of the checksum validation against the local temp dir. That 
> will save round trips to the remote cloud storage.



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

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

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

[Policeman Jenkins Server]

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

4 tests failed.
FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testBytesRefHash

Error Message:
expected:<35952> but was:<35936>

Stack Trace:
java.lang.AssertionError: expected:<35952> but was:<35936>
at 
__randomizedtesting.SeedInfo.seed([3BD815EB37898187:E225EED9A12C232F]: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.lucene.util.TestRamUsageEstimator.testBytesRefHash(TestRamUsageEstimator.java:119)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:835)


FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testBytesRefHash

Error Message:
expected:<35952> but was:<35936>

Stack Trace:
java.lang.AssertionError: expected:<35952> but was:<35936>
at 
__randomizedtesting.SeedInfo.seed([3BD815EB37898187:E225EED9A12C232F]: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 

[GitHub] [lucene-solr] atris commented on issue #734: LUCENE-8857: Introduce Custom Tiebreakers in TopDocs#merge

[GitBox]

atris commented on issue #734: LUCENE-8857: Introduce Custom Tiebreakers in 
TopDocs#merge
URL: https://github.com/apache/lucene-solr/pull/734#issuecomment-506506869
 
 
   Thanks @s1monw !
   
   @jpountz Would you want to add the CHANGES entry during merging, or should I 
push an iteration?


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


With regards,
Apache Git Services

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

[jira] [Updated] (SOLR-9961) RestoreCore needs the option to download files in parallel.

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-9961:
---
Attachment: (was: SOLR-9961.patch)

> RestoreCore needs the option to download files in parallel.
> ---
>
> Key: SOLR-9961
> URL: https://issues.apache.org/jira/browse/SOLR-9961
> Project: Solr
>  Issue Type: Improvement
>  Components: Backup/Restore
>Affects Versions: 6.2.1
>Reporter: Timothy Potter
>Priority: Major
> Attachments: SOLR-9961.patch, SOLR-9961.patch
>
>
> My backup to cloud storage (Google cloud storage in this case, but I think 
> this is a general problem) takes 8 minutes ... the restore of the same core 
> takes hours. The restore loop in RestoreCore is serial and doesn't allow me 
> to parallelize the expensive part of this operation (the IO from the remote 
> cloud storage service). We need the option to parallelize the download (like 
> distcp). 
> Also, I tried downloading the same directory using gsutil and it was very 
> fast, like 2 minutes. So I know it's not the pipe that's limiting perf here.
> Here's a very rough patch that does the parallelization. We may also want to 
> consider a two-step approach: 1) download in parallel to a temp dir, 2) 
> perform all the of the checksum validation against the local temp dir. That 
> will save round trips to the remote cloud storage.



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

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

[jira] [Updated] (SOLR-9961) RestoreCore needs the option to download files in parallel.

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-9961:
---
Attachment: SOLR-9961.patch

> RestoreCore needs the option to download files in parallel.
> ---
>
> Key: SOLR-9961
> URL: https://issues.apache.org/jira/browse/SOLR-9961
> Project: Solr
>  Issue Type: Improvement
>  Components: Backup/Restore
>Affects Versions: 6.2.1
>Reporter: Timothy Potter
>Priority: Major
> Attachments: SOLR-9961.patch, SOLR-9961.patch, SOLR-9961.patch
>
>
> My backup to cloud storage (Google cloud storage in this case, but I think 
> this is a general problem) takes 8 minutes ... the restore of the same core 
> takes hours. The restore loop in RestoreCore is serial and doesn't allow me 
> to parallelize the expensive part of this operation (the IO from the remote 
> cloud storage service). We need the option to parallelize the download (like 
> distcp). 
> Also, I tried downloading the same directory using gsutil and it was very 
> fast, like 2 minutes. So I know it's not the pipe that's limiting perf here.
> Here's a very rough patch that does the parallelization. We may also want to 
> consider a two-step approach: 1) download in parallel to a temp dir, 2) 
> perform all the of the checksum validation against the local temp dir. That 
> will save round trips to the remote cloud storage.



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

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

[jira] [Commented] (SOLR-12554) Expose IndexWriterConfig's RAMPerThreadHardLimitMB as SolrConfig.xml param

[Lucene/Solr QA (JIRA)]

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

Lucene/Solr QA commented on SOLR-12554:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 1 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  4m  
0s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  4m 
31s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  4m 
31s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  4m  6s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  3m 49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  3m 49s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 92m 50s{color} 
| {color:red} core in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  1m 
35s{color} | {color:green} test-framework in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black}107m 58s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.update.SolrIndexConfigTest |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12554 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12973022/SOLR-12554.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP 
Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / 7e57d3a |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 20 2018 |
| Default Java | LTS |
| unit | 
https://builds.apache.org/job/PreCommit-SOLR-Build/463/artifact/out/patch-unit-solr_core.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/463/testReport/ |
| modules | C: solr/core solr/test-framework U: solr |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/463/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Expose IndexWriterConfig's RAMPerThreadHardLimitMB as SolrConfig.xml param
> --
>
> Key: SOLR-12554
> URL: https://issues.apache.org/jira/browse/SOLR-12554
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-12554.patch, SOLR-12554.patch
>
>
> Currently, the RAMPerThreadHardLimitMB parameter of IWC is not exposed. This 
> is useful to control flush policies.



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

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

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

[Policeman Jenkins Server]

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

8 tests failed.
FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testBytesRefHash

Error Message:
expected:<36104> but was:<36120>

Stack Trace:
java.lang.AssertionError: expected:<36104> but was:<36120>
at 
__randomizedtesting.SeedInfo.seed([5F7F1C6049AC73BA:8682E752DF09D112]: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.lucene.util.TestRamUsageEstimator.testBytesRefHash(TestRamUsageEstimator.java:119)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:835)


FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testQuery

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([5F7F1C6049AC73BA:D40E6813B826496F]:0)
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at 
org.apache.lucene.util.TestRamUsageEstimator.testQuery(TestRamUsageEstimator.java:168)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 

[jira] [Commented] (SOLR-12988) Known OpenJDK >= 11 SSL (TLSv1.3) bugs can cause problems with Solr

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-12988:
-

now that SOLR-13574 is done i think this is probably good to go ... still doing 
some testing but if i don't see any porblems or objects soon i'll move forward 
with committing.

> Known OpenJDK >= 11 SSL (TLSv1.3) bugs can cause problems with Solr
> ---
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
>  Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
>  Labels: Java11, Java12, Java13
> Attachments: SOLR-12988.patch, SOLR-12988.patch, SOLR-12988.patch, 
> SOLR-13413.patch
>
>
> There are several known OpenJDK JVM bugs (begining with Java11, when TLS v1.3 
> support was first added) that are known to affect Solr's SSL support, and 
> have caused numerous test failures -- notably early "testing" builds of 
> OpenJDK 11, 12, & 13, as well as the officially released OpenJDK 11, 11.0.1, 
> and 11.0.2.
> From the standpoint of the Solr project, there is very little we can do to 
> mitigate these bugs, and have taken steps to ensure any code using our 
> {{SSLTestConfig}} / {{RandomizeSSL}} test-framework classes will be "SKIPed" 
> with an {{AssumptionViolatedException}} when used on JVMs that are known to 
> be problematic.
> Users who encounter any of the types of failures described below, or 
> developers who encounter test runs that "SKIP" with a message refering to 
> this issue ID, are encouraged to Upgrade their JVM. (or as a last resort: try 
> disabling "TLSv1.3" in your JVM security properties)
> 
> Examples of known bugs as they have manifested in Solr tests...
> * https://bugs.openjdk.java.net/browse/JDK-8212885
> ** "TLS 1.3 resumed session does not retain peer certificate chain"
> ** affects users with {{checkPeerNames=true}} in your SSL configuration
> ** causes 100% failure rate in Solr's 
> {{TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName}}
> ** can result in exceptions for SolrJ users, or in solr cloud server logs 
> when making intra-node requests, with a root cause of 
> "javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated"
> ** {noformat}
>[junit4]   2> Caused by: javax.net.ssl.SSLPeerUnverifiedException: peer 
> not authenticated
>[junit4]   2>  at 
> java.base/sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:526)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.verifyHostname(SSLConnectionSocketFactory.java:464)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:397)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:355)
>[junit4]   2>  at 
> org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
>[junit4]   2>  at 
> org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:359)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:381)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:237)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111)
>[junit4]   2>  at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
>[junit4]   2>  at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
>[junit4]   2>  at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56)
>[junit4]   2>  at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:542)
> {noformat}
> * https://bugs.openjdk.java.net/browse/JDK-8213202
> ** "Possible race condition in TLS 1.3 session resumption"
> ** May affect any and all Solr SSL users, although noted only in tests when 
> "clientAuth" was configured to be false
> ** Causes non-reproducing test failures, and sporadic end user exceptions 
> with a root cause of "javax.net.ssl.SSLException: Received fatal alert: 
> internal_error "
> ** SSL Debugging may indicate "Fatal (INTERNAL_ERROR): Session has no PSK"
> ** {noformat}
>[junit4]   2> Caused by: javax.net.ssl.SSLException: Received fatal alert: 
> 

[jira] [Resolved] (SOLR-13574) harden tests that fail (usually NPE) during After/AfterClas methods if there is an assumption violation in Before/BeforeClass methods

[Hoss Man (JIRA)]

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

Hoss Man resolved SOLR-13574.
-
Resolution: Fixed

> harden tests that fail (usually NPE) during After/AfterClas methods if there 
> is an assumption violation in Before/BeforeClass methods
> -
>
> Key: SOLR-13574
> URL: https://issues.apache.org/jira/browse/SOLR-13574
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13574.patch
>
>
> We have a bunch of tests that blindly try to call cleanup methods on objects 
> w/o sanity checking if the object exists and the cleanup is actually 
> neccessary -- which may not be true, particularly there was an Assumption 
> failure during a Before/BeforeClass method



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

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

[jira] [Commented] (SOLR-13574) harden tests that fail (usually NPE) during After/AfterClas methods if there is an assumption violation in Before/BeforeClass methods

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13574:


Commit 8db2fdfa910e418927b18246594dbaeaeac4dc21 in lucene-solr's branch 
refs/heads/branch_8x from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8db2fdf ]

SOLR-13574: Fix many test and test-framework classes to not fail on 
After/AfterClass cleanup if assumptions fail in Before/BeforeClass setup

(cherry picked from commit 7e57d3a9d93e8acb77ce299f8c79d92df563b864)

Conflicts:
solr/core/src/test/org/apache/solr/cloud/CleanupOldIndexTest.java


> harden tests that fail (usually NPE) during After/AfterClas methods if there 
> is an assumption violation in Before/BeforeClass methods
> -
>
> Key: SOLR-13574
> URL: https://issues.apache.org/jira/browse/SOLR-13574
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13574.patch
>
>
> We have a bunch of tests that blindly try to call cleanup methods on objects 
> w/o sanity checking if the object exists and the cleanup is actually 
> neccessary -- which may not be true, particularly there was an Assumption 
> failure during a Before/BeforeClass method



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

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

[jira] [Commented] (LUCENE-8878) Provide alternative sorting utility from SortField other than FieldComparator

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-8878:
-

Yes, please don't let me discourage you from attempting to simplify the API.

I just wanted to point out that for a search engine, there are totally valid 
use-cases for the sort comparator to exploit the priority queue to go faster. I 
think the distance one is "reasonable" in that sense.

The comparison-by-ordinal stuff we do for strings is more extreme, it is kind 
of a separate issue from that? Its related, There might be other ways to do it 
and still have good performance. I know there was a lot of investigation and 
benchmarking in past JIRA issues on that.

> Provide alternative sorting utility from SortField other than FieldComparator
> -
>
> Key: LUCENE-8878
> URL: https://issues.apache.org/jira/browse/LUCENE-8878
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Affects Versions: 8.1.1
>Reporter: Tony Xu
>Priority: Major
>
> The `FieldComparator` has many responsibilities and users get all of them at 
> once. At high level the main functionalities of `FieldComparator` are
>  * Provide LeafFieldComparator
>  * Allocate storage for requested number of hits
>  * Read the values from DocValues/Custom source etc.
>  * Compare two values
> There are two major areas for improvement
>  # The logic of reading values and storing them are coupled.
>  # User need to specify the size in order to create a `FieldComparator` but 
> sometimes the size is unknown upfront.
>  # From `FieldComparator`'s API, one can't reason about thread-safety so it 
> is not suitable for concurrent search.
>  E.g. Can two concurrent thread use the same `FieldComparator` to call 
> `getLeafComparator` for two different segments they are working on? In fact, 
> almost all existing implementations of `FieldComparator` are not thread-safe.
> The proposal is to enhance `SortField` with two APIs
>  # {color:#14892c}int compare(Object v1, Object v2){color} – this is to 
> compare two values from different docs for this field
>  # {color:#14892c}ValueAccessor newValueAccessor(LeafReaderContext 
> leaf){color} – This encapsulate the logic for obtaining the right 
> implementation in order to read the field values.
>  `ValueAccessor` should be accessed in a similar way as `DocValues` to 
> provide the sort value for a document in an advance & read fashion.
> With this API, hopefully we can reduce the memory usage when using 
> `FieldComparator` because the users either store the sort values or at least 
> the slot number besides the storage allocated by `FieldComparator` itself. 
> Ideally, only once copy of the values should be stored.
> The proposed API is also more friendly to concurrent search since it provides 
> the `ValueAccessor` per leaf. Although same `ValueAccessor` can't be shared 
> if there are more than one thread working on the same leaf, at least they can 
> initialize their own `ValueAccessor`.



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

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

[jira] [Commented] (LUCENE-8878) Provide alternative sorting utility from SortField other than FieldComparator

[Tony Xu (JIRA)]

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

Tony Xu commented on LUCENE-8878:
-

[~rcmuir] Thank you Robert for bring the implementation detail about 
LatLongPointDistanceComparator, I didn't know about that! Took a look at it I 
found –
* compare(int slot, int slot) method still compare the distance
* the setBottom(int slot) method set's the bottom distance (double) and 
computes the bounding box in a sampling fashion
* The optimization lies in compareBottom(int doc) method. It grabs the lat/long 
out of document and tries to reject the doc if the lat/long is out of bounding 
box.


I also noted there are compareTop/setTopValue methods used for paging. With all 
that, I will need to rethink and propose a different API


> Provide alternative sorting utility from SortField other than FieldComparator
> -
>
> Key: LUCENE-8878
> URL: https://issues.apache.org/jira/browse/LUCENE-8878
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Affects Versions: 8.1.1
>Reporter: Tony Xu
>Priority: Major
>
> The `FieldComparator` has many responsibilities and users get all of them at 
> once. At high level the main functionalities of `FieldComparator` are
>  * Provide LeafFieldComparator
>  * Allocate storage for requested number of hits
>  * Read the values from DocValues/Custom source etc.
>  * Compare two values
> There are two major areas for improvement
>  # The logic of reading values and storing them are coupled.
>  # User need to specify the size in order to create a `FieldComparator` but 
> sometimes the size is unknown upfront.
>  # From `FieldComparator`'s API, one can't reason about thread-safety so it 
> is not suitable for concurrent search.
>  E.g. Can two concurrent thread use the same `FieldComparator` to call 
> `getLeafComparator` for two different segments they are working on? In fact, 
> almost all existing implementations of `FieldComparator` are not thread-safe.
> The proposal is to enhance `SortField` with two APIs
>  # {color:#14892c}int compare(Object v1, Object v2){color} – this is to 
> compare two values from different docs for this field
>  # {color:#14892c}ValueAccessor newValueAccessor(LeafReaderContext 
> leaf){color} – This encapsulate the logic for obtaining the right 
> implementation in order to read the field values.
>  `ValueAccessor` should be accessed in a similar way as `DocValues` to 
> provide the sort value for a document in an advance & read fashion.
> With this API, hopefully we can reduce the memory usage when using 
> `FieldComparator` because the users either store the sort values or at least 
> the slot number besides the storage allocated by `FieldComparator` itself. 
> Ideally, only once copy of the values should be stored.
> The proposed API is also more friendly to concurrent search since it provides 
> the `ValueAccessor` per leaf. Although same `ValueAccessor` can't be shared 
> if there are more than one thread working on the same leaf, at least they can 
> initialize their own `ValueAccessor`.



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

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

Re: Welcome Kevin Risden to the PMC

[David Smiley]

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


On Thu, Jun 27, 2019 at 8:04 AM Jan Høydahl  wrote:

> I am pleased to announce that Kevin Risden has accepted the PMC's
> invitation to join.
>
> Welcome Kevin!
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Commented] (LUCENE-8855) Add Accountable to some Query implementations

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on LUCENE-8855:
---

I reverted it from 8.1.2 and I'm working on fixing the test failures on master 
/ branch_8x (very different estimates between Java 8, 11, and 13, even though 
RamUsageEstimator tries to mitigate that).

> Add Accountable to some Query implementations
> -
>
> Key: LUCENE-8855
> URL: https://issues.apache.org/jira/browse/LUCENE-8855
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 8.2
>
> Attachments: LUCENE-8855.patch, LUCENE-8855.patch, LUCENE-8855.patch, 
> LUCENE-8855.patch, LUCENE-8855.patch
>
>
> Query implementations should also support {{Accountable}} API in order to 
> monitor the memory consumption e.g. in caches where either keys or values are 
> {{Query}} instances.



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

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

[jira] [Commented] (LUCENE-8855) Add Accountable to some Query implementations

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-8855:
--

Yeah I agree!  The bug distinction on SOLR-13003 is debatable, and it had 
multiple possible solutions (like simply not supporting the mem setting on that 
cache).  It feels wrong to pull in non-bugs like this into a point release for 
that.

> Add Accountable to some Query implementations
> -
>
> Key: LUCENE-8855
> URL: https://issues.apache.org/jira/browse/LUCENE-8855
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 8.2
>
> Attachments: LUCENE-8855.patch, LUCENE-8855.patch, LUCENE-8855.patch, 
> LUCENE-8855.patch, LUCENE-8855.patch
>
>
> Query implementations should also support {{Accountable}} API in order to 
> monitor the memory consumption e.g. in caches where either keys or values are 
> {{Query}} instances.



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

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

[JENKINS] Lucene-Solr-8.x-Solaris (64bit/jdk1.8.0) - Build # 203 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Solaris/203/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

10 tests failed.
FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testQuery

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([98B548167549F52D:13C43C6584C3CFF8]:0)
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at 
org.apache.lucene.util.TestRamUsageEstimator.testQuery(TestRamUsageEstimator.java:168)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testMap

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([98B548167549F52D:B893FCC56FB2E65F]:0)
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at 
org.apache.lucene.util.TestRamUsageEstimator.testMap(TestRamUsageEstimator.java:128)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 

[JENKINS] Lucene-Solr-NightlyTests-8.x - Build # 134 - Unstable

[Apache Jenkins Server]

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

9 tests failed.
FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testCollection

Error Message:
expected:<280> but was:<256>

Stack Trace:
java.lang.AssertionError: expected:<280> but was:<256>
at 
__randomizedtesting.SeedInfo.seed([7B24B8F6EACF163B:940D9A4BC152A2BF]: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.lucene.util.TestRamUsageEstimator.testCollection(TestRamUsageEstimator.java:147)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testBytesRefHash

Error Message:
expected:<35952> but was:<35920>

Stack Trace:
java.lang.AssertionError: expected:<35952> but was:<35920>
at 
__randomizedtesting.SeedInfo.seed([7B24B8F6EACF163B:A2D943C47C6AB493]: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 

Re: Welcome Kevin Risden to the PMC

[Robert Muir]

Congratulations!

On Thu, Jun 27, 2019 at 8:04 AM Jan Høydahl  wrote:

> I am pleased to announce that Kevin Risden has accepted the PMC's
> invitation to join.
>
> Welcome Kevin!
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

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

[Policeman Jenkins Server]

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

5 tests failed.
FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testBytesRefHash

Error Message:
expected:<35952> but was:<35936>

Stack Trace:
java.lang.AssertionError: expected:<35952> but was:<35936>
at 
__randomizedtesting.SeedInfo.seed([758A99AB97061D51:AC77629901A3BFF9]: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.lucene.util.TestRamUsageEstimator.testBytesRefHash(TestRamUsageEstimator.java:119)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:835)


FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testBytesRefHash

Error Message:
expected:<35952> but was:<35936>

Stack Trace:
java.lang.AssertionError: expected:<35952> but was:<35936>
at 
__randomizedtesting.SeedInfo.seed([758A99AB97061D51:AC77629901A3BFF9]: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 

[jira] [Commented] (SOLR-13574) harden tests that fail (usually NPE) during After/AfterClas methods if there is an assumption violation in Before/BeforeClass methods

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13574:


Commit 7e57d3a9d93e8acb77ce299f8c79d92df563b864 in lucene-solr's branch 
refs/heads/master from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7e57d3a ]

SOLR-13574: Fix many test and test-framework classes to not fail on 
After/AfterClass cleanup if assumptions fail in Before/BeforeClass setup


> harden tests that fail (usually NPE) during After/AfterClas methods if there 
> is an assumption violation in Before/BeforeClass methods
> -
>
> Key: SOLR-13574
> URL: https://issues.apache.org/jira/browse/SOLR-13574
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13574.patch
>
>
> We have a bunch of tests that blindly try to call cleanup methods on objects 
> w/o sanity checking if the object exists and the cleanup is actually 
> neccessary -- which may not be true, particularly there was an Assumption 
> failure during a Before/BeforeClass method



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

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

[jira] [Commented] (SOLR-13580) java 13-ea NumberFormat.parse bugs in some Locales, affects ParseNumeric UpdateProcessors when using the 'locale' config option

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-13580:
-

[https://bugs.openjdk.java.net/browse/JDK-8226867]
{quote}
JDK-13 uses the CLDR v35 . From CLDR v34, the French grouping separator changed 
from no-break space U+00A0 to narrow no-break space U+202F. (Reference Release 
Notes for CLDR v34 : http://cldr.unicode.org/index/downloads/cldr-34 )
"10\u202F0898,83491" will give the expected result :
### input = 10?0898,83491
100898.83491
class java.lang.Double
java.text.ParsePosition[index=13,errorIndex=-1] 
{quote}

Linked issue: https://bugs.openjdk.java.net/browse/JDK-8225245
{quote}
Instead of hardcoding \u00A0, applications can use 
DecimalFormatSymbols.getInstance(Locale.FRENCH).getGroupingSeparator().
{quote}

...so it looks like we can change the test to work regardless of java version 
by using  DecimalFormatSymbols to determine the corect grouping character at 
runtime -- but that won't change the fact that end users who don't know any 
better might see a back compat break (in the ParseNumeric UpdateProcessors) if 
they upgrade to java13 ... so we should mak sure the isue description spells 
this out.

not sure there is much we can safely do to mitigate this for users across all 
possible locales that my be affected.

> java 13-ea NumberFormat.parse bugs in some Locales, affects ParseNumeric 
> UpdateProcessors when using the 'locale' config option
> ---
>
> Key: SOLR-13580
> URL: https://issues.apache.org/jira/browse/SOLR-13580
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
>  Labels: Java13
> Attachments: SOLR-13580.patch
>
>
> ParsingFieldUpdateProcessorsTest has uncovered a JDK 13-ea+26 bug when 
> dealing with the fr_FR Locale (which may affect other locales as well) which 
> causes the grouping seperator ( U+00A0 in fr_FR ) to be ignored when parsing, 
> treating them as a termination character -- example: "10 898" is parsed as 
> "10" instead of "10898", leaving the " 898" portion of the string unparsed.
> The way the ParseNumeric UpdateProcessors are implemented, the fact that the 
> NumbertFormat instance does not recognize the entire string as a Number 
> results in the String value being left "as is" in the input documents.
> In ParsingFieldUpdateProcessorsTest this has manifested as jenkins failures 
> like this...
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=ParsingFieldUpdateProcessorsTest 
> -Dtests.method=testParseFloatNonRootLocale -Dtests.seed=AE6C840917DD963B 
> -Dtests.nightly=true -Dtests.slow=true -Dtests.badapples=true 
> -Dtests.locale=us -Dtests.timezone=GMT -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 0.03s | 
> ParsingFieldUpdateProcessorsTest.testParseFloatNonRootLocale <<<
>[junit4]> Throwable #1: java.lang.AssertionError
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([AE6C840917DD963B:B5B079D8B7786A26]:0)
>[junit4]>  at 
> org.apache.solr.update.processor.ParsingFieldUpdateProcessorsTest.testParseFloatNonRootLocale(ParsingFieldUpdateProcessorsTest.java:471)
>[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:567)
>[junit4]>  at java.base/java.lang.Thread.run(Thread.java:830)
> {noformat}



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

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

Re: Welcome Kevin Risden to the PMC

[Steve Rowe]

Welcome Kevin!

--
Steve

> On Jun 27, 2019, at 8:04 AM, Jan Høydahl  wrote:
> 
> I am pleased to announce that Kevin Risden has accepted the PMC's invitation 
> to join.
> 
> Welcome Kevin!
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
> 
> 
> -
> 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

[GitHub] [lucene-solr] nknize commented on a change in pull request #709: LUCENE-8850: Calculate the area of a polygon and throw error when values are invalid

[GitBox]

nknize commented on a change in pull request #709: LUCENE-8850: Calculate the 
area of a polygon and throw error when values are invalid
URL: https://github.com/apache/lucene-solr/pull/709#discussion_r298261656
 
 

 ##
 File path: lucene/core/src/java/org/apache/lucene/geo/Polygon.java
 ##
 @@ -96,34 +99,50 @@ public Polygon(double[] polyLats, double[] polyLons, 
Polygon... holes) {
 this.holes = holes.clone();
 
 // compute bounding box
-double minLat = polyLats[0];
-double maxLat = polyLats[0];
-double minLon = polyLons[0];
-double maxLon = polyLons[0];
+double minLat = Double.POSITIVE_INFINITY;
+double maxLat = Double.NEGATIVE_INFINITY;
+double minLon = Double.POSITIVE_INFINITY;
+double maxLon = Double.NEGATIVE_INFINITY;
 
 double windingSum = 0d;
 final int numPts = polyLats.length - 1;
-for (int i = 1, j = 0; i < numPts; j = i++) {
+for (int i = 0; i < numPts; i++) {
   minLat = Math.min(polyLats[i], minLat);
   maxLat = Math.max(polyLats[i], maxLat);
   minLon = Math.min(polyLons[i], minLon);
   maxLon = Math.max(polyLons[i], maxLon);
   // compute signed area
-  windingSum += (polyLons[j] - polyLons[numPts])*(polyLats[i] - 
polyLats[numPts])
-  - (polyLats[j] - polyLats[numPts])*(polyLons[i] - polyLons[numPts]);
+  windingSum += polyLons[i] * polyLats[i + 1] - polyLats[i] * polyLons[i + 
1];
+}
+if (windingSum == 0) {
+  throw new IllegalArgumentException("Cannot compute the polygon / hole 
orientation.");
 }
 this.minLat = minLat;
 this.maxLat = maxLat;
 this.minLon = minLon;
 this.maxLon = maxLon;
 this.windingOrder = (windingSum < 0) ? GeoUtils.WindingOrder.CCW : 
GeoUtils.WindingOrder.CW;
+double area = Math.abs(windingSum / 2d);
+for (Polygon hole : holes) {
+  area -= hole.area();
+}
+if (area <= 0) {
+  throw new IllegalArgumentException("Polygon has an invalid area (area = 
" + area + ").");
+}
+this.area = area;
+
   }
 
   /** returns the number of vertex points */
   public int numPoints() {
 return polyLats.length;
   }
 
+  /** returns the area of the polygon */
+  public double area() {
 
 Review comment:
   I agree w/ @dsmiley re: units.  The calculation is using the [shoelace 
method](https://en.wikipedia.org/wiki/Shoelace_formula) on vertices in decimal 
degrees. So the units are deg^2. I remember exploring this a little over a year 
ago in [LUCENE-8364](https://issues.apache.org/jira/browse/LUCENE-8364) and 
originally having area because it was "easy". I ended up removing it until we 
had support for indexing in other projections (e.g., [equal 
area](https://en.wikipedia.org/wiki/Map_projection#Equal-area)). I think we 
should wait until 
[LUCENE-8632](https://issues.apache.org/jira/browse/LUCENE-8632) lands and only 
provide this area calculation in 
[XYPolygon](lucene/sandbox/src/java/org/apache/lucene/geo/XYPolygon.java) for 
regular cartesian geometries in non decimal degrees. 


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


With regards,
Apache Git Services

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

[jira] [Commented] (SOLR-13122) Ability to query aliases in Solr Admin UI

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-13122:
---

Then script it ;). Seriously, I don't think the convenience factor outweighs 
the risk. I'd argue that by the time someone goes through all the work to 
figure out what the consequences of specifying that parameter safely, they 
might just as well create a script

Should an alias to an alias be followed? What about if the alias points to 50 
collections? Or points to 50 aliases to underlying collections some of which 
have the same name as some alias or vice-versa? Or some chain of aliases points 
to a collection that's also part of another alias that's not being deleted? Or 
the chain of aliases are _all_ going to be deleted and, when they are we can 
safely delete the collection, did the we falsely refuse to delete the 
collection? All that wrapped in the confusion about an alias having the same 
name as a collection. My point is that these are complicated enough without 
having to also test to see, at each step, whether an alias and collection have 
the same name.

And to me it's especially dangerous that the whole structure is relatively 
fragile. Either we need to have very extensive tests that are maintained or 
make it far less likely to hit those gotchas

> Ability to query aliases in Solr Admin UI
> -
>
> Key: SOLR-13122
> URL: https://issues.apache.org/jira/browse/SOLR-13122
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Reporter: mosh
>Assignee: Jan Høydahl
>Priority: Major
>  Labels: UI
> Fix For: 8.2
>
> Attachments: alias-collection-menu-selected.png, 
> alias-collection-view.png, alias-collections-menu.png, 
> alias-collections-menu.png, alias-delete-dialogue.png, alias-dropdown.png, 
> alias-select-double.png, alias-view.png, new-collection-dropdown.png, 
> new-oll-overview.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> After having recently toyed with Time Routed Alias in SolrCloud,
> we have noticed there is no way to query an alias from the admin UI,
> since the combo box only contains the current collection in the cluster.
> Solr Admin UI ought to have a way to query these aliases, for better 
> convenience.



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

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

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

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 25085 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 2581 links (2111 relative) to 3394 anchors in 259 files
 [echo] Validated Links & Anchors via: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr-ref-guide/bare-bones-html/

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

package:

-unpack-solr-tgz:

-ensure-solr-tgz-exists:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr.tgz.unpacked
[untar] Expanding: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/package/solr-8.2.0.tgz
 into 
/x1/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 = 
/x1/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 = 
/x1/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 = 
/x1/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 = 
/x1/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 = 
/x1/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 = 
/x1/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 = 
/x1/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 = 
/x1/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 = 
/x1/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 = 
/x1/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 = 
/x1/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 

[JENKINS] Lucene-Solr-8.x-MacOSX (64bit/jdk1.8.0) - Build # 209 - Still unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-MacOSX/209/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC

10 tests failed.
FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testMap

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([A26C56053C74F67:2A0071B3493C5C15]:0)
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at 
org.apache.lucene.util.TestRamUsageEstimator.testMap(TestRamUsageEstimator.java:128)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testQuery

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([A26C56053C74F67:8157B113A24D75B2]:0)
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at 
org.apache.lucene.util.TestRamUsageEstimator.testQuery(TestRamUsageEstimator.java:168)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 

[jira] [Commented] (SOLR-13571) Make recent RefGuide rank well in Google

[Mike Sokolov (JIRA)]

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

Mike Sokolov commented on SOLR-13571:
-

Have we ever tried publishing a site map? Google used to have a feature that 
would read an XL file that described all the pages on the sure as a hint to its 
crawler. Also I wonder if we have ever checked out Google webmaster tools for 
the documentation site(s). 

> Make recent RefGuide rank well in Google
> 
>
> Key: SOLR-13571
> URL: https://issues.apache.org/jira/browse/SOLR-13571
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Jan Høydahl
>Priority: Major
>
> Spinoff from SOLR-13548
> The old Confluence ref-guide has a lot of pages pointing to it, and all of 
> that link karma is delegated to the {{/solr/guide/6_6/}} html ref guide, 
> making it often rank top. However we'd want newer content to rank high. See 
> these comments for some first ideas.



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

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

Re: Welcome Kevin Risden to the PMC

[Gus Heck]

Congratulations Kevin :)

On Thu, Jun 27, 2019 at 11:09 AM Erick Erickson 
wrote:

> Welcome Kevin!
>
> > On Jun 27, 2019, at 5:04 AM, Jan Høydahl  wrote:
> >
> > I am pleased to announce that Kevin Risden has accepted the PMC's
> invitation to join.
> >
> > Welcome Kevin!
> >
> > --
> > Jan Høydahl, search solution architect
> > Cominvent AS - www.cominvent.com
> >
> >
> > -
> > 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
>
>

-- 
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24300/
Java: 64bit/jdk-12.0.1 -XX:-UseCompressedOops -XX:+UseParallelGC

8 tests failed.
FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testQuery

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([72EB80A197748697:F99AF4D266FEBC42]:0)
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at 
org.apache.lucene.util.TestRamUsageEstimator.testQuery(TestRamUsageEstimator.java:168)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:835)


FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testBytesRefHash

Error Message:
expected:<36104> but was:<36120>

Stack Trace:
java.lang.AssertionError: expected:<36104> but was:<36120>
at 
__randomizedtesting.SeedInfo.seed([72EB80A197748697:AB167B9301D1243F]: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.lucene.util.TestRamUsageEstimator.testBytesRefHash(TestRamUsageEstimator.java:119)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 

[jira] [Commented] (SOLR-13122) Ability to query aliases in Solr Admin UI

[Gus Heck (JIRA)]

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

Gus Heck commented on SOLR-13122:
-

wandering Off topic a bit but 

 
{quote} Say somebody deletes an alias and we follow it and delete the 
underlying collection.
{quote}
 

I think this *should* be possible, but definitely should not be the default 
behavior. ( {{=true}} or something similarly clear 
and not accident prone should be required) It is very cumbersome to delete a 
large number of collections created by a routed alias right now. Not a common 
problem in normal scenarios, but a potential PITA when configuration mistakes 
are made.

> Ability to query aliases in Solr Admin UI
> -
>
> Key: SOLR-13122
> URL: https://issues.apache.org/jira/browse/SOLR-13122
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Reporter: mosh
>Assignee: Jan Høydahl
>Priority: Major
>  Labels: UI
> Fix For: 8.2
>
> Attachments: alias-collection-menu-selected.png, 
> alias-collection-view.png, alias-collections-menu.png, 
> alias-collections-menu.png, alias-delete-dialogue.png, alias-dropdown.png, 
> alias-select-double.png, alias-view.png, new-collection-dropdown.png, 
> new-oll-overview.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> After having recently toyed with Time Routed Alias in SolrCloud,
> we have noticed there is no way to query an alias from the admin UI,
> since the combo box only contains the current collection in the cluster.
> Solr Admin UI ought to have a way to query these aliases, for better 
> convenience.



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

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

[JENKINS] Lucene-Solr-BadApples-Tests-8.x - Build # 138 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-8.x/138/

4 tests failed.
FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testCollection

Error Message:
expected:<280> but was:<256>

Stack Trace:
java.lang.AssertionError: expected:<280> but was:<256>
at 
__randomizedtesting.SeedInfo.seed([91D5E36CBCD5A071:7EFCC1D1974814F5]: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.lucene.util.TestRamUsageEstimator.testCollection(TestRamUsageEstimator.java:147)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testBytesRefHash

Error Message:
expected:<35952> but was:<35920>

Stack Trace:
java.lang.AssertionError: expected:<35952> but was:<35920>
at 
__randomizedtesting.SeedInfo.seed([91D5E36CBCD5A071:4828185E2A7002D9]: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 

Re: [JENKINS] Solr-reference-guide-8.x - Build # 3944 - Still Failing

[Steve Rowe]

INFRA JIRA for "websites2" problem: 
https://issues.apache.org/jira/browse/INFRA-18666 


JIRA to add GPG key download to the ref guide build script: 
https://issues.apache.org/jira/browse/SOLR-13582

--
Steve

> On Jun 27, 2019, at 10:50 AM, Steve Rowe  wrote:
> 
> The 8.x ref guide builds are running on a node they've never run on before: 
> "websites2".  The master ref guide builds are running on the "websites1" 
> node, which has not exhibited the same build problems.  Both nodes are pinned 
> to label "git-websites", which can result in builds on either the "websites1" 
> node or the "websites2" node.  AFAICT there's some kind of routing based on 
> the identity (name maybe?) of the job, which results in effectively permanent 
> assignment to either one or the other node.
> 
> I put the key download commands from the error message into the 8.x job 
> config and triggered a run.  This enabled verification.  But there is now 
> another problem related to RVM's installation of Ruby 2.3.3: compilation is 
> failing, with details in a log file on the "websites2" machine, to which I 
> don't have access.  I'll contact Infra about it.
> 
> In the meantime, I pinned the 8.x build to "websites1" and triggered a build, 
> which succeeded.  I left in the key download commands, so leaving them in 
> permanently apparently wouldn't cause any trouble.  (I'll make an issue to 
> modify our build script to include a check for the keys and download them if 
> they don't exist.)
> 
> --
> Steve
> 
>> On Jun 27, 2019, at 9:22 AM, Cassandra Targett > > wrote:
>> 
>> Thanks Steve, that makes sense. Let me know if there’s anything I can do to 
>> help.
>> 
>> If possible, maybe the script could check for the keys and import them if 
>> not available? At the very least, maybe I should add something about this 
>> scenario to internal Ref Guide docs. I totally forgot this had happened 
>> before.
>> 
>> Sorry, I didn’t mean to imply you needed to disable the 8.1 job - I forgot 
>> to mention I recently gave myself permissions to do that in Jenkins - but 
>> thank you for doing it.
>> 
>> Cassandra
>> On Jun 27, 2019, 8:12 AM -0500, Steve Rowe > >, wrote:
>>> This has happened previously.  Usually it's a new machine that has never 
>>> built the ref guide previously.  IIRC there was an Infra notice a couple 
>>> days ago about one of the 2 machines used to build the ref guide 
>>> ("website1" OSLT) being taken offline.  Probably they put in place a 
>>> replacement for it.
>>> 
>>> In the past I've modified the job config to do what's suggested in the 
>>> error message: download the key to the new machine, trigger a run, then 
>>> comment out the key download in the job config.
>>> 
>>> I suppose we could always download the key on every run?
>>> 
>>> I'll work on it later today.
>>> 
>>> I'll go disable the 8.1 ref guide job now.
>>> 
>>> --
>>> Steve
>>> 
 On Jun 27, 2019, at 8:02 AM, Cassandra Targett >>> > wrote:
 
 This seems to be a persistent problem. It’s complaining about the keys for 
 checking the RVM download. Right now it’s the 8.x job that’s failing (and 
 8.1, which needs to be disabled), but the master branch build appears to 
 be fine.
 
 The jenkins.build.ref.guide.sh does the build, and I note in the beginning 
 of the script that it seems to assume that the RVM package keys are 
 already imported on the server (see 
 https://github.com/apache/lucene-solr/blob/master/dev-tools/scripts/jenkins.build.ref.guide.sh#L13
  
 ).
 
 Steve, you wrote this script and set up the overall build processes, do 
 you think the problem here might be that some changes have been made on 
 the Jenkins servers that removed those keys? The work to set this up was 
 done in https://issues.apache.org/jira/browse/SOLR-10568 
 , but it doesn’t mention 
 the keys or how they got imported onto those machines, so that part isn’t 
 clear to me.
 
 Thanks,
 
 Cassandra
 On Jun 27, 2019, 4:52 AM -0500, Apache Jenkins Server 
 mailto:jenk...@builds.apache.org>>, wrote:
> Build: https://builds.apache.org/job/Solr-reference-guide-8.x/3944/ 
> 
> 
> Log:
> Started by timer
> [EnvInject] - Loading node environment variables.
> Building remotely on websites2 (git-websites svn-websites) in workspace 
> /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-8.x
> No credentials specified
>> git rev-parse --is-inside-work-tree # timeout=10
> Fetching changes from the remote Git repository
>> git config remote.origin.url 
>> 

[jira] [Updated] (SOLR-13582) Ref guide build script: always check for and download public keys used to verify RVM distribution signature

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-13582:
--
Summary: Ref guide build script: always check for and download public keys 
used to verify RVM distribution signature  (was: Ref guide build script: always 
check for and download public keys used to verify RVM distributiion signature)

> Ref guide build script: always check for and download public keys used to 
> verify RVM distribution signature
> ---
>
> Key: SOLR-13582
> URL: https://issues.apache.org/jira/browse/SOLR-13582
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Minor
>
> The 8.x ref guide builds are running on a Jenkins node they've never run on 
> before: "websites2". As a result, the public keys used to verify the RVM 
> distribution are not on the machine, and when the RVM bootstrap encounters 
> this problem, it fails the build.
> In the past I've modified the Jenkins job config to download the public keys, 
> triggered a run to download the keys, and then commented out the key download 
> lines in the job config's build script.
> This issue is intended to permanently solve the problem by adding the 
> following to our build script 
> ({{dev-tools/scripts/jenkins.build.ref.guide.sh}}), to avoid manual 
> intervention when new nodes are added in the future:
>  * If {{gpg}} is installed:
>  ** If the keys needed to verify RVM distribution signature are not available:
>  *** Download the keys



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

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

[jira] [Created] (SOLR-13582) Ref guide build script: always check for and download public keys used to verify RVM distributiion signature

[Steve Rowe (JIRA)]

Steve Rowe created SOLR-13582:
-

 Summary: Ref guide build script: always check for and download 
public keys used to verify RVM distributiion signature
 Key: SOLR-13582
 URL: https://issues.apache.org/jira/browse/SOLR-13582
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Steve Rowe
Assignee: Steve Rowe


The 8.x ref guide builds are running on a Jenkins node they've never run on 
before: "websites2". As a result, the public keys used to verify the RVM 
distribution are not on the machine, and when the RVM bootstrap encounters this 
problem, it fails the build.

In the past I've modified the Jenkins job config to download the public keys, 
triggered a run to download the keys, and then commented out the key download 
lines in the job config's build script.

This issue is intended to permanently solve the problem by adding the following 
to our build script ({{dev-tools/scripts/jenkins.build.ref.guide.sh}}), to 
avoid manual intervention when new nodes are added in the future:
 * If {{gpg}} is installed:
 ** If the keys needed to verify RVM distribution signature are not available:
 *** Download the keys



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

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

[jira] [Commented] (SOLR-13571) Make recent RefGuide rank well in Google

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-13571:
--

I guess, one place to start thinking this through is on how important it is 
that users find the reference manual. As a reference, Stack Overflow (and rest 
of the network) have more focus on being discovered by Google than on their 
internal engines. Obviously, they have too, as that's where money and attention 
is. But it is still an interesting explicit goal post.

For us, if the users cannot find a relevant reference guide page quickly, they 
may
* think a particular feature does not exist
* join and ask on the User Mailing list
* discover the reference guide in general and browse through it
* discover the reference guide and use our - still limited - internal search

None of the options above seem optimal compared to leveraging the public search 
engine. But then, we have to worry about SEO. Clearly, the current SEO works 
well enough to get us to the 6.6 version of the guide and - very importantly - 
to a somewhat relevant page. Switching that to be a single target page would be 
easier for us, but may cost a lot of SEO. And, frankly, I am not at all sure 
that our guide is SEO-friendly enough on its own. I just did a search for 
MappingCharFilterFactory (as an example) and 6.6 RefGuide is at the top 
followed by (old) Javadoc, (old) Wiki, two source-code class links and then 
random websites and blogs. Latest version link just does not seem to appear in 
the first couple of pages (though 7.x clone of the RefGuide on some Chinese 
community site does).

I suspect that Google is detecting multiple guide versions as duplicate content 
and therefore only displays one version and the 6.6 version has more weight due 
to redirects. But if we remove/collapse that link, I am not sure if the 
correct/latest version of the manual will be picked up. This feels risky to me. 

I don't know what the optimal solution is, given the limited resources 
available for this part of the project. I am just really worried that lost 
Google ranking is hard to get back. Perhaps, as a minimum step, we could just 
refresh the URL map periodically to use whatever latest version is.

> Make recent RefGuide rank well in Google
> 
>
> Key: SOLR-13571
> URL: https://issues.apache.org/jira/browse/SOLR-13571
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Jan Høydahl
>Priority: Major
>
> Spinoff from SOLR-13548
> The old Confluence ref-guide has a lot of pages pointing to it, and all of 
> that link karma is delegated to the {{/solr/guide/6_6/}} html ref guide, 
> making it often rank top. However we'd want newer content to rank high. See 
> these comments for some first ideas.



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

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

[jira] [Comment Edited] (SOLR-12995) UnsupportedOperationException in HttpSolrCall.getRemotCoreUrl()

[Munendra S N (JIRA)]

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

Munendra S N edited comment on SOLR-12995 at 6/27/19 3:18 PM:
--

Looks like this is fixed in SOLR-13407. I'm planning to close this if there are 
no objections

cc [~ab]


was (Author: munendrasn):
Looks like this is fixed in SOLR-13047. I'm planning to close this if there are 
no objections

cc [~ab]

> UnsupportedOperationException in HttpSolrCall.getRemotCoreUrl()
> ---
>
> Key: SOLR-12995
> URL: https://issues.apache.org/jira/browse/SOLR-12995
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 7.5
> Environment: Debian 9.3, OpenJDK Runtime Environment (build 
> 1.8.0_181-8u181-b13-2~deb9u1-b13)
>Reporter: Markus Jelsma
>Priority: Minor
> Fix For: master (9.0), 8.2
>
>
> Spotted two of these in the logs of a production server. That collection's 
> other replicas didn't log this error. In all the logs, i have seen only two 
> occurences, just four minutes apart.
> {code}
> 2018-11-07 16:14:04.340 ERROR (qtp831236296-1185) [   ] o.a.s.s.HttpSolrCall 
> null:java.lang.UnsupportedOperationException
> at java.util.AbstractList.add(AbstractList.java:148)
> at java.util.AbstractList.add(AbstractList.java:108)
> at 
> org.apache.solr.servlet.HttpSolrCall.getRemotCoreUrl(HttpSolrCall.java:905)
> at 
> org.apache.solr.servlet.HttpSolrCall.extractRemotePath(HttpSolrCall.java:431)
> at org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:288)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:469)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)
> 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:1595)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)
> 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:531)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)
> at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)
> at 
> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)
> at 
> 

[jira] [Resolved] (SOLR-5313) json update extract boost from document value

[Munendra S N (JIRA)]

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

Munendra S N resolved SOLR-5313.

Resolution: Won't Do

As index times boosts are  no longer supported. closing this

> json update extract boost from document value
> -
>
> Key: SOLR-5313
> URL: https://issues.apache.org/jira/browse/SOLR-5313
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 3.6
>Reporter: Nicolas Franck
>Priority: Minor
>  Labels: boost, document, json, solr, update
>
> The current JsonLoader in org.apache.solr.handler provides a way to add a 
> boost to a document as a whole. But if you want to add multiple documents,
> each with its own boost, you have to create something like this:
> {
>   "add": { "boost":2.0, "doc": {} },
>   "add": { "boost":2.0, "doc": {} }
>   ..
> }
> No idea which JSON-writer can do this (I use the one from perl,
> that does not support duplicate keys).
> Therefore I tried to alter some of the code in JsonLoader::handleAdds.
> The code is between "//test - start" and "//test - end":
>   cmd.solrDoc = parseDoc(ev);
>   //test - start
>   if(boost_field != null){
>   SolrInputField b_field = cmd.solrDoc.getField(boost_field);
>   if(b_field != null){
>   log.info("boost_field found in document with value 
> '"+b_field.getFirstValue()+"'");  
>   float boost = 
> Float.parseFloat((String)b_field.getFirstValue());  
>   cmd.solrDoc.setDocumentBoost(boost);
>   cmd.solrDoc.removeField(boost_field);
>   }
>   }
>   //test - end
>  processor.processAdd(cmd);
> In this code I try to extract the boost value for the document from the 
> document itself. The default field is configured as "_boost", and is deleted
> from the document afterwards.
> I tried to subclass JsonLoader, but sadly the class is package-protected ;-)
> Could this be an interesting contribution?



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

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

Re: Welcome Kevin Risden to the PMC

[Erick Erickson]

Welcome Kevin!

> On Jun 27, 2019, at 5:04 AM, Jan Høydahl  wrote:
> 
> I am pleased to announce that Kevin Risden has accepted the PMC's invitation 
> to join.
> 
> Welcome Kevin!
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
> 
> 
> -
> 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

Re: [JENKINS] Solr-reference-guide-8.x - Build # 3944 - Still Failing

[Steve Rowe]

The 8.x ref guide builds are running on a node they've never run on before: 
"websites2".  The master ref guide builds are running on the "websites1" node, 
which has not exhibited the same build problems.  Both nodes are pinned to 
label "git-websites", which can result in builds on either the "websites1" node 
or the "websites2" node.  AFAICT there's some kind of routing based on the 
identity (name maybe?) of the job, which results in effectively permanent 
assignment to either one or the other node.

I put the key download commands from the error message into the 8.x job config 
and triggered a run.  This enabled verification.  But there is now another 
problem related to RVM's installation of Ruby 2.3.3: compilation is failing, 
with details in a log file on the "websites2" machine, to which I don't have 
access.  I'll contact Infra about it.

In the meantime, I pinned the 8.x build to "websites1" and triggered a build, 
which succeeded.  I left in the key download commands, so leaving them in 
permanently apparently wouldn't cause any trouble.  (I'll make an issue to 
modify our build script to include a check for the keys and download them if 
they don't exist.)

--
Steve

> On Jun 27, 2019, at 9:22 AM, Cassandra Targett  wrote:
> 
> Thanks Steve, that makes sense. Let me know if there’s anything I can do to 
> help.
> 
> If possible, maybe the script could check for the keys and import them if not 
> available? At the very least, maybe I should add something about this 
> scenario to internal Ref Guide docs. I totally forgot this had happened 
> before.
> 
> Sorry, I didn’t mean to imply you needed to disable the 8.1 job - I forgot to 
> mention I recently gave myself permissions to do that in Jenkins - but thank 
> you for doing it.
> 
> Cassandra
> On Jun 27, 2019, 8:12 AM -0500, Steve Rowe , wrote:
>> This has happened previously.  Usually it's a new machine that has never 
>> built the ref guide previously.  IIRC there was an Infra notice a couple 
>> days ago about one of the 2 machines used to build the ref guide ("website1" 
>> OSLT) being taken offline.  Probably they put in place a replacement for it.
>> 
>> In the past I've modified the job config to do what's suggested in the error 
>> message: download the key to the new machine, trigger a run, then comment 
>> out the key download in the job config.
>> 
>> I suppose we could always download the key on every run?
>> 
>> I'll work on it later today.
>> 
>> I'll go disable the 8.1 ref guide job now.
>> 
>> --
>> Steve
>> 
>>> On Jun 27, 2019, at 8:02 AM, Cassandra Targett >> > wrote:
>>> 
>>> This seems to be a persistent problem. It’s complaining about the keys for 
>>> checking the RVM download. Right now it’s the 8.x job that’s failing (and 
>>> 8.1, which needs to be disabled), but the master branch build appears to be 
>>> fine.
>>> 
>>> The jenkins.build.ref.guide.sh does the build, and I note in the beginning 
>>> of the script that it seems to assume that the RVM package keys are already 
>>> imported on the server (see 
>>> https://github.com/apache/lucene-solr/blob/master/dev-tools/scripts/jenkins.build.ref.guide.sh#L13
>>>  
>>> ).
>>> 
>>> Steve, you wrote this script and set up the overall build processes, do you 
>>> think the problem here might be that some changes have been made on the 
>>> Jenkins servers that removed those keys? The work to set this up was done 
>>> in https://issues.apache.org/jira/browse/SOLR-10568 
>>> , but it doesn’t mention 
>>> the keys or how they got imported onto those machines, so that part isn’t 
>>> clear to me.
>>> 
>>> Thanks,
>>> 
>>> Cassandra
>>> On Jun 27, 2019, 4:52 AM -0500, Apache Jenkins Server 
>>> mailto:jenk...@builds.apache.org>>, wrote:
 Build: https://builds.apache.org/job/Solr-reference-guide-8.x/3944/ 
 
 
 Log:
 Started by timer
 [EnvInject] - Loading node environment variables.
 Building remotely on websites2 (git-websites svn-websites) in workspace 
 /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-8.x
 No credentials specified
> git rev-parse --is-inside-work-tree # timeout=10
 Fetching changes from the remote Git repository
> git config remote.origin.url 
> https://gitbox.apache.org/repos/asf/lucene-solr.git 
>  # timeout=10
 Cleaning workspace
> git rev-parse --verify HEAD # timeout=10
 Resetting working tree
> git reset --hard # timeout=10
> git clean -fdx # timeout=10
 Fetching upstream changes from 
 https://gitbox.apache.org/repos/asf/lucene-solr.git 
 
> git --version # timeout=10
> git fetch --tags --progress 
> 

[jira] [Commented] (SOLR-13122) Ability to query aliases in Solr Admin UI

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-13122:
---

[~janhoy] We're on the same page actually. You wrote:

"I’m ok with an alias with same name if it is 100% we’ll defined everywhere 
that it is the alias that takes precedence..."

I don't have complete faith that we've done that. Or that even if we do 
everyone will be aware of whatever rules we define and follow them in future. 
And AFAICT, we don't have tests that test all of the conditions. I'm in favor 
of requiring that aliases and collections be disjoint sets of names if we have 
a path for users to deal with the situation I outlined. Currently, one little 
programming error and it's a catastrophe. Say somebody deletes an alias and we 
follow it and delete the underlying collection.

Wait,  wait, wait My  concern was that users could realize later that they 
needed to use aliases and couldn't/wouldn't be able to change their apps to use 
an alias with a different name. But I forgot about the collections API RENAME 
call that Andrzej put in, see SOLR-13262.

That changes things IMO. The risk I outlined about blowing away one collection 
temporarily goes away. The process would look like:

1> RENAME C1 to C1_something

2> CREATEALIAS C1 -> C1_something

Now swap the alias to point to C2_something or C1_something at will. Or create 
C2_something first and alias to that. or.. Doesn't matter, people have a way to 
atomically switch and still have a fallback. I don't  know the behavior when 
queries come in between <1> and <2>, but IMO if requests are a little wonky for 
a few minutes or if it requires a one-time maintenance window it's acceptable. 
We're talking a very short window.

This sounds like another JIRA though. I also haven't used RENAME so this is a 
little  theoretical. And we could also create a really explicit  error message 
like  "you cannot create an alias with the same name as an existing collection, 
you must  RENAME or DELETE the collection first"

> Ability to query aliases in Solr Admin UI
> -
>
> Key: SOLR-13122
> URL: https://issues.apache.org/jira/browse/SOLR-13122
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Reporter: mosh
>Assignee: Jan Høydahl
>Priority: Major
>  Labels: UI
> Fix For: 8.2
>
> Attachments: alias-collection-menu-selected.png, 
> alias-collection-view.png, alias-collections-menu.png, 
> alias-collections-menu.png, alias-delete-dialogue.png, alias-dropdown.png, 
> alias-select-double.png, alias-view.png, new-collection-dropdown.png, 
> new-oll-overview.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> After having recently toyed with Time Routed Alias in SolrCloud,
> we have noticed there is no way to query an alias from the admin UI,
> since the combo box only contains the current collection in the cluster.
> Solr Admin UI ought to have a way to query these aliases, for better 
> convenience.



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

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

[jira] [Commented] (SOLR-13571) Make recent RefGuide rank well in Google

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-13571:
--

I'm not totally against the idea of having a "latest", but I don't quite get 
why it can't be a redirect? My gut reaction is that it further complicates the 
release process, and since I'm pretty much the only one who ever does it (with 
one recent exception), I'd like to be very sure that additional steps are 
necessary. I'd be more likely to get on board if you were able to spell out the 
specific changes to the release process that this would cause.

Maybe it would be simpler to ask Infra to just change that big list of 
redirects to go to one single page that says "You have a link to the old 
version of the Ref Guide, here's where the latest versions are." Or just have 
it go to https://lucene.apache.org/solr/guide/. I mean, it's the internet - 
stuff moves and life pretty much goes on.

Related to that idea, we need to institute a proper 404 page and redirect rule 
for it.

There are also a large number of duplicated files in each release - CSS, fonts, 
images. I have been recently thinking I'd like to restructure everything so we 
stop uploading things that are very unlikely to change from release-to-release, 
but that is way beyond the scope here, and I don't have any concrete ideas 
there yet.

I think it's worth asking if the value we'd get here is worth the effort of 
more steps to the process and more duplication of content. It's been 3 years 
since we moved. I agree that having the 6.6 Guide rank highest is not good. But 
perhaps we can fix that in a simpler way?


> Make recent RefGuide rank well in Google
> 
>
> Key: SOLR-13571
> URL: https://issues.apache.org/jira/browse/SOLR-13571
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Jan Høydahl
>Priority: Major
>
> Spinoff from SOLR-13548
> The old Confluence ref-guide has a lot of pages pointing to it, and all of 
> that link karma is delegated to the {{/solr/guide/6_6/}} html ref guide, 
> making it often rank top. However we'd want newer content to rank high. See 
> these comments for some first ideas.



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

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

[jira] [Updated] (SOLR-13514) Missing closing parens in string representation of MultiBoolFunction

[Munendra S N (JIRA)]

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

Munendra S N updated SOLR-13514:

Status: Patch Available  (was: Open)

> Missing closing parens in string representation of MultiBoolFunction
> 
>
> Key: SOLR-13514
> URL: https://issues.apache.org/jira/browse/SOLR-13514
> Project: Solr
>  Issue Type: Bug
>Reporter: Florian Diebold
>Priority: Trivial
> Attachments: 0001-Fix-missing-parenthesis-in-MultiBoolFunction.patch, 
> SOLR-13514.patch
>
>
> The {{description}} function of {{MultiBoolFunction}} includes an open 
> parenthesis, but doesn't close it. This makes score explanations more 
> confusing than necessary sometimes.



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

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

[jira] [Commented] (SOLR-13514) Missing closing parens in string representation of MultiBoolFunction

[Munendra S N (JIRA)]

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

Munendra S N commented on SOLR-13514:
-

[^SOLR-13514.patch]
Changes are in lucene module. I have added the small testcase to verify this, 
probably move the issue to lucene project once tests pass

> Missing closing parens in string representation of MultiBoolFunction
> 
>
> Key: SOLR-13514
> URL: https://issues.apache.org/jira/browse/SOLR-13514
> Project: Solr
>  Issue Type: Bug
>Reporter: Florian Diebold
>Priority: Trivial
> Attachments: 0001-Fix-missing-parenthesis-in-MultiBoolFunction.patch, 
> SOLR-13514.patch
>
>
> The {{description}} function of {{MultiBoolFunction}} includes an open 
> parenthesis, but doesn't close it. This makes score explanations more 
> confusing than necessary sometimes.



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

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

[jira] [Updated] (SOLR-13514) Missing closing parens in string representation of MultiBoolFunction

[Munendra S N (JIRA)]

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

Munendra S N updated SOLR-13514:

Attachment: SOLR-13514.patch

> Missing closing parens in string representation of MultiBoolFunction
> 
>
> Key: SOLR-13514
> URL: https://issues.apache.org/jira/browse/SOLR-13514
> Project: Solr
>  Issue Type: Bug
>Reporter: Florian Diebold
>Priority: Trivial
> Attachments: 0001-Fix-missing-parenthesis-in-MultiBoolFunction.patch, 
> SOLR-13514.patch
>
>
> The {{description}} function of {{MultiBoolFunction}} includes an open 
> parenthesis, but doesn't close it. This makes score explanations more 
> confusing than necessary sometimes.



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

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

[JENKINS] Lucene-Solr-8.x-Linux (32bit/jdk1.8.0_201) - Build # 774 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/774/
Java: 32bit/jdk1.8.0_201 -client -XX:+UseG1GC

12 tests failed.
FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testBytesRefHash

Error Message:
expected:<35920> but was:<35896>

Stack Trace:
java.lang.AssertionError: expected:<35920> but was:<35896>
at 
__randomizedtesting.SeedInfo.seed([3C4B0646315F5792:E5B6FD74A7FAF53A]: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.lucene.util.TestRamUsageEstimator.testBytesRefHash(TestRamUsageEstimator.java:119)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testMap

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([3C4B0646315F5792:1C6DB2952BA444E0]:0)
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at 
org.apache.lucene.util.TestRamUsageEstimator.testMap(TestRamUsageEstimator.java:128)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 

[JENKINS] Solr-reference-guide-8.x - Build # 3949 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-8.x/3949/

Log: 
Started by user sarowe
[EnvInject] - Loading node environment variables.
Building remotely on websites2 (git-websites svn-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-8.x
No credentials specified
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from 
https://gitbox.apache.org/repos/asf/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress 
 > https://gitbox.apache.org/repos/asf/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/branch_8x^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/branch_8x^{commit} # timeout=10
Checking out Revision 976bc5151469f99a3cc3af198b870ef7b0628a1b 
(refs/remotes/origin/branch_8x)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 976bc5151469f99a3cc3af198b870ef7b0628a1b
Commit message: "LUCENE-8889: Add Tests For Accessors Of Ranges in 
PointRangeQuery (#748)"
 > git rev-list --no-walk 976bc5151469f99a3cc3af198b870ef7b0628a1b # timeout=10
No emails were triggered.
[Solr-reference-guide-8.x] $ /bin/bash -xe /tmp/jenkins11696892105446532628.sh
+ gpg2 --keyserver hkp://pool.sks-keyservers.net --recv-keys 
409B6B1796C275462A1703113804BB82D39DC0E3 
7D2BAF1CF37B13E2069D6956105BD0E739499BDB
/tmp/jenkins11696892105446532628.sh: line 4: gpg2: command not found
+ command curl -sSL https://rvm.io/mpapis.asc
+ curl -sSL https://rvm.io/mpapis.asc
+ gpg --import -
gpg: key 3804BB82D39DC0E3: 47 signatures not checked due to missing keys
gpg: /home/jenkins/.gnupg/trustdb.gpg: trustdb created
gpg: key 3804BB82D39DC0E3: public key "Michal Papis (RVM signing) 
" imported
gpg: Total number processed: 1
gpg:   imported: 1
gpg: no ultimately trusted keys found
+ command curl -sSL https://rvm.io/pkuczynski.asc
+ curl -sSL https://rvm.io/pkuczynski.asc
+ gpg --import -
gpg: key 105BD0E739499BDB: public key "Piotr Kuczynski 
" imported
gpg: Total number processed: 1
gpg:   imported: 1
+ bash dev-tools/scripts/jenkins.build.ref.guide.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.8.tar.gz
Downloading 
https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc
gpg: Signature made Wed 08 May 2019 02:14:49 PM UTC
gpg:using RSA key 7D2BAF1CF37B13E2069D6956105BD0E739499BDB
gpg: Good signature from "Piotr Kuczynski " [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7D2B AF1C F37B 13E2 069D  6956 105B D0E7 3949 9BDB
GPG verified '/home/jenkins/.rvm/archives/rvm-1.29.8.tgz'
Installing RVM to /home/jenkins/.rvm/
Installation of RVM in /home/jenkins/.rvm/ is almost complete:

  * To start using RVM you need to run `source /home/jenkins/.rvm/scripts/rvm`
in all your open shell windows, in rare cases you need to reopen all shell 
windows.
Thanks for installing RVM 
Please consider donating to our open collective to help us maintain RVM.

  Donate: https://opencollective.com/rvm/donate


+ set +x
Running 'source /home/jenkins/.rvm/scripts/rvm'
Running 'rvm cleanup all'
Cleaning up rvm archives
Cleaning up rvm repos
Cleaning up rvm src
Cleaning up rvm log
Cleaning up rvm tmp
Cleaning up rvm gemsets
Cleaning up rvm links
Cleanup done.
Running 'rvm autolibs disable'
Running 'rvm install ruby-2.3.3'
Searching for binary rubies, this might take some time.
No binary rubies available for: ubuntu/18.04/x86_64/ruby-2.3.3.
Continuing with compilation. Please read 'rvm help mount' to get more 
information on binary rubies.
Installing Ruby from source to: /home/jenkins/.rvm/rubies/ruby-2.3.3, this may 
take a while depending on your cpu(s)...
ruby-2.3.3 - #downloading ruby-2.3.3, this may take a while depending on your 
connection...
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 
0100 13.7M  100 13.7M0 0  33.9M  0 --:--:-- --:--:-- --:--:-- 33.9M
ruby-2.3.3 - #extracting ruby-2.3.3 to /home/jenkins/.rvm/src/ruby-2.3.3.
ruby-2.3.3 - #applying patch 
/home/jenkins/.rvm/patches/ruby/ruby_2_3_gcc7.patch.
ruby-2.3.3 - #applying patch 
/home/jenkins/.rvm/patches/ruby/2.3.3/random_c_using_NR_prefix.patch.
ruby-2.3.3 - 

[GitHub] [lucene-solr] s1monw commented on issue #734: LUCENE-8857: Introduce Custom Tiebreakers in TopDocs#merge

[GitBox]

s1monw commented on issue #734: LUCENE-8857: Introduce Custom Tiebreakers in 
TopDocs#merge
URL: https://github.com/apache/lucene-solr/pull/734#issuecomment-506355727
 
 
   > I think we should push this to master as you advised. Concurrently, should 
I raise a PR to add the old slicing algorithm back and call it under a version 
check?
   
   We should just revert the slicing change in 8.x IMO for now and keep it in 
master. I can do that after this is merged. I think we need a changes entry for 
this one too. LGTM otherwise.


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] Solr-reference-guide-8.x - Build # 3948 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-8.x/3948/

Log: 
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on websites2 (git-websites svn-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-8.x
No credentials specified
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from 
https://gitbox.apache.org/repos/asf/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress 
 > https://gitbox.apache.org/repos/asf/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/branch_8x^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/branch_8x^{commit} # timeout=10
Checking out Revision 976bc5151469f99a3cc3af198b870ef7b0628a1b 
(refs/remotes/origin/branch_8x)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 976bc5151469f99a3cc3af198b870ef7b0628a1b
Commit message: "LUCENE-8889: Add Tests For Accessors Of Ranges in 
PointRangeQuery (#748)"
 > git rev-list --no-walk 976bc5151469f99a3cc3af198b870ef7b0628a1b # timeout=10
No emails were triggered.
[Solr-reference-guide-8.x] $ /bin/bash -xe /tmp/jenkins16492872934279696600.sh
+ bash dev-tools/scripts/jenkins.build.ref.guide.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.8.tar.gz
Downloading 
https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc
gpg: Signature made Wed 08 May 2019 02:14:49 PM UTC
gpg:using RSA key 7D2BAF1CF37B13E2069D6956105BD0E739499BDB
gpg: Can't check signature: No public key
GPG signature verification failed for 
'/home/jenkins/.rvm/archives/rvm-1.29.8.tgz' - 
'https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc'! Try to 
install GPG v2 and then fetch the public key:

gpg --keyserver hkp://pool.sks-keyservers.net --recv-keys 
409B6B1796C275462A1703113804BB82D39DC0E3 
7D2BAF1CF37B13E2069D6956105BD0E739499BDB

or if it fails:

command curl -sSL https://rvm.io/mpapis.asc | gpg --import -
command curl -sSL https://rvm.io/pkuczynski.asc | gpg --import -

In case of further problems with validation please refer to 
https://rvm.io/rvm/security

Build step 'Execute shell' marked build as failure
Archiving artifacts
Publishing Javadoc
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-master-MacOSX (64bit/jdk-11.0.3) - Build # 5225 - Unstable!

[Policeman Jenkins Server]

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

9 tests failed.
FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testBytesRefHash

Error Message:
expected:<36104> but was:<36136>

Stack Trace:
java.lang.AssertionError: expected:<36104> but was:<36136>
at 
__randomizedtesting.SeedInfo.seed([71188C7C0EC3C753:A8E5774E986665FB]: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.lucene.util.TestRamUsageEstimator.testBytesRefHash(TestRamUsageEstimator.java:119)
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.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:834)


FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testQuery

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([71188C7C0EC3C753:FA69F80FFF49FD86]:0)
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at 
org.apache.lucene.util.TestRamUsageEstimator.testQuery(TestRamUsageEstimator.java:168)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 

[GitHub] [lucene-solr] jpountz commented on a change in pull request #747: LUCENE-8888: Improve distribution of points with data dimension in BKD tree leaves

[GitBox]

jpountz commented on a change in pull request #747: LUCENE-: Improve 
distribution of points with data dimension in BKD tree leaves
URL: https://github.com/apache/lucene-solr/pull/747#discussion_r298148028
 
 

 ##
 File path: 
lucene/core/src/java/org/apache/lucene/util/bkd/BKDRadixSelector.java
 ##
 @@ -60,14 +60,18 @@
   // prefix for temp files
   private final String tempFileNamePrefix;
 
+  private  int numDataDims, numIndexDims;
 
 Review comment:
   can they be final?


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] jpountz commented on a change in pull request #747: LUCENE-8888: Improve distribution of points with data dimension in BKD tree leaves

[GitBox]

jpountz commented on a change in pull request #747: LUCENE-: Improve 
distribution of points with data dimension in BKD tree leaves
URL: https://github.com/apache/lucene-solr/pull/747#discussion_r298148526
 
 

 ##
 File path: 
lucene/core/src/java/org/apache/lucene/util/bkd/BKDRadixSelector.java
 ##
 @@ -60,14 +60,18 @@
   // prefix for temp files
   private final String tempFileNamePrefix;
 
+  private  int numDataDims, numIndexDims;
+
 
   /**
* Sole constructor.
*/
-  public BKDRadixSelector(int numDim, int bytesPerDim, int 
maxPointsSortInHeap, Directory tempDir, String tempFileNamePrefix) {
+  public BKDRadixSelector(int numDataDims, int numIndexDims, int bytesPerDim, 
int maxPointsSortInHeap, Directory tempDir, String tempFileNamePrefix) {
 this.bytesPerDim = bytesPerDim;
-this.packedBytesLength = numDim * bytesPerDim;
-this.bytesSorted = bytesPerDim + Integer.BYTES;
+this.numDataDims = numDataDims;
+this.numIndexDims = numIndexDims;
+this.packedBytesLength = numDataDims * bytesPerDim;
+this.bytesSorted = bytesPerDim  + (numDataDims - numIndexDims) * 
bytesPerDim + Integer.BYTES;
 
 Review comment:
   Maybe add a comment saying that this accounts for the dimension we are 
sorting on, plus data-only dimensions and the doc ID. As we are making it more 
complex, it might be a bit tricky to understand what is happening here for 
someone who is reading this code for the first time.


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-SmokeRelease-8.1 - Build # 45 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.1/45/

No tests ran.

Build Log:
[...truncated 23880 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 2570 links (2103 relative) to 3374 anchors in 253 files
 [echo] Validated Links & Anchors via: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/solr/build/solr-ref-guide/bare-bones-html/

-dist-changes:
 [copy] Copying 4 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/solr/package/changes

package:

-unpack-solr-tgz:

-ensure-solr-tgz-exists:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/solr/build/solr.tgz.unpacked
[untar] Expanding: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/solr/package/solr-8.1.2.tgz
 into 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/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 = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/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 = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/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 = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/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 = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/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 = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/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 = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/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 = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/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 = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/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 = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/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 = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/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 = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/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 :: 

[jira] [Commented] (SOLR-13122) Ability to query aliases in Solr Admin UI

[Gus Heck (JIRA)]

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

Gus Heck commented on SOLR-13122:
-

Yeah, that would definitely be scope creep for this ticket. That makes sense.

> Ability to query aliases in Solr Admin UI
> -
>
> Key: SOLR-13122
> URL: https://issues.apache.org/jira/browse/SOLR-13122
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Reporter: mosh
>Assignee: Jan Høydahl
>Priority: Major
>  Labels: UI
> Fix For: 8.2
>
> Attachments: alias-collection-menu-selected.png, 
> alias-collection-view.png, alias-collections-menu.png, 
> alias-collections-menu.png, alias-delete-dialogue.png, alias-dropdown.png, 
> alias-select-double.png, alias-view.png, new-collection-dropdown.png, 
> new-oll-overview.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> After having recently toyed with Time Routed Alias in SolrCloud,
> we have noticed there is no way to query an alias from the admin UI,
> since the combo box only contains the current collection in the cluster.
> Solr Admin UI ought to have a way to query these aliases, for better 
> convenience.



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

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

Re: [JENKINS] Solr-reference-guide-8.x - Build # 3944 - Still Failing

[Cassandra Targett]

Thanks Steve, that makes sense. Let me know if there’s anything I can do to 
help.

If possible, maybe the script could check for the keys and import them if not 
available? At the very least, maybe I should add something about this scenario 
to internal Ref Guide docs. I totally forgot this had happened before.

Sorry, I didn’t mean to imply you needed to disable the 8.1 job - I forgot to 
mention I recently gave myself permissions to do that in Jenkins - but thank 
you for doing it.

Cassandra
On Jun 27, 2019, 8:12 AM -0500, Steve Rowe , wrote:
> This has happened previously.  Usually it's a new machine that has never 
> built the ref guide previously.  IIRC there was an Infra notice a couple days 
> ago about one of the 2 machines used to build the ref guide ("website1" OSLT) 
> being taken offline.  Probably they put in place a replacement for it.
>
> In the past I've modified the job config to do what's suggested in the error 
> message: download the key to the new machine, trigger a run, then comment out 
> the key download in the job config.
>
> I suppose we could always download the key on every run?
>
> I'll work on it later today.
>
> I'll go disable the 8.1 ref guide job now.
>
> --
> Steve
>
> > On Jun 27, 2019, at 8:02 AM, Cassandra Targett  
> > wrote:
> >
> > This seems to be a persistent problem. It’s complaining about the keys for 
> > checking the RVM download. Right now it’s the 8.x job that’s failing (and 
> > 8.1, which needs to be disabled), but the master branch build appears to be 
> > fine.
> >
> > The jenkins.build.ref.guide.sh does the build, and I note in the beginning 
> > of the script that it seems to assume that the RVM package keys are already 
> > imported on the server (see 
> > https://github.com/apache/lucene-solr/blob/master/dev-tools/scripts/jenkins.build.ref.guide.sh#L13).
> >
> > Steve, you wrote this script and set up the overall build processes, do you 
> > think the problem here might be that some changes have been made on the 
> > Jenkins servers that removed those keys? The work to set this up was done 
> > in https://issues.apache.org/jira/browse/SOLR-10568, but it doesn’t mention 
> > the keys or how they got imported onto those machines, so that part isn’t 
> > clear to me.
> >
> > Thanks,
> >
> > Cassandra
> > On Jun 27, 2019, 4:52 AM -0500, Apache Jenkins Server 
> > , wrote:
> > > Build: https://builds.apache.org/job/Solr-reference-guide-8.x/3944/
> > >
> > > Log:
> > > Started by timer
> > > [EnvInject] - Loading node environment variables.
> > > Building remotely on websites2 (git-websites svn-websites) in workspace 
> > > /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-8.x
> > > No credentials specified
> > > > git rev-parse --is-inside-work-tree # timeout=10
> > > Fetching changes from the remote Git repository
> > > > git config remote.origin.url 
> > > > https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
> > > Cleaning workspace
> > > > git rev-parse --verify HEAD # timeout=10
> > > Resetting working tree
> > > > git reset --hard # timeout=10
> > > > git clean -fdx # timeout=10
> > > Fetching upstream changes from 
> > > https://gitbox.apache.org/repos/asf/lucene-solr.git
> > > > git --version # timeout=10
> > > > git fetch --tags --progress 
> > > > https://gitbox.apache.org/repos/asf/lucene-solr.git 
> > > > +refs/heads/*:refs/remotes/origin/*
> > > > git rev-parse refs/remotes/origin/branch_8x^{commit} # timeout=10
> > > > git rev-parse refs/remotes/origin/origin/branch_8x^{commit} # timeout=10
> > > Checking out Revision 4e58515b0c6aa297be2416c5e5d70e9eda4fb1db 
> > > (refs/remotes/origin/branch_8x)
> > > > git config core.sparsecheckout # timeout=10
> > > > git checkout -f 4e58515b0c6aa297be2416c5e5d70e9eda4fb1db
> > > Commit message: "LUCENE-8886: Fix TestMutablePointsReaderUtils tests"
> > > > git rev-list --no-walk cf443ad9f756407fa8db5ad5bfd39c26367acbc9 # 
> > > > timeout=10
> > > No emails were triggered.
> > > [Solr-reference-guide-8.x] $ /bin/bash -xe 
> > > /tmp/jenkins9997498791593161379.sh
> > > + bash dev-tools/scripts/jenkins.build.ref.guide.sh
> > > + set -e
> > > + RVM_PATH=/home/jenkins/.rvm
> > > + RUBY_VERSION=ruby-2.3.3
> > > + GEMSET=solr-refguide-gemset
> > > + curl -sSL https://get.rvm.io
> > > + bash -s -- --ignore-dotfiles stable
> > > Turning on ignore dotfiles mode.
> > > Downloading https://github.com/rvm/rvm/archive/1.29.8.tar.gz
> > > Downloading 
> > > https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc
> > > gpg: Signature made Wed 08 May 2019 02:14:49 PM UTC
> > > gpg: using RSA key 7D2BAF1CF37B13E2069D6956105BD0E739499BDB
> > > gpg: Can't check signature: No public key
> > > GPG signature verification failed for 
> > > '/home/jenkins/.rvm/archives/rvm-1.29.8.tgz' - 
> > > 'https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc'! 
> > > Try to install GPG v2 and then fetch the public key:
> > >
> > > gpg --keyserver hkp://pool.sks-keyservers.net 

Re: [JENKINS] Solr-reference-guide-8.x - Build # 3944 - Still Failing

[Steve Rowe]

This has happened previously.  Usually it's a new machine that has never built 
the ref guide previously.  IIRC there was an Infra notice a couple days ago 
about one of the 2 machines used to build the ref guide ("website1" OSLT) being 
taken offline.  Probably they put in place a replacement for it.

In the past I've modified the job config to do what's suggested in the error 
message: download the key to the new machine, trigger a run, then comment out 
the key download in the job config.

I suppose we could always download the key on every run?

I'll work on it later today.

I'll go disable the 8.1 ref guide job now.

--
Steve

> On Jun 27, 2019, at 8:02 AM, Cassandra Targett  wrote:
> 
> This seems to be a persistent problem. It’s complaining about the keys for 
> checking the RVM download. Right now it’s the 8.x job that’s failing (and 
> 8.1, which needs to be disabled), but the master branch build appears to be 
> fine.
> 
> The jenkins.build.ref.guide.sh does the build, and I note in the beginning of 
> the script that it seems to assume that the RVM package keys are already 
> imported on the server (see 
> https://github.com/apache/lucene-solr/blob/master/dev-tools/scripts/jenkins.build.ref.guide.sh#L13
>  
> ).
> 
> Steve, you wrote this script and set up the overall build processes, do you 
> think the problem here might be that some changes have been made on the 
> Jenkins servers that removed those keys? The work to set this up was done in 
> https://issues.apache.org/jira/browse/SOLR-10568 
> , but it doesn’t mention 
> the keys or how they got imported onto those machines, so that part isn’t 
> clear to me.
> 
> Thanks,
> 
> Cassandra
> On Jun 27, 2019, 4:52 AM -0500, Apache Jenkins Server 
> , wrote:
>> Build: https://builds.apache.org/job/Solr-reference-guide-8.x/3944/
>> 
>> Log:
>> Started by timer
>> [EnvInject] - Loading node environment variables.
>> Building remotely on websites2 (git-websites svn-websites) in workspace 
>> /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-8.x
>> No credentials specified
>>> git rev-parse --is-inside-work-tree # timeout=10
>> Fetching changes from the remote Git repository
>>> git config remote.origin.url 
>>> https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
>> Cleaning workspace
>>> git rev-parse --verify HEAD # timeout=10
>> Resetting working tree
>>> git reset --hard # timeout=10
>>> git clean -fdx # timeout=10
>> Fetching upstream changes from 
>> https://gitbox.apache.org/repos/asf/lucene-solr.git
>>> git --version # timeout=10
>>> git fetch --tags --progress 
>>> https://gitbox.apache.org/repos/asf/lucene-solr.git 
>>> +refs/heads/*:refs/remotes/origin/*
>>> git rev-parse refs/remotes/origin/branch_8x^{commit} # timeout=10
>>> git rev-parse refs/remotes/origin/origin/branch_8x^{commit} # timeout=10
>> Checking out Revision 4e58515b0c6aa297be2416c5e5d70e9eda4fb1db 
>> (refs/remotes/origin/branch_8x)
>>> git config core.sparsecheckout # timeout=10
>>> git checkout -f 4e58515b0c6aa297be2416c5e5d70e9eda4fb1db
>> Commit message: "LUCENE-8886: Fix TestMutablePointsReaderUtils tests"
>>> git rev-list --no-walk cf443ad9f756407fa8db5ad5bfd39c26367acbc9 # timeout=10
>> No emails were triggered.
>> [Solr-reference-guide-8.x] $ /bin/bash -xe /tmp/jenkins9997498791593161379.sh
>> + bash dev-tools/scripts/jenkins.build.ref.guide.sh
>> + set -e
>> + RVM_PATH=/home/jenkins/.rvm
>> + RUBY_VERSION=ruby-2.3.3
>> + GEMSET=solr-refguide-gemset
>> + curl -sSL https://get.rvm.io
>> + bash -s -- --ignore-dotfiles stable
>> Turning on ignore dotfiles mode.
>> Downloading https://github.com/rvm/rvm/archive/1.29.8.tar.gz
>> Downloading 
>> https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc
>> gpg: Signature made Wed 08 May 2019 02:14:49 PM UTC
>> gpg: using RSA key 7D2BAF1CF37B13E2069D6956105BD0E739499BDB
>> gpg: Can't check signature: No public key
>> GPG signature verification failed for 
>> '/home/jenkins/.rvm/archives/rvm-1.29.8.tgz' - 
>> 'https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc'! Try 
>> to install GPG v2 and then fetch the public key:
>> 
>> gpg --keyserver hkp://pool.sks-keyservers.net --recv-keys 
>> 409B6B1796C275462A1703113804BB82D39DC0E3 
>> 7D2BAF1CF37B13E2069D6956105BD0E739499BDB
>> 
>> or if it fails:
>> 
>> command curl -sSL https://rvm.io/mpapis.asc | gpg --import -
>> command curl -sSL https://rvm.io/pkuczynski.asc | gpg --import -
>> 
>> In case of further problems with validation please refer to 
>> https://rvm.io/rvm/security
>> 
>> Build step 'Execute shell' marked build as failure
>> Archiving artifacts
>> Publishing Javadoc
>> Email was triggered for: Failure - Any
>> Sending email for trigger: Failure - Any
>> 
>> 
>> -
>> To unsubscribe, e-mail: 

[jira] [Commented] (SOLR-13122) Ability to query aliases in Solr Admin UI

[JIRA]

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

Jan Høydahl commented on SOLR-13122:


Ok, I don't have ambitions to restructure the whole UI in this issue, so I'll 
clean up so that the current proposed UI handles aliases and collections with 
the same name and then commit. Then let's open other Jiras to fix the dropdown 
or to get rid of duplication.

> Ability to query aliases in Solr Admin UI
> -
>
> Key: SOLR-13122
> URL: https://issues.apache.org/jira/browse/SOLR-13122
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Reporter: mosh
>Assignee: Jan Høydahl
>Priority: Major
>  Labels: UI
> Fix For: 8.2
>
> Attachments: alias-collection-menu-selected.png, 
> alias-collection-view.png, alias-collections-menu.png, 
> alias-collections-menu.png, alias-delete-dialogue.png, alias-dropdown.png, 
> alias-select-double.png, alias-view.png, new-collection-dropdown.png, 
> new-oll-overview.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> After having recently toyed with Time Routed Alias in SolrCloud,
> we have noticed there is no way to query an alias from the admin UI,
> since the combo box only contains the current collection in the cluster.
> Solr Admin UI ought to have a way to query these aliases, for better 
> convenience.



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

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

[jira] [Commented] (LUCENE-8857) Refactor TopDocs#Merge To Take In Custom Tie Breakers

[Atri Sharma (JIRA)]

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

Atri Sharma commented on LUCENE-8857:
-

Updated the PR with latest comments, removing merge functionality as well. 
Happy to iterate further

> Refactor TopDocs#Merge To Take In Custom Tie Breakers
> -
>
> Key: LUCENE-8857
> URL: https://issues.apache.org/jira/browse/LUCENE-8857
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Major
> Attachments: LUCENE-8857.patch, LUCENE-8857.patch, LUCENE-8857.patch, 
> LUCENE-8857.patch, LUCENE-8857.patch
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> In LUCENE-8829, the idea of having lambdas passed in to the API to allow 
> finer control over the process was discussed.
> This JIRA tracks adding a parameter to the API which allows passing in 
> lambdas to define custom tie breakers, thus allowing users to do custom 
> algorithms when required.
> CC: [~jpountz]  [~simonw] 



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

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

[GitHub] [lucene-solr] atris commented on issue #729: LUCENE-8862: Introduce Collector Level Memory Accounting

[GitBox]

atris commented on issue #729: LUCENE-8862: Introduce Collector Level Memory 
Accounting
URL: https://github.com/apache/lucene-solr/pull/729#issuecomment-506336287
 
 
   Thanks a ton!


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] [Resolved] (LUCENE-8887) CLONE - Add setting for moving FST offheap/onheap

[Simon Willnauer (JIRA)]

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

Simon Willnauer resolved LUCENE-8887.
-
Resolution: Duplicate

this seems to be opened accidentially

> CLONE - Add setting for moving FST offheap/onheap
> -
>
> Key: LUCENE-8887
> URL: https://issues.apache.org/jira/browse/LUCENE-8887
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: core/FSTs, core/store
>Reporter: LuYunCheng
>Assignee: Simon Willnauer
>Priority: Minor
> Fix For: master (9.0), 8.1
>
> Attachments: offheap_generic_settings.patch, offheap_settings.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> While LUCENE-8635, adds support for loading FST offheap using mmap, users do 
> not have the  flexibility to specify fields for which FST needs to be 
> offheap. This allows users to tune heap usage as per their workload.
> Ideal way will be to add an attribute to FieldInfo, where we have 
> put/getAttribute. Then FieldReader can inspect the FieldInfo and pass the 
> appropriate On/OffHeapStore when creating its FST. It can support special 
> keywords like ALL/NONE.



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

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

[JENKINS] Solr-reference-guide-8.x - Build # 3947 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-8.x/3947/

Log: 
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on websites2 (git-websites svn-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-8.x
No credentials specified
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from 
https://gitbox.apache.org/repos/asf/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress 
 > https://gitbox.apache.org/repos/asf/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/branch_8x^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/branch_8x^{commit} # timeout=10
Checking out Revision 976bc5151469f99a3cc3af198b870ef7b0628a1b 
(refs/remotes/origin/branch_8x)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 976bc5151469f99a3cc3af198b870ef7b0628a1b
Commit message: "LUCENE-8889: Add Tests For Accessors Of Ranges in 
PointRangeQuery (#748)"
 > git rev-list --no-walk 4e58515b0c6aa297be2416c5e5d70e9eda4fb1db # timeout=10
No emails were triggered.
[Solr-reference-guide-8.x] $ /bin/bash -xe /tmp/jenkins13165404624257453792.sh
+ bash dev-tools/scripts/jenkins.build.ref.guide.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.8.tar.gz
Downloading 
https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc
gpg: Signature made Wed 08 May 2019 02:14:49 PM UTC
gpg:using RSA key 7D2BAF1CF37B13E2069D6956105BD0E739499BDB
gpg: Can't check signature: No public key
GPG signature verification failed for 
'/home/jenkins/.rvm/archives/rvm-1.29.8.tgz' - 
'https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc'! Try to 
install GPG v2 and then fetch the public key:

gpg --keyserver hkp://pool.sks-keyservers.net --recv-keys 
409B6B1796C275462A1703113804BB82D39DC0E3 
7D2BAF1CF37B13E2069D6956105BD0E739499BDB

or if it fails:

command curl -sSL https://rvm.io/mpapis.asc | gpg --import -
command curl -sSL https://rvm.io/pkuczynski.asc | gpg --import -

In case of further problems with validation please refer to 
https://rvm.io/rvm/security

Build step 'Execute shell' marked build as failure
Archiving artifacts
Publishing Javadoc
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

[GitHub] [lucene-solr] atris commented on issue #729: LUCENE-8862: Introduce Collector Level Memory Accounting

[GitBox]

atris commented on issue #729: LUCENE-8862: Introduce Collector Level Memory 
Accounting
URL: https://github.com/apache/lucene-solr/pull/729#issuecomment-506330431
 
 
   @jpountz  Sorry, somehow missed moving the actual interface. Done now, let 
me know if it seems fine.


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] [Comment Edited] (SOLR-13122) Ability to query aliases in Solr Admin UI

[Gus Heck (JIRA)]

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

Gus Heck edited comment on SOLR-13122 at 6/27/19 12:27 PM:
---

I actually don't much like the collection drop down on the left. If anything 
goes it should be that. It's terribly hard to use if you have >10 collections 
or collection names longer than "foobar" Make one Time Routed Alias with daily 
collections for a month (which soon creates 30 collections named 
tweetsOrSomething_2019-06-XX) and then try to find your other collection 
"foobar" among the 30 wrapping entries in that drop down ...  yeah you have 
type ahead, but the drop down part becomes entirely useless. If you don't 
know/can't remember the collection name (or are exploring a new client's 
install on a testing machine?) the drop down is a pretty bad view of what 
exists. (and you would never even find the aliases without a lot of looking). 

One convenience for testing what things look like with lots of collections 
would be to create a TRA with a start date in the past and set maxFutureMs to 
something very high, and then send in one doc (via documents) with an id and 
the current date... it will then create a bunch of longish collection names for 
you. Note that I once did this with monthly collections since 1970 (a client 
was trying and luckily failing to do that, I did it just for fun locally to see 
if it could even work) and it crushed the system and died after the 500th 
collection and like 20 minutes so don't get too carried away :). 


was (Author: gus_heck):
I actually don't much like the collection drop down on the left. If anything 
goes it should be that. It's terribly hard to use if you have >10 collections 
or collection names longer than "foobar" Make one Time Routed Alias with daily 
collections for a month (which soon creates 30 collections named 
tweetsOrSomething_2019-06-XX) and then try to find you other collection 
"foobar" among the 30 wrapping entries in that drop down ...  yeah you have 
type ahead, but the drop down part becomes entirely useless. If you don't 
know/can't remember the collection name (or are exploring a new client's 
install on a testing machine?) the drop down is a pretty bad view of what 
exists. (and you would never even find the aliases without a lot of looking). 

One convenience for testing what things look like with lots of collections 
would be to create a TRA with a start date in the past and set maxFutureMs to 
something very high, and then send in one doc (via documents) with an id and 
the current date... it will then create a bunch of longish collection names for 
you. Note that I once did this with monthly collections since 1970 (a client 
was trying and luckily failing to do that, I did it just for fun locally to see 
if it could even work) and it crushed the system and died after the 500th 
collection and like 20 minutes so don't get too carried away :). 

> Ability to query aliases in Solr Admin UI
> -
>
> Key: SOLR-13122
> URL: https://issues.apache.org/jira/browse/SOLR-13122
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Reporter: mosh
>Assignee: Jan Høydahl
>Priority: Major
>  Labels: UI
> Fix For: 8.2
>
> Attachments: alias-collection-menu-selected.png, 
> alias-collection-view.png, alias-collections-menu.png, 
> alias-collections-menu.png, alias-delete-dialogue.png, alias-dropdown.png, 
> alias-select-double.png, alias-view.png, new-collection-dropdown.png, 
> new-oll-overview.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> After having recently toyed with Time Routed Alias in SolrCloud,
> we have noticed there is no way to query an alias from the admin UI,
> since the combo box only contains the current collection in the cluster.
> Solr Admin UI ought to have a way to query these aliases, for better 
> convenience.



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

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

[jira] [Commented] (SOLR-13122) Ability to query aliases in Solr Admin UI

[Gus Heck (JIRA)]

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

Gus Heck commented on SOLR-13122:
-

I actually don't much like the collection drop down on the left. If anything 
goes it should be that. It's terribly hard to use if you have >10 collections 
or collection names longer than "foobar" Make one Time Routed Alias with daily 
collections for a month (which soon creates 30 collections named 
tweetsOrSomething_2019-06-XX) and then try to find you other collection 
"foobar" among the 30 wrapping entries in that drop down ...  yeah you have 
type ahead, but the drop down part becomes entirely useless. If you don't 
know/can't remember the collection name (or are exploring a new client's 
install on a testing machine?) the drop down is a pretty bad view of what 
exists. (and you would never even find the aliases without a lot of looking). 

One convenience for testing what things look like with lots of collections 
would be to create a TRA with a start date in the past and set maxFutureMs to 
something very high, and then send in one doc (via documents) with an id and 
the current date... it will then create a bunch of longish collection names for 
you. Note that I once did this with monthly collections since 1970 (a client 
was trying and luckily failing to do that, I did it just for fun locally to see 
if it could even work) and it crushed the system and died after the 500th 
collection and like 20 minutes so don't get too carried away :). 

> Ability to query aliases in Solr Admin UI
> -
>
> Key: SOLR-13122
> URL: https://issues.apache.org/jira/browse/SOLR-13122
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Reporter: mosh
>Assignee: Jan Høydahl
>Priority: Major
>  Labels: UI
> Fix For: 8.2
>
> Attachments: alias-collection-menu-selected.png, 
> alias-collection-view.png, alias-collections-menu.png, 
> alias-collections-menu.png, alias-delete-dialogue.png, alias-dropdown.png, 
> alias-select-double.png, alias-view.png, new-collection-dropdown.png, 
> new-oll-overview.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> After having recently toyed with Time Routed Alias in SolrCloud,
> we have noticed there is no way to query an alias from the admin UI,
> since the combo box only contains the current collection in the cluster.
> Solr Admin UI ought to have a way to query these aliases, for better 
> convenience.



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

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

[GitHub] [lucene-solr] jpountz commented on a change in pull request #746: LUCENE-8885: Optimise BKD reader by exploiting cardinality information stored on leaves

[GitBox]

jpountz commented on a change in pull request #746: LUCENE-8885: Optimise BKD 
reader by exploiting cardinality information stored on leaves
URL: https://github.com/apache/lucene-solr/pull/746#discussion_r298139661
 
 

 ##
 File path: lucene/core/src/java/org/apache/lucene/index/PointValues.java
 ##
 @@ -208,6 +208,15 @@ protected PointValues() {
  *  docID order. */
 void visit(int docID, byte[] packedValue) throws IOException;
 
+/** Similar to {@link IntersectVisitor#visit(int, byte[])} but in this 
case the packedValue
+ * can have more than one docID associated to it. */
 
 Review comment:
   Can you document that the iterator should not escape the scope of this 
method so that implementations of PointValues are free to reuse the iterator?


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] jpountz commented on a change in pull request #746: LUCENE-8885: Optimise BKD reader by exploiting cardinality information stored on leaves

[GitBox]

jpountz commented on a change in pull request #746: LUCENE-8885: Optimise BKD 
reader by exploiting cardinality information stored on leaves
URL: https://github.com/apache/lucene-solr/pull/746#discussion_r298140894
 
 

 ##
 File path: lucene/core/src/java/org/apache/lucene/util/bkd/BKDReader.java
 ##
 @@ -780,4 +783,43 @@ public int getDocCount() {
   public boolean isLeafNode(int nodeID) {
 return nodeID >= leafNodeOffset;
   }
+
+  protected static class BKDReaderDocIDSetIterator extends DocIdSetIterator {
+
+int idx;
+int length;
+int offset;
+int[] docIds;
+
+public BKDReaderDocIDSetIterator(int maxPointsInLeafNode) {
+  this.docIds = new int[maxPointsInLeafNode];
+}
+
+@Override
+public int docID() {
+  if (idx == -1)  {
+return -1;
+  }
+  return docIds[offset + idx];
+}
+
+@Override
+public int nextDoc() throws IOException {
+  if (idx == length - 1) {
+return DocIdSetIterator.NO_MORE_DOCS;
+  }
+  idx++;
+  return docIds[offset + idx];
+}
+
+@Override
+public int advance(int target) throws IOException {
+  throw new UnsupportedOperationException();
 
 Review comment:
   I think it'd be better to support it, even if slow. Eg. you can return 
`slowAdvance(target)`.


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

Welcome Kevin Risden to the PMC

[Jan Høydahl]

I am pleased to announce that Kevin Risden has accepted the PMC's invitation to 
join.

Welcome Kevin!

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


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

Re: [JENKINS] Solr-reference-guide-8.x - Build # 3944 - Still Failing

[Cassandra Targett]

This seems to be a persistent problem. It’s complaining about the keys for 
checking the RVM download. Right now it’s the 8.x job that’s failing (and 8.1, 
which needs to be disabled), but the master branch build appears to be fine.

The jenkins.build.ref.guide.sh does the build, and I note in the beginning of 
the script that it seems to assume that the RVM package keys are already 
imported on the server (see 
https://github.com/apache/lucene-solr/blob/master/dev-tools/scripts/jenkins.build.ref.guide.sh#L13).

Steve, you wrote this script and set up the overall build processes, do you 
think the problem here might be that some changes have been made on the Jenkins 
servers that removed those keys? The work to set this up was done in 
https://issues.apache.org/jira/browse/SOLR-10568, but it doesn’t mention the 
keys or how they got imported onto those machines, so that part isn’t clear to 
me.

Thanks,

Cassandra
On Jun 27, 2019, 4:52 AM -0500, Apache Jenkins Server 
, wrote:
> Build: https://builds.apache.org/job/Solr-reference-guide-8.x/3944/
>
> Log:
> Started by timer
> [EnvInject] - Loading node environment variables.
> Building remotely on websites2 (git-websites svn-websites) in workspace 
> /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-8.x
> No credentials specified
> > git rev-parse --is-inside-work-tree # timeout=10
> Fetching changes from the remote Git repository
> > git config remote.origin.url 
> > https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
> Cleaning workspace
> > git rev-parse --verify HEAD # timeout=10
> Resetting working tree
> > git reset --hard # timeout=10
> > git clean -fdx # timeout=10
> Fetching upstream changes from 
> https://gitbox.apache.org/repos/asf/lucene-solr.git
> > git --version # timeout=10
> > git fetch --tags --progress 
> > https://gitbox.apache.org/repos/asf/lucene-solr.git 
> > +refs/heads/*:refs/remotes/origin/*
> > git rev-parse refs/remotes/origin/branch_8x^{commit} # timeout=10
> > git rev-parse refs/remotes/origin/origin/branch_8x^{commit} # timeout=10
> Checking out Revision 4e58515b0c6aa297be2416c5e5d70e9eda4fb1db 
> (refs/remotes/origin/branch_8x)
> > git config core.sparsecheckout # timeout=10
> > git checkout -f 4e58515b0c6aa297be2416c5e5d70e9eda4fb1db
> Commit message: "LUCENE-8886: Fix TestMutablePointsReaderUtils tests"
> > git rev-list --no-walk cf443ad9f756407fa8db5ad5bfd39c26367acbc9 # timeout=10
> No emails were triggered.
> [Solr-reference-guide-8.x] $ /bin/bash -xe /tmp/jenkins9997498791593161379.sh
> + bash dev-tools/scripts/jenkins.build.ref.guide.sh
> + set -e
> + RVM_PATH=/home/jenkins/.rvm
> + RUBY_VERSION=ruby-2.3.3
> + GEMSET=solr-refguide-gemset
> + curl -sSL https://get.rvm.io
> + bash -s -- --ignore-dotfiles stable
> Turning on ignore dotfiles mode.
> Downloading https://github.com/rvm/rvm/archive/1.29.8.tar.gz
> Downloading 
> https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc
> gpg: Signature made Wed 08 May 2019 02:14:49 PM UTC
> gpg: using RSA key 7D2BAF1CF37B13E2069D6956105BD0E739499BDB
> gpg: Can't check signature: No public key
> GPG signature verification failed for 
> '/home/jenkins/.rvm/archives/rvm-1.29.8.tgz' - 
> 'https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc'! Try 
> to install GPG v2 and then fetch the public key:
>
> gpg --keyserver hkp://pool.sks-keyservers.net --recv-keys 
> 409B6B1796C275462A1703113804BB82D39DC0E3 
> 7D2BAF1CF37B13E2069D6956105BD0E739499BDB
>
> or if it fails:
>
> command curl -sSL https://rvm.io/mpapis.asc | gpg --import -
> command curl -sSL https://rvm.io/pkuczynski.asc | gpg --import -
>
> In case of further problems with validation please refer to 
> https://rvm.io/rvm/security
>
> Build step 'Execute shell' marked build as failure
> Archiving artifacts
> Publishing Javadoc
> 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

[GitHub] [lucene-solr] iverase commented on issue #747: LUCENE-8888: Improve distribution of points with data dimension in BKD tree leaves

[GitBox]

iverase commented on issue #747: LUCENE-: Improve distribution of points 
with data dimension in BKD tree leaves
URL: https://github.com/apache/lucene-solr/pull/747#issuecomment-506317120
 
 
   Thanks @jpountz, I can indeed refactor PointValue and it seems it makes a 
lot of sense. It simplifies quite a lot the logic of the offline selector.


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] [Resolved] (LUCENE-8889) Remove Dead Code From PointRangeQuery

[Adrien Grand (JIRA)]

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

Adrien Grand resolved LUCENE-8889.
--
   Resolution: Fixed
Fix Version/s: 8.2
   master (9.0)

Oops I had not seen Jim commented here before merging. I'm still resolving, but 
happy to reopen/revert if there are concerns.

> Remove Dead Code From PointRangeQuery
> -
>
> Key: LUCENE-8889
> URL: https://issues.apache.org/jira/browse/LUCENE-8889
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Minor
> Fix For: master (9.0), 8.2
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> PointRangeQuery has accessors for the underlying points in the query but 
> those are never accessed. We should remove them



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

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

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-13-ea+26) - Build # 24299 - Still unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24299/
Java: 64bit/jdk-13-ea+26 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

8 tests failed.
FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testBytesRefHash

Error Message:
expected:<36104> but was:<36120>

Stack Trace:
java.lang.AssertionError: expected:<36104> but was:<36120>
at 
__randomizedtesting.SeedInfo.seed([8F1623AA53FF2311:56EBD898C55A81B9]: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.lucene.util.TestRamUsageEstimator.testBytesRefHash(TestRamUsageEstimator.java:119)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
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:830)


FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testQuery

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([8F1623AA53FF2311:46757D9A27519C4]:0)
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at 
org.apache.lucene.util.TestRamUsageEstimator.testQuery(TestRamUsageEstimator.java:168)
at 

[jira] [Resolved] (SOLR-13581) solr-1-vm

[JIRA]

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

Jan Høydahl resolved SOLR-13581.

Resolution: Invalid

Please discuss on the mailing lists before opening a Jira issue. Closing and 
removing huge binary attachment. This mostly looks like bot spam??

> solr-1-vm
> -
>
> Key: SOLR-13581
> URL: https://issues.apache.org/jira/browse/SOLR-13581
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI, config-api, Server
>Affects Versions: 8.1.1
>Reporter: นพรุจ ปัญญาสาร
>Priority: Major
>  Labels: newbie
> Fix For: 7.0.1
>
>




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

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

[jira] [Updated] (SOLR-13581) solr-1-vm

[JIRA]

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

Jan Høydahl updated SOLR-13581:
---
Attachment: (was: instana-agent-solaris-sparc-64bit.tar.gz)

> solr-1-vm
> -
>
> Key: SOLR-13581
> URL: https://issues.apache.org/jira/browse/SOLR-13581
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI, config-api, Server
>Affects Versions: 8.1.1
>Reporter: นพรุจ ปัญญาสาร
>Priority: Major
>  Labels: newbie
> Fix For: 7.0.1
>
>




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

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

[jira] [Commented] (LUCENE-8889) Remove Dead Code From PointRangeQuery

[ASF subversion and git services (JIRA)]

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

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

Commit 976bc5151469f99a3cc3af198b870ef7b0628a1b in lucene-solr's branch 
refs/heads/branch_8x from Atri Sharma
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=976bc51 ]

LUCENE-8889: Add Tests For Accessors Of Ranges in PointRangeQuery (#748)



> Remove Dead Code From PointRangeQuery
> -
>
> Key: LUCENE-8889
> URL: https://issues.apache.org/jira/browse/LUCENE-8889
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> PointRangeQuery has accessors for the underlying points in the query but 
> those are never accessed. We should remove them



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

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

[GitHub] [lucene-solr] jpountz commented on a change in pull request #729: LUCENE-8862: Introduce Collector Level Memory Accounting

[GitBox]

jpountz commented on a change in pull request #729: LUCENE-8862: Introduce 
Collector Level Memory Accounting
URL: https://github.com/apache/lucene-solr/pull/729#discussion_r298139002
 
 

 ##
 File path: lucene/core/src/java/org/apache/lucene/util/MemoryTracker.java
 ##
 @@ -0,0 +1,26 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.lucene.util;
+
+/**
+ * Tracks dynamic allocations/deallocations of memory for transient objects
+ */
+public interface MemoryTracker {
 
 Review comment:
   can you move this one as well to misc?


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] jpountz merged pull request #748: LUCENE-8889: Add Tests For Accessors Of Ranges in PointRangeQuery

[GitBox]

jpountz merged pull request #748: LUCENE-8889: Add Tests For Accessors Of 
Ranges in PointRangeQuery
URL: https://github.com/apache/lucene-solr/pull/748
 
 
   


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


With regards,
Apache Git Services

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

[jira] [Commented] (LUCENE-8889) Remove Dead Code From PointRangeQuery

[ASF subversion and git services (JIRA)]

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

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

Commit 7cd20384de947728bb425ddcbd6f87fba419efae in lucene-solr's branch 
refs/heads/master from Atri Sharma
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7cd2038 ]

LUCENE-8889: Add Tests For Accessors Of Ranges in PointRangeQuery (#748)



> Remove Dead Code From PointRangeQuery
> -
>
> Key: LUCENE-8889
> URL: https://issues.apache.org/jira/browse/LUCENE-8889
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> PointRangeQuery has accessors for the underlying points in the query but 
> those are never accessed. We should remove them



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

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

[JENKINS] Lucene-Solr-Tests-8.x - Build # 269 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/269/

4 tests failed.
FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testQuery

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([46328D29A682BBA8:CD43F95A5708817D]:0)
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at 
org.apache.lucene.util.TestRamUsageEstimator.testQuery(TestRamUsageEstimator.java:168)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testCollection

Error Message:
expected:<280> but was:<256>

Stack Trace:
java.lang.AssertionError: expected:<280> but was:<256>
at 
__randomizedtesting.SeedInfo.seed([46328D29A682BBA8:A91BAF948D1F0F2C]: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.lucene.util.TestRamUsageEstimator.testCollection(TestRamUsageEstimator.java:147)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 

[JENKINS] Solr-reference-guide-8.x - Build # 3946 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-8.x/3946/

Log: 
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on websites2 (git-websites svn-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-8.x
No credentials specified
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from 
https://gitbox.apache.org/repos/asf/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress 
 > https://gitbox.apache.org/repos/asf/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/branch_8x^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/branch_8x^{commit} # timeout=10
Checking out Revision 4e58515b0c6aa297be2416c5e5d70e9eda4fb1db 
(refs/remotes/origin/branch_8x)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 4e58515b0c6aa297be2416c5e5d70e9eda4fb1db
Commit message: "LUCENE-8886: Fix TestMutablePointsReaderUtils tests"
 > git rev-list --no-walk 4e58515b0c6aa297be2416c5e5d70e9eda4fb1db # timeout=10
No emails were triggered.
[Solr-reference-guide-8.x] $ /bin/bash -xe /tmp/jenkins5356421071007291422.sh
+ bash dev-tools/scripts/jenkins.build.ref.guide.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.8.tar.gz
Downloading 
https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc
gpg: Signature made Wed 08 May 2019 02:14:49 PM UTC
gpg:using RSA key 7D2BAF1CF37B13E2069D6956105BD0E739499BDB
gpg: Can't check signature: No public key
GPG signature verification failed for 
'/home/jenkins/.rvm/archives/rvm-1.29.8.tgz' - 
'https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc'! Try to 
install GPG v2 and then fetch the public key:

gpg --keyserver hkp://pool.sks-keyservers.net --recv-keys 
409B6B1796C275462A1703113804BB82D39DC0E3 
7D2BAF1CF37B13E2069D6956105BD0E739499BDB

or if it fails:

command curl -sSL https://rvm.io/mpapis.asc | gpg --import -
command curl -sSL https://rvm.io/pkuczynski.asc | gpg --import -

In case of further problems with validation please refer to 
https://rvm.io/rvm/security

Build step 'Execute shell' marked build as failure
Archiving artifacts
Publishing Javadoc
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] (SOLR-13122) Ability to query aliases in Solr Admin UI

[JIRA]

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

Jan Høydahl commented on SOLR-13122:


So here is a photoshopped screenshot to show how I imagine to combine the two 
menus. First the left-hand menu, with the top "Collections" menu removed and 
the add collection/alias buttons moved to inside the dropdown:

!new-collection-dropdown.png|width=150!

An alternative to two large buttons could be a small "+" sign to the right of 
the dropdown, or *one* button "Add Collection/Alias"

Next, when you select a collection, the Overview will be what the old 
collections menu did, with the delete & reload buttons, add replica etc:

!new-oll-overview.png|width=900!

Am I missing anything? Why can't we do this?

> Ability to query aliases in Solr Admin UI
> -
>
> Key: SOLR-13122
> URL: https://issues.apache.org/jira/browse/SOLR-13122
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Reporter: mosh
>Assignee: Jan Høydahl
>Priority: Major
>  Labels: UI
> Fix For: 8.2
>
> Attachments: alias-collection-menu-selected.png, 
> alias-collection-view.png, alias-collections-menu.png, 
> alias-collections-menu.png, alias-delete-dialogue.png, alias-dropdown.png, 
> alias-select-double.png, alias-view.png, new-collection-dropdown.png, 
> new-oll-overview.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> After having recently toyed with Time Routed Alias in SolrCloud,
> we have noticed there is no way to query an alias from the admin UI,
> since the combo box only contains the current collection in the cluster.
> Solr Admin UI ought to have a way to query these aliases, for better 
> convenience.



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

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

[jira] [Updated] (SOLR-13122) Ability to query aliases in Solr Admin UI

[JIRA]

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

Jan Høydahl updated SOLR-13122:
---
Attachment: new-oll-overview.png

> Ability to query aliases in Solr Admin UI
> -
>
> Key: SOLR-13122
> URL: https://issues.apache.org/jira/browse/SOLR-13122
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Reporter: mosh
>Assignee: Jan Høydahl
>Priority: Major
>  Labels: UI
> Fix For: 8.2
>
> Attachments: alias-collection-menu-selected.png, 
> alias-collection-view.png, alias-collections-menu.png, 
> alias-collections-menu.png, alias-delete-dialogue.png, alias-dropdown.png, 
> alias-select-double.png, alias-view.png, new-collection-dropdown.png, 
> new-oll-overview.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> After having recently toyed with Time Routed Alias in SolrCloud,
> we have noticed there is no way to query an alias from the admin UI,
> since the combo box only contains the current collection in the cluster.
> Solr Admin UI ought to have a way to query these aliases, for better 
> convenience.



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

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

[jira] [Updated] (SOLR-13122) Ability to query aliases in Solr Admin UI

[JIRA]

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

Jan Høydahl updated SOLR-13122:
---
Attachment: new-collection-dropdown.png

> Ability to query aliases in Solr Admin UI
> -
>
> Key: SOLR-13122
> URL: https://issues.apache.org/jira/browse/SOLR-13122
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Reporter: mosh
>Assignee: Jan Høydahl
>Priority: Major
>  Labels: UI
> Fix For: 8.2
>
> Attachments: alias-collection-menu-selected.png, 
> alias-collection-view.png, alias-collections-menu.png, 
> alias-collections-menu.png, alias-delete-dialogue.png, alias-dropdown.png, 
> alias-select-double.png, alias-view.png, new-collection-dropdown.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> After having recently toyed with Time Routed Alias in SolrCloud,
> we have noticed there is no way to query an alias from the admin UI,
> since the combo box only contains the current collection in the cluster.
> Solr Admin UI ought to have a way to query these aliases, for better 
> convenience.



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

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

[GitHub] [lucene-solr] atris commented on issue #533: LUCENE-8636: TestPointQueries and long execution times

[GitBox]

atris commented on issue #533: LUCENE-8636: TestPointQueries and long execution 
times
URL: https://github.com/apache/lucene-solr/pull/533#issuecomment-506309671
 
 
   Is this redundant now? Should we close it?


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