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

[Policeman Jenkins Server]

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

6 tests failed.
FAILED:  
org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName

Error Message:
Could not find collection:first_collection

Stack Trace:
java.lang.AssertionError: Could not find collection:first_collection
at 
__randomizedtesting.SeedInfo.seed([AFC6B1465E51061B:1C4266B6E5009ECA]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:155)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.checkCreateCollection(TestMiniSolrCloudClusterSSL.java:263)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.checkClusterWithCollectionCreations(TestMiniSolrCloudClusterSSL.java:233)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.checkClusterWithNodeReplacement(TestMiniSolrCloudClusterSSL.java:157)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName(TestMiniSolrCloudClusterSSL.java:139)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
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.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:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
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 

[jira] [Commented] (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:comment-tabpanel=16611590#comment-16611590
 ] 

David Smiley commented on SOLR-12593:
-

So I took the PR and further changed the ref guide page on this, and then the 
default config slightly as well. My changes grew in scope to misc things I 
didn't like in the guide for this feature but I hope other committers are happy 
with it. FWIW I held back from doing more :) [~arafalov] I know you tend to the 
configs so I'm hoping you can review this (or anyone of course).
 * Revamped the "Key Solr Cell Concepts"
 * Switched the examples / "trying out" instructions from using the 
"techproducts" example config to using our default config (via -e 
"schemaless"). Why? Firstly, I observed that the techproducts config didn't 
have the URPs I wanted. Fixable, yes, but... Secondly, I think it simply 
doesn't make sense to have the "techproducts" config, by virtue of its name, 
have things other than .. you know... _tech products_.
 ** The default configset's schema oddly does not include an "ignored" field 
type and "ignored_*" dynamic field. I added them. These are useful, especially 
with Solr Cell.
 ** minutia: removed the metadata name mapping of metadata "meta" to "ignored_" 
from the default parameters of the default configset's /update/extract request 
handler. I don't see the point of this and FWIW it's not in the techproducts 
config either.  Lets keep this config more minimal.
 ** The default configset is schemaless, and so the "try tika" instructions 
were modified to recognize the fact that the metadata is all automatically 
added instead of how it used to be which was only those fields that happened to 
be in the techproducts schema. This is good but there is an awkward part in the 
last step of the demo if you want to _not_ map the metadata since it requires 
wiping the core and starting over.
 * Added a tip on URPs with an example to specify these processors.

> 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)
>
> Attachments: SOLR-12593.patch
>
>  Time Spent: 3h 50m
>  Remaining Estimate: 0h
>
> 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] [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:

Attachment: SOLR-12593.patch

> 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)
>
> Attachments: SOLR-12593.patch
>
>  Time Spent: 3h 50m
>  Remaining Estimate: 0h
>
> 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

[JENKINS] Lucene-Solr-Tests-master - Build # 2805 - Unstable

[Apache Jenkins Server]

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

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

Error Message:
trigger did not fire within timeout, waitFor=5, killDelay=5000, minIgnored=0

Stack Trace:
java.lang.AssertionError: trigger did not fire within timeout, waitFor=5, 
killDelay=5000, minIgnored=0
at 
__randomizedtesting.SeedInfo.seed([494378BFF05FFCC2:F656B64173B59944]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.sim.TestSimLargeCluster.doTestNodeLost(TestSimLargeCluster.java:526)
at 
org.apache.solr.cloud.autoscaling.sim.TestSimLargeCluster.testNodeLost(TestSimLargeCluster.java:394)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
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:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 12383 lines...]
   [junit4] Suite: org.apache.solr.cloud.autoscaling.sim.TestSimLargeCluster
   

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

[Policeman Jenkins Server]

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

9 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.extraction.ExtractingRequestHandlerTest

Error Message:
SOLR-12759 JDK 11 (1st release) and Tika 1.x can result in extracting dates in 
a bad format.

Stack Trace:
java.lang.AssertionError: SOLR-12759 JDK 11 (1st release) and Tika 1.x can 
result in extracting dates in a bad format.
at __randomizedtesting.SeedInfo.seed([20E62DE81EE67574]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertFalse(Assert.java:68)
at 
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.beforeClass(ExtractingRequestHandlerTest.java:44)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
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.handler.extraction.ExtractingRequestHandlerTest

Error Message:
SOLR-12759 JDK 11 (1st release) and Tika 1.x can result in extracting dates in 
a bad format.

Stack Trace:
java.lang.AssertionError: SOLR-12759 JDK 11 (1st release) and Tika 1.x can 
result in extracting dates in a bad format.
at __randomizedtesting.SeedInfo.seed([20E62DE81EE67574]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertFalse(Assert.java:68)
at 
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.beforeClass(ExtractingRequestHandlerTest.java:44)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 

[JENKINS] Lucene-Solr-BadApples-NightlyTests-7.x - Build # 26 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-BadApples-NightlyTests-7.x/26/

6 tests failed.
FAILED:  org.apache.solr.cloud.SharedFSAutoReplicaFailoverTest.test

Error Message:
Could not load collection from ZK: solrj_collection

Stack Trace:
org.apache.solr.common.SolrException: Could not load collection from ZK: 
solrj_collection
at 
__randomizedtesting.SeedInfo.seed([C7B681A9FBA6B54A:4FE2BE73555AD8B2]:0)
at 
org.apache.solr.common.cloud.ZkStateReader.getCollectionLive(ZkStateReader.java:1316)
at 
org.apache.solr.common.cloud.ZkStateReader$LazyCollectionRef.get(ZkStateReader.java:732)
at 
org.apache.solr.common.cloud.ClusterState.getCollectionOrNull(ClusterState.java:148)
at 
org.apache.solr.common.cloud.ClusterState.getCollectionOrNull(ClusterState.java:131)
at 
org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:117)
at 
org.apache.solr.cloud.SharedFSAutoReplicaFailoverTest.assertSliceAndReplicaCount(SharedFSAutoReplicaFailoverTest.java:400)
at 
org.apache.solr.cloud.SharedFSAutoReplicaFailoverTest.testBasics(SharedFSAutoReplicaFailoverTest.java:225)
at 
org.apache.solr.cloud.SharedFSAutoReplicaFailoverTest.test(SharedFSAutoReplicaFailoverTest.java:148)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
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:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
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 

[jira] [Commented] (SOLR-10209) UI: Convert all Collections api calls to async requests, add new features/buttons

[JIRA]

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

Jan Høydahl commented on SOLR-10209:


Hi [~sarkaramr...@gmail.com], any plans to move this forward? Would be great to 
have a UI for doing collection backup/restore etc.

> UI: Convert all Collections api calls to async requests, add new 
> features/buttons
> -
>
> Key: SOLR-10209
> URL: https://issues.apache.org/jira/browse/SOLR-10209
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Reporter: Amrit Sarkar
>Priority: Major
> Attachments: SOLR-10209-v1.patch, SOLR-10209.patch, SOLR-10209.patch, 
> SOLR-10209.patch
>
>
> We are having discussion on multiple jiras for requests for Collections apis 
> from UI and how to improve them:
> -SOLR-9818: Solr admin UI rapidly retries any request(s) if it loses 
> connection with the server-
> -SOLR-10146: Admin UI: Button to delete a shard-
> SOLR-10201: Add Collection "creates collection", "Connection to Solr lost", 
> when replicationFactor>1
> Proposal =>
> *Phase 1:*
> Convert all Collections api calls to async requests and utilise REQUESTSTATUS 
> to fetch the information. There will be performance hit, but the requests 
> will be safe and sound. A progress bar will be added for request status.
> {noformat}
> > submit the async request
> if (the initial call failed or there was no status to be found)
> { report an error and suggest the user look check their system before 
> resubmitting the request. Bail out in this case, no retries, no attempt to 
> drive on. }
> else
> { put up a progress indicator while periodically checking the status, 
> Continue spinning until we can report the final status. }
> {noformat}
> *Phase 2:*
> Add new buttons/features to collections.html
> a) "Split" shard
> -b) "Delete" shard-
> c) "Backup" collection
> d) "Restore" collection
> Open to suggestions and feedbacks on this.



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

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

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

[Policeman Jenkins Server]

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

13 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.sim.TestSimGenericDistributedQueue.testDistributedQueue

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([C6AD27DFD766ED74]:0)


FAILED:  org.apache.solr.handler.TestSQLHandler.doTest

Error Message:
--> http://127.0.0.1:54164/uk_zu/collection1_shard2_replica_n41:Failed to 
execute sqlQuery 'select id, field_i, str_s, field_i_p, field_f_p, field_d_p, 
field_l_p from collection1 where (text='()' OR text='') AND text='' 
order by field_i desc' against JDBC connection 'jdbc:calcitesolr:'. Error while 
executing SQL "select id, field_i, str_s, field_i_p, field_f_p, field_d_p, 
field_l_p from collection1 where (text='()' OR text='') AND text='' 
order by field_i desc": java.io.IOException: 
java.util.concurrent.ExecutionException: java.io.IOException: --> 
http://127.0.0.1:54164/uk_zu/collection1_shard2_replica_n41/:can not sort on a 
field w/o docValues unless it is indexed and supports Uninversion: field_i

Stack Trace:
java.io.IOException: --> 
http://127.0.0.1:54164/uk_zu/collection1_shard2_replica_n41:Failed to execute 
sqlQuery 'select id, field_i, str_s, field_i_p, field_f_p, field_d_p, field_l_p 
from collection1 where (text='()' OR text='') AND text='' order by 
field_i desc' against JDBC connection 'jdbc:calcitesolr:'.
Error while executing SQL "select id, field_i, str_s, field_i_p, field_f_p, 
field_d_p, field_l_p from collection1 where (text='()' OR text='') AND 
text='' order by field_i desc": java.io.IOException: 
java.util.concurrent.ExecutionException: java.io.IOException: --> 
http://127.0.0.1:54164/uk_zu/collection1_shard2_replica_n41/:can not sort on a 
field w/o docValues unless it is indexed and supports Uninversion: field_i
at 
__randomizedtesting.SeedInfo.seed([C6AD27DFD766ED74:61E99F7BBADDFECD]:0)
at 
org.apache.solr.client.solrj.io.stream.SolrStream.read(SolrStream.java:215)
at 
org.apache.solr.handler.TestSQLHandler.getTuples(TestSQLHandler.java:2712)
at 
org.apache.solr.handler.TestSQLHandler.testBasicSelect(TestSQLHandler.java:137)
at org.apache.solr.handler.TestSQLHandler.doTest(TestSQLHandler.java:85)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
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:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
   

[jira] [Comment Edited] (SOLR-11836) Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-11836 at 9/11/18 10:42 PM:
-

It's the FacetStream that is causing the -1 limit to stop returning results. We 
can fix that as well.


was (Author: joel.bernstein):
It's the FacetStream that causing the -1 to stop working returning results. We 
can fix that as well.

> Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API
> 
>
> Key: SOLR-11836
> URL: https://issues.apache.org/jira/browse/SOLR-11836
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Alfonso Muñoz-Pomer Fuentes
>Priority: Major
>  Labels: facet, streaming
> Attachments: SOLR-11836.patch
>
>
> Currently, to retrieve all buckets using the streaming expressions facet 
> function, the {{bucketSizeLimit}} parameter must have a high enough value so 
> that all results will be included. Compare this with the JSON facet API, 
> where you can use {{"limit": -1}} to achieve this. It would help if such a 
> possibility existed.
> [Issue 11236|https://issues.apache.org/jira/browse/SOLR-11236] is related.



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

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

[jira] [Commented] (SOLR-11836) Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-11836:
---

It's the FacetStream that causing the -1 to stop working returning results. We 
can fix that as well.

> Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API
> 
>
> Key: SOLR-11836
> URL: https://issues.apache.org/jira/browse/SOLR-11836
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Alfonso Muñoz-Pomer Fuentes
>Priority: Major
>  Labels: facet, streaming
> Attachments: SOLR-11836.patch
>
>
> Currently, to retrieve all buckets using the streaming expressions facet 
> function, the {{bucketSizeLimit}} parameter must have a high enough value so 
> that all results will be included. Compare this with the JSON facet API, 
> where you can use {{"limit": -1}} to achieve this. It would help if such a 
> possibility existed.
> [Issue 11236|https://issues.apache.org/jira/browse/SOLR-11236] is related.



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

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

[jira] [Updated] (LUCENE-8493) Stop publishing .sha1 files with releases

[JIRA]

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

Jan Høydahl updated LUCENE-8493:

Fix Version/s: master (8.0)
   7.6

> Stop publishing .sha1 files with releases
> -
>
> Key: LUCENE-8493
> URL: https://issues.apache.org/jira/browse/LUCENE-8493
> Project: Lucene - Core
>  Issue Type: Task
>  Components: -tools
>Reporter: Jan Høydahl
>Priority: Major
>  Labels: build, release, security, sha1sum
> Fix For: 7.6, master (8.0)
>
> Attachments: LUCENE-8493.patch
>
>
> In LUCENE-7935 we added {{.sha512}} checksums to releases and removed 
> {{.md5}} files.
> According to the Release Distribution Policy 
> ([http://www.apache.org/dev/release-distribution#sigs-and-sums)]:
> {quote}For every artifact distributed to the public through Apache channels, 
> the PMC
> MUST supply a valid OpenPGP-compatible ASCII-armored detached signature file
> MUST supply at least one checksum file
> SHOULD supply a SHA-256 and/or SHA-512 checksum file
> *SHOULD NOT supply a MD5 or SHA-1 checksum file* (because these are 
> deprecated)
> {quote}
> So this Jira will stop publishing .sha1 files, leaving only the .sha512



--
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-8493) Stop publishing .sha1 files with releases

[JIRA]

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

Jan Høydahl commented on LUCENE-8493:
-

Attaching patch that skips sha1 sum generation

> Stop publishing .sha1 files with releases
> -
>
> Key: LUCENE-8493
> URL: https://issues.apache.org/jira/browse/LUCENE-8493
> Project: Lucene - Core
>  Issue Type: Task
>  Components: -tools
>Reporter: Jan Høydahl
>Priority: Major
>  Labels: build, release, security, sha1sum
> Fix For: 7.6, master (8.0)
>
> Attachments: LUCENE-8493.patch
>
>
> In LUCENE-7935 we added {{.sha512}} checksums to releases and removed 
> {{.md5}} files.
> According to the Release Distribution Policy 
> ([http://www.apache.org/dev/release-distribution#sigs-and-sums)]:
> {quote}For every artifact distributed to the public through Apache channels, 
> the PMC
> MUST supply a valid OpenPGP-compatible ASCII-armored detached signature file
> MUST supply at least one checksum file
> SHOULD supply a SHA-256 and/or SHA-512 checksum file
> *SHOULD NOT supply a MD5 or SHA-1 checksum file* (because these are 
> deprecated)
> {quote}
> So this Jira will stop publishing .sha1 files, leaving only the .sha512



--
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-8493) Stop publishing .sha1 files with releases

[JIRA]

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

Jan Høydahl updated LUCENE-8493:

Attachment: LUCENE-8493.patch

> Stop publishing .sha1 files with releases
> -
>
> Key: LUCENE-8493
> URL: https://issues.apache.org/jira/browse/LUCENE-8493
> Project: Lucene - Core
>  Issue Type: Task
>  Components: -tools
>Reporter: Jan Høydahl
>Priority: Major
>  Labels: build, release, security, sha1sum
> Attachments: LUCENE-8493.patch
>
>
> In LUCENE-7935 we added {{.sha512}} checksums to releases and removed 
> {{.md5}} files.
> According to the Release Distribution Policy 
> ([http://www.apache.org/dev/release-distribution#sigs-and-sums)]:
> {quote}For every artifact distributed to the public through Apache channels, 
> the PMC
> MUST supply a valid OpenPGP-compatible ASCII-armored detached signature file
> MUST supply at least one checksum file
> SHOULD supply a SHA-256 and/or SHA-512 checksum file
> *SHOULD NOT supply a MD5 or SHA-1 checksum file* (because these are 
> deprecated)
> {quote}
> So this Jira will stop publishing .sha1 files, leaving only the .sha512



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

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

Re: Lucene/Solr 7.5

[Jan Høydahl]

Jim, I just committed the last part of LUCENE-5143 regarding build changes 
related to KEYS file.
Feel free to test the buildAndPushRelease.py and smokeTestRelease.py scripts 
locally before the RC on friday, to check that they work on your computer as 
well :)
I'll update ReleaseTodo accordingly.

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

> 11. sep. 2018 kl. 23:35 skrev Varun Thacker :
> 
> Hi Jim,
> 
> You beat me to it :) Yeah after looking at Joel's comments there might be 
> some more work involved. So no point rushing it in 7.5 .
> 
> On Tue, Sep 11, 2018 at 1:16 PM jim ferenczi  > wrote:
> Sorry but this was just committed to master and branch_7x and I see some 
> discussions regarding the implication of this change. Is it really safe to 
> include it in 7.5 ?
> 
> Le mar. 11 sept. 2018 à 21:43, Varun Thacker  > a écrit :
> Hi Jim,
> 
> I'd like to backport SOLR-11836 if that's okay with you. It's a trivial fix 
> which I committed to master and branch_7x a little while ago.
> 
> On Tue, Sep 11, 2018 at 9:09 AM jim ferenczi  > wrote:
> Thanks Steve!
> 
> Le mar. 11 sept. 2018 à 18:02, Steve Rowe  > a écrit :
> Hi Jim,
> 
> > On Sep 11, 2018, at 11:32 AM, jim ferenczi  > > wrote:
> > 
> > Could someone help to setup the Jenkins releases build ? It seems that I 
> > cannot create jobs with my account.
> 
> 
> Each project's PMC Chair is responsible for granting job 
> creation/modification permissions on Jenkins: 
> https://cwiki.apache.org/confluence/display/INFRA/Jenkins#Jenkins-HowdoIgetanaccount
>  
> 
> 
> I’ll go create the 7.5 jobs now.
> 
> -- 
> Steve
> www.lucidworks.com 
> 
> > On Sep 11, 2018, at 11:32 AM, jim ferenczi  > > wrote:
> > 
> > No worries at all Cassandra. What do you think of building the first RC on 
> > Friday and start the vote on Monday next week ? This will leave some
> > room to finish the missing bits. 
> > Could someone help to setup the Jenkins releases build ? It seems that I 
> > cannot create jobs with my account.
> > 
> > Le mar. 11 sept. 2018 à 14:08, Cassandra Targett  > > a écrit :
> > Sorry, Jim, I should have replied yesterday about the state of things with 
> > the Ref Guide - it's close. I'm doing the last bit of big review I need to 
> > do and am nearly done with that, then I have a couple more small things 
> > done (including SOLR-12763 which I just created since I forgot to do it 
> > earlier). My goal is to be done by the end of my day today so you could do 
> > the RC tomorrow, but who knows what the day will bring work-wise, so I'll 
> > send another mail at the end of the day my time to let you know for sure.
> > 
> > On Mon, Sep 10, 2018 at 9:07 AM jim ferenczi  > > wrote:
> > I just fixed the invalid version (7.5.1) that I added in master and 7x. The 
> > next version on these branches should be 7.6.0, sorry for the noise.
> > 
> > Le lun. 10 sept. 2018 à 09:26, jim ferenczi  > > a écrit :
> > Hi,
> > 
> > Feature freeze for 7.5 has started, I just created a branch_7_5.:
> > 
> > * No new features may be committed to the branch.
> > * Documentation patches, build patches and serious bug fixes may be 
> > committed to the branch. However, you should submit all patches you want to 
> > commit to Jira first to give others the chance to review and possibly vote 
> > against the patch. Keep in mind that it is our main intention to keep the 
> > branch as stable as possible.
> > * All patches that are intended for the branch should first be committed to 
> > the unstable branch, merged into the stable branch, and then into the 
> > current release branch.
> > * Normal unstable and stable branch development may continue as usual. 
> > However, if you plan to commit a big change to the unstable branch while 
> > the branch feature freeze is in effect, think twice: can't the addition 
> > wait a couple more days? Merges of bug fixes into the branch may become 
> > more difficult.
> > * Only Jira issues with Fix version "7.5" and priority "Blocker" will delay 
> > a release candidate build.
> > 
> > I'll create the first RC later this week depending on the status of the 
> > Solr ref guide. Cassandra, can you update the status when you think that 
> > the ref guide is ready (no rush just a reminder that we need to sync during 
> > this release ;) ) ?
> > 
> > Cheers,
> > Jim
> > 
> > Le mer. 5 sept. 2018 à 17:57, Erick Erickson  > > a écrit :
> > Great, thanks!
> > On Wed, Sep 5, 2018 at 8:44 AM jim ferenczi  > > wrote:
> > >
> > > Sure it can wait a few days. Let's cut the branch next 

[jira] [Resolved] (LUCENE-5143) rm or formalize dealing with "general" KEYS files in our dist dir

[JIRA]

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

Jan Høydahl resolved LUCENE-5143.
-
Resolution: Fixed

Resolving this issue again after committing yesterday's proposed patch

I chose to remove the unused build targets both due to the fact that they have 
not been used for years, are stale, and do not comply with release policy of 
staging RCs to official dist area (see 
[http://www.apache.org/legal/release-policy.html#host-rc)]

I have successfully tested a full cycle of buildAndPushRelease.py and 
smokeTestRelease.py. [~jim.ferenczi] this should hopefully be good to go for 
friday's RC.

> rm or formalize dealing with "general" KEYS files in our dist dir
> -
>
> Key: LUCENE-5143
> URL: https://issues.apache.org/jira/browse/LUCENE-5143
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Hoss Man
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 7.5, master (8.0)
>
> Attachments: KEYS, KEYS, KEYS, KEYS, LUCENE-5143-reopen-smoke.patch, 
> LUCENE-5143-reopen-smoke.patch, LUCENE-5143.patch, LUCENE-5143.patch, 
> LUCENE-5143.patch, LUCENE-5143.patch, LUCENE-5143_READMEs.patch, 
> LUCENE-5143_READMEs.patch, LUCENE-5143_READMEs.patch, LUCENE_5143_KEYS.patch, 
> verify.log, verify.sh, verify.sh, verify.sh
>
>
> At some point in the past, we started creating a snapshots of KEYS (taken 
> from the auto-generated data from id.apache.org) in the release dir of each 
> release...
> http://www.apache.org/dist/lucene/solr/4.4.0/KEYS
> http://www.apache.org/dist/lucene/java/4.4.0/KEYS
> http://archive.apache.org/dist/lucene/java/4.3.0/KEYS
> http://archive.apache.org/dist/lucene/solr/4.3.0/KEYS
> etc...
> But we also still have some "general" KEYS files...
> https://www.apache.org/dist/lucene/KEYS
> https://www.apache.org/dist/lucene/java/KEYS
> https://www.apache.org/dist/lucene/solr/KEYS
> ...which (as i discovered when i went to add my key to them today) are stale 
> and don't seem to be getting updated.
> I vaguely remember someone (rmuir?) explaining to me at one point the reason 
> we started creating a fresh copy of KEYS in each release dir, but i no longer 
> remember what they said, and i can't find any mention of a reason in any of 
> the release docs, or in any sort of comment in buildAndPushRelease.py
> we probably do one of the following:
>  * remove these "general" KEYS files
>  * add a disclaimer to the top of these files that they are legacy files for 
> verifying old releases and are no longer used for new releases
>  * ensure these files are up to date stop generating per-release KEYS file 
> copies
>  * update our release process to ensure that the general files get updated on 
> each release as well



--
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-5143) rm or formalize dealing with "general" KEYS files in our dist dir

[ASF subversion and git services (JIRA)]

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

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

Commit 308504f828a770e0508e5b2eb8027f347f995b27 in lucene-solr's branch 
refs/heads/branch_7_5 from [~janhoy]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=308504f ]

LUCENE-5143: Fix smoketester, fix RM PGP key check, fix solr DOAP file, add 
CHANGES entry
Remove unused/stale 'copy-to-stage' and '-dist-keys' targets from ant build

(cherry picked from commit 5b96f89)


> rm or formalize dealing with "general" KEYS files in our dist dir
> -
>
> Key: LUCENE-5143
> URL: https://issues.apache.org/jira/browse/LUCENE-5143
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Hoss Man
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 7.5, master (8.0)
>
> Attachments: KEYS, KEYS, KEYS, KEYS, LUCENE-5143-reopen-smoke.patch, 
> LUCENE-5143-reopen-smoke.patch, LUCENE-5143.patch, LUCENE-5143.patch, 
> LUCENE-5143.patch, LUCENE-5143.patch, LUCENE-5143_READMEs.patch, 
> LUCENE-5143_READMEs.patch, LUCENE-5143_READMEs.patch, LUCENE_5143_KEYS.patch, 
> verify.log, verify.sh, verify.sh, verify.sh
>
>
> At some point in the past, we started creating a snapshots of KEYS (taken 
> from the auto-generated data from id.apache.org) in the release dir of each 
> release...
> http://www.apache.org/dist/lucene/solr/4.4.0/KEYS
> http://www.apache.org/dist/lucene/java/4.4.0/KEYS
> http://archive.apache.org/dist/lucene/java/4.3.0/KEYS
> http://archive.apache.org/dist/lucene/solr/4.3.0/KEYS
> etc...
> But we also still have some "general" KEYS files...
> https://www.apache.org/dist/lucene/KEYS
> https://www.apache.org/dist/lucene/java/KEYS
> https://www.apache.org/dist/lucene/solr/KEYS
> ...which (as i discovered when i went to add my key to them today) are stale 
> and don't seem to be getting updated.
> I vaguely remember someone (rmuir?) explaining to me at one point the reason 
> we started creating a fresh copy of KEYS in each release dir, but i no longer 
> remember what they said, and i can't find any mention of a reason in any of 
> the release docs, or in any sort of comment in buildAndPushRelease.py
> we probably do one of the following:
>  * remove these "general" KEYS files
>  * add a disclaimer to the top of these files that they are legacy files for 
> verifying old releases and are no longer used for new releases
>  * ensure these files are up to date stop generating per-release KEYS file 
> copies
>  * update our release process to ensure that the general files get updated on 
> each release as well



--
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-5143) rm or formalize dealing with "general" KEYS files in our dist dir

[ASF subversion and git services (JIRA)]

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

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

Commit 63a95ea9e95de5584a3debc7d860a33495380f42 in lucene-solr's branch 
refs/heads/branch_7x from [~janhoy]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=63a95ea ]

LUCENE-5143: Fix smoketester, fix RM PGP key check, fix solr DOAP file, add 
CHANGES entry
Remove unused/stale 'copy-to-stage' and '-dist-keys' targets from ant build

(cherry picked from commit 5b96f89)


> rm or formalize dealing with "general" KEYS files in our dist dir
> -
>
> Key: LUCENE-5143
> URL: https://issues.apache.org/jira/browse/LUCENE-5143
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Hoss Man
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 7.5, master (8.0)
>
> Attachments: KEYS, KEYS, KEYS, KEYS, LUCENE-5143-reopen-smoke.patch, 
> LUCENE-5143-reopen-smoke.patch, LUCENE-5143.patch, LUCENE-5143.patch, 
> LUCENE-5143.patch, LUCENE-5143.patch, LUCENE-5143_READMEs.patch, 
> LUCENE-5143_READMEs.patch, LUCENE-5143_READMEs.patch, LUCENE_5143_KEYS.patch, 
> verify.log, verify.sh, verify.sh, verify.sh
>
>
> At some point in the past, we started creating a snapshots of KEYS (taken 
> from the auto-generated data from id.apache.org) in the release dir of each 
> release...
> http://www.apache.org/dist/lucene/solr/4.4.0/KEYS
> http://www.apache.org/dist/lucene/java/4.4.0/KEYS
> http://archive.apache.org/dist/lucene/java/4.3.0/KEYS
> http://archive.apache.org/dist/lucene/solr/4.3.0/KEYS
> etc...
> But we also still have some "general" KEYS files...
> https://www.apache.org/dist/lucene/KEYS
> https://www.apache.org/dist/lucene/java/KEYS
> https://www.apache.org/dist/lucene/solr/KEYS
> ...which (as i discovered when i went to add my key to them today) are stale 
> and don't seem to be getting updated.
> I vaguely remember someone (rmuir?) explaining to me at one point the reason 
> we started creating a fresh copy of KEYS in each release dir, but i no longer 
> remember what they said, and i can't find any mention of a reason in any of 
> the release docs, or in any sort of comment in buildAndPushRelease.py
> we probably do one of the following:
>  * remove these "general" KEYS files
>  * add a disclaimer to the top of these files that they are legacy files for 
> verifying old releases and are no longer used for new releases
>  * ensure these files are up to date stop generating per-release KEYS file 
> copies
>  * update our release process to ensure that the general files get updated on 
> each release as well



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

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

Re: Lucene/Solr 7.5

[Varun Thacker]

Hi Jim,

You beat me to it :) Yeah after looking at Joel's comments there might be
some more work involved. So no point rushing it in 7.5 .

On Tue, Sep 11, 2018 at 1:16 PM jim ferenczi  wrote:

> Sorry but this was just committed to master and branch_7x and I see some
> discussions regarding the implication of this change. Is it really safe to
> include it in 7.5 ?
>
> Le mar. 11 sept. 2018 à 21:43, Varun Thacker  a écrit :
>
>> Hi Jim,
>>
>> I'd like to backport SOLR-11836 if that's okay with you. It's a trivial
>> fix which I committed to master and branch_7x a little while ago.
>>
>> On Tue, Sep 11, 2018 at 9:09 AM jim ferenczi 
>> wrote:
>>
>>> Thanks Steve!
>>>
>>> Le mar. 11 sept. 2018 à 18:02, Steve Rowe  a écrit :
>>>
 Hi Jim,

 > On Sep 11, 2018, at 11:32 AM, jim ferenczi 
 wrote:
 >
 > Could someone help to setup the Jenkins releases build ? It seems
 that I cannot create jobs with my account.


 Each project's PMC Chair is responsible for granting job
 creation/modification permissions on Jenkins:
 https://cwiki.apache.org/confluence/display/INFRA/Jenkins#Jenkins-HowdoIgetanaccount

 I’ll go create the 7.5 jobs now.

 --
 Steve
 www.lucidworks.com

 > On Sep 11, 2018, at 11:32 AM, jim ferenczi 
 wrote:
 >
 > No worries at all Cassandra. What do you think of building the first
 RC on Friday and start the vote on Monday next week ? This will leave some
 > room to finish the missing bits.
 > Could someone help to setup the Jenkins releases build ? It seems
 that I cannot create jobs with my account.
 >
 > Le mar. 11 sept. 2018 à 14:08, Cassandra Targett <
 casstarg...@gmail.com> a écrit :
 > Sorry, Jim, I should have replied yesterday about the state of things
 with the Ref Guide - it's close. I'm doing the last bit of big review I
 need to do and am nearly done with that, then I have a couple more small
 things done (including SOLR-12763 which I just created since I forgot to do
 it earlier). My goal is to be done by the end of my day today so you could
 do the RC tomorrow, but who knows what the day will bring work-wise, so
 I'll send another mail at the end of the day my time to let you know for
 sure.
 >
 > On Mon, Sep 10, 2018 at 9:07 AM jim ferenczi 
 wrote:
 > I just fixed the invalid version (7.5.1) that I added in master and
 7x. The next version on these branches should be 7.6.0, sorry for the 
 noise.
 >
 > Le lun. 10 sept. 2018 à 09:26, jim ferenczi 
 a écrit :
 > Hi,
 >
 > Feature freeze for 7.5 has started, I just created a branch_7_5.:
 >
 > * No new features may be committed to the branch.
 > * Documentation patches, build patches and serious bug fixes may be
 committed to the branch. However, you should submit all patches you want to
 commit to Jira first to give others the chance to review and possibly vote
 against the patch. Keep in mind that it is our main intention to keep the
 branch as stable as possible.
 > * All patches that are intended for the branch should first be
 committed to the unstable branch, merged into the stable branch, and then
 into the current release branch.
 > * Normal unstable and stable branch development may continue as
 usual. However, if you plan to commit a big change to the unstable branch
 while the branch feature freeze is in effect, think twice: can't the
 addition wait a couple more days? Merges of bug fixes into the branch may
 become more difficult.
 > * Only Jira issues with Fix version "7.5" and priority "Blocker" will
 delay a release candidate build.
 >
 > I'll create the first RC later this week depending on the status of
 the Solr ref guide. Cassandra, can you update the status when you think
 that the ref guide is ready (no rush just a reminder that we need to sync
 during this release ;) ) ?
 >
 > Cheers,
 > Jim
 >
 > Le mer. 5 sept. 2018 à 17:57, Erick Erickson 
 a écrit :
 > Great, thanks!
 > On Wed, Sep 5, 2018 at 8:44 AM jim ferenczi 
 wrote:
 > >
 > > Sure it can wait a few days. Let's cut the branch next Monday and
 we can sync with Cassandra to create the first RC when the ref guide is
 ready.
 > >
 > > Le mer. 5 sept. 2018 à 17:27, Erick Erickson <
 erickerick...@gmail.com> a écrit :
 > >>
 > >> Jim:
 > >>
 > >> I know it's the 11th hour, but WDYT about cutting the branch next
 > >> Monday? We see a flurry of activity (announcing a release does
 > >> that) and waiting to cut the branch might be easiest all
 'round.
 > >>
 > >> Up to you of course, I can backport the test fixes I'd like for
 > >> instance and I'd like to get the upgraded ZooKeeper in 7.5.
 > >>
 > >> Erick
 > >> On Tue, Sep 4, 2018 at 1:04 PM Cassandra 

[jira] [Commented] (SOLR-11836) Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-11836:
-

limit:-1 should work fine for JSON Facets.

bq. Also when I sent -1 directly to the JSON facet API it didn't return 
results. I'll need to dig into why.
Perhaps other code in the middle (i.e. before it gets to the JSON Facet code) 
manipulates that value and messes it up?

TestJsonFacets randomly specifies limit:-1 so this should be well tested too:
https://github.com/apache/lucene-solr/blob/master/solr/core/src/test/org/apache/solr/search/facet/TestJsonFacets.java#L935


> Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API
> 
>
> Key: SOLR-11836
> URL: https://issues.apache.org/jira/browse/SOLR-11836
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Alfonso Muñoz-Pomer Fuentes
>Priority: Major
>  Labels: facet, streaming
> Attachments: SOLR-11836.patch
>
>
> Currently, to retrieve all buckets using the streaming expressions facet 
> function, the {{bucketSizeLimit}} parameter must have a high enough value so 
> that all results will be included. Compare this with the JSON facet API, 
> where you can use {{"limit": -1}} to achieve this. It would help if such a 
> possibility existed.
> [Issue 11236|https://issues.apache.org/jira/browse/SOLR-11236] is related.



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

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

[jira] [Commented] (SOLR-11836) Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-11836:
---

I believe the Integer.MAX_VALUE is safe to use based on a review of 
*FacetFieldProcessor*.

I will test out this patch locally.

> Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API
> 
>
> Key: SOLR-11836
> URL: https://issues.apache.org/jira/browse/SOLR-11836
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Alfonso Muñoz-Pomer Fuentes
>Priority: Major
>  Labels: facet, streaming
> Attachments: SOLR-11836.patch
>
>
> Currently, to retrieve all buckets using the streaming expressions facet 
> function, the {{bucketSizeLimit}} parameter must have a high enough value so 
> that all results will be included. Compare this with the JSON facet API, 
> where you can use {{"limit": -1}} to achieve this. It would help if such a 
> possibility existed.
> [Issue 11236|https://issues.apache.org/jira/browse/SOLR-11236] is related.



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

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

[jira] [Commented] (LUCENE-7862) Should BKD cells store their min/max packed values?

[JIRA]

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

Jan Høydahl commented on LUCENE-7862:
-

[~ivera], it appears that your CHANGES entry for the 7x and 7_5 branches is 
listed under 7.5.4 instead of 7.5.0.

> Should BKD cells store their min/max packed values?
> ---
>
> Key: LUCENE-7862
> URL: https://issues.apache.org/jira/browse/LUCENE-7862
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Ignacio Vera
>Priority: Minor
> Fix For: 7.5, master (8.0)
>
> Attachments: LUCENE-7862.patch, LUCENE-7862.patch, LUCENE-7862.patch
>
>
> The index of the BKD tree already allows to know lower and upper bounds of 
> values in a given dimension. However the actual range of values might be more 
> narrow than what the index tells us, especially if splitting on one dimension 
> reduces the range of values in at least one other dimension. For instance 
> this tends to be the case with range fields: since we enforce that lower 
> bounds are less than upper bounds, splitting on one dimension will also 
> affect the range of values in the other dimension.
> So I'm wondering whether we should store the actual range of values for each 
> dimension in leaf blocks, this will hopefully allow to figure out that either 
> none or all values match in a block without having to check them all.



--
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-5143) rm or formalize dealing with "general" KEYS files in our dist dir

[ASF subversion and git services (JIRA)]

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

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

Commit 5b96f89d2b038bff2ed3351887a87108f7cc6ea3 in lucene-solr's branch 
refs/heads/master from [~janhoy]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5b96f89 ]

LUCENE-5143: Fix smoketester, fix RM PGP key check, fix solr DOAP file, add 
CHANGES entry
Remove unused/stale 'copy-to-stage' and '-dist-keys' targets from ant build


> rm or formalize dealing with "general" KEYS files in our dist dir
> -
>
> Key: LUCENE-5143
> URL: https://issues.apache.org/jira/browse/LUCENE-5143
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Hoss Man
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 7.5, master (8.0)
>
> Attachments: KEYS, KEYS, KEYS, KEYS, LUCENE-5143-reopen-smoke.patch, 
> LUCENE-5143-reopen-smoke.patch, LUCENE-5143.patch, LUCENE-5143.patch, 
> LUCENE-5143.patch, LUCENE-5143.patch, LUCENE-5143_READMEs.patch, 
> LUCENE-5143_READMEs.patch, LUCENE-5143_READMEs.patch, LUCENE_5143_KEYS.patch, 
> verify.log, verify.sh, verify.sh, verify.sh
>
>
> At some point in the past, we started creating a snapshots of KEYS (taken 
> from the auto-generated data from id.apache.org) in the release dir of each 
> release...
> http://www.apache.org/dist/lucene/solr/4.4.0/KEYS
> http://www.apache.org/dist/lucene/java/4.4.0/KEYS
> http://archive.apache.org/dist/lucene/java/4.3.0/KEYS
> http://archive.apache.org/dist/lucene/solr/4.3.0/KEYS
> etc...
> But we also still have some "general" KEYS files...
> https://www.apache.org/dist/lucene/KEYS
> https://www.apache.org/dist/lucene/java/KEYS
> https://www.apache.org/dist/lucene/solr/KEYS
> ...which (as i discovered when i went to add my key to them today) are stale 
> and don't seem to be getting updated.
> I vaguely remember someone (rmuir?) explaining to me at one point the reason 
> we started creating a fresh copy of KEYS in each release dir, but i no longer 
> remember what they said, and i can't find any mention of a reason in any of 
> the release docs, or in any sort of comment in buildAndPushRelease.py
> we probably do one of the following:
>  * remove these "general" KEYS files
>  * add a disclaimer to the top of these files that they are legacy files for 
> verifying old releases and are no longer used for new releases
>  * ensure these files are up to date stop generating per-release KEYS file 
> copies
>  * update our release process to ensure that the general files get updated on 
> each release as well



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

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

Re: Lucene/Solr 7.5

[jim ferenczi]

Perfect, thanks Cassandra !

Le mar. 11 sept. 2018 à 22:35, Cassandra Targett  a
écrit :

> Jim, your suggestion of Friday for the RC & vote on Monday sounds great.
>
> I'm done with my major reviews/edits. I still have the smaller typos I
> look for to do - I can skip those if I have to, but realistically I can
> probably get them done tomorrow.
>
> Cassandra
>
> On Tue, Sep 11, 2018 at 3:16 PM jim ferenczi 
> wrote:
>
>> Sorry but this was just committed to master and branch_7x and I see some
>> discussions regarding the implication of this change. Is it really safe to
>> include it in 7.5 ?
>>
>> Le mar. 11 sept. 2018 à 21:43, Varun Thacker  a
>> écrit :
>>
>>> Hi Jim,
>>>
>>> I'd like to backport SOLR-11836 if that's okay with you. It's a trivial
>>> fix which I committed to master and branch_7x a little while ago.
>>>
>>> On Tue, Sep 11, 2018 at 9:09 AM jim ferenczi 
>>> wrote:
>>>
 Thanks Steve!

 Le mar. 11 sept. 2018 à 18:02, Steve Rowe  a écrit :

> Hi Jim,
>
> > On Sep 11, 2018, at 11:32 AM, jim ferenczi 
> wrote:
> >
> > Could someone help to setup the Jenkins releases build ? It seems
> that I cannot create jobs with my account.
>
>
> Each project's PMC Chair is responsible for granting job
> creation/modification permissions on Jenkins:
> https://cwiki.apache.org/confluence/display/INFRA/Jenkins#Jenkins-HowdoIgetanaccount
>
> I’ll go create the 7.5 jobs now.
>
> --
> Steve
> www.lucidworks.com
>
> > On Sep 11, 2018, at 11:32 AM, jim ferenczi 
> wrote:
> >
> > No worries at all Cassandra. What do you think of building the first
> RC on Friday and start the vote on Monday next week ? This will leave some
> > room to finish the missing bits.
> > Could someone help to setup the Jenkins releases build ? It seems
> that I cannot create jobs with my account.
> >
> > Le mar. 11 sept. 2018 à 14:08, Cassandra Targett <
> casstarg...@gmail.com> a écrit :
> > Sorry, Jim, I should have replied yesterday about the state of
> things with the Ref Guide - it's close. I'm doing the last bit of big
> review I need to do and am nearly done with that, then I have a couple 
> more
> small things done (including SOLR-12763 which I just created since I 
> forgot
> to do it earlier). My goal is to be done by the end of my day today so you
> could do the RC tomorrow, but who knows what the day will bring work-wise,
> so I'll send another mail at the end of the day my time to let you know 
> for
> sure.
> >
> > On Mon, Sep 10, 2018 at 9:07 AM jim ferenczi 
> wrote:
> > I just fixed the invalid version (7.5.1) that I added in master and
> 7x. The next version on these branches should be 7.6.0, sorry for the 
> noise.
> >
> > Le lun. 10 sept. 2018 à 09:26, jim ferenczi 
> a écrit :
> > Hi,
> >
> > Feature freeze for 7.5 has started, I just created a branch_7_5.:
> >
> > * No new features may be committed to the branch.
> > * Documentation patches, build patches and serious bug fixes may be
> committed to the branch. However, you should submit all patches you want 
> to
> commit to Jira first to give others the chance to review and possibly vote
> against the patch. Keep in mind that it is our main intention to keep the
> branch as stable as possible.
> > * All patches that are intended for the branch should first be
> committed to the unstable branch, merged into the stable branch, and then
> into the current release branch.
> > * Normal unstable and stable branch development may continue as
> usual. However, if you plan to commit a big change to the unstable branch
> while the branch feature freeze is in effect, think twice: can't the
> addition wait a couple more days? Merges of bug fixes into the branch may
> become more difficult.
> > * Only Jira issues with Fix version "7.5" and priority "Blocker"
> will delay a release candidate build.
> >
> > I'll create the first RC later this week depending on the status of
> the Solr ref guide. Cassandra, can you update the status when you think
> that the ref guide is ready (no rush just a reminder that we need to sync
> during this release ;) ) ?
> >
> > Cheers,
> > Jim
> >
> > Le mer. 5 sept. 2018 à 17:57, Erick Erickson <
> erickerick...@gmail.com> a écrit :
> > Great, thanks!
> > On Wed, Sep 5, 2018 at 8:44 AM jim ferenczi 
> wrote:
> > >
> > > Sure it can wait a few days. Let's cut the branch next Monday and
> we can sync with Cassandra to create the first RC when the ref guide is
> ready.
> > >
> > > Le mer. 5 sept. 2018 à 17:27, Erick Erickson <
> erickerick...@gmail.com> a écrit :
> > >>
> > >> Jim:
> > >>
> > >> I know it's the 11th hour, but WDYT about cutting the branch 

Re: Lucene/Solr 7.5

[Cassandra Targett]

Jim, your suggestion of Friday for the RC & vote on Monday sounds great.

I'm done with my major reviews/edits. I still have the smaller typos I look
for to do - I can skip those if I have to, but realistically I can probably
get them done tomorrow.

Cassandra

On Tue, Sep 11, 2018 at 3:16 PM jim ferenczi  wrote:

> Sorry but this was just committed to master and branch_7x and I see some
> discussions regarding the implication of this change. Is it really safe to
> include it in 7.5 ?
>
> Le mar. 11 sept. 2018 à 21:43, Varun Thacker  a écrit :
>
>> Hi Jim,
>>
>> I'd like to backport SOLR-11836 if that's okay with you. It's a trivial
>> fix which I committed to master and branch_7x a little while ago.
>>
>> On Tue, Sep 11, 2018 at 9:09 AM jim ferenczi 
>> wrote:
>>
>>> Thanks Steve!
>>>
>>> Le mar. 11 sept. 2018 à 18:02, Steve Rowe  a écrit :
>>>
 Hi Jim,

 > On Sep 11, 2018, at 11:32 AM, jim ferenczi 
 wrote:
 >
 > Could someone help to setup the Jenkins releases build ? It seems
 that I cannot create jobs with my account.


 Each project's PMC Chair is responsible for granting job
 creation/modification permissions on Jenkins:
 https://cwiki.apache.org/confluence/display/INFRA/Jenkins#Jenkins-HowdoIgetanaccount

 I’ll go create the 7.5 jobs now.

 --
 Steve
 www.lucidworks.com

 > On Sep 11, 2018, at 11:32 AM, jim ferenczi 
 wrote:
 >
 > No worries at all Cassandra. What do you think of building the first
 RC on Friday and start the vote on Monday next week ? This will leave some
 > room to finish the missing bits.
 > Could someone help to setup the Jenkins releases build ? It seems
 that I cannot create jobs with my account.
 >
 > Le mar. 11 sept. 2018 à 14:08, Cassandra Targett <
 casstarg...@gmail.com> a écrit :
 > Sorry, Jim, I should have replied yesterday about the state of things
 with the Ref Guide - it's close. I'm doing the last bit of big review I
 need to do and am nearly done with that, then I have a couple more small
 things done (including SOLR-12763 which I just created since I forgot to do
 it earlier). My goal is to be done by the end of my day today so you could
 do the RC tomorrow, but who knows what the day will bring work-wise, so
 I'll send another mail at the end of the day my time to let you know for
 sure.
 >
 > On Mon, Sep 10, 2018 at 9:07 AM jim ferenczi 
 wrote:
 > I just fixed the invalid version (7.5.1) that I added in master and
 7x. The next version on these branches should be 7.6.0, sorry for the 
 noise.
 >
 > Le lun. 10 sept. 2018 à 09:26, jim ferenczi 
 a écrit :
 > Hi,
 >
 > Feature freeze for 7.5 has started, I just created a branch_7_5.:
 >
 > * No new features may be committed to the branch.
 > * Documentation patches, build patches and serious bug fixes may be
 committed to the branch. However, you should submit all patches you want to
 commit to Jira first to give others the chance to review and possibly vote
 against the patch. Keep in mind that it is our main intention to keep the
 branch as stable as possible.
 > * All patches that are intended for the branch should first be
 committed to the unstable branch, merged into the stable branch, and then
 into the current release branch.
 > * Normal unstable and stable branch development may continue as
 usual. However, if you plan to commit a big change to the unstable branch
 while the branch feature freeze is in effect, think twice: can't the
 addition wait a couple more days? Merges of bug fixes into the branch may
 become more difficult.
 > * Only Jira issues with Fix version "7.5" and priority "Blocker" will
 delay a release candidate build.
 >
 > I'll create the first RC later this week depending on the status of
 the Solr ref guide. Cassandra, can you update the status when you think
 that the ref guide is ready (no rush just a reminder that we need to sync
 during this release ;) ) ?
 >
 > Cheers,
 > Jim
 >
 > Le mer. 5 sept. 2018 à 17:57, Erick Erickson 
 a écrit :
 > Great, thanks!
 > On Wed, Sep 5, 2018 at 8:44 AM jim ferenczi 
 wrote:
 > >
 > > Sure it can wait a few days. Let's cut the branch next Monday and
 we can sync with Cassandra to create the first RC when the ref guide is
 ready.
 > >
 > > Le mer. 5 sept. 2018 à 17:27, Erick Erickson <
 erickerick...@gmail.com> a écrit :
 > >>
 > >> Jim:
 > >>
 > >> I know it's the 11th hour, but WDYT about cutting the branch next
 > >> Monday? We see a flurry of activity (announcing a release does
 > >> that) and waiting to cut the branch might be easiest all
 'round.
 > >>
 > >> Up to you of course, I can backport the test fixes I'd like for
 > >> instance and I'd like 

Re: Lucene/Solr 7.5

[jim ferenczi]

Sorry but this was just committed to master and branch_7x and I see some
discussions regarding the implication of this change. Is it really safe to
include it in 7.5 ?

Le mar. 11 sept. 2018 à 21:43, Varun Thacker  a écrit :

> Hi Jim,
>
> I'd like to backport SOLR-11836 if that's okay with you. It's a trivial
> fix which I committed to master and branch_7x a little while ago.
>
> On Tue, Sep 11, 2018 at 9:09 AM jim ferenczi 
> wrote:
>
>> Thanks Steve!
>>
>> Le mar. 11 sept. 2018 à 18:02, Steve Rowe  a écrit :
>>
>>> Hi Jim,
>>>
>>> > On Sep 11, 2018, at 11:32 AM, jim ferenczi 
>>> wrote:
>>> >
>>> > Could someone help to setup the Jenkins releases build ? It seems that
>>> I cannot create jobs with my account.
>>>
>>>
>>> Each project's PMC Chair is responsible for granting job
>>> creation/modification permissions on Jenkins:
>>> https://cwiki.apache.org/confluence/display/INFRA/Jenkins#Jenkins-HowdoIgetanaccount
>>>
>>> I’ll go create the 7.5 jobs now.
>>>
>>> --
>>> Steve
>>> www.lucidworks.com
>>>
>>> > On Sep 11, 2018, at 11:32 AM, jim ferenczi 
>>> wrote:
>>> >
>>> > No worries at all Cassandra. What do you think of building the first
>>> RC on Friday and start the vote on Monday next week ? This will leave some
>>> > room to finish the missing bits.
>>> > Could someone help to setup the Jenkins releases build ? It seems that
>>> I cannot create jobs with my account.
>>> >
>>> > Le mar. 11 sept. 2018 à 14:08, Cassandra Targett <
>>> casstarg...@gmail.com> a écrit :
>>> > Sorry, Jim, I should have replied yesterday about the state of things
>>> with the Ref Guide - it's close. I'm doing the last bit of big review I
>>> need to do and am nearly done with that, then I have a couple more small
>>> things done (including SOLR-12763 which I just created since I forgot to do
>>> it earlier). My goal is to be done by the end of my day today so you could
>>> do the RC tomorrow, but who knows what the day will bring work-wise, so
>>> I'll send another mail at the end of the day my time to let you know for
>>> sure.
>>> >
>>> > On Mon, Sep 10, 2018 at 9:07 AM jim ferenczi 
>>> wrote:
>>> > I just fixed the invalid version (7.5.1) that I added in master and
>>> 7x. The next version on these branches should be 7.6.0, sorry for the noise.
>>> >
>>> > Le lun. 10 sept. 2018 à 09:26, jim ferenczi 
>>> a écrit :
>>> > Hi,
>>> >
>>> > Feature freeze for 7.5 has started, I just created a branch_7_5.:
>>> >
>>> > * No new features may be committed to the branch.
>>> > * Documentation patches, build patches and serious bug fixes may be
>>> committed to the branch. However, you should submit all patches you want to
>>> commit to Jira first to give others the chance to review and possibly vote
>>> against the patch. Keep in mind that it is our main intention to keep the
>>> branch as stable as possible.
>>> > * All patches that are intended for the branch should first be
>>> committed to the unstable branch, merged into the stable branch, and then
>>> into the current release branch.
>>> > * Normal unstable and stable branch development may continue as usual.
>>> However, if you plan to commit a big change to the unstable branch while
>>> the branch feature freeze is in effect, think twice: can't the addition
>>> wait a couple more days? Merges of bug fixes into the branch may become
>>> more difficult.
>>> > * Only Jira issues with Fix version "7.5" and priority "Blocker" will
>>> delay a release candidate build.
>>> >
>>> > I'll create the first RC later this week depending on the status of
>>> the Solr ref guide. Cassandra, can you update the status when you think
>>> that the ref guide is ready (no rush just a reminder that we need to sync
>>> during this release ;) ) ?
>>> >
>>> > Cheers,
>>> > Jim
>>> >
>>> > Le mer. 5 sept. 2018 à 17:57, Erick Erickson 
>>> a écrit :
>>> > Great, thanks!
>>> > On Wed, Sep 5, 2018 at 8:44 AM jim ferenczi 
>>> wrote:
>>> > >
>>> > > Sure it can wait a few days. Let's cut the branch next Monday and we
>>> can sync with Cassandra to create the first RC when the ref guide is ready.
>>> > >
>>> > > Le mer. 5 sept. 2018 à 17:27, Erick Erickson <
>>> erickerick...@gmail.com> a écrit :
>>> > >>
>>> > >> Jim:
>>> > >>
>>> > >> I know it's the 11th hour, but WDYT about cutting the branch next
>>> > >> Monday? We see a flurry of activity (announcing a release does
>>> > >> that) and waiting to cut the branch might be easiest all 'round.
>>> > >>
>>> > >> Up to you of course, I can backport the test fixes I'd like for
>>> > >> instance and I'd like to get the upgraded ZooKeeper in 7.5.
>>> > >>
>>> > >> Erick
>>> > >> On Tue, Sep 4, 2018 at 1:04 PM Cassandra Targett <
>>> casstarg...@gmail.com> wrote:
>>> > >> >
>>> > >> > It's not so much the building of the RC as giving the content a
>>> detailed editorial review.
>>> > >> >
>>> > >> > The build/release process itself is well-documented and published
>>> with every Ref Guide:
>>> 

[jira] [Commented] (SOLR-11836) Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-11836:
---

Also when I sent -1 directly to the JSON facet API it didn't return results. 
I'll need to dig into why.

> Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API
> 
>
> Key: SOLR-11836
> URL: https://issues.apache.org/jira/browse/SOLR-11836
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Alfonso Muñoz-Pomer Fuentes
>Priority: Major
>  Labels: facet, streaming
> Attachments: SOLR-11836.patch
>
>
> Currently, to retrieve all buckets using the streaming expressions facet 
> function, the {{bucketSizeLimit}} parameter must have a high enough value so 
> that all results will be included. Compare this with the JSON facet API, 
> where you can use {{"limit": -1}} to achieve this. It would help if such a 
> possibility existed.
> [Issue 11236|https://issues.apache.org/jira/browse/SOLR-11236] is related.



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

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

[jira] [Commented] (SOLR-11836) Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-11836:
---

In that particular spot there are no array allocations made. It may be that in 
the lower level facet collecting code that array allocations are made based on 
limit. We could dig and see how the limit is being used and/or also ping Yonik 
and see what he thinks.

[~ysee...@gmail.com], do you feel it's safe to be setting the facet bucket 
limit to Integer.MAX_VALUE? 

> Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API
> 
>
> Key: SOLR-11836
> URL: https://issues.apache.org/jira/browse/SOLR-11836
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Alfonso Muñoz-Pomer Fuentes
>Priority: Major
>  Labels: facet, streaming
> Attachments: SOLR-11836.patch
>
>
> Currently, to retrieve all buckets using the streaming expressions facet 
> function, the {{bucketSizeLimit}} parameter must have a high enough value so 
> that all results will be included. Compare this with the JSON facet API, 
> where you can use {{"limit": -1}} to achieve this. It would help if such a 
> possibility existed.
> [Issue 11236|https://issues.apache.org/jira/browse/SOLR-11236] is related.



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

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

[jira] [Commented] (SOLR-11836) Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-11836:
--

I think we need to modify the patch a little after Joe's comment. We shouldn't 
use nteger.MAX_VALUE explicitly from FacetStream. We should just pass down -1 
and then let JSON Facets deal with -1 as it does currently .

So essentially remove this 
{code:java}
if (this.bucketSizeLimit == -1) {
  this.bucketSizeLimit = Integer.MAX_VALUE;
}{code}

> Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API
> 
>
> Key: SOLR-11836
> URL: https://issues.apache.org/jira/browse/SOLR-11836
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Alfonso Muñoz-Pomer Fuentes
>Priority: Major
>  Labels: facet, streaming
> Attachments: SOLR-11836.patch
>
>
> Currently, to retrieve all buckets using the streaming expressions facet 
> function, the {{bucketSizeLimit}} parameter must have a high enough value so 
> that all results will be included. Compare this with the JSON facet API, 
> where you can use {{"limit": -1}} to achieve this. It would help if such a 
> possibility existed.
> [Issue 11236|https://issues.apache.org/jira/browse/SOLR-11236] is related.



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

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

[jira] [Commented] (SOLR-11836) Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-11836:
--

Hi Joel,

I checked FacetFieldMerger and saw this statement which is why I assumed doing 
the same thing in FacetStream would be the right thing to do. 
{code:java}
int lim = freq.limit >= 0 ? (int)freq.limit : Integer.MAX_VALUE;{code}
{quote}or example it's possible that the JSON API is pre-allocating one or more 
arrays of that size.
{quote}
If this is happening perhaps we should create another Jira as this would affect 
JSON Facet API users as well? 

> Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API
> 
>
> Key: SOLR-11836
> URL: https://issues.apache.org/jira/browse/SOLR-11836
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Alfonso Muñoz-Pomer Fuentes
>Priority: Major
>  Labels: facet, streaming
> Attachments: SOLR-11836.patch
>
>
> Currently, to retrieve all buckets using the streaming expressions facet 
> function, the {{bucketSizeLimit}} parameter must have a high enough value so 
> that all results will be included. Compare this with the JSON facet API, 
> where you can use {{"limit": -1}} to achieve this. It would help if such a 
> possibility existed.
> [Issue 11236|https://issues.apache.org/jira/browse/SOLR-11236] is related.



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

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

[jira] [Commented] (SOLR-11836) Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-11836:
---

I was just looking this over and testing some things out locally.

I tested just sending -1 to the JSON -f-acet API and it didn't return results. 
It's also not a documented thing to do.

I see that the patch sets the limit to Integer.MAX_VALUE. It would be good to 
understand how this effects the internal data structures used by the JSON facet 
API. For example it's possible that the JSON API is pre-allocating one or more 
arrays of that size. This would not be an unusual thing todo inside Solr. If 
that's the case then setting limit to Integer.MAX_VALUE would be something that 
we want to avoid.

> Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API
> 
>
> Key: SOLR-11836
> URL: https://issues.apache.org/jira/browse/SOLR-11836
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Alfonso Muñoz-Pomer Fuentes
>Priority: Major
>  Labels: facet, streaming
> Attachments: SOLR-11836.patch
>
>
> Currently, to retrieve all buckets using the streaming expressions facet 
> function, the {{bucketSizeLimit}} parameter must have a high enough value so 
> that all results will be included. Compare this with the JSON facet API, 
> where you can use {{"limit": -1}} to achieve this. It would help if such a 
> possibility existed.
> [Issue 11236|https://issues.apache.org/jira/browse/SOLR-11236] is related.



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

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

[jira] [Comment Edited] (SOLR-11836) Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-11836 at 9/11/18 7:49 PM:


I was just looking this over and testing some things out locally.

I tested just sending -1 to the JSON facet API and it didn't return results. 
It's also not a documented thing to do.

I see that the patch sets the limit to Integer.MAX_VALUE. It would be good to 
understand how this effects the internal data structures used by the JSON facet 
API. For example it's possible that the JSON API is pre-allocating one or more 
arrays of that size. This would not be an unusual thing todo inside Solr. If 
that's the case then setting limit to Integer.MAX_VALUE would be something that 
we want to avoid.


was (Author: joel.bernstein):
I was just looking this over and testing some things out locally.

I tested just sending -1 to the JSON -f-acet API and it didn't return results. 
It's also not a documented thing to do.

I see that the patch sets the limit to Integer.MAX_VALUE. It would be good to 
understand how this effects the internal data structures used by the JSON facet 
API. For example it's possible that the JSON API is pre-allocating one or more 
arrays of that size. This would not be an unusual thing todo inside Solr. If 
that's the case then setting limit to Integer.MAX_VALUE would be something that 
we want to avoid.

> Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API
> 
>
> Key: SOLR-11836
> URL: https://issues.apache.org/jira/browse/SOLR-11836
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Alfonso Muñoz-Pomer Fuentes
>Priority: Major
>  Labels: facet, streaming
> Attachments: SOLR-11836.patch
>
>
> Currently, to retrieve all buckets using the streaming expressions facet 
> function, the {{bucketSizeLimit}} parameter must have a high enough value so 
> that all results will be included. Compare this with the JSON facet API, 
> where you can use {{"limit": -1}} to achieve this. It would help if such a 
> possibility existed.
> [Issue 11236|https://issues.apache.org/jira/browse/SOLR-11236] is related.



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

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

[jira] [Created] (LUCENE-8495) ComplexPhraseQuery.rewrite throws "Unknown query type:org.apache.lucene.search.SynonymQuery" when nested BooleanQuery contains a SynonymQuery

[Bjarke Mortensen (JIRA)]

Bjarke Mortensen created LUCENE-8495:


 Summary: ComplexPhraseQuery.rewrite throws "Unknown query 
type:org.apache.lucene.search.SynonymQuery" when nested BooleanQuery contains a 
SynonymQuery 
 Key: LUCENE-8495
 URL: https://issues.apache.org/jira/browse/LUCENE-8495
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/queryparser
Affects Versions: 7.4
Reporter: Bjarke Mortensen
 Attachments: 
0001-Added-support-for-nested-synonym-queries-in-ComplexP.patch

When using nested queries in ComplexPhrases, and a part of the query is a 
SynonymQuery, an exception is thrown from  addComplexPhraseClause:

{{throw new IllegalArgumentException("Unknown query type:"}}
{{ + childQuery.getClass().getName());}}

Examples (dogs and tv are synonyms):

{{"(cats OR dogs) cigar"}}

"platform* (video* OR tv)"~10

The bug is similar in nature to LUCENE-8305, in that SynonymQuery support was 
added to ComplexPhraseQueryParser (in LUCENE-7695), but was not expanded to 
nested queries.

The fix is similar to the one in LUCENE-8305, namely to add the same logic in 
addComplexPhraseClause as in rewrite.

See attached patch.



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

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

Re: Lucene/Solr 7.5

[Varun Thacker]

Hi Jim,

I'd like to backport SOLR-11836 if that's okay with you. It's a trivial fix
which I committed to master and branch_7x a little while ago.

On Tue, Sep 11, 2018 at 9:09 AM jim ferenczi  wrote:

> Thanks Steve!
>
> Le mar. 11 sept. 2018 à 18:02, Steve Rowe  a écrit :
>
>> Hi Jim,
>>
>> > On Sep 11, 2018, at 11:32 AM, jim ferenczi 
>> wrote:
>> >
>> > Could someone help to setup the Jenkins releases build ? It seems that
>> I cannot create jobs with my account.
>>
>>
>> Each project's PMC Chair is responsible for granting job
>> creation/modification permissions on Jenkins:
>> https://cwiki.apache.org/confluence/display/INFRA/Jenkins#Jenkins-HowdoIgetanaccount
>>
>> I’ll go create the 7.5 jobs now.
>>
>> --
>> Steve
>> www.lucidworks.com
>>
>> > On Sep 11, 2018, at 11:32 AM, jim ferenczi 
>> wrote:
>> >
>> > No worries at all Cassandra. What do you think of building the first RC
>> on Friday and start the vote on Monday next week ? This will leave some
>> > room to finish the missing bits.
>> > Could someone help to setup the Jenkins releases build ? It seems that
>> I cannot create jobs with my account.
>> >
>> > Le mar. 11 sept. 2018 à 14:08, Cassandra Targett 
>> a écrit :
>> > Sorry, Jim, I should have replied yesterday about the state of things
>> with the Ref Guide - it's close. I'm doing the last bit of big review I
>> need to do and am nearly done with that, then I have a couple more small
>> things done (including SOLR-12763 which I just created since I forgot to do
>> it earlier). My goal is to be done by the end of my day today so you could
>> do the RC tomorrow, but who knows what the day will bring work-wise, so
>> I'll send another mail at the end of the day my time to let you know for
>> sure.
>> >
>> > On Mon, Sep 10, 2018 at 9:07 AM jim ferenczi 
>> wrote:
>> > I just fixed the invalid version (7.5.1) that I added in master and 7x.
>> The next version on these branches should be 7.6.0, sorry for the noise.
>> >
>> > Le lun. 10 sept. 2018 à 09:26, jim ferenczi  a
>> écrit :
>> > Hi,
>> >
>> > Feature freeze for 7.5 has started, I just created a branch_7_5.:
>> >
>> > * No new features may be committed to the branch.
>> > * Documentation patches, build patches and serious bug fixes may be
>> committed to the branch. However, you should submit all patches you want to
>> commit to Jira first to give others the chance to review and possibly vote
>> against the patch. Keep in mind that it is our main intention to keep the
>> branch as stable as possible.
>> > * All patches that are intended for the branch should first be
>> committed to the unstable branch, merged into the stable branch, and then
>> into the current release branch.
>> > * Normal unstable and stable branch development may continue as usual.
>> However, if you plan to commit a big change to the unstable branch while
>> the branch feature freeze is in effect, think twice: can't the addition
>> wait a couple more days? Merges of bug fixes into the branch may become
>> more difficult.
>> > * Only Jira issues with Fix version "7.5" and priority "Blocker" will
>> delay a release candidate build.
>> >
>> > I'll create the first RC later this week depending on the status of the
>> Solr ref guide. Cassandra, can you update the status when you think that
>> the ref guide is ready (no rush just a reminder that we need to sync during
>> this release ;) ) ?
>> >
>> > Cheers,
>> > Jim
>> >
>> > Le mer. 5 sept. 2018 à 17:57, Erick Erickson 
>> a écrit :
>> > Great, thanks!
>> > On Wed, Sep 5, 2018 at 8:44 AM jim ferenczi 
>> wrote:
>> > >
>> > > Sure it can wait a few days. Let's cut the branch next Monday and we
>> can sync with Cassandra to create the first RC when the ref guide is ready.
>> > >
>> > > Le mer. 5 sept. 2018 à 17:27, Erick Erickson 
>> a écrit :
>> > >>
>> > >> Jim:
>> > >>
>> > >> I know it's the 11th hour, but WDYT about cutting the branch next
>> > >> Monday? We see a flurry of activity (announcing a release does
>> > >> that) and waiting to cut the branch might be easiest all 'round.
>> > >>
>> > >> Up to you of course, I can backport the test fixes I'd like for
>> > >> instance and I'd like to get the upgraded ZooKeeper in 7.5.
>> > >>
>> > >> Erick
>> > >> On Tue, Sep 4, 2018 at 1:04 PM Cassandra Targett <
>> casstarg...@gmail.com> wrote:
>> > >> >
>> > >> > It's not so much the building of the RC as giving the content a
>> detailed editorial review.
>> > >> >
>> > >> > The build/release process itself is well-documented and published
>> with every Ref Guide:
>> https://lucene.apache.org/solr/guide/how-to-contribute.html#building-publishing-the-guide.
>> It was designed from the artifact process, so it's nearly identical as a
>> process. It's really barely a burden.
>> > >> >
>> > >> > In terms of preparing the content, there are a number of things I
>> do:
>> > >> >
>> > >> > First, I try to ensure that every issue in CHANGES.txt that should
>> be documented has been documented. That involves an intensive 

[jira] [Commented] (SOLR-11836) Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11836:


Commit 1c493552a23741c4c2319ca35e5018603853db46 in lucene-solr's branch 
refs/heads/branch_7x from [~varunthacker]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1c49355 ]

SOLR-11836: add all contributors for the patch

(cherry picked from commit 2b553f0)


> Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API
> 
>
> Key: SOLR-11836
> URL: https://issues.apache.org/jira/browse/SOLR-11836
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Alfonso Muñoz-Pomer Fuentes
>Priority: Major
>  Labels: facet, streaming
> Attachments: SOLR-11836.patch
>
>
> Currently, to retrieve all buckets using the streaming expressions facet 
> function, the {{bucketSizeLimit}} parameter must have a high enough value so 
> that all results will be included. Compare this with the JSON facet API, 
> where you can use {{"limit": -1}} to achieve this. It would help if such a 
> possibility existed.
> [Issue 11236|https://issues.apache.org/jira/browse/SOLR-11236] is related.



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

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

[jira] [Commented] (SOLR-11836) Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11836:


Commit 2b553f03bec74f65604334b5047a9ce68dd5d344 in lucene-solr's branch 
refs/heads/master from [~varunthacker]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2b553f0 ]

SOLR-11836: add all contributors for the patch


> Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API
> 
>
> Key: SOLR-11836
> URL: https://issues.apache.org/jira/browse/SOLR-11836
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Alfonso Muñoz-Pomer Fuentes
>Priority: Major
>  Labels: facet, streaming
> Attachments: SOLR-11836.patch
>
>
> Currently, to retrieve all buckets using the streaming expressions facet 
> function, the {{bucketSizeLimit}} parameter must have a high enough value so 
> that all results will be included. Compare this with the JSON facet API, 
> where you can use {{"limit": -1}} to achieve this. It would help if such a 
> possibility existed.
> [Issue 11236|https://issues.apache.org/jira/browse/SOLR-11236] is related.



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

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

[jira] [Commented] (LUCENE-8343) BlendedInfixSuggester bad score calculus for certain suggestion weights

[ASF subversion and git services (JIRA)]

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

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

Commit d6143867df97d61f6d4eaafcce21b2319b5de602 in lucene-solr's branch 
refs/heads/master from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d614386 ]

LUCENE-8343: add CHANGES entry


> BlendedInfixSuggester bad score calculus for certain suggestion weights
> ---
>
> Key: LUCENE-8343
> URL: https://issues.apache.org/jira/browse/LUCENE-8343
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 7.3.1
>Reporter: Alessandro Benedetti
>Priority: Major
> Fix For: master (8.0)
>
> Attachments: LUCENE-8343.patch, LUCENE-8343.patch, LUCENE-8343.patch, 
> LUCENE-8343.patch, LUCENE-8343.patch, LUCENE-8343.patch
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Currently the BlendedInfixSuggester return a (long) score to rank the 
> suggestions.
> This score is calculated as a multiplication between :
> long *Weight* : the suggestion weight, coming from a document field, it can 
> be any long value ( including 1, 0,.. )
> double *Coefficient* : 0<=x<=1, calculated based on the position match, 
> earlier the better
> The resulting score is a long, which means that at the moment, any weight<10 
> can bring inconsistencies.
> *Edge cases* 
> Weight =1
> Score = 1( if we have a match at the beginning of the suggestion) or 0 ( for 
> any other match)
> Weight =0
> Score = 0 ( independently of the position match coefficient)



--
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-8459) Add SearcherTaxonomyManager constructor taking already opened readers

[ASF subversion and git services (JIRA)]

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

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

Commit 724c078c4e4b2f29e7ef466f59f6f086adf552e2 in lucene-solr's branch 
refs/heads/branch_7x from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=724c078 ]

LUCENE-8459: add SearcherTaxonomyManager constructor taking already opened 
readers


> Add SearcherTaxonomyManager constructor taking already opened readers
> -
>
> Key: LUCENE-8459
> URL: https://issues.apache.org/jira/browse/LUCENE-8459
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/facet
>Reporter: Michael McCandless
>Assignee: Michael McCandless
>Priority: Major
> Fix For: 7.5, master (8.0)
>
> Attachments: LUCENE-8459.patch
>
>
> Today it either takes {{IndexWriter}} or {{Directory}} (and it opens its own 
> {{DirectoryReader}}s) ... but I'd like to pass in my own reader so that e.g. 
> I can use a {{FilterDirectoryReader}}.  This is useful e.g. for tracking fun 
> low level stats like how many term dictionary lookups your queries are doing.
> My first attempt was to do my wrapping in {{SearcherFactory}}, but 
> {{SearcherManager}} gets angry when you do that ("SearcherFactory must wrap 
> exactly the provided reader").



--
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] [Resolved] (LUCENE-8459) Add SearcherTaxonomyManager constructor taking already opened readers

[Michael McCandless (JIRA)]

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

Michael McCandless resolved LUCENE-8459.

Resolution: Fixed

> Add SearcherTaxonomyManager constructor taking already opened readers
> -
>
> Key: LUCENE-8459
> URL: https://issues.apache.org/jira/browse/LUCENE-8459
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/facet
>Reporter: Michael McCandless
>Assignee: Michael McCandless
>Priority: Major
> Fix For: 7.5, master (8.0)
>
> Attachments: LUCENE-8459.patch
>
>
> Today it either takes {{IndexWriter}} or {{Directory}} (and it opens its own 
> {{DirectoryReader}}s) ... but I'd like to pass in my own reader so that e.g. 
> I can use a {{FilterDirectoryReader}}.  This is useful e.g. for tracking fun 
> low level stats like how many term dictionary lookups your queries are doing.
> My first attempt was to do my wrapping in {{SearcherFactory}}, but 
> {{SearcherManager}} gets angry when you do that ("SearcherFactory must wrap 
> exactly the provided reader").



--
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-8459) Add SearcherTaxonomyManager constructor taking already opened readers

[ASF subversion and git services (JIRA)]

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

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

Commit a9551404fd057c83abe3b47bbf9124d335790cbe in lucene-solr's branch 
refs/heads/master from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a955140 ]

LUCENE-8459: add SearcherTaxonomyManager constructor taking already opened 
readers


> Add SearcherTaxonomyManager constructor taking already opened readers
> -
>
> Key: LUCENE-8459
> URL: https://issues.apache.org/jira/browse/LUCENE-8459
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/facet
>Reporter: Michael McCandless
>Assignee: Michael McCandless
>Priority: Major
> Fix For: 7.5, master (8.0)
>
> Attachments: LUCENE-8459.patch
>
>
> Today it either takes {{IndexWriter}} or {{Directory}} (and it opens its own 
> {{DirectoryReader}}s) ... but I'd like to pass in my own reader so that e.g. 
> I can use a {{FilterDirectoryReader}}.  This is useful e.g. for tracking fun 
> low level stats like how many term dictionary lookups your queries are doing.
> My first attempt was to do my wrapping in {{SearcherFactory}}, but 
> {{SearcherManager}} gets angry when you do that ("SearcherFactory must wrap 
> exactly the provided reader").



--
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] [Resolved] (SOLR-12763) Ref Guide: Upgrade notes for 7.5

[Cassandra Targett (JIRA)]

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

Cassandra Targett resolved SOLR-12763.
--
   Resolution: Done
Fix Version/s: master (8.0)

> Ref Guide: Upgrade notes for 7.5
> 
>
> Key: SOLR-12763
> URL: https://issues.apache.org/jira/browse/SOLR-12763
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>Priority: Blocker
> Fix For: 7.5, master (8.0)
>
> Attachments: SOLR-12763.patch
>
>
> Put upgrade notes from CHANGES (and any other important-to-mention items) 
> into the Ref Guide for 7.5.



--
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-12763) Ref Guide: Upgrade notes for 7.5

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12763:


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

SOLR-12763: upgrade notes + some MergePolicy param fixes


> Ref Guide: Upgrade notes for 7.5
> 
>
> Key: SOLR-12763
> URL: https://issues.apache.org/jira/browse/SOLR-12763
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>Priority: Blocker
> Fix For: 7.5
>
> Attachments: SOLR-12763.patch
>
>
> Put upgrade notes from CHANGES (and any other important-to-mention items) 
> into the Ref Guide for 7.5.



--
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-12763) Ref Guide: Upgrade notes for 7.5

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12763:


Commit 951dcb1141eb1ce8dce782e6f26097d4b8575d09 in lucene-solr's branch 
refs/heads/branch_7_5 from [~ctargett]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=951dcb1 ]

SOLR-12763: upgrade notes + some MergePolicy param fixes


> Ref Guide: Upgrade notes for 7.5
> 
>
> Key: SOLR-12763
> URL: https://issues.apache.org/jira/browse/SOLR-12763
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>Priority: Blocker
> Fix For: 7.5
>
> Attachments: SOLR-12763.patch
>
>
> Put upgrade notes from CHANGES (and any other important-to-mention items) 
> into the Ref Guide for 7.5.



--
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-12763) Ref Guide: Upgrade notes for 7.5

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12763:


Commit 89bc082478ded31433352b426ad8806ab9238be0 in lucene-solr's branch 
refs/heads/master from [~ctargett]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=89bc082 ]

SOLR-12763: upgrade notes + some MergePolicy param fixes


> Ref Guide: Upgrade notes for 7.5
> 
>
> Key: SOLR-12763
> URL: https://issues.apache.org/jira/browse/SOLR-12763
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>Priority: Blocker
> Fix For: 7.5
>
> Attachments: SOLR-12763.patch
>
>
> Put upgrade notes from CHANGES (and any other important-to-mention items) 
> into the Ref Guide for 7.5.



--
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-11836) Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-11836:
--

Okay looks like the patch was provided by Amrit and not Alfonso. I'll fix the 
CHAGES entry

> Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API
> 
>
> Key: SOLR-11836
> URL: https://issues.apache.org/jira/browse/SOLR-11836
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Alfonso Muñoz-Pomer Fuentes
>Priority: Major
>  Labels: facet, streaming
> Attachments: SOLR-11836.patch
>
>
> Currently, to retrieve all buckets using the streaming expressions facet 
> function, the {{bucketSizeLimit}} parameter must have a high enough value so 
> that all results will be included. Compare this with the JSON facet API, 
> where you can use {{"limit": -1}} to achieve this. It would help if such a 
> possibility existed.
> [Issue 11236|https://issues.apache.org/jira/browse/SOLR-11236] is related.



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

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

[jira] [Updated] (SOLR-11836) Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-11836:
-
Affects Version/s: (was: 7.2)

> Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API
> 
>
> Key: SOLR-11836
> URL: https://issues.apache.org/jira/browse/SOLR-11836
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Alfonso Muñoz-Pomer Fuentes
>Priority: Major
>  Labels: facet, streaming
> Attachments: SOLR-11836.patch
>
>
> Currently, to retrieve all buckets using the streaming expressions facet 
> function, the {{bucketSizeLimit}} parameter must have a high enough value so 
> that all results will be included. Compare this with the JSON facet API, 
> where you can use {{"limit": -1}} to achieve this. It would help if such a 
> possibility existed.
> [Issue 11236|https://issues.apache.org/jira/browse/SOLR-11236] is related.



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

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

[jira] [Commented] (SOLR-11836) Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11836:


Commit 019239c77d6e502c76a293da0c2367c85b5d7843 in lucene-solr's branch 
refs/heads/branch_7x from [~varunthacker]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=019239c ]

SOLR-11836: FacetStream works with bucketSizeLimit of -1 which will fetch all 
the buckets

(cherry picked from commit d35d206)


> Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API
> 
>
> Key: SOLR-11836
> URL: https://issues.apache.org/jira/browse/SOLR-11836
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Affects Versions: 7.2
>Reporter: Alfonso Muñoz-Pomer Fuentes
>Priority: Major
>  Labels: facet, streaming
> Attachments: SOLR-11836.patch
>
>
> Currently, to retrieve all buckets using the streaming expressions facet 
> function, the {{bucketSizeLimit}} parameter must have a high enough value so 
> that all results will be included. Compare this with the JSON facet API, 
> where you can use {{"limit": -1}} to achieve this. It would help if such a 
> possibility existed.
> [Issue 11236|https://issues.apache.org/jira/browse/SOLR-11236] is related.



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

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

Lucene-6.5.0 God Class Design Smell Prioritization Survey

[Khalid AlKharabsheh]

 Dear Respondent,


This questionnaire is part of my Ph.D. thesis in the area of Design Smell
Prioritization. The purpose of the study is to define a priorities among
the classes having detected as God Class in order to decide which class to
be repaired first.
We analyzed the Lucene-6.5.0 project and the most important God Classes
(Large Class or The Blob) in terms of which of them should be scheduled
their reparation in first place. These classes are found in this
questionnaire. Completing this questionnaire should take about 5 minutes.

I would appreciate your kind attention and cooperation on sending your
questionnaire feedback as soon as possible. Notice that all information
related to the respondent or contained in this questionnaire will be
treated in strict confidence.

If you are not currently involved in this project, please forward this
message to project members you think are a better target for this
questionnaire. Even if you are currently involved in the project, we would
appreciated the participation of other project contributors, please resend
this questionnaire to them.

Thank you in advance.

Survey Link:
https://docs.google.com/forms/d/e/1FAIpQLSe0vZDqE6xAfoeF2BNTLOIA4EqR18MJGGZg3dr7wizL69Z_xQ/viewform?c=0=1


Yours sincerely,


-- 

Kha lid Alkharabsheh
LP2 [image: E-mail:] khalid.alkharabs...@usc.es 
[image: Phone:] +34 881816474
[image: Website:] citius.usc.es  · [image: Twitter:]
 citiususc 

[jira] [Commented] (SOLR-11836) Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11836:


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

SOLR-11836: FacetStream works with bucketSizeLimit of -1 which will fetch all 
the buckets


> Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API
> 
>
> Key: SOLR-11836
> URL: https://issues.apache.org/jira/browse/SOLR-11836
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Affects Versions: 7.2
>Reporter: Alfonso Muñoz-Pomer Fuentes
>Priority: Major
>  Labels: facet, streaming
> Attachments: SOLR-11836.patch
>
>
> Currently, to retrieve all buckets using the streaming expressions facet 
> function, the {{bucketSizeLimit}} parameter must have a high enough value so 
> that all results will be included. Compare this with the JSON facet API, 
> where you can use {{"limit": -1}} to achieve this. It would help if such a 
> possibility existed.
> [Issue 11236|https://issues.apache.org/jira/browse/SOLR-11236] is related.



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

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

[jira] [Updated] (SOLR-12761) Be able to configure “maxExpansions” for FuzzyQuery

[JIRA]

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

Manuel Gübeli updated SOLR-12761:
-
Priority: Minor  (was: Major)

> Be able to configure “maxExpansions” for FuzzyQuery
> ---
>
> Key: SOLR-12761
> URL: https://issues.apache.org/jira/browse/SOLR-12761
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 7.3
>Reporter: Manuel Gübeli
>Priority: Minor
>
> We had an issue where we reached the expansion limit of the FuzzyQuery.
> Situation:
>  * Query «meier~» found «Meier»
>  * Query «mazer~» found «Meier»
>  * Query «maxer~» found «Meier»
>  * Query «mayer~» did *NOT* find «Meier»
> The parameter “maxBooleanClauses” does not help in this situation since the 
> “maxExpansions” FuzzyQuery of is never set in Solr and therefore the default 
> value of 50 is used. Details: “SolrQuery-ParserBase” calles the default 
> constructor new FuzzyQuery(Term term, int maxEdits, int pre-fixLength) and 
> therefore FuzzyQuery run always with the default values defaultMaxExpansions 
> = 50 and defaultTranspositions = true)
> Suggestion expose FuzzyQuery parameters in solrconfig.xm like e.g. 
>  1024
>  
> Addtion would be:
>  0
>  50
>  true



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

[Policeman Jenkins Server]

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

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

Error Message:
Zipf distribution not descending!!!

Stack Trace:
java.lang.Exception: Zipf distribution not descending!!!
at 
__randomizedtesting.SeedInfo.seed([DEF51B88E0D9B0EA:FA4076ACF771B8C2]:0)
at 
org.apache.solr.client.solrj.io.stream.MathExpressionTest.testZipFDistribution(MathExpressionTest.java:2644)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
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:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 15835 lines...]
   [junit4] Suite: org.apache.solr.client.solrj.io.stream.MathExpressionTest
   [junit4]   2> Creating dataDir: 
/export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/solr/build/solr-solrj/test/J1/temp/solr.client.solrj.io.stream.MathExpressionTest_DEF51B88E0D9B0EA-001/init-core-data-001
   [junit4]   1> 

[jira] [Commented] (SOLR-11836) Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-11836:
--

Running tests and committing it to master and 7_x  and then checking with the 
RM to backport 

> Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API
> 
>
> Key: SOLR-11836
> URL: https://issues.apache.org/jira/browse/SOLR-11836
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Affects Versions: 7.2
>Reporter: Alfonso Muñoz-Pomer Fuentes
>Priority: Major
>  Labels: facet, streaming
> Attachments: SOLR-11836.patch
>
>
> Currently, to retrieve all buckets using the streaming expressions facet 
> function, the {{bucketSizeLimit}} parameter must have a high enough value so 
> that all results will be included. Compare this with the JSON facet API, 
> where you can use {{"limit": -1}} to achieve this. It would help if such a 
> possibility existed.
> [Issue 11236|https://issues.apache.org/jira/browse/SOLR-11236] is related.



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

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

[jira] [Commented] (SOLR-11836) Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-11836:
--

Patch applies cleanly on master. Looks good to me!

We should just commit this and it can be part of 7.5 . 

 

> Use -1 in bucketSizeLimit to get all facets, analogous to the JSON facet API
> 
>
> Key: SOLR-11836
> URL: https://issues.apache.org/jira/browse/SOLR-11836
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Affects Versions: 7.2
>Reporter: Alfonso Muñoz-Pomer Fuentes
>Priority: Major
>  Labels: facet, streaming
> Attachments: SOLR-11836.patch
>
>
> Currently, to retrieve all buckets using the streaming expressions facet 
> function, the {{bucketSizeLimit}} parameter must have a high enough value so 
> that all results will be included. Compare this with the JSON facet API, 
> where you can use {{"limit": -1}} to achieve this. It would help if such a 
> possibility existed.
> [Issue 11236|https://issues.apache.org/jira/browse/SOLR-11236] is related.



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

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

[jira] [Commented] (LUCENE-8343) BlendedInfixSuggester bad score calculus for certain suggestion weights

[ASF subversion and git services (JIRA)]

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

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

Commit 398074d0f878d4ba262245e35fa1ea285e52b791 in lucene-solr's branch 
refs/heads/master from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=398074d ]

LUCENE-8343: change suggesters to use Long instead of long weight during 
indexing, and double instead of long score at suggest time


> BlendedInfixSuggester bad score calculus for certain suggestion weights
> ---
>
> Key: LUCENE-8343
> URL: https://issues.apache.org/jira/browse/LUCENE-8343
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 7.3.1
>Reporter: Alessandro Benedetti
>Priority: Major
> Fix For: master (8.0)
>
> Attachments: LUCENE-8343.patch, LUCENE-8343.patch, LUCENE-8343.patch, 
> LUCENE-8343.patch, LUCENE-8343.patch, LUCENE-8343.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently the BlendedInfixSuggester return a (long) score to rank the 
> suggestions.
> This score is calculated as a multiplication between :
> long *Weight* : the suggestion weight, coming from a document field, it can 
> be any long value ( including 1, 0,.. )
> double *Coefficient* : 0<=x<=1, calculated based on the position match, 
> earlier the better
> The resulting score is a long, which means that at the moment, any weight<10 
> can bring inconsistencies.
> *Edge cases* 
> Weight =1
> Score = 1( if we have a match at the beginning of the suggestion) or 0 ( for 
> any other match)
> Weight =0
> Score = 0 ( independently of the position match coefficient)



--
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-8343) BlendedInfixSuggester bad score calculus for certain suggestion weights

[ASF subversion and git services (JIRA)]

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

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

Commit 2b636e8c3adb879f0cd2cff45824e226d747b5f0 in lucene-solr's branch 
refs/heads/master from [~alessandro.benedetti]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2b636e8 ]

[LUCENE-8343] minor documentation fixes


> BlendedInfixSuggester bad score calculus for certain suggestion weights
> ---
>
> Key: LUCENE-8343
> URL: https://issues.apache.org/jira/browse/LUCENE-8343
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 7.3.1
>Reporter: Alessandro Benedetti
>Priority: Major
> Fix For: master (8.0)
>
> Attachments: LUCENE-8343.patch, LUCENE-8343.patch, LUCENE-8343.patch, 
> LUCENE-8343.patch, LUCENE-8343.patch, LUCENE-8343.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently the BlendedInfixSuggester return a (long) score to rank the 
> suggestions.
> This score is calculated as a multiplication between :
> long *Weight* : the suggestion weight, coming from a document field, it can 
> be any long value ( including 1, 0,.. )
> double *Coefficient* : 0<=x<=1, calculated based on the position match, 
> earlier the better
> The resulting score is a long, which means that at the moment, any weight<10 
> can bring inconsistencies.
> *Edge cases* 
> Weight =1
> Score = 1( if we have a match at the beginning of the suggestion) or 0 ( for 
> any other match)
> Weight =0
> Score = 0 ( independently of the position match coefficient)



--
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-8343) BlendedInfixSuggester bad score calculus for certain suggestion weights

[ASF subversion and git services (JIRA)]

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

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

Commit e0232f104509f28126d9ce060663f87508366338 in lucene-solr's branch 
refs/heads/master from [~alessandro.benedetti]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e0232f1 ]

[LUCENE-8343] weight long overflow fix + test


> BlendedInfixSuggester bad score calculus for certain suggestion weights
> ---
>
> Key: LUCENE-8343
> URL: https://issues.apache.org/jira/browse/LUCENE-8343
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 7.3.1
>Reporter: Alessandro Benedetti
>Priority: Major
> Fix For: master (8.0)
>
> Attachments: LUCENE-8343.patch, LUCENE-8343.patch, LUCENE-8343.patch, 
> LUCENE-8343.patch, LUCENE-8343.patch, LUCENE-8343.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently the BlendedInfixSuggester return a (long) score to rank the 
> suggestions.
> This score is calculated as a multiplication between :
> long *Weight* : the suggestion weight, coming from a document field, it can 
> be any long value ( including 1, 0,.. )
> double *Coefficient* : 0<=x<=1, calculated based on the position match, 
> earlier the better
> The resulting score is a long, which means that at the moment, any weight<10 
> can bring inconsistencies.
> *Edge cases* 
> Weight =1
> Score = 1( if we have a match at the beginning of the suggestion) or 0 ( for 
> any other match)
> Weight =0
> Score = 0 ( independently of the position match coefficient)



--
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-8343) BlendedInfixSuggester bad score calculus for certain suggestion weights

[ASF subversion and git services (JIRA)]

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

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

Commit 1a83a146684f20f431ba646fecb7db311e1e0afa in lucene-solr's branch 
refs/heads/master from [~alessandro.benedetti]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1a83a14 ]

Merge remote-tracking branch 'upstream/master' into LUCENE-8343


> BlendedInfixSuggester bad score calculus for certain suggestion weights
> ---
>
> Key: LUCENE-8343
> URL: https://issues.apache.org/jira/browse/LUCENE-8343
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 7.3.1
>Reporter: Alessandro Benedetti
>Priority: Major
> Fix For: master (8.0)
>
> Attachments: LUCENE-8343.patch, LUCENE-8343.patch, LUCENE-8343.patch, 
> LUCENE-8343.patch, LUCENE-8343.patch, LUCENE-8343.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently the BlendedInfixSuggester return a (long) score to rank the 
> suggestions.
> This score is calculated as a multiplication between :
> long *Weight* : the suggestion weight, coming from a document field, it can 
> be any long value ( including 1, 0,.. )
> double *Coefficient* : 0<=x<=1, calculated based on the position match, 
> earlier the better
> The resulting score is a long, which means that at the moment, any weight<10 
> can bring inconsistencies.
> *Edge cases* 
> Weight =1
> Score = 1( if we have a match at the beginning of the suggestion) or 0 ( for 
> any other match)
> Weight =0
> Score = 0 ( independently of the position match coefficient)



--
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 #391: [LUCENE-8343] introduced weight 0 check and p...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/lucene-solr/pull/391


---

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

[jira] [Commented] (LUCENE-8343) BlendedInfixSuggester bad score calculus for certain suggestion weights

[ASF subversion and git services (JIRA)]

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

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

Commit 17cfa634798f96539c2535dca2e9a8f2cc0bff45 in lucene-solr's branch 
refs/heads/master from [~alessandro.benedetti]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=17cfa63 ]

[LUCENE-8343] documentation fix


> BlendedInfixSuggester bad score calculus for certain suggestion weights
> ---
>
> Key: LUCENE-8343
> URL: https://issues.apache.org/jira/browse/LUCENE-8343
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 7.3.1
>Reporter: Alessandro Benedetti
>Priority: Major
> Fix For: master (8.0)
>
> Attachments: LUCENE-8343.patch, LUCENE-8343.patch, LUCENE-8343.patch, 
> LUCENE-8343.patch, LUCENE-8343.patch, LUCENE-8343.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently the BlendedInfixSuggester return a (long) score to rank the 
> suggestions.
> This score is calculated as a multiplication between :
> long *Weight* : the suggestion weight, coming from a document field, it can 
> be any long value ( including 1, 0,.. )
> double *Coefficient* : 0<=x<=1, calculated based on the position match, 
> earlier the better
> The resulting score is a long, which means that at the moment, any weight<10 
> can bring inconsistencies.
> *Edge cases* 
> Weight =1
> Score = 1( if we have a match at the beginning of the suggestion) or 0 ( for 
> any other match)
> Weight =0
> Score = 0 ( independently of the position match coefficient)



--
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-8343) BlendedInfixSuggester bad score calculus for certain suggestion weights

[ASF subversion and git services (JIRA)]

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

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

Commit cef9a2283e30a297b3add8e73ee6dba9492dcc57 in lucene-solr's branch 
refs/heads/master from [~alessandro.benedetti]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=cef9a22 ]

Merge remote-tracking branch 'upstream/master' into LUCENE-8343


> BlendedInfixSuggester bad score calculus for certain suggestion weights
> ---
>
> Key: LUCENE-8343
> URL: https://issues.apache.org/jira/browse/LUCENE-8343
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 7.3.1
>Reporter: Alessandro Benedetti
>Priority: Major
> Fix For: master (8.0)
>
> Attachments: LUCENE-8343.patch, LUCENE-8343.patch, LUCENE-8343.patch, 
> LUCENE-8343.patch, LUCENE-8343.patch, LUCENE-8343.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently the BlendedInfixSuggester return a (long) score to rank the 
> suggestions.
> This score is calculated as a multiplication between :
> long *Weight* : the suggestion weight, coming from a document field, it can 
> be any long value ( including 1, 0,.. )
> double *Coefficient* : 0<=x<=1, calculated based on the position match, 
> earlier the better
> The resulting score is a long, which means that at the moment, any weight<10 
> can bring inconsistencies.
> *Edge cases* 
> Weight =1
> Score = 1( if we have a match at the beginning of the suggestion) or 0 ( for 
> any other match)
> Weight =0
> Score = 0 ( independently of the position match coefficient)



--
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-8343) BlendedInfixSuggester bad score calculus for certain suggestion weights

[ASF subversion and git services (JIRA)]

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

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

Commit e83e8ee1a42388606fffd10330ed1aeec9518098 in lucene-solr's branch 
refs/heads/master from [~alessandro.benedetti]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e83e8ee ]

[LUCENE-8343] introduced weight 0 check and positional coefficient scaling + 
tests


> BlendedInfixSuggester bad score calculus for certain suggestion weights
> ---
>
> Key: LUCENE-8343
> URL: https://issues.apache.org/jira/browse/LUCENE-8343
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 7.3.1
>Reporter: Alessandro Benedetti
>Priority: Major
> Attachments: LUCENE-8343.patch, LUCENE-8343.patch, LUCENE-8343.patch, 
> LUCENE-8343.patch, LUCENE-8343.patch, LUCENE-8343.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently the BlendedInfixSuggester return a (long) score to rank the 
> suggestions.
> This score is calculated as a multiplication between :
> long *Weight* : the suggestion weight, coming from a document field, it can 
> be any long value ( including 1, 0,.. )
> double *Coefficient* : 0<=x<=1, calculated based on the position match, 
> earlier the better
> The resulting score is a long, which means that at the moment, any weight<10 
> can bring inconsistencies.
> *Edge cases* 
> Weight =1
> Score = 1( if we have a match at the beginning of the suggestion) or 0 ( for 
> any other match)
> Weight =0
> Score = 0 ( independently of the position match coefficient)



--
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-8462) New Arabic snowball stemmer

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-8462:
-

+1 for the BSD-licensed test data, thank you.

> New Arabic snowball stemmer
> ---
>
> Key: LUCENE-8462
> URL: https://issues.apache.org/jira/browse/LUCENE-8462
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Ryadh Dahimene
>Priority: Trivial
>  Labels: Arabic, snowball, stemmer
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Added a new Arabic snowball stemmer based on 
> [https://github.com/snowballstem/snowball/blob/master/algorithms/arabic.sbl]
> As well an Arabic test dataset in `TestSnowballVocabData.zip` from the 
> -snowball-data- generated from the input file available here 
> -[https://github.com/snowballstem/snowball-data/tree/master/arabic]-
> [https://github.com/ibnmalik/golden-corpus-arabic/blob/develop/core/words.txt]
>  
> Link to the corresponding Github PR:
>  [https://github.com/apache/lucene-solr/pull/439]
>  Edited: updated the corpus link
>  



--
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-12639) Umbrella JIRA for adding support HTTP/2, jira/http2

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-12639:
-

I was doing some research on HTTP/2 and found that Kerberos/NTLM is not 
supported with HTTP/2? It looks like most servers will fall back to HTTP 1.1 if 
Kerberos authentication is required. I don't know if there is any way to work 
around this. Searching for "http/2 kerberos" in Google isn't promising.

> Umbrella JIRA for adding support HTTP/2, jira/http2
> ---
>
> Key: SOLR-12639
> URL: https://issues.apache.org/jira/browse/SOLR-12639
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: http2
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
>
> This ticket will aim to replace/add support of http2 by using jetty HTTP 
> client to Solr. All the works will be committed to jira/http2 branch. This 
> branch will be served like a stepping stone between the master branch and 
> Mark Miller starburst branch. I will try to keep jira/http2 as close as 
> master as possible (this will make merging in the future easier). In the same 
> time, changes in starburst branch will be split into smaller/testable parts 
> then push it to jira/http2 branch. 
> Anyone who interests at http2 for Solr can use jira/http2 branch but there is 
> no backward-compatibility guarantee.



--
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-12644) Supporting AuthenticationPlugin for Http2SolrClient

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-12644:
-

I was doing some research on HTTP/2 and found that Kerberos/NTLM is not 
supported with HTTP/2? It looks like most servers will fall back to HTTP 1.1 if 
Kerberos authentication is required. I don't know if there is any way to work 
around this. Searching for "http/2 kerberos" in Google isn't promising.

> Supporting AuthenticationPlugin for Http2SolrClient
> ---
>
> Key: SOLR-12644
> URL: https://issues.apache.org/jira/browse/SOLR-12644
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Attachments: SOLR-12644.patch
>
>
> All the tests of AuthenticationPlugin classes are marked as ignored. This 
> ticket aims to remove them.



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

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

Re: Lucene/Solr 7.5

[jim ferenczi]

Thanks Steve!

Le mar. 11 sept. 2018 à 18:02, Steve Rowe  a écrit :

> Hi Jim,
>
> > On Sep 11, 2018, at 11:32 AM, jim ferenczi 
> wrote:
> >
> > Could someone help to setup the Jenkins releases build ? It seems that I
> cannot create jobs with my account.
>
>
> Each project's PMC Chair is responsible for granting job
> creation/modification permissions on Jenkins:
> https://cwiki.apache.org/confluence/display/INFRA/Jenkins#Jenkins-HowdoIgetanaccount
>
> I’ll go create the 7.5 jobs now.
>
> --
> Steve
> www.lucidworks.com
>
> > On Sep 11, 2018, at 11:32 AM, jim ferenczi 
> wrote:
> >
> > No worries at all Cassandra. What do you think of building the first RC
> on Friday and start the vote on Monday next week ? This will leave some
> > room to finish the missing bits.
> > Could someone help to setup the Jenkins releases build ? It seems that I
> cannot create jobs with my account.
> >
> > Le mar. 11 sept. 2018 à 14:08, Cassandra Targett 
> a écrit :
> > Sorry, Jim, I should have replied yesterday about the state of things
> with the Ref Guide - it's close. I'm doing the last bit of big review I
> need to do and am nearly done with that, then I have a couple more small
> things done (including SOLR-12763 which I just created since I forgot to do
> it earlier). My goal is to be done by the end of my day today so you could
> do the RC tomorrow, but who knows what the day will bring work-wise, so
> I'll send another mail at the end of the day my time to let you know for
> sure.
> >
> > On Mon, Sep 10, 2018 at 9:07 AM jim ferenczi 
> wrote:
> > I just fixed the invalid version (7.5.1) that I added in master and 7x.
> The next version on these branches should be 7.6.0, sorry for the noise.
> >
> > Le lun. 10 sept. 2018 à 09:26, jim ferenczi  a
> écrit :
> > Hi,
> >
> > Feature freeze for 7.5 has started, I just created a branch_7_5.:
> >
> > * No new features may be committed to the branch.
> > * Documentation patches, build patches and serious bug fixes may be
> committed to the branch. However, you should submit all patches you want to
> commit to Jira first to give others the chance to review and possibly vote
> against the patch. Keep in mind that it is our main intention to keep the
> branch as stable as possible.
> > * All patches that are intended for the branch should first be committed
> to the unstable branch, merged into the stable branch, and then into the
> current release branch.
> > * Normal unstable and stable branch development may continue as usual.
> However, if you plan to commit a big change to the unstable branch while
> the branch feature freeze is in effect, think twice: can't the addition
> wait a couple more days? Merges of bug fixes into the branch may become
> more difficult.
> > * Only Jira issues with Fix version "7.5" and priority "Blocker" will
> delay a release candidate build.
> >
> > I'll create the first RC later this week depending on the status of the
> Solr ref guide. Cassandra, can you update the status when you think that
> the ref guide is ready (no rush just a reminder that we need to sync during
> this release ;) ) ?
> >
> > Cheers,
> > Jim
> >
> > Le mer. 5 sept. 2018 à 17:57, Erick Erickson 
> a écrit :
> > Great, thanks!
> > On Wed, Sep 5, 2018 at 8:44 AM jim ferenczi 
> wrote:
> > >
> > > Sure it can wait a few days. Let's cut the branch next Monday and we
> can sync with Cassandra to create the first RC when the ref guide is ready.
> > >
> > > Le mer. 5 sept. 2018 à 17:27, Erick Erickson 
> a écrit :
> > >>
> > >> Jim:
> > >>
> > >> I know it's the 11th hour, but WDYT about cutting the branch next
> > >> Monday? We see a flurry of activity (announcing a release does
> > >> that) and waiting to cut the branch might be easiest all 'round.
> > >>
> > >> Up to you of course, I can backport the test fixes I'd like for
> > >> instance and I'd like to get the upgraded ZooKeeper in 7.5.
> > >>
> > >> Erick
> > >> On Tue, Sep 4, 2018 at 1:04 PM Cassandra Targett <
> casstarg...@gmail.com> wrote:
> > >> >
> > >> > It's not so much the building of the RC as giving the content a
> detailed editorial review.
> > >> >
> > >> > The build/release process itself is well-documented and published
> with every Ref Guide:
> https://lucene.apache.org/solr/guide/how-to-contribute.html#building-publishing-the-guide.
> It was designed from the artifact process, so it's nearly identical as a
> process. It's really barely a burden.
> > >> >
> > >> > In terms of preparing the content, there are a number of things I
> do:
> > >> >
> > >> > First, I try to ensure that every issue in CHANGES.txt that should
> be documented has been documented. That involves an intensive review of
> CHANGES.txt and a comparison with commits to find what might be missing,
> then chasing people down to see if they intend to make changes or not.
> Assuming the person responds, then it's waiting for them to get their stuff
> done. This is usually about 2-3 days of effort, before the waiting around
> for answers 

[jira] [Commented] (LUCENE-8462) New Arabic snowball stemmer

[Ryadh Dahimene (JIRA)]

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

Ryadh Dahimene commented on LUCENE-8462:


Hi [~rcmuir], what do you think of the new dataset for the test vocabulary? 
Should I look for other alternatives?

[~thetaphi], following your comment I've started looking at the ant task `{{ant 
patch-snowball`}}  and yes it needs to be updated for the new snowball 
generated java classes. I will try to work on that and submit a change on a 
separate issue.

> New Arabic snowball stemmer
> ---
>
> Key: LUCENE-8462
> URL: https://issues.apache.org/jira/browse/LUCENE-8462
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Ryadh Dahimene
>Priority: Trivial
>  Labels: Arabic, snowball, stemmer
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Added a new Arabic snowball stemmer based on 
> [https://github.com/snowballstem/snowball/blob/master/algorithms/arabic.sbl]
> As well an Arabic test dataset in `TestSnowballVocabData.zip` from the 
> -snowball-data- generated from the input file available here 
> -[https://github.com/snowballstem/snowball-data/tree/master/arabic]-
> [https://github.com/ibnmalik/golden-corpus-arabic/blob/develop/core/words.txt]
>  
> Link to the corresponding Github PR:
>  [https://github.com/apache/lucene-solr/pull/439]
>  Edited: updated the corpus link
>  



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

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

Re: Lucene/Solr 7.5

[Steve Rowe]

Hi Jim,

> On Sep 11, 2018, at 11:32 AM, jim ferenczi  wrote:
> 
> Could someone help to setup the Jenkins releases build ? It seems that I 
> cannot create jobs with my account.


Each project's PMC Chair is responsible for granting job creation/modification 
permissions on Jenkins: 
https://cwiki.apache.org/confluence/display/INFRA/Jenkins#Jenkins-HowdoIgetanaccount

I’ll go create the 7.5 jobs now.

-- 
Steve
www.lucidworks.com

> On Sep 11, 2018, at 11:32 AM, jim ferenczi  wrote:
> 
> No worries at all Cassandra. What do you think of building the first RC on 
> Friday and start the vote on Monday next week ? This will leave some
> room to finish the missing bits. 
> Could someone help to setup the Jenkins releases build ? It seems that I 
> cannot create jobs with my account.
> 
> Le mar. 11 sept. 2018 à 14:08, Cassandra Targett  a 
> écrit :
> Sorry, Jim, I should have replied yesterday about the state of things with 
> the Ref Guide - it's close. I'm doing the last bit of big review I need to do 
> and am nearly done with that, then I have a couple more small things done 
> (including SOLR-12763 which I just created since I forgot to do it earlier). 
> My goal is to be done by the end of my day today so you could do the RC 
> tomorrow, but who knows what the day will bring work-wise, so I'll send 
> another mail at the end of the day my time to let you know for sure.
> 
> On Mon, Sep 10, 2018 at 9:07 AM jim ferenczi  wrote:
> I just fixed the invalid version (7.5.1) that I added in master and 7x. The 
> next version on these branches should be 7.6.0, sorry for the noise.
> 
> Le lun. 10 sept. 2018 à 09:26, jim ferenczi  a écrit :
> Hi,
> 
> Feature freeze for 7.5 has started, I just created a branch_7_5.:
> 
> * No new features may be committed to the branch.
> * Documentation patches, build patches and serious bug fixes may be committed 
> to the branch. However, you should submit all patches you want to commit to 
> Jira first to give others the chance to review and possibly vote against the 
> patch. Keep in mind that it is our main intention to keep the branch as 
> stable as possible.
> * All patches that are intended for the branch should first be committed to 
> the unstable branch, merged into the stable branch, and then into the current 
> release branch.
> * Normal unstable and stable branch development may continue as usual. 
> However, if you plan to commit a big change to the unstable branch while the 
> branch feature freeze is in effect, think twice: can't the addition wait a 
> couple more days? Merges of bug fixes into the branch may become more 
> difficult.
> * Only Jira issues with Fix version "7.5" and priority "Blocker" will delay a 
> release candidate build.
> 
> I'll create the first RC later this week depending on the status of the Solr 
> ref guide. Cassandra, can you update the status when you think that the ref 
> guide is ready (no rush just a reminder that we need to sync during this 
> release ;) ) ?
> 
> Cheers,
> Jim
> 
> Le mer. 5 sept. 2018 à 17:57, Erick Erickson  a 
> écrit :
> Great, thanks!
> On Wed, Sep 5, 2018 at 8:44 AM jim ferenczi  wrote:
> >
> > Sure it can wait a few days. Let's cut the branch next Monday and we can 
> > sync with Cassandra to create the first RC when the ref guide is ready.
> >
> > Le mer. 5 sept. 2018 à 17:27, Erick Erickson  a 
> > écrit :
> >>
> >> Jim:
> >>
> >> I know it's the 11th hour, but WDYT about cutting the branch next
> >> Monday? We see a flurry of activity (announcing a release does
> >> that) and waiting to cut the branch might be easiest all 'round.
> >>
> >> Up to you of course, I can backport the test fixes I'd like for
> >> instance and I'd like to get the upgraded ZooKeeper in 7.5.
> >>
> >> Erick
> >> On Tue, Sep 4, 2018 at 1:04 PM Cassandra Targett  
> >> wrote:
> >> >
> >> > It's not so much the building of the RC as giving the content a detailed 
> >> > editorial review.
> >> >
> >> > The build/release process itself is well-documented and published with 
> >> > every Ref Guide: 
> >> > https://lucene.apache.org/solr/guide/how-to-contribute.html#building-publishing-the-guide.
> >> >  It was designed from the artifact process, so it's nearly identical as 
> >> > a process. It's really barely a burden.
> >> >
> >> > In terms of preparing the content, there are a number of things I do:
> >> >
> >> > First, I try to ensure that every issue in CHANGES.txt that should be 
> >> > documented has been documented. That involves an intensive review of 
> >> > CHANGES.txt and a comparison with commits to find what might be missing, 
> >> > then chasing people down to see if they intend to make changes or not. 
> >> > Assuming the person responds, then it's waiting for them to get their 
> >> > stuff done. This is usually about 2-3 days of effort, before the waiting 
> >> > around for answers and/or commits.
> >> >
> >> > Then I review every commit and read it for clarity and correct English 
> >> > usage. Does it fit 

[jira] [Commented] (SOLR-12763) Ref Guide: Upgrade notes for 7.5

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-12763:
--

Patch for adding the upgrade notes for 7.5. It includes some changes to other 
pages for adding or clarifying params for mergePolicy and also field 
requirements for uniqueId.

Trying something new with the upgrade notes, which is to add a bold "heading" 
to break up the traditional bullet list like what's in CHANGES.txt. Hopefully 
that will help people more easily see things that might impact them either 
before they upgrade or after they've upgraded and are wondering why something 
changed.

I'll let this patch sit an hour or so and then push to the branches.

> Ref Guide: Upgrade notes for 7.5
> 
>
> Key: SOLR-12763
> URL: https://issues.apache.org/jira/browse/SOLR-12763
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>Priority: Blocker
> Fix For: 7.5
>
> Attachments: SOLR-12763.patch
>
>
> Put upgrade notes from CHANGES (and any other important-to-mention items) 
> into the Ref Guide for 7.5.



--
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-12763) Ref Guide: Upgrade notes for 7.5

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-12763:
-
Attachment: SOLR-12763.patch

> Ref Guide: Upgrade notes for 7.5
> 
>
> Key: SOLR-12763
> URL: https://issues.apache.org/jira/browse/SOLR-12763
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>Priority: Blocker
> Fix For: 7.5
>
> Attachments: SOLR-12763.patch
>
>
> Put upgrade notes from CHANGES (and any other important-to-mention items) 
> into the Ref Guide for 7.5.



--
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-8343) BlendedInfixSuggester bad score calculus for certain suggestion weights

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-8343:


Thanks [~alessandro.benedetti]; I'll have a look!

> BlendedInfixSuggester bad score calculus for certain suggestion weights
> ---
>
> Key: LUCENE-8343
> URL: https://issues.apache.org/jira/browse/LUCENE-8343
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 7.3.1
>Reporter: Alessandro Benedetti
>Priority: Major
> Attachments: LUCENE-8343.patch, LUCENE-8343.patch, LUCENE-8343.patch, 
> LUCENE-8343.patch, LUCENE-8343.patch, LUCENE-8343.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently the BlendedInfixSuggester return a (long) score to rank the 
> suggestions.
> This score is calculated as a multiplication between :
> long *Weight* : the suggestion weight, coming from a document field, it can 
> be any long value ( including 1, 0,.. )
> double *Coefficient* : 0<=x<=1, calculated based on the position match, 
> earlier the better
> The resulting score is a long, which means that at the moment, any weight<10 
> can bring inconsistencies.
> *Edge cases* 
> Weight =1
> Score = 1( if we have a match at the beginning of the suggestion) or 0 ( for 
> any other match)
> Weight =0
> Score = 0 ( independently of the position match coefficient)



--
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-12764) refer main query params for [subquery]

[Mikhail Khludnev (JIRA)]

Mikhail Khludnev created SOLR-12764:
---

 Summary: refer main query params for [subquery]
 Key: SOLR-12764
 URL: https://issues.apache.org/jira/browse/SOLR-12764
 Project: Solr
  Issue Type: Sub-task
  Components: Response Writers
Reporter: Mikhail Khludnev


There might be a parameter prefix to refer to main query params, however, it's 
not clear how to handle parameters of multiple levels of subqueries.



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

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

Re: Lucene/Solr 7.5

[jim ferenczi]

No worries at all Cassandra. What do you think of building the first RC on
Friday and start the vote on Monday next week ? This will leave some
room to finish the missing bits.
Could someone help to setup the Jenkins releases build ? It seems that I
cannot create jobs with my account.

Le mar. 11 sept. 2018 à 14:08, Cassandra Targett  a
écrit :

> Sorry, Jim, I should have replied yesterday about the state of things with
> the Ref Guide - it's close. I'm doing the last bit of big review I need to
> do and am nearly done with that, then I have a couple more small things
> done (including SOLR-12763 which I just created since I forgot to do it
> earlier). My goal is to be done by the end of my day today so you could do
> the RC tomorrow, but who knows what the day will bring work-wise, so I'll
> send another mail at the end of the day my time to let you know for sure.
>
> On Mon, Sep 10, 2018 at 9:07 AM jim ferenczi 
> wrote:
>
>> I just fixed the invalid version (7.5.1) that I added in master and 7x.
>> The next version on these branches should be 7.6.0, sorry for the noise.
>>
>> Le lun. 10 sept. 2018 à 09:26, jim ferenczi  a
>> écrit :
>>
>>> Hi,
>>>
>>> Feature freeze for 7.5 has started, I just created a branch_7_5.:
>>>
>>> * No new features may be committed to the branch.
>>> * Documentation patches, build patches and serious bug fixes may be
>>> committed to the branch. However, you should submit all patches you want to
>>> commit to Jira first to give others the chance to review and possibly vote
>>> against the patch. Keep in mind that it is our main intention to keep the
>>> branch as stable as possible.
>>> * All patches that are intended for the branch should first be committed
>>> to the unstable branch, merged into the stable branch, and then into the
>>> current release branch.
>>> * Normal unstable and stable branch development may continue as usual.
>>> However, if you plan to commit a big change to the unstable branch while
>>> the branch feature freeze is in effect, think twice: can't the addition
>>> wait a couple more days? Merges of bug fixes into the branch may become
>>> more difficult.
>>> * Only Jira issues with Fix version "7.5" and priority "Blocker" will
>>> delay a release candidate build.
>>>
>>> I'll create the first RC later this week depending on the status of the
>>> Solr ref guide. Cassandra, can you update the status when you think that
>>> the ref guide is ready (no rush just a reminder that we need to sync during
>>> this release ;) ) ?
>>>
>>> Cheers,
>>> Jim
>>>
>>> Le mer. 5 sept. 2018 à 17:57, Erick Erickson 
>>> a écrit :
>>>
 Great, thanks!
 On Wed, Sep 5, 2018 at 8:44 AM jim ferenczi 
 wrote:
 >
 > Sure it can wait a few days. Let's cut the branch next Monday and we
 can sync with Cassandra to create the first RC when the ref guide is ready.
 >
 > Le mer. 5 sept. 2018 à 17:27, Erick Erickson 
 a écrit :
 >>
 >> Jim:
 >>
 >> I know it's the 11th hour, but WDYT about cutting the branch next
 >> Monday? We see a flurry of activity (announcing a release does
 >> that) and waiting to cut the branch might be easiest all 'round.
 >>
 >> Up to you of course, I can backport the test fixes I'd like for
 >> instance and I'd like to get the upgraded ZooKeeper in 7.5.
 >>
 >> Erick
 >> On Tue, Sep 4, 2018 at 1:04 PM Cassandra Targett <
 casstarg...@gmail.com> wrote:
 >> >
 >> > It's not so much the building of the RC as giving the content a
 detailed editorial review.
 >> >
 >> > The build/release process itself is well-documented and published
 with every Ref Guide:
 https://lucene.apache.org/solr/guide/how-to-contribute.html#building-publishing-the-guide.
 It was designed from the artifact process, so it's nearly identical as a
 process. It's really barely a burden.
 >> >
 >> > In terms of preparing the content, there are a number of things I
 do:
 >> >
 >> > First, I try to ensure that every issue in CHANGES.txt that should
 be documented has been documented. That involves an intensive review of
 CHANGES.txt and a comparison with commits to find what might be missing,
 then chasing people down to see if they intend to make changes or not.
 Assuming the person responds, then it's waiting for them to get their stuff
 done. This is usually about 2-3 days of effort, before the waiting around
 for answers and/or commits.
 >> >
 >> > Then I review every commit and read it for clarity and correct
 English usage. Does it fit where someone put it? Does it explain what the
 author is hoping it explains? Also, many of our authors are not native
 English writers, and deserve the assistance of an editor to help put their
 work in the best possible light. In some cases, I feel I should extensively
 edit the contribution, which occasionally involves also immersing myself
 into the 

Speakers needed for Apache DC Roadshow

[Rich Bowen]

We need your help to make the Apache Washington DC Roadshow on Dec 4th a 
success.


What do we need most? Speakers!

We're bringing a unique DC flavor to this event by mixing Open Source 
Software with talks about Apache projects as well as OSS CyberSecurity, 
OSS in Government and and OSS Career advice.


Please take a look at: http://www.apachecon.com/usroadshow18/

(Note: You are receiving this message because you are subscribed to one 
or more mailing lists at The Apache Software Foundation.)


Rich, for the ApacheCon Planners

--
rbo...@apache.org
http://apachecon.com
@ApacheCon

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

[jira] [Resolved] (SOLR-4396) Make JSONWriter a public class

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-4396.
--
   Resolution: Fixed
Fix Version/s: master (8.0)
   7.5

So I'll resolve this. I'm a little unclear when this was actually done, so 
marking it as 7.5.

 

Munendra: If you think this shouldn't be closed, let me know.

> Make JSONWriter a public class
> --
>
> Key: SOLR-4396
> URL: https://issues.apache.org/jira/browse/SOLR-4396
> Project: Solr
>  Issue Type: Wish
>  Components: Response Writers
>Reporter: Stephen Tallamy
>Priority: Minor
> Fix For: 7.5, master (8.0)
>
>
> By making org.apache.solr.response.JSONWriter a public class it will allow 
> people to use this as a basis for their own custom writers that use a JSON 
> format. Would it be possible to move it out to allow for sub-classing?



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

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

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

[Policeman Jenkins Server]

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

10 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.extraction.ExtractingRequestHandlerTest

Error Message:
SOLR-12759 JDK 11 (1st release) and Tika 1.x can result in extracting dates in 
a bad format.

Stack Trace:
java.lang.AssertionError: SOLR-12759 JDK 11 (1st release) and Tika 1.x can 
result in extracting dates in a bad format.
at __randomizedtesting.SeedInfo.seed([870BE87CB9E238AE]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertFalse(Assert.java:68)
at 
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.beforeClass(ExtractingRequestHandlerTest.java:44)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
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.handler.extraction.ExtractingRequestHandlerTest

Error Message:
SOLR-12759 JDK 11 (1st release) and Tika 1.x can result in extracting dates in 
a bad format.

Stack Trace:
java.lang.AssertionError: SOLR-12759 JDK 11 (1st release) and Tika 1.x can 
result in extracting dates in a bad format.
at __randomizedtesting.SeedInfo.seed([870BE87CB9E238AE]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertFalse(Assert.java:68)
at 
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.beforeClass(ExtractingRequestHandlerTest.java:44)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 

[jira] [Commented] (SOLR-12701) Math expressions documentation for the 7.5 release

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12701:


Commit 47f7883393b1037e72b62112621d89fbd6991174 in lucene-solr's branch 
refs/heads/branch_7_5 from [~ctargett]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=47f7883 ]

SOLR-12701: format/style consistency fixes for math expression docs; CSS change 
to make bold monospace appear properly


> Math expressions documentation for the 7.5 release
> --
>
> Key: SOLR-12701
> URL: https://issues.apache.org/jira/browse/SOLR-12701
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Joel Bernstein
>Priority: Major
> Fix For: 7.5
>
>
> This ticket will be used to add new math expression documentation for the 7.5 
> release which is the initial release for the math expression docs. 



--
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-12701) Math expressions documentation for the 7.5 release

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12701:


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

SOLR-12701: format/style consistency fixes for math expression docs; CSS change 
to make bold monospace appear properly


> Math expressions documentation for the 7.5 release
> --
>
> Key: SOLR-12701
> URL: https://issues.apache.org/jira/browse/SOLR-12701
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Joel Bernstein
>Priority: Major
> Fix For: 7.5
>
>
> This ticket will be used to add new math expression documentation for the 7.5 
> release which is the initial release for the math expression docs. 



--
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-12701) Math expressions documentation for the 7.5 release

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12701:


Commit 7fdbf0c016e75422ebc18147cadea4ca75ab0a1a in lucene-solr's branch 
refs/heads/branch_7x from [~ctargett]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7fdbf0c ]

SOLR-12701: format/style consistency fixes for math expression docs; CSS change 
to make bold monospace appear properly


> Math expressions documentation for the 7.5 release
> --
>
> Key: SOLR-12701
> URL: https://issues.apache.org/jira/browse/SOLR-12701
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Joel Bernstein
>Priority: Major
> Fix For: 7.5
>
>
> This ticket will be used to add new math expression documentation for the 7.5 
> release which is the initial release for the math expression docs. 



--
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-MAVEN] Lucene-Solr-Maven-7.x #301: POMs out of sync

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Maven-7.x/301/

No tests ran.

Build Log:
[...truncated 18842 lines...]
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-7.x/build.xml:672: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-7.x/build.xml:209: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-7.x/lucene/build.xml:424: 
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-7.x/lucene/common-build.xml:2261:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-7.x/lucene/common-build.xml:1719:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-7.x/lucene/common-build.xml:650:
 Error deploying artifact 'org.apache.lucene:lucene-classification:jar': Error 
installing artifact's metadata: Error while deploying metadata: Error 
transferring file

Total time: 7 minutes 5 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[JENKINS] Lucene-Solr-Tests-master - Build # 2803 - Unstable

[Apache Jenkins Server]

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

2 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.sim.TestSimTriggerIntegration.testEventFromRestoredState

Error Message:
The trigger did not fire at all

Stack Trace:
java.lang.AssertionError: The trigger did not fire at all
at 
__randomizedtesting.SeedInfo.seed([D02FFFAB803928F3:D0194B6BA9348C99]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.sim.TestSimTriggerIntegration.testEventFromRestoredState(TestSimTriggerIntegration.java:713)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
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:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
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:  
org.apache.solr.cloud.autoscaling.sim.TestSimTriggerIntegration.testSearchRate

Error Message:
The trigger did not start in time

Stack Trace:
java.lang.AssertionError: The trigger did not start in time
at 

[jira] [Commented] (SOLR-12762) SolrCloudTestCase.clusterShape should check for active slices instead of all slices

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-12762:
--

Several tests already use {{CloudTestUtils.clusterShape(...)}}, which provides 
more options, among others checking only active shards and checking for shard 
leaders - we should probably consolidate this code in one place.

> SolrCloudTestCase.clusterShape should check for active slices instead of all 
> slices
> ---
>
> Key: SOLR-12762
> URL: https://issues.apache.org/jira/browse/SOLR-12762
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Trivial
> Fix For: 7.6, master (8.0)
>
> Attachments: SOLR-12762.01.patch, SOLR-12762.patch
>
>
> SolrCloudTestCase.clusterShare should assert against the active slices, based 
> on the javadoc and usage but it instead checks for all slices.



--
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-4396) Make JSONWriter a public class

[Munendra S N (JIRA)]

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

Munendra S N commented on SOLR-4396:


JSONWriter is made public as part of SOLR-12455

> Make JSONWriter a public class
> --
>
> Key: SOLR-4396
> URL: https://issues.apache.org/jira/browse/SOLR-4396
> Project: Solr
>  Issue Type: Wish
>  Components: Response Writers
>Reporter: Stephen Tallamy
>Priority: Minor
>
> By making org.apache.solr.response.JSONWriter a public class it will allow 
> people to use this as a basis for their own custom writers that use a JSON 
> format. Would it be possible to move it out to allow for sub-classing?



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

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

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-11-ea+28) - Build # 22840 - Unstable!

[Policeman Jenkins Server]

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

37 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.extraction.ExtractingRequestHandlerTest

Error Message:
SOLR-12759 JDK 11 (1st release) and Tika 1.x can result in extracting dates in 
a bad format.

Stack Trace:
java.lang.AssertionError: SOLR-12759 JDK 11 (1st release) and Tika 1.x can 
result in extracting dates in a bad format.
at __randomizedtesting.SeedInfo.seed([181749F5178B1B55]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertFalse(Assert.java:68)
at 
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.beforeClass(ExtractingRequestHandlerTest.java:44)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
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.handler.extraction.ExtractingRequestHandlerTest

Error Message:
SOLR-12759 JDK 11 (1st release) and Tika 1.x can result in extracting dates in 
a bad format.

Stack Trace:
java.lang.AssertionError: SOLR-12759 JDK 11 (1st release) and Tika 1.x can 
result in extracting dates in a bad format.
at __randomizedtesting.SeedInfo.seed([181749F5178B1B55]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertFalse(Assert.java:68)
at 
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.beforeClass(ExtractingRequestHandlerTest.java:44)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 

Re: Lucene/Solr 7.5

[Cassandra Targett]

Sorry, Jim, I should have replied yesterday about the state of things with
the Ref Guide - it's close. I'm doing the last bit of big review I need to
do and am nearly done with that, then I have a couple more small things
done (including SOLR-12763 which I just created since I forgot to do it
earlier). My goal is to be done by the end of my day today so you could do
the RC tomorrow, but who knows what the day will bring work-wise, so I'll
send another mail at the end of the day my time to let you know for sure.

On Mon, Sep 10, 2018 at 9:07 AM jim ferenczi  wrote:

> I just fixed the invalid version (7.5.1) that I added in master and 7x.
> The next version on these branches should be 7.6.0, sorry for the noise.
>
> Le lun. 10 sept. 2018 à 09:26, jim ferenczi  a
> écrit :
>
>> Hi,
>>
>> Feature freeze for 7.5 has started, I just created a branch_7_5.:
>>
>> * No new features may be committed to the branch.
>> * Documentation patches, build patches and serious bug fixes may be
>> committed to the branch. However, you should submit all patches you want to
>> commit to Jira first to give others the chance to review and possibly vote
>> against the patch. Keep in mind that it is our main intention to keep the
>> branch as stable as possible.
>> * All patches that are intended for the branch should first be committed
>> to the unstable branch, merged into the stable branch, and then into the
>> current release branch.
>> * Normal unstable and stable branch development may continue as usual.
>> However, if you plan to commit a big change to the unstable branch while
>> the branch feature freeze is in effect, think twice: can't the addition
>> wait a couple more days? Merges of bug fixes into the branch may become
>> more difficult.
>> * Only Jira issues with Fix version "7.5" and priority "Blocker" will
>> delay a release candidate build.
>>
>> I'll create the first RC later this week depending on the status of the
>> Solr ref guide. Cassandra, can you update the status when you think that
>> the ref guide is ready (no rush just a reminder that we need to sync during
>> this release ;) ) ?
>>
>> Cheers,
>> Jim
>>
>> Le mer. 5 sept. 2018 à 17:57, Erick Erickson  a
>> écrit :
>>
>>> Great, thanks!
>>> On Wed, Sep 5, 2018 at 8:44 AM jim ferenczi 
>>> wrote:
>>> >
>>> > Sure it can wait a few days. Let's cut the branch next Monday and we
>>> can sync with Cassandra to create the first RC when the ref guide is ready.
>>> >
>>> > Le mer. 5 sept. 2018 à 17:27, Erick Erickson 
>>> a écrit :
>>> >>
>>> >> Jim:
>>> >>
>>> >> I know it's the 11th hour, but WDYT about cutting the branch next
>>> >> Monday? We see a flurry of activity (announcing a release does
>>> >> that) and waiting to cut the branch might be easiest all 'round.
>>> >>
>>> >> Up to you of course, I can backport the test fixes I'd like for
>>> >> instance and I'd like to get the upgraded ZooKeeper in 7.5.
>>> >>
>>> >> Erick
>>> >> On Tue, Sep 4, 2018 at 1:04 PM Cassandra Targett <
>>> casstarg...@gmail.com> wrote:
>>> >> >
>>> >> > It's not so much the building of the RC as giving the content a
>>> detailed editorial review.
>>> >> >
>>> >> > The build/release process itself is well-documented and published
>>> with every Ref Guide:
>>> https://lucene.apache.org/solr/guide/how-to-contribute.html#building-publishing-the-guide.
>>> It was designed from the artifact process, so it's nearly identical as a
>>> process. It's really barely a burden.
>>> >> >
>>> >> > In terms of preparing the content, there are a number of things I
>>> do:
>>> >> >
>>> >> > First, I try to ensure that every issue in CHANGES.txt that should
>>> be documented has been documented. That involves an intensive review of
>>> CHANGES.txt and a comparison with commits to find what might be missing,
>>> then chasing people down to see if they intend to make changes or not.
>>> Assuming the person responds, then it's waiting for them to get their stuff
>>> done. This is usually about 2-3 days of effort, before the waiting around
>>> for answers and/or commits.
>>> >> >
>>> >> > Then I review every commit and read it for clarity and correct
>>> English usage. Does it fit where someone put it? Does it explain what the
>>> author is hoping it explains? Also, many of our authors are not native
>>> English writers, and deserve the assistance of an editor to help put their
>>> work in the best possible light. In some cases, I feel I should extensively
>>> edit the contribution, which occasionally involves also immersing myself
>>> into the change itself. This is another 2-4 days of effort.
>>> >> >
>>> >> > Then there's this list of problems people commit all the time, many
>>> of which I can often resolve reasonably quickly with find/replace:
>>> >> >
>>> >> > - sentences that don't end in periods
>>> >> > - inconsistency with instances of "i.e.," and "e.g.," (not "i.e.",
>>> "ie:", "IE", etc.)
>>> >> > - no spaces between words and punctuation (commas, colons,
>>> periods), such as "here 

[jira] [Created] (SOLR-12763) Ref Guide: Upgrade notes for 7.5

[Cassandra Targett (JIRA)]

Cassandra Targett created SOLR-12763:


 Summary: Ref Guide: Upgrade notes for 7.5
 Key: SOLR-12763
 URL: https://issues.apache.org/jira/browse/SOLR-12763
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: documentation
Reporter: Cassandra Targett
Assignee: Cassandra Targett
 Fix For: 7.5


Put upgrade notes from CHANGES (and any other important-to-mention items) into 
the Ref Guide for 7.5.



--
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/jdk-10.0.1) - Build # 785 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/785/
Java: 64bit/jdk-10.0.1 -XX:+UseCompressedOops -XX:+UseParallelGC

2 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.ScheduledTriggerTest.testTrigger

Error Message:
expected:<3> but was:<2>

Stack Trace:
java.lang.AssertionError: expected:<3> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([178A7EE215D6BB14:744148608C19C839]: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.cloud.autoscaling.ScheduledTriggerTest.scheduledTriggerTest(ScheduledTriggerTest.java:113)
at 
org.apache.solr.cloud.autoscaling.ScheduledTriggerTest.testTrigger(ScheduledTriggerTest.java:66)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
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:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
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)


FAILED:  

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

[Apache Jenkins Server]

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

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

[repro] Revision: 61447db8df360dbe69028931efa8b491a127462c

[repro] Repro line:  ant test  -Dtestcase=SearchHandlerTest 
-Dtests.method=testRequireZkConnected -Dtests.seed=395E456F583E324B 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=mk-MK 
-Dtests.timezone=GMT0 -Dtests.asserts=true -Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=TestSimTriggerIntegration 
-Dtests.method=testSearchRate -Dtests.seed=395E456F583E324B 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=ar-EG 
-Dtests.timezone=Pacific/Majuro -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: 
a1b6db26db5e03a31492549a181c285f9b35c9a2
[repro] git fetch
[repro] git checkout 61447db8df360dbe69028931efa8b491a127462c

[...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]   SearchHandlerTest
[repro]   TestSimTriggerIntegration
[repro] ant compile-test

[...truncated 3437 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=10 
-Dtests.class="*.SearchHandlerTest|*.TestSimTriggerIntegration" 
-Dtests.showOutput=onerror  -Dtests.seed=395E456F583E324B -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=mk-MK -Dtests.timezone=GMT0 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8

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

[repro] Failures:
[repro]   0/5 failed: org.apache.solr.handler.SearchHandlerTest
[repro]   0/5 failed: org.apache.solr.handler.component.SearchHandlerTest
[repro]   1/5 failed: 
org.apache.solr.cloud.autoscaling.sim.TestSimTriggerIntegration
[repro] git checkout a1b6db26db5e03a31492549a181c285f9b35c9a2

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

[...truncated 6 lines...]

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

[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-10) - Build # 7517 - Failure!

[Policeman Jenkins Server]

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

3 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.sim.TestSimGenericDistributedQueue.testDistributedQueueBlocking

Error Message:


Stack Trace:
java.util.concurrent.TimeoutException
at 
__randomizedtesting.SeedInfo.seed([44FBD9CBABFA5F12:151ABB2EFA8E366]:0)
at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:204)
at 
org.apache.solr.cloud.autoscaling.sim.TestSimDistributedQueue.testDistributedQueueBlocking(TestSimDistributedQueue.java:102)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
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:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
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)


FAILED:  
org.apache.solr.cloud.autoscaling.sim.TestSimGenericDistributedQueue.testDistributedQueue
 {#2}

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at 

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

[Policeman Jenkins Server]

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

34 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.extraction.ExtractingRequestHandlerTest

Error Message:
SOLR-12759 JDK 11 (1st release) and Tika 1.x can result in extracting dates in 
a bad format.

Stack Trace:
java.lang.AssertionError: SOLR-12759 JDK 11 (1st release) and Tika 1.x can 
result in extracting dates in a bad format.
at __randomizedtesting.SeedInfo.seed([C4EFA964CD8CC27B]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertFalse(Assert.java:68)
at 
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.beforeClass(ExtractingRequestHandlerTest.java:44)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
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.handler.extraction.ExtractingRequestHandlerTest

Error Message:
SOLR-12759 JDK 11 (1st release) and Tika 1.x can result in extracting dates in 
a bad format.

Stack Trace:
java.lang.AssertionError: SOLR-12759 JDK 11 (1st release) and Tika 1.x can 
result in extracting dates in a bad format.
at __randomizedtesting.SeedInfo.seed([C4EFA964CD8CC27B]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertFalse(Assert.java:68)
at 
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.beforeClass(ExtractingRequestHandlerTest.java:44)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at