[jira] [Resolved] (LUCENE-8825) Improve Print Info Of CheckHits

[Adrien Grand (JIRA)]

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

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

> Improve Print Info Of CheckHits
> ---
>
> Key: LUCENE-8825
> URL: https://issues.apache.org/jira/browse/LUCENE-8825
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Minor
> Fix For: master (9.0), 8.2
>
> Attachments: LUCENE-8825.patch
>
>
> CheckHits should publish the shardIndex of the two involved ScoreDoc 
> instances when there is a mismatch. Since shardIndex can be involved in the 
> ordering of result ScoreDocs (due to it being considered during tie break 
> when no sort order is specified), this can be useful for understanding test 
> failures involving CheckHits.



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

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

[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 379 - Unstable

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.TestCloudConsistency.testOutOfSyncReplicasCannotBecomeLeader

Error Message:
Doc with id=4 not found in 
http://127.0.0.1:45957/solr/outOfSyncReplicasCannotBecomeLeader-false due to: 
Path not found: /id; rsp={doc=null}

Stack Trace:
java.lang.AssertionError: Doc with id=4 not found in 
http://127.0.0.1:45957/solr/outOfSyncReplicasCannotBecomeLeader-false due to: 
Path not found: /id; rsp={doc=null}
at 
__randomizedtesting.SeedInfo.seed([35970B71AC514204:4B7C2B616F364D3E]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.solr.cloud.TestCloudConsistency.assertDocExists(TestCloudConsistency.java:283)
at 
org.apache.solr.cloud.TestCloudConsistency.assertDocsExistInAllReplicas(TestCloudConsistency.java:267)
at 
org.apache.solr.cloud.TestCloudConsistency.testOutOfSyncReplicasCannotBecomeLeader(TestCloudConsistency.java:138)
at 
org.apache.solr.cloud.TestCloudConsistency.testOutOfSyncReplicasCannotBecomeLeader(TestCloudConsistency.java:97)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-8.x-Linux/69/
Java: 64bit/jdk-11.0.2 -XX:+UseCompressedOops -XX:+UseParallelGC

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([9AFD119AB41D62A6:12A92E401AE10F5E]: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 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 

[JENKINS] Lucene-Solr-8.1-Windows (64bit/jdk-10.0.1) - Build # 135 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.1-Windows/135/
Java: 64bit/jdk-10.0.1 -XX:-UseCompressedOops -XX:+UseG1GC

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

Error Message:
Expected metric minimums for prefix SECURITY./authentication.: 
{failMissingCredentials=2, authenticated=19, passThrough=9, 
failWrongCredentials=1, requests=31, errors=0}, but got: 
{failMissingCredentials=2, authenticated=17, passThrough=12, 
totalTime=11160401, failWrongCredentials=1, requestTimes=1157, requests=32, 
errors=0}

Stack Trace:
java.lang.AssertionError: Expected metric minimums for prefix 
SECURITY./authentication.: {failMissingCredentials=2, authenticated=19, 
passThrough=9, failWrongCredentials=1, requests=31, errors=0}, but got: 
{failMissingCredentials=2, authenticated=17, passThrough=12, 
totalTime=11160401, failWrongCredentials=1, requestTimes=1157, requests=32, 
errors=0}
at 
__randomizedtesting.SeedInfo.seed([663CF2625AE79511:DA528470FEB4166B]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.solr.cloud.SolrCloudAuthTestCase.assertAuthMetricsMinimums(SolrCloudAuthTestCase.java:129)
at 
org.apache.solr.cloud.SolrCloudAuthTestCase.assertAuthMetricsMinimums(SolrCloudAuthTestCase.java:83)
at 
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:306)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 

[jira] [Commented] (SOLR-13530) Control requests to Solr based on the core size

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-13530:
--

I understand that the scope of this issue is somewhat different, but there's an 
already existing mechanism which may be used to mitigate such situations before 
they happen - {{IndexSizeTrigger}} can automatically execute {{SPLITSHARD}} 
when a replica grows beyond a specified threshold, expressed either as a number 
of bytes or a number of docs.

> Control requests to Solr based on the core size
> ---
>
> Key: SOLR-13530
> URL: https://issues.apache.org/jira/browse/SOLR-13530
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Anshum Gupta
>Priority: Major
>
> Large cores are almost always problematic. They show up as increased 
> replication times, recovery times, and much more. They also often are 
> attempted to be handled by using a larger heap, which is also almost always 
> an even bigger problem.
> We should be able to reject requests or at least log/notify when Solr core 
> grows beyond a specific threshold.



--
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-13512) Raw index data analysis tool

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-13512:
--

This is the output of {{Accountable.ramBytesUsed()}} which _should_ represent 
how much heap a given Accountable consumes. Whether it's useful in case of 
these low-level components remains to be seen - I suspect it does NOT represent 
the amount of MMap-ed memory, just the POJOs that totally reside in heap.

Anyway, this section is not affected by this issue, look for the {{rawSize}} 
section instead.

> Raw index data analysis tool
> 
>
> Key: SOLR-13512
> URL: https://issues.apache.org/jira/browse/SOLR-13512
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13512.patch, SOLR-13512.patch, SOLR-13512.patch, 
> SOLR-13512.patch, rawSizeDetails.json, rawSizeSummary.json
>
>
> A common question from Solr users is how to determine how a given schema 
> field and all its related index data contributes to the total index size.
> It's possible to estimate this information by doing a single full pass 
> through all index data, aggregating estimated sizes of terms, postings, doc 
> values and stored fields. The totals represent of course the worst case 
> scenario when there's no index compression at all, but still they should be 
> useful for answering the questions above.



--
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-8841) Explore Relevance Based Performance Benchmarks

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8841:
--

It used to be an Apache project. :) (Lucene subproject actually) 
https://lucene.apache.org/openrelevance/

> Explore Relevance Based Performance Benchmarks
> --
>
> Key: LUCENE-8841
> URL: https://issues.apache.org/jira/browse/LUCENE-8841
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Major
>
> While discussing improvements in relevance of fuzzy queries with [~jimczi], 
> the topic of how to measure impact of changes to relevance of common queries 
> came up. While a non trivial effort, having such a benchmark will allow us to 
> measure the impact of potential changes and also catch regressions well in 
> time.
>  
> This Jira tracks ideas and efforts in that direction



--
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-8841) Explore Relevance Based Performance Benchmarks

[Doug Turnbull (JIRA)]

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

Doug Turnbull commented on LUCENE-8841:
---

Big +1, though I suspect it would be very hard! This could be an Apache project 
in and of itself...

One challenge is that the number of use cases Lucene is used is tremendously 
diverse, from job search, to e-commerce, to legal search, to enterprise search, 
to news search, to Web search, to everything in between and outside the box. 
You wouldn't want a situation, for example, where you only have an e-commerce 
test set, so you end up creating a situation where Enterprise search users are 
harmed because of decisions made optimizing an e-commerce set. 

Another challenge is getting reliable relevance judgments. Teams go deep into 
developing their methodology for creating a golden set of judgments. This of 
course can be very domain specific and challenging problem. There's not a 
one-size-fits-all obvious approach. Some teams use human judges, others crowd 
source, others very analytics based. Some have access to conversion data, 
others don't. You have all sorts of biases to contend with in every situation. 
And the judgments evolve over time. (today's most relevant iPhone isn't the 
same as 2 years ago). So getting it right takes a lot of energy and time from 
mature search orgs. So what judgments/data you choose isn't clear if you want 
to cover a broad range of use cases.

I think the best case is to partner with some organizations that are willing to 
open up this data alongside their corpus. Where we could validate and feel good 
about the methodology they use in generating judgments. You'd need to update 
the relevance judgments and corpus over time. There's of course TREC and other 
academic datasets, that's one data point. Some folks I know at Wikipedia have 
talked about this. But you'd want some more commercial datasets (corpus + 
judgments).

But partnering with orgs would also have limits, as this stuff has very 
high-value to companies... But perhaps they'd be incentivized to open up their 
data if Lucene was going to make decisions with it that helped them?!?

 

> Explore Relevance Based Performance Benchmarks
> --
>
> Key: LUCENE-8841
> URL: https://issues.apache.org/jira/browse/LUCENE-8841
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Major
>
> While discussing improvements in relevance of fuzzy queries with [~jimczi], 
> the topic of how to measure impact of changes to relevance of common queries 
> came up. While a non trivial effort, having such a benchmark will allow us to 
> measure the impact of potential changes and also catch regressions well in 
> time.
>  
> This Jira tracks ideas and efforts in that direction



--
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 (64bit/jdk1.8.0_201) - Build # 399 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.1-Linux/399/
Java: 64bit/jdk1.8.0_201 -XX:+UseCompressedOops -XX:+UseG1GC

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

Error Message:
Expected metric minimums for prefix SECURITY./authentication.: 
{failMissingCredentials=2, authenticated=19, passThrough=9, 
failWrongCredentials=1, requests=31, errors=0}, but got: 
{failMissingCredentials=2, authenticated=16, passThrough=10, 
totalTime=16457823, failWrongCredentials=1, requestTimes=1015, requests=29, 
errors=0}

Stack Trace:
java.lang.AssertionError: Expected metric minimums for prefix 
SECURITY./authentication.: {failMissingCredentials=2, authenticated=19, 
passThrough=9, failWrongCredentials=1, requests=31, errors=0}, but got: 
{failMissingCredentials=2, authenticated=16, passThrough=10, 
totalTime=16457823, failWrongCredentials=1, requestTimes=1015, requests=29, 
errors=0}
at 
__randomizedtesting.SeedInfo.seed([2FBC459FD92BF34D:93D2338D7D787037]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.solr.cloud.SolrCloudAuthTestCase.assertAuthMetricsMinimums(SolrCloudAuthTestCase.java:129)
at 
org.apache.solr.cloud.SolrCloudAuthTestCase.assertAuthMetricsMinimums(SolrCloudAuthTestCase.java:83)
at 
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:306)
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 

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

[Policeman Jenkins Server]

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

10 tests failed.
FAILED:  org.apache.lucene.search.TestFieldCacheRewriteMethod.testRegexps

Error Message:
Hit 24 docnumbers don't match Hits length1=25 length2=25 hit=0: doc12=1.0 
shardIndex=0,  doc12=1.0 shardIndex=0 hit=1: doc14=1.0 shardIndex=0,  doc14=1.0 
shardIndex=0 hit=2: doc17=1.0 shardIndex=0,  doc17=1.0 shardIndex=0 hit=3: 
doc35=1.0 shardIndex=0,  doc35=1.0 shardIndex=0 hit=4: doc43=1.0 shardIndex=0,  
doc43=1.0 shardIndex=0 hit=5: doc64=1.0 shardIndex=0,  doc64=1.0 shardIndex=0 
hit=6: doc68=1.0 shardIndex=0,  doc68=1.0 shardIndex=0 hit=7: doc87=1.0 
shardIndex=0,  doc87=1.0 shardIndex=0 hit=8: doc88=1.0 shardIndex=0,  doc88=1.0 
shardIndex=0 hit=9: doc98=1.0 shardIndex=0,  doc98=1.0 shardIndex=0 hit=10: 
doc112=1.0 shardIndex=0,  doc112=1.0 shardIndex=0 hit=11: doc125=1.0 
shardIndex=0,  doc125=1.0 shardIndex=0 hit=12: doc126=1.0 shardIndex=0,  
doc126=1.0 shardIndex=0 hit=13: doc164=1.0 shardIndex=0,  doc164=1.0 
shardIndex=0 hit=14: doc187=1.0 shardIndex=0,  doc187=1.0 shardIndex=0 hit=15: 
doc260=1.0 shardIndex=0,  doc260=1.0 shardIndex=0 hit=16: doc325=1.0 
shardIndex=0,  doc325=1.0 shardIndex=0 hit=17: doc330=1.0 shardIndex=0,  
doc330=1.0 shardIndex=0 hit=18: doc333=1.0 shardIndex=0,  doc333=1.0 
shardIndex=0 hit=19: doc337=1.0 shardIndex=0,  doc337=1.0 shardIndex=0 hit=20: 
doc370=1.0 shardIndex=0,  doc370=1.0 shardIndex=0 hit=21: doc395=1.0 
shardIndex=0,  doc395=1.0 shardIndex=0 hit=22: doc407=1.0 shardIndex=0,  
doc407=1.0 shardIndex=0 hit=23: doc439=1.0 shardIndex=0,  doc439=1.0 
shardIndex=0 hit=24: doc553=1.0 shardIndex=0,  doc497=1.0 shardIndex=0 for 
query:field:/|?../

Stack Trace:
junit.framework.AssertionFailedError: Hit 24 docnumbers don't match
Hits length1=25 length2=25
hit=0: doc12=1.0 shardIndex=0,   doc12=1.0 shardIndex=0
hit=1: doc14=1.0 shardIndex=0,   doc14=1.0 shardIndex=0
hit=2: doc17=1.0 shardIndex=0,   doc17=1.0 shardIndex=0
hit=3: doc35=1.0 shardIndex=0,   doc35=1.0 shardIndex=0
hit=4: doc43=1.0 shardIndex=0,   doc43=1.0 shardIndex=0
hit=5: doc64=1.0 shardIndex=0,   doc64=1.0 shardIndex=0
hit=6: doc68=1.0 shardIndex=0,   doc68=1.0 shardIndex=0
hit=7: doc87=1.0 shardIndex=0,   doc87=1.0 shardIndex=0
hit=8: doc88=1.0 shardIndex=0,   doc88=1.0 shardIndex=0
hit=9: doc98=1.0 shardIndex=0,   doc98=1.0 shardIndex=0
hit=10: doc112=1.0 shardIndex=0, doc112=1.0 shardIndex=0
hit=11: doc125=1.0 shardIndex=0, doc125=1.0 shardIndex=0
hit=12: doc126=1.0 shardIndex=0, doc126=1.0 shardIndex=0
hit=13: doc164=1.0 shardIndex=0, doc164=1.0 shardIndex=0
hit=14: doc187=1.0 shardIndex=0, doc187=1.0 shardIndex=0
hit=15: doc260=1.0 shardIndex=0, doc260=1.0 shardIndex=0
hit=16: doc325=1.0 shardIndex=0, doc325=1.0 shardIndex=0
hit=17: doc330=1.0 shardIndex=0, doc330=1.0 shardIndex=0
hit=18: doc333=1.0 shardIndex=0, doc333=1.0 shardIndex=0
hit=19: doc337=1.0 shardIndex=0, doc337=1.0 shardIndex=0
hit=20: doc370=1.0 shardIndex=0, doc370=1.0 shardIndex=0
hit=21: doc395=1.0 shardIndex=0, doc395=1.0 shardIndex=0
hit=22: doc407=1.0 shardIndex=0, doc407=1.0 shardIndex=0
hit=23: doc439=1.0 shardIndex=0, doc439=1.0 shardIndex=0
hit=24: doc553=1.0 shardIndex=0, doc497=1.0 shardIndex=0
for query:field:/|?../
at 
__randomizedtesting.SeedInfo.seed([A993DB1E59F6C2DC:48CF9A0F875C9554]:0)
at junit.framework.Assert.fail(Assert.java:57)
at org.apache.lucene.search.CheckHits.checkEqual(CheckHits.java:205)
at 
org.apache.lucene.search.TestFieldCacheRewriteMethod.assertSame(TestFieldCacheRewriteMethod.java:42)
at 
org.apache.lucene.search.TestRegexpRandom2.testRegexps(TestRegexpRandom2.java:164)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 

[JENKINS] Lucene-Solr-8.1-Linux (64bit/jdk-12) - Build # 401 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.1-Linux/401/
Java: 64bit/jdk-12 -XX:+UseCompressedOops -XX:+UseG1GC

11 tests failed.
FAILED:  org.apache.solr.search.MergeStrategyTest.test

Error Message:
Error from server at http://127.0.0.1:45417/kj/er/collection1: 
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://[ff01::083]:2/kj/er/select

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:45417/kj/er/collection1: 
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://[ff01::083]:2/kj/er/select
at 
__randomizedtesting.SeedInfo.seed([F90820185A520440:715C1FC2F4AE69B8]: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.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.BaseDistributedSearchTestCase.queryServer(BaseDistributedSearchTestCase.java:626)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:678)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:656)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:635)
at 
org.apache.solr.search.MergeStrategyTest.test(MergeStrategyTest.java:79)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
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 

[GitHub] [lucene-solr] janhoy commented on issue #635: SOLR-13371 improve security chapters in refguide

[GitBox]

janhoy commented on issue #635: SOLR-13371 improve security chapters in refguide
URL: https://github.com/apache/lucene-solr/pull/635#issuecomment-500159196
 
 
   I pushed a commit that I think addresses all of your comments above 
(c600f7ae9ce950dfee659eefe74a5c5df409be0a). Feel free to merge or I can merge 
if there are no further comments.


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: Lucene / Solr Gradle Build Update

[Dawid Weiss]

> [...] but it will likely take me another 2-4 before I plan on having 
> something I'd considered ready for prime time 9x duties.

I'd say aim at integrating it sooner than later. I think everyone
realizes switching a build system isn't a minor deal; I'd expect some
things to not work right away. And even if something doesn't work,
there may be more hands willing to help out if it's a particular
person's itch. ;)

Gradle is a powerful toy and I personally find it fun to work with,
even if it drives me crazy sometimes when I can't figure out why
something doesn't work the way I think it should. :)

Dawid

On Sat, Jun 8, 2019 at 12:59 AM Mark Miller  wrote:
>
> Since I have heard no objection, I've continued working on moving the project 
> from ant+ivy+maven to gradle.
>
> At this point I've contributed significant time to this project. I hope 
> everyone has taken the time to consider this change and their possible 
> concerns. I don't want to beat a dead horse, but there is too much effort 
> involved to get caught up at the end.
>
> There is still a lot to do, it's not going to happen tomorrow, but many, many 
> things are done.
>
> The performance of the build in comparison to what we had will astonish you 
> on good hardware.
>
> Even comparing to your experience with the majority of maven builds, this 
> will be *significantly* faster. This is without using the gradle build cache 
> or paying proper attention to task uptodate properties.
>
> There are considerable improvements and benefits we can reap from this 
> change, but the sheer speed has made the development experience for me way 
> more enjoyable.
>
> My goal is to take us from a very powerful but complicated and slow and 
> clunky and dense build to what is essentially a modern top tier build 
> experience in power, performance, integrity and ease of use.
>
> I've made significant progress over the past month or so, but it will likely 
> take me another 2-4 before I plan on having something I'd considered ready 
> for prime time 9x duties.
>
> I'll take the time needed to get things right, hopefully everyone else will 
> take the time to help with a transition when that time comes.
>
> My hope is that version 9 is the first built with gradle. We can consider it 
> being available on 8 as well, but I don't think it makes sense to release 8x 
> versions with gradle. I think we should only consider the gradle build on 8x 
> as a developer convenience and it would be on the users of it to address 
> keeping it up to date with changes on the ant build as problems arise. 
> Depending on the time, it may not even make sense to put effort here.
>
> This weekend I'm wrapping up some work on making our dependency management 
> headache more transparent. I think we can make a lot of improvements on 
> understanding what is in our build and why and what is published or shipped 
> where and why.
>
> --
> - Mark
>
> http://about.me/markrmiller

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

Re: Github PRs without attached JIRA issue

[Jan Høydahl]

Jira has become very heavy-weight over the years and I'm not sure we need all 
those features.
I think Github issues are a bit too lightweight perhaps, so I'm not actively 
promoting option E, just lifting it up as a real alternative.

> As an example how would you implement the security issue visibility with 
> original poster and PMC able to see it in github?

Think they have something in the makings for this, see 
https://github.com/apache/lucene-solr/security/policy 
Have no idea if you can limit the group who sees them to PMC members though.

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

Re: [jira] [Commented] (SOLR-13131) Category Routed Aliases

[Gus Heck]

Ah yes I had meant to fix this. It's from when I was misunderstanding how
changes was meant to be updated... will do

On Sat, Jun 8, 2019 at 12:18 AM Cassandra Targett (JIRA) 
wrote:

>
> [
> https://issues.apache.org/jira/browse/SOLR-13131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859100#comment-16859100
> ]
>
> Cassandra Targett commented on SOLR-13131:
> --
>
> [~gus_heck] - CHANGES.txt includes this issue under 9.0, but this issue
> says it's fixed in 8.1 (and the docs are in 8.1). Was the CHANGES entry
> perhaps put in the wrong place?
>
> See https://github.com/apache/lucene-solr/blob/master/solr/CHANGES.txt#L56
>
> > Category Routed Aliases
> > ---
> >
> > Key: SOLR-13131
> > URL: https://issues.apache.org/jira/browse/SOLR-13131
> > Project: Solr
> >  Issue Type: Improvement
> >  Security Level: Public(Default Security Level. Issues are Public)
> >  Components: SolrCloud
> >Affects Versions: master (9.0)
> >Reporter: Gus Heck
> >Assignee: Gus Heck
> >Priority: Major
> > Fix For: 8.1, master (9.0)
> >
> > Attachments: indexingWithCRA.png, indexingwithoutCRA.png,
> indexintWithoutCRA2.png
> >
> >
> > This ticket is to add a second type of routed alias in addition to the
> current time routed aliases. The new type of alias will allow data driven
> creation of collections based on the values of a field and automated
> organization of these collections under an alias that allows the
> collections to also be searched as a whole.
> > The use case in mind at present is an IOT device type segregation, but I
> could also see this leading to the ability to direct updates to tenant
> specific hardware (in cooperation with autoscaling).
> > This ticket also looks forward to (but does not include) the creation of
> a Dimensionally Routed Alias which would allow organizing time routed data
> also segregated by device
> > Further design details to be added in comments.
> >
>
>
>
> --
> 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: Lucene / Solr Gradle Build Update

[Gus Heck]

Also looking forward to it. :) especially if it speeds things up. Moving
forward with it in 9x and not 8 sounds good to me. There are folks out
there who build themselves custom builds of Solr, so build changes this big
seem like a sort of back compatability concern, though obviously only for a
minority.

On Fri, Jun 7, 2019 at 11:05 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> Looking forward to it, and thanks a lot for your effort. Excited!
>
> On Sat, 8 Jun, 2019, 4:29 AM Mark Miller,  wrote:
>
>> Since I have heard no objection, I've continued working on moving the
>> project from ant+ivy+maven to gradle.
>>
>> At this point I've contributed significant time to this project. I hope
>> everyone has taken the time to consider this change and their possible
>> concerns. I don't want to beat a dead horse, but there is too much effort
>> involved to get caught up at the end.
>>
>> There is still a lot to do, it's not going to happen tomorrow, but many,
>> many things are done.
>>
>> The performance of the build in comparison to what we had will astonish
>> you on good hardware.
>>
>> Even comparing to your experience with the majority of maven builds, this
>> will be *significantly* faster. This is without using the gradle build
>> cache or paying proper attention to task uptodate properties.
>>
>> There are considerable improvements and benefits we can reap from this
>> change, but the sheer speed has made the development experience for me way
>> more enjoyable.
>>
>> My goal is to take us from a very powerful but complicated and slow and
>> clunky and dense build to what is essentially a modern top tier build
>> experience in power, performance, integrity and ease of use.
>>
>> I've made significant progress over the past month or so, but it will
>> likely take me another 2-4 before I plan on having something I'd considered
>> ready for prime time 9x duties.
>>
>> I'll take the time needed to get things right, hopefully everyone else
>> will take the time to help with a transition when that time comes.
>>
>> My hope is that version 9 is the first built with gradle. We can consider
>> it being available on 8 as well, but I don't think it makes sense to
>> release 8x versions with gradle. I think we should only consider the gradle
>> build on 8x as a developer convenience and it would be on the users of it
>> to address keeping it up to date with changes on the ant build as problems
>> arise. Depending on the time, it may not even make sense to put effort here.
>>
>> This weekend I'm wrapping up some work on making our dependency
>> management headache more transparent. I think we can make a lot of
>> improvements on understanding what is in our build and why and what is
>> published or shipped where and why.
>>
>> --
>> - Mark
>>
>> http://about.me/markrmiller
>>
>

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

[jira] [Updated] (SOLR-13523) Atomic Update results in NullPointerException

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski updated SOLR-13523:
---
Attachment: reproduce.sh

> Atomic Update results in NullPointerException
> -
>
> Key: SOLR-13523
> URL: https://issues.apache.org/jira/browse/SOLR-13523
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: JSON Request API, update
>Affects Versions: 8.0
> Environment: * Operating system: Win10 v1803 build 17143.766
>  * Java version:
> java 11.0.1 2018-10-16 LTS
> Java(TM) SE Runtime Environment 18.9 (build 11.0.1+13-LTS)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.1+13-LTS, mixed mode)
>  * solr-spec: 8.1.1
>  * solr-impl: 8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef - ab - 
> 2019-05-22 15:20:01
>  * lucene-spec: 8.1.1
>  * lucene-impl: 8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef - ab - 
> 2019-05-22 15:15:24
>Reporter: Kieran Devlin
>Priority: Major
> Attachments: XUBrk.png, Xn1RW.png, reproduce.sh
>
>
> Partially update a document via an atomic update, when I do so, the web sever 
> responds with a 500 status with the stack trace:
> {code:java}
> { "responseHeader":{ "status":500, "QTime":1}, "error":{ 
> "trace":"java.lang.NullPointerException\r\n\tat 
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.getFieldFromHierarchy(AtomicUpdateDocumentMerger.java:301)\r\n\tat
>  
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.mergeChildDoc(AtomicUpdateDocumentMerger.java:398)\r\n\tat
>  
> org.apache.solr.update.processor.DistributedUpdateProcessor.getUpdatedDocument(DistributedUpdateProcessor.java:697)\r\n\tat
>  
> org.apache.solr.update.processor.DistributedUpdateProcessor.doVersionAdd(DistributedUpdateProcessor.java:372)\r\n\tat
>  
> org.apache.solr.update.processor.DistributedUpdateProcessor.lambda$versionAdd$0(DistributedUpdateProcessor.java:337)\r\n\tat
>  
> org.apache.solr.update.VersionBucket.runWithLock(VersionBucket.java:50)\r\n\tat
>  
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:337)\r\n\tat
>  
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:223)\r\n\tat
>  
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)\r\n\tat
>  
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>  
> org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactory$AddSchemaFieldsUpdateProcessor.processAdd(AddSchemaFieldsUpdateProcessorFactory.java:475)\r\n\tat
>  
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>  
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>  
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>  
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>  
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>  
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>  
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>  
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>  
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>  
> org.apache.solr.update.processor.FieldNameMutatingUpdateProcessorFactory$1.processAdd(FieldNameMutatingUpdateProcessorFactory.java:75)\r\n\tat
>  
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>  
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>  
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>  
> org.apache.solr.update.processor.AbstractDefaultValueUpdateProcessorFactory$DefaultValueUpdateProcessor.processAdd(AbstractDefaultValueUpdateProcessorFactory.java:92)\r\n\tat
>  
> org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.handleAdds(JsonLoader.java:507)\r\n\tat
>  
> org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.processUpdate(JsonLoader.java:145)\r\n\tat
>  
> org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.load(JsonLoader.java:121)\r\n\tat
>  

[jira] [Commented] (SOLR-13523) Atomic Update results in NullPointerException

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski commented on SOLR-13523:


I noticed this yesterday and just saw this JIRA open for it.  I attached a 
script I've been using to reproduce it.  Just drop that in the root of your 
source checkout and run {{./reproduce.sh}} to trigger the bug.

I ran a git-bisect on {{master}} to figure out what might've caused this, and 
the first failing commit was:

{code}
➜  lucene-solr git:(8527ec11af8) ✗ git bisect bad 8527ec11af8
8527ec11af8099f86953ffad1182ad43c752f95b is the first bad commit
commit 8527ec11af8099f86953ffad1182ad43c752f95b
Author: Moshe 
Date:   Wed Apr 10 03:02:59 2019 -0400

SOLR-12638: Partial/Atomic updates of nested docs.
and [child] now works in RTG.

{code}

Tagging [~moshebla] and [~dsmiley], since they worked on that ticket.  Does 
this error message look familiar to either of you guys?  The NPE occurs on the 
first line of this method in AtomicUpdateDocumentMerger.

{code}
  /**
   *
   * @param completeHierarchy SolrInputDocument that represents the nested 
document hierarchy from its root
   * @param fieldPath the path to fetch, seperated by a '/' e.g. 
/children/grandChildren
   * @return the SolrInputField of fieldPath
   */
  public static SolrInputField getFieldFromHierarchy(SolrInputDocument 
completeHierarchy, String fieldPath) {
// substr to remove first '/'
final List docPaths = StrUtils.splitSmart(fieldPath.substring(1), 
'/');
Pair subPath;
SolrInputField sifToReplace = null;
SolrInputDocument currDoc = completeHierarchy;
for (String subPathString: docPaths) {
  subPath = getPathAndIndexFromNestPath(subPathString);
  sifToReplace = currDoc.getField(subPath.getLeft());
  currDoc = (SolrInputDocument) 
((List)sifToReplace.getValues()).get(subPath.getRight());
}
return sifToReplace;
  }
{code}

> Atomic Update results in NullPointerException
> -
>
> Key: SOLR-13523
> URL: https://issues.apache.org/jira/browse/SOLR-13523
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: JSON Request API, update
>Affects Versions: 8.0
> Environment: * Operating system: Win10 v1803 build 17143.766
>  * Java version:
> java 11.0.1 2018-10-16 LTS
> Java(TM) SE Runtime Environment 18.9 (build 11.0.1+13-LTS)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.1+13-LTS, mixed mode)
>  * solr-spec: 8.1.1
>  * solr-impl: 8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef - ab - 
> 2019-05-22 15:20:01
>  * lucene-spec: 8.1.1
>  * lucene-impl: 8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef - ab - 
> 2019-05-22 15:15:24
>Reporter: Kieran Devlin
>Priority: Major
> Attachments: XUBrk.png, Xn1RW.png, reproduce.sh
>
>
> Partially update a document via an atomic update, when I do so, the web sever 
> responds with a 500 status with the stack trace:
> {code:java}
> { "responseHeader":{ "status":500, "QTime":1}, "error":{ 
> "trace":"java.lang.NullPointerException\r\n\tat 
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.getFieldFromHierarchy(AtomicUpdateDocumentMerger.java:301)\r\n\tat
>  
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.mergeChildDoc(AtomicUpdateDocumentMerger.java:398)\r\n\tat
>  
> org.apache.solr.update.processor.DistributedUpdateProcessor.getUpdatedDocument(DistributedUpdateProcessor.java:697)\r\n\tat
>  
> org.apache.solr.update.processor.DistributedUpdateProcessor.doVersionAdd(DistributedUpdateProcessor.java:372)\r\n\tat
>  
> org.apache.solr.update.processor.DistributedUpdateProcessor.lambda$versionAdd$0(DistributedUpdateProcessor.java:337)\r\n\tat
>  
> org.apache.solr.update.VersionBucket.runWithLock(VersionBucket.java:50)\r\n\tat
>  
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:337)\r\n\tat
>  
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:223)\r\n\tat
>  
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)\r\n\tat
>  
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>  
> org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactory$AddSchemaFieldsUpdateProcessor.processAdd(AddSchemaFieldsUpdateProcessorFactory.java:475)\r\n\tat
>  
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>  
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>  
> 

[JENKINS] Lucene-Solr-8.1-Linux (64bit/jdk1.8.0_201) - Build # 400 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.1-Linux/400/
Java: 64bit/jdk1.8.0_201 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

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

Error Message:
Expected metric minimums for prefix SECURITY./authentication.: 
{failMissingCredentials=2, authenticated=19, passThrough=9, 
failWrongCredentials=1, requests=31, errors=0}, but got: 
{failMissingCredentials=2, authenticated=16, passThrough=10, 
totalTime=13819002, failWrongCredentials=1, requestTimes=1354, requests=29, 
errors=0}

Stack Trace:
java.lang.AssertionError: Expected metric minimums for prefix 
SECURITY./authentication.: {failMissingCredentials=2, authenticated=19, 
passThrough=9, failWrongCredentials=1, requests=31, errors=0}, but got: 
{failMissingCredentials=2, authenticated=16, passThrough=10, 
totalTime=13819002, failWrongCredentials=1, requestTimes=1354, requests=29, 
errors=0}
at 
__randomizedtesting.SeedInfo.seed([55047D349EDAA22F:E96A0B263A892155]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.solr.cloud.SolrCloudAuthTestCase.assertAuthMetricsMinimums(SolrCloudAuthTestCase.java:129)
at 
org.apache.solr.cloud.SolrCloudAuthTestCase.assertAuthMetricsMinimums(SolrCloudAuthTestCase.java:83)
at 
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:306)
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 

[GitHub] [lucene-solr] jasontedor commented on issue #706: Only ignore IOException on dirs when invoking force

[GitBox]

jasontedor commented on issue #706: Only ignore IOException on dirs when 
invoking force
URL: https://github.com/apache/lucene-solr/pull/706#issuecomment-500131845
 
 
   The associated issue is 
[LUCENE-8843](https://issues.apache.org/jira/projects/LUCENE/issues/LUCENE-8843).
 


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: [jira] [Commented] (LUCENE-8791) Add CollectorRescorer

[Michael Sokolov]

I think this is the same pro-rated idea from LUCENE-8681; when the
documents are randomly distributed among segments, the prediction can
be quite accurate. In the case of a time series index though (eg, or
any index where the distribution among segments is correlated with the
rank), then this approach to early termination is not directly
applicable.

On Fri, Jun 7, 2019 at 4:27 AM Adrien Grand (JIRA)  wrote:
>
>
> [ 
> https://issues.apache.org/jira/browse/LUCENE-8791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858391#comment-16858391
>  ]
>
> Adrien Grand commented on LUCENE-8791:
> --
>
> My concern is that we are introducing complexity for a use-case that seems to 
> be collecting a number of hits in the first pass that is above what I would 
> consider reasonable. I understand why you might want to set an executor 
> service on an IndexSearcher since it needs to do work over potentially 
> millions of hits. However, the order of magnitude of the number of documents 
> that I'm expecting rescoring to have to look at is more in the order of 
> hundreds and should run in a few milliseconds only already with a single 
> thread.
>
> That concern aside, I'm supportive of the ability of rescoring hits based on 
> a collector, which adds flexibility compared to what you can do with a query 
> rescorer. I won't veto this change, but could we make the single-threaded 
> constructor take a Collector rather than a CollectorManager and document that 
> the one that takes an ExecutorService is expert and usually doesn't help 
> significantly?
>
> bq. We distribute total number of results we are looking from matching across 
> segments evenly plus some static number for overhead
>
> This way of working would be a nice enhancement to IndexSearcher when 
> constructed with an ExecutorService! Do you just accept the decrease of 
> precision if one slice didn't collect enough hits, or do you re-run the 
> search on this slice with a greater number of hits?
>
> > 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, 
> > 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
>

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

[jira] [Commented] (LUCENE-8841) Explore Relevance Based Performance Benchmarks

[Atri Sharma (JIRA)]

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

Atri Sharma commented on LUCENE-8841:
-

Could we consider resurrecting it then?
-- 
Regards,

Atri
*l'apprenant*


> Explore Relevance Based Performance Benchmarks
> --
>
> Key: LUCENE-8841
> URL: https://issues.apache.org/jira/browse/LUCENE-8841
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Major
>
> While discussing improvements in relevance of fuzzy queries with [~jimczi], 
> the topic of how to measure impact of changes to relevance of common queries 
> came up. While a non trivial effort, having such a benchmark will allow us to 
> measure the impact of potential changes and also catch regressions well in 
> time.
>  
> This Jira tracks ideas and efforts in that direction



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

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

[jira] [Assigned] (LUCENE-8812) add KoreanNumberFilter to Nori(Korean) Analyzer

[Namgyu Kim (JIRA)]

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

Namgyu Kim reassigned LUCENE-8812:
--

Assignee: Namgyu Kim

> add KoreanNumberFilter to Nori(Korean) Analyzer
> ---
>
> Key: LUCENE-8812
> URL: https://issues.apache.org/jira/browse/LUCENE-8812
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Namgyu Kim
>Assignee: Namgyu Kim
>Priority: Major
> Attachments: LUCENE-8812.patch
>
>
> This is a follow-up issue to LUCENE-8784.
> The KoreanNumberFilter is a TokenFilter that normalizes Korean numbers to 
> regular Arabic decimal numbers in half-width characters.
> Logic is similar to JapaneseNumberFilter.
> It should be able to cover the following test cases.
> 1) Korean Word to Number
> 십만이천오백 => 102500
> 2) 1 character conversion
> 일영영영 => 1000
> 3) Decimal Point Calculation
> 3.2천 => 3200
> 4) Comma between three digits
> 4,647.0010 => 4647.001



--
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: Github PRs without attached JIRA issue

[Gus Heck]

I created an infra "wish" that relates somewhat to this as well...
https://issues.apache.org/jira/browse/INFRA-18518   I also don't like D.
There definitely needs to be only one place to search for issues. I don't
like E either, while convenient from github their issue system has way
fewer features, and I suspect even if we can port issues to it to keep the
"one place" that will be lossy. As an example how would you implement the
security issue visibility with original poster and PMC able to see it in
github? I don't think they have a notion of roles/access control that is
comparable. (or I'm simply unaware of it)

-Gus

On Fri, Jun 7, 2019 at 2:45 PM Cassandra Targett 
wrote:

> I created an issue for this at
> https://issues.apache.org/jira/browse/LUCENE-8842, and I’ll use that to
> create a branch and push up what I have so far for a template.
>
> Cassandra
> On Jun 7, 2019, 11:31 AM -0500, Kevin Risden , wrote:
>
> PR template would definitely be good. Easiest to implement with biggest
> impact. I like that all issues are in Jira. There is already an infra bot
> that will auto link Jiras and PRs if the PR has the a JIRA reference in it
> I think.
>
> For reference this is also the idea of contributing guidelines in addition
> to the PR template [1] There are a few types of files that would help
> people if they stumble on the github repo [2].
>
> [1]
> https://help.github.com/en/articles/setting-guidelines-for-repository-contributors
> [2]
> https://help.github.com/en/articles/creating-a-default-community-health-file-for-your-organization
>
> Kevin Risden
>
>
> On Fri, Jun 7, 2019 at 9:58 AM David Smiley 
> wrote:
>
> I think a PR template would be great.  Lets see yours Cassandra!
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Fri, Jun 7, 2019 at 9:35 AM Cassandra Targett 
> wrote:
>
> Heh, here’s another idea I’ve had in my drafts folder for a while but
> thought if I suggest it I should be available to follow up on it and wasn’t
> sure if I’d have time to properly.
>
> I actually started a pull request template and have a mostly complete
> version I could share (via a PR, I guess?). I don’t think it will 100%
> solve it, but it would greatly increase the number of issues that comply,
> for lack of a better term, with our processes/expectations for changes. In
> my draft I also included a short checklist to encourage people to make
> the patch for master, include tests with their patches, run precommit,
> and a few other things I thought might help new contributors understand
> what we need to get their patches reviewed faster.
>
> Your D and E ideas are interesting. I worry about fragmenting where
> definitive info about changes is stored (D) - I think there is a lot of
> value in having a single system of record for the community.
>
> I’d definitely be for exploring moving entirely to Github (E) - I think I
> said something along those lines in the lucene-solr Slack channel a few
> months ago - but have not spent much time figuring out all the downstream
> implications. I think we’d have to consider what we would gain vs what we
> would lose. I definitely don’t yet have a list, but I’m not initially
> against the idea.
>
> Cassandra
> On Jun 7, 2019, 5:53 AM -0500, Jan Høydahl , wrote:
>
> Hi,
>
> We have some contributors that open GitHub PRs without also opening a JIRA
> and linking the two. Probably because they are used to that workflow from
> other projects and expect someone to have a look at the contribution. There
> is an email sent to the dev list, and sometimes it is noticed, other times
> the PR just falls through the cracks and is forgotten.
>
> Here is a list of currently open PRs without a JIRA attached, 51 in total:
>
>
> https://github.com/apache/lucene-solr/pulls?utf8=✓=is%3Apr+is%3Aopen+NOT+LUCENE+in%3Atitle+AND+NOT+SOLR+in%3Atitle+
> 
>
> How can we improve on the situation? I see a few alternatives:
>
> A. Setup a bot with a GitHub WebHook that inspects the title and auto adds
> a comment if LUCENE or SOLR is missing
> https://developer.github.com/v3/activity/events/types/#pullrequestevent
> B. Send the result of the above query to the dev@ list monthly for
> someone to jump in and interact
> C. Add a GitHub Pull-Request Template
> https://help.github.com/en/articles/creating-a-pull-request-template-for-your-repository
> In there put some text about the requirement for a JIRA
> D. Treat PRs as first-class issues, without the need for a shadow JIRA. In
> that case, we'd reference PRs in CHANGES too, e.g.:
> * #217: Fix bug foo
> E. Migrate away from JIRA and use GitHub issues + PR instead. Some Apache
> projects do that already :)
>
> Let the discussion begin :)
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
>
> 

[jira] [Commented] (LUCENE-8781) Explore FST direct array arc encoding

[Mike Sokolov (JIRA)]

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

Mike Sokolov commented on LUCENE-8781:
--

OK, I see we write a version header and then check it for compatibility when 
reading. I think in the spirit of full disclosure, failing early, no surprises, 
etc, we should increase the version. That way older readers will know to fail 
fast when they come across a newer version FST. I'll open a new issue for this, 
and fixing the CHANGES.txt


> Explore FST direct array arc encoding 
> --
>
> Key: LUCENE-8781
> URL: https://issues.apache.org/jira/browse/LUCENE-8781
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Mike Sokolov
>Assignee: Dawid Weiss
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: FST-2-4.png, FST-6-9.png, FST-size.png
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> This issue is for exploring an alternate FST encoding of Arcs as full-sized 
> arrays so Arcs are addressed directly by label, avoiding binary search that 
> we use today for arrays of Arcs. PR: 
> https://github.com/apache/lucene-solr/pull/657
> h3. Testing
> ant test passes. I added some unit tests that were helpful in uncovering bugs 
> while
> implementing which are more difficult to chase down when uncovered by the 
> randomized testing we already do. They don't really test anything new; 
> they're just more focused.
> I'm not sure why, but ant precommit failed for me with:
> {noformat}
>  ...lucene-solr/solr/common-build.xml:536: Check for forbidden API calls 
> failed while scanning class 
> 'org.apache.solr.metrics.reporters.SolrGangliaReporterTest' 
> (SolrGangliaReporterTest.java): java.lang.ClassNotFoundException: 
> info.ganglia.gmetric4j.gmetric.GMetric (while looking up details about 
> referenced class 'info.ganglia.gmetric4j.gmetric.GMetric')
> {noformat}
> I also got Test2BFST running (it was originally timing out due to excessive 
> calls to ramBytesUsage(), which seems to have gotten slow), and it passed; 
> that change isn't include here.
> h4. Micro-benchmark
> I timed lookups in FST via FSTEnum.seekExact in a unit test under various 
> conditions. 
> h5. English words
> A test of looking up existing words in a dictionary of ~17 English words 
> shows improvements; the numbers listed are % change in FST size, time to look 
> up (FSTEnum.seekExact) words that are in the dict, and time to look up random 
> strings that are not in the dict. The comparison is against the current 
> codebase with the optimization disabled. A separate comparison of showed no 
> significant change of the baseline (no opto applied) vs the current master 
> FST impl with no code changes applied.
> ||  load=2||   load=4 ||  load=16 ||
> | +4, -6, -7  | +18, -11, -8 | +22, -11.5, -7 |
> The "load factor" used for those measurements controls when direct array arc 
> encoding is used;
> namely when the number of outgoing arcs was > load * (max label - min label).
> h5. sequential and random terms
> The same test, with terms being a sequence of integers as strings shows a 
> larger improvement, around 20% (load=4). This is presumably the best case for 
> this delta, where every Arc is encoded as a direct lookup.
> When random lowercase ASCII strings are used, a smaller improvement of around 
> 4% is seen.
> h4. luceneutil
> Testing w/luceneutil (wikimediumall) we see improvements mostly in the 
> PKLookup case. Other results seem noisy, with perhaps a small improvment in 
> some of the queries.
> {noformat}
> TaskQPS base  StdDevQPS opto  StdDev  
>   Pct diff
>   OrHighHigh6.93  (3.0%)6.89  (3.1%)   
> -0.5% (  -6% -5%)
>OrHighMed   45.15  (3.9%)   44.92  (3.5%)   
> -0.5% (  -7% -7%)
> Wildcard8.72  (4.7%)8.69  (4.6%)   
> -0.4% (  -9% -9%)
>   AndHighLow  274.11  (2.6%)  273.58  (3.1%)   
> -0.2% (  -5% -5%)
>OrHighLow  241.41  (1.9%)  241.11  (3.5%)   
> -0.1% (  -5% -5%)
>   AndHighMed   52.23  (4.1%)   52.41  (5.3%)
> 0.3% (  -8% -   10%)
>  MedTerm 1026.24  (3.1%) 1030.52  (4.3%)
> 0.4% (  -6% -8%)
> HighTerm .10  (3.4%) 1116.70  (4.0%)
> 0.5% (  -6% -8%)
>HighTermDayOfYearSort   14.59  (8.2%)   14.73  (9.3%)
> 1.0% ( -15% -   20%)
>  AndHighHigh   13.45  (6.2%)   13.61  (4.4%)
> 1.2% (  -8% -   12%)
>HighTermMonthSort   63.09 (12.5%)   64.13 (10.9%)
> 1.6% ( -19% -   28%)

[jira] [Updated] (LUCENE-8844) Bump FST Version

[Mike Sokolov (JIRA)]

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

Mike Sokolov updated LUCENE-8844:
-
Description: 
In LUCENE-8781, we changed the FST encoding but did not bump the version number 
we write in its header. The change was backwards-compatible (new readers can 
still read old FSTs), but not forwards-compatible: older readers would exhibit 
strange behavior if they attempted to read one of these newer format FSTs.

It would be much better if readers could catch such errors and notify in a 
sensible way, and we have version checking that does that; we just need to 
increase the VERSION_CURRENT constant.

Also, ~[~dsmiley] points out the CHANGES.txt entries for LUCENE-8781 should be 
moved to the 8.2.0 section since that change was backported. I think we can 
clean that up at the same time since it's version-related.

  was:
In LUCENE-8781, we changed the FST encoding but not bump the version number we 
write in its header. The change was backwards-compatible (new readers can still 
read old FSTs), but not forwards-compatible: older readers would exhibit 
strange behavior if they attempted to read one of these newer format FSTs.

It would be much better if readers could catch such errors and notify in a 
sensible way, and we have version checking that does that; we just need to 
increase the VERSION_CURRENT constant.

Also, ~[~dsmiley] points out the CHANGES.txt entries for LUCENE-8781 should be 
moved to the 8.2.0 section since that change was backported. I think we can 
clean that up at the same time since it's version-related.


> Bump FST Version
> 
>
> Key: LUCENE-8844
> URL: https://issues.apache.org/jira/browse/LUCENE-8844
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Mike Sokolov
>Assignee: Mike Sokolov
>Priority: Major
>
> In LUCENE-8781, we changed the FST encoding but did not bump the version 
> number we write in its header. The change was backwards-compatible (new 
> readers can still read old FSTs), but not forwards-compatible: older readers 
> would exhibit strange behavior if they attempted to read one of these newer 
> format FSTs.
> It would be much better if readers could catch such errors and notify in a 
> sensible way, and we have version checking that does that; we just need to 
> increase the VERSION_CURRENT constant.
> Also, ~[~dsmiley] points out the CHANGES.txt entries for LUCENE-8781 should 
> be moved to the 8.2.0 section since that change was backported. I think we 
> can clean that up at the same time since it's version-related.



--
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-8781) Explore FST direct array arc encoding

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-8781:
--

BTW you could have simply re-opened this issue; it’s in scope and this wasn’t 
released yet. I see you already opened another so just keep in mind for future. 

> Explore FST direct array arc encoding 
> --
>
> Key: LUCENE-8781
> URL: https://issues.apache.org/jira/browse/LUCENE-8781
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Mike Sokolov
>Assignee: Dawid Weiss
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: FST-2-4.png, FST-6-9.png, FST-size.png
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> This issue is for exploring an alternate FST encoding of Arcs as full-sized 
> arrays so Arcs are addressed directly by label, avoiding binary search that 
> we use today for arrays of Arcs. PR: 
> https://github.com/apache/lucene-solr/pull/657
> h3. Testing
> ant test passes. I added some unit tests that were helpful in uncovering bugs 
> while
> implementing which are more difficult to chase down when uncovered by the 
> randomized testing we already do. They don't really test anything new; 
> they're just more focused.
> I'm not sure why, but ant precommit failed for me with:
> {noformat}
>  ...lucene-solr/solr/common-build.xml:536: Check for forbidden API calls 
> failed while scanning class 
> 'org.apache.solr.metrics.reporters.SolrGangliaReporterTest' 
> (SolrGangliaReporterTest.java): java.lang.ClassNotFoundException: 
> info.ganglia.gmetric4j.gmetric.GMetric (while looking up details about 
> referenced class 'info.ganglia.gmetric4j.gmetric.GMetric')
> {noformat}
> I also got Test2BFST running (it was originally timing out due to excessive 
> calls to ramBytesUsage(), which seems to have gotten slow), and it passed; 
> that change isn't include here.
> h4. Micro-benchmark
> I timed lookups in FST via FSTEnum.seekExact in a unit test under various 
> conditions. 
> h5. English words
> A test of looking up existing words in a dictionary of ~17 English words 
> shows improvements; the numbers listed are % change in FST size, time to look 
> up (FSTEnum.seekExact) words that are in the dict, and time to look up random 
> strings that are not in the dict. The comparison is against the current 
> codebase with the optimization disabled. A separate comparison of showed no 
> significant change of the baseline (no opto applied) vs the current master 
> FST impl with no code changes applied.
> ||  load=2||   load=4 ||  load=16 ||
> | +4, -6, -7  | +18, -11, -8 | +22, -11.5, -7 |
> The "load factor" used for those measurements controls when direct array arc 
> encoding is used;
> namely when the number of outgoing arcs was > load * (max label - min label).
> h5. sequential and random terms
> The same test, with terms being a sequence of integers as strings shows a 
> larger improvement, around 20% (load=4). This is presumably the best case for 
> this delta, where every Arc is encoded as a direct lookup.
> When random lowercase ASCII strings are used, a smaller improvement of around 
> 4% is seen.
> h4. luceneutil
> Testing w/luceneutil (wikimediumall) we see improvements mostly in the 
> PKLookup case. Other results seem noisy, with perhaps a small improvment in 
> some of the queries.
> {noformat}
> TaskQPS base  StdDevQPS opto  StdDev  
>   Pct diff
>   OrHighHigh6.93  (3.0%)6.89  (3.1%)   
> -0.5% (  -6% -5%)
>OrHighMed   45.15  (3.9%)   44.92  (3.5%)   
> -0.5% (  -7% -7%)
> Wildcard8.72  (4.7%)8.69  (4.6%)   
> -0.4% (  -9% -9%)
>   AndHighLow  274.11  (2.6%)  273.58  (3.1%)   
> -0.2% (  -5% -5%)
>OrHighLow  241.41  (1.9%)  241.11  (3.5%)   
> -0.1% (  -5% -5%)
>   AndHighMed   52.23  (4.1%)   52.41  (5.3%)
> 0.3% (  -8% -   10%)
>  MedTerm 1026.24  (3.1%) 1030.52  (4.3%)
> 0.4% (  -6% -8%)
> HighTerm .10  (3.4%) 1116.70  (4.0%)
> 0.5% (  -6% -8%)
>HighTermDayOfYearSort   14.59  (8.2%)   14.73  (9.3%)
> 1.0% ( -15% -   20%)
>  AndHighHigh   13.45  (6.2%)   13.61  (4.4%)
> 1.2% (  -8% -   12%)
>HighTermMonthSort   63.09 (12.5%)   64.13 (10.9%)
> 1.6% ( -19% -   28%)
>  LowTerm 1338.94  (3.3%) 1383.90  (5.5%)
> 3.4% (  -5% -   12%)
> PKLookup  120.45  (2.5%)  130.91  (3.5%)
> 

[jira] [Updated] (LUCENE-8844) Bump FST Version (to 7)

[Mike Sokolov (JIRA)]

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

Mike Sokolov updated LUCENE-8844:
-
Summary: Bump FST Version (to 7)  (was: Bump FST Version)

> Bump FST Version (to 7)
> ---
>
> Key: LUCENE-8844
> URL: https://issues.apache.org/jira/browse/LUCENE-8844
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Mike Sokolov
>Assignee: Mike Sokolov
>Priority: Major
>
> In LUCENE-8781, we changed the FST encoding but did not bump the version 
> number we write in its header. The change was backwards-compatible (new 
> readers can still read old FSTs), but not forwards-compatible: older readers 
> would exhibit strange behavior if they attempted to read one of these newer 
> format FSTs.
> It would be much better if readers could catch such errors and notify in a 
> sensible way, and we have version checking that does that; we just need to 
> increase the VERSION_CURRENT constant.
> Also, ~[~dsmiley] points out the CHANGES.txt entries for LUCENE-8781 should 
> be moved to the 8.2.0 section since that change was backported. I think we 
> can clean that up at the same time since it's version-related.



--
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-8781) Explore FST direct array arc encoding

[Mike Sokolov (JIRA)]

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

Mike Sokolov commented on LUCENE-8781:
--

Got it, thanks. Yeah this was a tiny change, doesn't seem worth all the 
ceremony; I plan to just push after precommit, no PR, so why open an issue?

> Explore FST direct array arc encoding 
> --
>
> Key: LUCENE-8781
> URL: https://issues.apache.org/jira/browse/LUCENE-8781
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Mike Sokolov
>Assignee: Dawid Weiss
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: FST-2-4.png, FST-6-9.png, FST-size.png
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> This issue is for exploring an alternate FST encoding of Arcs as full-sized 
> arrays so Arcs are addressed directly by label, avoiding binary search that 
> we use today for arrays of Arcs. PR: 
> https://github.com/apache/lucene-solr/pull/657
> h3. Testing
> ant test passes. I added some unit tests that were helpful in uncovering bugs 
> while
> implementing which are more difficult to chase down when uncovered by the 
> randomized testing we already do. They don't really test anything new; 
> they're just more focused.
> I'm not sure why, but ant precommit failed for me with:
> {noformat}
>  ...lucene-solr/solr/common-build.xml:536: Check for forbidden API calls 
> failed while scanning class 
> 'org.apache.solr.metrics.reporters.SolrGangliaReporterTest' 
> (SolrGangliaReporterTest.java): java.lang.ClassNotFoundException: 
> info.ganglia.gmetric4j.gmetric.GMetric (while looking up details about 
> referenced class 'info.ganglia.gmetric4j.gmetric.GMetric')
> {noformat}
> I also got Test2BFST running (it was originally timing out due to excessive 
> calls to ramBytesUsage(), which seems to have gotten slow), and it passed; 
> that change isn't include here.
> h4. Micro-benchmark
> I timed lookups in FST via FSTEnum.seekExact in a unit test under various 
> conditions. 
> h5. English words
> A test of looking up existing words in a dictionary of ~17 English words 
> shows improvements; the numbers listed are % change in FST size, time to look 
> up (FSTEnum.seekExact) words that are in the dict, and time to look up random 
> strings that are not in the dict. The comparison is against the current 
> codebase with the optimization disabled. A separate comparison of showed no 
> significant change of the baseline (no opto applied) vs the current master 
> FST impl with no code changes applied.
> ||  load=2||   load=4 ||  load=16 ||
> | +4, -6, -7  | +18, -11, -8 | +22, -11.5, -7 |
> The "load factor" used for those measurements controls when direct array arc 
> encoding is used;
> namely when the number of outgoing arcs was > load * (max label - min label).
> h5. sequential and random terms
> The same test, with terms being a sequence of integers as strings shows a 
> larger improvement, around 20% (load=4). This is presumably the best case for 
> this delta, where every Arc is encoded as a direct lookup.
> When random lowercase ASCII strings are used, a smaller improvement of around 
> 4% is seen.
> h4. luceneutil
> Testing w/luceneutil (wikimediumall) we see improvements mostly in the 
> PKLookup case. Other results seem noisy, with perhaps a small improvment in 
> some of the queries.
> {noformat}
> TaskQPS base  StdDevQPS opto  StdDev  
>   Pct diff
>   OrHighHigh6.93  (3.0%)6.89  (3.1%)   
> -0.5% (  -6% -5%)
>OrHighMed   45.15  (3.9%)   44.92  (3.5%)   
> -0.5% (  -7% -7%)
> Wildcard8.72  (4.7%)8.69  (4.6%)   
> -0.4% (  -9% -9%)
>   AndHighLow  274.11  (2.6%)  273.58  (3.1%)   
> -0.2% (  -5% -5%)
>OrHighLow  241.41  (1.9%)  241.11  (3.5%)   
> -0.1% (  -5% -5%)
>   AndHighMed   52.23  (4.1%)   52.41  (5.3%)
> 0.3% (  -8% -   10%)
>  MedTerm 1026.24  (3.1%) 1030.52  (4.3%)
> 0.4% (  -6% -8%)
> HighTerm .10  (3.4%) 1116.70  (4.0%)
> 0.5% (  -6% -8%)
>HighTermDayOfYearSort   14.59  (8.2%)   14.73  (9.3%)
> 1.0% ( -15% -   20%)
>  AndHighHigh   13.45  (6.2%)   13.61  (4.4%)
> 1.2% (  -8% -   12%)
>HighTermMonthSort   63.09 (12.5%)   64.13 (10.9%)
> 1.6% ( -19% -   28%)
>  LowTerm 1338.94  (3.3%) 1383.90  (5.5%)
> 3.4% (  -5% -   12%)
> PKLookup  120.45  (2.5%)  130.91  (3.5%)
> 8.7% (   2% -  

Re: Lucene / Solr Gradle Build Update

[Michael Sokolov]

Please don't stop now! Many thanks for doing the work. Faster builds
will answer for any grumbling/transition pains I expect

On Sat, Jun 8, 2019 at 9:58 AM Gus Heck  wrote:
>
> Also looking forward to it. :) especially if it speeds things up. Moving 
> forward with it in 9x and not 8 sounds good to me. There are folks out there 
> who build themselves custom builds of Solr, so build changes this big seem 
> like a sort of back compatability concern, though obviously only for a 
> minority.
>
> On Fri, Jun 7, 2019 at 11:05 PM Ishan Chattopadhyaya 
>  wrote:
>>
>> Looking forward to it, and thanks a lot for your effort. Excited!
>>
>> On Sat, 8 Jun, 2019, 4:29 AM Mark Miller,  wrote:
>>>
>>> Since I have heard no objection, I've continued working on moving the 
>>> project from ant+ivy+maven to gradle.
>>>
>>> At this point I've contributed significant time to this project. I hope 
>>> everyone has taken the time to consider this change and their possible 
>>> concerns. I don't want to beat a dead horse, but there is too much effort 
>>> involved to get caught up at the end.
>>>
>>> There is still a lot to do, it's not going to happen tomorrow, but many, 
>>> many things are done.
>>>
>>> The performance of the build in comparison to what we had will astonish you 
>>> on good hardware.
>>>
>>> Even comparing to your experience with the majority of maven builds, this 
>>> will be *significantly* faster. This is without using the gradle build 
>>> cache or paying proper attention to task uptodate properties.
>>>
>>> There are considerable improvements and benefits we can reap from this 
>>> change, but the sheer speed has made the development experience for me way 
>>> more enjoyable.
>>>
>>> My goal is to take us from a very powerful but complicated and slow and 
>>> clunky and dense build to what is essentially a modern top tier build 
>>> experience in power, performance, integrity and ease of use.
>>>
>>> I've made significant progress over the past month or so, but it will 
>>> likely take me another 2-4 before I plan on having something I'd considered 
>>> ready for prime time 9x duties.
>>>
>>> I'll take the time needed to get things right, hopefully everyone else will 
>>> take the time to help with a transition when that time comes.
>>>
>>> My hope is that version 9 is the first built with gradle. We can consider 
>>> it being available on 8 as well, but I don't think it makes sense to 
>>> release 8x versions with gradle. I think we should only consider the gradle 
>>> build on 8x as a developer convenience and it would be on the users of it 
>>> to address keeping it up to date with changes on the ant build as problems 
>>> arise. Depending on the time, it may not even make sense to put effort here.
>>>
>>> This weekend I'm wrapping up some work on making our dependency management 
>>> headache more transparent. I think we can make a lot of improvements on 
>>> understanding what is in our build and why and what is published or shipped 
>>> where and why.
>>>
>>> --
>>> - Mark
>>>
>>> http://about.me/markrmiller
>
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)

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

[jira] [Commented] (LUCENE-8844) Bump FST Version (to 7)

[ASF subversion and git services (JIRA)]

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

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

Commit a8478c790aeb888e165670b3329188d3d5290ffd in lucene-solr's branch 
refs/heads/branch_8x from Michael Sokolov
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a8478c7 ]

LUCENE-8844: bump FST version and fix related CHANGES entry


> Bump FST Version (to 7)
> ---
>
> Key: LUCENE-8844
> URL: https://issues.apache.org/jira/browse/LUCENE-8844
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Mike Sokolov
>Assignee: Mike Sokolov
>Priority: Major
>
> In LUCENE-8781, we changed the FST encoding but did not bump the version 
> number we write in its header. The change was backwards-compatible (new 
> readers can still read old FSTs), but not forwards-compatible: older readers 
> would exhibit strange behavior if they attempted to read one of these newer 
> format FSTs.
> It would be much better if readers could catch such errors and notify in a 
> sensible way, and we have version checking that does that; we just need to 
> increase the VERSION_CURRENT constant.
> Also, ~[~dsmiley] points out the CHANGES.txt entries for LUCENE-8781 should 
> be moved to the 8.2.0 section since that change was backported. I think we 
> can clean that up at the same time since it's version-related.



--
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] msokolov commented on issue #701: LUCENE-8836 Optimize DocValues TermsDict to continue scanning from the last position when possible

[GitBox]

msokolov commented on issue #701: LUCENE-8836 Optimize DocValues TermsDict to 
continue scanning from the last position when possible
URL: https://github.com/apache/lucene-solr/pull/701#issuecomment-500131574
 
 
   bq. The approach I took was to run some Lucene tests while counting the 
total number of seeks and terms read in the IndexInput, with and without the 
optimization.
   
   The numbers look compelling. Is this a fair test though? Doesn't it ignore 
the cost added by the optimization? We now do some work saving last term,etc. 
It seems as if it could be justified by reductions in seeking, but a test that 
shows that holistically would be good, ideally targeting some common use case. 
The unit tests might be exercising fairly artifical edge cases? EG we probably 
don't want to be optimizing slow exact range query when the caller would be 
better off using a points field. For DocValues, typical use cases do probably 
involve sorting/scoring/grouping/aggregations. Do you have a use case you are 
targeting and can share results on?


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


With regards,
Apache Git Services

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

[jira] [Commented] (LUCENE-8841) Explore Relevance Based Performance Benchmarks

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8841:
--

Yes that would be possible.

> Explore Relevance Based Performance Benchmarks
> --
>
> Key: LUCENE-8841
> URL: https://issues.apache.org/jira/browse/LUCENE-8841
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Major
>
> While discussing improvements in relevance of fuzzy queries with [~jimczi], 
> the topic of how to measure impact of changes to relevance of common queries 
> came up. While a non trivial effort, having such a benchmark will allow us to 
> measure the impact of potential changes and also catch regressions well in 
> time.
>  
> This Jira tracks ideas and efforts in that direction



--
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-8829) TopDocs#Merge is Tightly Coupled To Number Of Collectors Involved

[Atri Sharma (JIRA)]

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

Atri Sharma commented on LUCENE-8829:
-

[~jpountz] Does it make sense to backport this to earlier branches ?

> TopDocs#Merge is Tightly Coupled To Number Of Collectors Involved
> -
>
> Key: LUCENE-8829
> URL: https://issues.apache.org/jira/browse/LUCENE-8829
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Atri Sharma
>Priority: Major
> Attachments: LUCENE-8829.patch, LUCENE-8829.patch
>
>
> While investigating LUCENE-8819, I understood that TopDocs#merge's order of 
> results are indirectly dependent on the number of collectors involved in the 
> merge. This is troubling because 1) The number of collectors involved in a 
> merge are cost based and directly dependent on the number of slices created 
> for the parallel searcher case. 2) TopN hits code path will invoke merge with 
> a single Collector, so essentially, doing the same TopN query with single 
> threaded and parallel threaded searcher will invoke different order of 
> results, which is a bad invariant that breaks.
>  
> The reason why this happens is because of the subtle way TopDocs#merge sets 
> shardIndex in the ScoreDoc population during populating the priority queue 
> used for merging. ShardIndex is essentially set to the ordinal of the 
> collector which generates the hit. This means that the shardIndex is 
> dependent on the number of collectors, even for the same set of hits.
>  
> In case of no sort order specified, shardIndex is used for tie breaking when 
> scores are equal. This translates to different orders for same hits with 
> different shardIndices.
>  
> I propose that we remove shardIndex from the default tie breaking mechanism 
> and replace it with docID. DocID order is the de facto that is expected 
> during collection, so it might make sense to use the same factor during tie 
> breaking when scores are the same.
>  
> CC: [~ivera]



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

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

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

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 64201 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj579673717
 [ecj-lint] Compiling 69 source files to /tmp/ecj579673717
 [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-master-Linux/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
 (at line 28)
 [ecj-lint] import javax.naming.InitialContext;
 [ecj-lint]^^^
 [ecj-lint] The type javax.naming.InitialContext is not accessible
 [ecj-lint] --
 [ecj-lint] 2. ERROR in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
 (at line 29)
 [ecj-lint] import javax.naming.NamingException;
 [ecj-lint]
 [ecj-lint] The type javax.naming.NamingException is not accessible
 [ecj-lint] --
 [ecj-lint] 3. ERROR in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
 (at line 182)
 [ecj-lint] c = getFromJndi(initProps, jndiName);
 [ecj-lint] ^^^
 [ecj-lint] The method getFromJndi(Properties, String) from the type new 
Callable(){} refers to the missing type NamingException
 [ecj-lint] --
 [ecj-lint] 4. ERROR in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
 (at line 245)
 [ecj-lint] private Connection getFromJndi(final Properties initProps, 
final String jndiName) throws NamingException,
 [ecj-lint] 
 ^^^
 [ecj-lint] NamingException cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 5. ERROR in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
 (at line 249)
 [ecj-lint] InitialContext ctx =  new InitialContext();
 [ecj-lint] ^^
 [ecj-lint] InitialContext cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 6. ERROR in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
 (at line 249)
 [ecj-lint] InitialContext ctx =  new InitialContext();
 [ecj-lint]   ^^
 [ecj-lint] InitialContext cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 6 problems (6 errors)

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

Total time: 104 minutes 32 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2

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

[jira] [Assigned] (LUCENE-8844) Bump FST Version

[Mike Sokolov (JIRA)]

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

Mike Sokolov reassigned LUCENE-8844:


Assignee: Mike Sokolov

> Bump FST Version
> 
>
> Key: LUCENE-8844
> URL: https://issues.apache.org/jira/browse/LUCENE-8844
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Mike Sokolov
>Assignee: Mike Sokolov
>Priority: Major
>
> In LUCENE-8781, we changed the FST encoding but not bump the version number 
> we write in its header. The change was backwards-compatible (new readers can 
> still read old FSTs), but not forwards-compatible: older readers would 
> exhibit strange behavior if they attempted to read one of these newer format 
> FSTs.
> It would be much better if readers could catch such errors and notify in a 
> sensible way, and we have version checking that does that; we just need to 
> increase the VERSION_CURRENT constant.
> Also, ~[~dsmiley] points out the CHANGES.txt entries for LUCENE-8781 should 
> be moved to the 8.2.0 section since that change was backported. I think we 
> can clean that up at the same time since it's version-related.



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

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

[jira] [Created] (LUCENE-8844) Bump FST Version

[Mike Sokolov (JIRA)]

Mike Sokolov created LUCENE-8844:


 Summary: Bump FST Version
 Key: LUCENE-8844
 URL: https://issues.apache.org/jira/browse/LUCENE-8844
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Mike Sokolov


In LUCENE-8781, we changed the FST encoding but not bump the version number we 
write in its header. The change was backwards-compatible (new readers can still 
read old FSTs), but not forwards-compatible: older readers would exhibit 
strange behavior if they attempted to read one of these newer format FSTs.

It would be much better if readers could catch such errors and notify in a 
sensible way, and we have version checking that does that; we just need to 
increase the VERSION_CURRENT constant.

Also, ~[~dsmiley] points out the CHANGES.txt entries for LUCENE-8781 should be 
moved to the 8.2.0 section since that change was backported. I think we can 
clean that up at the same time since it's version-related.



--
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=16859239#comment-16859239
 ] 

Atri Sharma commented on LUCENE-8791:
-

bq. could we make the single-threaded constructor take a Collector rather than 
a CollectorManager and document that the one that takes an ExecutorService is 
expert and usually doesn't help significantly?

That has also been one of my main gripes with the approach that this patch 
takes -- the default interface takes an ExecutorManager. Maybe it is just a 
matter of personal taste, but it still catches the eye. It would be great if we 
could improve upon that

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

Re: Sanity check: JIRA search discrepancy when logged-in/anon

[Alexandre Rafalovitch]

Ok,

I've done it for all currently public issues. It was a bit
nerve-wracking to modify 4k+ issues (1k at a time) :-)

Notes:
1) It is a bit hard to find all Public issues as Security level is not
in the dropdowns. So, the search query has to be in the advanced mode
and be: project = SOLR AND  Level = "Public"
2) Can only be done maximum 1000 issues at a time (under Tools/Bulk Change)
3) Check Edit
4) Set Security Level to None, scroll down all the way and uncheck
Send email, then submit
5) Confirm
6) Wait (approx 7min per 1000)
7) Acknowledge

I am not sure I have the right to update the release instructions, but
- as David said - this probably could be a good place to keep them in
check. Possibly in the same step as does the final issue cleanup
(something about versions I think).

Regards,
   Alex.

On Fri, 7 Jun 2019 at 09:26, David Smiley  wrote:
>
> Wow that's annoying!
>
> Perhaps we could add this bulk edit task as part of the release process 
> towards the end?  It's strictly not release related but it's a good a time as 
> any to do clean up while the RM is following a script.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Fri, Jun 7, 2019 at 8:52 AM Cassandra Targett  
> wrote:
>>
>> What you’re seeing is exactly the security level situation. Recall that it 
>> occurs with all issues that have a value in the Security Level field, 
>> whether that value is Public or Private. For all queries, if you are not 
>> logged in, you only see issues that have an empty value in the Security 
>> Level field. You can see the issues just fine if you know the ID, but they 
>> will not appear in query results unless you are logged in.
>>
>> The 14 you see for 7.4 when not logged in have no Security Level set at all. 
>> All 10 of the 7.3.1 issues you can’t see unless you are logged in have a 
>> value in the Security Level field, Public as it happens.
>>
>> One of the several draft emails I haven’t had time to send is a suggestion 
>> that we just simply do a bulk edit for all Public issues to remove the value 
>> entirely, and periodically do the same. I’d do it as often as I have time 
>> and remember to do it, but any of us could do it as long as we agree it’s a 
>> good idea.
>>
>> Cassandra
>> On Jun 7, 2019, 5:53 AM -0500, Alexandre Rafalovitch , 
>> wrote:
>>
>> Hi,
>>
>> It seems to be that something is not right with JIRA. It seems somehow
>> related to minor (x.y.Z) releases when looking for them in Anon mode.
>> And issues that target them.
>>
>> Reproduction:
>> 1) In Anon window, go to: https://issues.apache.org/jira/browse/SOLR-12202
>> 2) Click (to new window) on 7.3.1 release, which should show all
>> issues fixed in 7.3.1. I get nothing in anon and 10 in logged-in
>> 3) Click (to new window) on 7.4 release, and I see 14, instead of 169
>>
>> Same happens with https://issues.apache.org/jira/browse/SOLR-13255
>> (part of 7.7.1 release).
>>
>> I thought maybe this was connected to Security Level situation, but
>> both of these are marked public explicitly.
>>
>> Does anybody else sees this and/or knows whether this is some kind of
>> known issue?
>>
>> Regards,
>> Alex.
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>

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

[jira] [Commented] (SOLR-13105) A visual guide to Solr Math Expressions and Streaming Expressions

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13105:


Commit c45d4e31a202eec15a1544e1a60ada6ffdcc4ca1 in lucene-solr's branch 
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c45d4e3 ]

SOLR-13105: More gallery images


> A visual guide to Solr Math Expressions and Streaming Expressions
> -
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: Screen Shot 2019-01-14 at 10.56.32 AM.png, Screen Shot 
> 2019-02-21 at 2.14.43 PM.png, Screen Shot 2019-03-03 at 2.28.35 PM.png, 
> Screen Shot 2019-03-04 at 7.47.57 PM.png, Screen Shot 2019-03-13 at 10.47.47 
> AM.png, Screen Shot 2019-03-30 at 6.17.04 PM.png
>
>
> Visualization is now a fundamental element of Solr Streaming Expressions and 
> Math Expressions. This ticket will create a visual guide to Solr Math 
> Expressions and Solr Streaming Expressions that includes *Apache Zeppelin* 
> visualization examples.
> It will also cover using the JDBC expression to *analyze* and *visualize* 
> results from any JDBC compliant data source.
> Intro from the guide:
> {code:java}
> Streaming Expressions exposes the capabilities of Solr Cloud as composable 
> functions. These functions provide a system for searching, transforming, 
> analyzing and visualizing data stored in Solr Cloud collections.
> At a high level there are four main capabilities that will be explored in the 
> documentation:
> * Searching, sampling and aggregating results from Solr.
> * Transforming result sets after they are retrieved from Solr.
> * Analyzing and modeling result sets using probability and statistics and 
> machine learning libraries.
> * Visualizing result sets, aggregations and statistical models of the data.
> {code}
>  
> A few sample visualizations are attached to the ticket.



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

[DISCUSS] Reviving Open Relevance Project

[Atri Sharma]

Hi All,

In LUCENE-8841[1], the question of having a relevance benchmark which
allows measuring impact of changes to the relevance of common usecase
queries and guarding against unintentional regressions.

Adrien very kindly pointed out that Open Relevance project [2] is a
good candidate for that goal, and it would be a nice thing to revive
it and make it an updated and active suite (maybe with nightly
benchmarks on the lines of luceneutil?).

This thread is aimed at discussing the potential paths forward:

1) Do not revive the project.

2) Revive Open Relevance Project and make it a sub project of Lucene again

3) Revive Open Relevance Project and propose it as a generic
performance benchmark for Apache Software Foundation, not as a Lucene
subproject.

If we go down the path of 2), I would suggest a working committee that
can ensure the continued health of the project, to ensure it does not
go down the way it did in 2014.

Please share your thoughts.

Regards,

Atri












[1] https://issues.apache.org/jira/browse/LUCENE-8841
[2] https://lucene.apache.org/openrelevance/

-- 
Regards,

Atri
Apache Concerted

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

[jira] [Commented] (SOLR-13105) A visual guide to Solr Math Expressions and Streaming Expressions

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13105:


Commit b83e7f7e5aabe466068e2033e758ac06d8132ea4 in lucene-solr's branch 
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b83e7f7 ]

SOLR-13105: Fix trend image


> A visual guide to Solr Math Expressions and Streaming Expressions
> -
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: Screen Shot 2019-01-14 at 10.56.32 AM.png, Screen Shot 
> 2019-02-21 at 2.14.43 PM.png, Screen Shot 2019-03-03 at 2.28.35 PM.png, 
> Screen Shot 2019-03-04 at 7.47.57 PM.png, Screen Shot 2019-03-13 at 10.47.47 
> AM.png, Screen Shot 2019-03-30 at 6.17.04 PM.png
>
>
> Visualization is now a fundamental element of Solr Streaming Expressions and 
> Math Expressions. This ticket will create a visual guide to Solr Math 
> Expressions and Solr Streaming Expressions that includes *Apache Zeppelin* 
> visualization examples.
> It will also cover using the JDBC expression to *analyze* and *visualize* 
> results from any JDBC compliant data source.
> Intro from the guide:
> {code:java}
> Streaming Expressions exposes the capabilities of Solr Cloud as composable 
> functions. These functions provide a system for searching, transforming, 
> analyzing and visualizing data stored in Solr Cloud collections.
> At a high level there are four main capabilities that will be explored in the 
> documentation:
> * Searching, sampling and aggregating results from Solr.
> * Transforming result sets after they are retrieved from Solr.
> * Analyzing and modeling result sets using probability and statistics and 
> machine learning libraries.
> * Visualizing result sets, aggregations and statistical models of the data.
> {code}
>  
> A few sample visualizations are attached to the ticket.



--
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-8844) Bump FST Version (to 7)

[ASF subversion and git services (JIRA)]

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

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

Commit e85c6e6429956aade155eb29aee7adc3f79e4bc6 in lucene-solr's branch 
refs/heads/master from Michael Sokolov
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e85c6e6 ]

LUCENE-8844: bump FST version and fix related CHANGES entry


> Bump FST Version (to 7)
> ---
>
> Key: LUCENE-8844
> URL: https://issues.apache.org/jira/browse/LUCENE-8844
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Mike Sokolov
>Assignee: Mike Sokolov
>Priority: Major
>
> In LUCENE-8781, we changed the FST encoding but did not bump the version 
> number we write in its header. The change was backwards-compatible (new 
> readers can still read old FSTs), but not forwards-compatible: older readers 
> would exhibit strange behavior if they attempted to read one of these newer 
> format FSTs.
> It would be much better if readers could catch such errors and notify in a 
> sensible way, and we have version checking that does that; we just need to 
> increase the VERSION_CURRENT constant.
> Also, ~[~dsmiley] points out the CHANGES.txt entries for LUCENE-8781 should 
> be moved to the 8.2.0 section since that change was backported. I think we 
> can clean that up at the same time since it's version-related.



--
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-13105) A visual guide to Solr Math Expressions and Streaming Expressions

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13105:


Commit 90461bfdd0d4654a07ef22096266969e3ee4a717 in lucene-solr's branch 
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=90461bf ]

SOLR-13105: New aggs image


> A visual guide to Solr Math Expressions and Streaming Expressions
> -
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: Screen Shot 2019-01-14 at 10.56.32 AM.png, Screen Shot 
> 2019-02-21 at 2.14.43 PM.png, Screen Shot 2019-03-03 at 2.28.35 PM.png, 
> Screen Shot 2019-03-04 at 7.47.57 PM.png, Screen Shot 2019-03-13 at 10.47.47 
> AM.png, Screen Shot 2019-03-30 at 6.17.04 PM.png
>
>
> Visualization is now a fundamental element of Solr Streaming Expressions and 
> Math Expressions. This ticket will create a visual guide to Solr Math 
> Expressions and Solr Streaming Expressions that includes *Apache Zeppelin* 
> visualization examples.
> It will also cover using the JDBC expression to *analyze* and *visualize* 
> results from any JDBC compliant data source.
> Intro from the guide:
> {code:java}
> Streaming Expressions exposes the capabilities of Solr Cloud as composable 
> functions. These functions provide a system for searching, transforming, 
> analyzing and visualizing data stored in Solr Cloud collections.
> At a high level there are four main capabilities that will be explored in the 
> documentation:
> * Searching, sampling and aggregating results from Solr.
> * Transforming result sets after they are retrieved from Solr.
> * Analyzing and modeling result sets using probability and statistics and 
> machine learning libraries.
> * Visualizing result sets, aggregations and statistical models of the data.
> {code}
>  
> A few sample visualizations are attached to the ticket.



--
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-13131) Category Routed Aliases

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13131:


Commit 3d57a323a900bf2b80c27ba7a04387103ce516d2 in lucene-solr's branch 
refs/heads/master from Gus Heck
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3d57a32 ]

SOLR-13131 Fix CHANGES.txt entry


> Category Routed Aliases
> ---
>
> Key: SOLR-13131
> URL: https://issues.apache.org/jira/browse/SOLR-13131
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: master (9.0)
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Major
> Fix For: 8.1, master (9.0)
>
> Attachments: indexingWithCRA.png, indexingwithoutCRA.png, 
> indexintWithoutCRA2.png
>
>
> This ticket is to add a second type of routed alias in addition to the 
> current time routed aliases. The new type of alias will allow data driven 
> creation of collections based on the values of a field and automated 
> organization of these collections under an alias that allows the collections 
> to also be searched as a whole.
> The use case in mind at present is an IOT device type segregation, but I 
> could also see this leading to the ability to direct updates to tenant 
> specific hardware (in cooperation with autoscaling). 
> This ticket also looks forward to (but does not include) the creation of a 
> Dimensionally Routed Alias which would allow organizing time routed data also 
> segregated by device
> Further design details to be added in comments.
>  



--
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-13105) A visual guide to Solr Math Expressions and Streaming Expressions

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13105:


Commit d0c40fe0bd8ef0e8d294d30d68d19950e269 in lucene-solr's branch 
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d0c40fe ]

SOLR-13105: Add residuals plot


> A visual guide to Solr Math Expressions and Streaming Expressions
> -
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: Screen Shot 2019-01-14 at 10.56.32 AM.png, Screen Shot 
> 2019-02-21 at 2.14.43 PM.png, Screen Shot 2019-03-03 at 2.28.35 PM.png, 
> Screen Shot 2019-03-04 at 7.47.57 PM.png, Screen Shot 2019-03-13 at 10.47.47 
> AM.png, Screen Shot 2019-03-30 at 6.17.04 PM.png
>
>
> Visualization is now a fundamental element of Solr Streaming Expressions and 
> Math Expressions. This ticket will create a visual guide to Solr Math 
> Expressions and Solr Streaming Expressions that includes *Apache Zeppelin* 
> visualization examples.
> It will also cover using the JDBC expression to *analyze* and *visualize* 
> results from any JDBC compliant data source.
> Intro from the guide:
> {code:java}
> Streaming Expressions exposes the capabilities of Solr Cloud as composable 
> functions. These functions provide a system for searching, transforming, 
> analyzing and visualizing data stored in Solr Cloud collections.
> At a high level there are four main capabilities that will be explored in the 
> documentation:
> * Searching, sampling and aggregating results from Solr.
> * Transforming result sets after they are retrieved from Solr.
> * Analyzing and modeling result sets using probability and statistics and 
> machine learning libraries.
> * Visualizing result sets, aggregations and statistical models of the data.
> {code}
>  
> A few sample visualizations are attached to the ticket.



--
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-13105) A visual guide to Solr Math Expressions and Streaming Expressions

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13105:


Commit 928acb6f3e6668fc955d1300ba366f9644cf8c44 in lucene-solr's branch 
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=928acb6 ]

SOLR-13105: Add trend line


> A visual guide to Solr Math Expressions and Streaming Expressions
> -
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: Screen Shot 2019-01-14 at 10.56.32 AM.png, Screen Shot 
> 2019-02-21 at 2.14.43 PM.png, Screen Shot 2019-03-03 at 2.28.35 PM.png, 
> Screen Shot 2019-03-04 at 7.47.57 PM.png, Screen Shot 2019-03-13 at 10.47.47 
> AM.png, Screen Shot 2019-03-30 at 6.17.04 PM.png
>
>
> Visualization is now a fundamental element of Solr Streaming Expressions and 
> Math Expressions. This ticket will create a visual guide to Solr Math 
> Expressions and Solr Streaming Expressions that includes *Apache Zeppelin* 
> visualization examples.
> It will also cover using the JDBC expression to *analyze* and *visualize* 
> results from any JDBC compliant data source.
> Intro from the guide:
> {code:java}
> Streaming Expressions exposes the capabilities of Solr Cloud as composable 
> functions. These functions provide a system for searching, transforming, 
> analyzing and visualizing data stored in Solr Cloud collections.
> At a high level there are four main capabilities that will be explored in the 
> documentation:
> * Searching, sampling and aggregating results from Solr.
> * Transforming result sets after they are retrieved from Solr.
> * Analyzing and modeling result sets using probability and statistics and 
> machine learning libraries.
> * Visualizing result sets, aggregations and statistical models of the data.
> {code}
>  
> A few sample visualizations are attached to the ticket.



--
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-13105) A visual guide to Solr Math Expressions and Streaming Expressions

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13105:


Commit 54bc7e63bef0ae150306e27c5b6e375e69df82fe in lucene-solr's branch 
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=54bc7e6 ]

SOLR-13105: New aggs image


> A visual guide to Solr Math Expressions and Streaming Expressions
> -
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: Screen Shot 2019-01-14 at 10.56.32 AM.png, Screen Shot 
> 2019-02-21 at 2.14.43 PM.png, Screen Shot 2019-03-03 at 2.28.35 PM.png, 
> Screen Shot 2019-03-04 at 7.47.57 PM.png, Screen Shot 2019-03-13 at 10.47.47 
> AM.png, Screen Shot 2019-03-30 at 6.17.04 PM.png
>
>
> Visualization is now a fundamental element of Solr Streaming Expressions and 
> Math Expressions. This ticket will create a visual guide to Solr Math 
> Expressions and Solr Streaming Expressions that includes *Apache Zeppelin* 
> visualization examples.
> It will also cover using the JDBC expression to *analyze* and *visualize* 
> results from any JDBC compliant data source.
> Intro from the guide:
> {code:java}
> Streaming Expressions exposes the capabilities of Solr Cloud as composable 
> functions. These functions provide a system for searching, transforming, 
> analyzing and visualizing data stored in Solr Cloud collections.
> At a high level there are four main capabilities that will be explored in the 
> documentation:
> * Searching, sampling and aggregating results from Solr.
> * Transforming result sets after they are retrieved from Solr.
> * Analyzing and modeling result sets using probability and statistics and 
> machine learning libraries.
> * Visualizing result sets, aggregations and statistical models of the data.
> {code}
>  
> A few sample visualizations are attached to the ticket.



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

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-12) - Build # 24201 - Unstable!

[Policeman Jenkins Server]

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

3 tests failed.
FAILED:  org.apache.solr.cloud.TestCloudRecovery.corruptedLogTest

Error Message:
Timeout occurred while waiting response from server at: 
http://127.0.0.1:40465/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occurred while 
waiting response from server at: http://127.0.0.1:40465/solr
at 
__randomizedtesting.SeedInfo.seed([A89E196C32CA3E8A:2BE8469EE4B3302B]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:667)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java: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:211)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228)
at 
org.apache.solr.cloud.TestCloudRecovery.beforeTest(TestCloudRecovery.java:78)
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$9.evaluate(RandomizedRunner.java:972)
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 

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

[Policeman Jenkins Server]

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

5 tests failed.
FAILED:  org.apache.solr.DistributedIntervalFacetingTest.test

Error Message:
Error from server at http://127.0.0.1:36999/er/je/collection1: 
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://[ff01::114]:2/er/je/select

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:36999/er/je/collection1: 
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://[ff01::114]:2/er/je/select
at 
__randomizedtesting.SeedInfo.seed([5BCFDC0959FB5E2A:D39BE3D3F70733D2]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:656)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
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.BaseDistributedSearchTestCase.queryServer(BaseDistributedSearchTestCase.java:626)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:678)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:643)
at 
org.apache.solr.DistributedIntervalFacetingTest.doTestQuery(DistributedIntervalFacetingTest.java:192)
at 
org.apache.solr.DistributedIntervalFacetingTest.testRandom(DistributedIntervalFacetingTest.java:161)
at 
org.apache.solr.DistributedIntervalFacetingTest.test(DistributedIntervalFacetingTest.java:47)
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$ShardsRepeatStatement.callStatement(BaseDistributedSearchTestCase.java:1108)
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 

[jira] [Commented] (LUCENE-8817) Combine Nori and Kuromoji DictionaryBuilder

[Tomoko Uchida (JIRA)]

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

Tomoko Uchida commented on LUCENE-8817:
---

For me, it looks like a good starting point to create a directory 
{{analysis/mecab}} and place {{mecab-tools}} module (the option 4) under that.

We are already considering further integration of kuromoij and nori (at 
LUCENE-8816 and LUCENE-8812), and I suppose it would happen sooner or later. So 
how about looking at some ground design from here. For example:
{code:java}
analysis
└── mecab
 ├── common (module: analyzers-mecab-common)
 │   ├── build.xml
 │   └── src
 ├── kuromoji (module: analyzers-mecab-kuromoji)
 │   ├── build.xml
 │   └── src
 ├── nori (module: analyzers-mecab-nori)
 │   ├── build.xml
 │   └── src
 └── tools  (module: analyzers-mecab-tools)
 ├── build.xml
 └── src
{code}
On this issue, only "mecab-tools" module will be added (and the dependency on 
that should be added to current kuromoji and nori).
 That's just an idea and I am not an expert about the shadow maven poms. 
[~rcmuir], [~jim.ferenczi] and [~cm] may have different thoughts.

About the option 2, I don't think that's a good idea to change other modules' 
current structure (analysis-common or icu), opinions?
{quote}I will go ahead if direction is set, but landing will be delayed a 
little.
 The reason is that the build system is going to change. (SOLR-13452)
 But if it does not matter, I will proceed.
{quote}
We need to take care the ongoing change in build infrastructure, but I think it 
would not be a very big concern that stops the work here (and LUCENE-8816) :) 
After pushing the commits to the master, you would be able to backport the 
changes to the gradle branch (I think Mark Miller and others will give you help 
or advice for the work).

> Combine Nori and Kuromoji DictionaryBuilder
> ---
>
> Key: LUCENE-8817
> URL: https://issues.apache.org/jira/browse/LUCENE-8817
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Namgyu Kim
>Priority: Major
>
> This issue is related to LUCENE-8816.
> Currently Nori and Kuromoji Analyzer use the same dictionary structure. 
> (MeCab)
>  If we make combine DictionaryBuilder, we can reduce the code size.
>  But this task may have a dependency on the language.
>  (like HEADER string in BinaryDictionary and CharacterDefinition, methods in 
> BinaryDictionaryWriter, ...)
>  On the other hand, there are many overlapped classes.
> The purpose of this patch is to provide users of Nori and Kuromoji with the 
> same system dictionary generator.
> It may take some time because there is a little workload.
>  The work will be based on the latest master, and if the LUCENE-8816 is 
> finished first, I will pull the latest code and proceed.



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

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

[jira] [Comment Edited] (LUCENE-8817) Combine Nori and Kuromoji DictionaryBuilder

[Tomoko Uchida (JIRA)]

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

Tomoko Uchida edited comment on LUCENE-8817 at 6/9/19 2:45 AM:
---

For me, it looks like a good starting point to create a directory 
{{analysis/mecab}} and place {{mecab-tools}} module (the option 4) under that.

We are already considering further integration of kuromoij and nori (at 
LUCENE-8816 and LUCENE-8812), and I suppose it would happen sooner or later. So 
how about looking at some grand design from here. For example:
{code:java}
analysis
└── mecab
 ├── common (module: analyzers-mecab-common)
 │   ├── build.xml
 │   └── src
 ├── kuromoji (module: analyzers-mecab-kuromoji)
 │   ├── build.xml
 │   └── src
 ├── nori (module: analyzers-mecab-nori)
 │   ├── build.xml
 │   └── src
 └── tools  (module: analyzers-mecab-tools)
 ├── build.xml
 └── src
{code}
On this issue, only "mecab-tools" module will be added (and the dependency on 
that should be added to current kuromoji and nori).
 That's just an idea and I am not an expert about the shadow maven poms. 
[~rcmuir], [~jim.ferenczi] and [~cm] may have different thoughts.

About the option 2, I don't think that's a good idea to change other modules' 
current structure (analysis-common or icu), opinions?
{quote}I will go ahead if direction is set, but landing will be delayed a 
little.
 The reason is that the build system is going to change. (SOLR-13452)
 But if it does not matter, I will proceed.
{quote}
We need to take care the ongoing change in build infrastructure, but I think it 
would not be a very big concern that stops the work here (and LUCENE-8816) :) 
After pushing the commits to the master, you would be able to backport the 
changes to the gradle branch (I think Mark Miller and others will give you help 
or advice for the work).


was (Author: tomoko uchida):
For me, it looks like a good starting point to create a directory 
{{analysis/mecab}} and place {{mecab-tools}} module (the option 4) under that.

We are already considering further integration of kuromoij and nori (at 
LUCENE-8816 and LUCENE-8812), and I suppose it would happen sooner or later. So 
how about looking at some ground design from here. For example:
{code:java}
analysis
└── mecab
 ├── common (module: analyzers-mecab-common)
 │   ├── build.xml
 │   └── src
 ├── kuromoji (module: analyzers-mecab-kuromoji)
 │   ├── build.xml
 │   └── src
 ├── nori (module: analyzers-mecab-nori)
 │   ├── build.xml
 │   └── src
 └── tools  (module: analyzers-mecab-tools)
 ├── build.xml
 └── src
{code}
On this issue, only "mecab-tools" module will be added (and the dependency on 
that should be added to current kuromoji and nori).
 That's just an idea and I am not an expert about the shadow maven poms. 
[~rcmuir], [~jim.ferenczi] and [~cm] may have different thoughts.

About the option 2, I don't think that's a good idea to change other modules' 
current structure (analysis-common or icu), opinions?
{quote}I will go ahead if direction is set, but landing will be delayed a 
little.
 The reason is that the build system is going to change. (SOLR-13452)
 But if it does not matter, I will proceed.
{quote}
We need to take care the ongoing change in build infrastructure, but I think it 
would not be a very big concern that stops the work here (and LUCENE-8816) :) 
After pushing the commits to the master, you would be able to backport the 
changes to the gradle branch (I think Mark Miller and others will give you help 
or advice for the work).

> Combine Nori and Kuromoji DictionaryBuilder
> ---
>
> Key: LUCENE-8817
> URL: https://issues.apache.org/jira/browse/LUCENE-8817
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Namgyu Kim
>Priority: Major
>
> This issue is related to LUCENE-8816.
> Currently Nori and Kuromoji Analyzer use the same dictionary structure. 
> (MeCab)
>  If we make combine DictionaryBuilder, we can reduce the code size.
>  But this task may have a dependency on the language.
>  (like HEADER string in BinaryDictionary and CharacterDefinition, methods in 
> BinaryDictionaryWriter, ...)
>  On the other hand, there are many overlapped classes.
> The purpose of this patch is to provide users of Nori and Kuromoji with the 
> same system dictionary generator.
> It may take some time because there is a little workload.
>  The work will be based on the latest master, and if the LUCENE-8816 is 
> finished first, I will pull the latest code and proceed.



--
This message was sent by 

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/680/
Java: 64bit/jdk-13-ea+18 -XX:-UseCompressedOops -XX:+UseG1GC

4 tests failed.
FAILED:  org.apache.solr.cloud.BasicDistributedZkTest.test

Error Message:
Captured an uncaught exception in thread: Thread[id=19552, 
name=testExecutor-6880-thread-1, state=RUNNABLE, 
group=TGRP-BasicDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=19552, name=testExecutor-6880-thread-1, 
state=RUNNABLE, group=TGRP-BasicDistributedZkTest]
at 
__randomizedtesting.SeedInfo.seed([1260C895C1EA8DBC:9A34F74F6F16E044]:0)
Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:42579/p_o: ADDREPLICA failed to create replica
at __randomizedtesting.SeedInfo.seed([1260C895C1EA8DBC]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:656)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228)
at 
org.apache.solr.cloud.BasicDistributedZkTest.lambda$createCollectionInOneInstance$2(BasicDistributedZkTest.java:760)
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:835)


FAILED:  
org.apache.solr.handler.component.DistributedQueryComponentCustomSortTest.test

Error Message:
Error from server at http://127.0.0.1:46001/collection1: 
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://[ff01::114]:2/select

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:46001/collection1: 
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://[ff01::114]:2/select
at 
__randomizedtesting.SeedInfo.seed([1260C895C1EA8DBC:9A34F74F6F16E044]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:656)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
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.BaseDistributedSearchTestCase.queryServer(BaseDistributedSearchTestCase.java:626)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:678)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:656)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:635)
at 
org.apache.solr.handler.component.DistributedQueryComponentCustomSortTest.test(DistributedQueryComponentCustomSortTest.java:79)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
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 

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1864 - Still Unstable

[Apache Jenkins Server]

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

9 tests failed.
FAILED:  org.apache.lucene.search.TestTopDocsMerge.testSort_1

Error Message:
wrong hit docID expected:<100> but was:<5>

Stack Trace:
java.lang.AssertionError: wrong hit docID expected:<100> but was:<5>
at 
__randomizedtesting.SeedInfo.seed([C72A880F78380C88:51B75C6B86E12DB3]: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.lucene.util.TestUtil.assertConsistent(TestUtil.java:1046)
at 
org.apache.lucene.search.TestTopDocsMerge.testSort(TestTopDocsMerge.java:375)
at 
org.apache.lucene.search.TestTopDocsMerge.testSort_1(TestTopDocsMerge.java:71)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:834)


FAILED:  junit.framework.TestSuite.org.apache.lucene.search.TestTopDocsMerge

Error Message:
2 threads leaked from SUITE scope at org.apache.lucene.search.TestTopDocsMerge: 
1) Thread[id=7680, name=LuceneTestCase-1713-thread-1, state=WAITING, 
group=TGRP-TestTopDocsMerge] at 
java.base@11.0.1/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@11.0.1/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
 at 

[JENKINS] Lucene-Solr-8.1-Windows (64bit/jdk-10.0.1) - Build # 136 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.1-Windows/136/
Java: 64bit/jdk-10.0.1 -XX:+UseCompressedOops -XX:+UseG1GC

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

Error Message:
Expected metric minimums for prefix SECURITY./authentication.: 
{failMissingCredentials=2, authenticated=19, passThrough=9, 
failWrongCredentials=1, requests=31, errors=0}, but got: 
{failMissingCredentials=2, authenticated=18, passThrough=11, 
totalTime=15208702, failWrongCredentials=1, requestTimes=1541, requests=32, 
errors=0}

Stack Trace:
java.lang.AssertionError: Expected metric minimums for prefix 
SECURITY./authentication.: {failMissingCredentials=2, authenticated=19, 
passThrough=9, failWrongCredentials=1, requests=31, errors=0}, but got: 
{failMissingCredentials=2, authenticated=18, passThrough=11, 
totalTime=15208702, failWrongCredentials=1, requestTimes=1541, requests=32, 
errors=0}
at 
__randomizedtesting.SeedInfo.seed([752F60717940BAE9:C9411663DD133993]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.solr.cloud.SolrCloudAuthTestCase.assertAuthMetricsMinimums(SolrCloudAuthTestCase.java:129)
at 
org.apache.solr.cloud.SolrCloudAuthTestCase.assertAuthMetricsMinimums(SolrCloudAuthTestCase.java:83)
at 
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:306)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 

[jira] [Commented] (SOLR-13532) Unable to start core recovery due to timeout in ping request

[Gus Heck (JIRA)]

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

Gus Heck commented on SOLR-13532:
-

Hard coded timeouts are a general problem in several areas. I opened SOLR-13457 
a little while ago to track these sorts of problems.

> Unable to start core recovery due to timeout in ping request
> 
>
> Key: SOLR-13532
> URL: https://issues.apache.org/jira/browse/SOLR-13532
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 7.6
>Reporter: Suril Shah
>Priority: Major
>
> Discovered following issue with the core recovery:
>  * Core recovery is not being initialized and throwing following exception 
> message :
> {code:java}
> 2019-06-07 00:53:12.436 INFO  
> (recoveryExecutor-4-thread-1-processing-n::8983_solr 
> x:_shard41_replica_n2777 c: s:shard41 
> r:core_node2778) x:_shard41_replica_n2777 
> o.a.s.c.RecoveryStrategy Failed to connect leader http://:8983/solr 
> on recovery, try again{code}
>  * Above error occurs when ping request takes time more than a timeout period 
> which is hard-coded to one second in solr source code. However In a general 
> production setting it is common to have ping time more than one second, 
> hence, the core recovery never starts and exception is thrown.
>  * Also the other major concern is that this exception is logged as an info 
> message, hence it is very difficult to identify the error if info logging is 
> not enabled.
>  * Please refer to following code snippet from the [source 
> code|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java#L789-L803]
>  to understand the above issue.
> {code:java}
>   try (HttpSolrClient httpSolrClient = new 
> HttpSolrClient.Builder(leaderReplica.getCoreUrl())
>   .withSocketTimeout(1000)
>   .withConnectionTimeout(1000)
>   
> .withHttpClient(cc.getUpdateShardHandler().getRecoveryOnlyHttpClient())
>   .build()) {
> SolrPingResponse resp = httpSolrClient.ping();
> return leaderReplica;
>   } catch (IOException e) {
> log.info("Failed to connect leader {} on recovery, try again", 
> leaderReplica.getBaseUrl());
> Thread.sleep(500);
>   } catch (Exception e) {
> if (e.getCause() instanceof IOException) {
>   log.info("Failed to connect leader {} on recovery, try again", 
> leaderReplica.getBaseUrl());
>   Thread.sleep(500);
> } else {
>   return leaderReplica;
> }
>   }
> {code}
> The above issue will have high impact in production level clusters, since 
> cores not being able to recover may lead to data loss.
> Following improvements would be really helpful:
>  1. The [timeout for ping 
> request|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java#L790-L791]
>  in *RecoveryStrategy.java* should be configurable and the defaults set to 
> high values like 15seconds.
>  2. The exception message in [line 
> 797|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java#L797]
>  and [line 
> 801|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java#L801]
>  in *RecoveryStrategy.java* should be logged as *error* messages instead of 
> *info* messages



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

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

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

[Policeman Jenkins Server]

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

9 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestCloudSearcherWarming

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.cloud.TestCloudSearcherWarming: 1) Thread[id=3314, 
name=Thread-650, state=RUNNABLE, group=TGRP-TestCloudSearcherWarming] 
at java.base@11/java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)  
   at 
java.base@11/java.net.InetAddress$PlatformNameService.lookupAllHostAddr(InetAddress.java:928)
 at 
java.base@11/java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1514)
 at 
java.base@11/java.net.InetAddress$NameServiceAddresses.get(InetAddress.java:847)
 at 
java.base@11/java.net.InetAddress.getAllByName0(InetAddress.java:1504) 
at java.base@11/java.net.InetAddress.getLocalHost(InetAddress.java:1636)
 at 
app//org.apache.solr.handler.admin.SystemInfoHandler.initHostname(SystemInfoHandler.java:111)
 at 
app//org.apache.solr.handler.admin.SystemInfoHandler.(SystemInfoHandler.java:98)
 at 
app//org.apache.solr.handler.admin.SystemInfoHandler.(SystemInfoHandler.java:92)
 at 
jdk.internal.reflect.GeneratedConstructorAccessor77.newInstance(Unknown Source) 
at 
java.base@11/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 at 
java.base@11/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
 at 
app//org.apache.solr.core.SolrResourceLoader.newInstance(SolrResourceLoader.java:638)
 at 
app//org.apache.solr.core.SolrResourceLoader.newInstance(SolrResourceLoader.java:591)
 at 
app//org.apache.solr.core.SolrResourceLoader.newInstance(SolrResourceLoader.java:584)
 at 
app//org.apache.solr.core.SolrCore.createInstance(SolrCore.java:812) at 
app//org.apache.solr.core.PluginBag.createPlugin(PluginBag.java:141) at 
app//org.apache.solr.core.PluginBag.init(PluginBag.java:277) at 
app//org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers.java:130)
 at app//org.apache.solr.core.SolrCore.(SolrCore.java:984)
 at app//org.apache.solr.core.SolrCore.reload(SolrCore.java:671) at 
app//org.apache.solr.core.CoreContainer.reload(CoreContainer.java:1491) 
at 
app//org.apache.solr.core.SolrCore.lambda$getConfListener$21(SolrCore.java:3044)
 at 
app//org.apache.solr.core.SolrCore$$Lambda$636/0x0001006ef840.run(Unknown 
Source) at 
app//org.apache.solr.cloud.ZkController.lambda$fireEventListeners$14(ZkController.java:2509)
 at 
app//org.apache.solr.cloud.ZkController$$Lambda$1029/0x000100af4840.run(Unknown
 Source) at java.base@11/java.lang.Thread.run(Thread.java:834)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.cloud.TestCloudSearcherWarming: 
   1) Thread[id=3314, name=Thread-650, state=RUNNABLE, 
group=TGRP-TestCloudSearcherWarming]
at java.base@11/java.net.Inet6AddressImpl.lookupAllHostAddr(Native 
Method)
at 
java.base@11/java.net.InetAddress$PlatformNameService.lookupAllHostAddr(InetAddress.java:928)
at 
java.base@11/java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1514)
at 
java.base@11/java.net.InetAddress$NameServiceAddresses.get(InetAddress.java:847)
at 
java.base@11/java.net.InetAddress.getAllByName0(InetAddress.java:1504)
at java.base@11/java.net.InetAddress.getLocalHost(InetAddress.java:1636)
at 
app//org.apache.solr.handler.admin.SystemInfoHandler.initHostname(SystemInfoHandler.java:111)
at 
app//org.apache.solr.handler.admin.SystemInfoHandler.(SystemInfoHandler.java:98)
at 
app//org.apache.solr.handler.admin.SystemInfoHandler.(SystemInfoHandler.java:92)
at 
jdk.internal.reflect.GeneratedConstructorAccessor77.newInstance(Unknown Source)
at 
java.base@11/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at 
java.base@11/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
at 
app//org.apache.solr.core.SolrResourceLoader.newInstance(SolrResourceLoader.java:638)
at 
app//org.apache.solr.core.SolrResourceLoader.newInstance(SolrResourceLoader.java:591)
at 
app//org.apache.solr.core.SolrResourceLoader.newInstance(SolrResourceLoader.java:584)
at app//org.apache.solr.core.SolrCore.createInstance(SolrCore.java:812)
at app//org.apache.solr.core.PluginBag.createPlugin(PluginBag.java:141)
at app//org.apache.solr.core.PluginBag.init(PluginBag.java:277)
at 
app//org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers.java:130)
at 

[jira] [Commented] (SOLR-13105) A visual guide to Solr Math Expressions and Streaming Expressions

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13105:


Commit f01110c06336e74fcdcda095aacb56345f59054a in lucene-solr's branch 
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f01110c ]

SOLR-13105: Remove first diff


> A visual guide to Solr Math Expressions and Streaming Expressions
> -
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: Screen Shot 2019-01-14 at 10.56.32 AM.png, Screen Shot 
> 2019-02-21 at 2.14.43 PM.png, Screen Shot 2019-03-03 at 2.28.35 PM.png, 
> Screen Shot 2019-03-04 at 7.47.57 PM.png, Screen Shot 2019-03-13 at 10.47.47 
> AM.png, Screen Shot 2019-03-30 at 6.17.04 PM.png
>
>
> Visualization is now a fundamental element of Solr Streaming Expressions and 
> Math Expressions. This ticket will create a visual guide to Solr Math 
> Expressions and Solr Streaming Expressions that includes *Apache Zeppelin* 
> visualization examples.
> It will also cover using the JDBC expression to *analyze* and *visualize* 
> results from any JDBC compliant data source.
> Intro from the guide:
> {code:java}
> Streaming Expressions exposes the capabilities of Solr Cloud as composable 
> functions. These functions provide a system for searching, transforming, 
> analyzing and visualizing data stored in Solr Cloud collections.
> At a high level there are four main capabilities that will be explored in the 
> documentation:
> * Searching, sampling and aggregating results from Solr.
> * Transforming result sets after they are retrieved from Solr.
> * Analyzing and modeling result sets using probability and statistics and 
> machine learning libraries.
> * Visualizing result sets, aggregations and statistical models of the data.
> {code}
>  
> A few sample visualizations are attached to the ticket.



--
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 (64bit/jdk-11.0.2) - Build # 402 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.1-Linux/402/
Java: 64bit/jdk-11.0.2 -XX:-UseCompressedOops -XX:+UseSerialGC

15 tests failed.
FAILED:  org.apache.solr.cloud.DeleteReplicaTest.deleteLiveReplicaTest

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

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


FAILED:  
org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica

Error Message:
Timeout occurred while waiting response from server at: 
http://127.0.0.1:32927/solr

Stack Trace: