[jira] [Commented] (LUCENE-8369) Remove the spatial module as it is obsolete

[Lucene/Solr QA (JIRA)]

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

Lucene/Solr QA commented on LUCENE-8369:


| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 1 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
54s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:red}-1{color} | {color:red} compile {color} | {color:red}  0m  
2s{color} | {color:red} spatial in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red}  0m  2s{color} 
| {color:red} spatial in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red}  0m 46s{color} 
| {color:red} lucene_spatial-extras generated 4 new + 6 unchanged - 0 fixed = 
10 total (was 6) {color} |
| {color:red}-1{color} | {color:red} Release audit (RAT) {color} | {color:red}  
0m  2s{color} | {color:red} spatial in the patch failed. {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  0m 46s{color} | {color:green} Release audit (RAT) rat-sources 
passed {color} |
| {color:red}-1{color} | {color:red} Check forbidden APIs {color} | {color:red} 
 0m  2s{color} | {color:red} spatial in the patch failed. {color} |
| {color:red}-1{color} | {color:red} Validate source patterns {color} | 
{color:red}  0m  2s{color} | {color:red} spatial in the patch failed. {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}  0m  2s{color} 
| {color:red} spatial in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  2m 
15s{color} | {color:green} spatial-extras in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black}  4m 25s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-8369 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12929126/LUCENE-8369.patch |
| Optional Tests |  ratsources  validatesourcepatterns  compile  javac  unit  
checkforbiddenapis  |
| uname | Linux lucene1-us-west 3.13.0-88-generic #135-Ubuntu SMP Wed Jun 8 
21:10:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-LUCENE-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / 6ab3ff8 |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on July 24 2018 |
| Default Java | 1.8.0_172 |
| compile | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/54/artifact/out/patch-compile-lucene_spatial.txt
 |
| javac | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/54/artifact/out/patch-compile-lucene_spatial.txt
 |
| javac | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/54/artifact/out/diff-compile-javac-lucene_spatial-extras.txt
 |
| Release audit (RAT) | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/54/artifact/out/patch-compile-lucene_spatial.txt
 |
| Check forbidden APIs | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/54/artifact/out/patch-compile-lucene_spatial.txt
 |
| Validate source patterns | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/54/artifact/out/patch-compile-lucene_spatial.txt
 |
| unit | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/54/artifact/out/patch-unit-lucene_spatial.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/54/testReport/ |
| modules | C: lucene lucene/spatial lucene/spatial-extras U: lucene |
| Console output | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/54/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Remove the spatial module as it is obsolete
> ---
>
> Key: LUCENE-8369
> URL: https://issues.apache.org/jira/browse/LUCENE-8369
> Project: Lucene - Core
>  Issue Type: Task
>  Components: modules/spatial
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: LUCENE-8369.patch
>
>
> The "spatial" module is at this juncture nearly empty with only a couple 
> utilities that aren't used by anything in the entire codebase -- 
> GeoRelationUtils, and MortonEncoder.  Perhaps it should have been removed 
> earlier in LUCENE-7664 which was the removal of GeoPointField which was 
> essentially 

[JENKINS-EA] Lucene-Solr-BadApples-master-Linux (64bit/jdk-11-ea+23) - Build # 70 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-master-Linux/70/
Java: 64bit/jdk-11-ea+23 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

53 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates

Error Message:


Stack Trace:
java.lang.NullPointerException
at __randomizedtesting.SeedInfo.seed([B9BD4F792E6E3242]:0)
at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.createMiniSolrCloudCluster(TestStressCloudBlindAtomicUpdates.java:138)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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:  
junit.framework.TestSuite.org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates

Error Message:


Stack Trace:
java.lang.NullPointerException
at __randomizedtesting.SeedInfo.seed([B9BD4F792E6E3242]:0)
at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.afterClass(TestStressCloudBlindAtomicUpdates.java:158)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:897)
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 

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

[Apache Jenkins Server]

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

7 tests failed.
FAILED:  
org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitMixedReplicaTypes

Error Message:
unexpected shard state expected: but was:

Stack Trace:
java.lang.AssertionError: unexpected shard state expected: but 
was:
at 
__randomizedtesting.SeedInfo.seed([AFA5901DD60A7218:1766C4BD2AD1A76D]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at 
org.apache.solr.cloud.api.collections.ShardSplitTest.verifyShard(ShardSplitTest.java:380)
at 
org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitMixedReplicaTypes(ShardSplitTest.java:372)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1008)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:983)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)

[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 1077 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/1077/

No tests ran.

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

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

-dist-keys:
  [get] Getting: http://home.apache.org/keys/group/lucene.asc
  [get] To: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/KEYS

package:

-unpack-solr-tgz:

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

generate-maven-artifacts:

resolve:

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 

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

[Policeman Jenkins Server]

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

5 tests failed.
FAILED:  org.apache.solr.handler.TestReplicationHandler.doTestStressReplication

Error Message:
found:2[index.20180726052515836, index.20180726052516685, index.properties, 
replication.properties, snapshot_metadata]

Stack Trace:
java.lang.AssertionError: found:2[index.20180726052515836, 
index.20180726052516685, index.properties, replication.properties, 
snapshot_metadata]
at 
__randomizedtesting.SeedInfo.seed([66813C38D75BE2BC:BD2A3CFED2738B0F]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:969)
at 
org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:940)
at 
org.apache.solr.handler.TestReplicationHandler.doTestStressReplication(TestReplicationHandler.java:916)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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 

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  
org.apache.solr.handler.component.InfixSuggestersTest.testShutdownDuringBuild

Error Message:
junit.framework.AssertionFailedError: Unexpected wrapped exception type, 
expected CoreIsClosedException

Stack Trace:
java.util.concurrent.ExecutionException: junit.framework.AssertionFailedError: 
Unexpected wrapped exception type, expected CoreIsClosedException
at 
__randomizedtesting.SeedInfo.seed([F209A10A941C1996:2D84C3B5AA754CF4]:0)
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at 
org.apache.solr.handler.component.InfixSuggestersTest.testShutdownDuringBuild(InfixSuggestersTest.java:130)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: junit.framework.AssertionFailedError: Unexpected wrapped 

[JENKINS] Lucene-Solr-BadApples-Tests-7.x - Build # 111 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-7.x/111/

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

Error Message:
Test abandoned because suite timeout was reached.

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


FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.HttpPartitionTest

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

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


FAILED:  org.apache.solr.search.TestRecovery.testExistOldBufferLog

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([7E8A73E785BEAAD1:20DA6EB20B713A58]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertFalse(Assert.java:68)
at org.junit.Assert.assertFalse(Assert.java:79)
at 
org.apache.solr.search.TestRecovery.testExistOldBufferLog(TestRecovery.java:1073)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

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

[Policeman Jenkins Server]

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

3 tests failed.
FAILED:  
org.apache.solr.handler.component.InfixSuggestersTest.testShutdownDuringBuild

Error Message:
junit.framework.AssertionFailedError: Unexpected wrapped exception type, 
expected CoreIsClosedException

Stack Trace:
java.util.concurrent.ExecutionException: junit.framework.AssertionFailedError: 
Unexpected wrapped exception type, expected CoreIsClosedException
at 
__randomizedtesting.SeedInfo.seed([A49517DE469233B8:7B18756178FB66DA]:0)
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at 
org.apache.solr.handler.component.InfixSuggestersTest.testShutdownDuringBuild(InfixSuggestersTest.java:130)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: junit.framework.AssertionFailedError: 

[jira] [Commented] (LUCENE-8204) ReqOptSumScorer should leverage sub scorers' per-block max scores

[Lucene/Solr QA (JIRA)]

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

Lucene/Solr QA commented on LUCENE-8204:


| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red}  0m  
0s{color} | {color:red} The patch doesn't appear to include any new or modified 
tests. Please justify why no new tests are needed for this patch. Also please 
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
51s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m 
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  1m 17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  1m 14s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  1m 14s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 37m  
6s{color} | {color:green} core in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  4m 
46s{color} | {color:green} test-framework in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 48m 28s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-8204 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12933048/LUCENE-8204.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP 
Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-LUCENE-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / 6ab3ff8 |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 20 2018 |
| Default Java | 1.8.0_172 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/53/testReport/ |
| modules | C: lucene/core lucene/test-framework U: lucene |
| Console output | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/53/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> ReqOptSumScorer should leverage sub scorers' per-block max scores
> -
>
> Key: LUCENE-8204
> URL: https://issues.apache.org/jira/browse/LUCENE-8204
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-8204.patch
>
>
> Currently it only looks at max scores on the entire segment. Given that 
> per-block max scores usually give lower upper bounds of the score, this 
> should help.
> This is especially important for LUCENE-8197 to work well since the main 
> query would typically be added as a MUST clauses of a boolean query while the 
> query that scores on features would be a SHOULD clause.



--
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-7314) Graduate LatLonPoint to core

[ASF subversion and git services (JIRA)]

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

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

Commit 950b7b6b1b92849721eaed50ecad9711199180e8 in lucene-solr's branch 
refs/heads/branch_7x from [~nknize]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=950b7b6 ]

LUCENE-7314: Graduate LatLonPoint and query classes to core


> Graduate LatLonPoint to core
> 
>
> Key: LUCENE-7314
> URL: https://issues.apache.org/jira/browse/LUCENE-7314
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7314.patch, LUCENE-7314.patch
>
>
> Maybe we should graduate these fields (and related queries) to core for 
> Lucene 6.1?



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

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

[JENKINS] Lucene-Solr-repro - Build # 1041 - Still Unstable

[Apache Jenkins Server]

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

[...truncated 28 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.x/268/consoleText

[repro] Revision: d31e4596192d2486a6272f654720d33f3ddfeda6

[repro] Ant options: -DsmokeTestRelease.java9=/home/jenkins/tools/java/latest1.9
[repro] Repro line:  ant test  -Dtestcase=TestTriggerIntegration 
-Dtests.method=testNodeLostTriggerRestoreState -Dtests.seed=568C9D4B4F793C24 
-Dtests.multiplier=2 -Dtests.locale=es-CO -Dtests.timezone=Europe/Kaliningrad 
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
6ab3ff83923b48d18d885d46ac0ebccf8d526f91
[repro] git fetch
[repro] git checkout d31e4596192d2486a6272f654720d33f3ddfeda6

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

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

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

[...truncated 3335 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.TestTriggerIntegration" -Dtests.showOutput=onerror 
-DsmokeTestRelease.java9=/home/jenkins/tools/java/latest1.9 
-Dtests.seed=568C9D4B4F793C24 -Dtests.multiplier=2 -Dtests.locale=es-CO 
-Dtests.timezone=Europe/Kaliningrad -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

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

[repro] Failures:
[repro]   5/5 failed: 
org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration

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

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

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

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

[...truncated 3335 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.TestTriggerIntegration" -Dtests.showOutput=onerror 
-DsmokeTestRelease.java9=/home/jenkins/tools/java/latest1.9 
-Dtests.seed=568C9D4B4F793C24 -Dtests.multiplier=2 -Dtests.locale=es-CO 
-Dtests.timezone=Europe/Kaliningrad -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

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

[repro] Failures at the tip of branch_7x:
[repro]   1/5 failed: 
org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration
[repro] git checkout 6ab3ff83923b48d18d885d46ac0ebccf8d526f91

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

[...truncated 5 lines...]

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

[JENKINS] Lucene-Solr-7.x-Linux (32bit/jdk1.8.0_172) - Build # 2416 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2416/
Java: 32bit/jdk1.8.0_172 -client -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.ComputePlanActionTest.testNodeLost

Error Message:
org.apache.solr.common.SolrException: 

Stack Trace:
org.apache.solr.common.SolrException: org.apache.solr.common.SolrException: 
at 
__randomizedtesting.SeedInfo.seed([4DD2406E85939C18:F2C78E900679F99E]:0)
at 
org.apache.solr.common.cloud.rule.ImplicitSnitch.getTags(ImplicitSnitch.java:78)
at 
org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchTagValues(SolrClientNodeStateProvider.java:130)
at 
org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.getNodeValues(SolrClientNodeStateProvider.java:122)
at 
org.apache.solr.cloud.autoscaling.ComputePlanActionTest.printState(ComputePlanActionTest.java:151)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:992)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.apache.solr.common.SolrException: 
at 
org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$AutoScalingSnitch.getRemoteInfo(SolrClientNodeStateProvider.java:291)
at 

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

[Apache Jenkins Server]

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

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

[repro] Revision: 3bf98da39f36d862745be166a0a59303c4ed1714

[repro] Ant options: -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
[repro] Repro line:  ant test  -Dtestcase=TestMockDirectoryWrapper 
-Dtests.method=testThreadSafetyInListAll -Dtests.seed=BDA551E5D65E7EDF 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=it-IT -Dtests.timezone=CNT -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[repro] Repro line:  ant test  -Dtestcase=TestLatLonShapeQueries 
-Dtests.method=testRandomBig -Dtests.seed=500649313F881BC1 -Dtests.multiplier=2 
-Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=pt -Dtests.timezone=Pacific/Truk -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
71c0bddd149b7c0364fbba8d31494dcd9f57f1ef
[repro] git fetch
[repro] git checkout 3bf98da39f36d862745be166a0a59303c4ed1714

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

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

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]lucene/test-framework
[repro]   TestMockDirectoryWrapper
[repro]lucene/sandbox
[repro]   TestLatLonShapeQueries
[repro] ant compile-test

[...truncated 156 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.TestMockDirectoryWrapper" -Dtests.showOutput=onerror 
-Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.seed=BDA551E5D65E7EDF -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=it-IT -Dtests.timezone=CNT -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

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

[repro] ant compile-test

[...truncated 110 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.TestLatLonShapeQueries" -Dtests.showOutput=onerror 
-Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.seed=500649313F881BC1 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=pt -Dtests.timezone=Pacific/Truk -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

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

[repro] Failures:
[repro]   2/5 failed: org.apache.lucene.store.TestMockDirectoryWrapper
[repro]   5/5 failed: org.apache.lucene.document.TestLatLonShapeQueries

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

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

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

[...truncated 7 lines...]
[repro] Test suites by module:
[repro]lucene/sandbox
[repro]   TestLatLonShapeQueries
[repro] ant compile-test

[...truncated 178 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.TestLatLonShapeQueries" -Dtests.showOutput=onerror 
-Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.seed=500649313F881BC1 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=pt -Dtests.timezone=Pacific/Truk -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

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

[repro] Failures at the tip of branch_7x:
[repro]   5/5 failed: org.apache.lucene.document.TestLatLonShapeQueries

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

[...truncated 7 lines...]
[repro] Test suites by module:
[repro]lucene/sandbox
[repro]   TestLatLonShapeQueries
[repro] ant compile-test

[...truncated 178 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.TestLatLonShapeQueries" -Dtests.showOutput=onerror 
-Dtests.multiplier=2 

[jira] [Commented] (LUCENE-7314) Graduate LatLonPoint to core

[ASF subversion and git services (JIRA)]

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

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

Commit 6ab3ff83923b48d18d885d46ac0ebccf8d526f91 in lucene-solr's branch 
refs/heads/master from [~nknize]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6ab3ff8 ]

LUCENE-7314: Graduate LatLonPoint and query classes to core


> Graduate LatLonPoint to core
> 
>
> Key: LUCENE-7314
> URL: https://issues.apache.org/jira/browse/LUCENE-7314
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7314.patch, LUCENE-7314.patch
>
>
> Maybe we should graduate these fields (and related queries) to core for 
> Lucene 6.1?



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

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

[jira] [Commented] (LUCENE-8060) Require users to tell us whether they need total hit counts

[Hoss Man (JIRA)]

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

Hoss Man commented on LUCENE-8060:
--

{quote}On the other hand I'm concerned that the "nothing" approach is not very 
usable in practice as it is hard to build a UI with pagination, which I see is 
a very common need. ...
{quote}
Oh, right – because if we default to "0" (or "-1" or whatever means "don't 
track at all") the the consumer of TopDocs doesn't even know if there should be 
a "next" link. yeah, i guess some arbitrary finite positive integer is the 
least bad option.
{quote}... maybe we could add a setter on IndexSearcher?
{quote}
Yeah i dunno... that just feels kind of weird to me – i guess i have two straw 
man concerns about that approach...
 # why have a {{setDefaultNumTotalHitsToTrack(int)}} just for this concept, and 
not a setter for all the other collector concepts that we currently have 
defaults for in the simple search/searchAfter methods (like {{Sort sort}} , 
{{boolean doDocScores}} , {{boolean doMaxScore}} , etc...)
 ** do we want to go down the route of an {{IndexSearcherConfig}} ?
 # this seems like it introduces divergent "intermediate APIs" for users to 
learn about that might frustrate them down the road...
 ** Today, the first time you build an app you just call something like 
{{IndexSearcher.search(myQuery, 100, mySort)}} and you're happy, and then later 
if you decide you want to do something more complicated you read the docs and 
learn about Collectors and you start using the builder methods to create 
collectors that solve common problems, and if you get to the point that those 
don't meet your needs you already understand the collector concept and you can 
write your own (composing existing ones)
 ** if there's IndexSearcher setters that change the default behavior of the 
{{search()}} methods, then that becomes the path of least resistence that 
intermediate users go down to do slightly more complex things, but if they 
reach the point where they want to do something new that doesn't have a setter, 
they have to "start over" learning about how to do searchers, and read up on 
writting/composing collectors w/o having used the out of the box collector 
builds yet.

> Require users to tell us whether they need total hit counts
> ---
>
> Key: LUCENE-8060
> URL: https://issues.apache.org/jira/browse/LUCENE-8060
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: master (8.0)
>
>
> We are getting optimizations when hit counts are not required (sorted 
> indexes, MAXSCORE, short-circuiting of phrase queries) but our users won't 
> benefit from them unless we disable exact hit counts by default or we require 
> them to tell us whether hit counts are required.
> I think making hit counts approximate by default is going to be a bit trappy, 
> so I'm rather leaning towards requiring users to tell us explicitly whether 
> they need total hit counts. I can think of two ways to do that: either by 
> passing a boolean to the IndexSearcher constructor or by adding a boolean to 
> all methods that produce TopDocs instances. I like the latter better but I'm 
> open to discussion or other ideas?



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

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

[jira] [Commented] (SOLR-12589) metrics name should not contains "/" path seperator while using SolrGangliaReporter

[Lucene/Solr QA (JIRA)]

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

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

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} patch {color} | {color:blue}  0m  
3s{color} | {color:blue} The patch file was not named according to SOLR's 
naming conventions. Please see 
https://wiki.apache.org/solr/HowToContribute#Creating_the_patch_file for 
instructions. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red}  0m  
0s{color} | {color:red} The patch doesn't appear to include any new or modified 
tests. Please justify why no new tests are needed for this patch. Also please 
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  3m 
25s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  3m  
3s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  3m  
3s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  3m  3s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  3m  3s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  3m  3s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 76m 54s{color} 
| {color:red} core in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 86m 59s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.cloud.autoscaling.MetricTriggerTest |
|   | solr.servlet.HttpSolrCallGetCoreTest |
|   | solr.handler.admin.SegmentsInfoRequestHandlerTest |
|   | solr.cloud.autoscaling.SearchRateTriggerIntegrationTest |
|   | solr.cloud.DistribCursorPagingTest |
|   | solr.handler.admin.MetricsHandlerTest |
|   | solr.handler.admin.MBeansHandlerTest |
|   | solr.metrics.reporters.solr.SolrCloudReportersTest |
|   | solr.metrics.reporters.solr.SolrShardReporterTest |
|   | solr.cloud.autoscaling.TestPolicyCloud |
|   | solr.cloud.autoscaling.sim.TestTriggerIntegration |
|   | solr.core.RequestHandlersTest |
|   | solr.cloud.autoscaling.SearchRateTriggerTest |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12589 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12933024/SOLR-12589-1.diff |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP 
Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / 71c0bdd |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 20 2018 |
| Default Java | 1.8.0_172 |
| unit | 
https://builds.apache.org/job/PreCommit-SOLR-Build/151/artifact/out/patch-unit-solr_core.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/151/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/151/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> metrics name should not contains "/" path seperator while using 
> SolrGangliaReporter
> ---
>
> Key: SOLR-12589
> URL: https://issues.apache.org/jira/browse/SOLR-12589
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.3.1, 7.4, master (8.0)
>Reporter: weizhenyuan
>Priority: Minor
> Fix For: master (8.0)
>
> Attachments: SOLR-12589-1.diff
>
>
> As I was using  SolrGangliaReporter,  default metrics names will contains 
> "/", which is 
> offen used in FileSystem as an seperator, than it encounters  ERROR cause 
> creating 
> metrics data file failed,  bellow is the Exception in  /var/log/messages:
> Jul 25 15:01:37 hb-bp1tg6t003y04p201-001 gmetad: Unable to write 

[jira] [Commented] (LUCENE-8060) Require users to tell us whether they need total hit counts

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8060:
--

I'd like to avoid IndexSearcher doing "nothing" or "everything". "everything" 
has the downside that it makes queries slow. On the other hand I'm concerned 
that the "nothing" approach is not very usable in practice as it is hard to 
build a UI with pagination, which I see is a very common need. I wouldn't like 
that simple use-cases can't use the simple search() methods on IndexSearcher 
and need to create collectors manually.

It is true that a value of 1000 or 10,000 feels arbitrary and might not be 
ideal for everybody depending on data volumes or use-case, but maybe we could 
add a setter on IndexSearcher?

> Require users to tell us whether they need total hit counts
> ---
>
> Key: LUCENE-8060
> URL: https://issues.apache.org/jira/browse/LUCENE-8060
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: master (8.0)
>
>
> We are getting optimizations when hit counts are not required (sorted 
> indexes, MAXSCORE, short-circuiting of phrase queries) but our users won't 
> benefit from them unless we disable exact hit counts by default or we require 
> them to tell us whether hit counts are required.
> I think making hit counts approximate by default is going to be a bit trappy, 
> so I'm rather leaning towards requiring users to tell us explicitly whether 
> they need total hit counts. I can think of two ways to do that: either by 
> passing a boolean to the IndexSearcher constructor or by adding a boolean to 
> all methods that produce TopDocs instances. I like the latter better but I'm 
> open to discussion or other ideas?



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

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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.handler.component.InfixSuggestersTest.testShutdownDuringBuild

Error Message:
junit.framework.AssertionFailedError: Unexpected wrapped exception type, 
expected CoreIsClosedException

Stack Trace:
java.util.concurrent.ExecutionException: junit.framework.AssertionFailedError: 
Unexpected wrapped exception type, expected CoreIsClosedException
at 
__randomizedtesting.SeedInfo.seed([216495DF9F0D91A7:FEE9F760A164C4C5]:0)
at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
at 
org.apache.solr.handler.component.InfixSuggestersTest.testShutdownDuringBuild(InfixSuggestersTest.java:130)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: junit.framework.AssertionFailedError: Unexpected wrapped 

[jira] [Resolved] (SOLR-12581) add a "min_popularity" option to relatedness() aggregation that forces scores to -Inf if fg/bg pops don't meet a threshold

[Hoss Man (JIRA)]

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

Hoss Man resolved SOLR-12581.
-
   Resolution: Fixed
Fix Version/s: 7.5
   master (8.0)

> add a "min_popularity" option to relatedness() aggregation that forces scores 
> to -Inf if fg/bg pops don't meet a threshold
> --
>
> Key: SOLR-12581
> URL: https://issues.apache.org/jira/browse/SOLR-12581
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Fix For: master (8.0), 7.5
>
> Attachments: SOLR-12581.patch, SOLR-12581.patch
>
>
> as discussed in SOLR-9480 and noted in TODO comments, the original SKG code 
> base had a "min_pop" option that would completely ignore "terms" if the fg/bg 
> popularities weren't above a user specified threshold.  with the 
> implementation of SKG as a {{relatedness()}} aggregation function, we need to 
> leave any actual filtering of buckets by an aggregation result to a future 
> generalized JSON facet enhancement, but what we can do today is implement an 
> optional {{min_popularity}} option on {{relatedness()}} that forces the 
> {{relatedness}} score to -Infinity so buckets that don't meat the threshold 
> at least score "as low as possible"



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

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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.handler.component.InfixSuggestersTest.testShutdownDuringBuild

Error Message:
junit.framework.AssertionFailedError: Unexpected wrapped exception type, 
expected CoreIsClosedException

Stack Trace:
java.util.concurrent.ExecutionException: junit.framework.AssertionFailedError: 
Unexpected wrapped exception type, expected CoreIsClosedException
at 
__randomizedtesting.SeedInfo.seed([74E26E5226461DD1:AB6F0CED182F48B3]:0)
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at 
org.apache.solr.handler.component.InfixSuggestersTest.testShutdownDuringBuild(InfixSuggestersTest.java:130)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: junit.framework.AssertionFailedError: 

[jira] [Commented] (LUCENE-8060) Require users to tell us whether they need total hit counts

[Hoss Man (JIRA)]

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

Hoss Man commented on LUCENE-8060:
--

{quote}I think as long as totalHits is renamed/replaced to force a compilation 
error and draw attention to the need to use a Collector if you want to control 
if/how-much the total number of hits is accurately recorded, it's fine to 
hadcode a default in the IndexSearcher methods that return TopDocs directly ... 
i would go so far as to suggest that in that in that situation, hardcoding 
maxTotalHits/minExactTotalHits to "0" (ie: don't bother trying to track exactly 
at all) would be fine.
{quote}
To elaborate, my thinking is that having the "simple" IndexSearcher  APIs use a 
default of "nothing" (or "everything", ie: 
{{maxTotalHitsToTrack=Integer.MAX_VALUE}} ) seems much easier to 
explain/understand to new users regardless of their index size/usecases then 
some arbitrary positive number like "10,000")

But better still – let's assume:
 * we deprecate/remove {{TopDocs.totalHits}}
 ** replace it with a {{TopDocs.getTotalHits()}}
 * we add an {{int maxTotalHitsToTrack}} option on the collectors (builders)
 ** document it such that any positive number means "track accurate hit count 
up to this amount, after that just stop"
 ** document everything such that if {{maxTotalHitsToTrack}} is set to a 
negative number then then {{TopDocs.getTotalHits()}} will throw an illegal 
state exception.

...then i would suggest that the IndexSearcher methods that return TopDocs 
directly should default to using {{maxTotalHitsToTrack=-1}} .. so any attempt 
to use the "simple" apis makes it really clear it doesn't support hit tracking.

> Require users to tell us whether they need total hit counts
> ---
>
> Key: LUCENE-8060
> URL: https://issues.apache.org/jira/browse/LUCENE-8060
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: master (8.0)
>
>
> We are getting optimizations when hit counts are not required (sorted 
> indexes, MAXSCORE, short-circuiting of phrase queries) but our users won't 
> benefit from them unless we disable exact hit counts by default or we require 
> them to tell us whether hit counts are required.
> I think making hit counts approximate by default is going to be a bit trappy, 
> so I'm rather leaning towards requiring users to tell us explicitly whether 
> they need total hit counts. I can think of two ways to do that: either by 
> passing a boolean to the IndexSearcher constructor or by adding a boolean to 
> all methods that produce TopDocs instances. I like the latter better but I'm 
> open to discussion or other ideas?



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

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

[jira] [Commented] (SOLR-12587) Reuse Lucene's PriorityQueue for the ExportHandler

[Adrien Grand (JIRA)]

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

Adrien Grand commented on SOLR-12587:
-

Oh I see, a chicken-and-egg issue! I think this getSentinelObjet is designed to 
be implemented in an anonymous class. Maybe we should change PriorityQueue to 
take eg. a {{Supplier}} in place of the {{boolean prepopulate}} and remove 
{{getSentinelObject}}.

> Reuse Lucene's PriorityQueue for the ExportHandler
> --
>
> Key: SOLR-12587
> URL: https://issues.apache.org/jira/browse/SOLR-12587
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
>  Labels: export-writer
> Attachments: SOLR-12587.patch
>
>
> We have a priority queue in Lucene  {{org.apache.lucene.utilPriorityQueue}} . 
> The Export Handler also implements a PriorityQueue 
> {{org.apache.solr.handler.export.PriorityQueue}} . Both are obviously very 
> similar with minor API differences. 
>  
> The aim here is to reuse Lucene's PQ and remove the Solr implementation. 
>  



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

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

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

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.lucene.document.TestLatLonShapeQueries.testRandomBig

Error Message:
GC overhead limit exceeded

Stack Trace:
java.lang.OutOfMemoryError: GC overhead limit exceeded
at 
__randomizedtesting.SeedInfo.seed([CBEEC144D17967E0:4CB9BCCB40201B60]:0)
at java.util.Arrays.copyOf(Arrays.java:3181)
at java.util.ArrayList.grow(ArrayList.java:265)
at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:239)
at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:231)
at java.util.ArrayList.add(ArrayList.java:462)
at 
org.apache.lucene.geo.GeoTestUtil.surpriseMePolygon(GeoTestUtil.java:505)
at org.apache.lucene.geo.GeoTestUtil.nextPolygon(GeoTestUtil.java:390)
at 
org.apache.lucene.document.TestLatLonShapeQueries.doTestRandom(TestLatLonShapeQueries.java:127)
at 
org.apache.lucene.document.TestLatLonShapeQueries.testRandomBig(TestLatLonShapeQueries.java:107)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)




Build Log:
[...truncated 10343 lines...]
   [junit4] Suite: org.apache.lucene.document.TestLatLonShapeQueries
   [junit4]   2> NOTE: download the large Jenkins line-docs file by running 
'ant get-jenkins-line-docs' in the lucene directory.
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestLatLonShapeQueries -Dtests.method=testRandomBig 
-Dtests.seed=CBEEC144D17967E0 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt
 -Dtests.locale=sk -Dtests.timezone=America/Port-au-Prince -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] ERROR306s J0 | TestLatLonShapeQueries.testRandomBig <<<
   [junit4]> Throwable #1: java.lang.OutOfMemoryError: GC overhead limit 
exceeded
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([CBEEC144D17967E0:4CB9BCCB40201B60]:0)
   [junit4]>at java.util.Arrays.copyOf(Arrays.java:3181)
   [junit4]>at java.util.ArrayList.grow(ArrayList.java:265)
   [junit4]>at 
java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:239)
   [junit4]>at 
java.util.ArrayList.ensureCapacityInternal(ArrayList.java:231)
   [junit4]>at java.util.ArrayList.add(ArrayList.java:462)
   [junit4]>at 
org.apache.lucene.geo.GeoTestUtil.surpriseMePolygon(GeoTestUtil.java:505)
   [junit4]>at 
org.apache.lucene.geo.GeoTestUtil.nextPolygon(GeoTestUtil.java:390)
   [junit4]>at 

[jira] [Closed] (SOLR-10042) Delete old deprecated Admin UI

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch closed SOLR-10042.


> Delete old deprecated Admin UI
> --
>
> Key: SOLR-10042
> URL: https://issues.apache.org/jira/browse/SOLR-10042
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 7.0
>
> Attachments: SOLR-10042.patch, SOLR-10042_remove_commented.patch
>
>
> The old jQuery based Admin UI has been deprecated since 6.0. Let us clean up 
> the last known bugs in Angular UI and simply delete the old UI in  master.



--
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-8060) Require users to tell us whether they need total hit counts

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8060:
--

{quote}I don't know a lot about how the current estimation code works
{quote}
It assumes that the density of matches is the same in the whole index. So if 
docs are collected exactly until doc id 1000 and there are 1M documents in the 
index, it just multiplies the number of collected documents by 1000. This is 
often a bad estimate and we have no idea of how large the error is.
{quote}would that even be possible?
{quote}
I'm not aware of ways to get good estimates for queries that match many 
documents efficiently, especially conjunctions. So the error bound would be 
terrible in those cases I'm afraid. Maybe we could give a lower bound and an 
upper bound, or an enum that would say whether the hit count is accurate or a 
lower bound of the actual hit count.
{quote}i would go so far as to suggest that in that in that situation, 
hardcoding maxTotalHits/minExactTotalHits to "0" (ie: don't bother trying to 
track exactly at all) would be fine.
{quote}
OK. Thanks for the feedback!

> Require users to tell us whether they need total hit counts
> ---
>
> Key: LUCENE-8060
> URL: https://issues.apache.org/jira/browse/LUCENE-8060
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: master (8.0)
>
>
> We are getting optimizations when hit counts are not required (sorted 
> indexes, MAXSCORE, short-circuiting of phrase queries) but our users won't 
> benefit from them unless we disable exact hit counts by default or we require 
> them to tell us whether hit counts are required.
> I think making hit counts approximate by default is going to be a bit trappy, 
> so I'm rather leaning towards requiring users to tell us explicitly whether 
> they need total hit counts. I can think of two ways to do that: either by 
> passing a boolean to the IndexSearcher constructor or by adding a boolean to 
> all methods that produce TopDocs instances. I like the latter better but I'm 
> open to discussion or other ideas?



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

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

[JENKINS] Lucene-Solr-7.x-Windows (64bit/jdk1.8.0_172) - Build # 714 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/714/
Java: 64bit/jdk1.8.0_172 -XX:+UseCompressedOops -XX:+UseParallelGC

7 tests failed.
FAILED:  
org.apache.solr.cloud.cdcr.CdcrBootstrapTest.testBootstrapWithContinousIndexingOnSourceCluster

Error Message:
Document mismatch on target after sync expected:<2000> but was:<1901>

Stack Trace:
java.lang.AssertionError: Document mismatch on target after sync 
expected:<2000> but was:<1901>
at 
__randomizedtesting.SeedInfo.seed([95D87E0264F5BC01:419D355B83A30FFA]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.cloud.cdcr.CdcrBootstrapTest.testBootstrapWithContinousIndexingOnSourceCluster(CdcrBootstrapTest.java:296)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.security.hadoop.TestDelegationWithHadoopAuth.testDelegationTokenRenew

Error Message:
expected:<200> but was:<403>

Stack Trace:
java.lang.AssertionError: expected:<200> but was:<403>
at 
__randomizedtesting.SeedInfo.seed([24085B44C07ED9CF:1393AF5AF8B2046B]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.security.hadoop.TestDelegationWithHadoopAuth.renewDelegationToken(TestDelegationWithHadoopAuth.java:120)
at 
org.apache.solr.security.hadoop.TestDelegationWithHadoopAuth.verifyDelegationTokenRenew(TestDelegationWithHadoopAuth.java:302)
at 
org.apache.solr.security.hadoop.TestDelegationWithHadoopAuth.testDelegationTokenRenew(TestDelegationWithHadoopAuth.java:319)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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 

Re: Tip: patches from IntelliJ IDEA

[David Smiley]

Maybe... though I find the quickness of a bash/sed script more desirable.
Our ant build has a lot going on as it is.  I could add this to dev-tools
somewhere.

I posted here: https://issues.apache.org/jira/browse/YETUS-645 and it is
getting some traction so lets see where it leads.

On Wed, Jul 25, 2018 at 1:13 PM Erik Hatcher  wrote:

> David -
>
> Would it make sense to bake that into the build file so that it's
> immediately handy?maybe `ant idea-patch-fix`?
>
> Erik
>
>
>
> On Jul 25, 2018, at 10:35 AM, David Smiley 
> wrote:
>
> I use IntelliJ IDEA, and furthermore I use the "create patch" feature to
> generate a patch file.  This is far more convenient than using the CLI when
> there are multiple "change lists", and for other reasons, since at the CLI
> I would have to presumably list out each changed file to include.
>
> However, IntelliJ's patches aren't always compatible with other tools that
> consume patch files.  We use Apache Yetus and it doesn't like them -- it
> won't even kick off a build so you'll never see a comment from it in the
> related JIRA issue.  JetBrains is tracking this patch compatibility
> deficiency and they may improve it in the future but it's been years.
>
> I wrote the following one-liner script on my path that I use to convert a
> patch file in-place.  The only thing that it does that is necessary to make
> Yetus like it is to add the "a/" and "b/" to the file paths in the patch.
> Here it is:
>
> # see https://youtrack.jetbrains.com/issue/IDEA-92793
> sed -i '' -e 's/^--- /--- a\//g' -e 's/^+++ /+++ b\//g' "$1"
>
> I'm sharing this so others know of the issue and may want to use this
> script as well.  I will report it to Yetus; maybe they'll include detection
> of when to do this so I don't have to remember to.
>
> ~ David
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

[jira] [Commented] (LUCENE-8425) Expose hard live docs on SegmentReader level

[Lucene/Solr QA (JIRA)]

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

Lucene/Solr QA commented on LUCENE-8425:


| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:red}-1{color} | {color:red} patch {color} | {color:red}  0m  5s{color} 
| {color:red} LUCENE-8425 does not apply to master. Rebase required? Wrong 
Branch? See 
https://wiki.apache.org/lucene-java/HowToContribute#Contributing_your_work for 
help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-8425 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12933008/LUCENE-8425.patch |
| Console output | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/52/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



>  Expose hard live docs on SegmentReader level
> -
>
> Key: LUCENE-8425
> URL: https://issues.apache.org/jira/browse/LUCENE-8425
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: master (8.0), 7.5
>Reporter: Simon Willnauer
>Priority: Major
> Fix For: master (8.0), 7.5
>
> Attachments: LUCENE-8425.patch, LUCENE-8425.patch
>
>
> Today if soft deletes are used we expose a union of hard and soft deletes
> via LeafReader#getLiveDocs. Yet, if a users wants to take advantage of
> searching also soft-deleted documents the only option today is to search
> all documents even though some of them are hard deleted. The 
> recommendation
> is to not mix those but in exceptional cases ie. when a document hits a
> non-aborting exception during indexing the document is marked as hard
> deleted which is the correct action. In order to filter those out having
> access to the hard live docs on the segment reader level allows to filter 
> out
> these documents.



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

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

[JENKINS] Lucene-Solr-Tests-7.x - Build # 699 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/699/

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

Error Message:
ObjectTracker found 1 object(s) that were not released!!! [TransactionLog] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.update.TransactionLog  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.update.TransactionLog.(TransactionLog.java:188)  at 
org.apache.solr.update.UpdateLog.newTransactionLog(UpdateLog.java:467)  at 
org.apache.solr.update.UpdateLog.ensureLog(UpdateLog.java:1323)  at 
org.apache.solr.update.UpdateLog.add(UpdateLog.java:571)  at 
org.apache.solr.update.UpdateLog.add(UpdateLog.java:551)  at 
org.apache.solr.update.DirectUpdateHandler2.doNormalUpdate(DirectUpdateHandler2.java:345)
  at 
org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:283)
  at 
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:233)
  at 
org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:67)
  at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
  at 
org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:951)
  at 
org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1167)
  at 
org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:634)
  at 
org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)
  at 
org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:98)  
at 
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:188)
  at 
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readIterator(JavaBinUpdateRequestCodec.java:144)
  at org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:311) 
 at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:256)  at 
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readNamedList(JavaBinUpdateRequestCodec.java:130)
  at org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:276) 
 at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:256)  at 
org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:178)  at 
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:195)
  at 
org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(JavabinLoader.java:109)
  at org.apache.solr.handler.loader.JavabinLoader.load(JavabinLoader.java:55)  
at 
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:97)
  at 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2541)  at 
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:709)  at 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:515)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1642)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1642)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533) 
 at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
  at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)  
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:674)  
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) 
 at 

[jira] [Created] (SOLR-12594) MetricsHistoryHandler.getOverseerLeader fails when hostname contains hyphen

[Hoss Man (JIRA)]

Hoss Man created SOLR-12594:
---

 Summary: MetricsHistoryHandler.getOverseerLeader fails when 
hostname contains hyphen
 Key: SOLR-12594
 URL: https://issues.apache.org/jira/browse/SOLR-12594
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man
Assignee: Andrzej Bialecki 


as reported on the user list...

{quote}
We encounter a lot of log warning entries from the MetricsHistoryHandler saying

o.a.s.h.a.MetricsHistoryHandler Unknown format of leader id, skipping:
244550997187166214-server1-b.myhost:8983_solr-n_94


I don't even know what this _MetricsHistoryHandler_ does, but at least there's 
a warning.


Looking at the code you can see that it has to fail if the hostname of the node 
contains a hyphen:
{quote}

{code}
String[] ids = oid.split("-");
if (ids.length != 3) { // unknown format
  log.warn("Unknown format of leader id, skipping: " + oid);
  return null;
}
{code}



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

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

[jira] [Commented] (LUCENE-8060) Require users to tell us whether they need total hit counts

[Hoss Man (JIRA)]

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

Hoss Man commented on LUCENE-8060:
--

I don't know a lot about how the current estimation code works, but would it be 
worthwhile to capture info in the TopDocs about how accurate/confident the 
totalHits is, and instead of an {{int maxTotalHits}} option make it an {{int 
minExactTotalHits}} option?

So if a caller specifies {{minExactTotalHits=5000}} and the resulting 
{{TopDocs.totalHits == 42}} then there would also be a 
{{TopDocs.totalHitsAccuracy == 1.0D}} because we're 100% confident that that's 
the number of hits ... but if {{TopDocs.totalHits == 4200}} then maybe  
{{TopDocs.totalHitsAccuracy == 0.1D}} or maybe {{TopDocs.totalHitsAccuracy == 
0.9D}} depending on how confident the estimation is.

would that even be possible?



bq. Regarding integration in IndexSearcher, I am thinking of 3 ideas:

I think as long as {{totalHits}} is renamed/replaced to force a compilation 
error and draw attention to the need to use a Collector if you want to control 
if/how-much the total number of hits is accurately recorded, it's fine to 
hadcode a default in the IndexSearcher methods that return TopDocs directly ... 
i would go so far as to suggest that in that in that situation, hardcoding 
maxTotalHits/minExactTotalHits to "0" (ie: don't bother trying to track exactly 
at all) would be fine.


> Require users to tell us whether they need total hit counts
> ---
>
> Key: LUCENE-8060
> URL: https://issues.apache.org/jira/browse/LUCENE-8060
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: master (8.0)
>
>
> We are getting optimizations when hit counts are not required (sorted 
> indexes, MAXSCORE, short-circuiting of phrase queries) but our users won't 
> benefit from them unless we disable exact hit counts by default or we require 
> them to tell us whether hit counts are required.
> I think making hit counts approximate by default is going to be a bit trappy, 
> so I'm rather leaning towards requiring users to tell us explicitly whether 
> they need total hit counts. I can think of two ways to do that: either by 
> passing a boolean to the IndexSearcher constructor or by adding a boolean to 
> all methods that produce TopDocs instances. I like the latter better but I'm 
> open to discussion or other ideas?



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

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

[jira] [Commented] (SOLR-12581) add a "min_popularity" option to relatedness() aggregation that forces scores to -Inf if fg/bg pops don't meet a threshold

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12581:


Commit 71c0bddd149b7c0364fbba8d31494dcd9f57f1ef in lucene-solr's branch 
refs/heads/master from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=71c0bdd ]

SOLR-12581: the JSON Facet 'relatedness()' aggregate function now supports a 
'min_popularity' option using the extended type:func syntax


> add a "min_popularity" option to relatedness() aggregation that forces scores 
> to -Inf if fg/bg pops don't meet a threshold
> --
>
> Key: SOLR-12581
> URL: https://issues.apache.org/jira/browse/SOLR-12581
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-12581.patch, SOLR-12581.patch
>
>
> as discussed in SOLR-9480 and noted in TODO comments, the original SKG code 
> base had a "min_pop" option that would completely ignore "terms" if the fg/bg 
> popularities weren't above a user specified threshold.  with the 
> implementation of SKG as a {{relatedness()}} aggregation function, we need to 
> leave any actual filtering of buckets by an aggregation result to a future 
> generalized JSON facet enhancement, but what we can do today is implement an 
> optional {{min_popularity}} option on {{relatedness()}} that forces the 
> {{relatedness}} score to -Infinity so buckets that don't meat the threshold 
> at least score "as low as possible"



--
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-12581) add a "min_popularity" option to relatedness() aggregation that forces scores to -Inf if fg/bg pops don't meet a threshold

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12581:


Commit cf9c3c11a28deff188f4edb5ee5cdd0637cdb958 in lucene-solr's branch 
refs/heads/branch_7x from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=cf9c3c1 ]

SOLR-12581: the JSON Facet 'relatedness()' aggregate function now supports a 
'min_popularity' option using the extended type:func syntax

(cherry picked from commit 71c0bddd149b7c0364fbba8d31494dcd9f57f1ef)


> add a "min_popularity" option to relatedness() aggregation that forces scores 
> to -Inf if fg/bg pops don't meet a threshold
> --
>
> Key: SOLR-12581
> URL: https://issues.apache.org/jira/browse/SOLR-12581
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-12581.patch, SOLR-12581.patch
>
>
> as discussed in SOLR-9480 and noted in TODO comments, the original SKG code 
> base had a "min_pop" option that would completely ignore "terms" if the fg/bg 
> popularities weren't above a user specified threshold.  with the 
> implementation of SKG as a {{relatedness()}} aggregation function, we need to 
> leave any actual filtering of buckets by an aggregation result to a future 
> generalized JSON facet enhancement, but what we can do today is implement an 
> optional {{min_popularity}} option on {{relatedness()}} that forces the 
> {{relatedness}} score to -Infinity so buckets that don't meat the threshold 
> at least score "as low as possible"



--
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-2562) Make Luke a Lucene/Solr Module

[Tomoko Uchida (JIRA)]

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

Tomoko Uchida commented on LUCENE-2562:
---

Sure, this is LUCENE's issue  ;)

> Make Luke a Lucene/Solr Module
> --
>
> Key: LUCENE-2562
> URL: https://issues.apache.org/jira/browse/LUCENE-2562
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Mark Miller
>Priority: Major
>  Labels: gsoc2014
> Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, 
> LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, 
> LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, 
> Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, 
> luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> see
> "RE: Luke - in need of maintainer": 
> http://markmail.org/message/m4gsto7giltvrpuf
> "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q
> I think it would be great if there was a version of Luke that always worked 
> with trunk - and it would also be great if it was easier to match Luke jars 
> with Lucene versions.
> While I'd like to get GWT Luke into the mix as well, I think the easiest 
> starting point is to straight port Luke to another UI toolkit before 
> abstracting out DTO objects that both GWT Luke and Pivot Luke could share.
> I've started slowly converting Luke's use of thinlet to Apache Pivot. I 
> haven't/don't have a lot of time for this at the moment, but I've plugged 
> away here and there over the past work or two. There is still a *lot* to do.



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

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

[JENKINS] Lucene-Solr-master-Windows (64bit/jdk1.8.0_172) - Build # 7446 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7446/
Java: 64bit/jdk1.8.0_172 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

10 tests failed.
FAILED:  org.apache.solr.cloud.CollectionsAPISolrJTest.testAddAndDeleteReplica

Error Message:
Error from server at http://127.0.0.1:50347/solr: Error waiting for corenode 
gone

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:50347/solr: Error waiting for corenode gone
at 
__randomizedtesting.SeedInfo.seed([461AC99190E46CC7:A8AAB0C497287B7D]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1106)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:886)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:819)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.cloud.CollectionsAPISolrJTest.testAddAndDeleteReplica(CollectionsAPISolrJTest.java:357)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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 

Re: Tip: patches from IntelliJ IDEA

[Erik Hatcher]

David -

Would it make sense to bake that into the build file so that it's immediately 
handy?maybe `ant idea-patch-fix`?

Erik



> On Jul 25, 2018, at 10:35 AM, David Smiley  wrote:
> 
> I use IntelliJ IDEA, and furthermore I use the "create patch" feature to 
> generate a patch file.  This is far more convenient than using the CLI when 
> there are multiple "change lists", and for other reasons, since at the CLI I 
> would have to presumably list out each changed file to include.
> 
> However, IntelliJ's patches aren't always compatible with other tools that 
> consume patch files.  We use Apache Yetus and it doesn't like them -- it 
> won't even kick off a build so you'll never see a comment from it in the 
> related JIRA issue.  JetBrains is tracking this patch compatibility 
> deficiency and they may improve it in the future but it's been years.
> 
> I wrote the following one-liner script on my path that I use to convert a 
> patch file in-place.  The only thing that it does that is necessary to make 
> Yetus like it is to add the "a/" and "b/" to the file paths in the patch.  
> Here it is:
> 
> # see https://youtrack.jetbrains.com/issue/IDEA-92793 
> 
> sed -i '' -e 's/^--- /--- a\//g' -e 's/^+++ /+++ b\//g' "$1"
> 
> I'm sharing this so others know of the issue and may want to use this script 
> as well.  I will report it to Yetus; maybe they'll include detection of when 
> to do this so I don't have to remember to.
> 
> ~ David
> -- 
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley 
>  | Book: 
> http://www.solrenterprisesearchserver.com 
> 

[jira] [Commented] (LUCENE-2562) Make Luke a Lucene/Solr Module

[Torsten Krah (JIRA)]

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

Torsten Krah commented on LUCENE-2562:
--

Please don't make it a part of solr. The benefit of Luke is to have it 
standalone so you can use it just with plain Lucene. I am not using solr, but 
Lucene, so I would like to see it only with Lucene distribution and not be 
dependent on solr. My 2 cents about this.

> Make Luke a Lucene/Solr Module
> --
>
> Key: LUCENE-2562
> URL: https://issues.apache.org/jira/browse/LUCENE-2562
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Mark Miller
>Priority: Major
>  Labels: gsoc2014
> Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, 
> LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, 
> LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, 
> Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, 
> luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> see
> "RE: Luke - in need of maintainer": 
> http://markmail.org/message/m4gsto7giltvrpuf
> "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q
> I think it would be great if there was a version of Luke that always worked 
> with trunk - and it would also be great if it was easier to match Luke jars 
> with Lucene versions.
> While I'd like to get GWT Luke into the mix as well, I think the easiest 
> starting point is to straight port Luke to another UI toolkit before 
> abstracting out DTO objects that both GWT Luke and Pivot Luke could share.
> I've started slowly converting Luke's use of thinlet to Apache Pivot. I 
> haven't/don't have a lot of time for this at the moment, but I've plugged 
> away here and there over the past work or two. There is still a *lot* to do.



--
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-8060) Require users to tell us whether they need total hit counts

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8060:
--

Our current hit count estimations are terrible. I don't think any user would 
want to rely on them or even display them in a UI. Problem is that hit counts 
are useful from a UI perspective, for instance for pagination, or to improve 
the user experience by giving users a sense of how many matches there are and 
giving confidence in the search engine by showing the user that there is a lot 
of content that matches his query.

I think an ok trade-off that would address the two above use-cases would be to 
only count up to a certain hit count? For instance if you allow users to 
paginate up to page 10 and have 20 hits per page, you only need to count up to 
200 hits to know how many pages to display. Similarly if your end goal is only 
to show users that you have lots of content, you could only count up to eg. 
10,000 matches and show something like "more than 10,000 hits" in the UI if 
that number is reached. In both cases, this should help keep the counting 
overhead contained so that it doesn't end up being the bottleneck of query 
processing?

I believe both TopScoreDocCollector and TopFieldCollector could easily be 
changed in order to replace `boolean trackTotalHits` with something like `int 
maxTotalHits` and we would stop counting after visiting maxTotalHits documents?

Regarding integration in IndexSearcher, I am thinking of 3 ideas:
 - hardcode a value for this parameter, maybe 10,000 and rename 
TopDocs.totalHits to make sure users get a compile error
 - add a parameter to the search() methods to require users to pass a 
maxTotalHits
 - add a required constructor argument to IndexSearcher that would affect all 
search() methods

We could also make the top docs collectors just compute a ScoreDoc[] (ie. no 
total hits) and require users to compute the hit count separately, but I'm 
concerned that it would make simple usage of Lucene harder.

Opinions?

> Require users to tell us whether they need total hit counts
> ---
>
> Key: LUCENE-8060
> URL: https://issues.apache.org/jira/browse/LUCENE-8060
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: master (8.0)
>
>
> We are getting optimizations when hit counts are not required (sorted 
> indexes, MAXSCORE, short-circuiting of phrase queries) but our users won't 
> benefit from them unless we disable exact hit counts by default or we require 
> them to tell us whether hit counts are required.
> I think making hit counts approximate by default is going to be a bit trappy, 
> so I'm rather leaning towards requiring users to tell us explicitly whether 
> they need total hit counts. I can think of two ways to do that: either by 
> passing a boolean to the IndexSearcher constructor or by adding a boolean to 
> all methods that produce TopDocs instances. I like the latter better but I'm 
> open to discussion or other ideas?



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

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

[jira] [Updated] (SOLR-12542) Trying to export on a non doc-values field gives no response

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-12542:
-
Labels: export-writer  (was: )

> Trying to export on a non doc-values field gives no response
> 
>
> Key: SOLR-12542
> URL: https://issues.apache.org/jira/browse/SOLR-12542
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Priority: Major
>  Labels: export-writer
> Attachments: chrome.png
>
>
> I wanted to see the current behaviour of the export writer when it came to 
> boolean fields and ran into this issue.
> Start solr: ./bin/solr start -e cloud -noprompt
> {code:java}
> ~/solr-7.4.0$ curl -v 
> "http://localhost:8983/solr/gettingstarted/export/?q=*:*=a_b%20desc=id;
> * Trying ::1...
> * TCP_NODELAY set
> * Connected to localhost (::1) port 8983 (#0)
> > GET /solr/gettingstarted/export/?q=*:*=a_b%20desc=id HTTP/1.1
> > Host: localhost:8983
> > User-Agent: curl/7.54.0
> > Accept: */*
> > 
> < HTTP/1.1 500 Server Error
> < Content-Type: application/octet-stream
> < Content-Length: 0
> < 
> * Connection #0 to host localhost left intact{code}
>  
> This basically comes back with no response, and unless you look at the server 
> logs can't tell what the error is. Chrome displays the attached screenshot 
> which is what confused me to start with. 
> From the logs
> {code:java}
> ERROR - 2018-07-09 12:04:53.951; [c:gettingstarted s:shard2 r:core_node8 
> x:gettingstarted_shard2_replica_n6] org.apache.solr.servlet.HttpSolrCall; 
> null:java.io.IOException: a_b must have DocValues to use this feature.
> at org.apache.solr.handler.ExportWriter.getSortDoc(ExportWriter.java:389)
> at org.apache.solr.handler.ExportWriter.writeDocs(ExportWriter.java:231)
> at org.apache.solr.handler.ExportWriter.lambda$null$1(ExportWriter.java:222)
> at 
> org.apache.solr.response.JSONWriter.writeIterator(JSONResponseWriter.java:515)
> at 
> org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:179)
> at org.apache.solr.response.JSONWriter$2.put(JSONResponseWriter.java:551)
> at 
> org.apache.solr.handler.ExportWriter.lambda$null$2(ExportWriter.java:222){code}



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

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

[jira] [Updated] (SOLR-12543) Export Handler errors come back with HTTP 200

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-12543:
-
Labels: export-writer  (was: )

> Export Handler errors come back with HTTP 200
> -
>
> Key: SOLR-12543
> URL: https://issues.apache.org/jira/browse/SOLR-12543
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Priority: Major
>  Labels: export-writer
>
> If I do a wrong export query like this we get back http code 200
> {code:java}
> ~/solr-7.4.0$ curl -v 
> "http://localhost:8983/solr/gettingstarted/export/?q=*:*;
> * Trying ::1...
> * TCP_NODELAY set
> * Connected to localhost (::1) port 8983 (#0)
> > GET /solr/gettingstarted/export/?q=*:* HTTP/1.1
> > Host: localhost:8983
> > User-Agent: curl/7.54.0
> > Accept: */*
> > 
> < HTTP/1.1 200 OK
> < Content-Type: json
> < Transfer-Encoding: chunked
> < 
> {
> "responseHeader":{"status":400},
> "response":{
> "numFound":0,
> * Connection #0 to host localhost left intact
> "docs":[{"EXCEPTION":"org.apache.solr.search.SyntaxError: No sort criteria 
> was provided."}]}}
> {code}
>  
> For reference if I do a bad solr query like this we get back a HTTP 400
> {code:java}
> ~/solr-7.4.0$ curl -v http://localhost:8983/solr/gettingstarted/query/?q=a:a
> * Trying ::1...
> * TCP_NODELAY set
> * Connected to localhost (::1) port 8983 (#0)
> > GET /solr/gettingstarted/query/?q=a:a HTTP/1.1
> > Host: localhost:8983
> > User-Agent: curl/7.54.0
> > Accept: */*
> > 
> < HTTP/1.1 400 Bad Request
> < Cache-Control: no-cache, no-store
> < Pragma: no-cache
> < Expires: Sat, 01 Jan 2000 01:00:00 GMT
> < Last-Modified: Mon, 09 Jul 2018 13:12:51 GMT
> < ETag: "1647f2c5e7e"
> < Content-Type: text/plain;charset=utf-8
> < Content-Length: 317
> < 
> {
> "responseHeader":{
> "zkConnected":true,
> "status":400,
> "QTime":1,
> "params":{
> "q":"a:a"}},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"undefined field a",
> "code":400}}
> * Connection #0 to host localhost left intact{code}
>  



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

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

[jira] [Comment Edited] (LUCENE-2562) Make Luke a Lucene/Solr Module

[Tomoko Uchida (JIRA)]

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

Tomoko Uchida edited comment on LUCENE-2562 at 7/25/18 3:34 PM:


[~sokolov] Thanks comments, sure, a tiny http server is always on my mind. (I 
am a just another web engineer, I know there are plenty of nice & light webapp 
frameworks...)

However,  I'm not sure that adding web assets (html, css, js) to Lucene, pure 
Java library, is acceptable. May be server side rendering (JavaScript free) is 
ok? I have no idea.

But web GUI perhaps get the point, when we are in a little bit dark period for 
client applications now.

Apache Pivot, first Mark Miller introduced here, has not been updated for one 
year. So I've switched to JavaFX as a promising framework, this is decoupled 
from JDK and blocked for Apache projects (at least for now.)

 


was (Author: tomoko uchida):
[~sokolov] Thanks comments, sure, a tiny http server is always on my mind. (I 
am a just another web engineer, I know there are plenty of nice & light webapp 
frameworks...)

However,  I'm not sure that adding web assets (html, css, js) to Lucene, pure 
Java library, is acceptable. May be server side rendering (JavaScript free) is 
ok? I have no idea...

 

> Make Luke a Lucene/Solr Module
> --
>
> Key: LUCENE-2562
> URL: https://issues.apache.org/jira/browse/LUCENE-2562
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Mark Miller
>Priority: Major
>  Labels: gsoc2014
> Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, 
> LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, 
> LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, 
> Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, 
> luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> see
> "RE: Luke - in need of maintainer": 
> http://markmail.org/message/m4gsto7giltvrpuf
> "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q
> I think it would be great if there was a version of Luke that always worked 
> with trunk - and it would also be great if it was easier to match Luke jars 
> with Lucene versions.
> While I'd like to get GWT Luke into the mix as well, I think the easiest 
> starting point is to straight port Luke to another UI toolkit before 
> abstracting out DTO objects that both GWT Luke and Pivot Luke could share.
> I've started slowly converting Luke's use of thinlet to Apache Pivot. I 
> haven't/don't have a lot of time for this at the moment, but I've plugged 
> away here and there over the past work or two. There is still a *lot* to do.



--
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-12593) Remove date parsing functionality from extraction contrib

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12593:


Commit 0d7b2f43623c0a7f8b9bf7e6f2b38f611c3bd607 in lucene-solr's branch 
refs/heads/branch_7x from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0d7b2f4 ]

SOLR-10243: Apply @AwaitsFix on TestExtractionDateUtil.testParseDate to be 
fixed by SOLR-12593

(cherry picked from commit 528e8bc)


> Remove date parsing functionality from extraction contrib
> -
>
> Key: SOLR-12593
> URL: https://issues.apache.org/jira/browse/SOLR-12593
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - Solr Cell (Tika extraction)
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
>
> The date parsing functionality in the extraction contrib is obsoleted by 
> equivalent functionality in ParseDateFieldUpdateProcessorFactory.  It should 
> be removed.  We should add documentation within this part of the ref guide on 
> how to accomplish the same (and test it).



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

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

[jira] [Commented] (SOLR-10243) Fix TestExtractionDateUtil.testParseDate sporadic failures

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10243:


Commit 0d7b2f43623c0a7f8b9bf7e6f2b38f611c3bd607 in lucene-solr's branch 
refs/heads/branch_7x from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0d7b2f4 ]

SOLR-10243: Apply @AwaitsFix on TestExtractionDateUtil.testParseDate to be 
fixed by SOLR-12593

(cherry picked from commit 528e8bc)


> Fix TestExtractionDateUtil.testParseDate sporadic failures
> --
>
> Key: SOLR-10243
> URL: https://issues.apache.org/jira/browse/SOLR-10243
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - Solr Cell (Tika extraction)
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Attachments: SimpleDateFormatTimeZoneBug.java
>
>
> Jenkins test failure:
> {{ant test  -Dtestcase=TestExtractionDateUtil -Dtests.method=testParseDate 
> -Dtests.seed=B72AC4792F31F74B -Dtests.slow=true -Dtests.locale=lv 
> -Dtests.timezone=America/Metlakatla -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8}}   It reproduces on 6x for me but not master.
> I reviewed this briefly and there seems to be a locale assumption in the test.
> 1 tests failed.
> FAILED:  
> org.apache.solr.handler.extraction.TestExtractionDateUtil.testParseDate
> Error Message:
> Incorrect parsed timestamp: 1226583351000 != 1226579751000 (Thu Nov 13 
> 04:35:51 AKST 2008)
> Stack Trace:
> java.lang.AssertionError: Incorrect parsed timestamp: 1226583351000 != 
> 1226579751000 (Thu Nov 13 04:35:51 AKST 2008)
> at 
> __randomizedtesting.SeedInfo.seed([B72AC4792F31F74B:FD33BC4C549880FE]:0)
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.assertTrue(Assert.java:43)
> at 
> org.apache.solr.handler.extraction.TestExtractionDateUtil.assertParsedDate(TestExtractionDateUtil.java:59)
> at 
> org.apache.solr.handler.extraction.TestExtractionDateUtil.testParseDate(TestExtractionDateUtil.java:54)



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

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

[jira] [Created] (SOLR-12593) Remove date parsing functionality from extraction contrib

[David Smiley (JIRA)]

David Smiley created SOLR-12593:
---

 Summary: Remove date parsing functionality from extraction contrib
 Key: SOLR-12593
 URL: https://issues.apache.org/jira/browse/SOLR-12593
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: contrib - Solr Cell (Tika extraction)
Reporter: David Smiley
Assignee: David Smiley


The date parsing functionality in the extraction contrib is obsoleted by 
equivalent functionality in ParseDateFieldUpdateProcessorFactory.  It should be 
removed.  We should add documentation within this part of the ref guide on how 
to accomplish the same (and test it).



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

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

[jira] [Created] (SOLR-12591) Ensure ParseDateFieldUpdateProcessorFactory can be used instead of ExtractionDateUtil

[David Smiley (JIRA)]

David Smiley created SOLR-12591:
---

 Summary: Ensure ParseDateFieldUpdateProcessorFactory can be used 
instead of ExtractionDateUtil
 Key: SOLR-12591
 URL: https://issues.apache.org/jira/browse/SOLR-12591
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: David Smiley
Assignee: David Smiley
 Fix For: master (8.0)


ParseDateFieldUpdateProcessorFactory should ideally be able to handle the cases 
that ExtractionDateUtil does in the "extraction" contrib module.  Tests should 
be added, ported from patches in SOLR-12561 that enhance TestExtractionDateUtil 
to similarly ensure the URP is tested.  I think in this issue, I should switch 
out Joda time for java.time as well (though leave the complete removal for 
SOLR-12586) if it any changes are actually necessary – they probably will be.

Once this issue is complete, it should be appropriate to gut date time parsing 
out of the "extraction" contrib module – a separate issue. 



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

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

[jira] [Updated] (SOLR-12422) Update Ref Guide to recommend against using the ExtractingRequestHandler in production

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-12422:
-
Issue Type: Improvement  (was: Task)

> Update Ref Guide to recommend against using the ExtractingRequestHandler in 
> production
> --
>
> Key: SOLR-12422
> URL: https://issues.apache.org/jira/browse/SOLR-12422
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Tim Allison
>Priority: Major
>
> [~elyograg] recently updated the wiki to include the hard-learned guidance 
> that the ExtractingRequestHandler should not be used in production. 
> [~ctargett] recommended updating the reference guide instead. Let’s update 
> the ref guide.
>  
> ...note to self...don't open issue on tiny screen...sorry for the clutter...



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

Tip: patches from IntelliJ IDEA

[David Smiley]

I use IntelliJ IDEA, and furthermore I use the "create patch" feature to
generate a patch file.  This is far more convenient than using the CLI when
there are multiple "change lists", and for other reasons, since at the CLI
I would have to presumably list out each changed file to include.

However, IntelliJ's patches aren't always compatible with other tools that
consume patch files.  We use Apache Yetus and it doesn't like them -- it
won't even kick off a build so you'll never see a comment from it in the
related JIRA issue.  JetBrains is tracking this patch compatibility
deficiency and they may improve it in the future but it's been years.

I wrote the following one-liner script on my path that I use to convert a
patch file in-place.  The only thing that it does that is necessary to make
Yetus like it is to add the "a/" and "b/" to the file paths in the patch.
Here it is:

# see https://youtrack.jetbrains.com/issue/IDEA-92793
sed -i '' -e 's/^--- /--- a\//g' -e 's/^+++ /+++ b\//g' "$1"

I'm sharing this so others know of the issue and may want to use this
script as well.  I will report it to Yetus; maybe they'll include detection
of when to do this so I don't have to remember to.

~ David
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  
org.apache.solr.handler.component.InfixSuggestersTest.testShutdownDuringBuild

Error Message:
junit.framework.AssertionFailedError: Unexpected wrapped exception type, 
expected CoreIsClosedException

Stack Trace:
java.util.concurrent.ExecutionException: junit.framework.AssertionFailedError: 
Unexpected wrapped exception type, expected CoreIsClosedException
at 
__randomizedtesting.SeedInfo.seed([BD63A6DCEADD7410:62EEC463D4B42172]:0)
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at 
org.apache.solr.handler.component.InfixSuggestersTest.testShutdownDuringBuild(InfixSuggestersTest.java:130)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: junit.framework.AssertionFailedError: Unexpected 

[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-11-ea+23) - Build # 2413 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2413/
Java: 64bit/jdk-11-ea+23 -XX:+UseCompressedOops -XX:+UseG1GC

16 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.handler.TestSQLHandler

Error Message:
1 thread leaked from SUITE scope at org.apache.solr.handler.TestSQLHandler: 
1) Thread[id=4085, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-TestSQLHandler] at 
java.base@11-ea/java.lang.Thread.sleep(Native Method) at 
app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
 at java.base@11-ea/java.lang.Thread.run(Thread.java:834)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.handler.TestSQLHandler: 
   1) Thread[id=4085, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-TestSQLHandler]
at java.base@11-ea/java.lang.Thread.sleep(Native Method)
at 
app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
at java.base@11-ea/java.lang.Thread.run(Thread.java:834)
at __randomizedtesting.SeedInfo.seed([EAD14EC7DB2144E7]:0)


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

Error Message:
1 thread leaked from SUITE scope at org.apache.solr.handler.TestSQLHandler: 
1) Thread[id=4364, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-TestSQLHandler] at 
java.base@11-ea/java.lang.Thread.sleep(Native Method) at 
app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
 at java.base@11-ea/java.lang.Thread.run(Thread.java:834)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.handler.TestSQLHandler: 
   1) Thread[id=4364, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-TestSQLHandler]
at java.base@11-ea/java.lang.Thread.sleep(Native Method)
at 
app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
at java.base@11-ea/java.lang.Thread.run(Thread.java:834)
at __randomizedtesting.SeedInfo.seed([EAD14EC7DB2144E7]:0)


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

Error Message:
1 thread leaked from SUITE scope at org.apache.solr.handler.TestSQLHandler: 
1) Thread[id=33252, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-TestSQLHandler] at 
java.base@11-ea/java.lang.Thread.sleep(Native Method) at 
app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
 at java.base@11-ea/java.lang.Thread.run(Thread.java:834)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.handler.TestSQLHandler: 
   1) Thread[id=33252, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-TestSQLHandler]
at java.base@11-ea/java.lang.Thread.sleep(Native Method)
at 
app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
at java.base@11-ea/java.lang.Thread.run(Thread.java:834)
at __randomizedtesting.SeedInfo.seed([EAD14EC7DB2144E7]:0)


FAILED:  
org.apache.solr.cloud.autoscaling.ScheduledTriggerIntegrationTest.testScheduledTrigger

Error Message:
 null Live Nodes: [127.0.0.1:38453_solr, 127.0.0.1:41841_solr] Last available 
state: null

Stack Trace:
java.lang.AssertionError: 
null
Live Nodes: [127.0.0.1:38453_solr, 127.0.0.1:41841_solr]
Last available state: null
at 
__randomizedtesting.SeedInfo.seed([EAD14EC7DB2144E7:79CA06B585DC1FD3]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:278)
at 
org.apache.solr.cloud.autoscaling.ScheduledTriggerIntegrationTest.testScheduledTrigger(ScheduledTriggerIntegrationTest.java:82)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 

[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-11-ea+23) - Build # 2414 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2414/
Java: 64bit/jdk-11-ea+23 -XX:-UseCompressedOops -XX:+UseParallelGC

5 tests failed.
FAILED:  org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.testBiDir

Error Message:
cluster 2 docs mismatch expected:<1000> but was:<490>

Stack Trace:
java.lang.AssertionError: cluster 2 docs mismatch expected:<1000> but was:<490>
at 
__randomizedtesting.SeedInfo.seed([61288D56A353D960:24F37DB4BB7D9522]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.testBiDir(CdcrBidirectionalTest.java:100)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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.search.mlt.CloudMLTQParserTest.testHighWLValue

Error Message:
Error from server at https://127.0.0.1:34635/solr/mlt-collection: 

[jira] [Commented] (SOLR-12587) Reuse Lucene's PriorityQueue for the ExportHandler

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-12587:
--

Hi Adrien,

I thought about that approach initially but won't {{proto}} be null at that 
point?
{code:java}
public SortQueue(int len, SortDoc proto) {
  super(len, true);
  this.proto = proto;
..
}

@Override
protected SortDoc getSentinelObject() {
  return proto.copy(); //proto has not been initialized
}{code}

> Reuse Lucene's PriorityQueue for the ExportHandler
> --
>
> Key: SOLR-12587
> URL: https://issues.apache.org/jira/browse/SOLR-12587
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
>  Labels: export-writer
> Attachments: SOLR-12587.patch
>
>
> We have a priority queue in Lucene  {{org.apache.lucene.utilPriorityQueue}} . 
> The Export Handler also implements a PriorityQueue 
> {{org.apache.solr.handler.export.PriorityQueue}} . Both are obviously very 
> similar with minor API differences. 
>  
> The aim here is to reuse Lucene's PQ and remove the Solr implementation. 
>  



--
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-8204) ReqOptSumScorer should leverage sub scorers' per-block max scores

[Jim Ferenczi (JIRA)]

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

Jim Ferenczi commented on LUCENE-8204:
--

Here is a patch that implements the block skipping logic. I had to modify the 
RandomApproximationQuery in the tests to make it compatible with 
advanceShallow. I also ran some benchmarks on wikimediumall, I used the 
HighLow, HighMed and HighHigh queries from the original benchmark and made the 
second clause optional to test this scorer:
{noformat}
  TaskQPS lucene_baseline  StdDevQPS lucene_candidate  StdDev   
 Pct diff
HighMed   37.51  (0.0%)   38.05  (0.0%)1.4% (   1% -
1%)
HighHigh  11.02  (0.0%)   16.47  (0.0%)   49.5% (  49% -   
49%)
HighLow  103.91  (0.0%)  219.08  (0.0%)  110.8% ( 110% -  
110%)
{noformat}

> ReqOptSumScorer should leverage sub scorers' per-block max scores
> -
>
> Key: LUCENE-8204
> URL: https://issues.apache.org/jira/browse/LUCENE-8204
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-8204.patch
>
>
> Currently it only looks at max scores on the entire segment. Given that 
> per-block max scores usually give lower upper bounds of the score, this 
> should help.
> This is especially important for LUCENE-8197 to work well since the main 
> query would typically be added as a MUST clauses of a boolean query while the 
> query that scores on features would be a SHOULD clause.



--
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-2562) Make Luke a Lucene/Solr Module

[Mike Sokolov (JIRA)]

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

Mike Sokolov commented on LUCENE-2562:
--

Random, out of left field question here, please feel free to ignore, but have 
you considered porting to an HTTP/HTML gui? It could still be a standalone app 
using a little embedded HTTP service like [this 
one](https://docs.oracle.com/javase/7/docs/jre/api/net/httpserver/spec/com/sun/net/httpserver/HttpServer.html).
 I for one have wanted to run Luke on a remote "cloud" server, but using X 
Windows to bring up the GUI locally is a pretty big barrier (especially if your 
local machine is not UNIX!).

> Make Luke a Lucene/Solr Module
> --
>
> Key: LUCENE-2562
> URL: https://issues.apache.org/jira/browse/LUCENE-2562
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Mark Miller
>Priority: Major
>  Labels: gsoc2014
> Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, 
> LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, 
> LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, 
> Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, 
> luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> see
> "RE: Luke - in need of maintainer": 
> http://markmail.org/message/m4gsto7giltvrpuf
> "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q
> I think it would be great if there was a version of Luke that always worked 
> with trunk - and it would also be great if it was easier to match Luke jars 
> with Lucene versions.
> While I'd like to get GWT Luke into the mix as well, I think the easiest 
> starting point is to straight port Luke to another UI toolkit before 
> abstracting out DTO objects that both GWT Luke and Pivot Luke could share.
> I've started slowly converting Luke's use of thinlet to Apache Pivot. I 
> haven't/don't have a lot of time for this at the moment, but I've plugged 
> away here and there over the past work or two. There is still a *lot* to do.



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

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

[jira] [Updated] (SOLR-12539) JSON Facet shorthand list syntax (Comma seperated list) doesn't trim leading/trailing spaces -- affects range "other" and "include" options (probably more)

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-12539:
-
Component/s: Facet Module

> JSON Facet shorthand list syntax (Comma seperated list) doesn't trim 
> leading/trailing spaces -- affects range "other" and "include" options 
> (probably more)
> ---
>
> Key: SOLR-12539
> URL: https://issues.apache.org/jira/browse/SOLR-12539
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: Hoss Man
>Priority: Major
>
> when doing a {{type: range}} JSON Facet request, if you use the supported 
> "comma seperated string" syntax instead of a true JSON List for specifing 
> options like {{other}} or {{include}} then any whitepsace in your string is 
> left in and breaks the parsin of those options.
> This probably affects other features of JSON Faceting that also support this 
> comma seperated string shorthand (tag exclusions?)
> 
> This works...
> {code}
> bin/solr -e techproducts
> ...
> $ curl http://localhost:8983/solr/techproducts/query -d 
> 'q=*:*=0=true=
> {x:{type:range,
> field:price,
> start:0,
> end:100,
> gap:20,
> other:"before,after"}}'
> {
>   "response":{"numFound":32,"start":0,"docs":[]
>   },
>   "facets":{
> "count":32,
> "x":{
>   "buckets":[{
>   "val":0.0,
>   "count":5},
> ...
>   "before":{
> "count":0},
>   "after":{
> "count":9
> {code}
> This doesn't (note the subtle amount of whitespace in the error message)...
> {code}
> $ curl http://localhost:8983/solr/techproducts/query -d 
> 'q=*:*=0=true=
> {x:{type:range,
> field:price,
> start:0,
> end:100,
> gap:20,
> other:"before, after"}}'
> {
>   "error":{
> "metadata":[
>   "error-class","org.apache.solr.common.SolrException",
>   "root-error-class","java.lang.IllegalArgumentException"],
> "msg":" after is not a valid type of 'other' range facet information",
> "code":400}}
> {code}
> ...exagerated...
> {code}
> $ curl http://localhost:8983/solr/techproducts/query -d 
> 'q=*:*=0=true=
> {x:{type:range,
> field:price,
> start:0,
> end:100,
> gap:20,
> other:"before,   after"}}'
> {
>   "error":{
> "metadata":[
>   "error-class","org.apache.solr.common.SolrException",
>   "root-error-class","java.lang.IllegalArgumentException"],
> "msg":"   after is not a valid type of 'other' 
> range facet information",
> "code":400}}
> {code}



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

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

[jira] [Updated] (SOLR-9793) Add support for more supported JSON Facet params to FacetStream

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-9793:

Component/s: Facet Module

> Add support for more supported JSON Facet params to FacetStream
> ---
>
> Key: SOLR-9793
> URL: https://issues.apache.org/jira/browse/SOLR-9793
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: Varun Thacker
>Priority: Major
>
> Currently the facet stream ( 
> https://cwiki.apache.org/confluence/display/solr/Streaming+Expressions#StreamingExpressions-facet
>  ) supports most which is passed down to the JSON Facet API.
> I think we can add support for these params as well:
> mincount
> prefix



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

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

[jira] [Updated] (SOLR-12582) Consider api/documentation synergies/overlap between JSON Faceting relatedness() function and significantTerms sreaming expression

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-12582:
-
Component/s: Facet Module

> Consider api/documentation synergies/overlap between JSON Faceting 
> relatedness() function and significantTerms sreaming expression
> --
>
> Key: SOLR-12582
> URL: https://issues.apache.org/jira/browse/SOLR-12582
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module, streaming expressions
>Reporter: Hoss Man
>Priority: Major
>
> In SOLR-12581, Alexandre asked the tangential question below, which i've spun 
> off into it's own jira...
> {quote}
> Sort of a side-question, but this work _\[adding new options to the JSON 
> faceting relatedness() aggregation\]_ seems to overlap/compliment the 
> significantTerms work done for streaming/QueryParser: 
> http://lucene.apache.org/solr/guide/7_4/stream-source-reference.html#significantterms
> Are we saying SignificantTerms is for simpler use cases (as fore/back queries 
> are corpus-wide) and then go into relatedness() for more complex analysis? 
> Should the options be roughly compatible where it makes sense and/or 
> similarly named?
> Just wondering because I could see this confusing newbies trying to see when 
> to use which option.
> {quote}



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

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

[jira] [Updated] (SOLR-12564) Full support for histogram and summary metric types in Prometheus exporter

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-12564:
-
Component/s: metrics

> Full support for histogram and summary metric types in Prometheus exporter
> --
>
> Key: SOLR-12564
> URL: https://issues.apache.org/jira/browse/SOLR-12564
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.3.1
>Reporter: Michał Politowski
>Priority: Minor
>
> The Prometheus metrics exporter in contrib does not support exposing complex 
> metrics types: histograms and summaries. In particular request times metrics 
> in Solr provide quantile values, which could be exposed as a Prometheus 
> summary.
> These complex types are represented in the Prometheus wire format as multiple 
> samples with different, related names, which should be produced in a 
> particular order under a common header as described in 
> [https://prometheus.io/docs/instrumenting/exposition_formats/]
> The current Solr Prometheus exporter is able to produce any required sample 
> lines, but not to group them as specified.
> This is only a minor issue for now, as Prometheus currently seems to ignore 
> these constraints (and metrics types in general) itself, but this may change 
> in the future (as stated eg. in 
> [https://prometheus.io/docs/concepts/metric_types/])



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

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

[jira] [Updated] (SOLR-12478) make JSON.facet aware of timeAllowed

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-12478:
-
Component/s: Facet Module

> make JSON.facet aware of timeAllowed 
> -
>
> Key: SOLR-12478
> URL: https://issues.apache.org/jira/browse/SOLR-12478
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: Mikhail Khludnev
>Priority: Major
>
>  It make sense to prevent heavy facets from spinning infinitely by checking 
> [timeout|https://lucene.apache.org/solr/guide/7_3/common-query-parameters.html#timeallowed-parameter].
>  
>  



--
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-12587) Reuse Lucene's PriorityQueue for the ExportHandler

[Adrien Grand (JIRA)]

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

Adrien Grand commented on SOLR-12587:
-

I think you could fix your first nocommit by passing prepopulate=true to the 
constructor and implementing getSentinelObject with {{return proto.copy(); }}. 
For your reset() method, you could also take advantage of the fact that 
PriorityQueue extends Iterable so you don't need casts or to know that indices 
start at 1 in the heap array.

> Reuse Lucene's PriorityQueue for the ExportHandler
> --
>
> Key: SOLR-12587
> URL: https://issues.apache.org/jira/browse/SOLR-12587
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
>  Labels: export-writer
> Attachments: SOLR-12587.patch
>
>
> We have a priority queue in Lucene  {{org.apache.lucene.utilPriorityQueue}} . 
> The Export Handler also implements a PriorityQueue 
> {{org.apache.solr.handler.export.PriorityQueue}} . Both are obviously very 
> similar with minor API differences. 
>  
> The aim here is to reuse Lucene's PQ and remove the Solr implementation. 
>  



--
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-2562) Make Luke a Lucene/Solr Module

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on LUCENE-2562:
---

Couple of points to consider:
 * JDK 11 is a disruption moment anyway, as Oracle will no longer provide the 
official JDK to non-paying customers. Instead, there will be (Redhat-like) 
policy of OpenJDK vs Official JDK: 
[http://www.oracle.com/technetwork/java/javase/eol-135779.html] So, we would 
have to have some real thinking/testing around what that means.
 * If Luke is supposed to be part of Solr distribution, we already have 
HTML/CSS assets for Admin UI, etc. Luke could potentially be a plugin of sorts 
(which has its own issues too)
 * If Luke is supposed to be part of Lucene-only distribution, I guess the 
discussion is a bit more complicated

> Make Luke a Lucene/Solr Module
> --
>
> Key: LUCENE-2562
> URL: https://issues.apache.org/jira/browse/LUCENE-2562
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Mark Miller
>Priority: Major
>  Labels: gsoc2014
> Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, 
> LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, 
> LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, 
> Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, 
> luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> see
> "RE: Luke - in need of maintainer": 
> http://markmail.org/message/m4gsto7giltvrpuf
> "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q
> I think it would be great if there was a version of Luke that always worked 
> with trunk - and it would also be great if it was easier to match Luke jars 
> with Lucene versions.
> While I'd like to get GWT Luke into the mix as well, I think the easiest 
> starting point is to straight port Luke to another UI toolkit before 
> abstracting out DTO objects that both GWT Luke and Pivot Luke could share.
> I've started slowly converting Luke's use of thinlet to Apache Pivot. I 
> haven't/don't have a lot of time for this at the moment, but I've plugged 
> away here and there over the past work or two. There is still a *lot* to do.



--
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-2562) Make Luke a Lucene/Solr Module

[Tomoko Uchida (JIRA)]

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

Tomoko Uchida edited comment on LUCENE-2562 at 7/25/18 4:04 PM:


Sorry for unfocused comment, I have no idea about what's the best.

So Swing based UI (plus web one, if someone can work for this) could be the 
starting point because it is not likely to obsoleted or removed from JDK in a 
while :)


was (Author: tomoko uchida):
Sorry for unfocused comment, I have no idea about what's the best.

So Swing based UI (plus web one, if someone can work for this) could be the 
starting point because it is not likely to obsoleted or removed from JDK at 
least in a while :)

> Make Luke a Lucene/Solr Module
> --
>
> Key: LUCENE-2562
> URL: https://issues.apache.org/jira/browse/LUCENE-2562
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Mark Miller
>Priority: Major
>  Labels: gsoc2014
> Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, 
> LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, 
> LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, 
> Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, 
> luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> see
> "RE: Luke - in need of maintainer": 
> http://markmail.org/message/m4gsto7giltvrpuf
> "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q
> I think it would be great if there was a version of Luke that always worked 
> with trunk - and it would also be great if it was easier to match Luke jars 
> with Lucene versions.
> While I'd like to get GWT Luke into the mix as well, I think the easiest 
> starting point is to straight port Luke to another UI toolkit before 
> abstracting out DTO objects that both GWT Luke and Pivot Luke could share.
> I've started slowly converting Luke's use of thinlet to Apache Pivot. I 
> haven't/don't have a lot of time for this at the moment, but I've plugged 
> away here and there over the past work or two. There is still a *lot* to do.



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

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

[jira] [Updated] (SOLR-12587) Reuse Lucene's PriorityQueue for the ExportHandler

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-12587:
-
Labels: export-writer  (was: )

> Reuse Lucene's PriorityQueue for the ExportHandler
> --
>
> Key: SOLR-12587
> URL: https://issues.apache.org/jira/browse/SOLR-12587
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
>  Labels: export-writer
> Attachments: SOLR-12587.patch
>
>
> We have a priority queue in Lucene  {{org.apache.lucene.utilPriorityQueue}} . 
> The Export Handler also implements a PriorityQueue 
> {{org.apache.solr.handler.export.PriorityQueue}} . Both are obviously very 
> similar with minor API differences. 
>  
> The aim here is to reuse Lucene's PQ and remove the Solr implementation. 
>  



--
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-2562) Make Luke a Lucene/Solr Module

[Tomoko Uchida (JIRA)]

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

Tomoko Uchida commented on LUCENE-2562:
---

Sorry for unfocused comment, I have no idea about what's the best.

So Swing based UI (plus web one, if someone can work for this) could be the 
starting point because it is not likely to obsoleted or removed from JDK at 
least in a while :)

> Make Luke a Lucene/Solr Module
> --
>
> Key: LUCENE-2562
> URL: https://issues.apache.org/jira/browse/LUCENE-2562
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Mark Miller
>Priority: Major
>  Labels: gsoc2014
> Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, 
> LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, 
> LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, 
> Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, 
> luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> see
> "RE: Luke - in need of maintainer": 
> http://markmail.org/message/m4gsto7giltvrpuf
> "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q
> I think it would be great if there was a version of Luke that always worked 
> with trunk - and it would also be great if it was easier to match Luke jars 
> with Lucene versions.
> While I'd like to get GWT Luke into the mix as well, I think the easiest 
> starting point is to straight port Luke to another UI toolkit before 
> abstracting out DTO objects that both GWT Luke and Pivot Luke could share.
> I've started slowly converting Luke's use of thinlet to Apache Pivot. I 
> haven't/don't have a lot of time for this at the moment, but I've plugged 
> away here and there over the past work or two. There is still a *lot* to do.



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

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

[jira] [Updated] (SOLR-12593) Remove date parsing functionality from extraction contrib

[David Smiley (JIRA)]

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

David Smiley updated SOLR-12593:

Fix Version/s: master (8.0)

> Remove date parsing functionality from extraction contrib
> -
>
> Key: SOLR-12593
> URL: https://issues.apache.org/jira/browse/SOLR-12593
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - Solr Cell (Tika extraction)
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Fix For: master (8.0)
>
>
> The date parsing functionality in the extraction contrib is obsoleted by 
> equivalent functionality in ParseDateFieldUpdateProcessorFactory.  It should 
> be removed.  We should add documentation within this part of the ref guide on 
> how to accomplish the same (and test it).



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

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

[jira] [Commented] (SOLR-10243) Fix TestExtractionDateUtil.testParseDate sporadic failures

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10243:


Commit 528e8bceac2e1ffcba33b6eb630a52329b34756e in lucene-solr's branch 
refs/heads/master from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=528e8bc ]

SOLR-10243: Apply @AwaitsFix on TestExtractionDateUtil.testParseDate to be 
fixed by SOLR-12593


> Fix TestExtractionDateUtil.testParseDate sporadic failures
> --
>
> Key: SOLR-10243
> URL: https://issues.apache.org/jira/browse/SOLR-10243
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - Solr Cell (Tika extraction)
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Attachments: SimpleDateFormatTimeZoneBug.java
>
>
> Jenkins test failure:
> {{ant test  -Dtestcase=TestExtractionDateUtil -Dtests.method=testParseDate 
> -Dtests.seed=B72AC4792F31F74B -Dtests.slow=true -Dtests.locale=lv 
> -Dtests.timezone=America/Metlakatla -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8}}   It reproduces on 6x for me but not master.
> I reviewed this briefly and there seems to be a locale assumption in the test.
> 1 tests failed.
> FAILED:  
> org.apache.solr.handler.extraction.TestExtractionDateUtil.testParseDate
> Error Message:
> Incorrect parsed timestamp: 1226583351000 != 1226579751000 (Thu Nov 13 
> 04:35:51 AKST 2008)
> Stack Trace:
> java.lang.AssertionError: Incorrect parsed timestamp: 1226583351000 != 
> 1226579751000 (Thu Nov 13 04:35:51 AKST 2008)
> at 
> __randomizedtesting.SeedInfo.seed([B72AC4792F31F74B:FD33BC4C549880FE]:0)
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.assertTrue(Assert.java:43)
> at 
> org.apache.solr.handler.extraction.TestExtractionDateUtil.assertParsedDate(TestExtractionDateUtil.java:59)
> at 
> org.apache.solr.handler.extraction.TestExtractionDateUtil.testParseDate(TestExtractionDateUtil.java:54)



--
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-12593) Remove date parsing functionality from extraction contrib

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12593:


Commit 528e8bceac2e1ffcba33b6eb630a52329b34756e in lucene-solr's branch 
refs/heads/master from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=528e8bc ]

SOLR-10243: Apply @AwaitsFix on TestExtractionDateUtil.testParseDate to be 
fixed by SOLR-12593


> Remove date parsing functionality from extraction contrib
> -
>
> Key: SOLR-12593
> URL: https://issues.apache.org/jira/browse/SOLR-12593
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - Solr Cell (Tika extraction)
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
>
> The date parsing functionality in the extraction contrib is obsoleted by 
> equivalent functionality in ParseDateFieldUpdateProcessorFactory.  It should 
> be removed.  We should add documentation within this part of the ref guide on 
> how to accomplish the same (and test it).



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

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

[jira] [Closed] (SOLR-12561) Port ExtractionDateUtil to java.time API

[David Smiley (JIRA)]

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

David Smiley closed SOLR-12561.
---

> Port ExtractionDateUtil to java.time API
> 
>
> Key: SOLR-12561
> URL: https://issues.apache.org/jira/browse/SOLR-12561
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - Solr Cell (Tika extraction)
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: master (8.0)
>
> Attachments: SOLR-12561.patch, SOLR-12561.patch, SOLR-12561.patch
>
>
> The ExtractionDateUtil class in the extraction contrib uses 
> SimpleDateFormatter.  The Java 8 java.time API is superior; you can find 
> articles out there why.  One thing that comes to mind is less timezone 
> bugginess – SOLR-10243.  Although the API may be a bit baroque IMO 
> (over-engineered).  Here I'd like to switch over the API and furthermore have 
> the patterns be pre-parsed so that at runtime we don't need to re-parse the 
> patterns.



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

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

[jira] [Created] (SOLR-12592) Support the cores:'EQUAL' in autoscaling policies

[Noble Paul (JIRA)]

Noble Paul created SOLR-12592:
-

 Summary: Support the cores:'EQUAL' in autoscaling policies
 Key: SOLR-12592
 URL: https://issues.apache.org/jira/browse/SOLR-12592
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Noble Paul
Assignee: Noble Paul


It's possible to  sort nodes according to cores and the system can normally 
prefer nodes with fewer cores when placing new replicas. However, it may not 
give suggestions to move off replicas , if the system  is already in an 
unbalanced state.
The following rule may help achieve such a balanced distribution of cores
{code}
{"cores":"#EQUAL" , node: "#ANY"}
{code}

The value of cores is computed as {{total_cores/total_nodes}}. for e.g: if 
there are 28 cores in total and there are 5 nodes . the value of cores= 28/5 = 
5.6. This means a node may have either 5 cores or 6 cores.

It's possible that this may cause a conflict with other collection-specific 
rules such as
{code}
{"replica":"#EQUAL" , "node" : "#ANY"}
{code}

It can be remedied by making this rule , not strict.
{code}
{"cores":"#EQUAL" , "node": "#ANY", "strict"=false}
{code}




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

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

[jira] [Updated] (SOLR-12592) Support the cores:'EQUAL' in autoscaling policies

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-12592:
--
Component/s: SolrCloud
 AutoScaling

> Support the cores:'EQUAL' in autoscaling policies
> -
>
> Key: SOLR-12592
> URL: https://issues.apache.org/jira/browse/SOLR-12592
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, SolrCloud
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>
> It's possible to  sort nodes according to cores and the system can normally 
> prefer nodes with fewer cores when placing new replicas. However, it may not 
> give suggestions to move off replicas , if the system  is already in an 
> unbalanced state.
> The following rule may help achieve such a balanced distribution of cores
> {code}
> {"cores":"#EQUAL" , node: "#ANY"}
> {code}
> The value of cores is computed as {{total_cores/total_nodes}}. for e.g: if 
> there are 28 cores in total and there are 5 nodes . the value of cores= 28/5 
> = 5.6. This means a node may have either 5 cores or 6 cores.
> It's possible that this may cause a conflict with other collection-specific 
> rules such as
> {code}
> {"replica":"#EQUAL" , "node" : "#ANY"}
> {code}
> It can be remedied by making this rule , not strict.
> {code}
> {"cores":"#EQUAL" , "node": "#ANY", "strict"=false}
> {code}



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

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

[jira] [Commented] (LUCENE-2562) Make Luke a Lucene/Solr Module

[Tomoko Uchida (JIRA)]

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

Tomoko Uchida commented on LUCENE-2562:
---

[~sokolov] Thanks comments, sure, a tiny http server is always on my mind. (I 
am a just another web engineer, I know there are plenty of nice & light webapp 
frameworks...)

However,  I'm not sure that adding web assets (html, css, js) to Lucene, pure 
Java library, is acceptable. May be server side rendering (JavaScript free) is 
ok? I have no idea...

 

> Make Luke a Lucene/Solr Module
> --
>
> Key: LUCENE-2562
> URL: https://issues.apache.org/jira/browse/LUCENE-2562
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Mark Miller
>Priority: Major
>  Labels: gsoc2014
> Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, 
> LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, 
> LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, 
> Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, 
> luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> see
> "RE: Luke - in need of maintainer": 
> http://markmail.org/message/m4gsto7giltvrpuf
> "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q
> I think it would be great if there was a version of Luke that always worked 
> with trunk - and it would also be great if it was easier to match Luke jars 
> with Lucene versions.
> While I'd like to get GWT Luke into the mix as well, I think the easiest 
> starting point is to straight port Luke to another UI toolkit before 
> abstracting out DTO objects that both GWT Luke and Pivot Luke could share.
> I've started slowly converting Luke's use of thinlet to Apache Pivot. I 
> haven't/don't have a lot of time for this at the moment, but I've plugged 
> away here and there over the past work or two. There is still a *lot* to do.



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

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

[jira] [Updated] (SOLR-12422) Update Ref Guide to recommend against using the ExtractingRequestHandler in production

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-12422:
-
Component/s: documentation

> Update Ref Guide to recommend against using the ExtractingRequestHandler in 
> production
> --
>
> Key: SOLR-12422
> URL: https://issues.apache.org/jira/browse/SOLR-12422
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Tim Allison
>Priority: Major
>
> [~elyograg] recently updated the wiki to include the hard-learned guidance 
> that the ExtractingRequestHandler should not be used in production. 
> [~ctargett] recommended updating the reference guide instead. Let’s update 
> the ref guide.
>  
> ...note to self...don't open issue on tiny screen...sorry for the clutter...



--
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-12590) Improve Solr resource loader coverage in the ref guide

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-12590:
---

test

> Improve Solr resource loader coverage in the ref guide
> --
>
> Key: SOLR-12590
> URL: https://issues.apache.org/jira/browse/SOLR-12590
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-12590.patch
>
>
> In SolrCloud, storing large resources (e.g. binary machine learned models) on 
> the local filesystem should be a viable alternative to increasing ZooKeeper's 
> max file size limit (1MB), but there are undocumented complications.



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

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

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

[Apache Jenkins Server]

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

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

[repro] Revision: 3edd07b20bf637a62d4303c4f7a646e166ac55b6

[repro] Ant options: -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-7.x/test-data/enwiki.random.lines.txt
[repro] Repro line:  ant test  -Dtestcase=TestMockDirectoryWrapper 
-Dtests.method=testThreadSafetyInListAll -Dtests.seed=3F18BAEF97C7B4BC 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.badapples=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=sr-BA -Dtests.timezone=Antarctica/Troll -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=TestLatLonShapeQueries 
-Dtests.method=testRandomBig -Dtests.seed=A249B8C8C3DFFF9 -Dtests.multiplier=2 
-Dtests.nightly=true -Dtests.slow=true -Dtests.badapples=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=ru -Dtests.timezone=Etc/GMT+7 -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[repro] Repro line:  ant test  -Dtestcase=IndexSizeTriggerTest 
-Dtests.method=testSplitIntegration -Dtests.seed=EE9E6F4F6108C35B 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.badapples=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=es-PR -Dtests.timezone=Etc/GMT-9 -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=IndexSizeTriggerTest 
-Dtests.method=testMergeIntegration -Dtests.seed=EE9E6F4F6108C35B 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.badapples=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=es-PR -Dtests.timezone=Etc/GMT-9 -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=TestDocTermOrdsUninvertLimit 
-Dtests.method=testTriggerUnInvertLimit -Dtests.seed=EE9E6F4F6108C35B 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.badapples=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=ar-BH -Dtests.timezone=Asia/Almaty -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=TestDocTermOrdsUninvertLimit 
-Dtests.seed=EE9E6F4F6108C35B -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true -Dtests.badapples=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=ar-BH -Dtests.timezone=Asia/Almaty -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=BasicDistributedZkTest 
-Dtests.method=test -Dtests.seed=EE9E6F4F6108C35B -Dtests.multiplier=2 
-Dtests.nightly=true -Dtests.slow=true -Dtests.badapples=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=en-NZ -Dtests.timezone=Africa/Mbabane -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=TestAuthenticationFramework 
-Dtests.method=testBasics -Dtests.seed=EE9E6F4F6108C35B -Dtests.multiplier=2 
-Dtests.nightly=true -Dtests.slow=true -Dtests.badapples=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=sr-Latn-ME -Dtests.timezone=America/Belem -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=HdfsChaosMonkeyNothingIsSafeTest 
-Dtests.method=test -Dtests.seed=EE9E6F4F6108C35B -Dtests.multiplier=2 
-Dtests.nightly=true -Dtests.slow=true -Dtests.badapples=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=pt-BR -Dtests.timezone=Asia/Jayapura -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=HdfsChaosMonkeyNothingIsSafeTest 
-Dtests.seed=EE9E6F4F6108C35B -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true -Dtests.badapples=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=pt-BR -Dtests.timezone=Asia/Jayapura -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=TestBulkSchemaConcurrent 

[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-11-ea+23) - Build # 2412 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2412/
Java: 64bit/jdk-11-ea+23 -XX:+UseCompressedOops -XX:+UseParallelGC

20 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.io.graph.GraphExpressionTest

Error Message:
6 threads leaked from SUITE scope at 
org.apache.solr.client.solrj.io.graph.GraphExpressionTest: 1) 
Thread[id=502, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-GraphExpressionTest] at 
java.base@11-ea/java.lang.Thread.sleep(Native Method) at 
app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
 at java.base@11-ea/java.lang.Thread.run(Thread.java:834)2) 
Thread[id=504, name=ShortestPathStream-249-thread-1-EventThread, state=WAITING, 
group=TGRP-GraphExpressionTest] at 
java.base@11-ea/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@11-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
 at 
java.base@11-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
 at 
java.base@11-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433)
 at 
app//org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:502)3) 
Thread[id=505, name=zkConnectionManagerCallback-254-thread-1, state=WAITING, 
group=TGRP-GraphExpressionTest] at 
java.base@11-ea/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@11-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
 at 
java.base@11-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
 at 
java.base@11-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433)
 at 
java.base@11-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1054)
 at 
java.base@11-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1114)
 at 
java.base@11-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
 at java.base@11-ea/java.lang.Thread.run(Thread.java:834)4) 
Thread[id=509, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-GraphExpressionTest] at 
java.base@11-ea/java.lang.Thread.sleep(Native Method) at 
app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
 at java.base@11-ea/java.lang.Thread.run(Thread.java:834)5) 
Thread[id=508, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-GraphExpressionTest] at 
java.base@11-ea/java.lang.Thread.sleep(Native Method) at 
app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
 at java.base@11-ea/java.lang.Thread.run(Thread.java:834)6) 
Thread[id=503, 
name=ShortestPathStream-249-thread-1-SendThread(127.0.0.1:40183), 
state=TIMED_WAITING, group=TGRP-GraphExpressionTest] at 
java.base@11-ea/java.lang.Thread.sleep(Native Method) at 
app//org.apache.zookeeper.client.StaticHostProvider.next(StaticHostProvider.java:105)
 at 
app//org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:1000)
 at 
app//org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1063)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 6 threads leaked from SUITE 
scope at org.apache.solr.client.solrj.io.graph.GraphExpressionTest: 
   1) Thread[id=502, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-GraphExpressionTest]
at java.base@11-ea/java.lang.Thread.sleep(Native Method)
at 
app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
at java.base@11-ea/java.lang.Thread.run(Thread.java:834)
   2) Thread[id=504, name=ShortestPathStream-249-thread-1-EventThread, 
state=WAITING, group=TGRP-GraphExpressionTest]
at java.base@11-ea/jdk.internal.misc.Unsafe.park(Native Method)
at 
java.base@11-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
at 
java.base@11-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
at 
java.base@11-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433)
at 
app//org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:502)
   3) Thread[id=505, name=zkConnectionManagerCallback-254-thread-1, 
state=WAITING, group=TGRP-GraphExpressionTest]
at java.base@11-ea/jdk.internal.misc.Unsafe.park(Native Method)
at 
java.base@11-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
at 
java.base@11-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
at 

[jira] [Created] (SOLR-12590) Improve Solr resource loader coverage in the ref guide

[Steve Rowe (JIRA)]

Steve Rowe created SOLR-12590:
-

 Summary: Improve Solr resource loader coverage in the ref guide
 Key: SOLR-12590
 URL: https://issues.apache.org/jira/browse/SOLR-12590
 Project: Solr
  Issue Type: Task
  Security Level: Public (Default Security Level. Issues are Public)
  Components: documentation
Reporter: Steve Rowe
Assignee: Steve Rowe


In SolrCloud, storing large resources (e.g. binary machine learned models) on 
the local filesystem should be a viable alternative to increasing ZooKeeper's 
max file size limit (1MB), but there are undocumented complications.



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

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

[jira] [Updated] (LUCENE-8204) ReqOptSumScorer should leverage sub scorers' per-block max scores

[Jim Ferenczi (JIRA)]

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

Jim Ferenczi updated LUCENE-8204:
-
Attachment: LUCENE-8204.patch

> ReqOptSumScorer should leverage sub scorers' per-block max scores
> -
>
> Key: LUCENE-8204
> URL: https://issues.apache.org/jira/browse/LUCENE-8204
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-8204.patch
>
>
> Currently it only looks at max scores on the entire segment. Given that 
> per-block max scores usually give lower upper bounds of the score, this 
> should help.
> This is especially important for LUCENE-8197 to work well since the main 
> query would typically be added as a MUST clauses of a boolean query while the 
> query that scores on features would be a SHOULD clause.



--
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 pull request #416: WIP: SOLR-12519

[dsmiley]

Github user dsmiley commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/416#discussion_r205126064
  
--- Diff: 
solr/core/src/java/org/apache/solr/response/transform/DeeplyNestedChildDocTransformer.java
 ---
@@ -132,54 +126,49 @@ public void transform(SolrDocument rootDoc, int 
rootDocId) {
 // load the doc
 SolrDocument doc = 
DocsStreamer.convertLuceneDocToSolrDoc(docFetcher.doc(docId),
 schema, new SolrReturnFields());
-doc.setField(NEST_PATH_FIELD_NAME, fullDocPath);
 if (shouldDecorateWithDVs) {
   docFetcher.decorateDocValueFields(doc, docId, 
dvFieldsToReturn);
 }
 // get parent path
 // put into pending
 String parentDocPath = lookupParentPath(fullDocPath);
-pendingParentPathsToChildren.put(parentDocPath, doc); // 
multimap add (won't replace)
 
-// if this path has pending child docs, add them.
-if (isAncestor) {
-  addChildrenToParent(doc, 
pendingParentPathsToChildren.get(fullDocPath));
-  pendingParentPathsToChildren.removeAll(fullDocPath); // no 
longer pending
+if(isAncestor) {
+  // if this path has pending child docs, add them.
+  addChildrenToParent(doc, 
pendingParentPathsToChildren.remove(fullDocPath)); // no longer pending
 }
+pendingParentPathsToChildren.computeIfAbsent(parentDocPath, x 
-> ArrayListMultimap.create())
+.put(trimIfSingleDoc(getLastPath(fullDocPath)), doc); // 
multimap add (won't replace)
   }
 }
 
 // only children of parent remain
 assert pendingParentPathsToChildren.keySet().size() == 1;
 
-addChildrenToParent(rootDoc, 
pendingParentPathsToChildren.get(null));
+addChildrenToParent(rootDoc, 
pendingParentPathsToChildren.remove(null));
   }
 } catch (IOException e) {
   rootDoc.put(getName(), "Could not fetch child Documents");
 }
   }
 
-  void addChildToParent(SolrDocument parent, SolrDocument child, String 
label) {
-// lookup leaf key for these children using path
-// depending on the label, add to the parent at the right key/label
-// TODO: unfortunately this is the 2nd time we grab the paths for 
these docs. resolve how?
-String trimmedPath = trimSuffixFromPaths(getLastPath(label));
-if (!parent.containsKey(trimmedPath) && (label.contains(NUM_SEP_CHAR) 
&& !label.endsWith(NUM_SEP_CHAR))) {
-  List list = new ArrayList<>();
-  parent.setField(trimmedPath, list);
+  void addChildrenToParent(SolrDocument parent, Multimap children) {
+for(String childLabel: children.keySet()) {
--- End diff --

Ah, I see (I didn't look at Multimap's iteration options when I wrote 
that).  Your code here is good.


---

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

[GitHub] lucene-solr pull request #416: WIP: SOLR-12519

[moshebla]

Github user moshebla commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/416#discussion_r205125247
  
--- Diff: 
solr/core/src/java/org/apache/solr/response/transform/ChildDocTransformerFactory.java
 ---
@@ -67,7 +73,9 @@
 
   public static final String PATH_SEP_CHAR = "/";
   public static final String NUM_SEP_CHAR = "#";
-  private static final String sRootFilter = "*:* NOT " + 
NEST_PATH_FIELD_NAME + ":*";
+  private static final BooleanQuery rootFilter = new BooleanQuery.Builder()
+  .add(new BooleanClause(new MatchAllDocsQuery(), 
BooleanClause.Occur.MUST))
+  .add(new BooleanClause(new WildcardQuery(new 
Term(NEST_PATH_FIELD_NAME, new BytesRef("*"))), 
BooleanClause.Occur.MUST_NOT)).build();
--- End diff --

My bad, I'll fix this in the next commit.


---

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

[GitHub] lucene-solr pull request #416: WIP: SOLR-12519

[moshebla]

Github user moshebla commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/416#discussion_r205124868
  
--- Diff: 
solr/core/src/java/org/apache/solr/response/transform/DeeplyNestedChildDocTransformer.java
 ---
@@ -132,54 +126,49 @@ public void transform(SolrDocument rootDoc, int 
rootDocId) {
 // load the doc
 SolrDocument doc = 
DocsStreamer.convertLuceneDocToSolrDoc(docFetcher.doc(docId),
 schema, new SolrReturnFields());
-doc.setField(NEST_PATH_FIELD_NAME, fullDocPath);
 if (shouldDecorateWithDVs) {
   docFetcher.decorateDocValueFields(doc, docId, 
dvFieldsToReturn);
 }
 // get parent path
 // put into pending
 String parentDocPath = lookupParentPath(fullDocPath);
-pendingParentPathsToChildren.put(parentDocPath, doc); // 
multimap add (won't replace)
 
-// if this path has pending child docs, add them.
-if (isAncestor) {
-  addChildrenToParent(doc, 
pendingParentPathsToChildren.get(fullDocPath));
-  pendingParentPathsToChildren.removeAll(fullDocPath); // no 
longer pending
+if(isAncestor) {
+  // if this path has pending child docs, add them.
+  addChildrenToParent(doc, 
pendingParentPathsToChildren.remove(fullDocPath)); // no longer pending
 }
+pendingParentPathsToChildren.computeIfAbsent(parentDocPath, x 
-> ArrayListMultimap.create())
+.put(trimIfSingleDoc(getLastPath(fullDocPath)), doc); // 
multimap add (won't replace)
   }
 }
 
 // only children of parent remain
 assert pendingParentPathsToChildren.keySet().size() == 1;
 
-addChildrenToParent(rootDoc, 
pendingParentPathsToChildren.get(null));
+addChildrenToParent(rootDoc, 
pendingParentPathsToChildren.remove(null));
   }
 } catch (IOException e) {
   rootDoc.put(getName(), "Could not fetch child Documents");
 }
   }
 
-  void addChildToParent(SolrDocument parent, SolrDocument child, String 
label) {
-// lookup leaf key for these children using path
-// depending on the label, add to the parent at the right key/label
-// TODO: unfortunately this is the 2nd time we grab the paths for 
these docs. resolve how?
-String trimmedPath = trimSuffixFromPaths(getLastPath(label));
-if (!parent.containsKey(trimmedPath) && (label.contains(NUM_SEP_CHAR) 
&& !label.endsWith(NUM_SEP_CHAR))) {
-  List list = new ArrayList<>();
-  parent.setField(trimmedPath, list);
+  void addChildrenToParent(SolrDocument parent, Multimap children) {
+for(String childLabel: children.keySet()) {
--- End diff --

it seems like MultiMap entries are not returned as the collections for each 
key, but are instead returned as entries with each key added to it. It seems 
more efficient to add the whole array at once, reducing the amount of lookups 
that have to be made for each child. We could do this in one simple look up.


---

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

[GitHub] lucene-solr pull request #416: WIP: SOLR-12519

[dsmiley]

Github user dsmiley commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/416#discussion_r205124848
  
--- Diff: 
solr/core/src/java/org/apache/solr/response/transform/DeeplyNestedChildDocTransformer.java
 ---
@@ -190,8 +179,18 @@ private String getLastPath(String path) {
 return path.substring(path.lastIndexOf(PATH_SEP_CHAR.charAt(0)) + 1);
   }
 
-  private String trimSuffixFromPaths(String path) {
-return path.replaceAll("#\\d|#", "");
+  private String trimIfSingleDoc(String path) {
--- End diff --

Oh gotcha -- sure.  It does complicate an explanation of what that String 
is, as it won't simply be a label, but that's okay.  Please add comments where 
we declare the field to explain this stuff. (e.g.. what the outer String is 
(with example), what the intermediate string is (with 2 examples)).


---

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

[GitHub] lucene-solr pull request #416: WIP: SOLR-12519

[moshebla]

Github user moshebla commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/416#discussion_r205123592
  
--- Diff: 
solr/core/src/java/org/apache/solr/response/transform/DeeplyNestedChildDocTransformer.java
 ---
@@ -190,8 +179,18 @@ private String getLastPath(String path) {
 return path.substring(path.lastIndexOf(PATH_SEP_CHAR.charAt(0)) + 1);
   }
 
-  private String trimSuffixFromPaths(String path) {
-return path.replaceAll("#\\d|#", "");
+  private String trimIfSingleDoc(String path) {
--- End diff --

Do we really need a set though?
If we trim only the array docs we can then easily figure out at insert time 
whether the item is a single doc or an array, optimizing the insert time, and 
removing the need for a set


---

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

[GitHub] lucene-solr pull request #416: WIP: SOLR-12519

[dsmiley]

Github user dsmiley commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/416#discussion_r205119770
  
--- Diff: 
solr/core/src/java/org/apache/solr/response/transform/DeeplyNestedChildDocTransformer.java
 ---
@@ -108,12 +103,11 @@ public void transform(SolrDocument rootDoc, int 
rootDocId) {
   final LeafReaderContext leafReaderContext = 
searcher.getIndexReader().leaves().get(seg);
   final SortedDocValues segPathDocValues = 
DocValues.getSorted(leafReaderContext.reader(), NEST_PATH_FIELD_NAME);
 
-  Multimap pendingParentPathsToChildren = 
ArrayListMultimap.create();
+  Map> 
pendingParentPathsToChildren = new HashMap<>();
--- End diff --

Ah good catch; yes a Map and not MultiMap at outer level once we add the 
label intermediate


---

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

[GitHub] lucene-solr pull request #416: WIP: SOLR-12519

[dsmiley]

Github user dsmiley commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/416#discussion_r205121128
  
--- Diff: 
solr/core/src/java/org/apache/solr/response/transform/DeeplyNestedChildDocTransformer.java
 ---
@@ -132,54 +126,49 @@ public void transform(SolrDocument rootDoc, int 
rootDocId) {
 // load the doc
 SolrDocument doc = 
DocsStreamer.convertLuceneDocToSolrDoc(docFetcher.doc(docId),
 schema, new SolrReturnFields());
-doc.setField(NEST_PATH_FIELD_NAME, fullDocPath);
 if (shouldDecorateWithDVs) {
   docFetcher.decorateDocValueFields(doc, docId, 
dvFieldsToReturn);
 }
 // get parent path
 // put into pending
 String parentDocPath = lookupParentPath(fullDocPath);
-pendingParentPathsToChildren.put(parentDocPath, doc); // 
multimap add (won't replace)
 
-// if this path has pending child docs, add them.
-if (isAncestor) {
-  addChildrenToParent(doc, 
pendingParentPathsToChildren.get(fullDocPath));
-  pendingParentPathsToChildren.removeAll(fullDocPath); // no 
longer pending
+if(isAncestor) {
+  // if this path has pending child docs, add them.
+  addChildrenToParent(doc, 
pendingParentPathsToChildren.remove(fullDocPath)); // no longer pending
 }
+pendingParentPathsToChildren.computeIfAbsent(parentDocPath, x 
-> ArrayListMultimap.create())
+.put(trimIfSingleDoc(getLastPath(fullDocPath)), doc); // 
multimap add (won't replace)
--- End diff --

I believe we simply want the label here; maybe add a method getLeafLabel() 
that takes a path and returns the leaf label.  It would trim off any "#" with 
digits no matter if it's a single doc or not.


---

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

[GitHub] lucene-solr pull request #416: WIP: SOLR-12519

[dsmiley]

Github user dsmiley commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/416#discussion_r205122374
  
--- Diff: 
solr/core/src/java/org/apache/solr/response/transform/DeeplyNestedChildDocTransformer.java
 ---
@@ -190,8 +179,18 @@ private String getLastPath(String path) {
 return path.substring(path.lastIndexOf(PATH_SEP_CHAR.charAt(0)) + 1);
   }
 
-  private String trimSuffixFromPaths(String path) {
-return path.replaceAll("#\\d|#", "");
+  private String trimIfSingleDoc(String path) {
--- End diff --

I'll assume this is still WIP as we discussed wanting to use a Set 
of child docs, and thus we wouldn't trim conditionally for single doc.


---

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

[GitHub] lucene-solr pull request #416: WIP: SOLR-12519

[dsmiley]

Github user dsmiley commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/416#discussion_r205121643
  
--- Diff: 
solr/core/src/java/org/apache/solr/response/transform/DeeplyNestedChildDocTransformer.java
 ---
@@ -132,54 +126,49 @@ public void transform(SolrDocument rootDoc, int 
rootDocId) {
 // load the doc
 SolrDocument doc = 
DocsStreamer.convertLuceneDocToSolrDoc(docFetcher.doc(docId),
 schema, new SolrReturnFields());
-doc.setField(NEST_PATH_FIELD_NAME, fullDocPath);
 if (shouldDecorateWithDVs) {
   docFetcher.decorateDocValueFields(doc, docId, 
dvFieldsToReturn);
 }
 // get parent path
 // put into pending
 String parentDocPath = lookupParentPath(fullDocPath);
-pendingParentPathsToChildren.put(parentDocPath, doc); // 
multimap add (won't replace)
 
-// if this path has pending child docs, add them.
-if (isAncestor) {
-  addChildrenToParent(doc, 
pendingParentPathsToChildren.get(fullDocPath));
-  pendingParentPathsToChildren.removeAll(fullDocPath); // no 
longer pending
+if(isAncestor) {
+  // if this path has pending child docs, add them.
+  addChildrenToParent(doc, 
pendingParentPathsToChildren.remove(fullDocPath)); // no longer pending
 }
+pendingParentPathsToChildren.computeIfAbsent(parentDocPath, x 
-> ArrayListMultimap.create())
+.put(trimIfSingleDoc(getLastPath(fullDocPath)), doc); // 
multimap add (won't replace)
   }
 }
 
 // only children of parent remain
 assert pendingParentPathsToChildren.keySet().size() == 1;
 
-addChildrenToParent(rootDoc, 
pendingParentPathsToChildren.get(null));
+addChildrenToParent(rootDoc, 
pendingParentPathsToChildren.remove(null));
   }
 } catch (IOException e) {
   rootDoc.put(getName(), "Could not fetch child Documents");
 }
   }
 
-  void addChildToParent(SolrDocument parent, SolrDocument child, String 
label) {
-// lookup leaf key for these children using path
-// depending on the label, add to the parent at the right key/label
-// TODO: unfortunately this is the 2nd time we grab the paths for 
these docs. resolve how?
-String trimmedPath = trimSuffixFromPaths(getLastPath(label));
-if (!parent.containsKey(trimmedPath) && (label.contains(NUM_SEP_CHAR) 
&& !label.endsWith(NUM_SEP_CHAR))) {
-  List list = new ArrayList<>();
-  parent.setField(trimmedPath, list);
+  void addChildrenToParent(SolrDocument parent, Multimap children) {
+for(String childLabel: children.keySet()) {
--- End diff --

there is likely a way to iterate over Map.Entry or similar so you don't 
have to "get" each in the next line.


---

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

[GitHub] lucene-solr pull request #416: WIP: SOLR-12519

[dsmiley]

Github user dsmiley commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/416#discussion_r205119233
  
--- Diff: 
solr/core/src/java/org/apache/solr/response/transform/ChildDocTransformerFactory.java
 ---
@@ -67,7 +73,9 @@
 
   public static final String PATH_SEP_CHAR = "/";
   public static final String NUM_SEP_CHAR = "#";
-  private static final String sRootFilter = "*:* NOT " + 
NEST_PATH_FIELD_NAME + ":*";
+  private static final BooleanQuery rootFilter = new BooleanQuery.Builder()
+  .add(new BooleanClause(new MatchAllDocsQuery(), 
BooleanClause.Occur.MUST))
+  .add(new BooleanClause(new WildcardQuery(new 
Term(NEST_PATH_FIELD_NAME, new BytesRef("*"))), 
BooleanClause.Occur.MUST_NOT)).build();
--- End diff --

I think I suggested using DocValuesExistsQuery which only depends on the 
existence of DocValues and should be efficient


---

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/765/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

3 tests failed.
FAILED:  
org.apache.solr.handler.component.InfixSuggestersTest.testShutdownDuringBuild

Error Message:
junit.framework.AssertionFailedError: Unexpected wrapped exception type, 
expected CoreIsClosedException

Stack Trace:
java.util.concurrent.ExecutionException: junit.framework.AssertionFailedError: 
Unexpected wrapped exception type, expected CoreIsClosedException
at 
__randomizedtesting.SeedInfo.seed([2AE9DFE2F7D5394D:F564BD5DC9BC6C2F]:0)
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at 
org.apache.solr.handler.component.InfixSuggestersTest.testShutdownDuringBuild(InfixSuggestersTest.java:130)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: junit.framework.AssertionFailedError: Unexpected 

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

[Apache Jenkins Server]

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

[...truncated 28 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-7.x/110/consoleText

[repro] Revision: 3bf98da39f36d862745be166a0a59303c4ed1714

[repro] Repro line:  ant test  -Dtestcase=ShardSplitTest -Dtests.method=test 
-Dtests.seed=51FB1926F9D8F9E4 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.badapples=true -Dtests.locale=sr-Latn -Dtests.timezone=Pacific/Johnston 
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII

[repro] Repro line:  ant test  -Dtestcase=ShardSplitTest 
-Dtests.method=testSplitWithChaosMonkey -Dtests.seed=51FB1926F9D8F9E4 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true 
-Dtests.locale=sr-Latn -Dtests.timezone=Pacific/Johnston -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[repro] Repro line:  ant test  -Dtestcase=IndexSizeTriggerTest 
-Dtests.method=testMergeIntegration -Dtests.seed=51FB1926F9D8F9E4 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true 
-Dtests.locale=es-PR -Dtests.timezone=Asia/Dushanbe -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[repro] Repro line:  ant test  -Dtestcase=TestLargeCluster 
-Dtests.method=testNodeLost -Dtests.seed=51FB1926F9D8F9E4 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=uk 
-Dtests.timezone=America/Hermosillo -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
d25f62634b95e49df739a5a2612f9b719ef3a77d
[repro] git fetch
[repro] git checkout 3bf98da39f36d862745be166a0a59303c4ed1714

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

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

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

[...truncated 3335 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=15 
-Dtests.class="*.IndexSizeTriggerTest|*.TestLargeCluster|*.ShardSplitTest" 
-Dtests.showOutput=onerror  -Dtests.seed=51FB1926F9D8F9E4 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=es-PR 
-Dtests.timezone=Asia/Dushanbe -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

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

[repro] Failures:
[repro]   4/5 failed: org.apache.solr.cloud.autoscaling.sim.TestLargeCluster
[repro]   5/5 failed: org.apache.solr.cloud.api.collections.ShardSplitTest
[repro]   5/5 failed: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest

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

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

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

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

[...truncated 3318 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=10 
-Dtests.class="*.IndexSizeTriggerTest|*.ShardSplitTest" 
-Dtests.showOutput=onerror  -Dtests.seed=51FB1926F9D8F9E4 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=es-PR 
-Dtests.timezone=Asia/Dushanbe -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

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

[repro] Failures at the tip of branch_7x:
[repro]   0/5 failed: org.apache.solr.cloud.api.collections.ShardSplitTest
[repro]   5/5 failed: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest

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

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

[...truncated 3318 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.IndexSizeTriggerTest" -Dtests.showOutput=onerror  
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true 
-Dtests.locale=es-PR -Dtests.timezone=Asia/Dushanbe -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

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

[repro] Failures at the tip of branch_7x without a seed:
[repro]   5/5 failed: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest
[repro] git checkout d25f62634b95e49df739a5a2612f9b719ef3a77d

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

[...truncated 6 lines...]

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

[GitHub] lucene-solr issue #416: WIP: SOLR-12519

[moshebla]

Github user moshebla commented on the issue:

https://github.com/apache/lucene-solr/pull/416
  
I tried optimizing the lookup and insertion of child documents.
Hopefully I'll get more time tomorrow to get the tests up to scratch.


---

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

[jira] [Updated] (SOLR-9351) JSON Facet field should sometimes default to facet.method=stream

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-9351:

Component/s: Facet Module

> JSON Facet field should sometimes default to facet.method=stream
> 
>
> Key: SOLR-9351
> URL: https://issues.apache.org/jira/browse/SOLR-9351
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: David Smiley
>Priority: Major
>
> The {{method}} on a field/term facet could be automatically set to "stream" 
> in some cases and get better results?.  For example if {{limit}} is -1 or is 
> a number that is at a decent proportion of the known available terms, then 
> "stream" makes sense to me.  And also, provided that the "base" docset (aka 
> input domain) is large.



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

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

[jira] [Updated] (SOLR-8909) Streaming Expressions should leverage streaming facets

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-8909:

Component/s: streaming expressions
 Facet Module

> Streaming Expressions should leverage streaming facets
> --
>
> Key: SOLR-8909
> URL: https://issues.apache.org/jira/browse/SOLR-8909
> Project: Solr
>  Issue Type: Bug
>  Components: Facet Module, streaming expressions
>Reporter: Yonik Seeley
>Priority: Major
>
> The JSON Facet API can currently stream facets (use method=stream) from a 
> single node.  Each facet bucket is calculated as it is written out, so field 
> cardinality has no effect on memory.
> This is only from a single node - normal distributed search/faceting does not 
> stream...  But that's what streaming expressions are for anyway!
> One current caveat: streaming currently only works with "sort=index asc" (the 
> term order in the Lucene index).
> Future work could allow more complex sorts, at the cost of some memory to 
> calculate the sort criteria for each bucket prior to streaming out.  Of 
> course more complex sorts would require more complex merging logic (i.e. even 
> a sort by bucket count is not a simple merge sort and requires more buffering 
> in the merging node).



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

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

[jira] [Updated] (SOLR-8681) Json facets in range dates do not mantain the order across multiple shards

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-8681:

Component/s: Facet Module

> Json facets in range dates do not mantain the order across multiple shards
> --
>
> Key: SOLR-8681
> URL: https://issues.apache.org/jira/browse/SOLR-8681
> Project: Solr
>  Issue Type: Bug
>  Components: Facet Module
>Reporter: Pablo Anzorena
>Priority: Major
>
> I have multiple shards and when I make a range facet in a date field across 
> the shards, it does not respect the order. That is, making a request with gap 
> +1YEARS across the shards 2012_collection, 2013_collection, 2014_collection 
> the response put 2013 first, then 2012, and then 2014 (for example). I tried 
> making it with +1MONTHS and it respect the order within each shard, but not 
> in a global way.



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

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

[jira] [Updated] (SOLR-9565) Make every UpdateRequestProcessor available implicitly

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-9565:

Component/s: UpdateRequestProcessors

> Make every UpdateRequestProcessor available implicitly
> --
>
> Key: SOLR-9565
> URL: https://issues.apache.org/jira/browse/SOLR-9565
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UpdateRequestProcessors
>Reporter: Noble Paul
>Priority: Major
> Attachments: SOLR-9565.patch
>
>
> Now that we can 'construct' the URP chains through request parameters, we 
> should make all the URPs available automatically. The next challenge is to 
> make them read the configuration from request parameters as well
> to access {{HTMLStripFieldUpdateProcessorFactory}} the parameter could be 
> {{processor=HTMLStripField}} (The UpdateProcessorFactory part is 
> automatically appended )
> The next step is to make the URPs accept request parameters instead of just 
> configuration parameters e.g: 
> {{processor=HTMLStripField=}}



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

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

[jira] [Updated] (SOLR-11706) JSON FacetModule can't compute stats (min,max,etc...) on multivalued fields

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-11706:
-
Component/s: Facet Module

> JSON FacetModule can't compute stats (min,max,etc...) on multivalued fields
> ---
>
> Key: SOLR-11706
> URL: https://issues.apache.org/jira/browse/SOLR-11706
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: Hoss Man
>Priority: Major
> Attachments: SOLR-11706.patch
>
>
> While trying to write some tests demonstrating equivalences between the 
> StatsComponent and the JSON FacetModule i discovered that the FacetModules 
> stat functions (min, max, etc...) don't seem to work on multivalued fields.
> Based on the stack traces, i gather the problem is because the FacetModule 
> seems to rely exclusively on using the "Function" parsers to get a value 
> source -- apparently w/o any other method of accumulating numeric stats from 
> multivalued (numeric) DocValues?



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

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

[jira] [Updated] (SOLR-10157) JSON Facets should give more helpful error msg when users attempt to an unknown aggregation

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-10157:
-
Component/s: Facet Module

> JSON Facets should give more helpful error msg when users attempt to an 
> unknown aggregation
> ---
>
> Key: SOLR-10157
> URL: https://issues.apache.org/jira/browse/SOLR-10157
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: Hoss Man
>Priority: Major
>
> Sample question from a confused solr-user email...
> {noformat}
> > I'm getting this error when I tried to do a division in JSON Facet.
> >
> >   "error":{
> > "msg":"org.apache.solr.search.SyntaxError: Unknown aggregation agg_div 
> > in ('div(4,2)', pos=4)",
> > "code":400}}
> >
> >
> > Is this division function supported in JSON Facet?
> {noformat}
> And the subsequent followup from the same user...
> bq. I found that we can't put div(4,2) directly, as it wouldn't work.
> bq. It will work if I put something like max(div(4,2)).
> 
> It seems like a better error handline code path for 
> {{FunctionQParser.parseAgg}} (once we've confirmed no such aggregation 
> exists) would be:
> * attempt to parse the original string as a regular (non-Agg)ValueSource) 
> function
> ** if that succeeds, give the user an error indicating that this ValueSource 
> must be wrapped in an aggregation
> ** if it fails, continue to throw the original error
> * either way, any error thrown should refer to the _original_ {{id}} before 
> For example: 
> * {{div(price,popularity)}} should throw an error with a msg along the lines 
> of: {{'div' is a per-document function, not a multi-document aggregation 
> function, input: div(price,popularity)}}
> *  {{HOSS(price,popularity)}} on the other hand should throw an error such 
> as: {{Unknown aggregation HOSS in ('HOSS(price,populaity)' ...}}
> ** note the message cites {{HOSS}} not {{agg_HOSS}}



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

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

[jira] [Updated] (SOLR-12330) Referencing non existing parameter in JSON Facet "filter" (and/or other NPEs) either reported too little and even might be ignored

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-12330:
-
Component/s: Facet Module

> Referencing non existing parameter in JSON Facet "filter" (and/or other NPEs) 
> either reported too little and even might be ignored 
> ---
>
> Key: SOLR-12330
> URL: https://issues.apache.org/jira/browse/SOLR-12330
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Affects Versions: 7.3
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12330.patch, SOLR-12330.patch
>
>
> Just encounter such weird behaviour, will recheck and followup. 
> {{"filter":["\{!v=$bogus}"]}} responds back with just NPE which makes 
> impossible to guess the reason.
> It might be even worse, since {{"filter":[\{"param":"bogus"}]}} seems like 
> just silently ignored.
> Once agin, I'll double check. 



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

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

[jira] [Updated] (SOLR-12581) add a "min_popularity" option to relatedness() aggregation that forces scores to -Inf if fg/bg pops don't meet a threshold

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-12581:
-
Component/s: Facet Module

> add a "min_popularity" option to relatedness() aggregation that forces scores 
> to -Inf if fg/bg pops don't meet a threshold
> --
>
> Key: SOLR-12581
> URL: https://issues.apache.org/jira/browse/SOLR-12581
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-12581.patch, SOLR-12581.patch
>
>
> as discussed in SOLR-9480 and noted in TODO comments, the original SKG code 
> base had a "min_pop" option that would completely ignore "terms" if the fg/bg 
> popularities weren't above a user specified threshold.  with the 
> implementation of SKG as a {{relatedness()}} aggregation function, we need to 
> leave any actual filtering of buckets by an aggregation result to a future 
> generalized JSON facet enhancement, but what we can do today is implement an 
> optional {{min_popularity}} option on {{relatedness()}} that forces the 
> {{relatedness}} score to -Infinity so buckets that don't meat the threshold 
> at least score "as low as possible"



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

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

[jira] [Updated] (SOLR-12556) JSON Field Facet refinement can return incorrect counts/stats for sorted buckets -- when using processEmpty

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-12556:
-
Component/s: Facet Module

> JSON Field Facet refinement can return incorrect counts/stats for sorted 
> buckets -- when using processEmpty
> ---
>
> Key: SOLR-12556
> URL: https://issues.apache.org/jira/browse/SOLR-12556
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: Hoss Man
>Priority: Major
>
> Creating this spin off of SOLR-12343 - the fix in that issue addresses the 
> most common cases, but does not help when {{processEmpty:true}} is used...
> {panel}
> in {{getRefinement()}} you've got {{returnedAllBuckets}} taking into 
> consideration {{processEmpty:true}} - so that even if a shardA doesn't say it 
> has {{more:true}} we will still send it candidate bucketX for refinement if 
> we didn't explicitly {{saw}} bucketX on shardA. so far so good.
> but then, once all the refinement is done, and we have a fully refined 
> bucketX it might now sort "lower" then an incomplete bucketY ... and 
> {{isBucketComplete}} doesn't pay any attention to {{processEmpty:true}} ... 
> so it sees that shardA does *not* have {{more:true}} and thinks (the 
> incomplete) bucketY is ok to return.
> {panel}



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

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

[jira] [Updated] (SOLR-12582) Consider api/documentation synergies/overlap between JSON Faceting relatedness() function and significantTerms sreaming expression

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-12582:
-
Component/s: streaming expressions

> Consider api/documentation synergies/overlap between JSON Faceting 
> relatedness() function and significantTerms sreaming expression
> --
>
> Key: SOLR-12582
> URL: https://issues.apache.org/jira/browse/SOLR-12582
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module, streaming expressions
>Reporter: Hoss Man
>Priority: Major
>
> In SOLR-12581, Alexandre asked the tangential question below, which i've spun 
> off into it's own jira...
> {quote}
> Sort of a side-question, but this work _\[adding new options to the JSON 
> faceting relatedness() aggregation\]_ seems to overlap/compliment the 
> significantTerms work done for streaming/QueryParser: 
> http://lucene.apache.org/solr/guide/7_4/stream-source-reference.html#significantterms
> Are we saying SignificantTerms is for simpler use cases (as fore/back queries 
> are corpus-wide) and then go into relatedness() for more complex analysis? 
> Should the options be roughly compatible where it makes sense and/or 
> similarly named?
> Just wondering because I could see this confusing newbies trying to see when 
> to use which option.
> {quote}



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