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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.MissingSegmentRecoveryTest.testLeaderRecovery

Error Message:
Expected a collection with one shard and two replicas Timeout waiting to see 
state for collection=MissingSegmentRecoveryTest 
:DocCollection(MissingSegmentRecoveryTest//collections/MissingSegmentRecoveryTest/state.json/7)={
   "pullReplicas":"0",   "replicationFactor":"2",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node3":{   "core":"MissingSegmentRecoveryTest_shard1_replica_n1", 
  "base_url":"http://127.0.0.1:44168/solr;,   
"node_name":"127.0.0.1:44168_solr",   "state":"down",   
"type":"NRT",   "force_set_state":"false"}, "core_node4":{  
 "core":"MissingSegmentRecoveryTest_shard1_replica_n2",   
"base_url":"http://127.0.0.1:37120/solr;,   
"node_name":"127.0.0.1:37120_solr",   "state":"active",   
"type":"NRT",   "force_set_state":"false",   
"leader":"true",   "router":{"name":"compositeId"},   
"maxShardsPerNode":"1",   "autoAddReplicas":"false",   "nrtReplicas":"2",   
"tlogReplicas":"0"} Live Nodes: [127.0.0.1:37120_solr, 127.0.0.1:44168_solr] 
Last available state: 
DocCollection(MissingSegmentRecoveryTest//collections/MissingSegmentRecoveryTest/state.json/7)={
   "pullReplicas":"0",   "replicationFactor":"2",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node3":{   "core":"MissingSegmentRecoveryTest_shard1_replica_n1", 
  "base_url":"http://127.0.0.1:44168/solr;,   
"node_name":"127.0.0.1:44168_solr",   "state":"down",   
"type":"NRT",   "force_set_state":"false"}, "core_node4":{  
 "core":"MissingSegmentRecoveryTest_shard1_replica_n2",   
"base_url":"http://127.0.0.1:37120/solr;,   
"node_name":"127.0.0.1:37120_solr",   "state":"active",   
"type":"NRT",   "force_set_state":"false",   
"leader":"true",   "router":{"name":"compositeId"},   
"maxShardsPerNode":"1",   "autoAddReplicas":"false",   "nrtReplicas":"2",   
"tlogReplicas":"0"}

Stack Trace:
java.lang.AssertionError: Expected a collection with one shard and two replicas
Timeout waiting to see state for collection=MissingSegmentRecoveryTest 
:DocCollection(MissingSegmentRecoveryTest//collections/MissingSegmentRecoveryTest/state.json/7)={
  "pullReplicas":"0",
  "replicationFactor":"2",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node3":{
  "core":"MissingSegmentRecoveryTest_shard1_replica_n1",
  "base_url":"http://127.0.0.1:44168/solr;,
  "node_name":"127.0.0.1:44168_solr",
  "state":"down",
  "type":"NRT",
  "force_set_state":"false"},
"core_node4":{
  "core":"MissingSegmentRecoveryTest_shard1_replica_n2",
  "base_url":"http://127.0.0.1:37120/solr;,
  "node_name":"127.0.0.1:37120_solr",
  "state":"active",
  "type":"NRT",
  "force_set_state":"false",
  "leader":"true",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false",
  "nrtReplicas":"2",
  "tlogReplicas":"0"}
Live Nodes: [127.0.0.1:37120_solr, 127.0.0.1:44168_solr]
Last available state: 
DocCollection(MissingSegmentRecoveryTest//collections/MissingSegmentRecoveryTest/state.json/7)={
  "pullReplicas":"0",
  "replicationFactor":"2",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node3":{
  "core":"MissingSegmentRecoveryTest_shard1_replica_n1",
  "base_url":"http://127.0.0.1:44168/solr;,
  "node_name":"127.0.0.1:44168_solr",
  "state":"down",
  "type":"NRT",
  "force_set_state":"false"},
"core_node4":{
  "core":"MissingSegmentRecoveryTest_shard1_replica_n2",
  "base_url":"http://127.0.0.1:37120/solr;,
  "node_name":"127.0.0.1:37120_solr",
  "state":"active",
  "type":"NRT",
  "force_set_state":"false",
  "leader":"true",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false",
  "nrtReplicas":"2",
  "tlogReplicas":"0"}
at 
__randomizedtesting.SeedInfo.seed([3AD49302CCEF415F:6A810B0195CEF742]:0)
at org.junit.Assert.fail(Assert.java:88)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:310)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:288)
at 
org.apache.solr.cloud.MissingSegmentRecoveryTest.testLeaderRecovery(MissingSegmentRecoveryTest.java:106)
 

[GitHub] [lucene-solr] noblepaul commented on a change in pull request #666: SOLR-13437: fork noggit code into Solr

[GitBox]

noblepaul commented on a change in pull request #666: SOLR-13437: fork noggit 
code into Solr
URL: https://github.com/apache/lucene-solr/pull/666#discussion_r283630028
 
 

 ##
 File path: solr/solrj/src/java/org/apache/solr/common/json/ObjectBuilder.java
 ##
 @@ -0,0 +1,166 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
 
 Review comment:
   ASL let's you modify content , yeah, we can add a credit in the NOTICE.txt


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


With regards,
Apache Git Services

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

Re: Welcome Michael Sokolov as Lucene/ Solr committer

[Varun Thacker]

Congratulations Michael!

On Mon, May 13, 2019 at 9:31 PM Koji Sekiguchi 
wrote:

> Congratulations and welcome, Michael!
>
> Koji
>
> On 2019/05/14 4:11, Dawid Weiss wrote:
> > Hello everyone,
> >
> > Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!
> >
> > Many of you probably know Mike as he's been around for quite a while
> > -- answering questions, reviewing patches, providing insight and
> > actively working on new code.
> >
> > Congratulations and welcome! It is a tradition to introduce yourself
> > with a brief bio, Mike.
> >
> > Dawid
> >
> > -
> > 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
>
>

[JENKINS] Lucene-Solr-BadApples-master-Linux (64bit/jdk-11) - Build # 205 - Failure!

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 62682 lines...]
-ecj-javadoc-lint-tests:
[mkdir] Created dir: /tmp/ecj1447885494
 [ecj-lint] Compiling 48 source files to /tmp/ecj1447885494
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
 [ecj-lint] --
 [ecj-lint] 1. ERROR in 
/home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 23)
 [ecj-lint] import javax.naming.NamingException;
 [ecj-lint]
 [ecj-lint] The type javax.naming.NamingException is not accessible
 [ecj-lint] --
 [ecj-lint] 2. ERROR in 
/home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 28)
 [ecj-lint] public class MockInitialContextFactory implements 
InitialContextFactory {
 [ecj-lint]  ^
 [ecj-lint] The type MockInitialContextFactory must implement the inherited 
abstract method InitialContextFactory.getInitialContext(Hashtable)
 [ecj-lint] --
 [ecj-lint] 3. ERROR in 
/home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 30)
 [ecj-lint] private final javax.naming.Context context;
 [ecj-lint]   
 [ecj-lint] The type javax.naming.Context is not accessible
 [ecj-lint] --
 [ecj-lint] 4. ERROR in 
/home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 33)
 [ecj-lint] context = mock(javax.naming.Context.class);
 [ecj-lint] ^^^
 [ecj-lint] context cannot be resolved to a variable
 [ecj-lint] --
 [ecj-lint] 5. ERROR in 
/home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 33)
 [ecj-lint] context = mock(javax.naming.Context.class);
 [ecj-lint]
 [ecj-lint] The type javax.naming.Context is not accessible
 [ecj-lint] --
 [ecj-lint] 6. ERROR in 
/home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 36)
 [ecj-lint] when(context.lookup(anyString())).thenAnswer(invocation -> 
objects.get(invocation.getArgument(0)));
 [ecj-lint]  ^^^
 [ecj-lint] context cannot be resolved
 [ecj-lint] --
 [ecj-lint] 7. ERROR in 
/home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 38)
 [ecj-lint] } catch (NamingException e) {
 [ecj-lint]  ^^^
 [ecj-lint] NamingException cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 8. ERROR in 
/home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 45)
 [ecj-lint] public javax.naming.Context getInitialContext(Hashtable env) {
 [ecj-lint]
 [ecj-lint] The type javax.naming.Context is not accessible
 [ecj-lint] --
 [ecj-lint] 9. ERROR in 
/home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 46)
 [ecj-lint] return context;
 [ecj-lint]^^^
 [ecj-lint] context cannot be resolved to a variable
 [ecj-lint] --
 [ecj-lint] 9 problems (9 errors)

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/build.xml:643: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/build.xml:101: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/solr/build.xml:687: 
The following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/solr/common-build.xml:479:
 The following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/lucene/common-build.xml:2016:
 The following error occurred while 

Re: Welcome Michael Sokolov as Lucene/ Solr committer

[Koji Sekiguchi]

Congratulations and welcome, Michael!

Koji

On 2019/05/14 4:11, Dawid Weiss wrote:

Hello everyone,

Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!

Many of you probably know Mike as he's been around for quite a while
-- answering questions, reviewing patches, providing insight and
actively working on new code.

Congratulations and welcome! It is a tradition to introduce yourself
with a brief bio, Mike.

Dawid

-
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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.client.solrj.io.stream.MathExpressionTest.testGammaDistribution

Error Message:
0.860369347327234 0.8719520073317888

Stack Trace:
java.lang.AssertionError: 0.860369347327234 0.8719520073317888
at 
__randomizedtesting.SeedInfo.seed([87B29B28AA821C6F:BAC8B08689FAB678]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.solr.client.solrj.io.stream.MathExpressionTest.testGammaDistribution(MathExpressionTest.java:4590)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 16749 lines...]
   [junit4] Suite: org.apache.solr.client.solrj.io.stream.MathExpressionTest
   [junit4]   2> 240666 INFO  
(SUITE-MathExpressionTest-seed#[87B29B28AA821C6F]-worker) [] 
o.a.s.SolrTestCaseJ4 SecureRandom 

SOLR-13437 Forking noggit

[Mike Drob]

Hey Lucene/Solr PMC,

Regarding the proposed fork in SOLR-13437, has anybody checked if the original 
maintainer wants to keep noggit in his own namespace? I realize Yonik is part 
of the PMC here, so he can definitely speak for himself if he wants. Explicitly 
asking him in a public venue goes a long way to maintaining the ASF reputation 
of friendliness to smaller open source communities and projects.

Thanks,
Mike

P.S. I am not subscribed to this list despite being an ASF Member, so please 
explicitly cc me on replies if you want me to see the responses.


-
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 # 98 - Failure

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 23881 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 2531 links (2070 relative) to 3358 anchors in 253 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 :: 

[jira] [Updated] (SOLR-13467) Spatial: Add S2 lib for more efficient Geo3D indexes

[David Smiley (JIRA)]

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

David Smiley updated SOLR-13467:

Description: 
Here I'm adding a dependency on [Google S2 Geometry|http://s2geometry.io] 
(121KB) so that we can use {{prefixTree="s2"}} on a spatial field type that is 
using Geo3D.  Lucene spatial-extras already has this dependency, albeit it is 
optional.  I enhanced tests to exercise it.
Additionally, I document here a strictness Geo3D has in which the polygon 
points must be provided in a particular order or else the interpretation of the 
shape is inverted.  This so-called "right hand rule" order is somewhat standard 
but some libs (like JTS) don't care.

  was:There's a limitation/gotcha on Geo3D in which the polygon points must be 
provided in a particular order or else the interpretation of the same is 
inverted.  In addition, lets add a reference to {{prefixTree="s2"}} and 
possibly a test for the same.

Component/s: spatial
Summary: Spatial: Add S2 lib for more efficient Geo3D indexes  (was: 
Ref guide: spatial: document Geo3D better)

Originally this was just going to be about documenting the point order in the 
ref guide but then I added a test, then added S2, then realized -- oh yeah, S2 
isn't in Solr, so scope creep.

It'd be nice to have S2 be the default when Geo3D is used, but that's best done 
in Lucene and thus a separate issue.  This would require knowledge of the 
Version since it affects the index.  Any way I don't have time for that now.

> Spatial: Add S2 lib for more efficient Geo3D indexes
> 
>
> Key: SOLR-13467
> URL: https://issues.apache.org/jira/browse/SOLR-13467
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation, spatial
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
>
> Here I'm adding a dependency on [Google S2 Geometry|http://s2geometry.io] 
> (121KB) so that we can use {{prefixTree="s2"}} on a spatial field type that 
> is using Geo3D.  Lucene spatial-extras already has this dependency, albeit it 
> is optional.  I enhanced tests to exercise it.
> Additionally, I document here a strictness Geo3D has in which the polygon 
> points must be provided in a particular order or else the interpretation of 
> the shape is inverted.  This so-called "right hand rule" order is somewhat 
> standard but some libs (like JTS) don't care.



--
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] madrob commented on a change in pull request #666: SOLR-13437: fork noggit code into Solr

[GitBox]

madrob commented on a change in pull request #666: SOLR-13437: fork noggit code 
into Solr
URL: https://github.com/apache/lucene-solr/pull/666#discussion_r283607834
 
 

 ##
 File path: solr/solrj/src/java/org/apache/solr/common/json/ObjectBuilder.java
 ##
 @@ -0,0 +1,166 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
 
 Review comment:
   This file was originally with a header "copyright Yonik - 2006" I don't 
think we can remove that, and might have to also carry forward a line in a 
NOTICE.txt to meet the ASLv2 requirements.


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

Re: Welcome Michael Sokolov as Lucene/ Solr committer

[Furkan KAMACI]

Congrats Michael!

14 May 2019 Sal, saat 05:37 tarihinde Robert Muir  şunu
yazdı:

> Welcome!
>
> On Mon, May 13, 2019 at 3:12 PM Dawid Weiss  wrote:
> >
> > Hello everyone,
> >
> > Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!
> >
> > Many of you probably know Mike as he's been around for quite a while
> > -- answering questions, reviewing patches, providing insight and
> > actively working on new code.
> >
> > Congratulations and welcome! It is a tradition to introduce yourself
> > with a brief bio, Mike.
> >
> > Dawid
> >
> > -
> > 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: Welcome Michael Sokolov as Lucene/ Solr committer

[Robert Muir]

Welcome!

On Mon, May 13, 2019 at 3:12 PM Dawid Weiss  wrote:
>
> Hello everyone,
>
> Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!
>
> Many of you probably know Mike as he's been around for quite a while
> -- answering questions, reviewing patches, providing insight and
> actively working on new code.
>
> Congratulations and welcome! It is a tradition to introduce yourself
> with a brief bio, Mike.
>
> Dawid
>
> -
> 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: Welcome Michael Sokolov as Lucene/ Solr committer

[Michael Sokolov]

Thanks, Joel

On Mon, May 13, 2019 at 5:07 PM Joel Bernstein  wrote:
>
> Welcome Michael!
>
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
>
> On Mon, May 13, 2019 at 5:04 PM Karl Wright  wrote:
>>
>> Welcome, Michael!
>> Karl
>>
>>
>> On Mon, May 13, 2019 at 4:52 PM Martin Gainty  wrote:
>>>
>>> Удачи Майкл!
>>>
>>>
>>> 
>>> From: Erick Erickson 
>>> Sent: Monday, May 13, 2019 4:11 PM
>>> To: dev@lucene.apache.org
>>> Subject: Re: Welcome Michael Sokolov as Lucene/ Solr committer
>>>
>>> Welcome Michael!
>>>
>>> > On May 13, 2019, at 2:48 PM, Dawid Weiss  wrote:
>>> >
>>> >> I am pretty sure my first interaction with the Apache Solr/Lucene 
>>> >> community was back in 2012,
>>> >
>>> > Yeah... I really don't know how it happened you haven't been
>>> > invited earlier. Everyone just kind of assumed you
>>> > have committer rights already! :)
>>> >
>>> >
>>> > D.
>>> >
>>> > On Mon, May 13, 2019 at 9:23 PM Michael Sokolov  
>>> > wrote:
>>> >>
>>> >> Thanks Dawid, and thank you to everyone who voted to grant me access
>>> >> to this awesome project!
>>> >>
>>> >> I spent many years building full text search web applications serving
>>> >> large texts (especially dictionaries, encyclopedias, and academic
>>> >> journals). I cut my teeth with AltaVista back in 1998, and tried many
>>> >> other search engines before finally coming around to Solr/Lucene.
>>> >>
>>> >> I am pretty sure my first interaction with the Apache Solr/Lucene
>>> >> community was back in 2012, when I was looking to solve a performance
>>> >> problem we encountered highlighting gigantic documents. Since then
>>> >> I've worked on many projects involving Solr and Lucene, and
>>> >> ElasticSearch, and made various contributions, implemented some of my
>>> >> own extensions, made a separate XML query engine based on Solr (Lux -
>>> >> no longer active), went to a few Lucene/Solr Revolutions (spoke at
>>> >> one), and always in the back of my mind was the idea of contributing
>>> >> more actively and becoming a full participant in this thriving open
>>> >> source project. Now I'm really excited that has come to pass, and look
>>> >> forward to digging in even deeper, and helping to keep this thing
>>> >> going.
>>> >>
>>> >> -Mike
>>> >>
>>> >> On Mon, May 13, 2019 at 3:12 PM Dawid Weiss  
>>> >> wrote:
>>> >>>
>>> >>> Hello everyone,
>>> >>>
>>> >>> Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!
>>> >>>
>>> >>> Many of you probably know Mike as he's been around for quite a while
>>> >>> -- answering questions, reviewing patches, providing insight and
>>> >>> actively working on new code.
>>> >>>
>>> >>> Congratulations and welcome! It is a tradition to introduce yourself
>>> >>> with a brief bio, Mike.
>>> >>>
>>> >>> Dawid
>>> >
>>> > -
>>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>>> >
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>

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

Re: Welcome Michael Sokolov as Lucene/ Solr committer

[Michael Sokolov]

Thanks, Đạt !

On Mon, May 13, 2019 at 5:14 PM Đạt Cao Mạnh  wrote:
>
> Welcome Michael!
>
> On Mon, 13 May 2019 at 22:10, David Smiley  wrote:
>>
>> Congratulations and welcome Mike!  Well deserved.
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Mon, May 13, 2019 at 3:12 PM Dawid Weiss  wrote:
>>>
>>> Hello everyone,
>>>
>>> Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!
>>>
>>> Many of you probably know Mike as he's been around for quite a while
>>> -- answering questions, reviewing patches, providing insight and
>>> actively working on new code.
>>>
>>> Congratulations and welcome! It is a tradition to introduce yourself
>>> with a brief bio, Mike.
>>>
>>> Dawid
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
> --
> Best regards,
> Cao Mạnh Đạt
> D.O.B : 31-07-1991
> Cell: (+84) 946.328.329
> E-mail: caomanhdat...@gmail.com

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

Re: Welcome Michael Sokolov as Lucene/ Solr committer

[Michael Sokolov]

Thanks, Tomás

On Mon, May 13, 2019 at 5:57 PM Tomás Fernández Löbbe
 wrote:
>
> Welcome Michael!
>
> On Mon, May 13, 2019 at 2:21 PM Yonik Seeley  wrote:
>>
>> Congrats Mike!
>> -Yonik
>>
>>
>> On Mon, May 13, 2019 at 3:23 PM Michael Sokolov  wrote:
>>>
>>> Thanks Dawid, and thank you to everyone who voted to grant me access
>>> to this awesome project!
>>>
>>> I spent many years building full text search web applications serving
>>> large texts (especially dictionaries, encyclopedias, and academic
>>> journals). I cut my teeth with AltaVista back in 1998, and tried many
>>> other search engines before finally coming around to Solr/Lucene.
>>>
>>> I am pretty sure my first interaction with the Apache Solr/Lucene
>>> community was back in 2012, when I was looking to solve a performance
>>> problem we encountered highlighting gigantic documents. Since then
>>> I've worked on many projects involving Solr and Lucene, and
>>> ElasticSearch, and made various contributions, implemented some of my
>>> own extensions, made a separate XML query engine based on Solr (Lux -
>>> no longer active), went to a few Lucene/Solr Revolutions (spoke at
>>> one), and always in the back of my mind was the idea of contributing
>>> more actively and becoming a full participant in this thriving open
>>> source project. Now I'm really excited that has come to pass, and look
>>> forward to digging in even deeper, and helping to keep this thing
>>> going.
>>>
>>> -Mike
>>>
>>> On Mon, May 13, 2019 at 3:12 PM Dawid Weiss  wrote:
>>> >
>>> > Hello everyone,
>>> >
>>> > Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!
>>> >
>>> > Many of you probably know Mike as he's been around for quite a while
>>> > -- answering questions, reviewing patches, providing insight and
>>> > actively working on new code.
>>> >
>>> > Congratulations and welcome! It is a tradition to introduce yourself
>>> > with a brief bio, Mike.
>>> >
>>> > Dawid
>>>
>>> -
>>> 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: Welcome Michael Sokolov as Lucene/ Solr committer

[Michael Sokolov]

Thanks, Yonik!

On Mon, May 13, 2019 at 5:21 PM Yonik Seeley  wrote:
>
> Congrats Mike!
> -Yonik
>
>
> On Mon, May 13, 2019 at 3:23 PM Michael Sokolov  wrote:
>>
>> Thanks Dawid, and thank you to everyone who voted to grant me access
>> to this awesome project!
>>
>> I spent many years building full text search web applications serving
>> large texts (especially dictionaries, encyclopedias, and academic
>> journals). I cut my teeth with AltaVista back in 1998, and tried many
>> other search engines before finally coming around to Solr/Lucene.
>>
>> I am pretty sure my first interaction with the Apache Solr/Lucene
>> community was back in 2012, when I was looking to solve a performance
>> problem we encountered highlighting gigantic documents. Since then
>> I've worked on many projects involving Solr and Lucene, and
>> ElasticSearch, and made various contributions, implemented some of my
>> own extensions, made a separate XML query engine based on Solr (Lux -
>> no longer active), went to a few Lucene/Solr Revolutions (spoke at
>> one), and always in the back of my mind was the idea of contributing
>> more actively and becoming a full participant in this thriving open
>> source project. Now I'm really excited that has come to pass, and look
>> forward to digging in even deeper, and helping to keep this thing
>> going.
>>
>> -Mike
>>
>> On Mon, May 13, 2019 at 3:12 PM Dawid Weiss  wrote:
>> >
>> > Hello everyone,
>> >
>> > Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!
>> >
>> > Many of you probably know Mike as he's been around for quite a while
>> > -- answering questions, reviewing patches, providing insight and
>> > actively working on new code.
>> >
>> > Congratulations and welcome! It is a tradition to introduce yourself
>> > with a brief bio, Mike.
>> >
>> > Dawid
>>
>> -
>> 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: Welcome Michael Sokolov as Lucene/ Solr committer

[Michael Sokolov]

Thanks, David - I appreciate that

On Mon, May 13, 2019 at 5:10 PM David Smiley  wrote:
>
> Congratulations and welcome Mike!  Well deserved.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Mon, May 13, 2019 at 3:12 PM Dawid Weiss  wrote:
>>
>> Hello everyone,
>>
>> Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!
>>
>> Many of you probably know Mike as he's been around for quite a while
>> -- answering questions, reviewing patches, providing insight and
>> actively working on new code.
>>
>> Congratulations and welcome! It is a tradition to introduce yourself
>> with a brief bio, Mike.
>>
>> Dawid
>>
>> -
>> 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

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk-11.0.2) - Build # 5144 - Still unstable!

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation.testForwarding

Error Message:
Error from server at http://127.0.0.1:56297/solr/forwardingCollection: Expected 
mime type application/octet-stream but got text/html.Error 401 
Authentication required  HTTP ERROR 401 
Problem accessing /solr/forwardingCollection/select. Reason: 
Authentication requiredhttp://eclipse.org/jetty;>Powered 
by Jetty:// 9.4.14.v20181114

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:56297/solr/forwardingCollection: Expected mime 
type application/octet-stream but got text/html. 


Error 401 Authentication required

HTTP ERROR 401
Problem accessing /solr/forwardingCollection/select. Reason:
Authentication requiredhttp://eclipse.org/jetty;>Powered by Jetty:// 9.4.14.v20181114




at 
__randomizedtesting.SeedInfo.seed([48D26D56C0BD8968:A95404A8DD8B6F81]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:613)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:987)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:1002)
at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation.testForwarding(TestSolrCloudWithSecureImpersonation.java:328)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

Re: Welcome Michael Sokolov as Lucene/ Solr committer

[Michael Sokolov]

Thanks, Karl!

On Mon, May 13, 2019 at 5:04 PM Karl Wright  wrote:
>
> Welcome, Michael!
> Karl
>
>
> On Mon, May 13, 2019 at 4:52 PM Martin Gainty  wrote:
>>
>> Удачи Майкл!
>>
>>
>> 
>> From: Erick Erickson 
>> Sent: Monday, May 13, 2019 4:11 PM
>> To: dev@lucene.apache.org
>> Subject: Re: Welcome Michael Sokolov as Lucene/ Solr committer
>>
>> Welcome Michael!
>>
>> > On May 13, 2019, at 2:48 PM, Dawid Weiss  wrote:
>> >
>> >> I am pretty sure my first interaction with the Apache Solr/Lucene 
>> >> community was back in 2012,
>> >
>> > Yeah... I really don't know how it happened you haven't been
>> > invited earlier. Everyone just kind of assumed you
>> > have committer rights already! :)
>> >
>> >
>> > D.
>> >
>> > On Mon, May 13, 2019 at 9:23 PM Michael Sokolov  wrote:
>> >>
>> >> Thanks Dawid, and thank you to everyone who voted to grant me access
>> >> to this awesome project!
>> >>
>> >> I spent many years building full text search web applications serving
>> >> large texts (especially dictionaries, encyclopedias, and academic
>> >> journals). I cut my teeth with AltaVista back in 1998, and tried many
>> >> other search engines before finally coming around to Solr/Lucene.
>> >>
>> >> I am pretty sure my first interaction with the Apache Solr/Lucene
>> >> community was back in 2012, when I was looking to solve a performance
>> >> problem we encountered highlighting gigantic documents. Since then
>> >> I've worked on many projects involving Solr and Lucene, and
>> >> ElasticSearch, and made various contributions, implemented some of my
>> >> own extensions, made a separate XML query engine based on Solr (Lux -
>> >> no longer active), went to a few Lucene/Solr Revolutions (spoke at
>> >> one), and always in the back of my mind was the idea of contributing
>> >> more actively and becoming a full participant in this thriving open
>> >> source project. Now I'm really excited that has come to pass, and look
>> >> forward to digging in even deeper, and helping to keep this thing
>> >> going.
>> >>
>> >> -Mike
>> >>
>> >> On Mon, May 13, 2019 at 3:12 PM Dawid Weiss  wrote:
>> >>>
>> >>> Hello everyone,
>> >>>
>> >>> Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!
>> >>>
>> >>> Many of you probably know Mike as he's been around for quite a while
>> >>> -- answering questions, reviewing patches, providing insight and
>> >>> actively working on new code.
>> >>>
>> >>> Congratulations and welcome! It is a tradition to introduce yourself
>> >>> with a brief bio, Mike.
>> >>>
>> >>> Dawid
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>> >
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>

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

Re: Welcome Michael Sokolov as Lucene/ Solr committer

[Michael Sokolov]

Alas, I had to resort to Google Translate; Thank you!

On Mon, May 13, 2019 at 4:52 PM Martin Gainty  wrote:
>
> Удачи Майкл!
>
>
> 
> From: Erick Erickson 
> Sent: Monday, May 13, 2019 4:11 PM
> To: dev@lucene.apache.org
> Subject: Re: Welcome Michael Sokolov as Lucene/ Solr committer
>
> Welcome Michael!
>
> > On May 13, 2019, at 2:48 PM, Dawid Weiss  wrote:
> >
> >> I am pretty sure my first interaction with the Apache Solr/Lucene 
> >> community was back in 2012,
> >
> > Yeah... I really don't know how it happened you haven't been
> > invited earlier. Everyone just kind of assumed you
> > have committer rights already! :)
> >
> >
> > D.
> >
> > On Mon, May 13, 2019 at 9:23 PM Michael Sokolov  wrote:
> >>
> >> Thanks Dawid, and thank you to everyone who voted to grant me access
> >> to this awesome project!
> >>
> >> I spent many years building full text search web applications serving
> >> large texts (especially dictionaries, encyclopedias, and academic
> >> journals). I cut my teeth with AltaVista back in 1998, and tried many
> >> other search engines before finally coming around to Solr/Lucene.
> >>
> >> I am pretty sure my first interaction with the Apache Solr/Lucene
> >> community was back in 2012, when I was looking to solve a performance
> >> problem we encountered highlighting gigantic documents. Since then
> >> I've worked on many projects involving Solr and Lucene, and
> >> ElasticSearch, and made various contributions, implemented some of my
> >> own extensions, made a separate XML query engine based on Solr (Lux -
> >> no longer active), went to a few Lucene/Solr Revolutions (spoke at
> >> one), and always in the back of my mind was the idea of contributing
> >> more actively and becoming a full participant in this thriving open
> >> source project. Now I'm really excited that has come to pass, and look
> >> forward to digging in even deeper, and helping to keep this thing
> >> going.
> >>
> >> -Mike
> >>
> >> On Mon, May 13, 2019 at 3:12 PM Dawid Weiss  wrote:
> >>>
> >>> Hello everyone,
> >>>
> >>> Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!
> >>>
> >>> Many of you probably know Mike as he's been around for quite a while
> >>> -- answering questions, reviewing patches, providing insight and
> >>> actively working on new code.
> >>>
> >>> Congratulations and welcome! It is a tradition to introduce yourself
> >>> with a brief bio, Mike.
> >>>
> >>> Dawid
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

Re: Welcome Michael Sokolov as Lucene/ Solr committer

[Michael Sokolov]

Thank you!

On Mon, May 13, 2019 at 4:26 PM Ignacio Vera  wrote:
>
> Welcome!
>
> On Mon, May 13, 2019 at 4:11 PM Erick Erickson  
> wrote:
>>
>> Welcome Michael!
>>
>> > On May 13, 2019, at 2:48 PM, Dawid Weiss  wrote:
>> >
>> >> I am pretty sure my first interaction with the Apache Solr/Lucene 
>> >> community was back in 2012,
>> >
>> > Yeah... I really don't know how it happened you haven't been
>> > invited earlier. Everyone just kind of assumed you
>> > have committer rights already! :)
>> >
>> >
>> > D.
>> >
>> > On Mon, May 13, 2019 at 9:23 PM Michael Sokolov  wrote:
>> >>
>> >> Thanks Dawid, and thank you to everyone who voted to grant me access
>> >> to this awesome project!
>> >>
>> >> I spent many years building full text search web applications serving
>> >> large texts (especially dictionaries, encyclopedias, and academic
>> >> journals). I cut my teeth with AltaVista back in 1998, and tried many
>> >> other search engines before finally coming around to Solr/Lucene.
>> >>
>> >> I am pretty sure my first interaction with the Apache Solr/Lucene
>> >> community was back in 2012, when I was looking to solve a performance
>> >> problem we encountered highlighting gigantic documents. Since then
>> >> I've worked on many projects involving Solr and Lucene, and
>> >> ElasticSearch, and made various contributions, implemented some of my
>> >> own extensions, made a separate XML query engine based on Solr (Lux -
>> >> no longer active), went to a few Lucene/Solr Revolutions (spoke at
>> >> one), and always in the back of my mind was the idea of contributing
>> >> more actively and becoming a full participant in this thriving open
>> >> source project. Now I'm really excited that has come to pass, and look
>> >> forward to digging in even deeper, and helping to keep this thing
>> >> going.
>> >>
>> >> -Mike
>> >>
>> >> On Mon, May 13, 2019 at 3:12 PM Dawid Weiss  wrote:
>> >>>
>> >>> Hello everyone,
>> >>>
>> >>> Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!
>> >>>
>> >>> Many of you probably know Mike as he's been around for quite a while
>> >>> -- answering questions, reviewing patches, providing insight and
>> >>> actively working on new code.
>> >>>
>> >>> Congratulations and welcome! It is a tradition to introduce yourself
>> >>> with a brief bio, Mike.
>> >>>
>> >>> Dawid
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>> >
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>

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

Re: Welcome Michael Sokolov as Lucene/ Solr committer

[Michael Sokolov]

Ha! Thanks, Erik

On Mon, May 13, 2019 at 3:28 PM Erik Hatcher  wrote:
>
> Welcome, Michael!  It’s about time :)
>
> > On May 13, 2019, at 15:11, Dawid Weiss  wrote:
> >
> > Hello everyone,
> >
> > Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!
> >
> > Many of you probably know Mike as he's been around for quite a while
> > -- answering questions, reviewing patches, providing insight and
> > actively working on new code.
> >
> > Congratulations and welcome! It is a tradition to introduce yourself
> > with a brief bio, Mike.
> >
> > Dawid
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

Re: Welcome Michael Sokolov as Lucene/ Solr committer

[Christian Moen]

Congratulations, Michael!

On Tue, May 14, 2019 at 4:23 AM Michael Sokolov  wrote:

> Thanks Dawid, and thank you to everyone who voted to grant me access
> to this awesome project!
>
> I spent many years building full text search web applications serving
> large texts (especially dictionaries, encyclopedias, and academic
> journals). I cut my teeth with AltaVista back in 1998, and tried many
> other search engines before finally coming around to Solr/Lucene.
>
> I am pretty sure my first interaction with the Apache Solr/Lucene
> community was back in 2012, when I was looking to solve a performance
> problem we encountered highlighting gigantic documents. Since then
> I've worked on many projects involving Solr and Lucene, and
> ElasticSearch, and made various contributions, implemented some of my
> own extensions, made a separate XML query engine based on Solr (Lux -
> no longer active), went to a few Lucene/Solr Revolutions (spoke at
> one), and always in the back of my mind was the idea of contributing
> more actively and becoming a full participant in this thriving open
> source project. Now I'm really excited that has come to pass, and look
> forward to digging in even deeper, and helping to keep this thing
> going.
>
> -Mike
>
> On Mon, May 13, 2019 at 3:12 PM Dawid Weiss  wrote:
> >
> > Hello everyone,
> >
> > Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!
> >
> > Many of you probably know Mike as he's been around for quite a while
> > -- answering questions, reviewing patches, providing insight and
> > actively working on new code.
> >
> > Congratulations and welcome! It is a tradition to introduce yourself
> > with a brief bio, Mike.
> >
> > Dawid
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Welcome Michael Sokolov as Lucene/ Solr committer

[Michael Sokolov]

Thanks, Ishan!

On Mon, May 13, 2019 at 3:26 PM Ishan Chattopadhyaya
 wrote:
>
> Congratulations and welcome, Michael!
>
> On Tue, May 14, 2019 at 12:53 AM Michael Sokolov  wrote:
> >
> > Thanks Dawid, and thank you to everyone who voted to grant me access
> > to this awesome project!
> >
> > I spent many years building full text search web applications serving
> > large texts (especially dictionaries, encyclopedias, and academic
> > journals). I cut my teeth with AltaVista back in 1998, and tried many
> > other search engines before finally coming around to Solr/Lucene.
> >
> > I am pretty sure my first interaction with the Apache Solr/Lucene
> > community was back in 2012, when I was looking to solve a performance
> > problem we encountered highlighting gigantic documents. Since then
> > I've worked on many projects involving Solr and Lucene, and
> > ElasticSearch, and made various contributions, implemented some of my
> > own extensions, made a separate XML query engine based on Solr (Lux -
> > no longer active), went to a few Lucene/Solr Revolutions (spoke at
> > one), and always in the back of my mind was the idea of contributing
> > more actively and becoming a full participant in this thriving open
> > source project. Now I'm really excited that has come to pass, and look
> > forward to digging in even deeper, and helping to keep this thing
> > going.
> >
> > -Mike
> >
> > On Mon, May 13, 2019 at 3:12 PM Dawid Weiss  wrote:
> > >
> > > Hello everyone,
> > >
> > > Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!
> > >
> > > Many of you probably know Mike as he's been around for quite a while
> > > -- answering questions, reviewing patches, providing insight and
> > > actively working on new code.
> > >
> > > Congratulations and welcome! It is a tradition to introduce yourself
> > > with a brief bio, Mike.
> > >
> > > Dawid
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

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

[Policeman Jenkins Server]

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

3 tests failed.
FAILED:  org.apache.solr.cloud.ReindexCollectionTest.testFailure

Error Message:


Stack Trace:
java.lang.NullPointerException
at 
__randomizedtesting.SeedInfo.seed([1A85DB5396C5A037:723828BFACF5C298]:0)
at 
org.apache.solr.cloud.ReindexCollectionTest.lambda$testFailure$9(ReindexCollectionTest.java:318)
at 
org.apache.solr.common.cloud.ClusterState.lambda$forEachCollection$0(ClusterState.java:359)
at java.base/java.util.LinkedHashMap.forEach(LinkedHashMap.java:684)
at 
org.apache.solr.common.cloud.ClusterState.forEachCollection(ClusterState.java:357)
at 
org.apache.solr.cloud.ReindexCollectionTest.testFailure(ReindexCollectionTest.java:317)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:830)


FAILED:  org.apache.solr.metrics.rrd.SolrRrdBackendFactoryTest.testBasic

Error 

[JENKINS] Lucene-Solr-SmokeRelease-8.1 - Build # 32 - Still Failing

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 23881 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 2531 links (2070 relative) to 3358 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.0.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 :: 

Re: Welcome Michael Sokolov as Lucene/ Solr committer

[Anshum Gupta]

Congratulations and welcome, Michael!

On Mon, May 13, 2019 at 12:12 PM Dawid Weiss  wrote:

> Hello everyone,
>
> Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!
>
> Many of you probably know Mike as he's been around for quite a while
> -- answering questions, reviewing patches, providing insight and
> actively working on new code.
>
> Congratulations and welcome! It is a tradition to introduce yourself
> with a brief bio, Mike.
>
> Dawid
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
Anshum Gupta

Re: Welcome Michael Sokolov as Lucene/ Solr committer

[Tomoko Uchida]

Welcome, Michael!

Tomoko

2019年5月14日(火) 6:57 Tomás Fernández Löbbe :
>
> Welcome Michael!
>
> On Mon, May 13, 2019 at 2:21 PM Yonik Seeley  wrote:
>>
>> Congrats Mike!
>> -Yonik
>>
>>
>> On Mon, May 13, 2019 at 3:23 PM Michael Sokolov  wrote:
>>>
>>> Thanks Dawid, and thank you to everyone who voted to grant me access
>>> to this awesome project!
>>>
>>> I spent many years building full text search web applications serving
>>> large texts (especially dictionaries, encyclopedias, and academic
>>> journals). I cut my teeth with AltaVista back in 1998, and tried many
>>> other search engines before finally coming around to Solr/Lucene.
>>>
>>> I am pretty sure my first interaction with the Apache Solr/Lucene
>>> community was back in 2012, when I was looking to solve a performance
>>> problem we encountered highlighting gigantic documents. Since then
>>> I've worked on many projects involving Solr and Lucene, and
>>> ElasticSearch, and made various contributions, implemented some of my
>>> own extensions, made a separate XML query engine based on Solr (Lux -
>>> no longer active), went to a few Lucene/Solr Revolutions (spoke at
>>> one), and always in the back of my mind was the idea of contributing
>>> more actively and becoming a full participant in this thriving open
>>> source project. Now I'm really excited that has come to pass, and look
>>> forward to digging in even deeper, and helping to keep this thing
>>> going.
>>>
>>> -Mike
>>>
>>> On Mon, May 13, 2019 at 3:12 PM Dawid Weiss  wrote:
>>> >
>>> > Hello everyone,
>>> >
>>> > Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!
>>> >
>>> > Many of you probably know Mike as he's been around for quite a while
>>> > -- answering questions, reviewing patches, providing insight and
>>> > actively working on new code.
>>> >
>>> > Congratulations and welcome! It is a tradition to introduce yourself
>>> > with a brief bio, Mike.
>>> >
>>> > Dawid
>>>
>>> -
>>> 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

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

[Apache Jenkins Server]

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

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.hdfs.HdfsChaosMonkeySafeLeaderTest

Error Message:
ObjectTracker found 1 object(s) that were not released!!! [HdfsTransactionLog] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.update.HdfsTransactionLog  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.update.HdfsTransactionLog.(HdfsTransactionLog.java:129)  
at org.apache.solr.update.HdfsTransactionLog.(HdfsTransactionLog.java:76) 
 at org.apache.solr.update.HdfsUpdateLog.ensureLog(HdfsUpdateLog.java:340)  at 
org.apache.solr.update.UpdateLog.deleteByQuery(UpdateLog.java:660)  at 
org.apache.solr.update.DirectUpdateHandler2.deleteByQuery(DirectUpdateHandler2.java:532)
  at 
org.apache.solr.update.processor.RunUpdateProcessor.processDelete(RunUpdateProcessorFactory.java:87)
  at 
org.apache.solr.update.processor.UpdateRequestProcessor.processDelete(UpdateRequestProcessor.java:59)
  at 
org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalDelete(DistributedUpdateProcessor.java:263)
  at 
org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalDeleteByQuery(DistributedUpdateProcessor.java:899)
  at 
org.apache.solr.update.processor.DistributedUpdateProcessor.versionDeleteByQuery(DistributedUpdateProcessor.java:854)
  at 
org.apache.solr.update.processor.DistributedUpdateProcessor.doDeleteByQuery(DistributedUpdateProcessor.java:815)
  at 
org.apache.solr.update.processor.DistributedZkUpdateProcessor.doDeleteByQuery(DistributedZkUpdateProcessor.java:442)
  at 
org.apache.solr.update.processor.DistributedUpdateProcessor.processDelete(DistributedUpdateProcessor.java:718)
  at 
org.apache.solr.update.processor.DistributedZkUpdateProcessor.processDelete(DistributedZkUpdateProcessor.java:297)
  at 
org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processDelete(LogUpdateProcessorFactory.java:124)
  at 
org.apache.solr.handler.loader.JavabinLoader.delete(JavabinLoader.java:210)  at 
org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(JavabinLoader.java:128)
  at org.apache.solr.handler.loader.JavabinLoader.load(JavabinLoader.java:70)  
at 
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:97)
  at 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2566)  at 
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:756)  at 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:542)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:165)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) 
 at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
  at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)  
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:703)  
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) 
 at org.eclipse.jetty.server.Server.handle(Server.java:502)  at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)  at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)  at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)  at 
org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:411)
  at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:305)  
at 

[jira] [Commented] (SOLR-8776) Support RankQuery in grouping

[Diego Ceccarelli (JIRA)]

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

Diego Ceccarelli commented on SOLR-8776:


[~ichattopadhyaya] are you still interested in moving this forward? It is 
really very painful to update it upstream when it gets stale :D 

> Support RankQuery in grouping
> -
>
> Key: SOLR-8776
> URL: https://issues.apache.org/jira/browse/SOLR-8776
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Affects Versions: 6.0
>Reporter: Diego Ceccarelli
>Priority: Minor
> Attachments: 0001-SOLR-8776-Support-RankQuery-in-grouping.patch, 
> 0001-SOLR-8776-Support-RankQuery-in-grouping.patch, 
> 0001-SOLR-8776-Support-RankQuery-in-grouping.patch, 
> 0001-SOLR-8776-Support-RankQuery-in-grouping.patch, 
> 0001-SOLR-8776-Support-RankQuery-in-grouping.patch
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Currently it is not possible to use RankQuery [1] and Grouping [2] together 
> (see also [3]). In some situations Grouping can be replaced by Collapse and 
> Expand Results [4] (that supports reranking), but i) collapse cannot 
> guarantee that at least a minimum number of groups will be returned for a 
> query, and ii) in the Solr Cloud setting you will have constraints on how to 
> partition the documents among the shards.
> I'm going to start working on supporting RankQuery in grouping. I'll start 
> attaching a patch with a test that fails because grouping does not support 
> the rank query and then I'll try to fix the problem, starting from the non 
> distributed setting (GroupingSearch).
> My feeling is that since grouping is mostly performed by Lucene, RankQuery 
> should be refactored and moved (or partially moved) there. 
> Any feedback is welcome.
> [1] https://cwiki.apache.org/confluence/display/solr/RankQuery+API 
> [2] https://cwiki.apache.org/confluence/display/solr/Result+Grouping
> [3] 
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201507.mbox/%3ccahm-lpuvspest-sw63_8a6gt-wor6ds_t_nb2rope93e4+s...@mail.gmail.com%3E
> [4] 
> https://cwiki.apache.org/confluence/display/solr/Collapse+and+Expand+Results



--
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 Michael Sokolov as Lucene/ Solr committer

[Tomás Fernández Löbbe]

Welcome Michael!

On Mon, May 13, 2019 at 2:21 PM Yonik Seeley  wrote:

> Congrats Mike!
> -Yonik
>
>
> On Mon, May 13, 2019 at 3:23 PM Michael Sokolov 
> wrote:
>
>> Thanks Dawid, and thank you to everyone who voted to grant me access
>> to this awesome project!
>>
>> I spent many years building full text search web applications serving
>> large texts (especially dictionaries, encyclopedias, and academic
>> journals). I cut my teeth with AltaVista back in 1998, and tried many
>> other search engines before finally coming around to Solr/Lucene.
>>
>> I am pretty sure my first interaction with the Apache Solr/Lucene
>> community was back in 2012, when I was looking to solve a performance
>> problem we encountered highlighting gigantic documents. Since then
>> I've worked on many projects involving Solr and Lucene, and
>> ElasticSearch, and made various contributions, implemented some of my
>> own extensions, made a separate XML query engine based on Solr (Lux -
>> no longer active), went to a few Lucene/Solr Revolutions (spoke at
>> one), and always in the back of my mind was the idea of contributing
>> more actively and becoming a full participant in this thriving open
>> source project. Now I'm really excited that has come to pass, and look
>> forward to digging in even deeper, and helping to keep this thing
>> going.
>>
>> -Mike
>>
>> On Mon, May 13, 2019 at 3:12 PM Dawid Weiss 
>> wrote:
>> >
>> > Hello everyone,
>> >
>> > Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!
>> >
>> > Many of you probably know Mike as he's been around for quite a while
>> > -- answering questions, reviewing patches, providing insight and
>> > actively working on new code.
>> >
>> > Congratulations and welcome! It is a tradition to introduce yourself
>> > with a brief bio, Mike.
>> >
>> > Dawid
>>
>> -
>> 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 # 100 - Unstable

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.handler.component.TestDistributedStatsComponentCardinality.test

Error Message:
.responseHeader.status:200!=0

Stack Trace:
junit.framework.AssertionFailedError: .responseHeader.status:200!=0
at 
__randomizedtesting.SeedInfo.seed([10B9C8F15AE1699B:98EDF72BF41D0463]:0)
at junit.framework.Assert.fail(Assert.java:57)
at 
org.apache.solr.BaseDistributedSearchTestCase.compareSolrResponses(BaseDistributedSearchTestCase.java:999)
at 
org.apache.solr.BaseDistributedSearchTestCase.compareResponses(BaseDistributedSearchTestCase.java:1026)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:680)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:643)
at 
org.apache.solr.handler.component.TestDistributedStatsComponentCardinality.test(TestDistributedStatsComponentCardinality.java:143)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 

[JENKINS-EA] Lucene-Solr-8.1-Windows (64bit/jdk-13-ea+18) - Build # 105 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.1-Windows/105/
Java: 64bit/jdk-13-ea+18 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.sim.TestSimComputePlanAction.testNodeWithMultipleReplicasLost

Error Message:
OverseerTriggerThread never caught up to the latest znodeVersion

Stack Trace:
java.util.concurrent.TimeoutException: OverseerTriggerThread never caught up to 
the latest znodeVersion
at 
__randomizedtesting.SeedInfo.seed([25238CE346EF10A4:15E36D61CE9DF1F8]:0)
at org.apache.solr.util.TimeOut.waitFor(TimeOut.java:66)
at 
org.apache.solr.cloud.autoscaling.sim.SimSolrCloudTestCase.assertAutoscalingUpdateComplete(SimSolrCloudTestCase.java:89)
at 
org.apache.solr.cloud.autoscaling.sim.TestSimComputePlanAction.testNodeWithMultipleReplicasLost(TestSimComputePlanAction.java:207)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:835)




Build Log:
[...truncated 2106 lines...]
   [junit4] JVM 

Re: Welcome Michael Sokolov as Lucene/ Solr committer

[Yonik Seeley]

Congrats Mike!
-Yonik


On Mon, May 13, 2019 at 3:23 PM Michael Sokolov  wrote:

> Thanks Dawid, and thank you to everyone who voted to grant me access
> to this awesome project!
>
> I spent many years building full text search web applications serving
> large texts (especially dictionaries, encyclopedias, and academic
> journals). I cut my teeth with AltaVista back in 1998, and tried many
> other search engines before finally coming around to Solr/Lucene.
>
> I am pretty sure my first interaction with the Apache Solr/Lucene
> community was back in 2012, when I was looking to solve a performance
> problem we encountered highlighting gigantic documents. Since then
> I've worked on many projects involving Solr and Lucene, and
> ElasticSearch, and made various contributions, implemented some of my
> own extensions, made a separate XML query engine based on Solr (Lux -
> no longer active), went to a few Lucene/Solr Revolutions (spoke at
> one), and always in the back of my mind was the idea of contributing
> more actively and becoming a full participant in this thriving open
> source project. Now I'm really excited that has come to pass, and look
> forward to digging in even deeper, and helping to keep this thing
> going.
>
> -Mike
>
> On Mon, May 13, 2019 at 3:12 PM Dawid Weiss  wrote:
> >
> > Hello everyone,
> >
> > Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!
> >
> > Many of you probably know Mike as he's been around for quite a while
> > -- answering questions, reviewing patches, providing insight and
> > actively working on new code.
> >
> > Congratulations and welcome! It is a tradition to introduce yourself
> > with a brief bio, Mike.
> >
> > Dawid
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Welcome Michael Sokolov as Lucene/ Solr committer

[Đạt Cao Mạnh]

Welcome Michael!

On Mon, 13 May 2019 at 22:10, David Smiley  wrote:

> Congratulations and welcome Mike!  Well deserved.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Mon, May 13, 2019 at 3:12 PM Dawid Weiss  wrote:
>
>> Hello everyone,
>>
>> Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!
>>
>> Many of you probably know Mike as he's been around for quite a while
>> -- answering questions, reviewing patches, providing insight and
>> actively working on new code.
>>
>> Congratulations and welcome! It is a tradition to introduce yourself
>> with a brief bio, Mike.
>>
>> Dawid
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>> --
*Best regards,*
*Cao Mạnh Đạt*


*D.O.B : 31-07-1991Cell: (+84) 946.328.329E-mail: caomanhdat...@gmail.com
*

Re: Welcome Michael Sokolov as Lucene/ Solr committer

[David Smiley]

Congratulations and welcome Mike!  Well deserved.

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


On Mon, May 13, 2019 at 3:12 PM Dawid Weiss  wrote:

> Hello everyone,
>
> Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!
>
> Many of you probably know Mike as he's been around for quite a while
> -- answering questions, reviewing patches, providing insight and
> actively working on new code.
>
> Congratulations and welcome! It is a tradition to introduce yourself
> with a brief bio, Mike.
>
> Dawid
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Welcome Michael Sokolov as Lucene/ Solr committer

[Joel Bernstein]

Welcome Michael!


Joel Bernstein
http://joelsolr.blogspot.com/


On Mon, May 13, 2019 at 5:04 PM Karl Wright  wrote:

> Welcome, Michael!
> Karl
>
>
> On Mon, May 13, 2019 at 4:52 PM Martin Gainty  wrote:
>
>> Удачи Майкл!
>>
>>
>> --
>> *From:* Erick Erickson 
>> *Sent:* Monday, May 13, 2019 4:11 PM
>> *To:* dev@lucene.apache.org
>> *Subject:* Re: Welcome Michael Sokolov as Lucene/ Solr committer
>>
>> Welcome Michael!
>>
>> > On May 13, 2019, at 2:48 PM, Dawid Weiss  wrote:
>> >
>> >> I am pretty sure my first interaction with the Apache Solr/Lucene
>> community was back in 2012,
>> >
>> > Yeah... I really don't know how it happened you haven't been
>> > invited earlier. Everyone just kind of assumed you
>> > have committer rights already! :)
>> >
>> >
>> > D.
>> >
>> > On Mon, May 13, 2019 at 9:23 PM Michael Sokolov 
>> wrote:
>> >>
>> >> Thanks Dawid, and thank you to everyone who voted to grant me access
>> >> to this awesome project!
>> >>
>> >> I spent many years building full text search web applications serving
>> >> large texts (especially dictionaries, encyclopedias, and academic
>> >> journals). I cut my teeth with AltaVista back in 1998, and tried many
>> >> other search engines before finally coming around to Solr/Lucene.
>> >>
>> >> I am pretty sure my first interaction with the Apache Solr/Lucene
>> >> community was back in 2012, when I was looking to solve a performance
>> >> problem we encountered highlighting gigantic documents. Since then
>> >> I've worked on many projects involving Solr and Lucene, and
>> >> ElasticSearch, and made various contributions, implemented some of my
>> >> own extensions, made a separate XML query engine based on Solr (Lux -
>> >> no longer active), went to a few Lucene/Solr Revolutions (spoke at
>> >> one), and always in the back of my mind was the idea of contributing
>> >> more actively and becoming a full participant in this thriving open
>> >> source project. Now I'm really excited that has come to pass, and look
>> >> forward to digging in even deeper, and helping to keep this thing
>> >> going.
>> >>
>> >> -Mike
>> >>
>> >> On Mon, May 13, 2019 at 3:12 PM Dawid Weiss 
>> wrote:
>> >>>
>> >>> Hello everyone,
>> >>>
>> >>> Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!
>> >>>
>> >>> Many of you probably know Mike as he's been around for quite a while
>> >>> -- answering questions, reviewing patches, providing insight and
>> >>> actively working on new code.
>> >>>
>> >>> Congratulations and welcome! It is a tradition to introduce yourself
>> >>> with a brief bio, Mike.
>> >>>
>> >>> Dawid
>> >
>> > -
>> > 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: Welcome Michael Sokolov as Lucene/ Solr committer

[Karl Wright]

Welcome, Michael!
Karl


On Mon, May 13, 2019 at 4:52 PM Martin Gainty  wrote:

> Удачи Майкл!
>
>
> --
> *From:* Erick Erickson 
> *Sent:* Monday, May 13, 2019 4:11 PM
> *To:* dev@lucene.apache.org
> *Subject:* Re: Welcome Michael Sokolov as Lucene/ Solr committer
>
> Welcome Michael!
>
> > On May 13, 2019, at 2:48 PM, Dawid Weiss  wrote:
> >
> >> I am pretty sure my first interaction with the Apache Solr/Lucene
> community was back in 2012,
> >
> > Yeah... I really don't know how it happened you haven't been
> > invited earlier. Everyone just kind of assumed you
> > have committer rights already! :)
> >
> >
> > D.
> >
> > On Mon, May 13, 2019 at 9:23 PM Michael Sokolov 
> wrote:
> >>
> >> Thanks Dawid, and thank you to everyone who voted to grant me access
> >> to this awesome project!
> >>
> >> I spent many years building full text search web applications serving
> >> large texts (especially dictionaries, encyclopedias, and academic
> >> journals). I cut my teeth with AltaVista back in 1998, and tried many
> >> other search engines before finally coming around to Solr/Lucene.
> >>
> >> I am pretty sure my first interaction with the Apache Solr/Lucene
> >> community was back in 2012, when I was looking to solve a performance
> >> problem we encountered highlighting gigantic documents. Since then
> >> I've worked on many projects involving Solr and Lucene, and
> >> ElasticSearch, and made various contributions, implemented some of my
> >> own extensions, made a separate XML query engine based on Solr (Lux -
> >> no longer active), went to a few Lucene/Solr Revolutions (spoke at
> >> one), and always in the back of my mind was the idea of contributing
> >> more actively and becoming a full participant in this thriving open
> >> source project. Now I'm really excited that has come to pass, and look
> >> forward to digging in even deeper, and helping to keep this thing
> >> going.
> >>
> >> -Mike
> >>
> >> On Mon, May 13, 2019 at 3:12 PM Dawid Weiss 
> wrote:
> >>>
> >>> Hello everyone,
> >>>
> >>> Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!
> >>>
> >>> Many of you probably know Mike as he's been around for quite a while
> >>> -- answering questions, reviewing patches, providing insight and
> >>> actively working on new code.
> >>>
> >>> Congratulations and welcome! It is a tradition to introduce yourself
> >>> with a brief bio, Mike.
> >>>
> >>> Dawid
> >
> > -
> > 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: Welcome Michael Sokolov as Lucene/ Solr committer

[Martin Gainty]

Удачи Майкл!


From: Erick Erickson 
Sent: Monday, May 13, 2019 4:11 PM
To: dev@lucene.apache.org
Subject: Re: Welcome Michael Sokolov as Lucene/ Solr committer

Welcome Michael!

> On May 13, 2019, at 2:48 PM, Dawid Weiss  wrote:
>
>> I am pretty sure my first interaction with the Apache Solr/Lucene community 
>> was back in 2012,
>
> Yeah... I really don't know how it happened you haven't been
> invited earlier. Everyone just kind of assumed you
> have committer rights already! :)
>
>
> D.
>
> On Mon, May 13, 2019 at 9:23 PM Michael Sokolov  wrote:
>>
>> Thanks Dawid, and thank you to everyone who voted to grant me access
>> to this awesome project!
>>
>> I spent many years building full text search web applications serving
>> large texts (especially dictionaries, encyclopedias, and academic
>> journals). I cut my teeth with AltaVista back in 1998, and tried many
>> other search engines before finally coming around to Solr/Lucene.
>>
>> I am pretty sure my first interaction with the Apache Solr/Lucene
>> community was back in 2012, when I was looking to solve a performance
>> problem we encountered highlighting gigantic documents. Since then
>> I've worked on many projects involving Solr and Lucene, and
>> ElasticSearch, and made various contributions, implemented some of my
>> own extensions, made a separate XML query engine based on Solr (Lux -
>> no longer active), went to a few Lucene/Solr Revolutions (spoke at
>> one), and always in the back of my mind was the idea of contributing
>> more actively and becoming a full participant in this thriving open
>> source project. Now I'm really excited that has come to pass, and look
>> forward to digging in even deeper, and helping to keep this thing
>> going.
>>
>> -Mike
>>
>> On Mon, May 13, 2019 at 3:12 PM Dawid Weiss  wrote:
>>>
>>> Hello everyone,
>>>
>>> Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!
>>>
>>> Many of you probably know Mike as he's been around for quite a while
>>> -- answering questions, reviewing patches, providing insight and
>>> actively working on new code.
>>>
>>> Congratulations and welcome! It is a tradition to introduce yourself
>>> with a brief bio, Mike.
>>>
>>> Dawid
>
> -
> 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: Welcome Michael Sokolov as Lucene/ Solr committer

[Ignacio Vera]

Welcome!

On Mon, May 13, 2019 at 4:11 PM Erick Erickson 
wrote:

> Welcome Michael!
>
> > On May 13, 2019, at 2:48 PM, Dawid Weiss  wrote:
> >
> >> I am pretty sure my first interaction with the Apache Solr/Lucene
> community was back in 2012,
> >
> > Yeah... I really don't know how it happened you haven't been
> > invited earlier. Everyone just kind of assumed you
> > have committer rights already! :)
> >
> >
> > D.
> >
> > On Mon, May 13, 2019 at 9:23 PM Michael Sokolov 
> wrote:
> >>
> >> Thanks Dawid, and thank you to everyone who voted to grant me access
> >> to this awesome project!
> >>
> >> I spent many years building full text search web applications serving
> >> large texts (especially dictionaries, encyclopedias, and academic
> >> journals). I cut my teeth with AltaVista back in 1998, and tried many
> >> other search engines before finally coming around to Solr/Lucene.
> >>
> >> I am pretty sure my first interaction with the Apache Solr/Lucene
> >> community was back in 2012, when I was looking to solve a performance
> >> problem we encountered highlighting gigantic documents. Since then
> >> I've worked on many projects involving Solr and Lucene, and
> >> ElasticSearch, and made various contributions, implemented some of my
> >> own extensions, made a separate XML query engine based on Solr (Lux -
> >> no longer active), went to a few Lucene/Solr Revolutions (spoke at
> >> one), and always in the back of my mind was the idea of contributing
> >> more actively and becoming a full participant in this thriving open
> >> source project. Now I'm really excited that has come to pass, and look
> >> forward to digging in even deeper, and helping to keep this thing
> >> going.
> >>
> >> -Mike
> >>
> >> On Mon, May 13, 2019 at 3:12 PM Dawid Weiss 
> wrote:
> >>>
> >>> Hello everyone,
> >>>
> >>> Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!
> >>>
> >>> Many of you probably know Mike as he's been around for quite a while
> >>> -- answering questions, reviewing patches, providing insight and
> >>> actively working on new code.
> >>>
> >>> Congratulations and welcome! It is a tradition to introduce yourself
> >>> with a brief bio, Mike.
> >>>
> >>> Dawid
> >
> > -
> > 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: Welcome Michael Sokolov as Lucene/ Solr committer

[Erick Erickson]

Welcome Michael!

> On May 13, 2019, at 2:48 PM, Dawid Weiss  wrote:
> 
>> I am pretty sure my first interaction with the Apache Solr/Lucene community 
>> was back in 2012,
> 
> Yeah... I really don't know how it happened you haven't been
> invited earlier. Everyone just kind of assumed you
> have committer rights already! :)
> 
> 
> D.
> 
> On Mon, May 13, 2019 at 9:23 PM Michael Sokolov  wrote:
>> 
>> Thanks Dawid, and thank you to everyone who voted to grant me access
>> to this awesome project!
>> 
>> I spent many years building full text search web applications serving
>> large texts (especially dictionaries, encyclopedias, and academic
>> journals). I cut my teeth with AltaVista back in 1998, and tried many
>> other search engines before finally coming around to Solr/Lucene.
>> 
>> I am pretty sure my first interaction with the Apache Solr/Lucene
>> community was back in 2012, when I was looking to solve a performance
>> problem we encountered highlighting gigantic documents. Since then
>> I've worked on many projects involving Solr and Lucene, and
>> ElasticSearch, and made various contributions, implemented some of my
>> own extensions, made a separate XML query engine based on Solr (Lux -
>> no longer active), went to a few Lucene/Solr Revolutions (spoke at
>> one), and always in the back of my mind was the idea of contributing
>> more actively and becoming a full participant in this thriving open
>> source project. Now I'm really excited that has come to pass, and look
>> forward to digging in even deeper, and helping to keep this thing
>> going.
>> 
>> -Mike
>> 
>> On Mon, May 13, 2019 at 3:12 PM Dawid Weiss  wrote:
>>> 
>>> Hello everyone,
>>> 
>>> Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!
>>> 
>>> Many of you probably know Mike as he's been around for quite a while
>>> -- answering questions, reviewing patches, providing insight and
>>> actively working on new code.
>>> 
>>> Congratulations and welcome! It is a tradition to introduce yourself
>>> with a brief bio, Mike.
>>> 
>>> Dawid
> 
> -
> 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: Welcome Michael Sokolov as Lucene/ Solr committer

[Dawid Weiss]

> I am pretty sure my first interaction with the Apache Solr/Lucene community 
> was back in 2012,

Yeah... I really don't know how it happened you haven't been
invited earlier. Everyone just kind of assumed you
have committer rights already! :)


D.

On Mon, May 13, 2019 at 9:23 PM Michael Sokolov  wrote:
>
> Thanks Dawid, and thank you to everyone who voted to grant me access
> to this awesome project!
>
> I spent many years building full text search web applications serving
> large texts (especially dictionaries, encyclopedias, and academic
> journals). I cut my teeth with AltaVista back in 1998, and tried many
> other search engines before finally coming around to Solr/Lucene.
>
> I am pretty sure my first interaction with the Apache Solr/Lucene
> community was back in 2012, when I was looking to solve a performance
> problem we encountered highlighting gigantic documents. Since then
> I've worked on many projects involving Solr and Lucene, and
> ElasticSearch, and made various contributions, implemented some of my
> own extensions, made a separate XML query engine based on Solr (Lux -
> no longer active), went to a few Lucene/Solr Revolutions (spoke at
> one), and always in the back of my mind was the idea of contributing
> more actively and becoming a full participant in this thriving open
> source project. Now I'm really excited that has come to pass, and look
> forward to digging in even deeper, and helping to keep this thing
> going.
>
> -Mike
>
> On Mon, May 13, 2019 at 3:12 PM Dawid Weiss  wrote:
> >
> > Hello everyone,
> >
> > Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!
> >
> > Many of you probably know Mike as he's been around for quite a while
> > -- answering questions, reviewing patches, providing insight and
> > actively working on new code.
> >
> > Congratulations and welcome! It is a tradition to introduce yourself
> > with a brief bio, Mike.
> >
> > Dawid

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

[jira] [Commented] (SOLR-6853) solr.ManagedSynonymFilterFactory/ManagedStopwordFilterFactory: URLEncoding - Not able to delete Synonyms/Stopwords with special characters

[Sheri Watkins (JIRA)]

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

Sheri Watkins commented on SOLR-6853:
-

Yes, the ticket can be closed since we are migrating the whole solution into a 
new platform.
I am no longer on that team and it took some time to find someone who knew 
about it, so I apologize for the delayed response.






> solr.ManagedSynonymFilterFactory/ManagedStopwordFilterFactory: URLEncoding - 
> Not able to delete Synonyms/Stopwords with special characters
> --
>
> Key: SOLR-6853
> URL: https://issues.apache.org/jira/browse/SOLR-6853
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 4.10.2
> Environment: Solr 4.10.2 running @ Win7
>Reporter: Tomasz Sulkowski
>Priority: Major
>  Labels: ManagedStopwordFilterFactory, 
> ManagedSynonymFilterFactory, REST, SOLR
> Attachments: SOLR-6853.patch
>
>
> Hi Guys,
> We're using the SOLR Rest API in order to manage synonyms and stopwords with 
> solr.Managed*FilterFactory.
> {_emphasis_}The same applies to stopwords. I am going to explain the synonym 
> case only from this point on.{_emphasis_}
> Let us consider the following _schema_analysis_synonyms_en.json managedMap: {
> "xxx#xxx":["xxx#xxx"],
> "xxx%xxx":["xxx%xxx"],
> "xxx/xxx":["xxx/xxx"],
> "xxx:xxx":["xxx:xxx"],
> "xxx;xxx":["xxx;xxx"],
> "xx ":["xx "]
> }
> I can add such synonym to keyword relations using REST API. The problem is 
> that I cannot remove/list them as 
> http://localhost:8983/solr/collection1/schema/analysis/synonyms/en/
>  where  is one of the map's key throws 404, or 500 (in case of 
> xxx%25xxx):
> java.lang.NullPointerException at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:367)
>  at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)
>  at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
>  at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455) at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137) 
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557) 
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>  at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
>  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384) 
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>  at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
>  at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) 
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
>  at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
>  at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>  at org.eclipse.jetty.server.Server.handle(Server.java:368) at 
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
>  at 
> org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
>  at 
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
>  at 
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
>  at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640) at 
> org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) at 
> org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
>  at 
> org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
>  at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>  at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>  at java.lang.Thread.run(Unknown Source)



--
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-13440) Support saving/restoring state of the SimCloudManager for repeatable simulations

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13440:


Commit 87ebe6edd684556c9231c6409f1d5da3a0dbd4cb in lucene-solr's branch 
refs/heads/branch_8x from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=87ebe6e ]

SOLR-13440: Fix a precommit issue.


> Support saving/restoring state of the SimCloudManager for repeatable 
> simulations
> 
>
> Key: SOLR-13440
> URL: https://issues.apache.org/jira/browse/SOLR-13440
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-13440.patch, SOLR-13440.patch
>
>
> In order to run simulated experiments that test variations in autoscaling 
> configs and their impact on the cluster layout we need to be able to start 
> from a known well-defined state.
> Currently the {{bin/solr autoscaling -simulate}} tool supports getting the 
> initial state from an actual running cluster. This issue proposes adding 
> support for saving and restoring this state from local files for running 
> repeatable experiments.



--
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-13440) Support saving/restoring state of the SimCloudManager for repeatable simulations

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13440:


Commit 33b4b6c14bcb95209e673476ae4eb47b2dbcbfd0 in lucene-solr's branch 
refs/heads/branch_8x from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=33b4b6c ]

SOLR-13440: Support saving/restoring autoscaling state for repeatable 
simulations.


> Support saving/restoring state of the SimCloudManager for repeatable 
> simulations
> 
>
> Key: SOLR-13440
> URL: https://issues.apache.org/jira/browse/SOLR-13440
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-13440.patch, SOLR-13440.patch
>
>
> In order to run simulated experiments that test variations in autoscaling 
> configs and their impact on the cluster layout we need to be able to start 
> from a known well-defined state.
> Currently the {{bin/solr autoscaling -simulate}} tool supports getting the 
> initial state from an actual running cluster. This issue proposes adding 
> support for saving and restoring this state from local files for running 
> repeatable experiments.



--
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 Michael Sokolov as Lucene/ Solr committer

[Noble Paul]

Welcome Mike, looking forward to collaborate with you

On Tue, May 14, 2019 at 5:31 AM Uwe Schindler  wrote:

> Welcome Mike, great to have you on board! ️
>
> Uwe
>
> Am May 13, 2019 7:23:18 PM UTC schrieb Michael Sokolov  >:
>>
>> Thanks Dawid, and thank you to everyone who voted to grant me access
>> to this awesome project!
>>
>> I spent many years building full text search web applications serving
>> large texts (especially dictionaries, encyclopedias, and academic
>> journals). I cut my teeth with AltaVista back in 1998, and tried many
>> other search engines before finally coming around to Solr/Lucene.
>>
>> I am pretty sure my first interaction with the Apache Solr/Lucene
>> community was back in 2012, when I was looking to solve a performance
>> problem we encountered highlighting gigantic documents. Since then
>> I've worked on many projects involving Solr and Lucene, and
>> ElasticSearch, and made various contributions, implemented some of my
>> own extensions, made a separate XML query engine based on Solr (Lux -
>> no longer active), went to a few Lucene/Solr Revolutions (spoke at
>> one), and always in the back of my mind was the idea of contributing
>> more actively and becoming a full participant in this thriving open
>> source project. Now I'm really excited that has come to pass, and look
>> forward to digging in even deeper, and helping to keep this thing
>> going.
>>
>> -Mike
>>
>> On Mon, May 13, 2019 at 3:12 PM Dawid Weiss  wrote:
>>
>>>
>>>  Hello everyone,
>>>
>>>  Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!
>>>
>>>  Many of you probably know Mike as he's been around for quite a while
>>>  -- answering questions, reviewing patches, providing insight and
>>>  actively working on new code.
>>>
>>>  Congratulations and welcome! It is a tradition to introduce yourself
>>>  with a brief bio, Mike.
>>>
>>>  Dawid
>>>
>> --
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> https://www.thetaphi.de
>


-- 
-
Noble Paul

Re: Welcome Michael Sokolov as Lucene/ Solr committer

[Kevin Risden]

Welcome and congrats!

Kevin Risden


On Mon, May 13, 2019 at 3:32 PM Uwe Schindler  wrote:

> Welcome Mike, great to have you on board! ️
>
> Uwe
>
> Am May 13, 2019 7:23:18 PM UTC schrieb Michael Sokolov  >:
>>
>> Thanks Dawid, and thank you to everyone who voted to grant me access
>> to this awesome project!
>>
>> I spent many years building full text search web applications serving
>> large texts (especially dictionaries, encyclopedias, and academic
>> journals). I cut my teeth with AltaVista back in 1998, and tried many
>> other search engines before finally coming around to Solr/Lucene.
>>
>> I am pretty sure my first interaction with the Apache Solr/Lucene
>> community was back in 2012, when I was looking to solve a performance
>> problem we encountered highlighting gigantic documents. Since then
>> I've worked on many projects involving Solr and Lucene, and
>> ElasticSearch, and made various contributions, implemented some of my
>> own extensions, made a separate XML query engine based on Solr (Lux -
>> no longer active), went to a few Lucene/Solr Revolutions (spoke at
>> one), and always in the back of my mind was the idea of contributing
>> more actively and becoming a full participant in this thriving open
>> source project. Now I'm really excited that has come to pass, and look
>> forward to digging in even deeper, and helping to keep this thing
>> going.
>>
>> -Mike
>>
>> On Mon, May 13, 2019 at 3:12 PM Dawid Weiss  wrote:
>>
>>>
>>>  Hello everyone,
>>>
>>>  Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!
>>>
>>>  Many of you probably know Mike as he's been around for quite a while
>>>  -- answering questions, reviewing patches, providing insight and
>>>  actively working on new code.
>>>
>>>  Congratulations and welcome! It is a tradition to introduce yourself
>>>  with a brief bio, Mike.
>>>
>>>  Dawid
>>>
>> --
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> https://www.thetaphi.de
>

Re: Welcome Michael Sokolov as Lucene/ Solr committer

[Uwe Schindler]

Welcome Mike, great to have you on board! ️

Uwe

Am May 13, 2019 7:23:18 PM UTC schrieb Michael Sokolov :
>Thanks Dawid, and thank you to everyone who voted to grant me access
>to this awesome project!
>
>I spent many years building full text search web applications serving
>large texts (especially dictionaries, encyclopedias, and academic
>journals). I cut my teeth with AltaVista back in 1998, and tried many
>other search engines before finally coming around to Solr/Lucene.
>
>I am pretty sure my first interaction with the Apache Solr/Lucene
>community was back in 2012, when I was looking to solve a performance
>problem we encountered highlighting gigantic documents. Since then
>I've worked on many projects involving Solr and Lucene, and
>ElasticSearch, and made various contributions, implemented some of my
>own extensions, made a separate XML query engine based on Solr (Lux -
>no longer active), went to a few Lucene/Solr Revolutions (spoke at
>one), and always in the back of my mind was the idea of contributing
>more actively and becoming a full participant in this thriving open
>source project. Now I'm really excited that has come to pass, and look
>forward to digging in even deeper, and helping to keep this thing
>going.
>
>-Mike
>
>On Mon, May 13, 2019 at 3:12 PM Dawid Weiss 
>wrote:
>>
>> Hello everyone,
>>
>> Please join me in welcoming Michael Sokolov as Lucene/ Solr
>committer!
>>
>> Many of you probably know Mike as he's been around for quite a while
>> -- answering questions, reviewing patches, providing insight and
>> actively working on new code.
>>
>> Congratulations and welcome! It is a tradition to introduce yourself
>> with a brief bio, Mike.
>>
>> Dawid
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>For additional commands, e-mail: dev-h...@lucene.apache.org

--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de

Re: Welcome Michael Sokolov as Lucene/ Solr committer

[Erik Hatcher]

Welcome, Michael!  It’s about time :)

> On May 13, 2019, at 15:11, Dawid Weiss  wrote:
> 
> Hello everyone,
> 
> Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!
> 
> Many of you probably know Mike as he's been around for quite a while
> -- answering questions, reviewing patches, providing insight and
> actively working on new code.
> 
> Congratulations and welcome! It is a tradition to introduce yourself
> with a brief bio, Mike.
> 
> Dawid
> 
> -
> 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: Welcome Michael Sokolov as Lucene/ Solr committer

[Ishan Chattopadhyaya]

Congratulations and welcome, Michael!

On Tue, May 14, 2019 at 12:53 AM Michael Sokolov  wrote:
>
> Thanks Dawid, and thank you to everyone who voted to grant me access
> to this awesome project!
>
> I spent many years building full text search web applications serving
> large texts (especially dictionaries, encyclopedias, and academic
> journals). I cut my teeth with AltaVista back in 1998, and tried many
> other search engines before finally coming around to Solr/Lucene.
>
> I am pretty sure my first interaction with the Apache Solr/Lucene
> community was back in 2012, when I was looking to solve a performance
> problem we encountered highlighting gigantic documents. Since then
> I've worked on many projects involving Solr and Lucene, and
> ElasticSearch, and made various contributions, implemented some of my
> own extensions, made a separate XML query engine based on Solr (Lux -
> no longer active), went to a few Lucene/Solr Revolutions (spoke at
> one), and always in the back of my mind was the idea of contributing
> more actively and becoming a full participant in this thriving open
> source project. Now I'm really excited that has come to pass, and look
> forward to digging in even deeper, and helping to keep this thing
> going.
>
> -Mike
>
> On Mon, May 13, 2019 at 3:12 PM Dawid Weiss  wrote:
> >
> > Hello everyone,
> >
> > Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!
> >
> > Many of you probably know Mike as he's been around for quite a while
> > -- answering questions, reviewing patches, providing insight and
> > actively working on new code.
> >
> > Congratulations and welcome! It is a tradition to introduce yourself
> > with a brief bio, Mike.
> >
> > Dawid
>
> -
> 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: Welcome Michael Sokolov as Lucene/ Solr committer

[Michael Sokolov]

Thanks Dawid, and thank you to everyone who voted to grant me access
to this awesome project!

I spent many years building full text search web applications serving
large texts (especially dictionaries, encyclopedias, and academic
journals). I cut my teeth with AltaVista back in 1998, and tried many
other search engines before finally coming around to Solr/Lucene.

I am pretty sure my first interaction with the Apache Solr/Lucene
community was back in 2012, when I was looking to solve a performance
problem we encountered highlighting gigantic documents. Since then
I've worked on many projects involving Solr and Lucene, and
ElasticSearch, and made various contributions, implemented some of my
own extensions, made a separate XML query engine based on Solr (Lux -
no longer active), went to a few Lucene/Solr Revolutions (spoke at
one), and always in the back of my mind was the idea of contributing
more actively and becoming a full participant in this thriving open
source project. Now I'm really excited that has come to pass, and look
forward to digging in even deeper, and helping to keep this thing
going.

-Mike

On Mon, May 13, 2019 at 3:12 PM Dawid Weiss  wrote:
>
> Hello everyone,
>
> Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!
>
> Many of you probably know Mike as he's been around for quite a while
> -- answering questions, reviewing patches, providing insight and
> actively working on new code.
>
> Congratulations and welcome! It is a tradition to introduce yourself
> with a brief bio, Mike.
>
> Dawid

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

[jira] [Commented] (LUCENE-8793) Enhanced UI for CustomAnalyzer : show analysis steps

[Jun Ohtani (JIRA)]

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

Jun Ohtani commented on LUCENE-8793:


Hi [~Tomoko Uchida],

Thanks for finding a bug. 

I fixed the bug you mentioned. And also changed the layout "Step by Step" 
checkbox.

I attached [^LUCENE-8793.patch] that has the original name. Please review new 
patch file?

Thanks

> Enhanced UI for CustomAnalyzer : show analysis steps
> 
>
> Key: LUCENE-8793
> URL: https://issues.apache.org/jira/browse/LUCENE-8793
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/luke
>Reporter: Jun Ohtani
>Priority: Minor
> Attachments: LUCENE-8793-2.patch, LUCENE-8793.patch, 
> LUCENE-8793.patch, Screen Shot 2019-05-06 at 10.00.57.png, Screen Shot 
> 2019-05-07 at 1.40.47.png, Screenshot from 2019-05-06 13-45-40.png, 
> Screenshot from 2019-05-06 13-46-16.png
>
>
> This is a migrated issue from previous Luke project in GitHub: 
> [https://github.com/DmitryKey/luke/issues/134]
>  
> For on-the-fly inspection / debugging, it is desirable to show the more 
> detailed step by step information in the Custom Analyzer UI.
> This will be just like Solr's Analysis screen,
> [https://lucene.apache.org/solr/guide/7_5/analysis-screen.html]
> or Elasticsearch's {{_analyze}} API and Kibana's Analyzer UI.
> [https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-analyze.html]
> [https://github.com/johtani/analyze-api-ui-plugin]



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

Welcome Michael Sokolov as Lucene/ Solr committer

[Dawid Weiss]

Hello everyone,

Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!

Many of you probably know Mike as he's been around for quite a while
-- answering questions, reviewing patches, providing insight and
actively working on new code.

Congratulations and welcome! It is a tradition to introduce yourself
with a brief bio, Mike.

Dawid

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

[jira] [Updated] (LUCENE-8793) Enhanced UI for CustomAnalyzer : show analysis steps

[Jun Ohtani (JIRA)]

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

Jun Ohtani updated LUCENE-8793:
---
Attachment: LUCENE-8793.patch

> Enhanced UI for CustomAnalyzer : show analysis steps
> 
>
> Key: LUCENE-8793
> URL: https://issues.apache.org/jira/browse/LUCENE-8793
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/luke
>Reporter: Jun Ohtani
>Priority: Minor
> Attachments: LUCENE-8793-2.patch, LUCENE-8793.patch, 
> LUCENE-8793.patch, Screen Shot 2019-05-06 at 10.00.57.png, Screen Shot 
> 2019-05-07 at 1.40.47.png, Screenshot from 2019-05-06 13-45-40.png, 
> Screenshot from 2019-05-06 13-46-16.png
>
>
> This is a migrated issue from previous Luke project in GitHub: 
> [https://github.com/DmitryKey/luke/issues/134]
>  
> For on-the-fly inspection / debugging, it is desirable to show the more 
> detailed step by step information in the Custom Analyzer UI.
> This will be just like Solr's Analysis screen,
> [https://lucene.apache.org/solr/guide/7_5/analysis-screen.html]
> or Elasticsearch's {{_analyze}} API and Kibana's Analyzer UI.
> [https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-analyze.html]
> [https://github.com/johtani/analyze-api-ui-plugin]



--
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-12697) pure DocValues support for FieldValueFeature

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-12697:


Thanks [~erickerickson] for the ping(s)! I'd seen your earlier comments but 
had/have only limited time to continue here.

The just attached patch rebases against latest master, shrinking the patch now 
that the SOLR-13049 portion of it is committed.
{quote}Can SOLR-12625 be used in this case or, perhaps, reworked to make it 
usable here? ...
{quote}
{quote}... the calls to SolrDocumentFetcher, ...
{quote}
>From a quick look there are several public {{SolrDocumentFetcher}} methods. 
>[~slivotov] would you perhaps recall anything about how you chose the method 
>to call? I'm not yet familiar with the {{SolrDocumentFetcher}} class.

And two things I noticed and wondered whilst rebasing the patch:
 * {{FieldValueFeature.fieldAsSet}} can now be removed since it becomes unused 
with the changes here?
 * {{docFetcher}} and {{returnFields}} are currently 
{{FieldValueFeatureScorer}} members, could they be {{FieldValueFeatureWeight}} 
members instead?

> pure DocValues support for FieldValueFeature
> 
>
> Key: SOLR-12697
> URL: https://issues.apache.org/jira/browse/SOLR-12697
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LTR
>Reporter: Stanislav Livotov
>Priority: Major
> Attachments: SOLR-12697.patch, SOLR-12697.patch, SOLR-12697.patch, 
> SOLR-12697.patch
>
>
> [~slivotov] wrote in SOLR-12688:
> bq. ... FieldValueFeature doesn't support pure DocValues fields (Stored 
> false). Please also note that for fields which are both stored and DocValues 
> it is working not optimal because it is extracting just one field from the 
> stored document. DocValues are obviously faster for such usecases. ...
> (Please see SOLR-12688 description for overall context and analysis results.)



--
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-12697) pure DocValues support for FieldValueFeature

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-12697:
---
Attachment: SOLR-12697.patch

> pure DocValues support for FieldValueFeature
> 
>
> Key: SOLR-12697
> URL: https://issues.apache.org/jira/browse/SOLR-12697
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LTR
>Reporter: Stanislav Livotov
>Priority: Major
> Attachments: SOLR-12697.patch, SOLR-12697.patch, SOLR-12697.patch, 
> SOLR-12697.patch
>
>
> [~slivotov] wrote in SOLR-12688:
> bq. ... FieldValueFeature doesn't support pure DocValues fields (Stored 
> false). Please also note that for fields which are both stored and DocValues 
> it is working not optimal because it is extracting just one field from the 
> stored document. DocValues are obviously faster for such usecases. ...
> (Please see SOLR-12688 description for overall context and analysis results.)



--
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-13440) Support saving/restoring state of the SimCloudManager for repeatable simulations

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13440:


Commit 2315c6d1b899075b88f39a546f5bbd10716a4a5e in lucene-solr's branch 
refs/heads/master from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2315c6d ]

SOLR-13440: Fix a precommit issue.


> Support saving/restoring state of the SimCloudManager for repeatable 
> simulations
> 
>
> Key: SOLR-13440
> URL: https://issues.apache.org/jira/browse/SOLR-13440
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-13440.patch, SOLR-13440.patch
>
>
> In order to run simulated experiments that test variations in autoscaling 
> configs and their impact on the cluster layout we need to be able to start 
> from a known well-defined state.
> Currently the {{bin/solr autoscaling -simulate}} tool supports getting the 
> initial state from an actual running cluster. This issue proposes adding 
> support for saving and restoring this state from local files for running 
> repeatable experiments.



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

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

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

[Apache Jenkins Server]

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

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

[repro] Revision: 0aaf5432089075cf3847508ae83de76ee5e44b97

[repro] Ant options: -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-master/test-data/enwiki.random.lines.txt
[repro] Repro line:  ant test  -Dtestcase=HdfsAutoAddReplicasIntegrationTest 
-Dtests.method=testSimple -Dtests.seed=C551697D6DBDF3BB -Dtests.multiplier=2 
-Dtests.nightly=true -Dtests.slow=true -Dtests.badapples=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-master/test-data/enwiki.random.lines.txt
 -Dtests.locale=jgo-CM -Dtests.timezone=Europe/Gibraltar -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=TestCloudConsistency 
-Dtests.method=testOutOfSyncReplicasCannotBecomeLeader 
-Dtests.seed=C551697D6DBDF3BB -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true -Dtests.badapples=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-master/test-data/enwiki.random.lines.txt
 -Dtests.locale=en-BM -Dtests.timezone=America/Santa_Isabel 
-Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  
-Dtestcase=TestDistributedStatsComponentCardinality -Dtests.method=test 
-Dtests.seed=C551697D6DBDF3BB -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true -Dtests.badapples=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-master/test-data/enwiki.random.lines.txt
 -Dtests.locale=en-SI -Dtests.timezone=America/Curacao -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
0aaf5432089075cf3847508ae83de76ee5e44b97
[repro] git fetch
[repro] git checkout 0aaf5432089075cf3847508ae83de76ee5e44b97

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

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

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

[...truncated 3309 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=15 
-Dtests.class="*.TestDistributedStatsComponentCardinality|*.TestCloudConsistency|*.HdfsAutoAddReplicasIntegrationTest"
 -Dtests.showOutput=onerror -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-master/test-data/enwiki.random.lines.txt
 -Dtests.seed=C551697D6DBDF3BB -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true -Dtests.badapples=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-master/test-data/enwiki.random.lines.txt
 -Dtests.locale=en-SI -Dtests.timezone=America/Curacao -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

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

[repro] Failures:
[repro]   0/5 failed: org.apache.solr.cloud.TestCloudConsistency
[repro]   3/5 failed: 
org.apache.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest
[repro]   5/5 failed: 
org.apache.solr.handler.component.TestDistributedStatsComponentCardinality

[repro] Re-testing 100% failures at the tip of master
[repro] git fetch
[repro] git checkout master

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

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

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

[...truncated 3310 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.TestDistributedStatsComponentCardinality" 
-Dtests.showOutput=onerror -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-master/test-data/enwiki.random.lines.txt
 -Dtests.seed=C551697D6DBDF3BB -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true -Dtests.badapples=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-master/test-data/enwiki.random.lines.txt
 -Dtests.locale=en-SI -Dtests.timezone=America/Curacao -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

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

[repro] Failures at the tip of master:
[repro]   5/5 failed: 
org.apache.solr.handler.component.TestDistributedStatsComponentCardinality

[repro] Re-testing 100% failures at the tip of master without a seed
[repro] ant clean

[...truncated 8 lines...]
[repro] Test suites by module:
[repro]solr/core
[repro]  

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitShardWithRuleLink

Error Message:
Error from server at http://127.0.0.1:40795: Underlying core creation failed 
while creating collection: shardSplitWithRule_link

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:40795: Underlying core creation failed while 
creating collection: shardSplitWithRule_link
at 
__randomizedtesting.SeedInfo.seed([BD1C43B5F7844DDE:B700F62E7D182B7B]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:649)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1068)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:837)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:769)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:224)
at 
org.apache.solr.cloud.api.collections.ShardSplitTest.doSplitShardWithRule(ShardSplitTest.java:650)
at 
org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitShardWithRuleLink(ShardSplitTest.java:633)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 

[jira] [Commented] (SOLR-13440) Support saving/restoring state of the SimCloudManager for repeatable simulations

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13440:


Commit f2c18bacf23fea8586ef263dca2814d8fdd279ae in lucene-solr's branch 
refs/heads/master from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f2c18ba ]

SOLR-13440: Support saving/restoring autoscaling state for repeatable 
simulations.


> Support saving/restoring state of the SimCloudManager for repeatable 
> simulations
> 
>
> Key: SOLR-13440
> URL: https://issues.apache.org/jira/browse/SOLR-13440
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-13440.patch, SOLR-13440.patch
>
>
> In order to run simulated experiments that test variations in autoscaling 
> configs and their impact on the cluster layout we need to be able to start 
> from a known well-defined state.
> Currently the {{bin/solr autoscaling -simulate}} tool supports getting the 
> initial state from an actual running cluster. This issue proposes adding 
> support for saving and restoring this state from local files for running 
> repeatable experiments.



--
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] [Reopened] (SOLR-13331) Atomic Update Multivalue remove does not work

[JIRA]

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

Thomas Wöckinger reopened SOLR-13331:
-

Fixes missing for BinaryField, BoolField, UUIDField and a corner case for 
EnumField

> Atomic Update Multivalue remove does not work
> -
>
> Key: SOLR-13331
> URL: https://issues.apache.org/jira/browse/SOLR-13331
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UpdateRequestProcessors
>Affects Versions: 7.7, 7.7.1, 8.0
> Environment: Standalone Solr Server
>Reporter: Thomas Wöckinger
>Assignee: Jason Gerlowski
>Priority: Critical
>  Labels: patch, pull-request-available, ready-to-commit, test
> Fix For: 7.7.2, 8.1, master (9.0)
>
> Attachments: Fix-SOLR13331-Add-toNativeType-implementations.patch, 
> SOLR-13331.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> When using JavaBinCodec the values of collections are of type 
> ByteArrayUtf8CharSequence, existing field values are Strings so the remove 
> Operation does not have any effect.
> The relevant code is located in class AtomicUpdateDocumentMerger method 
> doRemove.
> The method parameter fieldVal contains the collection values of type 
> ByteArrayUtf8CharSequence, the variable original contains the collection of 
> Strings



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

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

[GitHub] [lucene-solr] don-vip opened a new pull request #674: Fix "Apache License, Version 2.0" spelling

[GitBox]

don-vip opened a new pull request #674: Fix "Apache License, Version 2.0" 
spelling
URL: https://github.com/apache/lucene-solr/pull/674
 
 
   There are many Java libraries licensed under "Apache License, Version 2.0" 
that do not use its official spelling.
   This causes issues like https://issues.apache.org/jira/browse/MPIR-382: with 
every library defining its own spelling, it's difficult in large projects to 
have a clear view of all licenses in use.
   This PR changes the license spelling to the official one, as advised by 
Maven developers.


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-13445) Preferred replicas on nodes with same system properties as the query master

[JIRA]

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

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

Nice! Thanks for adding this Dat!

> Preferred replicas on nodes with same system properties as the query master
> ---
>
> Key: SOLR-13445
> URL: https://issues.apache.org/jira/browse/SOLR-13445
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13445.patch, SOLR-13445.patch, SOLR-13445.patch
>
>
> Currently, Solr chooses a random replica for each shard to fan out the query 
> request. However, this presents a problem when running Solr in multiple 
> availability zones.
> If one availability zone fails then it affects all Solr nodes because they 
> will try to connect to Solr nodes in the failed availability zone until the 
> request times out. This can lead to a build up of threads on each Solr node 
> until the node goes out of memory. This results in a cascading failure.
> This issue try to solve this problem by adding
> * another shardPreference param named {{node.sysprop}}, so the query will be 
> routed to nodes with same defined system properties as the current one.
> * default shardPreferences on the whole cluster, which will be stored in 
> {{/clusterprops.json}}.
> * a cacher for fetching other nodes system properties whenever /live_nodes 
> get changed.



--
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-master - Build # 15845 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-master/15845/

Log: 
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on websites1 (git-websites svn-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master
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/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 9189472d70a7453d2bc2dc538f14f2c9b494 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 9189472d70a7453d2bc2dc538f14f2c9b494
Commit message: "Adding backcompat indexes for 8.1"
 > git rev-list --no-walk 9189472d70a7453d2bc2dc538f14f2c9b494 # timeout=10
No emails were triggered.
[Solr-reference-guide-master] $ /bin/bash -xe /tmp/jenkins3856621223023844802.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 using RSA key ID 39499BDB
gpg: Good signature from "Piotr Kuczynski "
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/shared/.rvm/archives/rvm-1.29.8.tgz'
Upgrading the RVM installation in /home/jenkins/shared/.rvm/
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
  * It looks like some old stuff is laying around RVM, you can cleanup with: 
rvm cleanup all


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'
Warning! PATH is not properly set up, 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
 Usually this is caused by shell initialization files. Search for 
PATH=... entries.
 You can also re-add RVM to your profile by running: rvm get 
stable --auto-dotfiles
 To fix it temporarily in this shell session run: rvm use 
ruby-2.3.3
 To ignore this error add 
rvm_silence_path_mismatch_check_flag=1 to your 
~/.rvmrc file.
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'
Warning! PATH is not properly set up, 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
 Usually this is caused by shell initialization files. Search for 
PATH=... entries.
 You can also re-add RVM to your profile by running: rvm get 
stable --auto-dotfiles
 To fix it temporarily in this shell session run: rvm use 
ruby-2.3.3
 To ignore this error add 
rvm_silence_path_mismatch_check_flag=1 to your 
~/.rvmrc file.
Running 'rvm install ruby-2.3.3'
Warning! PATH is not properly set up, 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
 Usually this is caused by shell initialization files. Search for 
PATH=... entries.
 You can also re-add RVM to your profile by running: rvm get 
stable --auto-dotfiles
 To fix it temporarily in this shell session run: rvm use 
ruby-2.3.3
 To ignore this error add 
rvm_silence_path_mismatch_check_flag=1 to your 
~/.rvmrc file.
Already installed ruby-2.3.3.
To reinstall use:

rvm reinstall ruby-2.3.3

Running 'rvm gemset create solr-refguide-gemset'
ruby-2.3.3 - #gemset created 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3@solr-refguide-gemset
ruby-2.3.3 - #generating solr-refguide-gemset 
wrappers|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\.
Running 'rvm ruby-2.3.3@solr-refguide-gemset'
Using /home/jenkins/shared/.rvm/gems/ruby-2.3.3 with gemset solr-refguide-gemset
Running 'gem install --force --version 3.5.0 jekyll'
Successfully installed 

[jira] [Commented] (SOLR-13126) Multiplicative boost of isn't applied when one of the summed or multiplied queries doesn't match

[JIRA]

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

Jan Høydahl commented on SOLR-13126:


There will not be any further releases for 7.3 or 7.5. We’ll soon release 7.7.2 
with this fix and you should consider upgrading to that version which is 
backward compatible with all 7.x versions.

> Multiplicative boost of isn't applied when one of the summed or multiplied 
> queries doesn't match 
> -
>
> Key: SOLR-13126
> URL: https://issues.apache.org/jira/browse/SOLR-13126
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Affects Versions: 7.3, 7.4, 7.6, 7.7, 7.5.0, 7.7.1
> Environment: Reproduced with macOS 10.14.1, a quick test with Windows 
> 10 showed the same result.
>Reporter: Thomas Aglassinger
>Assignee: Alan Woodward
>Priority: Major
> Fix For: 7.7.2, 8.0
>
> Attachments: 
> 0001-use-deprecated-classes-to-fix-regression-introduced-.patch, 
> 0002-SOLR-13126-Added-test-case.patch, 2019-02-14_1715.png, SOLR-13126.patch, 
> SOLR-13126.patch, debugQuery.json, image-2019-02-13-16-17-56-272.png, 
> screenshot-1.png, solr_match_neither_nextteil_nor_sony.json, 
> solr_match_neither_nextteil_nor_sony.txt, solr_match_netzteil_and_sony.json, 
> solr_match_netzteil_and_sony.txt, solr_match_netzteil_only.json, 
> solr_match_netzteil_only.txt
>
>
> Under certain circumstances search results from queries with multiple 
> multiplicative boosts using the Solr functions {{product()}} and {{query()}} 
> result in a score that is inconsistent with the one from the debugQuery 
> information. Also only the debug score is correct while the actual search 
> results show a wrong score.
> This seems somewhat similar to the behaviour described in 
> https://issues.apache.org/jira/browse/LUCENE-7132, though this issue has been 
> resolved a while ago.
> A little background: we are using Solr as a search platform for the 
> e-commerce framework SAP Hybris. There the shop administrator can create 
> multiplicative boost rules (see below for an example) where a value like 2.0 
> means that an item gets boosted to 200%. This works fine in the demo shop 
> distributed by SAP but breaks in our shop. We encountered the issue when 
> Upgrading from Solr 7.2.1 / Hybris 6.7 to Solr 7.5 / Hybris 18.8.3 (which 
> would have been named Hybris 6.8 but the version naming schema changed).
> We reduced the Solr query generated by Hybris to the relevant parts and could 
> reproduce the issue in the Solr admin without any Hybris connection.
> I attached the JSON result of a test query but here's a description of the 
> parts that seemed most relevant to me.
> The {{responseHeader.params}} reads (slightly rearranged):
> {code:java}
> "q":"{!boost b=$ymb}(+{!lucene v=$yq})",
> "ymb":"product(query({!v=\"name_text_de\\:Netzteil\\^=2.0\"},1),query({!v=\"name_text_de\\:Sony\\^=3.0\"},1))",
> "yq":"*:*",
> "sort":"score desc",
> "debugQuery":"true",
> // Added to keep the output small but probably unrelated to the actual issue
> "fl":"score,id,code_string,name_text_de",
> "fq":"catalogId:\"someProducts\"",
> "rows":"10",
> {code}
> This example boosts the German product name (field {{name_text_de}}) in case 
> in contains certain terms:
>  * "Netzteil" (power supply) is boosted to 200%
>  * "Sony" is boosted to 300%
> Consequently a product containing both terms should be boosted to 600%.
> Also the query function has the value 1 specified as default in case the name 
> does not contain the respective term resulting in a pseudo boost that 
> preserves the score.
> According to the debug information the parser used is the LuceneQParser, 
> which translates this to the following parsed query:
> {quote}FunctionScoreQuery(FunctionScoreQuery(+*:*, scored by 
> boost(product(query((ConstantScore(name_text_de:netzteil))^2.0,def=1.0),query((ConstantScore(name_text_de:sony))^3.0,def=1.0)
> {quote}
> And the translated boost is:
> {quote}org.apache.lucene.queries.function.valuesource.ProductFloatFunction:product(query((ConstantScore(name_text_de:netzteil))^2.0,def=1.0),query((ConstantScore(name_text_de:sony))^3.0,def=1.0))
> {quote}
> When taking a look at the search result, among other the following products 
> are included (see the JSON comments for an analysis of each result):
> {code:javascript}
>  {
> "id":"someProducts/Online/test711",
> "name_text_de":"Original Sony Vaio Netzteil",
> "code_string":"test711",
> // CORRECT, both "Netzteil" and "Sony" are included in the name
> "score":6.0},
>   {
> "id":"someProducts/Online/taxTestingProductThree",
>  

[jira] [Commented] (SOLR-13463) Solr admin user credentials defined with -Dbasicauth property during start is visible in admin UI to any user.

[JIRA]

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

Jan Høydahl commented on SOLR-13463:


Please see 
https://lucene.apache.org/solr/guide/7_7/solr-control-script-reference.html#enabling-basic-authentication

If you try this on a clean solr install you should be able to copy the same 
commands into solr.in.sh on your current cluster.

> Solr admin user credentials defined with -Dbasicauth property during start is 
> visible in admin UI to any user.
> --
>
> Key: SOLR-13463
> URL: https://issues.apache.org/jira/browse/SOLR-13463
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 7.7.1
> Environment: QA
>Reporter: Vinodh
>Priority: Major
>  Labels: admin-interface, credentials
>
> We have configured Solr basic authentication in our environment and used 
> Dbasicauth property to define username:password. Since these property will be 
> added to Solr startup, the Solr admin username & password details defined 
> with -Dbasicauth property are displayed in plain text format to all users who 
> are able to login into admin UI interface in JVM & Java properties sections. 
> So even a read user who has privileges to login admin UI can able to see 
> admin user username & password details.



--
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.1-Linux (32bit/jdk1.8.0_201) - Build # 322 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.1-Linux/322/
Java: 32bit/jdk1.8.0_201 -server -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.cloud.AliasIntegrationTest.testClusterStateProviderAPI

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

Stack Trace:
java.lang.AssertionError: {} expected:<2> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([1AC9568D75AE9FE5:51ECAA106A566AE]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at 
org.apache.solr.cloud.AliasIntegrationTest.testClusterStateProviderAPI(AliasIntegrationTest.java:291)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 14521 lines...]
   [junit4] Suite: org.apache.solr.cloud.AliasIntegrationTest
   [junit4]   2> Creating dataDir: 

[jira] [Commented] (LUCENE-8798) Autogenerated ID for LeafReaderContexts Within An IndexSearcher

[Atri Sharma (JIRA)]

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

Atri Sharma commented on LUCENE-8798:
-

[~sokolov] Yes, sorry about that.

> Autogenerated ID for LeafReaderContexts Within An IndexSearcher
> ---
>
> Key: LUCENE-8798
> URL: https://issues.apache.org/jira/browse/LUCENE-8798
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Minor
>
> It would be good to be able to uniquely identify LeafReaderContext objects 
> associated within a single IndexSearcher. This would allow storing of 
> metadata around segments, such as demonstrated in 
> https://issues.apache.org/jira/browse/LUCENE-879
> The ID will be unique across the IndexSearcher instance and will make no 
> guarantees of any semantic value outside the instance.



--
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-8798) Autogenerated ID for LeafReaderContexts Within An IndexSearcher

[Mike Sokolov (JIRA)]

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

Mike Sokolov commented on LUCENE-8798:
--

I think what confused me was the link to the other JIRA seems to have a typo - 
it links to an ancient unrelated issue, but I guess you meant to link to one of 
your recent ones?

> Autogenerated ID for LeafReaderContexts Within An IndexSearcher
> ---
>
> Key: LUCENE-8798
> URL: https://issues.apache.org/jira/browse/LUCENE-8798
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Minor
>
> It would be good to be able to uniquely identify LeafReaderContext objects 
> associated within a single IndexSearcher. This would allow storing of 
> metadata around segments, such as demonstrated in 
> https://issues.apache.org/jira/browse/LUCENE-879
> The ID will be unique across the IndexSearcher instance and will make no 
> guarantees of any semantic value outside the instance.



--
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-MacOSX (64bit/jdk-11.0.2) - Build # 5143 - Failure!

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 62593 lines...]
-ecj-javadoc-lint-tests:
[mkdir] Created dir: 
/var/folders/qg/h2dfw5s161s51l2bn79mrb7rgn/T/ecj1605720493
 [ecj-lint] Compiling 48 source files to 
/var/folders/qg/h2dfw5s161s51l2bn79mrb7rgn/T/ecj1605720493
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/Users/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/Users/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
 [ecj-lint] --
 [ecj-lint] 1. ERROR in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 23)
 [ecj-lint] import javax.naming.NamingException;
 [ecj-lint]
 [ecj-lint] The type javax.naming.NamingException is not accessible
 [ecj-lint] --
 [ecj-lint] 2. ERROR in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 28)
 [ecj-lint] public class MockInitialContextFactory implements 
InitialContextFactory {
 [ecj-lint]  ^
 [ecj-lint] The type MockInitialContextFactory must implement the inherited 
abstract method InitialContextFactory.getInitialContext(Hashtable)
 [ecj-lint] --
 [ecj-lint] 3. ERROR in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 30)
 [ecj-lint] private final javax.naming.Context context;
 [ecj-lint]   
 [ecj-lint] The type javax.naming.Context is not accessible
 [ecj-lint] --
 [ecj-lint] 4. ERROR in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 33)
 [ecj-lint] context = mock(javax.naming.Context.class);
 [ecj-lint] ^^^
 [ecj-lint] context cannot be resolved to a variable
 [ecj-lint] --
 [ecj-lint] 5. ERROR in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 33)
 [ecj-lint] context = mock(javax.naming.Context.class);
 [ecj-lint]
 [ecj-lint] The type javax.naming.Context is not accessible
 [ecj-lint] --
 [ecj-lint] 6. ERROR in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 36)
 [ecj-lint] when(context.lookup(anyString())).thenAnswer(invocation -> 
objects.get(invocation.getArgument(0)));
 [ecj-lint]  ^^^
 [ecj-lint] context cannot be resolved
 [ecj-lint] --
 [ecj-lint] 7. ERROR in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 38)
 [ecj-lint] } catch (NamingException e) {
 [ecj-lint]  ^^^
 [ecj-lint] NamingException cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 8. ERROR in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 45)
 [ecj-lint] public javax.naming.Context getInitialContext(Hashtable env) {
 [ecj-lint]
 [ecj-lint] The type javax.naming.Context is not accessible
 [ecj-lint] --
 [ecj-lint] 9. ERROR in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 46)
 [ecj-lint] return context;
 [ecj-lint]^^^
 [ecj-lint] context cannot be resolved to a variable
 [ecj-lint] --
 [ecj-lint] 9 problems (9 errors)

BUILD FAILED
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/build.xml:634: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/build.xml:101: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/build.xml:687: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/common-build.xml:479: 
The following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/common-build.xml:2016:
 The following error occurred while executing this line:

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.solr.cloud.AliasIntegrationTest.testClusterStateProviderAPI

Error Message:
should be a routed alias

Stack Trace:
java.lang.AssertionError: should be a routed alias
at 
__randomizedtesting.SeedInfo.seed([AB2E83A2DD08E661:B4F91F8EAE031F2A]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.solr.cloud.AliasIntegrationTest.testClusterStateProviderAPI(AliasIntegrationTest.java:302)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:830)


FAILED:  org.apache.solr.metrics.rrd.SolrRrdBackendFactoryTest.testBasic

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

Stack Trace:
java.lang.AssertionError: {} expected:<1> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([AB2E83A2DD08E661:D49EB702D4604F]:0)
at 

[jira] [Commented] (LUCENE-8798) Autogenerated ID for LeafReaderContexts Within An IndexSearcher

[Atri Sharma (JIRA)]

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

Atri Sharma commented on LUCENE-8798:
-

[~sokolov] Yes, as I commented in the other JIRA, this idea does not directly 
relate to the CollectorScorer patch, but came as an outcome of reading through 
it.

 

This is more of a readability and clarity perspective proposal – considering 
that LeafReaderContext allows initialization without assigning a specific 
ordinal, there should be an unique identifier which will be valid for any 
constructed LeafReaderContext – irrespective of which constructor initialized 
it.

 

My primary use case is to allow a secure way of storing in memory runtime 
metadata about segments during a search execution, hence the invariant that the 
ID has no relevance outside the scope of the owning IndexSearcher. Making 
persistent IDs that get written to segment blocks is an interesting idea, but 
is not what I planned to originally propose.

> Autogenerated ID for LeafReaderContexts Within An IndexSearcher
> ---
>
> Key: LUCENE-8798
> URL: https://issues.apache.org/jira/browse/LUCENE-8798
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Minor
>
> It would be good to be able to uniquely identify LeafReaderContext objects 
> associated within a single IndexSearcher. This would allow storing of 
> metadata around segments, such as demonstrated in 
> https://issues.apache.org/jira/browse/LUCENE-879
> The ID will be unique across the IndexSearcher instance and will make no 
> guarantees of any semantic value outside the instance.



--
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-8798) Autogenerated ID for LeafReaderContexts Within An IndexSearcher

[Mike Sokolov (JIRA)]

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

Mike Sokolov commented on LUCENE-8798:
--

[~atris] I glanced at the issue you referenced, but I don't see how it relates 
to this. Could you sketch out a use case where this would be better than using 
the ordinals that we use today to identify segments? Would these be persisted? 

> Autogenerated ID for LeafReaderContexts Within An IndexSearcher
> ---
>
> Key: LUCENE-8798
> URL: https://issues.apache.org/jira/browse/LUCENE-8798
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Minor
>
> It would be good to be able to uniquely identify LeafReaderContext objects 
> associated within a single IndexSearcher. This would allow storing of 
> metadata around segments, such as demonstrated in 
> https://issues.apache.org/jira/browse/LUCENE-879
> The ID will be unique across the IndexSearcher instance and will make no 
> guarantees of any semantic value outside the instance.



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

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

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

[Apache Jenkins Server]

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

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

[repro] Revision: 47c4e4184a5482894753fb4f7aa5126cf9f035c8

[repro] Ant options: -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.1/test-data/enwiki.random.lines.txt
[repro] Repro line:  ant test  -Dtestcase=CdcrReplicationHandlerTest 
-Dtests.method=testReplicationWithBufferedUpdates -Dtests.seed=B63DE4397274D9EB 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.1/test-data/enwiki.random.lines.txt
 -Dtests.locale=mt-MT -Dtests.timezone=PLT -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[repro] Repro line:  ant test  -Dtestcase=TestReplicationHandler 
-Dtests.seed=B63DE4397274D9EB -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.1/test-data/enwiki.random.lines.txt
 -Dtests.locale=mk -Dtests.timezone=America/Caracas -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[repro] Repro line:  ant test  -Dtestcase=AuditLoggerIntegrationTest 
-Dtests.method=testSynchronous -Dtests.seed=B63DE4397274D9EB 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.1/test-data/enwiki.random.lines.txt
 -Dtests.locale=hu-HU -Dtests.timezone=Pacific/Samoa -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
9189472d70a7453d2bc2dc538f14f2c9b494
[repro] git fetch
[repro] git checkout 47c4e4184a5482894753fb4f7aa5126cf9f035c8

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

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

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

[...truncated 3576 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=15 
-Dtests.class="*.CdcrReplicationHandlerTest|*.AuditLoggerIntegrationTest|*.TestReplicationHandler"
 -Dtests.showOutput=onerror -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.1/test-data/enwiki.random.lines.txt
 -Dtests.seed=B63DE4397274D9EB -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.1/test-data/enwiki.random.lines.txt
 -Dtests.locale=mt-MT -Dtests.timezone=PLT -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

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

[repro] Failures:
[repro]   0/5 failed: org.apache.solr.security.AuditLoggerIntegrationTest
[repro]   1/5 failed: org.apache.solr.cloud.cdcr.CdcrReplicationHandlerTest
[repro]   1/5 failed: org.apache.solr.handler.TestReplicationHandler
[repro] git checkout 9189472d70a7453d2bc2dc538f14f2c9b494

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

[...truncated 6 lines...]

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

[jira] [Issue Comment Deleted] (LUCENE-8795) ArrayIndexOutOfBoundsException during System.arraycopy in BKDWriter

[Torben Riis (JIRA)]

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

Torben Riis updated LUCENE-8795:

Comment: was deleted

(was: I will be out of office until May 14th 2019.

I may or may not get a chance to read mails during my absence.
If you cannot wait for a reply until my return, please send your request to 
helpd...@multi-support.com for a more prompt 
response.


Kind regards

Torben Riis
--
—
Torben Riis
Lead Architect
Multi-Support · Making good business run better
+45 96 600 600 · www.multi-support.com
)

> ArrayIndexOutOfBoundsException during System.arraycopy in BKDWriter
> ---
>
> Key: LUCENE-8795
> URL: https://issues.apache.org/jira/browse/LUCENE-8795
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index
>Affects Versions: 6.6
> Environment: h2. Operating system/Platform
> {code:java}
> IBM i - V7R3M0
> {code}
> h2. Java version
> {code:java}
> java version "1.8.0_191"
> Java(TM) SE Runtime Environment (build 8.0.5.25 - 
> pap6480sr5fp25-20181030_01(SR5 FP25))
> IBM J9 VM (build 2.9, JRE 1.8.0 OS/400 ppc64-64-Bit Compressed References 
> 20181029_400846 (JIT enabled, AOT enabled)
> OpenJ9   - c5c78da
> OMR  - 3d5ac33
> IBM  - 8c1bdc2)
> JCL - 20181022_01 based on Oracle jdk8u191-b26
> NOTICE: If no version information is found above, this could indicate a 
> corrupted Java installation!
> Java detected was: /QOpenSys/QIBM/ProdData/JavaVM/jdk80/64bit/bin/java
> -Dmultiarchive.basepath=/home/NEXTOWN/Multi-Support/Next -Xms128m -Xmx2048m
> {code}
>Reporter: Torben Riis
>Priority: Major
>
> Hi,
> I’m a bit stuck here and needs a clue or two in order to continue our 
> investigations. Hope that someone can help. :)
> Periodically, around once a month, we get the below 
> {{ArrayIndexOutOfBoundsException}} on our system. We use multiple indexes and 
> the error can originate from any of them, but the error always occurs in line 
> 1217 in {{BKDWriter}} (during a {{System.arraycopy}}).
> We found a couple of issues on the net regarding JIT optimization problem 
> related to J9, but they all looks like they have been resolved and cannot be 
> reproduced anymore. But nevertheless, we have added the following {{-Xjit}} 
> flags to excludes JIT optimization for every class / inner classes in the 
> {{bkd}} package. Moreover, we have also made a complete copy of the whole 
> installation in production, and added the opposite arguments (enforce JIT 
> optimizations for the specific classes). First we will try with 
> {{optLevel=hot}}, but if this doesn’t show anything we will afterwards try 
> with {{veryHot}} and {{scorching}}. Unfortunately we do not have the result 
> of this yet, but I’ll of course post it when it is known.
> Unfortunately it’s not possible to run OpenJDK on the IBM i platform, so such 
> a test will not be possible, but it is worth mentioning that our product is a 
> standard product, which typically run on the Windows or Linux platform using 
> AdoptOpenJDK. Currently we have a couple of hundred installations running out 
> there on these platforms, and without any problems. But on the IBM I platform 
> with J9 we sometimes see this exception.
> Any good ideas for further investigations? Or have seen such issue before?
> We are using Lucene 6.6.0 and runs on IBM J9 on the IBM I platform.
> h2.  Stacktrace
> {code:java}
> Exception in thread "Lucene Merge Thread #0" 2019-05-01T06:10:07.970 CEST 
> [Lucene Merge Thread #0] org.apache.lucene.index.MergePolicy$MergeException: 
> java.lang.ArrayIndexOutOfBoundsException
> at 
> org.apache.lucene.index.ConcurrentMergeScheduler.handleMergeException(ConcurrentMergeScheduler.java:703)
> at 
> org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:683)
> Caused by: 2019-05-01T06:10:07.971 CEST [Lucene Merge Thread #0] 
> java.lang.ArrayIndexOutOfBoundsException
> at 
> org.apache.lucene.util.bkd.BKDWriter.recursePackIndex(BKDWriter.java:1217)
> at 
> org.apache.lucene.util.bkd.BKDWriter.recursePackIndex(BKDWriter.java:1197)
> at 
> org.apache.lucene.util.bkd.BKDWriter.packIndex(BKDWriter.java:1078)
> at 
> org.apache.lucene.util.bkd.BKDWriter.writeIndex(BKDWriter.java:1245)
> at 
> org.apache.lucene.util.bkd.BKDWriter.access$600(BKDWriter.java:82)
> at 
> org.apache.lucene.util.bkd.BKDWriter$OneDimensionBKDWriter.finish(BKDWriter.java:648)
> at org.apache.lucene.util.bkd.BKDWriter.merge(BKDWriter.java:560)
> at 
> org.apache.lucene.codecs.lucene60.Lucene60PointsWriter.merge(Lucene60PointsWriter.java:212)
> at 
> 

[JENKINS] Lucene-Solr-NightlyTests-8.1 - Build # 32 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.1/32/

2 tests failed.
FAILED:  org.apache.solr.cloud.TestCloudRecovery2.test

Error Message:
 Timeout waiting to see state for collection=collection1 
:DocCollection(collection1//collections/collection1/state.json/11)={   
"pullReplicas":"0",   "replicationFactor":"2",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node2":{   "core":"collection1_shard1_replica_n1",   
"base_url":"https://127.0.0.1:42062/solr;,   
"node_name":"127.0.0.1:42062_solr",   "state":"active",   
"type":"NRT",   "force_set_state":"false",   "leader":"true"},  
   "core_node4":{   "core":"collection1_shard1_replica_n3", 
  "base_url":"https://127.0.0.1:43467/solr;,   
"node_name":"127.0.0.1:43467_solr",   "state":"down",   
"type":"NRT",   "force_set_state":"false",   
"router":{"name":"compositeId"},   "maxShardsPerNode":"2",   
"autoAddReplicas":"false",   "nrtReplicas":"2",   "tlogReplicas":"0"} Live 
Nodes: [127.0.0.1:42062_solr, 127.0.0.1:43467_solr] Last available state: 
DocCollection(collection1//collections/collection1/state.json/11)={   
"pullReplicas":"0",   "replicationFactor":"2",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node2":{   "core":"collection1_shard1_replica_n1",   
"base_url":"https://127.0.0.1:42062/solr;,   
"node_name":"127.0.0.1:42062_solr",   "state":"active",   
"type":"NRT",   "force_set_state":"false",   "leader":"true"},  
   "core_node4":{   "core":"collection1_shard1_replica_n3", 
  "base_url":"https://127.0.0.1:43467/solr;,   
"node_name":"127.0.0.1:43467_solr",   "state":"down",   
"type":"NRT",   "force_set_state":"false",   
"router":{"name":"compositeId"},   "maxShardsPerNode":"2",   
"autoAddReplicas":"false",   "nrtReplicas":"2",   "tlogReplicas":"0"}

Stack Trace:
java.lang.AssertionError: 
Timeout waiting to see state for collection=collection1 
:DocCollection(collection1//collections/collection1/state.json/11)={
  "pullReplicas":"0",
  "replicationFactor":"2",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node2":{
  "core":"collection1_shard1_replica_n1",
  "base_url":"https://127.0.0.1:42062/solr;,
  "node_name":"127.0.0.1:42062_solr",
  "state":"active",
  "type":"NRT",
  "force_set_state":"false",
  "leader":"true"},
"core_node4":{
  "core":"collection1_shard1_replica_n3",
  "base_url":"https://127.0.0.1:43467/solr;,
  "node_name":"127.0.0.1:43467_solr",
  "state":"down",
  "type":"NRT",
  "force_set_state":"false",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"2",
  "autoAddReplicas":"false",
  "nrtReplicas":"2",
  "tlogReplicas":"0"}
Live Nodes: [127.0.0.1:42062_solr, 127.0.0.1:43467_solr]
Last available state: 
DocCollection(collection1//collections/collection1/state.json/11)={
  "pullReplicas":"0",
  "replicationFactor":"2",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node2":{
  "core":"collection1_shard1_replica_n1",
  "base_url":"https://127.0.0.1:42062/solr;,
  "node_name":"127.0.0.1:42062_solr",
  "state":"active",
  "type":"NRT",
  "force_set_state":"false",
  "leader":"true"},
"core_node4":{
  "core":"collection1_shard1_replica_n3",
  "base_url":"https://127.0.0.1:43467/solr;,
  "node_name":"127.0.0.1:43467_solr",
  "state":"down",
  "type":"NRT",
  "force_set_state":"false",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"2",
  "autoAddReplicas":"false",
  "nrtReplicas":"2",
  "tlogReplicas":"0"}
at 
__randomizedtesting.SeedInfo.seed([DF83706E1088C08F:57D74FB4BE74AD77]:0)
at org.junit.Assert.fail(Assert.java:88)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:310)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:288)
at 
org.apache.solr.cloud.TestCloudRecovery2.test(TestCloudRecovery2.java:91)
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 

[jira] [Created] (LUCENE-8798) Autogenerated ID for LeafReaderContexts Within An IndexSearcher

[Atri Sharma (JIRA)]

Atri Sharma created LUCENE-8798:
---

 Summary: Autogenerated ID for LeafReaderContexts Within An 
IndexSearcher
 Key: LUCENE-8798
 URL: https://issues.apache.org/jira/browse/LUCENE-8798
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Atri Sharma


It would be good to be able to uniquely identify LeafReaderContext objects 
associated within a single IndexSearcher. This would allow storing of metadata 
around segments, such as demonstrated in 
https://issues.apache.org/jira/browse/LUCENE-879

The ID will be unique across the IndexSearcher instance and will make no 
guarantees of any semantic value outside the instance.



--
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-13347) Error writing Transaction log for UUIDField

[JIRA]

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

Thomas Wöckinger updated SOLR-13347:

Affects Version/s: 7.7
   7.7.1

> Error writing Transaction log for UUIDField
> ---
>
> Key: SOLR-13347
> URL: https://issues.apache.org/jira/browse/SOLR-13347
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Server
>Affects Versions: 7.7, 7.7.1, 8.0
>Reporter: Thomas Wöckinger
>Priority: Major
>  Labels: pull-request-available, ready-to-commit, test
>
> When using Atomic Update, adding a value leads to following Exception
> org.apache.solr.common.SolrException: TransactionLog doesn't know how to 
> serialize class java.util.UUID; try implementing ObjectResolver?
>     at 
> org.apache.solr.update.TransactionLog$1.resolve(TransactionLog.java:100)
>     at 
> org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:263)
>     at 
> org.apache.solr.common.util.JavaBinCodec.writeArray(JavaBinCodec.java:770)
>     at 
> org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:369)
>     at 
> org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:362)
>     at 
> org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:252)
>     at 
> org.apache.solr.common.util.JavaBinCodec$BinEntryWriter.put(JavaBinCodec.java:437)
>     at 
> org.apache.solr.common.MapWriter$EntryWriter.putNoEx(MapWriter.java:100)
>     at 
> org.apache.solr.common.MapWriter$EntryWriter.lambda$getBiConsumer$0(MapWriter.java:160)
>     at java.base/java.util.LinkedHashMap.forEach(LinkedHashMap.java:684)
>     at 
> org.apache.solr.common.SolrInputDocument.writeMap(SolrInputDocument.java:51)
>     at 
> org.apache.solr.common.util.JavaBinCodec.writeSolrInputDocument(JavaBinCodec.java:657)
>     at org.apache.solr.update.TransactionLog.write(TransactionLog.java:371)
>     at org.apache.solr.update.UpdateLog.add(UpdateLog.java:573)
>     at org.apache.solr.update.UpdateLog.add(UpdateLog.java:552)
>     at 
> org.apache.solr.update.DirectUpdateHandler2.doNormalUpdate(DirectUpdateHandler2.java:351)
>     at 
> org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:289)
>     at 
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:236)
>     at 
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:76)
>     at 
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
>     at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:995)
>     at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1216)
>     at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:700)
>     at 
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)
>     at 
> org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:110)
>     at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:327)
>     at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readIterator(JavaBinUpdateRequestCodec.java:280)
>     at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:335)
>     at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:280)
>     at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readNamedList(JavaBinUpdateRequestCodec.java:235)
>     at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:300)
>     at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:280)
>     at 
> org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:193)
>     at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:126)
>     at 
> org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(JavabinLoader.java:123)
>     at 
> org.apache.solr.handler.loader.JavabinLoader.load(JavabinLoader.java:70)
>     at 
> org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:97)
>     at 
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68)
>     at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
>     at org.apache.solr.core.SolrCore.execute(SolrCore.java:2559)



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

[jira] [Updated] (SOLR-11841) Removing values from a multivalued EnumField by Atomic Update does not work when using XML as codec

[JIRA]

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

Thomas Wöckinger updated SOLR-11841:

Affects Version/s: 6.6.5

> Removing values from a multivalued EnumField by Atomic Update does not work 
> when using XML as codec
> ---
>
> Key: SOLR-11841
> URL: https://issues.apache.org/jira/browse/SOLR-11841
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Server, UpdateRequestProcessors
>Affects Versions: 6.6.2, 6.6.5, 7.6, 7.7, 7.7.1, 8.0
> Environment: EmbeddedSolrServer, HttpSolrClient when using 
> RequestWriter instead of BinaryRequestWriter
>Reporter: Thomas Wöckinger
>Priority: Major
>  Labels: pull-request-available, ready-to-commit, test
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> If XMLLoader is used to build SolrInputDocuments Enum values are treated as 
> String values and not as EnumFieldValue like it is done by the binary codec.
> So the doRemove call of AtomicUpdateDocumentMerger will get String values 
> which does not match any EnumFieldValue from the existingField values.
> The behaviour can be tested easily with  the EmbeddedSolrServer because it 
> uses the XML codec to convert the SolrRequest.
> Just create a multivalued EnumField add some values and try to remove some 
> with
> atomic update calls.
> The values will remain unchanged.



--
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-11841) Removing values from a multivalued EnumField by Atomic Update does not work when using XML as codec

[JIRA]

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

Thomas Wöckinger updated SOLR-11841:

Affects Version/s: 7.6
   7.7
   7.7.1
   8.0

> Removing values from a multivalued EnumField by Atomic Update does not work 
> when using XML as codec
> ---
>
> Key: SOLR-11841
> URL: https://issues.apache.org/jira/browse/SOLR-11841
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Server, UpdateRequestProcessors
>Affects Versions: 6.6.2, 7.6, 7.7, 7.7.1, 8.0
> Environment: EmbeddedSolrServer, HttpSolrClient when using 
> RequestWriter instead of BinaryRequestWriter
>Reporter: Thomas Wöckinger
>Priority: Major
>  Labels: pull-request-available, ready-to-commit, test
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> If XMLLoader is used to build SolrInputDocuments Enum values are treated as 
> String values and not as EnumFieldValue like it is done by the binary codec.
> So the doRemove call of AtomicUpdateDocumentMerger will get String values 
> which does not match any EnumFieldValue from the existingField values.
> The behaviour can be tested easily with  the EmbeddedSolrServer because it 
> uses the XML codec to convert the SolrRequest.
> Just create a multivalued EnumField add some values and try to remove some 
> with
> atomic update calls.
> The values will remain unchanged.



--
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-8791) Add CollectorRescorer

[Atri Sharma (JIRA)]

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

Atri Sharma commented on LUCENE-8791:
-

Thinking more about this, using LeafReaderContext.ord directly as positional 
parameter might be risky since LeafReaderContext has a constructor where it 
sets the ord to 0. Ideally that should not happen given that these segments are 
already scored once, but that might be one case worth thinking about?

> Add CollectorRescorer
> -
>
> Key: LUCENE-8791
> URL: https://issues.apache.org/jira/browse/LUCENE-8791
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Elbek Kamoliddinov
>Priority: Major
> Attachments: LUCENE-8791.patch, LUCENE-8791.patch
>
>
> This is another implementation of query rescorer api (LUCENE-5489). It adds 
> rescoring functionality based on provided CollectorManager. 
>  



--
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 # 551 - Unstable!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.AliasIntegrationTest.testClusterStateProviderAPI

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

Stack Trace:
java.lang.AssertionError: {} expected:<2> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([4E12C765955FBA1C:51C55B49E6544357]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at 
org.apache.solr.cloud.AliasIntegrationTest.testClusterStateProviderAPI(AliasIntegrationTest.java:291)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 14405 lines...]
   [junit4] Suite: org.apache.solr.cloud.AliasIntegrationTest
   [junit4]   2> Creating dataDir: 

[jira] [Commented] (LUCENE-8727) IndexSearcher#search(Query,int) should operate on a shared priority queue when configured with an executor

[Atri Sharma (JIRA)]

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

Atri Sharma commented on LUCENE-8727:
-

Will take a crack at this soon

> IndexSearcher#search(Query,int) should operate on a shared priority queue 
> when configured with an executor
> --
>
> Key: LUCENE-8727
> URL: https://issues.apache.org/jira/browse/LUCENE-8727
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
>
> If IndexSearcher is configured with an executor, then the top docs for each 
> slice are computed separately before being merged once the top docs for all 
> slices are computed. With block-max WAND this is a bit of a waste of 
> resources: it would be better if an increase of the min competitive score 
> could help skip non-competitive hits on every slice and not just the current 
> one.



--
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-7697) IndexSearcher should leverage index sorting

[Atri Sharma (JIRA)]

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

Atri Sharma commented on LUCENE-7697:
-

[~jpountz] Ok, I will take up 8727 then.

> IndexSearcher should leverage index sorting
> ---
>
> Key: LUCENE-7697
> URL: https://issues.apache.org/jira/browse/LUCENE-7697
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
>
> We made good efforts in order to make index sorting fast and easy to 
> configure. We should now look into making IndexSearcher aware of it. This 
> will probably require changes of the API as not collecting all matches means 
> that we can no longer know things like the total number of hits or the 
> maximum score.
> I don't plan to work on it anytime soon, I'm just opening this issue to raise 
> awareness. I'd be happy to do reviews however if someone decides to tackle it.



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

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

[jira] [Commented] (LUCENE-8757) Better Segment To Thread Mapping Algorithm

[Atri Sharma (JIRA)]

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

Atri Sharma commented on LUCENE-8757:
-

[~jpountz] Thanks, TopDocs#merge is what really opened my eyes to this 
invariant. Attached is an updated patch.

 

Please let me know if it looks fine.

[^LUCENE-8757.patch]

> Better Segment To Thread Mapping Algorithm
> --
>
> Key: LUCENE-8757
> URL: https://issues.apache.org/jira/browse/LUCENE-8757
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Assignee: Simon Willnauer
>Priority: Major
> Attachments: LUCENE-8757.patch, LUCENE-8757.patch, LUCENE-8757.patch, 
> LUCENE-8757.patch, LUCENE-8757.patch
>
>
> The current segments to threads allocation algorithm always allocates one 
> thread per segment. This is detrimental to performance in case of skew in 
> segment sizes since small segments also get their dedicated thread. This can 
> lead to performance degradation due to context switching overheads.
>  
> A better algorithm which is cognizant of size skew would have better 
> performance for realistic scenarios



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

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

[jira] [Updated] (LUCENE-8757) Better Segment To Thread Mapping Algorithm

[Atri Sharma (JIRA)]

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

Atri Sharma updated LUCENE-8757:

Attachment: LUCENE-8757.patch

> Better Segment To Thread Mapping Algorithm
> --
>
> Key: LUCENE-8757
> URL: https://issues.apache.org/jira/browse/LUCENE-8757
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Assignee: Simon Willnauer
>Priority: Major
> Attachments: LUCENE-8757.patch, LUCENE-8757.patch, LUCENE-8757.patch, 
> LUCENE-8757.patch, LUCENE-8757.patch
>
>
> The current segments to threads allocation algorithm always allocates one 
> thread per segment. This is detrimental to performance in case of skew in 
> segment sizes since small segments also get their dedicated thread. This can 
> lead to performance degradation due to context switching overheads.
>  
> A better algorithm which is cognizant of size skew would have better 
> performance for realistic scenarios



--
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: [jira] [Commented] (LUCENE-8757) Better Segment To Thread Mapping Algorithm

[Simon Willnauer]

I think this should be done inside IndexSearcher. It’s a general problem, no?

> On 13. May 2019, at 10:25, Adrien Grand (JIRA)  wrote:
> 
> 
>[ 
> https://issues.apache.org/jira/browse/LUCENE-8757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16838363#comment-16838363
>  ] 
> 
> Adrien Grand commented on LUCENE-8757:
> --
> 
> Yes. Top-docs collectors are expected to tie-break by doc ID in case 
> documents compare equal. Things like TopDocs#merge compare doc IDs explicitly 
> for that purpose, but Collector#collect implementations just rely on the fact 
> that documents are collected in order to ignore documents that compare equal 
> to the current k-th best hit. So we need to sort segments within a slice by 
> docBase in order to get the same top hits regardless of how slices have been 
> constructed.
> 
>> Better Segment To Thread Mapping Algorithm
>> --
>> 
>>Key: LUCENE-8757
>>URL: https://issues.apache.org/jira/browse/LUCENE-8757
>>Project: Lucene - Core
>> Issue Type: Improvement
>>   Reporter: Atri Sharma
>>   Assignee: Simon Willnauer
>>   Priority: Major
>>Attachments: LUCENE-8757.patch, LUCENE-8757.patch, LUCENE-8757.patch, 
>> LUCENE-8757.patch
>> 
>> 
>> The current segments to threads allocation algorithm always allocates one 
>> thread per segment. This is detrimental to performance in case of skew in 
>> segment sizes since small segments also get their dedicated thread. This can 
>> lead to performance degradation due to context switching overheads.
>>  
>> A better algorithm which is cognizant of size skew would have better 
>> performance for realistic scenarios
> 
> 
> 
> --
> 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
> 

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

[jira] [Resolved] (SOLR-13445) Preferred replicas on nodes with same system properties as the query master

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat resolved SOLR-13445.
-
Resolution: Fixed

> Preferred replicas on nodes with same system properties as the query master
> ---
>
> Key: SOLR-13445
> URL: https://issues.apache.org/jira/browse/SOLR-13445
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13445.patch, SOLR-13445.patch, SOLR-13445.patch
>
>
> Currently, Solr chooses a random replica for each shard to fan out the query 
> request. However, this presents a problem when running Solr in multiple 
> availability zones.
> If one availability zone fails then it affects all Solr nodes because they 
> will try to connect to Solr nodes in the failed availability zone until the 
> request times out. This can lead to a build up of threads on each Solr node 
> until the node goes out of memory. This results in a cascading failure.
> This issue try to solve this problem by adding
> * another shardPreference param named {{node.sysprop}}, so the query will be 
> routed to nodes with same defined system properties as the current one.
> * default shardPreferences on the whole cluster, which will be stored in 
> {{/clusterprops.json}}.
> * a cacher for fetching other nodes system properties whenever /live_nodes 
> get changed.



--
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-13331) Atomic Update Multivalue remove does not work

[JIRA]

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

Thomas Wöckinger updated SOLR-13331:

Labels: patch pull-request-available ready-to-commit test  (was: patch 
pull-request-available test)

> Atomic Update Multivalue remove does not work
> -
>
> Key: SOLR-13331
> URL: https://issues.apache.org/jira/browse/SOLR-13331
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UpdateRequestProcessors
>Affects Versions: 7.7, 7.7.1, 8.0
> Environment: Standalone Solr Server
>Reporter: Thomas Wöckinger
>Assignee: Jason Gerlowski
>Priority: Critical
>  Labels: patch, pull-request-available, ready-to-commit, test
> Fix For: 7.7.2, 8.1, master (9.0)
>
> Attachments: Fix-SOLR13331-Add-toNativeType-implementations.patch, 
> SOLR-13331.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> When using JavaBinCodec the values of collections are of type 
> ByteArrayUtf8CharSequence, existing field values are Strings so the remove 
> Operation does not have any effect.
> The relevant code is located in class AtomicUpdateDocumentMerger method 
> doRemove.
> The method parameter fieldVal contains the collection values of type 
> ByteArrayUtf8CharSequence, the variable original contains the collection of 
> Strings



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

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

[JENKINS] Solr-reference-guide-8.1 - Build # 87 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-8.1/87/

Log: 
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on websites1 (git-websites svn-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-8.1
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_8_1^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/branch_8_1^{commit} # timeout=10
Checking out Revision 47c4e4184a5482894753fb4f7aa5126cf9f035c8 
(refs/remotes/origin/branch_8_1)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 47c4e4184a5482894753fb4f7aa5126cf9f035c8
Commit message: "SOLR-13453: Adjust auth metrics asserts in tests after 
SOLR-13449 (#668)"
 > git rev-list --no-walk 47c4e4184a5482894753fb4f7aa5126cf9f035c8 # timeout=10
No emails were triggered.
[Solr-reference-guide-8.1] $ /bin/bash -xe /tmp/jenkins5879921638818335208.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: can't open signed data `/home/jenkins/shared/.rvm/archives/rvm-1.29.8.tgz'
gpg: can't hash datafile: file open error
GPG signature verification failed for 
'/home/jenkins/shared/.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] [Updated] (SOLR-11841) Removing values from a multivalued EnumField by Atomic Update does not work when using XML as codec

[JIRA]

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

Thomas Wöckinger updated SOLR-11841:

Labels: pull-request-available ready-to-commit test  (was: 
pull-request-available test)

> Removing values from a multivalued EnumField by Atomic Update does not work 
> when using XML as codec
> ---
>
> Key: SOLR-11841
> URL: https://issues.apache.org/jira/browse/SOLR-11841
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Server, UpdateRequestProcessors
>Affects Versions: 6.6.2
> Environment: EmbeddedSolrServer, HttpSolrClient when using 
> RequestWriter instead of BinaryRequestWriter
>Reporter: Thomas Wöckinger
>Priority: Major
>  Labels: pull-request-available, ready-to-commit, test
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> If XMLLoader is used to build SolrInputDocuments Enum values are treated as 
> String values and not as EnumFieldValue like it is done by the binary codec.
> So the doRemove call of AtomicUpdateDocumentMerger will get String values 
> which does not match any EnumFieldValue from the existingField values.
> The behaviour can be tested easily with  the EmbeddedSolrServer because it 
> uses the XML codec to convert the SolrRequest.
> Just create a multivalued EnumField add some values and try to remove some 
> with
> atomic update calls.
> The values will remain unchanged.



--
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-13347) Error writing Transaction log for UUIDField

[JIRA]

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

Thomas Wöckinger updated SOLR-13347:

Labels: pull-request-available ready-to-commit test  (was: 
pull-request-available test)

> Error writing Transaction log for UUIDField
> ---
>
> Key: SOLR-13347
> URL: https://issues.apache.org/jira/browse/SOLR-13347
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Server
>Affects Versions: 8.0
>Reporter: Thomas Wöckinger
>Priority: Major
>  Labels: pull-request-available, ready-to-commit, test
>
> When using Atomic Update, adding a value leads to following Exception
> org.apache.solr.common.SolrException: TransactionLog doesn't know how to 
> serialize class java.util.UUID; try implementing ObjectResolver?
>     at 
> org.apache.solr.update.TransactionLog$1.resolve(TransactionLog.java:100)
>     at 
> org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:263)
>     at 
> org.apache.solr.common.util.JavaBinCodec.writeArray(JavaBinCodec.java:770)
>     at 
> org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:369)
>     at 
> org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:362)
>     at 
> org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:252)
>     at 
> org.apache.solr.common.util.JavaBinCodec$BinEntryWriter.put(JavaBinCodec.java:437)
>     at 
> org.apache.solr.common.MapWriter$EntryWriter.putNoEx(MapWriter.java:100)
>     at 
> org.apache.solr.common.MapWriter$EntryWriter.lambda$getBiConsumer$0(MapWriter.java:160)
>     at java.base/java.util.LinkedHashMap.forEach(LinkedHashMap.java:684)
>     at 
> org.apache.solr.common.SolrInputDocument.writeMap(SolrInputDocument.java:51)
>     at 
> org.apache.solr.common.util.JavaBinCodec.writeSolrInputDocument(JavaBinCodec.java:657)
>     at org.apache.solr.update.TransactionLog.write(TransactionLog.java:371)
>     at org.apache.solr.update.UpdateLog.add(UpdateLog.java:573)
>     at org.apache.solr.update.UpdateLog.add(UpdateLog.java:552)
>     at 
> org.apache.solr.update.DirectUpdateHandler2.doNormalUpdate(DirectUpdateHandler2.java:351)
>     at 
> org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:289)
>     at 
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:236)
>     at 
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:76)
>     at 
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
>     at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:995)
>     at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1216)
>     at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:700)
>     at 
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)
>     at 
> org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:110)
>     at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:327)
>     at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readIterator(JavaBinUpdateRequestCodec.java:280)
>     at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:335)
>     at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:280)
>     at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readNamedList(JavaBinUpdateRequestCodec.java:235)
>     at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:300)
>     at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:280)
>     at 
> org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:193)
>     at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:126)
>     at 
> org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(JavabinLoader.java:123)
>     at 
> org.apache.solr.handler.loader.JavabinLoader.load(JavabinLoader.java:70)
>     at 
> org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:97)
>     at 
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68)
>     at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
>     at org.apache.solr.core.SolrCore.execute(SolrCore.java:2559)



--
This message was sent by Atlassian JIRA

[jira] [Commented] (LUCENE-7697) IndexSearcher should leverage index sorting

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-7697:
--

I am not, but [~jtibshirani] recently mentioned to me that she'd like to look 
into LUCENE-7714. There is LUCENE-8727 which is somewhat related too: some of 
the optimizations that we apply based on the minimum competitive score, and to 
a lesser extent index sorting, become less efficient when IndexSearcher is 
configured with an executor. This is due to the fact that these optimizations 
leverage information about already collected documents to more efficiently 
collect new documents. Since IndexSearcher searches each slice independently, a 
given slice can't benefit from information that has been collected in other 
slices.

> IndexSearcher should leverage index sorting
> ---
>
> Key: LUCENE-7697
> URL: https://issues.apache.org/jira/browse/LUCENE-7697
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
>
> We made good efforts in order to make index sorting fast and easy to 
> configure. We should now look into making IndexSearcher aware of it. This 
> will probably require changes of the API as not collecting all matches means 
> that we can no longer know things like the total number of hits or the 
> maximum score.
> I don't plan to work on it anytime soon, I'm just opening this issue to raise 
> awareness. I'd be happy to do reviews however if someone decides to tackle it.



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

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

[jira] [Commented] (LUCENE-8757) Better Segment To Thread Mapping Algorithm

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8757:
--

Yes. Top-docs collectors are expected to tie-break by doc ID in case documents 
compare equal. Things like TopDocs#merge compare doc IDs explicitly for that 
purpose, but Collector#collect implementations just rely on the fact that 
documents are collected in order to ignore documents that compare equal to the 
current k-th best hit. So we need to sort segments within a slice by docBase in 
order to get the same top hits regardless of how slices have been constructed.

> Better Segment To Thread Mapping Algorithm
> --
>
> Key: LUCENE-8757
> URL: https://issues.apache.org/jira/browse/LUCENE-8757
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Assignee: Simon Willnauer
>Priority: Major
> Attachments: LUCENE-8757.patch, LUCENE-8757.patch, LUCENE-8757.patch, 
> LUCENE-8757.patch
>
>
> The current segments to threads allocation algorithm always allocates one 
> thread per segment. This is detrimental to performance in case of skew in 
> segment sizes since small segments also get their dedicated thread. This can 
> lead to performance degradation due to context switching overheads.
>  
> A better algorithm which is cognizant of size skew would have better 
> performance for realistic scenarios



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

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

RE: [VOTE] Release Lucene/Solr 8.1.0 RC2

[Uwe Schindler]

Hi,

 

I did not notice that the vote already started. Here are Policeman’s result 
(Java 8/9):

 

SUCCESS! [2:45:20.607123]

 

Finished: SUCCESS

 

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

https://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Ishan Chattopadhyaya  
Sent: Sunday, May 12, 2019 6:49 PM
To: Lucene Dev 
Subject: Re: [VOTE] Release Lucene/Solr 8.1.0 RC2

 

The vote has passed. I'll release the artifacts shortly. Thanks to everyone who 
voted.

 

On Sun, 12 May, 2019, 12:21 PM Tomoko Uchida, mailto:tomoko.uchida.1...@gmail.com> > wrote:

+1
SUCCESS! [1:44:18.764013]

Tomoko

2019年5月12日(日) 13:28 Atri Sharma mailto:a...@linux.com> >:
>
> +1(Non Binding)
>
>  SUCCESS! [1:38:45.22756]
>
>
> On Sat, May 11, 2019 at 3:23 PM Jan Høydahl   > wrote:
> >
> > +1  SUCCESS! [1:29:54.577538]  (macOS, AdoptOpenJDK)
> >
> > --
> > Jan Høydahl, search solution architect
> > Cominvent AS - www.cominvent.com  
> >
> > 10. mai 2019 kl. 15:56 skrev Michael McCandless  >  >:
> >
> > +1
> >
> > SUCCESS! [0:50:14.775863]
> >
> > Mike McCandless
> >
> > http://blog.mikemccandless.com
> >
> >
> > On Thu, May 9, 2019 at 11:37 AM Ishan Chattopadhyaya 
> > mailto:ichattopadhy...@gmail.com> > wrote:
> >>
> >> Please vote for release candidate 2 for Lucene/Solr 8.1.0
> >>
> >> The artifacts can be downloaded from:
> >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.1.0-RC2-revdbe5ed0b2f17677ca6c904ebae919363f2d36a0a
> >>
> >> You can run the smoke tester directly with this command:
> >>
> >> python3 -u dev-tools/scripts/smokeTestRelease.py \
> >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.1.0-RC2-revdbe5ed0b2f17677ca6c904ebae919363f2d36a0a
> >>
> >> Here's my +1
> >> SUCCESS! [0:44:31.244021]
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> >>  
> >> For additional commands, e-mail: dev-h...@lucene.apache.org 
> >>  
> >>
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>  
> For additional commands, e-mail: dev-h...@lucene.apache.org 
>  
>

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

[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-11.0.2) - Build # 7938 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7938/
Java: 64bit/jdk-11.0.2 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth

Error Message:
Error from server at http://127.0.0.1:49466/solr/authCollection: Error from 
server at null: Expected mime type application/octet-stream but got text/html. 
   Error 401 require 
authentication  HTTP ERROR 401 Problem 
accessing /solr/authCollection_shard2_replica_n2/select. Reason: 
require authenticationhttp://eclipse.org/jetty;>Powered 
by Jetty:// 9.4.14.v20181114

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:49466/solr/authCollection: Error from server at 
null: Expected mime type application/octet-stream but got text/html. 


Error 401 require authentication

HTTP ERROR 401
Problem accessing /solr/authCollection_shard2_replica_n2/select. Reason:
require authenticationhttp://eclipse.org/jetty;>Powered by Jetty:// 9.4.14.v20181114




at 
__randomizedtesting.SeedInfo.seed([DCACB02A18238BE3:60C2C638BC700899]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:649)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1068)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:837)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:769)
at 
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:290)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 

[jira] [Comment Edited] (SOLR-13126) Multiplicative boost of isn't applied when one of the summed or multiplied queries doesn't match

[Thomas Zillinger (JIRA)]

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

Thomas Zillinger edited comment on SOLR-13126 at 5/13/19 6:37 AM:
--

[~janhoy] could this also be backported to Solr 7.3 - 7.5?


was (Author: tomzi):
[~janhoy] could this also be backported to Solr 7.5?

> Multiplicative boost of isn't applied when one of the summed or multiplied 
> queries doesn't match 
> -
>
> Key: SOLR-13126
> URL: https://issues.apache.org/jira/browse/SOLR-13126
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Affects Versions: 7.3, 7.4, 7.6, 7.7, 7.5.0, 7.7.1
> Environment: Reproduced with macOS 10.14.1, a quick test with Windows 
> 10 showed the same result.
>Reporter: Thomas Aglassinger
>Assignee: Alan Woodward
>Priority: Major
> Fix For: 7.7.2, 8.0
>
> Attachments: 
> 0001-use-deprecated-classes-to-fix-regression-introduced-.patch, 
> 0002-SOLR-13126-Added-test-case.patch, 2019-02-14_1715.png, SOLR-13126.patch, 
> SOLR-13126.patch, debugQuery.json, image-2019-02-13-16-17-56-272.png, 
> screenshot-1.png, solr_match_neither_nextteil_nor_sony.json, 
> solr_match_neither_nextteil_nor_sony.txt, solr_match_netzteil_and_sony.json, 
> solr_match_netzteil_and_sony.txt, solr_match_netzteil_only.json, 
> solr_match_netzteil_only.txt
>
>
> Under certain circumstances search results from queries with multiple 
> multiplicative boosts using the Solr functions {{product()}} and {{query()}} 
> result in a score that is inconsistent with the one from the debugQuery 
> information. Also only the debug score is correct while the actual search 
> results show a wrong score.
> This seems somewhat similar to the behaviour described in 
> https://issues.apache.org/jira/browse/LUCENE-7132, though this issue has been 
> resolved a while ago.
> A little background: we are using Solr as a search platform for the 
> e-commerce framework SAP Hybris. There the shop administrator can create 
> multiplicative boost rules (see below for an example) where a value like 2.0 
> means that an item gets boosted to 200%. This works fine in the demo shop 
> distributed by SAP but breaks in our shop. We encountered the issue when 
> Upgrading from Solr 7.2.1 / Hybris 6.7 to Solr 7.5 / Hybris 18.8.3 (which 
> would have been named Hybris 6.8 but the version naming schema changed).
> We reduced the Solr query generated by Hybris to the relevant parts and could 
> reproduce the issue in the Solr admin without any Hybris connection.
> I attached the JSON result of a test query but here's a description of the 
> parts that seemed most relevant to me.
> The {{responseHeader.params}} reads (slightly rearranged):
> {code:java}
> "q":"{!boost b=$ymb}(+{!lucene v=$yq})",
> "ymb":"product(query({!v=\"name_text_de\\:Netzteil\\^=2.0\"},1),query({!v=\"name_text_de\\:Sony\\^=3.0\"},1))",
> "yq":"*:*",
> "sort":"score desc",
> "debugQuery":"true",
> // Added to keep the output small but probably unrelated to the actual issue
> "fl":"score,id,code_string,name_text_de",
> "fq":"catalogId:\"someProducts\"",
> "rows":"10",
> {code}
> This example boosts the German product name (field {{name_text_de}}) in case 
> in contains certain terms:
>  * "Netzteil" (power supply) is boosted to 200%
>  * "Sony" is boosted to 300%
> Consequently a product containing both terms should be boosted to 600%.
> Also the query function has the value 1 specified as default in case the name 
> does not contain the respective term resulting in a pseudo boost that 
> preserves the score.
> According to the debug information the parser used is the LuceneQParser, 
> which translates this to the following parsed query:
> {quote}FunctionScoreQuery(FunctionScoreQuery(+*:*, scored by 
> boost(product(query((ConstantScore(name_text_de:netzteil))^2.0,def=1.0),query((ConstantScore(name_text_de:sony))^3.0,def=1.0)
> {quote}
> And the translated boost is:
> {quote}org.apache.lucene.queries.function.valuesource.ProductFloatFunction:product(query((ConstantScore(name_text_de:netzteil))^2.0,def=1.0),query((ConstantScore(name_text_de:sony))^3.0,def=1.0))
> {quote}
> When taking a look at the search result, among other the following products 
> are included (see the JSON comments for an analysis of each result):
> {code:javascript}
>  {
> "id":"someProducts/Online/test711",
> "name_text_de":"Original Sony Vaio Netzteil",
> "code_string":"test711",
> // CORRECT, both "Netzteil" and "Sony" are included in the name
> "score":6.0},
>   {
> "id":"someProducts/Online/taxTestingProductThree",
>  

[jira] [Commented] (SOLR-13126) Multiplicative boost of isn't applied when one of the summed or multiplied queries doesn't match

[Thomas Zillinger (JIRA)]

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

Thomas Zillinger commented on SOLR-13126:
-

[~janhoy] could this also be backported to Solr 7.5?

> Multiplicative boost of isn't applied when one of the summed or multiplied 
> queries doesn't match 
> -
>
> Key: SOLR-13126
> URL: https://issues.apache.org/jira/browse/SOLR-13126
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Affects Versions: 7.3, 7.4, 7.6, 7.7, 7.5.0, 7.7.1
> Environment: Reproduced with macOS 10.14.1, a quick test with Windows 
> 10 showed the same result.
>Reporter: Thomas Aglassinger
>Assignee: Alan Woodward
>Priority: Major
> Fix For: 7.7.2, 8.0
>
> Attachments: 
> 0001-use-deprecated-classes-to-fix-regression-introduced-.patch, 
> 0002-SOLR-13126-Added-test-case.patch, 2019-02-14_1715.png, SOLR-13126.patch, 
> SOLR-13126.patch, debugQuery.json, image-2019-02-13-16-17-56-272.png, 
> screenshot-1.png, solr_match_neither_nextteil_nor_sony.json, 
> solr_match_neither_nextteil_nor_sony.txt, solr_match_netzteil_and_sony.json, 
> solr_match_netzteil_and_sony.txt, solr_match_netzteil_only.json, 
> solr_match_netzteil_only.txt
>
>
> Under certain circumstances search results from queries with multiple 
> multiplicative boosts using the Solr functions {{product()}} and {{query()}} 
> result in a score that is inconsistent with the one from the debugQuery 
> information. Also only the debug score is correct while the actual search 
> results show a wrong score.
> This seems somewhat similar to the behaviour described in 
> https://issues.apache.org/jira/browse/LUCENE-7132, though this issue has been 
> resolved a while ago.
> A little background: we are using Solr as a search platform for the 
> e-commerce framework SAP Hybris. There the shop administrator can create 
> multiplicative boost rules (see below for an example) where a value like 2.0 
> means that an item gets boosted to 200%. This works fine in the demo shop 
> distributed by SAP but breaks in our shop. We encountered the issue when 
> Upgrading from Solr 7.2.1 / Hybris 6.7 to Solr 7.5 / Hybris 18.8.3 (which 
> would have been named Hybris 6.8 but the version naming schema changed).
> We reduced the Solr query generated by Hybris to the relevant parts and could 
> reproduce the issue in the Solr admin without any Hybris connection.
> I attached the JSON result of a test query but here's a description of the 
> parts that seemed most relevant to me.
> The {{responseHeader.params}} reads (slightly rearranged):
> {code:java}
> "q":"{!boost b=$ymb}(+{!lucene v=$yq})",
> "ymb":"product(query({!v=\"name_text_de\\:Netzteil\\^=2.0\"},1),query({!v=\"name_text_de\\:Sony\\^=3.0\"},1))",
> "yq":"*:*",
> "sort":"score desc",
> "debugQuery":"true",
> // Added to keep the output small but probably unrelated to the actual issue
> "fl":"score,id,code_string,name_text_de",
> "fq":"catalogId:\"someProducts\"",
> "rows":"10",
> {code}
> This example boosts the German product name (field {{name_text_de}}) in case 
> in contains certain terms:
>  * "Netzteil" (power supply) is boosted to 200%
>  * "Sony" is boosted to 300%
> Consequently a product containing both terms should be boosted to 600%.
> Also the query function has the value 1 specified as default in case the name 
> does not contain the respective term resulting in a pseudo boost that 
> preserves the score.
> According to the debug information the parser used is the LuceneQParser, 
> which translates this to the following parsed query:
> {quote}FunctionScoreQuery(FunctionScoreQuery(+*:*, scored by 
> boost(product(query((ConstantScore(name_text_de:netzteil))^2.0,def=1.0),query((ConstantScore(name_text_de:sony))^3.0,def=1.0)
> {quote}
> And the translated boost is:
> {quote}org.apache.lucene.queries.function.valuesource.ProductFloatFunction:product(query((ConstantScore(name_text_de:netzteil))^2.0,def=1.0),query((ConstantScore(name_text_de:sony))^3.0,def=1.0))
> {quote}
> When taking a look at the search result, among other the following products 
> are included (see the JSON comments for an analysis of each result):
> {code:javascript}
>  {
> "id":"someProducts/Online/test711",
> "name_text_de":"Original Sony Vaio Netzteil",
> "code_string":"test711",
> // CORRECT, both "Netzteil" and "Sony" are included in the name
> "score":6.0},
>   {
> "id":"someProducts/Online/taxTestingProductThree",
> "name_text_de":"Steuertestprodukt Zwei",
> "code_string":"taxTestingProductThree",
> // CORRECT, neither 

[jira] [Commented] (SOLR-13463) Solr admin user credentials defined with -Dbasicauth property during start is visible in admin UI to any user.

[Vinodh (JIRA)]

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

Vinodh commented on SOLR-13463:
---

Hi Jan,

 

I stored username and password in a file as *user:password* format and used 
"*-Dsolr.httpclient.config=*" property to defined the location of the file. But 
with this property, I'm getting below error while start solr nodes. Are you 
referring to this way of storing the password or anything else? Can you please 
also let me how to achieve what you had mentioned in your comment "we could 
also add a default redaction of basicauth property like we do for* password* " ?

 

Exception in thread "main" java.lang.ExceptionInInitializerError
    at org.apache.solr.util.SolrCLI.getHttpClient(SolrCLI.java:598)
    at org.apache.solr.util.SolrCLI$StatusTool.getStatus(SolrCLI.java:924)
    at org.apache.solr.util.SolrCLI$StatusTool.runImpl(SolrCLI.java:880)
    at org.apache.solr.util.SolrCLI$ToolBase.runTool(SolrCLI.java:177)
    at org.apache.solr.util.SolrCLI.main(SolrCLI.java:283)
Caused by: java.lang.IllegalArgumentException: username & password must be 
specified with 
org.apache.solr.client.solrj.impl.PreemptiveBasicAuthClientBuilderFactory
    at 
org.apache.solr.client.solrj.impl.PreemptiveBasicAuthClientBuilderFactory.initHttpClientBuilder(PreemptiveBasicAuthClientBuilderFactory.java:117)
    at 
org.apache.solr.client.solrj.impl.PreemptiveBasicAuthClientBuilderFactory.getHttpClientBuilder(PreemptiveBasicAuthClientBuilderFactory.java:109)
    at 
org.apache.solr.client.solrj.impl.HttpClientUtil.(HttpClientUtil.java:155)

> Solr admin user credentials defined with -Dbasicauth property during start is 
> visible in admin UI to any user.
> --
>
> Key: SOLR-13463
> URL: https://issues.apache.org/jira/browse/SOLR-13463
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 7.7.1
> Environment: QA
>Reporter: Vinodh
>Priority: Major
>  Labels: admin-interface, credentials
>
> We have configured Solr basic authentication in our environment and used 
> Dbasicauth property to define username:password. Since these property will be 
> added to Solr startup, the Solr admin username & password details defined 
> with -Dbasicauth property are displayed in plain text format to all users who 
> are able to login into admin UI interface in JVM & Java properties sections. 
> So even a read user who has privileges to login admin UI can able to see 
> admin user username & password details.



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