[JENKINS-EA] Lucene-Solr-7.0-Linux (64bit/jdk-9-ea+178) - Build # 147 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.0-Linux/147/
Java: 64bit/jdk-9-ea+178 -XX:-UseCompressedOops -XX:+UseG1GC 
--illegal-access=deny

1 tests failed.
FAILED:  org.apache.solr.TestDistributedSearch.test

Error Message:
Error from server at http://127.0.0.1:38747//collection1: ERROR: [doc=1] Error 
adding field 'severity'='Not Available' msg=EnumFieldType requires 
docValues="true".

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:38747//collection1: ERROR: [doc=1] Error adding 
field 'severity'='Not Available' msg=EnumFieldType requires docValues="true".
at 
__randomizedtesting.SeedInfo.seed([81C6880737673323:992B7DD999B5EDB]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:627)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:173)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:138)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:152)
at 
org.apache.solr.BaseDistributedSearchTestCase.indexDoc(BaseDistributedSearchTestCase.java:483)
at 
org.apache.solr.BaseDistributedSearchTestCase.indexr(BaseDistributedSearchTestCase.java:465)
at 
org.apache.solr.TestDistributedSearch.test(TestDistributedSearch.java:1052)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsRepeatStatement.callStatement(BaseDistributedSearchTestCase.java:1019)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/204/
Java: 64bit/jdk1.8.0_141 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.TestDistributedSearch.test

Error Message:
Error from server at http://127.0.0.1:36753//collection1: ERROR: [doc=1] Error 
adding field 'severity'='Not Available' msg=EnumFieldType requires 
docValues="true".

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:36753//collection1: ERROR: [doc=1] Error adding 
field 'severity'='Not Available' msg=EnumFieldType requires docValues="true".
at 
__randomizedtesting.SeedInfo.seed([A1F7BC792B34:29A383A385C85ECB]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:627)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:173)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:138)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:152)
at 
org.apache.solr.BaseDistributedSearchTestCase.indexDoc(BaseDistributedSearchTestCase.java:483)
at 
org.apache.solr.BaseDistributedSearchTestCase.indexr(BaseDistributedSearchTestCase.java:465)
at 
org.apache.solr.TestDistributedSearch.test(TestDistributedSearch.java:1052)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsRepeatStatement.callStatement(BaseDistributedSearchTestCase.java:1019)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 

[jira] [Commented] (SOLR-10317) Solr Nightly Benchmarks

[Vivek Narang (JIRA)]

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

Vivek Narang commented on SOLR-10317:
-

Hi [~ichattopadhyaya],
Status:
-Testing complete and bugs fixed in the new QPS calculation logic, the code 
will be pushed in one hour. 
Regards.

> Solr Nightly Benchmarks
> ---
>
> Key: SOLR-10317
> URL: https://issues.apache.org/jira/browse/SOLR-10317
> Project: Solr
>  Issue Type: Task
>Reporter: Ishan Chattopadhyaya
>  Labels: gsoc2017, mentor
> Attachments: changes-lucene-20160907.json, 
> changes-solr-20160907.json, managed-schema, 
> Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks.docx, 
> Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks-FINAL-PROPOSAL.pdf, 
> Screenshot from 2017-07-30 20-30-05.png, SOLR-10317.patch, SOLR-10317.patch, 
> solrconfig.xml
>
>
> Solr needs nightly benchmarks reporting. Similar Lucene benchmarks can be 
> found here, https://home.apache.org/~mikemccand/lucenebench/.
> Preferably, we need:
> # A suite of benchmarks that build Solr from a commit point, start Solr 
> nodes, both in SolrCloud and standalone mode, and record timing information 
> of various operations like indexing, querying, faceting, grouping, 
> replication etc.
> # It should be possible to run them either as an independent suite or as a 
> Jenkins job, and we should be able to report timings as graphs (Jenkins has 
> some charting plugins).
> # The code should eventually be integrated in the Solr codebase, so that it 
> never goes out of date.
> There is some prior work / discussion:
> # https://github.com/shalinmangar/solr-perf-tools (Shalin)
> # https://github.com/chatman/solr-upgrade-tests/blob/master/BENCHMARKS.md 
> (Ishan/Vivek)
> # SOLR-2646 & SOLR-9863 (Mark Miller)
> # https://home.apache.org/~mikemccand/lucenebench/ (Mike McCandless)
> # https://github.com/lucidworks/solr-scale-tk (Tim Potter)
> There is support for building, starting, indexing/querying and stopping Solr 
> in some of these frameworks above. However, the benchmarks run are very 
> limited. Any of these can be a starting point, or a new framework can as well 
> be used. The motivation is to be able to cover every functionality of Solr 
> with a corresponding benchmark that is run every night.
> Proposing this as a GSoC 2017 project. I'm willing to mentor, and I'm sure 
> [~shalinmangar] and [~markrmil...@gmail.com] would help here.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_141) - Build # 20261 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20261/
Java: 32bit/jdk1.8.0_141 -server -XX:+UseParallelGC

2 tests failed.
FAILED:  
org.apache.lucene.search.suggest.analyzing.AnalyzingSuggesterTest.testRandomRealisticKeys

Error Message:
input automaton is too large: 1001

Stack Trace:
java.lang.IllegalArgumentException: input automaton is too large: 1001
at 
__randomizedtesting.SeedInfo.seed([CF9E36AE33A5C122:4D5AC03BE61C35E9]:0)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1298)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 

[jira] [Commented] (SOLR-10821) Write documentation for the autoscaling APIs and policy/preferences syntax for Solr 7.0

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10821:


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

SOLR-10821: Ref guide documentation for Autoscaling

Squashed commit of the following:

commit 4a8eb9491a1dc8099805656adec34197d0dab092
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 14:35:57 2017 +0530

SOLR-10821: Added note on using maxShardsPerNode along with a policy

commit 2a9bb140e12a60f93a6314647cf7d4fdc7f4fe60
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 14:04:48 2017 +0530

SOLR-10821: Use availability zone as an example instead of region

commit e5f0fe130ae7a269df7a3741c7ed7bf8b009c446
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:34:04 2017 +0530

SOLR-10821: Removed mention of triggers

commit 876276626a90849068d5fd893ba3660ac687
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:32:29 2017 +0530

SOLR-10821: Added policy specifications and examples

commit 245be9c44af7427fbde292120520f70ed54cadc9
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:12:09 2017 +0530

SOLR-10821: Added note on what happens when you change the 
policy/preferences

commit 202fe3324748fdfb12d5ffbba60bd69c6aa768cb
Author: Shalin Shekhar Mangar 
Date:   Thu Aug 3 20:32:10 2017 +0530

SOLR-10821: Added specification for policy attributes and operators

commit ccb6c559eb1ee080c5be06f1b471554d5038f699
Author: Shalin Shekhar Mangar 
Date:   Thu Aug 3 13:14:41 2017 +0530

SOLR-10821: Added documentation on how to completely remove cluster 
preferences and policies

commit 24e4827f2e482929546a6e0de447046f79e1510d
Author: Shalin Shekhar Mangar 
Date:   Tue Aug 1 10:00:15 2017 +0530

SOLR-10821: Added documentation for cluster preferences

commit d77c4786909e406ba194ef7144e1abd38c8bce83
Author: Cassandra Targett 
Date:   Mon Jul 31 13:19:30 2017 -0500

SOLR-10821: standardize "autoscaling" spelling & headings; other small copy 
edits

commit 4644e2963d8bb51aada46fc3c9180eec0bfdac12
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 17:15:29 2017 +0530

SOLR-10821: Added docs for the autoscaling write APIs

commit c7c0c86a2e3e15e6aa4e986a865e73e596cf275e
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 14:13:56 2017 +0530

Added docs for the autoscaling read and diagnostics API

commit 1fd011cce3a97eb51597d5ca09c02ca5038c769b
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:14:35 2017 +0530

SOLR-10821: Removed host/port and only show the path information in example

commit 9199fa3432f8c5ab4df35dbe776aeb586baa60ec
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:12:46 2017 +0530

SOLR-10821: Remove mention of triggers and listeners

commit d7f7639fa1dbe3584f9f1dabb3663a5630b78fcb
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:06:19 2017 +0530

SOLR-10821: First cut of nav structure and overview page for autoscaling 
features in 7.0


> Write documentation for the autoscaling APIs and policy/preferences syntax 
> for Solr 7.0
> ---
>
> Key: SOLR-10821
> URL: https://issues.apache.org/jira/browse/SOLR-10821
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>  Labels: autoscaling
> Fix For: 7.0
>
>
> We need to document the following:
> # set-policy
> # set-cluster-preferences
> # set-cluster-policy
> # Autoscaling configuration read API
> # Autoscaling diagnostics API
> # policy and preference rule syntax



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10821) Write documentation for the autoscaling APIs and policy/preferences syntax for Solr 7.0

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10821:


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

SOLR-10821: Ref guide documentation for Autoscaling

Squashed commit of the following:

commit 4a8eb9491a1dc8099805656adec34197d0dab092
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 14:35:57 2017 +0530

SOLR-10821: Added note on using maxShardsPerNode along with a policy

commit 2a9bb140e12a60f93a6314647cf7d4fdc7f4fe60
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 14:04:48 2017 +0530

SOLR-10821: Use availability zone as an example instead of region

commit e5f0fe130ae7a269df7a3741c7ed7bf8b009c446
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:34:04 2017 +0530

SOLR-10821: Removed mention of triggers

commit 876276626a90849068d5fd893ba3660ac687
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:32:29 2017 +0530

SOLR-10821: Added policy specifications and examples

commit 245be9c44af7427fbde292120520f70ed54cadc9
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:12:09 2017 +0530

SOLR-10821: Added note on what happens when you change the 
policy/preferences

commit 202fe3324748fdfb12d5ffbba60bd69c6aa768cb
Author: Shalin Shekhar Mangar 
Date:   Thu Aug 3 20:32:10 2017 +0530

SOLR-10821: Added specification for policy attributes and operators

commit ccb6c559eb1ee080c5be06f1b471554d5038f699
Author: Shalin Shekhar Mangar 
Date:   Thu Aug 3 13:14:41 2017 +0530

SOLR-10821: Added documentation on how to completely remove cluster 
preferences and policies

commit 24e4827f2e482929546a6e0de447046f79e1510d
Author: Shalin Shekhar Mangar 
Date:   Tue Aug 1 10:00:15 2017 +0530

SOLR-10821: Added documentation for cluster preferences

commit d77c4786909e406ba194ef7144e1abd38c8bce83
Author: Cassandra Targett 
Date:   Mon Jul 31 13:19:30 2017 -0500

SOLR-10821: standardize "autoscaling" spelling & headings; other small copy 
edits

commit 4644e2963d8bb51aada46fc3c9180eec0bfdac12
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 17:15:29 2017 +0530

SOLR-10821: Added docs for the autoscaling write APIs

commit c7c0c86a2e3e15e6aa4e986a865e73e596cf275e
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 14:13:56 2017 +0530

Added docs for the autoscaling read and diagnostics API

commit 1fd011cce3a97eb51597d5ca09c02ca5038c769b
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:14:35 2017 +0530

SOLR-10821: Removed host/port and only show the path information in example

commit 9199fa3432f8c5ab4df35dbe776aeb586baa60ec
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:12:46 2017 +0530

SOLR-10821: Remove mention of triggers and listeners

commit d7f7639fa1dbe3584f9f1dabb3663a5630b78fcb
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:06:19 2017 +0530

SOLR-10821: First cut of nav structure and overview page for autoscaling 
features in 7.0


> Write documentation for the autoscaling APIs and policy/preferences syntax 
> for Solr 7.0
> ---
>
> Key: SOLR-10821
> URL: https://issues.apache.org/jira/browse/SOLR-10821
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>  Labels: autoscaling
> Fix For: 7.0
>
>
> We need to document the following:
> # set-policy
> # set-cluster-preferences
> # set-cluster-policy
> # Autoscaling configuration read API
> # Autoscaling diagnostics API
> # policy and preference rule syntax



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10821) Write documentation for the autoscaling APIs and policy/preferences syntax for Solr 7.0

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10821:


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

SOLR-10821: Ref guide documentation for Autoscaling

Squashed commit of the following:

commit 4a8eb9491a1dc8099805656adec34197d0dab092
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 14:35:57 2017 +0530

SOLR-10821: Added note on using maxShardsPerNode along with a policy

commit 2a9bb140e12a60f93a6314647cf7d4fdc7f4fe60
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 14:04:48 2017 +0530

SOLR-10821: Use availability zone as an example instead of region

commit e5f0fe130ae7a269df7a3741c7ed7bf8b009c446
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:34:04 2017 +0530

SOLR-10821: Removed mention of triggers

commit 876276626a90849068d5fd893ba3660ac687
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:32:29 2017 +0530

SOLR-10821: Added policy specifications and examples

commit 245be9c44af7427fbde292120520f70ed54cadc9
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:12:09 2017 +0530

SOLR-10821: Added note on what happens when you change the 
policy/preferences

commit 202fe3324748fdfb12d5ffbba60bd69c6aa768cb
Author: Shalin Shekhar Mangar 
Date:   Thu Aug 3 20:32:10 2017 +0530

SOLR-10821: Added specification for policy attributes and operators

commit ccb6c559eb1ee080c5be06f1b471554d5038f699
Author: Shalin Shekhar Mangar 
Date:   Thu Aug 3 13:14:41 2017 +0530

SOLR-10821: Added documentation on how to completely remove cluster 
preferences and policies

commit 24e4827f2e482929546a6e0de447046f79e1510d
Author: Shalin Shekhar Mangar 
Date:   Tue Aug 1 10:00:15 2017 +0530

SOLR-10821: Added documentation for cluster preferences

commit d77c4786909e406ba194ef7144e1abd38c8bce83
Author: Cassandra Targett 
Date:   Mon Jul 31 13:19:30 2017 -0500

SOLR-10821: standardize "autoscaling" spelling & headings; other small copy 
edits

commit 4644e2963d8bb51aada46fc3c9180eec0bfdac12
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 17:15:29 2017 +0530

SOLR-10821: Added docs for the autoscaling write APIs

commit c7c0c86a2e3e15e6aa4e986a865e73e596cf275e
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 14:13:56 2017 +0530

Added docs for the autoscaling read and diagnostics API

commit 1fd011cce3a97eb51597d5ca09c02ca5038c769b
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:14:35 2017 +0530

SOLR-10821: Removed host/port and only show the path information in example

commit 9199fa3432f8c5ab4df35dbe776aeb586baa60ec
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:12:46 2017 +0530

SOLR-10821: Remove mention of triggers and listeners

commit d7f7639fa1dbe3584f9f1dabb3663a5630b78fcb
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:06:19 2017 +0530

SOLR-10821: First cut of nav structure and overview page for autoscaling 
features in 7.0


> Write documentation for the autoscaling APIs and policy/preferences syntax 
> for Solr 7.0
> ---
>
> Key: SOLR-10821
> URL: https://issues.apache.org/jira/browse/SOLR-10821
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>  Labels: autoscaling
> Fix For: 7.0
>
>
> We need to document the following:
> # set-policy
> # set-cluster-preferences
> # set-cluster-policy
> # Autoscaling configuration read API
> # Autoscaling diagnostics API
> # policy and preference rule syntax



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10821) Write documentation for the autoscaling APIs and policy/preferences syntax for Solr 7.0

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10821:


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

SOLR-10821: Ref guide documentation for Autoscaling

Squashed commit of the following:

commit 4a8eb9491a1dc8099805656adec34197d0dab092
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 14:35:57 2017 +0530

SOLR-10821: Added note on using maxShardsPerNode along with a policy

commit 2a9bb140e12a60f93a6314647cf7d4fdc7f4fe60
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 14:04:48 2017 +0530

SOLR-10821: Use availability zone as an example instead of region

commit e5f0fe130ae7a269df7a3741c7ed7bf8b009c446
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:34:04 2017 +0530

SOLR-10821: Removed mention of triggers

commit 876276626a90849068d5fd893ba3660ac687
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:32:29 2017 +0530

SOLR-10821: Added policy specifications and examples

commit 245be9c44af7427fbde292120520f70ed54cadc9
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:12:09 2017 +0530

SOLR-10821: Added note on what happens when you change the 
policy/preferences

commit 202fe3324748fdfb12d5ffbba60bd69c6aa768cb
Author: Shalin Shekhar Mangar 
Date:   Thu Aug 3 20:32:10 2017 +0530

SOLR-10821: Added specification for policy attributes and operators

commit ccb6c559eb1ee080c5be06f1b471554d5038f699
Author: Shalin Shekhar Mangar 
Date:   Thu Aug 3 13:14:41 2017 +0530

SOLR-10821: Added documentation on how to completely remove cluster 
preferences and policies

commit 24e4827f2e482929546a6e0de447046f79e1510d
Author: Shalin Shekhar Mangar 
Date:   Tue Aug 1 10:00:15 2017 +0530

SOLR-10821: Added documentation for cluster preferences

commit d77c4786909e406ba194ef7144e1abd38c8bce83
Author: Cassandra Targett 
Date:   Mon Jul 31 13:19:30 2017 -0500

SOLR-10821: standardize "autoscaling" spelling & headings; other small copy 
edits

commit 4644e2963d8bb51aada46fc3c9180eec0bfdac12
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 17:15:29 2017 +0530

SOLR-10821: Added docs for the autoscaling write APIs

commit c7c0c86a2e3e15e6aa4e986a865e73e596cf275e
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 14:13:56 2017 +0530

Added docs for the autoscaling read and diagnostics API

commit 1fd011cce3a97eb51597d5ca09c02ca5038c769b
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:14:35 2017 +0530

SOLR-10821: Removed host/port and only show the path information in example

commit 9199fa3432f8c5ab4df35dbe776aeb586baa60ec
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:12:46 2017 +0530

SOLR-10821: Remove mention of triggers and listeners

commit d7f7639fa1dbe3584f9f1dabb3663a5630b78fcb
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:06:19 2017 +0530

SOLR-10821: First cut of nav structure and overview page for autoscaling 
features in 7.0


> Write documentation for the autoscaling APIs and policy/preferences syntax 
> for Solr 7.0
> ---
>
> Key: SOLR-10821
> URL: https://issues.apache.org/jira/browse/SOLR-10821
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>  Labels: autoscaling
> Fix For: 7.0
>
>
> We need to document the following:
> # set-policy
> # set-cluster-preferences
> # set-cluster-policy
> # Autoscaling configuration read API
> # Autoscaling diagnostics API
> # policy and preference rule syntax



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10821) Write documentation for the autoscaling APIs and policy/preferences syntax for Solr 7.0

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10821:


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

SOLR-10821: Ref guide documentation for Autoscaling

Squashed commit of the following:

commit 4a8eb9491a1dc8099805656adec34197d0dab092
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 14:35:57 2017 +0530

SOLR-10821: Added note on using maxShardsPerNode along with a policy

commit 2a9bb140e12a60f93a6314647cf7d4fdc7f4fe60
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 14:04:48 2017 +0530

SOLR-10821: Use availability zone as an example instead of region

commit e5f0fe130ae7a269df7a3741c7ed7bf8b009c446
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:34:04 2017 +0530

SOLR-10821: Removed mention of triggers

commit 876276626a90849068d5fd893ba3660ac687
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:32:29 2017 +0530

SOLR-10821: Added policy specifications and examples

commit 245be9c44af7427fbde292120520f70ed54cadc9
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:12:09 2017 +0530

SOLR-10821: Added note on what happens when you change the 
policy/preferences

commit 202fe3324748fdfb12d5ffbba60bd69c6aa768cb
Author: Shalin Shekhar Mangar 
Date:   Thu Aug 3 20:32:10 2017 +0530

SOLR-10821: Added specification for policy attributes and operators

commit ccb6c559eb1ee080c5be06f1b471554d5038f699
Author: Shalin Shekhar Mangar 
Date:   Thu Aug 3 13:14:41 2017 +0530

SOLR-10821: Added documentation on how to completely remove cluster 
preferences and policies

commit 24e4827f2e482929546a6e0de447046f79e1510d
Author: Shalin Shekhar Mangar 
Date:   Tue Aug 1 10:00:15 2017 +0530

SOLR-10821: Added documentation for cluster preferences

commit d77c4786909e406ba194ef7144e1abd38c8bce83
Author: Cassandra Targett 
Date:   Mon Jul 31 13:19:30 2017 -0500

SOLR-10821: standardize "autoscaling" spelling & headings; other small copy 
edits

commit 4644e2963d8bb51aada46fc3c9180eec0bfdac12
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 17:15:29 2017 +0530

SOLR-10821: Added docs for the autoscaling write APIs

commit c7c0c86a2e3e15e6aa4e986a865e73e596cf275e
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 14:13:56 2017 +0530

Added docs for the autoscaling read and diagnostics API

commit 1fd011cce3a97eb51597d5ca09c02ca5038c769b
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:14:35 2017 +0530

SOLR-10821: Removed host/port and only show the path information in example

commit 9199fa3432f8c5ab4df35dbe776aeb586baa60ec
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:12:46 2017 +0530

SOLR-10821: Remove mention of triggers and listeners

commit d7f7639fa1dbe3584f9f1dabb3663a5630b78fcb
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:06:19 2017 +0530

SOLR-10821: First cut of nav structure and overview page for autoscaling 
features in 7.0


> Write documentation for the autoscaling APIs and policy/preferences syntax 
> for Solr 7.0
> ---
>
> Key: SOLR-10821
> URL: https://issues.apache.org/jira/browse/SOLR-10821
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>  Labels: autoscaling
> Fix For: 7.0
>
>
> We need to document the following:
> # set-policy
> # set-cluster-preferences
> # set-cluster-policy
> # Autoscaling configuration read API
> # Autoscaling diagnostics API
> # policy and preference rule syntax



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10821) Write documentation for the autoscaling APIs and policy/preferences syntax for Solr 7.0

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10821:


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

SOLR-10821: Ref guide documentation for Autoscaling

Squashed commit of the following:

commit 4a8eb9491a1dc8099805656adec34197d0dab092
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 14:35:57 2017 +0530

SOLR-10821: Added note on using maxShardsPerNode along with a policy

commit 2a9bb140e12a60f93a6314647cf7d4fdc7f4fe60
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 14:04:48 2017 +0530

SOLR-10821: Use availability zone as an example instead of region

commit e5f0fe130ae7a269df7a3741c7ed7bf8b009c446
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:34:04 2017 +0530

SOLR-10821: Removed mention of triggers

commit 876276626a90849068d5fd893ba3660ac687
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:32:29 2017 +0530

SOLR-10821: Added policy specifications and examples

commit 245be9c44af7427fbde292120520f70ed54cadc9
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:12:09 2017 +0530

SOLR-10821: Added note on what happens when you change the 
policy/preferences

commit 202fe3324748fdfb12d5ffbba60bd69c6aa768cb
Author: Shalin Shekhar Mangar 
Date:   Thu Aug 3 20:32:10 2017 +0530

SOLR-10821: Added specification for policy attributes and operators

commit ccb6c559eb1ee080c5be06f1b471554d5038f699
Author: Shalin Shekhar Mangar 
Date:   Thu Aug 3 13:14:41 2017 +0530

SOLR-10821: Added documentation on how to completely remove cluster 
preferences and policies

commit 24e4827f2e482929546a6e0de447046f79e1510d
Author: Shalin Shekhar Mangar 
Date:   Tue Aug 1 10:00:15 2017 +0530

SOLR-10821: Added documentation for cluster preferences

commit d77c4786909e406ba194ef7144e1abd38c8bce83
Author: Cassandra Targett 
Date:   Mon Jul 31 13:19:30 2017 -0500

SOLR-10821: standardize "autoscaling" spelling & headings; other small copy 
edits

commit 4644e2963d8bb51aada46fc3c9180eec0bfdac12
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 17:15:29 2017 +0530

SOLR-10821: Added docs for the autoscaling write APIs

commit c7c0c86a2e3e15e6aa4e986a865e73e596cf275e
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 14:13:56 2017 +0530

Added docs for the autoscaling read and diagnostics API

commit 1fd011cce3a97eb51597d5ca09c02ca5038c769b
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:14:35 2017 +0530

SOLR-10821: Removed host/port and only show the path information in example

commit 9199fa3432f8c5ab4df35dbe776aeb586baa60ec
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:12:46 2017 +0530

SOLR-10821: Remove mention of triggers and listeners

commit d7f7639fa1dbe3584f9f1dabb3663a5630b78fcb
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:06:19 2017 +0530

SOLR-10821: First cut of nav structure and overview page for autoscaling 
features in 7.0


> Write documentation for the autoscaling APIs and policy/preferences syntax 
> for Solr 7.0
> ---
>
> Key: SOLR-10821
> URL: https://issues.apache.org/jira/browse/SOLR-10821
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>  Labels: autoscaling
> Fix For: 7.0
>
>
> We need to document the following:
> # set-policy
> # set-cluster-preferences
> # set-cluster-policy
> # Autoscaling configuration read API
> # Autoscaling diagnostics API
> # policy and preference rule syntax



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10821) Write documentation for the autoscaling APIs and policy/preferences syntax for Solr 7.0

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10821:


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

SOLR-10821: Ref guide documentation for Autoscaling

Squashed commit of the following:

commit 4a8eb9491a1dc8099805656adec34197d0dab092
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 14:35:57 2017 +0530

SOLR-10821: Added note on using maxShardsPerNode along with a policy

commit 2a9bb140e12a60f93a6314647cf7d4fdc7f4fe60
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 14:04:48 2017 +0530

SOLR-10821: Use availability zone as an example instead of region

commit e5f0fe130ae7a269df7a3741c7ed7bf8b009c446
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:34:04 2017 +0530

SOLR-10821: Removed mention of triggers

commit 876276626a90849068d5fd893ba3660ac687
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:32:29 2017 +0530

SOLR-10821: Added policy specifications and examples

commit 245be9c44af7427fbde292120520f70ed54cadc9
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:12:09 2017 +0530

SOLR-10821: Added note on what happens when you change the 
policy/preferences

commit 202fe3324748fdfb12d5ffbba60bd69c6aa768cb
Author: Shalin Shekhar Mangar 
Date:   Thu Aug 3 20:32:10 2017 +0530

SOLR-10821: Added specification for policy attributes and operators

commit ccb6c559eb1ee080c5be06f1b471554d5038f699
Author: Shalin Shekhar Mangar 
Date:   Thu Aug 3 13:14:41 2017 +0530

SOLR-10821: Added documentation on how to completely remove cluster 
preferences and policies

commit 24e4827f2e482929546a6e0de447046f79e1510d
Author: Shalin Shekhar Mangar 
Date:   Tue Aug 1 10:00:15 2017 +0530

SOLR-10821: Added documentation for cluster preferences

commit d77c4786909e406ba194ef7144e1abd38c8bce83
Author: Cassandra Targett 
Date:   Mon Jul 31 13:19:30 2017 -0500

SOLR-10821: standardize "autoscaling" spelling & headings; other small copy 
edits

commit 4644e2963d8bb51aada46fc3c9180eec0bfdac12
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 17:15:29 2017 +0530

SOLR-10821: Added docs for the autoscaling write APIs

commit c7c0c86a2e3e15e6aa4e986a865e73e596cf275e
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 14:13:56 2017 +0530

Added docs for the autoscaling read and diagnostics API

commit 1fd011cce3a97eb51597d5ca09c02ca5038c769b
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:14:35 2017 +0530

SOLR-10821: Removed host/port and only show the path information in example

commit 9199fa3432f8c5ab4df35dbe776aeb586baa60ec
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:12:46 2017 +0530

SOLR-10821: Remove mention of triggers and listeners

commit d7f7639fa1dbe3584f9f1dabb3663a5630b78fcb
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:06:19 2017 +0530

SOLR-10821: First cut of nav structure and overview page for autoscaling 
features in 7.0


> Write documentation for the autoscaling APIs and policy/preferences syntax 
> for Solr 7.0
> ---
>
> Key: SOLR-10821
> URL: https://issues.apache.org/jira/browse/SOLR-10821
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>  Labels: autoscaling
> Fix For: 7.0
>
>
> We need to document the following:
> # set-policy
> # set-cluster-preferences
> # set-cluster-policy
> # Autoscaling configuration read API
> # Autoscaling diagnostics API
> # policy and preference rule syntax



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10821) Write documentation for the autoscaling APIs and policy/preferences syntax for Solr 7.0

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10821:


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

SOLR-10821: Ref guide documentation for Autoscaling

Squashed commit of the following:

commit 4a8eb9491a1dc8099805656adec34197d0dab092
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 14:35:57 2017 +0530

SOLR-10821: Added note on using maxShardsPerNode along with a policy

commit 2a9bb140e12a60f93a6314647cf7d4fdc7f4fe60
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 14:04:48 2017 +0530

SOLR-10821: Use availability zone as an example instead of region

commit e5f0fe130ae7a269df7a3741c7ed7bf8b009c446
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:34:04 2017 +0530

SOLR-10821: Removed mention of triggers

commit 876276626a90849068d5fd893ba3660ac687
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:32:29 2017 +0530

SOLR-10821: Added policy specifications and examples

commit 245be9c44af7427fbde292120520f70ed54cadc9
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:12:09 2017 +0530

SOLR-10821: Added note on what happens when you change the 
policy/preferences

commit 202fe3324748fdfb12d5ffbba60bd69c6aa768cb
Author: Shalin Shekhar Mangar 
Date:   Thu Aug 3 20:32:10 2017 +0530

SOLR-10821: Added specification for policy attributes and operators

commit ccb6c559eb1ee080c5be06f1b471554d5038f699
Author: Shalin Shekhar Mangar 
Date:   Thu Aug 3 13:14:41 2017 +0530

SOLR-10821: Added documentation on how to completely remove cluster 
preferences and policies

commit 24e4827f2e482929546a6e0de447046f79e1510d
Author: Shalin Shekhar Mangar 
Date:   Tue Aug 1 10:00:15 2017 +0530

SOLR-10821: Added documentation for cluster preferences

commit d77c4786909e406ba194ef7144e1abd38c8bce83
Author: Cassandra Targett 
Date:   Mon Jul 31 13:19:30 2017 -0500

SOLR-10821: standardize "autoscaling" spelling & headings; other small copy 
edits

commit 4644e2963d8bb51aada46fc3c9180eec0bfdac12
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 17:15:29 2017 +0530

SOLR-10821: Added docs for the autoscaling write APIs

commit c7c0c86a2e3e15e6aa4e986a865e73e596cf275e
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 14:13:56 2017 +0530

Added docs for the autoscaling read and diagnostics API

commit 1fd011cce3a97eb51597d5ca09c02ca5038c769b
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:14:35 2017 +0530

SOLR-10821: Removed host/port and only show the path information in example

commit 9199fa3432f8c5ab4df35dbe776aeb586baa60ec
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:12:46 2017 +0530

SOLR-10821: Remove mention of triggers and listeners

commit d7f7639fa1dbe3584f9f1dabb3663a5630b78fcb
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:06:19 2017 +0530

SOLR-10821: First cut of nav structure and overview page for autoscaling 
features in 7.0


> Write documentation for the autoscaling APIs and policy/preferences syntax 
> for Solr 7.0
> ---
>
> Key: SOLR-10821
> URL: https://issues.apache.org/jira/browse/SOLR-10821
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>  Labels: autoscaling
> Fix For: 7.0
>
>
> We need to document the following:
> # set-policy
> # set-cluster-preferences
> # set-cluster-policy
> # Autoscaling configuration read API
> # Autoscaling diagnostics API
> # policy and preference rule syntax



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10821) Write documentation for the autoscaling APIs and policy/preferences syntax for Solr 7.0

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10821:


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

SOLR-10821: Ref guide documentation for Autoscaling

Squashed commit of the following:

commit 4a8eb9491a1dc8099805656adec34197d0dab092
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 14:35:57 2017 +0530

SOLR-10821: Added note on using maxShardsPerNode along with a policy

commit 2a9bb140e12a60f93a6314647cf7d4fdc7f4fe60
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 14:04:48 2017 +0530

SOLR-10821: Use availability zone as an example instead of region

commit e5f0fe130ae7a269df7a3741c7ed7bf8b009c446
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:34:04 2017 +0530

SOLR-10821: Removed mention of triggers

commit 876276626a90849068d5fd893ba3660ac687
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:32:29 2017 +0530

SOLR-10821: Added policy specifications and examples

commit 245be9c44af7427fbde292120520f70ed54cadc9
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:12:09 2017 +0530

SOLR-10821: Added note on what happens when you change the 
policy/preferences

commit 202fe3324748fdfb12d5ffbba60bd69c6aa768cb
Author: Shalin Shekhar Mangar 
Date:   Thu Aug 3 20:32:10 2017 +0530

SOLR-10821: Added specification for policy attributes and operators

commit ccb6c559eb1ee080c5be06f1b471554d5038f699
Author: Shalin Shekhar Mangar 
Date:   Thu Aug 3 13:14:41 2017 +0530

SOLR-10821: Added documentation on how to completely remove cluster 
preferences and policies

commit 24e4827f2e482929546a6e0de447046f79e1510d
Author: Shalin Shekhar Mangar 
Date:   Tue Aug 1 10:00:15 2017 +0530

SOLR-10821: Added documentation for cluster preferences

commit d77c4786909e406ba194ef7144e1abd38c8bce83
Author: Cassandra Targett 
Date:   Mon Jul 31 13:19:30 2017 -0500

SOLR-10821: standardize "autoscaling" spelling & headings; other small copy 
edits

commit 4644e2963d8bb51aada46fc3c9180eec0bfdac12
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 17:15:29 2017 +0530

SOLR-10821: Added docs for the autoscaling write APIs

commit c7c0c86a2e3e15e6aa4e986a865e73e596cf275e
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 14:13:56 2017 +0530

Added docs for the autoscaling read and diagnostics API

commit 1fd011cce3a97eb51597d5ca09c02ca5038c769b
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:14:35 2017 +0530

SOLR-10821: Removed host/port and only show the path information in example

commit 9199fa3432f8c5ab4df35dbe776aeb586baa60ec
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:12:46 2017 +0530

SOLR-10821: Remove mention of triggers and listeners

commit d7f7639fa1dbe3584f9f1dabb3663a5630b78fcb
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:06:19 2017 +0530

SOLR-10821: First cut of nav structure and overview page for autoscaling 
features in 7.0


> Write documentation for the autoscaling APIs and policy/preferences syntax 
> for Solr 7.0
> ---
>
> Key: SOLR-10821
> URL: https://issues.apache.org/jira/browse/SOLR-10821
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>  Labels: autoscaling
> Fix For: 7.0
>
>
> We need to document the following:
> # set-policy
> # set-cluster-preferences
> # set-cluster-policy
> # Autoscaling configuration read API
> # Autoscaling diagnostics API
> # policy and preference rule syntax



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10821) Write documentation for the autoscaling APIs and policy/preferences syntax for Solr 7.0

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10821:


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

SOLR-10821: Ref guide documentation for Autoscaling

Squashed commit of the following:

commit 4a8eb9491a1dc8099805656adec34197d0dab092
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 14:35:57 2017 +0530

SOLR-10821: Added note on using maxShardsPerNode along with a policy

commit 2a9bb140e12a60f93a6314647cf7d4fdc7f4fe60
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 14:04:48 2017 +0530

SOLR-10821: Use availability zone as an example instead of region

commit e5f0fe130ae7a269df7a3741c7ed7bf8b009c446
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:34:04 2017 +0530

SOLR-10821: Removed mention of triggers

commit 876276626a90849068d5fd893ba3660ac687
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:32:29 2017 +0530

SOLR-10821: Added policy specifications and examples

commit 245be9c44af7427fbde292120520f70ed54cadc9
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:12:09 2017 +0530

SOLR-10821: Added note on what happens when you change the 
policy/preferences

commit 202fe3324748fdfb12d5ffbba60bd69c6aa768cb
Author: Shalin Shekhar Mangar 
Date:   Thu Aug 3 20:32:10 2017 +0530

SOLR-10821: Added specification for policy attributes and operators

commit ccb6c559eb1ee080c5be06f1b471554d5038f699
Author: Shalin Shekhar Mangar 
Date:   Thu Aug 3 13:14:41 2017 +0530

SOLR-10821: Added documentation on how to completely remove cluster 
preferences and policies

commit 24e4827f2e482929546a6e0de447046f79e1510d
Author: Shalin Shekhar Mangar 
Date:   Tue Aug 1 10:00:15 2017 +0530

SOLR-10821: Added documentation for cluster preferences

commit d77c4786909e406ba194ef7144e1abd38c8bce83
Author: Cassandra Targett 
Date:   Mon Jul 31 13:19:30 2017 -0500

SOLR-10821: standardize "autoscaling" spelling & headings; other small copy 
edits

commit 4644e2963d8bb51aada46fc3c9180eec0bfdac12
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 17:15:29 2017 +0530

SOLR-10821: Added docs for the autoscaling write APIs

commit c7c0c86a2e3e15e6aa4e986a865e73e596cf275e
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 14:13:56 2017 +0530

Added docs for the autoscaling read and diagnostics API

commit 1fd011cce3a97eb51597d5ca09c02ca5038c769b
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:14:35 2017 +0530

SOLR-10821: Removed host/port and only show the path information in example

commit 9199fa3432f8c5ab4df35dbe776aeb586baa60ec
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:12:46 2017 +0530

SOLR-10821: Remove mention of triggers and listeners

commit d7f7639fa1dbe3584f9f1dabb3663a5630b78fcb
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:06:19 2017 +0530

SOLR-10821: First cut of nav structure and overview page for autoscaling 
features in 7.0


> Write documentation for the autoscaling APIs and policy/preferences syntax 
> for Solr 7.0
> ---
>
> Key: SOLR-10821
> URL: https://issues.apache.org/jira/browse/SOLR-10821
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>  Labels: autoscaling
> Fix For: 7.0
>
>
> We need to document the following:
> # set-policy
> # set-cluster-preferences
> # set-cluster-policy
> # Autoscaling configuration read API
> # Autoscaling diagnostics API
> # policy and preference rule syntax



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10821) Write documentation for the autoscaling APIs and policy/preferences syntax for Solr 7.0

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10821:


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

SOLR-10821: Ref guide documentation for Autoscaling

Squashed commit of the following:

commit 4a8eb9491a1dc8099805656adec34197d0dab092
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 14:35:57 2017 +0530

SOLR-10821: Added note on using maxShardsPerNode along with a policy

commit 2a9bb140e12a60f93a6314647cf7d4fdc7f4fe60
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 14:04:48 2017 +0530

SOLR-10821: Use availability zone as an example instead of region

commit e5f0fe130ae7a269df7a3741c7ed7bf8b009c446
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:34:04 2017 +0530

SOLR-10821: Removed mention of triggers

commit 876276626a90849068d5fd893ba3660ac687
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:32:29 2017 +0530

SOLR-10821: Added policy specifications and examples

commit 245be9c44af7427fbde292120520f70ed54cadc9
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:12:09 2017 +0530

SOLR-10821: Added note on what happens when you change the 
policy/preferences

commit 202fe3324748fdfb12d5ffbba60bd69c6aa768cb
Author: Shalin Shekhar Mangar 
Date:   Thu Aug 3 20:32:10 2017 +0530

SOLR-10821: Added specification for policy attributes and operators

commit ccb6c559eb1ee080c5be06f1b471554d5038f699
Author: Shalin Shekhar Mangar 
Date:   Thu Aug 3 13:14:41 2017 +0530

SOLR-10821: Added documentation on how to completely remove cluster 
preferences and policies

commit 24e4827f2e482929546a6e0de447046f79e1510d
Author: Shalin Shekhar Mangar 
Date:   Tue Aug 1 10:00:15 2017 +0530

SOLR-10821: Added documentation for cluster preferences

commit d77c4786909e406ba194ef7144e1abd38c8bce83
Author: Cassandra Targett 
Date:   Mon Jul 31 13:19:30 2017 -0500

SOLR-10821: standardize "autoscaling" spelling & headings; other small copy 
edits

commit 4644e2963d8bb51aada46fc3c9180eec0bfdac12
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 17:15:29 2017 +0530

SOLR-10821: Added docs for the autoscaling write APIs

commit c7c0c86a2e3e15e6aa4e986a865e73e596cf275e
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 14:13:56 2017 +0530

Added docs for the autoscaling read and diagnostics API

commit 1fd011cce3a97eb51597d5ca09c02ca5038c769b
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:14:35 2017 +0530

SOLR-10821: Removed host/port and only show the path information in example

commit 9199fa3432f8c5ab4df35dbe776aeb586baa60ec
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:12:46 2017 +0530

SOLR-10821: Remove mention of triggers and listeners

commit d7f7639fa1dbe3584f9f1dabb3663a5630b78fcb
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:06:19 2017 +0530

SOLR-10821: First cut of nav structure and overview page for autoscaling 
features in 7.0


> Write documentation for the autoscaling APIs and policy/preferences syntax 
> for Solr 7.0
> ---
>
> Key: SOLR-10821
> URL: https://issues.apache.org/jira/browse/SOLR-10821
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>  Labels: autoscaling
> Fix For: 7.0
>
>
> We need to document the following:
> # set-policy
> # set-cluster-preferences
> # set-cluster-policy
> # Autoscaling configuration read API
> # Autoscaling diagnostics API
> # policy and preference rule syntax



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10821) Write documentation for the autoscaling APIs and policy/preferences syntax for Solr 7.0

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10821:


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

SOLR-10821: Ref guide documentation for Autoscaling

Squashed commit of the following:

commit 4a8eb9491a1dc8099805656adec34197d0dab092
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 14:35:57 2017 +0530

SOLR-10821: Added note on using maxShardsPerNode along with a policy

commit 2a9bb140e12a60f93a6314647cf7d4fdc7f4fe60
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 14:04:48 2017 +0530

SOLR-10821: Use availability zone as an example instead of region

commit e5f0fe130ae7a269df7a3741c7ed7bf8b009c446
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:34:04 2017 +0530

SOLR-10821: Removed mention of triggers

commit 876276626a90849068d5fd893ba3660ac687
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:32:29 2017 +0530

SOLR-10821: Added policy specifications and examples

commit 245be9c44af7427fbde292120520f70ed54cadc9
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:12:09 2017 +0530

SOLR-10821: Added note on what happens when you change the 
policy/preferences

commit 202fe3324748fdfb12d5ffbba60bd69c6aa768cb
Author: Shalin Shekhar Mangar 
Date:   Thu Aug 3 20:32:10 2017 +0530

SOLR-10821: Added specification for policy attributes and operators

commit ccb6c559eb1ee080c5be06f1b471554d5038f699
Author: Shalin Shekhar Mangar 
Date:   Thu Aug 3 13:14:41 2017 +0530

SOLR-10821: Added documentation on how to completely remove cluster 
preferences and policies

commit 24e4827f2e482929546a6e0de447046f79e1510d
Author: Shalin Shekhar Mangar 
Date:   Tue Aug 1 10:00:15 2017 +0530

SOLR-10821: Added documentation for cluster preferences

commit d77c4786909e406ba194ef7144e1abd38c8bce83
Author: Cassandra Targett 
Date:   Mon Jul 31 13:19:30 2017 -0500

SOLR-10821: standardize "autoscaling" spelling & headings; other small copy 
edits

commit 4644e2963d8bb51aada46fc3c9180eec0bfdac12
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 17:15:29 2017 +0530

SOLR-10821: Added docs for the autoscaling write APIs

commit c7c0c86a2e3e15e6aa4e986a865e73e596cf275e
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 14:13:56 2017 +0530

Added docs for the autoscaling read and diagnostics API

commit 1fd011cce3a97eb51597d5ca09c02ca5038c769b
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:14:35 2017 +0530

SOLR-10821: Removed host/port and only show the path information in example

commit 9199fa3432f8c5ab4df35dbe776aeb586baa60ec
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:12:46 2017 +0530

SOLR-10821: Remove mention of triggers and listeners

commit d7f7639fa1dbe3584f9f1dabb3663a5630b78fcb
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:06:19 2017 +0530

SOLR-10821: First cut of nav structure and overview page for autoscaling 
features in 7.0


> Write documentation for the autoscaling APIs and policy/preferences syntax 
> for Solr 7.0
> ---
>
> Key: SOLR-10821
> URL: https://issues.apache.org/jira/browse/SOLR-10821
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>  Labels: autoscaling
> Fix For: 7.0
>
>
> We need to document the following:
> # set-policy
> # set-cluster-preferences
> # set-cluster-policy
> # Autoscaling configuration read API
> # Autoscaling diagnostics API
> # policy and preference rule syntax



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10821) Write documentation for the autoscaling APIs and policy/preferences syntax for Solr 7.0

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10821:


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

SOLR-10821: Ref guide documentation for Autoscaling

Squashed commit of the following:

commit 4a8eb9491a1dc8099805656adec34197d0dab092
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 14:35:57 2017 +0530

SOLR-10821: Added note on using maxShardsPerNode along with a policy

commit 2a9bb140e12a60f93a6314647cf7d4fdc7f4fe60
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 14:04:48 2017 +0530

SOLR-10821: Use availability zone as an example instead of region

commit e5f0fe130ae7a269df7a3741c7ed7bf8b009c446
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:34:04 2017 +0530

SOLR-10821: Removed mention of triggers

commit 876276626a90849068d5fd893ba3660ac687
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:32:29 2017 +0530

SOLR-10821: Added policy specifications and examples

commit 245be9c44af7427fbde292120520f70ed54cadc9
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:12:09 2017 +0530

SOLR-10821: Added note on what happens when you change the 
policy/preferences

commit 202fe3324748fdfb12d5ffbba60bd69c6aa768cb
Author: Shalin Shekhar Mangar 
Date:   Thu Aug 3 20:32:10 2017 +0530

SOLR-10821: Added specification for policy attributes and operators

commit ccb6c559eb1ee080c5be06f1b471554d5038f699
Author: Shalin Shekhar Mangar 
Date:   Thu Aug 3 13:14:41 2017 +0530

SOLR-10821: Added documentation on how to completely remove cluster 
preferences and policies

commit 24e4827f2e482929546a6e0de447046f79e1510d
Author: Shalin Shekhar Mangar 
Date:   Tue Aug 1 10:00:15 2017 +0530

SOLR-10821: Added documentation for cluster preferences

commit d77c4786909e406ba194ef7144e1abd38c8bce83
Author: Cassandra Targett 
Date:   Mon Jul 31 13:19:30 2017 -0500

SOLR-10821: standardize "autoscaling" spelling & headings; other small copy 
edits

commit 4644e2963d8bb51aada46fc3c9180eec0bfdac12
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 17:15:29 2017 +0530

SOLR-10821: Added docs for the autoscaling write APIs

commit c7c0c86a2e3e15e6aa4e986a865e73e596cf275e
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 14:13:56 2017 +0530

Added docs for the autoscaling read and diagnostics API

commit 1fd011cce3a97eb51597d5ca09c02ca5038c769b
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:14:35 2017 +0530

SOLR-10821: Removed host/port and only show the path information in example

commit 9199fa3432f8c5ab4df35dbe776aeb586baa60ec
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:12:46 2017 +0530

SOLR-10821: Remove mention of triggers and listeners

commit d7f7639fa1dbe3584f9f1dabb3663a5630b78fcb
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:06:19 2017 +0530

SOLR-10821: First cut of nav structure and overview page for autoscaling 
features in 7.0


> Write documentation for the autoscaling APIs and policy/preferences syntax 
> for Solr 7.0
> ---
>
> Key: SOLR-10821
> URL: https://issues.apache.org/jira/browse/SOLR-10821
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>  Labels: autoscaling
> Fix For: 7.0
>
>
> We need to document the following:
> # set-policy
> # set-cluster-preferences
> # set-cluster-policy
> # Autoscaling configuration read API
> # Autoscaling diagnostics API
> # policy and preference rule syntax



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10821) Write documentation for the autoscaling APIs and policy/preferences syntax for Solr 7.0

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10821:


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

SOLR-10821: Ref guide documentation for Autoscaling

Squashed commit of the following:

commit 4a8eb9491a1dc8099805656adec34197d0dab092
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 14:35:57 2017 +0530

SOLR-10821: Added note on using maxShardsPerNode along with a policy

commit 2a9bb140e12a60f93a6314647cf7d4fdc7f4fe60
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 14:04:48 2017 +0530

SOLR-10821: Use availability zone as an example instead of region

commit e5f0fe130ae7a269df7a3741c7ed7bf8b009c446
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:34:04 2017 +0530

SOLR-10821: Removed mention of triggers

commit 876276626a90849068d5fd893ba3660ac687
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:32:29 2017 +0530

SOLR-10821: Added policy specifications and examples

commit 245be9c44af7427fbde292120520f70ed54cadc9
Author: Shalin Shekhar Mangar 
Date:   Fri Aug 4 08:12:09 2017 +0530

SOLR-10821: Added note on what happens when you change the 
policy/preferences

commit 202fe3324748fdfb12d5ffbba60bd69c6aa768cb
Author: Shalin Shekhar Mangar 
Date:   Thu Aug 3 20:32:10 2017 +0530

SOLR-10821: Added specification for policy attributes and operators

commit ccb6c559eb1ee080c5be06f1b471554d5038f699
Author: Shalin Shekhar Mangar 
Date:   Thu Aug 3 13:14:41 2017 +0530

SOLR-10821: Added documentation on how to completely remove cluster 
preferences and policies

commit 24e4827f2e482929546a6e0de447046f79e1510d
Author: Shalin Shekhar Mangar 
Date:   Tue Aug 1 10:00:15 2017 +0530

SOLR-10821: Added documentation for cluster preferences

commit d77c4786909e406ba194ef7144e1abd38c8bce83
Author: Cassandra Targett 
Date:   Mon Jul 31 13:19:30 2017 -0500

SOLR-10821: standardize "autoscaling" spelling & headings; other small copy 
edits

commit 4644e2963d8bb51aada46fc3c9180eec0bfdac12
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 17:15:29 2017 +0530

SOLR-10821: Added docs for the autoscaling write APIs

commit c7c0c86a2e3e15e6aa4e986a865e73e596cf275e
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 14:13:56 2017 +0530

Added docs for the autoscaling read and diagnostics API

commit 1fd011cce3a97eb51597d5ca09c02ca5038c769b
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:14:35 2017 +0530

SOLR-10821: Removed host/port and only show the path information in example

commit 9199fa3432f8c5ab4df35dbe776aeb586baa60ec
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:12:46 2017 +0530

SOLR-10821: Remove mention of triggers and listeners

commit d7f7639fa1dbe3584f9f1dabb3663a5630b78fcb
Author: Shalin Shekhar Mangar 
Date:   Mon Jul 31 13:06:19 2017 +0530

SOLR-10821: First cut of nav structure and overview page for autoscaling 
features in 7.0


> Write documentation for the autoscaling APIs and policy/preferences syntax 
> for Solr 7.0
> ---
>
> Key: SOLR-10821
> URL: https://issues.apache.org/jira/browse/SOLR-10821
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>  Labels: autoscaling
> Fix For: 7.0
>
>
> We need to document the following:
> # set-policy
> # set-cluster-preferences
> # set-cluster-policy
> # Autoscaling configuration read API
> # Autoscaling diagnostics API
> # policy and preference rule syntax



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11126) Node-level health check handler

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-11126:
--

# It is a bad idea to do {{updateLiveNodes}} on each invocation of the handler. 
I think the watcher is good enough. # Can you change the logging to debug level?
# We shouldn't be creating new handlers which aren't available in the v2 path 
anymore. Can you add a v2 equivalent for this handler?
# Can't we use this for non-cloud cases as well? Perhaps add a param 
(cloud=true?) to signal that the response should be OK only when running in 
cloud mode
# If we do the above, we can add a param for core and then deprecate the 
PingRequestHandler and eventually remove it.

> Node-level health check handler
> ---
>
> Key: SOLR-11126
> URL: https://issues.apache.org/jira/browse/SOLR-11126
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Fix For: master (8.0)
>
> Attachments: SOLR-11126.patch
>
>
> Solr used to have the PING handler at core level, but with SolrCloud, we are 
> missing a node level health check handler. It would be good to have. The API 
> would look like:
> * solr/admin/health (v1 API)
> * solr/node/health (v2 API)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11202) Implement a set-property command for AutoScaling API

[Shalin Shekhar Mangar (JIRA)]

Shalin Shekhar Mangar created SOLR-11202:


 Summary: Implement a set-property command for AutoScaling API
 Key: SOLR-11202
 URL: https://issues.apache.org/jira/browse/SOLR-11202
 Project: Solr
  Issue Type: Sub-task
  Security Level: Public (Default Security Level. Issues are Public)
  Components: AutoScaling, SolrCloud
Reporter: Shalin Shekhar Mangar
 Fix For: 7.1


The Autoscaling API should support a {{set-property}} command so that 
properties specific to autoscaling can be set/unset. Examples of such 
properties are:
# The scheduled delay between trigger invocations (currently defaults to 1s)
# Min time between actions (currently defaults to 5s)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11201) Implement trigger for arbitrary metrics

[Shalin Shekhar Mangar (JIRA)]

Shalin Shekhar Mangar created SOLR-11201:


 Summary: Implement trigger for arbitrary metrics
 Key: SOLR-11201
 URL: https://issues.apache.org/jira/browse/SOLR-11201
 Project: Solr
  Issue Type: Sub-task
  Security Level: Public (Default Security Level. Issues are Public)
  Components: AutoScaling, SolrCloud
Reporter: Shalin Shekhar Mangar
 Fix For: 7.2


It should be possible to set a trigger on any metrics exposed by the Metrics 
API using a threshold value. Supporting {{waitFor}} may not be possible or 
useful for all metrics. For those we will implement proper trigger support 
(such as searchRate) However, a naive implementation might be to just poll the 
value of the metric frequently and if it is consistently above the threshold, 
fire the trigger.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/203/
Java: 32bit/jdk1.8.0_141 -server -XX:+UseParallelGC

3 tests failed.
FAILED:  org.apache.lucene.index.TestStressNRT.test

Error Message:
MockDirectoryWrapper: cannot close: there are still 26 open files: {_5c.cfs=1, 
_5n.fdt=1, _5d.cfs=1, _5n_LuceneVarGapFixedInterval_0.doc=1, 
_5a_LuceneVarGapFixedInterval_0.doc=1, _5k_LuceneVarGapFixedInterval_0.doc=1, 
_5h_LuceneVarGapFixedInterval_0.doc=1, _5n_LuceneVarGapFixedInterval_0.tib=1, 
_5k_LuceneVarGapFixedInterval_0.tib=1, _5k.fdt=1, 
_5h_LuceneVarGapFixedInterval_0.tib=1, _5j.fdt=1, 
_5a_LuceneVarGapFixedInterval_0.tib=1, _57.cfs=1, _5a.fdt=1, _5i.fdt=1, 
_5h.fdt=1, _5i_LuceneVarGapFixedInterval_0.doc=1, _5g.cfs=1, _5p.cfs=1, 
_5j_LuceneVarGapFixedInterval_0.tib=1, _5u.cfs=1, _5o.cfs=1, 
_5j_LuceneVarGapFixedInterval_0.doc=1, _5i_LuceneVarGapFixedInterval_0.tib=1, 
_5e.cfs=1}

Stack Trace:
java.lang.RuntimeException: MockDirectoryWrapper: cannot close: there are still 
26 open files: {_5c.cfs=1, _5n.fdt=1, _5d.cfs=1, 
_5n_LuceneVarGapFixedInterval_0.doc=1, _5a_LuceneVarGapFixedInterval_0.doc=1, 
_5k_LuceneVarGapFixedInterval_0.doc=1, _5h_LuceneVarGapFixedInterval_0.doc=1, 
_5n_LuceneVarGapFixedInterval_0.tib=1, _5k_LuceneVarGapFixedInterval_0.tib=1, 
_5k.fdt=1, _5h_LuceneVarGapFixedInterval_0.tib=1, _5j.fdt=1, 
_5a_LuceneVarGapFixedInterval_0.tib=1, _57.cfs=1, _5a.fdt=1, _5i.fdt=1, 
_5h.fdt=1, _5i_LuceneVarGapFixedInterval_0.doc=1, _5g.cfs=1, _5p.cfs=1, 
_5j_LuceneVarGapFixedInterval_0.tib=1, _5u.cfs=1, _5o.cfs=1, 
_5j_LuceneVarGapFixedInterval_0.doc=1, _5i_LuceneVarGapFixedInterval_0.tib=1, 
_5e.cfs=1}
at 
org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:841)
at org.apache.lucene.index.TestStressNRT.test(TestStressNRT.java:398)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 

Re: ant precommit failing due to the solr dev guide

[Karl Wright]

I think you need to configure your git to checkout with native line endings
too to make it happen.

Karl


On Fri, Aug 4, 2017 at 8:13 PM, Steve Rowe  wrote:

> I have a Windows 10 box, I’ll see if I can reproduce.
>
> --
> Steve
> www.lucidworks.com
>
> > On Aug 4, 2017, at 5:02 AM, Uwe Schindler  wrote:
> >
> > Hi,
> >
> > yes you’re right: Jenkins and also my computer uses Unix linefeeds. So I
> think Steve’s script has a bug with newlines, although I think the regex is
> correct, but maybe it’s a side-effect of another regex (I don’t fully
> understand what the check should do!).
> >
> > Uwe
> >
> > -
> > Uwe Schindler
> > Achterdiek 19, D-28357 Bremen
> > http://www.thetaphi.de
> > eMail: u...@thetaphi.de
> >
> > From: Karl Wright [mailto:daddy...@gmail.com]
> > Sent: Friday, August 4, 2017 12:20 AM
> > To: Lucene/Solr dev 
> > Subject: Re: ant precommit failing due to the solr dev guide
> >
> > _144 also doesn't work for me.
> >
> > Looking at one of the .adoc files, the checkout has CR/LF at the end of
> the line, right after the "->" eg:
> >
> > 
> >
> > Is your git configured to checkout in native format?
> >
> > Karl
> >
> >
> > On Thu, Aug 3, 2017 at 5:42 PM, Karl Wright  wrote:
> >> 1.8.0_45 didn't work either; downloading _144 now (will take a while).
> >>
> >> Karl
> >>
> >>
> >> On Thu, Aug 3, 2017 at 5:09 PM, Karl Wright  wrote:
> >>> Thanks, I'll update.
> >>>
> >>> Karl
> >>>
> >>>
> >>> On Thu, Aug 3, 2017 at 12:30 PM, Uwe Schindler 
> wrote:
>  Oh, I think I know:
>  Java 8 update 5: Please update and try again. Such old versions had
> problems in String#split(), I don’t exactly remember but they were able to
> return some duplicate/empty tokens.
> 
>  Uwe
> 
>  -
>  Uwe Schindler
>  Achterdiek 19, D-28357 Bremen
>  http://www.thetaphi.de
>  eMail: u...@thetaphi.de
> 
>  From: Uwe Schindler [mailto:u...@thetaphi.de]
>  Sent: Thursday, August 3, 2017 6:28 PM
>  To: 'dev@lucene.apache.org' 
>  Subject: RE: ant precommit failing due to the solr dev guide
> 
>  I see no problems on windows jenkins and no problems on my local
> computer.
> 
>  Steve’s script has a regex for matching newlines, but this one looks
> correct. Would it be possible to check, how the newlines look like on your
> *.adoc files (e.g., post a hexdump)?
> 
>  Uwe
> 
>  -
>  Uwe Schindler
>  Achterdiek 19, D-28357 Bremen
>  http://www.thetaphi.de
>  eMail: u...@thetaphi.de
> 
>  From: Uwe Schindler [mailto:u...@thetaphi.de]
>  Sent: Thursday, August 3, 2017 5:33 PM
>  To: dev@lucene.apache.org
>  Subject: RE: ant precommit failing due to the solr dev guide
> 
>  Hi,
> 
>  Could be an newline issue in the groovy script… On windows some regex
> using \n or similar won’t match….
> 
>  I will check on my system.
> 
>  -
>  Uwe Schindler
>  Achterdiek 19, D-28357 Bremen
>  http://www.thetaphi.de
>  eMail: u...@thetaphi.de
> 
>  From: Karl Wright [mailto:daddy...@gmail.com]
>  Sent: Thursday, August 3, 2017 5:08 PM
>  To: Lucene/Solr dev 
>  Subject: Re: ant precommit failing due to the solr dev guide
> 
>  Sure -- this is Windows 10, an older JDK 8: C:\Program
> Files\Java\jdk1.8.0_05
> 
>  Anything else you are interested in?
> 
>  Karl
> 
> 
>  On Thu, Aug 3, 2017 at 11:04 AM, Steve Rowe  wrote:
> > Hi Karl,
> >
> > I looked at a couple of the errors, and they were all in "[source]"
> sections, which should be exempted from the “unescaped symbol” check, which
> is performed in the "-validate-source-patterns” target in the top-level
> build.xml.  The groovy method “checkForUnescapedSymbolSubstitutions” is
> where this “[source]” section exemption is supposed to happen.
> >
> > The “-validate-source-patterns” target depends on “resolve-groovy”,
> which pins the version, so I don’t think this is an issue of stale build
> tools.
> >
> > I don’t know how to reproduce the problem you’re seeing, so I’m not
> sure how to fix it.  Could you provide details on your platform?
> >
> > --
> > Steve
> > www.lucidworks.com
> >
> > > On Aug 3, 2017, at 10:20 AM, Karl Wright 
> wrote:
> > >
> > > 'When I run `ant precommit` on master on my machine, I don't get
> those
> > > errors. Is your branch out of date perhaps?'
> > >
> > > This is on master, and yes, my work area is up to date.
> > > Any other ideas?  Have the required versions of some of the build
> tools changed recently or something?
> > >
> > > Karl
> > >
> > >
> > >
> > > On Thu, Aug 3, 2017 at 9:18 AM, Cassandra Targett <
> 

Re: 7.0 Release Update

[Steve Rowe]

Oh, SOLR-11183 is also a Blocker, I just put 7.0 as fixVersion so that it will 
show up on the 7.0 Blockers JIRA query.

--
Steve
www.lucidworks.com

> On Aug 4, 2017, at 8:28 PM, Steve Rowe  wrote:
> 
> I’ve finished up addressing blockers.  The only remaining one is SOLR-10939: 
> JoinQParser gives incorrect results with numeric PointsFields, which Yonik is 
> working on.
> 
> --
> Steve
> www.lucidworks.com
> 
>> On Jul 25, 2017, at 7:02 PM, Steve Rowe  wrote:
>> 
>> I worked through the list of issues with the "numeric-tries-to-points” label 
>> and marked those as 7.0 Blocker that seemed reasonable, on the assumption 
>> that we should at a minimum give clear error messages for points 
>> non-compatibility.
>> 
>> If others don’t agree with the Blocker assessments I’ve made, I’m willing to 
>> discuss on the issues.
>> 
>> I plan on starting to work on the remaining 7.0 blockers now.  I would 
>> welcome assistance in clearing them up.
>> 
>> Here’s a JIRA query to see just the remaining 7.0 blockers, of which there 
>> are currently 12:
>> 
>> 
>> 
>> --
>> Steve
>> www.lucidworks.com
>> 
>>> On Jul 25, 2017, at 2:41 PM, Anshum Gupta  wrote:
>>> 
>>> I will *try* to get to it, but can't confirm. If someone else has a spare 
>>> cycle and can take it up before I get to it, please do.
>>> 
>>> -Anshum
>>> 
>>> On Tue, Jul 25, 2017 at 10:44 AM Cassandra Targett  
>>> wrote:
>>> I believe the only remaining blocker to SOLR-10803 (to mark all Trie*
>>> fields as deprecated) is SOLR-11023, which Hoss was working on. As he
>>> noted last night, he is off for vacation for the next 2 weeks. Is
>>> anyone else available to work on it so 7.0 isn't stalled for 2+ more
>>> weeks?
>>> 
>>> Now would also be a good time to look over any other bugs with
>>> PointFields and make a case if any should be considered blockers for
>>> 7.0. I think they all share a label:
>>> https://issues.apache.org/jira/issues/?jql=status%20%3D%20Open%20AND%20labels%20%3D%20numeric-tries-to-points
>>> 
>>> On Tue, Jul 11, 2017 at 4:59 PM, Chris Hostetter
>>>  wrote:
 
 : So, my overall point is that if A) we agree that we want to deprecate
 : Trie* numeric fields, and B) we want to hold up the 7.0 release until
 : that's done, it's more than just updating the example schemas if we
 : want to ensure a quality app for users. We still need to fix the tests
 : and also fix bugs that are going to be really painful for users. And
 : to get all that done soon, we definitely need some more volunteers.
 
 I've beefed up the description of SOLR-10807 with tips on how people can
 help out...
 
 https://issues.apache.org/jira/browse/SOLR-10807
 
 
 
 -Hoss
 http://www.lucidworks.com/
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>> 
>> 
> 


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

[jira] [Updated] (SOLR-11183) why call the API end point /v2 will there ever be a /v3

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-11183:
--
Fix Version/s: 7.0

> why call the API end point /v2 will there ever be a /v3
> ---
>
> Key: SOLR-11183
> URL: https://issues.apache.org/jira/browse/SOLR-11183
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.0
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Blocker
> Fix For: 7.0
>
>
> The mail thread
> http://lucene.472066.n3.nabble.com/v2-API-will-there-ever-be-a-v3-td4340901.html
> it makes sense to prefix v2 APIs at {{/api}} intsead of {{/v2}} if we never 
> plan to have a {{/v3}}
> In principle, it makes total sense
> The challenge is that it takes a while to change the code and tests to make 
> to work. Should this be a blocker and should we hold up the release



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: 7.0 Release Update

[Steve Rowe]

I’ve finished up addressing blockers.  The only remaining one is SOLR-10939: 
JoinQParser gives incorrect results with numeric PointsFields, which Yonik is 
working on.

--
Steve
www.lucidworks.com

> On Jul 25, 2017, at 7:02 PM, Steve Rowe  wrote:
> 
> I worked through the list of issues with the "numeric-tries-to-points” label 
> and marked those as 7.0 Blocker that seemed reasonable, on the assumption 
> that we should at a minimum give clear error messages for points 
> non-compatibility.
> 
> If others don’t agree with the Blocker assessments I’ve made, I’m willing to 
> discuss on the issues.
> 
> I plan on starting to work on the remaining 7.0 blockers now.  I would 
> welcome assistance in clearing them up.
> 
> Here’s a JIRA query to see just the remaining 7.0 blockers, of which there 
> are currently 12:
> 
> 
> 
> --
> Steve
> www.lucidworks.com
> 
>> On Jul 25, 2017, at 2:41 PM, Anshum Gupta  wrote:
>> 
>> I will *try* to get to it, but can't confirm. If someone else has a spare 
>> cycle and can take it up before I get to it, please do.
>> 
>> -Anshum
>> 
>> On Tue, Jul 25, 2017 at 10:44 AM Cassandra Targett  
>> wrote:
>> I believe the only remaining blocker to SOLR-10803 (to mark all Trie*
>> fields as deprecated) is SOLR-11023, which Hoss was working on. As he
>> noted last night, he is off for vacation for the next 2 weeks. Is
>> anyone else available to work on it so 7.0 isn't stalled for 2+ more
>> weeks?
>> 
>> Now would also be a good time to look over any other bugs with
>> PointFields and make a case if any should be considered blockers for
>> 7.0. I think they all share a label:
>> https://issues.apache.org/jira/issues/?jql=status%20%3D%20Open%20AND%20labels%20%3D%20numeric-tries-to-points
>> 
>> On Tue, Jul 11, 2017 at 4:59 PM, Chris Hostetter
>>  wrote:
>>> 
>>> : So, my overall point is that if A) we agree that we want to deprecate
>>> : Trie* numeric fields, and B) we want to hold up the 7.0 release until
>>> : that's done, it's more than just updating the example schemas if we
>>> : want to ensure a quality app for users. We still need to fix the tests
>>> : and also fix bugs that are going to be really painful for users. And
>>> : to get all that done soon, we definitely need some more volunteers.
>>> 
>>> I've beefed up the description of SOLR-10807 with tips on how people can
>>> help out...
>>> 
>>> https://issues.apache.org/jira/browse/SOLR-10807
>>> 
>>> 
>>> 
>>> -Hoss
>>> http://www.lucidworks.com/
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 
> 


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

Re: ant precommit failing due to the solr dev guide

[Steve Rowe]

I have a Windows 10 box, I’ll see if I can reproduce.

--
Steve
www.lucidworks.com

> On Aug 4, 2017, at 5:02 AM, Uwe Schindler  wrote:
> 
> Hi,
>  
> yes you’re right: Jenkins and also my computer uses Unix linefeeds. So I 
> think Steve’s script has a bug with newlines, although I think the regex is 
> correct, but maybe it’s a side-effect of another regex (I don’t fully 
> understand what the check should do!).
>  
> Uwe
>  
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>  
> From: Karl Wright [mailto:daddy...@gmail.com] 
> Sent: Friday, August 4, 2017 12:20 AM
> To: Lucene/Solr dev 
> Subject: Re: ant precommit failing due to the solr dev guide
>  
> _144 also doesn't work for me.
>  
> Looking at one of the .adoc files, the checkout has CR/LF at the end of the 
> line, right after the "->" eg:
> 
> 
>  
> Is your git configured to checkout in native format?
>  
> Karl
>  
>  
> On Thu, Aug 3, 2017 at 5:42 PM, Karl Wright  wrote:
>> 1.8.0_45 didn't work either; downloading _144 now (will take a while).
>>  
>> Karl
>>  
>>  
>> On Thu, Aug 3, 2017 at 5:09 PM, Karl Wright  wrote:
>>> Thanks, I'll update.
>>>  
>>> Karl
>>>  
>>>  
>>> On Thu, Aug 3, 2017 at 12:30 PM, Uwe Schindler  wrote:
 Oh, I think I know:
 Java 8 update 5: Please update and try again. Such old versions had 
 problems in String#split(), I don’t exactly remember but they were able to 
 return some duplicate/empty tokens.
  
 Uwe
  
 -
 Uwe Schindler
 Achterdiek 19, D-28357 Bremen
 http://www.thetaphi.de
 eMail: u...@thetaphi.de
  
 From: Uwe Schindler [mailto:u...@thetaphi.de] 
 Sent: Thursday, August 3, 2017 6:28 PM
 To: 'dev@lucene.apache.org' 
 Subject: RE: ant precommit failing due to the solr dev guide
  
 I see no problems on windows jenkins and no problems on my local computer.
  
 Steve’s script has a regex for matching newlines, but this one looks 
 correct. Would it be possible to check, how the newlines look like on your 
 *.adoc files (e.g., post a hexdump)?
  
 Uwe
  
 -
 Uwe Schindler
 Achterdiek 19, D-28357 Bremen
 http://www.thetaphi.de
 eMail: u...@thetaphi.de
  
 From: Uwe Schindler [mailto:u...@thetaphi.de] 
 Sent: Thursday, August 3, 2017 5:33 PM
 To: dev@lucene.apache.org
 Subject: RE: ant precommit failing due to the solr dev guide
  
 Hi,
  
 Could be an newline issue in the groovy script… On windows some regex 
 using \n or similar won’t match….
  
 I will check on my system.
  
 -
 Uwe Schindler
 Achterdiek 19, D-28357 Bremen
 http://www.thetaphi.de
 eMail: u...@thetaphi.de
  
 From: Karl Wright [mailto:daddy...@gmail.com] 
 Sent: Thursday, August 3, 2017 5:08 PM
 To: Lucene/Solr dev 
 Subject: Re: ant precommit failing due to the solr dev guide
  
 Sure -- this is Windows 10, an older JDK 8: C:\Program 
 Files\Java\jdk1.8.0_05
  
 Anything else you are interested in?
  
 Karl
  
  
 On Thu, Aug 3, 2017 at 11:04 AM, Steve Rowe  wrote:
> Hi Karl,
> 
> I looked at a couple of the errors, and they were all in "[source]" 
> sections, which should be exempted from the “unescaped symbol” check, 
> which is performed in the "-validate-source-patterns” target in the 
> top-level build.xml.  The groovy method 
> “checkForUnescapedSymbolSubstitutions” is where this “[source]” section 
> exemption is supposed to happen.
> 
> The “-validate-source-patterns” target depends on “resolve-groovy”, which 
> pins the version, so I don’t think this is an issue of stale build tools.
> 
> I don’t know how to reproduce the problem you’re seeing, so I’m not sure 
> how to fix it.  Could you provide details on your platform?
> 
> --
> Steve
> www.lucidworks.com
> 
> > On Aug 3, 2017, at 10:20 AM, Karl Wright  wrote:
> >
> > 'When I run `ant precommit` on master on my machine, I don't get those
> > errors. Is your branch out of date perhaps?'
> >
> > This is on master, and yes, my work area is up to date.
> > Any other ideas?  Have the required versions of some of the build tools 
> > changed recently or something?
> >
> > Karl
> >
> >
> >
> > On Thu, Aug 3, 2017 at 9:18 AM, Cassandra Targett 
> >  wrote:
> > Those are documentation-lint validations added via SOLR-10883 for the
> > Solr Ref Guide (committed weeks ago).
> >
> > When I run `ant precommit` on master on my machine, I don't get those
> > errors. Is your branch out of date perhaps?
> >

[jira] [Commented] (SOLR-10803) Mark all Trie/LegacyNumeric based fields @deprecated in Solr7

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10803:


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

SOLR-10803: Mark all Trie/LegacyNumeric based fields @deprecated in Solr7.


> Mark all Trie/LegacyNumeric based fields @deprecated in Solr7
> -
>
> Key: SOLR-10803
> URL: https://issues.apache.org/jira/browse/SOLR-10803
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Adrien Grand
>Assignee: Steve Rowe
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-10803.patch
>
>
> If we want to be able to remove support for legacy numerics from Solr in 8.0, 
> we need to forbid the use of Trie*Field in indices that are created on or 
> after 7.0.
> 
> At a minimum, we can mark them deprecated and plan to remove them in 8.0, so 
> the usual compatibility rules will apply.
> at a later date we can (in theory) provide a conversion tool -- or convert 
> automatically -- to point fields



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-10803) Mark all Trie/LegacyNumeric based fields @deprecated in Solr7

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-10803.
---
   Resolution: Fixed
Fix Version/s: 7.1
   master (8.0)

> Mark all Trie/LegacyNumeric based fields @deprecated in Solr7
> -
>
> Key: SOLR-10803
> URL: https://issues.apache.org/jira/browse/SOLR-10803
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Adrien Grand
>Assignee: Steve Rowe
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-10803.patch
>
>
> If we want to be able to remove support for legacy numerics from Solr in 8.0, 
> we need to forbid the use of Trie*Field in indices that are created on or 
> after 7.0.
> 
> At a minimum, we can mark them deprecated and plan to remove them in 8.0, so 
> the usual compatibility rules will apply.
> at a later date we can (in theory) provide a conversion tool -- or convert 
> automatically -- to point fields



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10803) Mark all Trie/LegacyNumeric based fields @deprecated in Solr7

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10803:


Commit 6aeae1c0a87d587cec94622fc582510745db4cec in lucene-solr's branch 
refs/heads/branch_7_0 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6aeae1c ]

SOLR-10803: Mark all Trie/LegacyNumeric based fields @deprecated in Solr7.


> Mark all Trie/LegacyNumeric based fields @deprecated in Solr7
> -
>
> Key: SOLR-10803
> URL: https://issues.apache.org/jira/browse/SOLR-10803
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Adrien Grand
>Assignee: Steve Rowe
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-10803.patch
>
>
> If we want to be able to remove support for legacy numerics from Solr in 8.0, 
> we need to forbid the use of Trie*Field in indices that are created on or 
> after 7.0.
> 
> At a minimum, we can mark them deprecated and plan to remove them in 8.0, so 
> the usual compatibility rules will apply.
> at a later date we can (in theory) provide a conversion tool -- or convert 
> automatically -- to point fields



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10803) Mark all Trie/LegacyNumeric based fields @deprecated in Solr7

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10803:


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

SOLR-10803: Mark all Trie/LegacyNumeric based fields @deprecated in Solr7.


> Mark all Trie/LegacyNumeric based fields @deprecated in Solr7
> -
>
> Key: SOLR-10803
> URL: https://issues.apache.org/jira/browse/SOLR-10803
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Adrien Grand
>Assignee: Steve Rowe
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-10803.patch
>
>
> If we want to be able to remove support for legacy numerics from Solr in 8.0, 
> we need to forbid the use of Trie*Field in indices that are created on or 
> after 7.0.
> 
> At a minimum, we can mark them deprecated and plan to remove them in 8.0, so 
> the usual compatibility rules will apply.
> at a later date we can (in theory) provide a conversion tool -- or convert 
> automatically -- to point fields



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (SOLR-10803) Mark all Trie/LegacyNumeric based fields @deprecated in Solr7

[Steve Rowe (JIRA)]

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

Steve Rowe reassigned SOLR-10803:
-

Assignee: Steve Rowe

> Mark all Trie/LegacyNumeric based fields @deprecated in Solr7
> -
>
> Key: SOLR-10803
> URL: https://issues.apache.org/jira/browse/SOLR-10803
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Adrien Grand
>Assignee: Steve Rowe
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0
>
> Attachments: SOLR-10803.patch
>
>
> If we want to be able to remove support for legacy numerics from Solr in 8.0, 
> we need to forbid the use of Trie*Field in indices that are created on or 
> after 7.0.
> 
> At a minimum, we can mark them deprecated and plan to remove them in 8.0, so 
> the usual compatibility rules will apply.
> at a later date we can (in theory) provide a conversion tool -- or convert 
> automatically -- to point fields



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10803) Mark all Trie/LegacyNumeric based fields @deprecated in Solr7

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-10803:
--
Attachment: SOLR-10803.patch

Patch deprecating all Trie-related classes.

Committing shortly.

> Mark all Trie/LegacyNumeric based fields @deprecated in Solr7
> -
>
> Key: SOLR-10803
> URL: https://issues.apache.org/jira/browse/SOLR-10803
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Adrien Grand
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0
>
> Attachments: SOLR-10803.patch
>
>
> If we want to be able to remove support for legacy numerics from Solr in 8.0, 
> we need to forbid the use of Trie*Field in indices that are created on or 
> after 7.0.
> 
> At a minimum, we can mark them deprecated and plan to remove them in 8.0, so 
> the usual compatibility rules will apply.
> at a later date we can (in theory) provide a conversion tool -- or convert 
> automatically -- to point fields



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-11023) Need SortedNumerics/Points version of EnumField

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-11023.
---
   Resolution: Fixed
Fix Version/s: 7.1
   master (8.0)

> Need SortedNumerics/Points version of EnumField
> ---
>
> Key: SOLR-11023
> URL: https://issues.apache.org/jira/browse/SOLR-11023
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Steve Rowe
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-11023.patch, SOLR-11023.patch, SOLR-11023.patch, 
> SOLR-11023.patch, SOLR-11023.patch, SOLR-11023.patch
>
>
> although it's not a subclass of TrieField, EnumField does use 
> "LegacyIntField" to index the int value associated with each of the enum 
> values, in addition to using SortedSetDocValuesField when {{docValues="true" 
> multivalued="true"}}.
> I have no idea if Points would be better/worse then Terms for low cardinality 
> usecases like EnumField, but either way we should think about a new variant 
> of EnumField that doesn't depend on 
> LegacyIntField/LegacyNumericUtils.intToPrefixCoded and uses 
> SortedNumericDocValues.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11023) Need SortedNumerics/Points version of EnumField

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11023:


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

SOLR-11023: Added EnumFieldType, a non-Trie-based version of EnumField, and 
deprecated EnumField in favor of EnumFieldType.


> Need SortedNumerics/Points version of EnumField
> ---
>
> Key: SOLR-11023
> URL: https://issues.apache.org/jira/browse/SOLR-11023
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Steve Rowe
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0
>
> Attachments: SOLR-11023.patch, SOLR-11023.patch, SOLR-11023.patch, 
> SOLR-11023.patch, SOLR-11023.patch, SOLR-11023.patch
>
>
> although it's not a subclass of TrieField, EnumField does use 
> "LegacyIntField" to index the int value associated with each of the enum 
> values, in addition to using SortedSetDocValuesField when {{docValues="true" 
> multivalued="true"}}.
> I have no idea if Points would be better/worse then Terms for low cardinality 
> usecases like EnumField, but either way we should think about a new variant 
> of EnumField that doesn't depend on 
> LegacyIntField/LegacyNumericUtils.intToPrefixCoded and uses 
> SortedNumericDocValues.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11023) Need SortedNumerics/Points version of EnumField

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11023:


Commit 41f6ae55ba2cbd01848130f2be3db2cea48e34a4 in lucene-solr's branch 
refs/heads/branch_7_0 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=41f6ae5 ]

SOLR-11023: Added EnumFieldType, a non-Trie-based version of EnumField, and 
deprecated EnumField in favor of EnumFieldType.

 Conflicts:
solr/core/src/java/org/apache/solr/schema/EnumField.java
solr/core/src/test/org/apache/solr/schema/EnumFieldTest.java


> Need SortedNumerics/Points version of EnumField
> ---
>
> Key: SOLR-11023
> URL: https://issues.apache.org/jira/browse/SOLR-11023
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Steve Rowe
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0
>
> Attachments: SOLR-11023.patch, SOLR-11023.patch, SOLR-11023.patch, 
> SOLR-11023.patch, SOLR-11023.patch, SOLR-11023.patch
>
>
> although it's not a subclass of TrieField, EnumField does use 
> "LegacyIntField" to index the int value associated with each of the enum 
> values, in addition to using SortedSetDocValuesField when {{docValues="true" 
> multivalued="true"}}.
> I have no idea if Points would be better/worse then Terms for low cardinality 
> usecases like EnumField, but either way we should think about a new variant 
> of EnumField that doesn't depend on 
> LegacyIntField/LegacyNumericUtils.intToPrefixCoded and uses 
> SortedNumericDocValues.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11023) Need SortedNumerics/Points version of EnumField

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11023:


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

SOLR-11023: Added EnumFieldType, a non-Trie-based version of EnumField, and 
deprecated EnumField in favor of EnumFieldType.


> Need SortedNumerics/Points version of EnumField
> ---
>
> Key: SOLR-11023
> URL: https://issues.apache.org/jira/browse/SOLR-11023
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Steve Rowe
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0
>
> Attachments: SOLR-11023.patch, SOLR-11023.patch, SOLR-11023.patch, 
> SOLR-11023.patch, SOLR-11023.patch, SOLR-11023.patch
>
>
> although it's not a subclass of TrieField, EnumField does use 
> "LegacyIntField" to index the int value associated with each of the enum 
> values, in addition to using SortedSetDocValuesField when {{docValues="true" 
> multivalued="true"}}.
> I have no idea if Points would be better/worse then Terms for low cardinality 
> usecases like EnumField, but either way we should think about a new variant 
> of EnumField that doesn't depend on 
> LegacyIntField/LegacyNumericUtils.intToPrefixCoded and uses 
> SortedNumericDocValues.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11023) Need SortedNumerics/Points version of EnumField

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-11023:
--
Attachment: SOLR-11023.patch

Final patch, including some precommit, test, and doc fixes.

100 beasting iterations of EnumFieldTest all passed, as did precommit and all 
Solr tests.

Committing shortly.

> Need SortedNumerics/Points version of EnumField
> ---
>
> Key: SOLR-11023
> URL: https://issues.apache.org/jira/browse/SOLR-11023
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Steve Rowe
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0
>
> Attachments: SOLR-11023.patch, SOLR-11023.patch, SOLR-11023.patch, 
> SOLR-11023.patch, SOLR-11023.patch, SOLR-11023.patch
>
>
> although it's not a subclass of TrieField, EnumField does use 
> "LegacyIntField" to index the int value associated with each of the enum 
> values, in addition to using SortedSetDocValuesField when {{docValues="true" 
> multivalued="true"}}.
> I have no idea if Points would be better/worse then Terms for low cardinality 
> usecases like EnumField, but either way we should think about a new variant 
> of EnumField that doesn't depend on 
> LegacyIntField/LegacyNumericUtils.intToPrefixCoded and uses 
> SortedNumericDocValues.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10796) TestPointFields: increase randomized testing of non-trivial values

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10796:
---

My Jenkins found a reproducing seed for a failure in one of the beefed up tests 
- I'll investigate:

{noformat}
Checking out Revision d09d8bcaa9cc7e1f58646028f4389e11958dd93f 
(refs/remotes/origin/branch_7x)
[...]
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestPointFields 
-Dtests.method=testDoublePointFieldRangeFacet -Dtests.seed=3F61066AF1671866 
-Dtests.slow=true -Dtests.locale=es-SV -Dtests.timezone=America/Cambridge_Bay 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
   [junit4] ERROR   0.01s J4  | TestPointFields.testDoublePointFieldRangeFacet 
<<<
   [junit4]> Throwable #1: java.lang.NumberFormatException
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([3F61066AF1671866:603562685C3CEB8D]:0)
   [junit4]>at java.math.BigDecimal.(BigDecimal.java:494)
   [junit4]>at java.math.BigDecimal.(BigDecimal.java:383)
   [junit4]>at java.math.BigDecimal.(BigDecimal.java:806)
   [junit4]>at java.math.BigDecimal.valueOf(BigDecimal.java:1274)
   [junit4]>at 
org.apache.solr.schema.TestPointFields.testDoublePointFieldRangeFacet(TestPointFields.java:618)
   [junit4]>at java.lang.Thread.run(Thread.java:745)
[...]
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
{id=PostingsFormat(name=Memory)}, 
docValues:{foo_p_f_ni_dv_ns=DocValuesFormat(name=Lucene70), 
foo_p_f_ni_dv_ns_mv=DocValuesFormat(name=Lucene70), 
number_p_dt_dv_ns=DocValuesFormat(name=Direct), 
foo_p_d_ni_dv_ns_mv=DocValuesFormat(name=Asserting), 
foo_p_i_ni_dv_ns=DocValuesFormat(name=Direct), 
number_p_f_ni_mv_dv_smf=DocValuesFormat(name=Asserting), 
number_p_dt_ni_mv_dv_sml=DocValuesFormat(name=Lucene70), 
number_p_i_dv_ns=DocValuesFormat(name=Lucene70), 
number_p_l_ni_dv=DocValuesFormat(name=Memory), 
number_p_f_dv=DocValuesFormat(name=Direct), 
number_p_l_dv_ns=DocValuesFormat(name=Memory), 
foo_p_l_ni_dv_ns=DocValuesFormat(name=Lucene70), 
number_p_dt_ni_mv_dv=DocValuesFormat(name=Memory), 
number_p_l_dv_sml=DocValuesFormat(name=Asserting), 
number_p_i_dv_smf=DocValuesFormat(name=Memory), 
number_p_d_ni_ns_dv=DocValuesFormat(name=Direct), 
number_p_dt_ni_dv_ns_mv=DocValuesFormat(name=Direct), 
number_p_i_ni_dv_ns_mv=DocValuesFormat(name=Asserting), 
number_p_f_dv_smf=DocValuesFormat(name=Lucene70), 
number_p_l_ni_dv_ns=DocValuesFormat(name=Memory), 
number_p_l_dv_smf=DocValuesFormat(name=Lucene70), 
number_p_d_ni_mv_dv_sml=DocValuesFormat(name=Lucene70), 
number_p_f_ni_dv_ns_mv=DocValuesFormat(name=Direct), 
number_p_d_dv_smf=DocValuesFormat(name=Lucene70), 
number_p_f_ni_mv_dv_sml=DocValuesFormat(name=Lucene70), 
number_p_d_ni_mv_dv_smf=DocValuesFormat(name=Asserting), 
number_p_dt_ni_dv=DocValuesFormat(name=Direct), 
number_p_f_dv_ns_mv=DocValuesFormat(name=Direct), 
number_p_l_dv_ns_mv=DocValuesFormat(name=Memory), 
number_p_dt_mv_dv_sml=DocValuesFormat(name=Lucene70), 
number_p_l_ni_ns_dv=DocValuesFormat(name=Direct), 
number_p_i_ni_dv_ns=DocValuesFormat(name=Asserting), 
number_p_i_dv_sml=DocValuesFormat(name=Direct), 
number_p_f_ni_ns_dv=DocValuesFormat(name=Memory), 
foo_p_d_ni_dv_ns=DocValuesFormat(name=Asserting), 
number_p_dt_dv_sml=DocValuesFormat(name=Lucene70), 
number_p_dt_dv_smf=DocValuesFormat(name=Asserting), 
number_p_i_mv_dv=DocValuesFormat(name=Asserting), 
number_p_l_ni_dv_ns_mv=DocValuesFormat(name=Memory), 
number_p_d_ni_dv=DocValuesFormat(name=Memory), 
number_p_dt_ni_dv_sml=DocValuesFormat(name=Asserting), 
number_p_d_mv_dv_smf=DocValuesFormat(name=Asserting), 
number_p_d_ni_dv_smf=DocValuesFormat(name=Asserting), 
number_p_dt_ni_dv_smf=DocValuesFormat(name=Lucene70), 
foo_p_l_ni_dv_ns_mv=DocValuesFormat(name=Lucene70), 
number_p_d_mv_dv_sml=DocValuesFormat(name=Lucene70), 
number_p_dt_ni_ns_dv=DocValuesFormat(name=Memory), 
number_p_dt_mv_dv_smf=DocValuesFormat(name=Asserting), 
foo_p_i_ni_dv_ns_mv=DocValuesFormat(name=Direct), 
number_p_l_mv_dv=DocValuesFormat(name=Direct), 
number_p_d_ni_dv_sml=DocValuesFormat(name=Lucene70), 
number_p_i_ni_mv_dv=DocValuesFormat(name=Lucene70), 
number_p_f_mv_dv=DocValuesFormat(name=Memory), 
number_p_f_ni_mv_dv=DocValuesFormat(name=Memory), 
number_p_i_mv_dv_smf=DocValuesFormat(name=Memory), 
foo_p_dt_ni_dv_ns_mv=DocValuesFormat(name=Asserting), 
number_p_l_ni_mv_dv=DocValuesFormat(name=Direct), 
number_p_l_ni_dv_sml=DocValuesFormat(name=Asserting), 
number_p_d_dv=DocValuesFormat(name=Memory), 
number_p_i_ni_mv_dv_smf=DocValuesFormat(name=Direct), 
number_p_d_dv_ns=DocValuesFormat(name=Memory), 
number_p_l_ni_dv_smf=DocValuesFormat(name=Lucene70), 
number_p_i_ni_mv_dv_sml=DocValuesFormat(name=Memory), 
number_p_dt_dv_ns_mv=DocValuesFormat(name=Direct), 
number_p_l_dv=DocValuesFormat(name=Memory), 

[jira] [Commented] (SOLR-7344) Allow Jetty thread pool limits while still avoiding distributed deadlock.

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-7344:
-

Hi Hrishikesh,

Okay reading a bit more would this comment of yours accurately describe the 
current state of work?

{quote}OK. Here is the first cut implementation of this idea 
https://github.com/hgadre/servletrequest-scheduler
This is just the core logic for this approach. We still need to implement solr 
specific policy to use it. I am thinking to partition the worker pool such that 
we identify following types of requests,
Internal_Querying
Internal_Indexing
External_Local (viz. requests sent by external clients such that a given 
collection is available on this server).
External_Forwarded (viz. requests sent by external clients such that a given 
collection is not available on this server).
Admin requests 
I think the tricky part here is to identify the appropriate thread-pool size 
for each of the partition. Please take a look and let me know any 
feedback.{quote}

So this Jira would add a filter , then SOLR-7683  and SOLR-7684 would actually 
make use of it?

> Allow Jetty thread pool limits while still avoiding distributed deadlock.
> -
>
> Key: SOLR-7344
> URL: https://issues.apache.org/jira/browse/SOLR-7344
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Mark Miller
> Attachments: SOLR-7344.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11190) GraphQuery not working if field has only docValues

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-11190:
--

Hi Karthik,

In this patch if a field has both docValues=true and indexed=true then we'd 
still end up using DocValuesTermsQuery ? 

I think we should prefer TermInSetQuery if we have indexed=true enabled?

> GraphQuery not working if field has only docValues
> --
>
> Key: SOLR-11190
> URL: https://issues.apache.org/jira/browse/SOLR-11190
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 6.6
>Reporter: Karthik Ramachandran
>Assignee: Karthik Ramachandran
> Attachments: SOLR-11190.patch
>
>
> Graph traversal is not working if field has only docValues since the 
> construction of leaf or parent node queries uses only TermQuery.
> \\ \\
> {code:xml|title=managed-schema|borderStyle=solid}
> 
>  docValues="true" />
>  docValues="true" />
>  docValues="true" />
>  docValues="true" />
> id
> 
>  precisionStep="0" positionIncrementGap="0"/>
> 
> {code}
> {code}
> curl -XPOST -H 'Content-Type: application/json' 
> 'http://localhost:8983/solr/graph/update' --data-binary ' {
>  "add" : { "doc" : { "id" : "1", "name" : "Root1" } },
>  "add" : { "doc" : { "id" : "2", "name" : "Root2" } },
>  "add" : { "doc" : { "id" : "3", "name" : "Root3" } },
>  "add" : { "doc" : { "id" : "11", "parentid" : "1", "name" : "Root1 Child1" } 
> },
>  "add" : { "doc" : { "id" : "12", "parentid" : "1", "name" : "Root1 Child2" } 
> },
>  "add" : { "doc" : { "id" : "13", "parentid" : "1", "name" : "Root1 Child3" } 
> },
>  "add" : { "doc" : { "id" : "21", "parentid" : "2", "name" : "Root2 Child1" } 
> },
>  "add" : { "doc" : { "id" : "22", "parentid" : "2", "name" : "Root2 Child2" } 
> },
>  "add" : { "doc" : { "id" : "121", "parentid" : "12", "name" : "Root12 
> Child1" } },
>  "add" : { "doc" : { "id" : "122", "parentid" : "12", "name" : "Root12 
> Child2" } },
>  "add" : { "doc" : { "id" : "131", "parentid" : "13", "name" : "Root13 
> Child1" } },
>  "commit" : {}
> }'
> {code}
> {code}
> http://localhost:8983/solr/graph/select?q=*:*={!graph from=parentid 
> to=id}id:1
> or
> http://localhost:8983/solr/graph/select?q=*:*={!graph from=id 
> to=parentid}id:122
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-11198) downconfig downloads empty file as folder

[Isabelle Giguere (JIRA)]

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

Isabelle Giguere edited comment on SOLR-11198 at 8/4/17 10:41 PM:
--

My command (on Windows)

> java -cp "C:\Path\to\lib\*" org.apache.solr.cloud.ZkCLI -cmd downconfig 
> -zkhost localhost:2181/ot/solr -confname otif_en -confdir 
> "C:\Path\to\output\otif_en"

Note that I cannot reproduce the issue using Zookeeper 3.4.6 and Solr 5.4.1, 
with exactly the same command.
We just upgraded to Zookeeper 3.4.10 and Solr 6.6.0

I'll try  Zookeeper 3.4.6 with Solr 6.6.0, and Zookeeper 3.4.10 with Solr 
5.4.1, if it can help narrow things down.


Update : 
No matter what version of Zookeeper, -cmd downconfig :
- Solr 6.6.0 outputs the empty synonyms.txt file as a folder.
- Solr 5.4.1 outputs the empty synonyms.txt file as a file.


was (Author: igiguere):
My command (on Windows)

> java -cp "C:\Path\to\lib\*" org.apache.solr.cloud.ZkCLI -cmd downconfig 
> -zkhost localhost:2181/ot/solr -confname otif_en -confdir 
> "C:\Path\to\output\otif_en"

Note that I cannot reproduce the issue using Zookeeper 3.4.6 and Solr 5.4.1, 
with exactly the same command.
We just upgraded to Zookeeper 3.4.10 and Solr 6.6.0

I'll try  Zookeeper 3.4.6 with Solr 6.6.0, and Zookeeper 3.4.10 with Solr 
5.4.1, if it can help narrow things down.

> downconfig downloads empty file as folder
> -
>
> Key: SOLR-11198
> URL: https://issues.apache.org/jira/browse/SOLR-11198
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
> Environment: Windows 7
>Reporter: Isabelle Giguere
>Priority: Minor
>
> With Solr 6.6.0, when downloading a config from Zookeeper (3.4.10), if a file 
> is empty, it is downloaded as a folder (on Windows, at least).
> A Zookeeper browser (Eclipse: Zookeeper Explorer) shows the file as a file, 
> however, in ZK.
> Noticed because we keep an empty synonyms.txt file in the Solr config 
> provided with our product, in case a client would want to use it.
> The workaround is simple, since the file allows comments: just add a comment, 
> so it is not empty.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-7344) Allow Jetty thread pool limits while still avoiding distributed deadlock.

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-7344:
-

Hi Hrishikesh,

Would 
https://github.com/hgadre/servletrequest-scheduler/blob/master/src/main/java/org/apache/solr/scheduling/RequestSchedulerFilter.java
 be the best place to start looking at the current state of work ?

> Allow Jetty thread pool limits while still avoiding distributed deadlock.
> -
>
> Key: SOLR-7344
> URL: https://issues.apache.org/jira/browse/SOLR-7344
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Mark Miller
> Attachments: SOLR-7344.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7655) Speed up geo-distance queries that match most documents

[Maciej Zasada (JIRA)]

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

Maciej Zasada commented on LUCENE-7655:
---

Hi [~jpountz],
I'd like to contribute this improvement. I opened a PR on GH, would you mind 
taking a look? Unit tests pass, I also ran luceneutil spatial test: {code} 
perf.IndexAndSearchOpenStreetMaps -points -distance {code}
and after tuning queries to match ~75% of the docs, I did see ~ +20% QPS gain. 
Let me know if I can do anything more. Cheers!

> Speed up geo-distance queries that match most documents
> ---
>
> Key: LUCENE-7655
> URL: https://issues.apache.org/jira/browse/LUCENE-7655
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
>
> I think the same optimization that was applied in LUCENE-7641 would also work 
> with geo-distance queries?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11198) downconfig downloads empty file as folder

[Isabelle Giguere (JIRA)]

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

Isabelle Giguere commented on SOLR-11198:
-

My command (on Windows)

> java -cp "C:\Path\to\lib\*" org.apache.solr.cloud.ZkCLI -cmd downconfig 
> -zkhost localhost:2181/ot/solr -confname otif_en -confdir 
> "C:\Path\to\output\otif_en"

Note that I cannot reproduce the issue using Zookeeper 3.4.6 and Solr 5.4.1, 
with exactly the same command.
We just upgraded to Zookeeper 3.4.10 and Solr 6.6.0

I'll try  Zookeeper 3.4.6 with Solr 6.6.0, and Zookeeper 3.4.10 with Solr 
5.4.1, if it can help narrow things down.

> downconfig downloads empty file as folder
> -
>
> Key: SOLR-11198
> URL: https://issues.apache.org/jira/browse/SOLR-11198
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
> Environment: Windows 7
>Reporter: Isabelle Giguere
>Priority: Minor
>
> With Solr 6.6.0, when downloading a config from Zookeeper (3.4.10), if a file 
> is empty, it is downloaded as a folder (on Windows, at least).
> A Zookeeper browser (Eclipse: Zookeeper Explorer) shows the file as a file, 
> however, in ZK.
> Noticed because we keep an empty synonyms.txt file in the Solr config 
> provided with our product, in case a client would want to use it.
> The workaround is simple, since the file allows comments: just add a comment, 
> so it is not empty.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-7.0-Linux (32bit/jdk1.8.0_141) - Build # 145 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.0-Linux/145/
Java: 32bit/jdk1.8.0_141 -client -XX:+UseParallelGC

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

Error Message:
2 threads leaked from SUITE scope at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 1) 
Thread[id=15047, name=jetty-launcher-3160-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:530)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505)   
 2) Thread[id=15045, name=jetty-launcher-3160-thread-2-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:530)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 2 threads leaked from SUITE 
scope at org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 
   1) Thread[id=15047, name=jetty-launcher-3160-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
at 

[jira] [Commented] (SOLR-11190) GraphQuery not working if field has only docValues

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-11190:
---

GitHub user mrkarthik opened a pull request:

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

SOLR-11190: Fix GraphQuery not working if field has only docValues



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mrkarthik/lucene-solr jira/SOLR-11190

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/227.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #227


commit b0d568f58d408fd5bbbac5f0e88c795ac3a163ad
Author: Karthik Ramachandran 
Date:   2017-08-04T21:34:02Z

SOLR-11190: Fix GraphQuery not working if field has only docValues




> GraphQuery not working if field has only docValues
> --
>
> Key: SOLR-11190
> URL: https://issues.apache.org/jira/browse/SOLR-11190
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 6.6
>Reporter: Karthik Ramachandran
>Assignee: Karthik Ramachandran
> Attachments: SOLR-11190.patch
>
>
> Graph traversal is not working if field has only docValues since the 
> construction of leaf or parent node queries uses only TermQuery.
> \\ \\
> {code:xml|title=managed-schema|borderStyle=solid}
> 
>  docValues="true" />
>  docValues="true" />
>  docValues="true" />
>  docValues="true" />
> id
> 
>  precisionStep="0" positionIncrementGap="0"/>
> 
> {code}
> {code}
> curl -XPOST -H 'Content-Type: application/json' 
> 'http://localhost:8983/solr/graph/update' --data-binary ' {
>  "add" : { "doc" : { "id" : "1", "name" : "Root1" } },
>  "add" : { "doc" : { "id" : "2", "name" : "Root2" } },
>  "add" : { "doc" : { "id" : "3", "name" : "Root3" } },
>  "add" : { "doc" : { "id" : "11", "parentid" : "1", "name" : "Root1 Child1" } 
> },
>  "add" : { "doc" : { "id" : "12", "parentid" : "1", "name" : "Root1 Child2" } 
> },
>  "add" : { "doc" : { "id" : "13", "parentid" : "1", "name" : "Root1 Child3" } 
> },
>  "add" : { "doc" : { "id" : "21", "parentid" : "2", "name" : "Root2 Child1" } 
> },
>  "add" : { "doc" : { "id" : "22", "parentid" : "2", "name" : "Root2 Child2" } 
> },
>  "add" : { "doc" : { "id" : "121", "parentid" : "12", "name" : "Root12 
> Child1" } },
>  "add" : { "doc" : { "id" : "122", "parentid" : "12", "name" : "Root12 
> Child2" } },
>  "add" : { "doc" : { "id" : "131", "parentid" : "13", "name" : "Root13 
> Child1" } },
>  "commit" : {}
> }'
> {code}
> {code}
> http://localhost:8983/solr/graph/select?q=*:*={!graph from=parentid 
> to=id}id:1
> or
> http://localhost:8983/solr/graph/select?q=*:*={!graph from=id 
> to=parentid}id:122
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[GitHub] lucene-solr pull request #227: SOLR-11190: Fix GraphQuery not working if fie...

[mrkarthik]

GitHub user mrkarthik opened a pull request:

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

SOLR-11190: Fix GraphQuery not working if field has only docValues



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mrkarthik/lucene-solr jira/SOLR-11190

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/227.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #227


commit b0d568f58d408fd5bbbac5f0e88c795ac3a163ad
Author: Karthik Ramachandran 
Date:   2017-08-04T21:34:02Z

SOLR-11190: Fix GraphQuery not working if field has only docValues




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Updated] (SOLR-11200) provide a config to enable disable ConcurrentMergeSchedule.doAutoIOThrottle

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-11200:
-
Issue Type: Improvement  (was: Bug)

> provide a config to enable disable ConcurrentMergeSchedule.doAutoIOThrottle
> ---
>
> Key: SOLR-11200
> URL: https://issues.apache.org/jira/browse/SOLR-11200
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Nawab Zada Asad iqbal
>Priority: Minor
>
> This config can be useful while bulk indexing. Lucene introduced it 
> https://issues.apache.org/jira/browse/LUCENE-6119 . 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11200) provide a config to enable disable ConcurrentMergeSchedule.doAutoIOThrottle

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-11200:
-
Affects Version/s: (was: 6.6)

> provide a config to enable disable ConcurrentMergeSchedule.doAutoIOThrottle
> ---
>
> Key: SOLR-11200
> URL: https://issues.apache.org/jira/browse/SOLR-11200
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Nawab Zada Asad iqbal
>Priority: Minor
>
> This config can be useful while bulk indexing. Lucene introduced it 
> https://issues.apache.org/jira/browse/LUCENE-6119 . 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11200) provide a config to enable disable ConcurrentMergeSchedule.doAutoIOThrottle

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-11200:
--

Hi Nawab,

I would start by looking at {{SolrIndexConfig#buildMergeScheduler}}

We can provide an argument like "mergeThrottle"  boolean variable and use that 
to create the merge policy 

It will be also nice if Solr can INFO log when merges are being throttled. 
Currently it's only available via infostream logging but that prints a lot more 
information. 

> provide a config to enable disable ConcurrentMergeSchedule.doAutoIOThrottle
> ---
>
> Key: SOLR-11200
> URL: https://issues.apache.org/jira/browse/SOLR-11200
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: Nawab Zada Asad iqbal
>Priority: Minor
>
> This config can be useful while bulk indexing. Lucene introduced it 
> https://issues.apache.org/jira/browse/LUCENE-6119 . 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11198) downconfig downloads empty file as folder

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-11198:
--

We need a bit more info on how you are downloading the config - the command you 
are using - to be sure there isn't an error somewhere in there. I tried it on 
my machine (Mac), and it worked fine, so we want to be clear how you are using 
it so we can reproduce.

Here's the command I used: {{./bin/solr zk cp 
zk:/configs/gettingstarted/stopwords.txt file:/Desktop -z localhost:9983}} 
(When I did this, I modified the default stopwords.txt so it is empty).


> downconfig downloads empty file as folder
> -
>
> Key: SOLR-11198
> URL: https://issues.apache.org/jira/browse/SOLR-11198
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
> Environment: Windows 7
>Reporter: Isabelle Giguere
>Priority: Minor
>
> With Solr 6.6.0, when downloading a config from Zookeeper (3.4.10), if a file 
> is empty, it is downloaded as a folder (on Windows, at least).
> A Zookeeper browser (Eclipse: Zookeeper Explorer) shows the file as a file, 
> however, in ZK.
> Noticed because we keep an empty synonyms.txt file in the Solr config 
> provided with our product, in case a client would want to use it.
> The workaround is simple, since the file allows comments: just add a comment, 
> so it is not empty.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11190) GraphQuery not working if field has only docValues

[Karthik Ramachandran (JIRA)]

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

Karthik Ramachandran updated SOLR-11190:

Attachment: SOLR-11190.patch

> GraphQuery not working if field has only docValues
> --
>
> Key: SOLR-11190
> URL: https://issues.apache.org/jira/browse/SOLR-11190
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 6.6
>Reporter: Karthik Ramachandran
>Assignee: Karthik Ramachandran
> Attachments: SOLR-11190.patch
>
>
> Graph traversal is not working if field has only docValues since the 
> construction of leaf or parent node queries uses only TermQuery.
> \\ \\
> {code:xml|title=managed-schema|borderStyle=solid}
> 
>  docValues="true" />
>  docValues="true" />
>  docValues="true" />
>  docValues="true" />
> id
> 
>  precisionStep="0" positionIncrementGap="0"/>
> 
> {code}
> {code}
> curl -XPOST -H 'Content-Type: application/json' 
> 'http://localhost:8983/solr/graph/update' --data-binary ' {
>  "add" : { "doc" : { "id" : "1", "name" : "Root1" } },
>  "add" : { "doc" : { "id" : "2", "name" : "Root2" } },
>  "add" : { "doc" : { "id" : "3", "name" : "Root3" } },
>  "add" : { "doc" : { "id" : "11", "parentid" : "1", "name" : "Root1 Child1" } 
> },
>  "add" : { "doc" : { "id" : "12", "parentid" : "1", "name" : "Root1 Child2" } 
> },
>  "add" : { "doc" : { "id" : "13", "parentid" : "1", "name" : "Root1 Child3" } 
> },
>  "add" : { "doc" : { "id" : "21", "parentid" : "2", "name" : "Root2 Child1" } 
> },
>  "add" : { "doc" : { "id" : "22", "parentid" : "2", "name" : "Root2 Child2" } 
> },
>  "add" : { "doc" : { "id" : "121", "parentid" : "12", "name" : "Root12 
> Child1" } },
>  "add" : { "doc" : { "id" : "122", "parentid" : "12", "name" : "Root12 
> Child2" } },
>  "add" : { "doc" : { "id" : "131", "parentid" : "13", "name" : "Root13 
> Child1" } },
>  "commit" : {}
> }'
> {code}
> {code}
> http://localhost:8983/solr/graph/select?q=*:*={!graph from=parentid 
> to=id}id:1
> or
> http://localhost:8983/solr/graph/select?q=*:*={!graph from=id 
> to=parentid}id:122
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11200) provide a config to enable disable ConcurrentMergeSchedule.doAutoIOThrottle

[Nawab Zada Asad iqbal (JIRA)]

Nawab Zada Asad iqbal created SOLR-11200:


 Summary: provide a config to enable disable 
ConcurrentMergeSchedule.doAutoIOThrottle
 Key: SOLR-11200
 URL: https://issues.apache.org/jira/browse/SOLR-11200
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.6
Reporter: Nawab Zada Asad iqbal
Priority: Minor


This config can be useful while bulk indexing. Lucene introduced it 
https://issues.apache.org/jira/browse/LUCENE-6119 . 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (SOLR-11190) GraphQuery not working if field has only docValues

[Karthik Ramachandran (JIRA)]

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

Karthik Ramachandran reassigned SOLR-11190:
---

Assignee: Karthik Ramachandran

> GraphQuery not working if field has only docValues
> --
>
> Key: SOLR-11190
> URL: https://issues.apache.org/jira/browse/SOLR-11190
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 6.6
>Reporter: Karthik Ramachandran
>Assignee: Karthik Ramachandran
>
> Graph traversal is not working if field has only docValues since the 
> construction of leaf or parent node queries uses only TermQuery.
> \\ \\
> {code:xml|title=managed-schema|borderStyle=solid}
> 
>  docValues="true" />
>  docValues="true" />
>  docValues="true" />
>  docValues="true" />
> id
> 
>  precisionStep="0" positionIncrementGap="0"/>
> 
> {code}
> {code}
> curl -XPOST -H 'Content-Type: application/json' 
> 'http://localhost:8983/solr/graph/update' --data-binary ' {
>  "add" : { "doc" : { "id" : "1", "name" : "Root1" } },
>  "add" : { "doc" : { "id" : "2", "name" : "Root2" } },
>  "add" : { "doc" : { "id" : "3", "name" : "Root3" } },
>  "add" : { "doc" : { "id" : "11", "parentid" : "1", "name" : "Root1 Child1" } 
> },
>  "add" : { "doc" : { "id" : "12", "parentid" : "1", "name" : "Root1 Child2" } 
> },
>  "add" : { "doc" : { "id" : "13", "parentid" : "1", "name" : "Root1 Child3" } 
> },
>  "add" : { "doc" : { "id" : "21", "parentid" : "2", "name" : "Root2 Child1" } 
> },
>  "add" : { "doc" : { "id" : "22", "parentid" : "2", "name" : "Root2 Child2" } 
> },
>  "add" : { "doc" : { "id" : "121", "parentid" : "12", "name" : "Root12 
> Child1" } },
>  "add" : { "doc" : { "id" : "122", "parentid" : "12", "name" : "Root12 
> Child2" } },
>  "add" : { "doc" : { "id" : "131", "parentid" : "13", "name" : "Root13 
> Child1" } },
>  "commit" : {}
> }'
> {code}
> {code}
> http://localhost:8983/solr/graph/select?q=*:*={!graph from=parentid 
> to=id}id:1
> or
> http://localhost:8983/solr/graph/select?q=*:*={!graph from=id 
> to=parentid}id:122
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11023) Need SortedNumerics/Points version of EnumField

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-11023:
--
Attachment: SOLR-11023.patch

Hopefully final patch, including a CHANGES entry and ref guide updates.

I'll commit once precommit, a 100-iteration beasting of EnumFieldTest, and all 
Solr tests pass.

> Need SortedNumerics/Points version of EnumField
> ---
>
> Key: SOLR-11023
> URL: https://issues.apache.org/jira/browse/SOLR-11023
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Steve Rowe
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0
>
> Attachments: SOLR-11023.patch, SOLR-11023.patch, SOLR-11023.patch, 
> SOLR-11023.patch, SOLR-11023.patch
>
>
> although it's not a subclass of TrieField, EnumField does use 
> "LegacyIntField" to index the int value associated with each of the enum 
> values, in addition to using SortedSetDocValuesField when {{docValues="true" 
> multivalued="true"}}.
> I have no idea if Points would be better/worse then Terms for low cardinality 
> usecases like EnumField, but either way we should think about a new variant 
> of EnumField that doesn't depend on 
> LegacyIntField/LegacyNumericUtils.intToPrefixCoded and uses 
> SortedNumericDocValues.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11199) Support OR queries in the Payload Score Parser

[Erik Hatcher (JIRA)]

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

Erik Hatcher commented on SOLR-11199:
-

Yeah, the SpanNearQuery approach was really just the first pass until something 
better and more flexible came along to create SpanQuery's from some (likely) 
payloaded terms.

> Support OR queries in the Payload Score Parser 
> ---
>
> Key: SOLR-11199
> URL: https://issues.apache.org/jira/browse/SOLR-11199
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>
> PayloadScoreQParserPlugin always creates a SpanNearQuery. 
> In my use-case I want to be able to do an OR query and then use a sum 
> function to sum up all the scores.
> So if the PayloadScoreQParserPlugin supported an operator param which could 
> be used to pick between phrase searches ( the default currently ) OR and ANDs 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20259/
Java: 64bit/jdk1.8.0_141 -XX:+UseCompressedOops -XX:+UseParallelGC

3 tests failed.
FAILED:  
org.apache.lucene.search.suggest.document.TestSuggestField.testRealisticKeys

Error Message:
input automaton is too large: 1001

Stack Trace:
java.lang.IllegalArgumentException: input automaton is too large: 1001
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1298)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 
org.apache.lucene.util.automaton.Operations.topoSortStatesRecurse(Operations.java:1306)
at 

[jira] [Created] (SOLR-11199) Support OR queries in the Payload Score Parser

[Varun Thacker (JIRA)]

Varun Thacker created SOLR-11199:


 Summary: Support OR queries in the Payload Score Parser 
 Key: SOLR-11199
 URL: https://issues.apache.org/jira/browse/SOLR-11199
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Varun Thacker


PayloadScoreQParserPlugin always creates a SpanNearQuery. 

In my use-case I want to be able to do an OR query and then use a sum function 
to sum up all the scores.

So if the PayloadScoreQParserPlugin supported an operator param which could be 
used to pick between phrase searches ( the default currently ) OR and ANDs 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7655) Speed up geo-distance queries that match most documents

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LUCENE-7655:


GitHub user mzasada opened a pull request:

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

LUCENE-7655 Speed up geo-distance queries that match most documents



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mzasada/lucene-solr LUCENE-7655

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/226.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #226


commit cea3578fc58cb72873a93702b93f0aefb8040b4a
Author: mzasada 
Date:   2017-08-02T13:58:30Z

LUCENE-7655 Speed up geo-distance queries that match most documents




> Speed up geo-distance queries that match most documents
> ---
>
> Key: LUCENE-7655
> URL: https://issues.apache.org/jira/browse/LUCENE-7655
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
>
> I think the same optimization that was applied in LUCENE-7641 would also work 
> with geo-distance queries?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[GitHub] lucene-solr pull request #226: LUCENE-7655 Speed up geo-distance queries tha...

[mzasada]

GitHub user mzasada opened a pull request:

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

LUCENE-7655 Speed up geo-distance queries that match most documents



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mzasada/lucene-solr LUCENE-7655

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/226.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #226


commit cea3578fc58cb72873a93702b93f0aefb8040b4a
Author: mzasada 
Date:   2017-08-02T13:58:30Z

LUCENE-7655 Speed up geo-distance queries that match most documents




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Created] (SOLR-11198) downconfig downloads empty file as folder

[Isabelle Giguere (JIRA)]

Isabelle Giguere created SOLR-11198:
---

 Summary: downconfig downloads empty file as folder
 Key: SOLR-11198
 URL: https://issues.apache.org/jira/browse/SOLR-11198
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.6
 Environment: Windows 7
Reporter: Isabelle Giguere
Priority: Minor


With Solr 6.6.0, when downloading a config from Zookeeper (3.4.10), if a file 
is empty, it is downloaded as a folder (on Windows, at least).

A Zookeeper browser (Eclipse: Zookeeper Explorer) shows the file as a file, 
however, in ZK.

Noticed because we keep an empty synonyms.txt file in the Solr config provided 
with our product, in case a client would want to use it.

The workaround is simple, since the file allows comments: just add a comment, 
so it is not empty.




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11197) support force-kill opt-out

[Omar Abdelnabi (JIRA)]

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

Omar Abdelnabi updated SOLR-11197:
--
Attachment: SOLR-11197.patch

Attaching a patch

> support force-kill opt-out
> --
>
> Key: SOLR-11197
> URL: https://issues.apache.org/jira/browse/SOLR-11197
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Omar Abdelnabi
>Priority: Minor
> Attachments: SOLR-11197.patch
>
>
> Currently once the SOLR_STOP_WAIT time is up then the solr process gets 
> forcefully killed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11197) support force-kill opt-out

[Omar Abdelnabi (JIRA)]

Omar Abdelnabi created SOLR-11197:
-

 Summary: support force-kill opt-out
 Key: SOLR-11197
 URL: https://issues.apache.org/jira/browse/SOLR-11197
 Project: Solr
  Issue Type: Task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Omar Abdelnabi
Priority: Minor


Currently once the SOLR_STOP_WAIT time is up then the solr process gets 
forcefully killed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_141) - Build # 20258 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20258/
Java: 32bit/jdk1.8.0_141 -client -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.handler.TestSolrConfigHandlerConcurrent.test

Error Message:


Stack Trace:
java.lang.NullPointerException
at 
__randomizedtesting.SeedInfo.seed([99B0A63C28CEF9AF:11E499E686329457]:0)
at 
org.apache.solr.handler.TestSolrConfigHandlerConcurrent.test(TestSolrConfigHandlerConcurrent.java:109)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 11069 lines...]
   [junit4] Suite: org.apache.solr.handler.TestSolrConfigHandlerConcurrent
   [junit4]   2> 204164 INFO  

[jira] [Commented] (SOLR-11196) Solr 6.5.0 consuming entire Heap suddenly while working smoothly on Solr 6.1.0

[Walter Underwood (JIRA)]

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

Walter Underwood commented on SOLR-11196:
-

Ah, missed that openSearcher was false.

This host is named production-solr-master, so it might be master-slave. 

> Solr 6.5.0 consuming entire Heap suddenly while working smoothly on Solr 6.1.0
> --
>
> Key: SOLR-11196
> URL: https://issues.apache.org/jira/browse/SOLR-11196
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.5, 6.6
>Reporter: Amit
>Priority: Critical
>
> Please note, this issue does not occurs on Solr-6.1.0 while the same occurs 
> on Solr-6.5.0 and above. To fix this we had to move back to Solr-6.1.0 
> version.
> We have been hit by a Solr Behavior in production which we are unable to 
> debug. To start with here are the configurations for solr:
> Solr Version: 6.5, Master with 1 Slave of the same configuration as mentioned 
> below.
> *JVM Config:*
>   
> {code:java}
>  -Xms2048m
>  -Xmx4096m
>  -XX:+ParallelRefProcEnabled
>  -XX:+UseCMSInitiatingOccupancyOnly
>  -XX:CMSInitiatingOccupancyFraction=50
> {code}
> Rest all are default values.
> *Solr Config:*
>  
> {code:java}
>
>   
>   {solr.autoCommit.maxTime:30}
>   false
> 
> 
> 
>   {solr.autoSoftCommit.maxTime:90}
> 
> 
> 
>   1024
>autowarmCount="0" />
>autowarmCount="0" />
>autowarmCount="0" />
>initialSize="0" autowarmCount="10" regenerator="solr.NoOpRegenerator" />
>   true
>   20
>   ${solr.query.max.docs:40}
>   
>   false
>   2
> 
> {code}
> *The Host (AWS) configurations are:*
> RAM: 7.65GB
> Cores: 4
> Now, our solr works perfectly fine for hours and sometimes for days but 
> sometimes suddenly memory jumps up and the GC kicks in causing long big 
> pauses with not much to recover. We are seeing this happening most often when 
> one or multiple segments gets added or deleted post a hard commit. It doesn't 
> matter how many documents got indexed. The images attached shows that just 1 
> document was indexed, causing an addition of one segment and it all got 
> messed up till we restarted the Solr.
> Here are the images from NewRelic and Sematext (Kindly click on the links to 
> view):
> [JVM Heap Memory Image | https://i.stack.imgur.com/9dQAy.png]
> [1 Document and 1 Segment addition Image | 
> https://i.stack.imgur.com/6N4FC.png]
> Update: Here is the JMap output when SOLR last died, we have now increased 
> the JVM memory to xmx of 12GB:
>  
> {code:java}
>  num #instances #bytes  class name
>   --
>   1:  11210921 1076248416  
> org.apache.lucene.codecs.lucene50.Lucene50PostingsFormat$IntBlockTermState
>   2:  10623486  934866768  [Lorg.apache.lucene.index.TermState;
>   3:  15567646  475873992  [B
>   4:  10623485  424939400  
> org.apache.lucene.search.spans.SpanTermQuery$SpanTermWeight
>   5:  15508972  372215328  org.apache.lucene.util.BytesRef
>   6:  15485834  371660016  org.apache.lucene.index.Term
>   7:  15477679  371464296  
> org.apache.lucene.search.spans.SpanTermQuery
>   8:  10623486  339951552  org.apache.lucene.index.TermContext
>   9:   1516724  150564320  [Ljava.lang.Object;
>  10:724486   50948800  [C
>  11:   1528110   36674640  java.util.ArrayList
>  12:849884   27196288  
> org.apache.lucene.search.spans.SpanNearQuery
>  13:582008   23280320  
> org.apache.lucene.search.spans.SpanNearQuery$SpanNearWeight
>  14:481601   23116848  org.apache.lucene.document.FieldType
>  15:623073   19938336  org.apache.lucene.document.StoredField
>  16:721649   17319576  java.lang.String
>  17: 327297329640  [J
>  18: 146435788376  [F
> {code}
> The load on Solr is not much - max it goes to 2000 requests per minute. The 
> indexing load can sometimes be in burst but most of the time its pretty low. 
> But as mentioned above sometimes even a single document indexing can put solr 
> into tizzy and sometimes it just works like a charm.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-11196) Solr 6.5.0 consuming entire Heap suddenly while working smoothly on Solr 6.1.0

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-11196.
---
Resolution: Invalid

> Solr 6.5.0 consuming entire Heap suddenly while working smoothly on Solr 6.1.0
> --
>
> Key: SOLR-11196
> URL: https://issues.apache.org/jira/browse/SOLR-11196
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.5, 6.6
>Reporter: Amit
>Priority: Critical
>
> Please note, this issue does not occurs on Solr-6.1.0 while the same occurs 
> on Solr-6.5.0 and above. To fix this we had to move back to Solr-6.1.0 
> version.
> We have been hit by a Solr Behavior in production which we are unable to 
> debug. To start with here are the configurations for solr:
> Solr Version: 6.5, Master with 1 Slave of the same configuration as mentioned 
> below.
> *JVM Config:*
>   
> {code:java}
>  -Xms2048m
>  -Xmx4096m
>  -XX:+ParallelRefProcEnabled
>  -XX:+UseCMSInitiatingOccupancyOnly
>  -XX:CMSInitiatingOccupancyFraction=50
> {code}
> Rest all are default values.
> *Solr Config:*
>  
> {code:java}
>
>   
>   {solr.autoCommit.maxTime:30}
>   false
> 
> 
> 
>   {solr.autoSoftCommit.maxTime:90}
> 
> 
> 
>   1024
>autowarmCount="0" />
>autowarmCount="0" />
>autowarmCount="0" />
>initialSize="0" autowarmCount="10" regenerator="solr.NoOpRegenerator" />
>   true
>   20
>   ${solr.query.max.docs:40}
>   
>   false
>   2
> 
> {code}
> *The Host (AWS) configurations are:*
> RAM: 7.65GB
> Cores: 4
> Now, our solr works perfectly fine for hours and sometimes for days but 
> sometimes suddenly memory jumps up and the GC kicks in causing long big 
> pauses with not much to recover. We are seeing this happening most often when 
> one or multiple segments gets added or deleted post a hard commit. It doesn't 
> matter how many documents got indexed. The images attached shows that just 1 
> document was indexed, causing an addition of one segment and it all got 
> messed up till we restarted the Solr.
> Here are the images from NewRelic and Sematext (Kindly click on the links to 
> view):
> [JVM Heap Memory Image | https://i.stack.imgur.com/9dQAy.png]
> [1 Document and 1 Segment addition Image | 
> https://i.stack.imgur.com/6N4FC.png]
> Update: Here is the JMap output when SOLR last died, we have now increased 
> the JVM memory to xmx of 12GB:
>  
> {code:java}
>  num #instances #bytes  class name
>   --
>   1:  11210921 1076248416  
> org.apache.lucene.codecs.lucene50.Lucene50PostingsFormat$IntBlockTermState
>   2:  10623486  934866768  [Lorg.apache.lucene.index.TermState;
>   3:  15567646  475873992  [B
>   4:  10623485  424939400  
> org.apache.lucene.search.spans.SpanTermQuery$SpanTermWeight
>   5:  15508972  372215328  org.apache.lucene.util.BytesRef
>   6:  15485834  371660016  org.apache.lucene.index.Term
>   7:  15477679  371464296  
> org.apache.lucene.search.spans.SpanTermQuery
>   8:  10623486  339951552  org.apache.lucene.index.TermContext
>   9:   1516724  150564320  [Ljava.lang.Object;
>  10:724486   50948800  [C
>  11:   1528110   36674640  java.util.ArrayList
>  12:849884   27196288  
> org.apache.lucene.search.spans.SpanNearQuery
>  13:582008   23280320  
> org.apache.lucene.search.spans.SpanNearQuery$SpanNearWeight
>  14:481601   23116848  org.apache.lucene.document.FieldType
>  15:623073   19938336  org.apache.lucene.document.StoredField
>  16:721649   17319576  java.lang.String
>  17: 327297329640  [J
>  18: 146435788376  [F
> {code}
> The load on Solr is not much - max it goes to 2000 requests per minute. The 
> indexing load can sometimes be in burst but most of the time its pretty low. 
> But as mentioned above sometimes even a single document indexing can put solr 
> into tizzy and sometimes it just works like a charm.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11196) Solr 6.5.0 consuming entire Heap suddenly while working smoothly on Solr 6.1.0

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-11196:
---

Disagree with your point 7. The hard commit has openSearcher set to false so 
the soft commit is the only thing making documents visible. This is a 
relatively common pattern to limit the size of the tlog without doing the work 
of opening new searchers.

Otherwise agree totally and would add that the caches are very large relative 
to the memory. You have a filterCache set to 8192. Each entry can consume 
maxDoc/8 bytes, have you examined how much actually gets used when you go into 
the bad state?

You say "we have now increased the JVM memory to xmx of 12GB". Where is it 
coming from when you only have 7.65 GB available? My rule of thumb is to 
reserve _at least_ half the physical memory for the OS for MMapDirecotry's use, 
see: http://blog.thetaphi.de/2012/07/use-lucenes-mmapdirectory-on-64bit.html

All in all this is a misconfigured system, I doubt it's anything Solr can do 
much about. I'll close this JIRA, we can re-open it if you can show this is 
really a Solr problem and not just misconfiguration on your part, but let's 
discuss this on the user's list first.

> Solr 6.5.0 consuming entire Heap suddenly while working smoothly on Solr 6.1.0
> --
>
> Key: SOLR-11196
> URL: https://issues.apache.org/jira/browse/SOLR-11196
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.5, 6.6
>Reporter: Amit
>Priority: Critical
>
> Please note, this issue does not occurs on Solr-6.1.0 while the same occurs 
> on Solr-6.5.0 and above. To fix this we had to move back to Solr-6.1.0 
> version.
> We have been hit by a Solr Behavior in production which we are unable to 
> debug. To start with here are the configurations for solr:
> Solr Version: 6.5, Master with 1 Slave of the same configuration as mentioned 
> below.
> *JVM Config:*
>   
> {code:java}
>  -Xms2048m
>  -Xmx4096m
>  -XX:+ParallelRefProcEnabled
>  -XX:+UseCMSInitiatingOccupancyOnly
>  -XX:CMSInitiatingOccupancyFraction=50
> {code}
> Rest all are default values.
> *Solr Config:*
>  
> {code:java}
>
>   
>   {solr.autoCommit.maxTime:30}
>   false
> 
> 
> 
>   {solr.autoSoftCommit.maxTime:90}
> 
> 
> 
>   1024
>autowarmCount="0" />
>autowarmCount="0" />
>autowarmCount="0" />
>initialSize="0" autowarmCount="10" regenerator="solr.NoOpRegenerator" />
>   true
>   20
>   ${solr.query.max.docs:40}
>   
>   false
>   2
> 
> {code}
> *The Host (AWS) configurations are:*
> RAM: 7.65GB
> Cores: 4
> Now, our solr works perfectly fine for hours and sometimes for days but 
> sometimes suddenly memory jumps up and the GC kicks in causing long big 
> pauses with not much to recover. We are seeing this happening most often when 
> one or multiple segments gets added or deleted post a hard commit. It doesn't 
> matter how many documents got indexed. The images attached shows that just 1 
> document was indexed, causing an addition of one segment and it all got 
> messed up till we restarted the Solr.
> Here are the images from NewRelic and Sematext (Kindly click on the links to 
> view):
> [JVM Heap Memory Image | https://i.stack.imgur.com/9dQAy.png]
> [1 Document and 1 Segment addition Image | 
> https://i.stack.imgur.com/6N4FC.png]
> Update: Here is the JMap output when SOLR last died, we have now increased 
> the JVM memory to xmx of 12GB:
>  
> {code:java}
>  num #instances #bytes  class name
>   --
>   1:  11210921 1076248416  
> org.apache.lucene.codecs.lucene50.Lucene50PostingsFormat$IntBlockTermState
>   2:  10623486  934866768  [Lorg.apache.lucene.index.TermState;
>   3:  15567646  475873992  [B
>   4:  10623485  424939400  
> org.apache.lucene.search.spans.SpanTermQuery$SpanTermWeight
>   5:  15508972  372215328  org.apache.lucene.util.BytesRef
>   6:  15485834  371660016  org.apache.lucene.index.Term
>   7:  15477679  371464296  
> org.apache.lucene.search.spans.SpanTermQuery
>   8:  10623486  339951552  org.apache.lucene.index.TermContext
>   9:   1516724  150564320  [Ljava.lang.Object;
>  10:724486   50948800  [C
>  11:   1528110   36674640  java.util.ArrayList
>  12:849884   27196288  
> org.apache.lucene.search.spans.SpanNearQuery
>  13:582008   23280320  
> org.apache.lucene.search.spans.SpanNearQuery$SpanNearWeight
>  14:481601   23116848  org.apache.lucene.document.FieldType

[jira] [Commented] (SOLR-11196) Solr 6.5.0 consuming entire Heap suddenly while working smoothly on Solr 6.1.0

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-11196:
---

cut-n-paste from the user's list reply from Walter Underwood:
1. This should be a question on the solr-u...@lucene.apache.org, not a bug 
report.

2. A 12 GB heap on an instance with 7.65 GB of RAM is a fatal configuration. A 
full GC will cause lots of swapping and an extreme slowdown.

3. A 4 GB heap on an instance with 7.65 GB of RAM is not a good configuration. 
That does not leave enough room for the OS, other processes, and file buffers 
to cache Solr’s index files.

4. That instance is pretty small for Solr. The smallest AWS instance we run has 
15 GB of RAM. We run an 8 GB heap. Check the disk access on New Relic during 
the slowdown. 

5. Does this instance swap to magnetic disk? Are the Solr indexes on magnetic 
ephemeral or magnetic EBS? Check the iops on New Relic. When you hit the max 
iops for a disk volume, very bad performance things happen.

6. Set -Xms equal to -Xmx. Growing the heap to max at startup is a waste of 
time and makes Solr slow at the beginning. The heap will always get to max.

7. Setting a longer time for auto soft commit than for auto hard commit is 
nonsense. Just don’t do the soft commit.

wunder

> Solr 6.5.0 consuming entire Heap suddenly while working smoothly on Solr 6.1.0
> --
>
> Key: SOLR-11196
> URL: https://issues.apache.org/jira/browse/SOLR-11196
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.5, 6.6
>Reporter: Amit
>Priority: Critical
>
> Please note, this issue does not occurs on Solr-6.1.0 while the same occurs 
> on Solr-6.5.0 and above. To fix this we had to move back to Solr-6.1.0 
> version.
> We have been hit by a Solr Behavior in production which we are unable to 
> debug. To start with here are the configurations for solr:
> Solr Version: 6.5, Master with 1 Slave of the same configuration as mentioned 
> below.
> *JVM Config:*
>   
> {code:java}
>  -Xms2048m
>  -Xmx4096m
>  -XX:+ParallelRefProcEnabled
>  -XX:+UseCMSInitiatingOccupancyOnly
>  -XX:CMSInitiatingOccupancyFraction=50
> {code}
> Rest all are default values.
> *Solr Config:*
>  
> {code:java}
>
>   
>   {solr.autoCommit.maxTime:30}
>   false
> 
> 
> 
>   {solr.autoSoftCommit.maxTime:90}
> 
> 
> 
>   1024
>autowarmCount="0" />
>autowarmCount="0" />
>autowarmCount="0" />
>initialSize="0" autowarmCount="10" regenerator="solr.NoOpRegenerator" />
>   true
>   20
>   ${solr.query.max.docs:40}
>   
>   false
>   2
> 
> {code}
> *The Host (AWS) configurations are:*
> RAM: 7.65GB
> Cores: 4
> Now, our solr works perfectly fine for hours and sometimes for days but 
> sometimes suddenly memory jumps up and the GC kicks in causing long big 
> pauses with not much to recover. We are seeing this happening most often when 
> one or multiple segments gets added or deleted post a hard commit. It doesn't 
> matter how many documents got indexed. The images attached shows that just 1 
> document was indexed, causing an addition of one segment and it all got 
> messed up till we restarted the Solr.
> Here are the images from NewRelic and Sematext (Kindly click on the links to 
> view):
> [JVM Heap Memory Image | https://i.stack.imgur.com/9dQAy.png]
> [1 Document and 1 Segment addition Image | 
> https://i.stack.imgur.com/6N4FC.png]
> Update: Here is the JMap output when SOLR last died, we have now increased 
> the JVM memory to xmx of 12GB:
>  
> {code:java}
>  num #instances #bytes  class name
>   --
>   1:  11210921 1076248416  
> org.apache.lucene.codecs.lucene50.Lucene50PostingsFormat$IntBlockTermState
>   2:  10623486  934866768  [Lorg.apache.lucene.index.TermState;
>   3:  15567646  475873992  [B
>   4:  10623485  424939400  
> org.apache.lucene.search.spans.SpanTermQuery$SpanTermWeight
>   5:  15508972  372215328  org.apache.lucene.util.BytesRef
>   6:  15485834  371660016  org.apache.lucene.index.Term
>   7:  15477679  371464296  
> org.apache.lucene.search.spans.SpanTermQuery
>   8:  10623486  339951552  org.apache.lucene.index.TermContext
>   9:   1516724  150564320  [Ljava.lang.Object;
>  10:724486   50948800  [C
>  11:   1528110   36674640  java.util.ArrayList
>  12:849884   27196288  
> org.apache.lucene.search.spans.SpanNearQuery
>  13:582008   23280320  
> org.apache.lucene.search.spans.SpanNearQuery$SpanNearWeight
>  14: 

[jira] [Updated] (SOLR-10939) JoinQParser gives incorrect results with numeric PointsFields

[Yonik Seeley (JIRA)]

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

Yonik Seeley updated SOLR-10939:

Attachment: SOLR-10939.patch

Here's a patch that refactors and reuses the graph points collector for join.
I also made some changes to the join test:
1) if Points are selected, then docValues must be enabled (an exception is 
thrown otherwise)
2) removed testing joins across incompatible fields (for example matching an 
int field to a text field won't result in any matches)


> JoinQParser gives incorrect results with numeric PointsFields
> -
>
> Key: SOLR-10939
> URL: https://issues.apache.org/jira/browse/SOLR-10939
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Yonik Seeley
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0
>
> Attachments: SOLR-10939.patch
>
>
> If you try to use the {{\{!join\}}} QParser with numeric points fields, you 
> will get silently incorrect results.
> The underlying root cause seems to be that JoinQParser's JoinQuery assumes 
> every field it's dealing with has indexed terms. (AFAICT it won't even work 
> with {{indexed="false" docValues="true"}} Trie fields)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: [jira] [Updated] (SOLR-11196) Solr 6.5.0 consuming entire Heap suddenly while working smoothly on Solr 6.1.0

[Walter Underwood]

1. This should be a question on the solr-u...@lucene.apache.org, not a bug 
report.

2. A 12 GB heap on an instance with 7.65 GB of RAM is a fatal configuration. A 
full GC will cause lots of swapping and an extreme slowdown.

3. A 4 GB heap on an instance with 7.65 GB of RAM is not a good configuration. 
That does not leave enough room for the OS, other processes, and file buffers 
to cache Solr’s index files.

4. That instance is pretty small for Solr. The smallest AWS instance we run has 
15 GB of RAM. We run an 8 GB heap. Check the disk access on New Relic during 
the slowdown. 

5. Does this instance swap to magnetic disk? Are the Solr indexes on magnetic 
ephemeral or magnetic EBS? Check the iops on New Relic. When you hit the max 
iops for a disk volume, very bad performance things happen.

6. Set -Xms equal to -Xmx. Growing the heap to max at startup is a waste of 
time and makes Solr slow at the beginning. The heap will always get to max.

7. Setting a longer time for auto soft commit than for auto hard commit is 
nonsense. Just don’t do the soft commit.

wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)


> On Aug 4, 2017, at 7:13 AM, Amit (JIRA)  wrote:
> 
> 
> [ 
> https://issues.apache.org/jira/browse/SOLR-11196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>  ]
> 
> Amit updated SOLR-11196:
> 
>Description: 
> Please note, this issue does not occurs on Solr-6.1.0 while the same occurs 
> on Solr-6.5.0 and above. To fix this we had to move back to Solr-6.1.0 
> version.
> 
> We have been hit by a Solr Behavior in production which we are unable to 
> debug. To start with here are the configurations for solr:
> 
> Solr Version: 6.5, Master with 1 Slave of the same configuration as mentioned 
> below.
> 
> *JVM Config:*
> 
> 
> {code:java}
> -Xms2048m
> -Xmx4096m
> -XX:+ParallelRefProcEnabled
> -XX:+UseCMSInitiatingOccupancyOnly
> -XX:CMSInitiatingOccupancyFraction=50
> {code}
> 
> Rest all are default values.
> 
> *Solr Config:*
> 
> 
> {code:java}
>   
>  
>  {solr.autoCommit.maxTime:30}
>  false
>
>
>
>  {solr.autoSoftCommit.maxTime:90}
>
>
> 
>
>  1024
>   autowarmCount="0" />
>   autowarmCount="0" />
>   autowarmCount="0" />
>   initialSize="0" autowarmCount="10" regenerator="solr.NoOpRegenerator" />
>  true
>  20
>  ${solr.query.max.docs:40}
>  
>  false
>  2
>
> {code}
> 
> *The Host (AWS) configurations are:*
> 
> RAM: 7.65GB
> Cores: 4
> 
> Now, our solr works perfectly fine for hours and sometimes for days but 
> sometimes suddenly memory jumps up and the GC kicks in causing long big 
> pauses with not much to recover. We are seeing this happening most often when 
> one or multiple segments gets added or deleted post a hard commit. It doesn't 
> matter how many documents got indexed. The images attached shows that just 1 
> document was indexed, causing an addition of one segment and it all got 
> messed up till we restarted the Solr.
> 
> Here are the images from NewRelic and Sematext (Kindly click on the links to 
> view):
> 
> JVM Heap Memory Image : [https://i.stack.imgur.com/9dQAy.png]
> 1 Document and 1 Segment addition Image: [https://i.stack.imgur.com/6N4FC.png]
> 
> Update: Here is the JMap output when SOLR last died, we have now increased 
> the JVM memory to xmx of 12GB:
> 
> 
> {code:java}
> num #instances #bytes  class name
>  --
>  1:  11210921 1076248416  
> org.apache.lucene.codecs.lucene50.Lucene50PostingsFormat$IntBlockTermState
>  2:  10623486  934866768  [Lorg.apache.lucene.index.TermState;
>  3:  15567646  475873992  [B
>  4:  10623485  424939400  
> org.apache.lucene.search.spans.SpanTermQuery$SpanTermWeight
>  5:  15508972  372215328  org.apache.lucene.util.BytesRef
>  6:  15485834  371660016  org.apache.lucene.index.Term
>  7:  15477679  371464296  org.apache.lucene.search.spans.SpanTermQuery
>  8:  10623486  339951552  org.apache.lucene.index.TermContext
>  9:   1516724  150564320  [Ljava.lang.Object;
> 10:724486   50948800  [C
> 11:   1528110   36674640  java.util.ArrayList
> 12:849884   27196288  org.apache.lucene.search.spans.SpanNearQuery
> 13:582008   23280320  
> org.apache.lucene.search.spans.SpanNearQuery$SpanNearWeight
> 14:481601   23116848  org.apache.lucene.document.FieldType
> 15:623073   19938336  org.apache.lucene.document.StoredField
> 16:721649   17319576  java.lang.String
> 17: 327297329640  [J
> 18: 146435788376  [F
> {code}
> 
> 
> The load on Solr is not much - max it goes to 2000 requests per minute. The 
> indexing load can sometimes be in burst but most of the time its pretty low. 

[jira] [Updated] (SOLR-11196) Solr 6.5.0 consuming entire Heap suddenly while working smoothly on Solr 6.1.0

[Amit (JIRA)]

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

Amit updated SOLR-11196:

Description: 
Please note, this issue does not occurs on Solr-6.1.0 while the same occurs on 
Solr-6.5.0 and above. To fix this we had to move back to Solr-6.1.0 version.

We have been hit by a Solr Behavior in production which we are unable to debug. 
To start with here are the configurations for solr:

Solr Version: 6.5, Master with 1 Slave of the same configuration as mentioned 
below.

*JVM Config:*

  
{code:java}
 -Xms2048m
 -Xmx4096m
 -XX:+ParallelRefProcEnabled
 -XX:+UseCMSInitiatingOccupancyOnly
 -XX:CMSInitiatingOccupancyFraction=50
{code}

Rest all are default values.

*Solr Config:*

 
{code:java}
   
  
  {solr.autoCommit.maxTime:30}
  false



  {solr.autoSoftCommit.maxTime:90}




  1024
  
  
  
  
  true
  20
  ${solr.query.max.docs:40}
  
  false
  2

{code}

*The Host (AWS) configurations are:*

RAM: 7.65GB
Cores: 4

Now, our solr works perfectly fine for hours and sometimes for days but 
sometimes suddenly memory jumps up and the GC kicks in causing long big pauses 
with not much to recover. We are seeing this happening most often when one or 
multiple segments gets added or deleted post a hard commit. It doesn't matter 
how many documents got indexed. The images attached shows that just 1 document 
was indexed, causing an addition of one segment and it all got messed up till 
we restarted the Solr.

Here are the images from NewRelic and Sematext (Kindly click on the links to 
view):

[JVM Heap Memory Image | https://i.stack.imgur.com/9dQAy.png]
[1 Document and 1 Segment addition Image | https://i.stack.imgur.com/6N4FC.png]

Update: Here is the JMap output when SOLR last died, we have now increased the 
JVM memory to xmx of 12GB:

 
{code:java}
 num #instances #bytes  class name
  --
  1:  11210921 1076248416  
org.apache.lucene.codecs.lucene50.Lucene50PostingsFormat$IntBlockTermState
  2:  10623486  934866768  [Lorg.apache.lucene.index.TermState;
  3:  15567646  475873992  [B
  4:  10623485  424939400  
org.apache.lucene.search.spans.SpanTermQuery$SpanTermWeight
  5:  15508972  372215328  org.apache.lucene.util.BytesRef
  6:  15485834  371660016  org.apache.lucene.index.Term
  7:  15477679  371464296  org.apache.lucene.search.spans.SpanTermQuery
  8:  10623486  339951552  org.apache.lucene.index.TermContext
  9:   1516724  150564320  [Ljava.lang.Object;
 10:724486   50948800  [C
 11:   1528110   36674640  java.util.ArrayList
 12:849884   27196288  org.apache.lucene.search.spans.SpanNearQuery
 13:582008   23280320  
org.apache.lucene.search.spans.SpanNearQuery$SpanNearWeight
 14:481601   23116848  org.apache.lucene.document.FieldType
 15:623073   19938336  org.apache.lucene.document.StoredField
 16:721649   17319576  java.lang.String
 17: 327297329640  [J
 18: 146435788376  [F
{code}


The load on Solr is not much - max it goes to 2000 requests per minute. The 
indexing load can sometimes be in burst but most of the time its pretty low. 
But as mentioned above sometimes even a single document indexing can put solr 
into tizzy and sometimes it just works like a charm.

  was:
Please note, this issue does not occurs on Solr-6.1.0 while the same occurs on 
Solr-6.5.0 and above. To fix this we had to move back to Solr-6.1.0 version.

We have been hit by a Solr Behavior in production which we are unable to debug. 
To start with here are the configurations for solr:

Solr Version: 6.5, Master with 1 Slave of the same configuration as mentioned 
below.

*JVM Config:*

  
{code:java}
 -Xms2048m
 -Xmx4096m
 -XX:+ParallelRefProcEnabled
 -XX:+UseCMSInitiatingOccupancyOnly
 -XX:CMSInitiatingOccupancyFraction=50
{code}

Rest all are default values.

*Solr Config:*

 
{code:java}
   
  
  {solr.autoCommit.maxTime:30}
  false



  {solr.autoSoftCommit.maxTime:90}




  1024
  
  
  
  
  true
  20
  ${solr.query.max.docs:40}
  
  false
  2

{code}

*The Host (AWS) configurations are:*

RAM: 7.65GB
Cores: 4

Now, our solr works perfectly fine for hours and sometimes for days but 
sometimes suddenly memory jumps up and the GC kicks in causing long big pauses 
with not much to recover. We are seeing this happening most often when one or 
multiple segments gets added or deleted post a hard commit. It doesn't matter 
how many documents got indexed. The images attached shows that just 1 document 
was indexed, causing an addition of one segment and it all got messed 

[jira] [Updated] (SOLR-11196) Solr 6.5.0 consuming entire Heap suddenly while working smoothly on Solr 6.1.0

[Amit (JIRA)]

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

Amit updated SOLR-11196:

Description: 
Please note, this issue does not occurs on Solr-6.1.0 while the same occurs on 
Solr-6.5.0 and above. To fix this we had to move back to Solr-6.1.0 version.

We have been hit by a Solr Behavior in production which we are unable to debug. 
To start with here are the configurations for solr:

Solr Version: 6.5, Master with 1 Slave of the same configuration as mentioned 
below.

*JVM Config:*

  
{code:java}
 -Xms2048m
 -Xmx4096m
 -XX:+ParallelRefProcEnabled
 -XX:+UseCMSInitiatingOccupancyOnly
 -XX:CMSInitiatingOccupancyFraction=50
{code}

Rest all are default values.

*Solr Config:*

 
{code:java}
   
  
  {solr.autoCommit.maxTime:30}
  false



  {solr.autoSoftCommit.maxTime:90}




  1024
  
  
  
  
  true
  20
  ${solr.query.max.docs:40}
  
  false
  2

{code}

*The Host (AWS) configurations are:*

RAM: 7.65GB
Cores: 4

Now, our solr works perfectly fine for hours and sometimes for days but 
sometimes suddenly memory jumps up and the GC kicks in causing long big pauses 
with not much to recover. We are seeing this happening most often when one or 
multiple segments gets added or deleted post a hard commit. It doesn't matter 
how many documents got indexed. The images attached shows that just 1 document 
was indexed, causing an addition of one segment and it all got messed up till 
we restarted the Solr.

Here are the images from NewRelic and Sematext (Kindly click on the links to 
view):

[JVM Heap Memory Image | https://i.stack.imgur.com/9dQAy.png]
1 Document and 1 Segment addition Image: [https://i.stack.imgur.com/6N4FC.png]

Update: Here is the JMap output when SOLR last died, we have now increased the 
JVM memory to xmx of 12GB:

 
{code:java}
 num #instances #bytes  class name
  --
  1:  11210921 1076248416  
org.apache.lucene.codecs.lucene50.Lucene50PostingsFormat$IntBlockTermState
  2:  10623486  934866768  [Lorg.apache.lucene.index.TermState;
  3:  15567646  475873992  [B
  4:  10623485  424939400  
org.apache.lucene.search.spans.SpanTermQuery$SpanTermWeight
  5:  15508972  372215328  org.apache.lucene.util.BytesRef
  6:  15485834  371660016  org.apache.lucene.index.Term
  7:  15477679  371464296  org.apache.lucene.search.spans.SpanTermQuery
  8:  10623486  339951552  org.apache.lucene.index.TermContext
  9:   1516724  150564320  [Ljava.lang.Object;
 10:724486   50948800  [C
 11:   1528110   36674640  java.util.ArrayList
 12:849884   27196288  org.apache.lucene.search.spans.SpanNearQuery
 13:582008   23280320  
org.apache.lucene.search.spans.SpanNearQuery$SpanNearWeight
 14:481601   23116848  org.apache.lucene.document.FieldType
 15:623073   19938336  org.apache.lucene.document.StoredField
 16:721649   17319576  java.lang.String
 17: 327297329640  [J
 18: 146435788376  [F
{code}


The load on Solr is not much - max it goes to 2000 requests per minute. The 
indexing load can sometimes be in burst but most of the time its pretty low. 
But as mentioned above sometimes even a single document indexing can put solr 
into tizzy and sometimes it just works like a charm.

  was:
Please note, this issue does not occurs on Solr-6.1.0 while the same occurs on 
Solr-6.5.0 and above. To fix this we had to move back to Solr-6.1.0 version.

We have been hit by a Solr Behavior in production which we are unable to debug. 
To start with here are the configurations for solr:

Solr Version: 6.5, Master with 1 Slave of the same configuration as mentioned 
below.

*JVM Config:*

  
{code:java}
 -Xms2048m
 -Xmx4096m
 -XX:+ParallelRefProcEnabled
 -XX:+UseCMSInitiatingOccupancyOnly
 -XX:CMSInitiatingOccupancyFraction=50
{code}

Rest all are default values.

*Solr Config:*

 
{code:java}
   
  
  {solr.autoCommit.maxTime:30}
  false



  {solr.autoSoftCommit.maxTime:90}




  1024
  
  
  
  
  true
  20
  ${solr.query.max.docs:40}
  
  false
  2

{code}

*The Host (AWS) configurations are:*

RAM: 7.65GB
Cores: 4

Now, our solr works perfectly fine for hours and sometimes for days but 
sometimes suddenly memory jumps up and the GC kicks in causing long big pauses 
with not much to recover. We are seeing this happening most often when one or 
multiple segments gets added or deleted post a hard commit. It doesn't matter 
how many documents got indexed. The images attached shows that just 1 document 
was indexed, causing an addition of one segment and it all got messed 

[jira] [Updated] (SOLR-11196) Solr 6.5.0 consuming entire Heap suddenly while working smoothly on Solr 6.1.0

[Amit (JIRA)]

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

Amit updated SOLR-11196:

Description: 
Please note, this issue does not occurs on Solr-6.1.0 while the same occurs on 
Solr-6.5.0 and above. To fix this we had to move back to Solr-6.1.0 version.

We have been hit by a Solr Behavior in production which we are unable to debug. 
To start with here are the configurations for solr:

Solr Version: 6.5, Master with 1 Slave of the same configuration as mentioned 
below.

*JVM Config:*

  
{code:java}
 -Xms2048m
 -Xmx4096m
 -XX:+ParallelRefProcEnabled
 -XX:+UseCMSInitiatingOccupancyOnly
 -XX:CMSInitiatingOccupancyFraction=50
{code}

Rest all are default values.

*Solr Config:*

 
{code:java}
   
  
  {solr.autoCommit.maxTime:30}
  false



  {solr.autoSoftCommit.maxTime:90}




  1024
  
  
  
  
  true
  20
  ${solr.query.max.docs:40}
  
  false
  2

{code}

*The Host (AWS) configurations are:*

RAM: 7.65GB
Cores: 4

Now, our solr works perfectly fine for hours and sometimes for days but 
sometimes suddenly memory jumps up and the GC kicks in causing long big pauses 
with not much to recover. We are seeing this happening most often when one or 
multiple segments gets added or deleted post a hard commit. It doesn't matter 
how many documents got indexed. The images attached shows that just 1 document 
was indexed, causing an addition of one segment and it all got messed up till 
we restarted the Solr.

Here are the images from NewRelic and Sematext (Kindly click on the links to 
view):

JVM Heap Memory Image : [https://i.stack.imgur.com/9dQAy.png]
1 Document and 1 Segment addition Image: [https://i.stack.imgur.com/6N4FC.png]

Update: Here is the JMap output when SOLR last died, we have now increased the 
JVM memory to xmx of 12GB:

 
{code:java}
 num #instances #bytes  class name
  --
  1:  11210921 1076248416  
org.apache.lucene.codecs.lucene50.Lucene50PostingsFormat$IntBlockTermState
  2:  10623486  934866768  [Lorg.apache.lucene.index.TermState;
  3:  15567646  475873992  [B
  4:  10623485  424939400  
org.apache.lucene.search.spans.SpanTermQuery$SpanTermWeight
  5:  15508972  372215328  org.apache.lucene.util.BytesRef
  6:  15485834  371660016  org.apache.lucene.index.Term
  7:  15477679  371464296  org.apache.lucene.search.spans.SpanTermQuery
  8:  10623486  339951552  org.apache.lucene.index.TermContext
  9:   1516724  150564320  [Ljava.lang.Object;
 10:724486   50948800  [C
 11:   1528110   36674640  java.util.ArrayList
 12:849884   27196288  org.apache.lucene.search.spans.SpanNearQuery
 13:582008   23280320  
org.apache.lucene.search.spans.SpanNearQuery$SpanNearWeight
 14:481601   23116848  org.apache.lucene.document.FieldType
 15:623073   19938336  org.apache.lucene.document.StoredField
 16:721649   17319576  java.lang.String
 17: 327297329640  [J
 18: 146435788376  [F
{code}


The load on Solr is not much - max it goes to 2000 requests per minute. The 
indexing load can sometimes be in burst but most of the time its pretty low. 
But as mentioned above sometimes even a single document indexing can put solr 
into tizzy and sometimes it just works like a charm.

  was:
Please note, this issue does not occurs on Solr-6.1.0 while the same occurs on 
Solr-6.5.0 and above. To fix this we had to move back to Solr-6.1.0 version.

We have been hit by a Solr Behavior in production which we are unable to debug. 
To start with here are the configurations for solr:

Solr Version: 6.5, Master with 1 Slave of the same configuration as mentioned 
below.

*JVM Config:*

  
{code:java}
 -Xms2048m
 -Xmx4096m
 -XX:+ParallelRefProcEnabled
 -XX:+UseCMSInitiatingOccupancyOnly
 -XX:CMSInitiatingOccupancyFraction=50
{code}

Rest all are default values.

*Solr Config:*

 
{code:java}
   
  
  {solr.autoCommit.maxTime:30}
  false



  {solr.autoSoftCommit.maxTime:90}




  1024
  
  
  
  
  true
  20
  ${solr.query.max.docs:40}
  
  false
  2

{code}

*The Host (AWS) configurations are:*

RAM: 7.65GB
Cores: 4

Now, our solr works perfectly fine for hours and sometimes for days but 
sometimes suddenly memory jumps up and the GC kicks in causing long big pauses 
with not much to recover. We are seeing this happening most often when one or 
multiple segments gets added or deleted post a hard commit. It doesn't matter 
how many documents got indexed. The images attached shows that just 1 document 
was indexed, causing an addition of one segment and it all got messed 

[jira] [Commented] (SOLR-11178) Change error handling in AutoScalingHandler to be consistent w/ other APIs

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11178:


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

SOLR-11178: Change error handling in AutoScalingHandler to be consistent w/ 
other APIs


> Change error handling in AutoScalingHandler to be consistent w/ other APIs
> --
>
> Key: SOLR-11178
> URL: https://issues.apache.org/jira/browse/SOLR-11178
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-11178.patch
>
>
> AutoScalingHandler throws errors for each single error in the payload. 
> config, schema and security API doesn't behave like that. They throw one 
> single error which contains all the errors in the payload. This should be 
> fixed in 7.0 as well because it will break backward compatibility in clients .



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11196) Solr 6.5.0 consuming entire Heap suddenly while working smoothly on Solr 6.1.0

[Amit (JIRA)]

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

Amit updated SOLR-11196:

Description: 
Please note, this issue does not occurs on Solr-6.1.0 while the same occurs on 
Solr-6.5.0 and above. To fix this we had to move back to Solr-6.1.0 version.

We have been hit by a Solr Behavior in production which we are unable to debug. 
To start with here are the configurations for solr:

Solr Version: 6.5, Master with 1 Slave of the same configuration as mentioned 
below.

*JVM Config:*

  
{code:java}
 -Xms2048m
 -Xmx4096m
 -XX:+ParallelRefProcEnabled
 -XX:+UseCMSInitiatingOccupancyOnly
 -XX:CMSInitiatingOccupancyFraction=50
{code}

Rest all are default values.

*Solr Config:*

 
{code:java}
   
  
  {solr.autoCommit.maxTime:30}
  false



  {solr.autoSoftCommit.maxTime:90}




  1024
  
  
  
  
  true
  20
  ${solr.query.max.docs:40}
  
  false
  2

{code}

*The Host (AWS) configurations are:*

RAM: 7.65GB
Cores: 4

Now, our solr works perfectly fine for hours and sometimes for days but 
sometimes suddenly memory jumps up and the GC kicks in causing long big pauses 
with not much to recover. We are seeing this happening most often when one or 
multiple segments gets added or deleted post a hard commit. It doesn't matter 
how many documents got indexed. The images attached shows that just 1 document 
was indexed, causing an addition of one segment and it all got messed up till 
we restarted the Solr.

Here are the images from NewRelic and Sematext (Kindly click on the links to 
view):

[JVM Heap Memory Image : https://i.stack.imgur.com/9dQAy.png]
1 Document and 1 Segment addition Image: [https://i.stack.imgur.com/6N4FC.png]

Update: Here is the JMap output when SOLR last died, we have now increased the 
JVM memory to xmx of 12GB:

 
{code:java}
 num #instances #bytes  class name
  --
  1:  11210921 1076248416  
org.apache.lucene.codecs.lucene50.Lucene50PostingsFormat$IntBlockTermState
  2:  10623486  934866768  [Lorg.apache.lucene.index.TermState;
  3:  15567646  475873992  [B
  4:  10623485  424939400  
org.apache.lucene.search.spans.SpanTermQuery$SpanTermWeight
  5:  15508972  372215328  org.apache.lucene.util.BytesRef
  6:  15485834  371660016  org.apache.lucene.index.Term
  7:  15477679  371464296  org.apache.lucene.search.spans.SpanTermQuery
  8:  10623486  339951552  org.apache.lucene.index.TermContext
  9:   1516724  150564320  [Ljava.lang.Object;
 10:724486   50948800  [C
 11:   1528110   36674640  java.util.ArrayList
 12:849884   27196288  org.apache.lucene.search.spans.SpanNearQuery
 13:582008   23280320  
org.apache.lucene.search.spans.SpanNearQuery$SpanNearWeight
 14:481601   23116848  org.apache.lucene.document.FieldType
 15:623073   19938336  org.apache.lucene.document.StoredField
 16:721649   17319576  java.lang.String
 17: 327297329640  [J
 18: 146435788376  [F
{code}


The load on Solr is not much - max it goes to 2000 requests per minute. The 
indexing load can sometimes be in burst but most of the time its pretty low. 
But as mentioned above sometimes even a single document indexing can put solr 
into tizzy and sometimes it just works like a charm.

  was:
Please note, this issue does not occurs on Solr-6.1.0 while the same occurs on 
Solr-6.5.0 and above. To fix this we had to move back to Solr-6.1.0 version.

We have been hit by a Solr Behavior in production which we are unable to debug. 
To start with here are the configurations for solr:

Solr Version: 6.5, Master with 1 Slave of the same configuration as mentioned 
below.

*JVM Config:*

  
{code:java}
 -Xms2048m
 -Xmx4096m
 -XX:+ParallelRefProcEnabled
 -XX:+UseCMSInitiatingOccupancyOnly
 -XX:CMSInitiatingOccupancyFraction=50
{code}

Rest all are default values.

*Solr Config:*

 
{code:java}
   
  
  {solr.autoCommit.maxTime:30}
  false



  {solr.autoSoftCommit.maxTime:90}




  1024
  
  
  
  
  true
  20
  ${solr.query.max.docs:40}
  
  false
  2

{code}

*The Host (AWS) configurations are:*

RAM: 7.65GB
Cores: 4

Now, our solr works perfectly fine for hours and sometimes for days but 
sometimes suddenly memory jumps up and the GC kicks in causing long big pauses 
with not much to recover. We are seeing this happening most often when one or 
multiple segments gets added or deleted post a hard commit. It doesn't matter 
how many documents got indexed. The images attached shows that just 1 document 
was indexed, causing an addition of one segment and it all got messed 

[jira] [Commented] (SOLR-11178) Change error handling in AutoScalingHandler to be consistent w/ other APIs

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11178:


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

SOLR-11178: Change error handling in AutoScalingHandler to be consistent w/ 
other APIs


> Change error handling in AutoScalingHandler to be consistent w/ other APIs
> --
>
> Key: SOLR-11178
> URL: https://issues.apache.org/jira/browse/SOLR-11178
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-11178.patch
>
>
> AutoScalingHandler throws errors for each single error in the payload. 
> config, schema and security API doesn't behave like that. They throw one 
> single error which contains all the errors in the payload. This should be 
> fixed in 7.0 as well because it will break backward compatibility in clients .



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11196) Solr 6.5.0 consuming entire Heap suddenly while working smoothly on Solr 6.1.0

[Amit (JIRA)]

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

Amit updated SOLR-11196:

Description: 
Please note, this issue does not occurs on Solr-6.1.0 while the same occurs on 
Solr-6.5.0 and above. To fix this we had to move back to Solr-6.1.0 version.

We have been hit by a Solr Behavior in production which we are unable to debug. 
To start with here are the configurations for solr:

Solr Version: 6.5, Master with 1 Slave of the same configuration as mentioned 
below.

*JVM Config:*

  
{code:java}
 -Xms2048m
 -Xmx4096m
 -XX:+ParallelRefProcEnabled
 -XX:+UseCMSInitiatingOccupancyOnly
 -XX:CMSInitiatingOccupancyFraction=50
{code}

Rest all are default values.

*Solr Config:*

 
{code:java}
   
  
  {solr.autoCommit.maxTime:30}
  false



  {solr.autoSoftCommit.maxTime:90}




  1024
  
  
  
  
  true
  20
  ${solr.query.max.docs:40}
  
  false
  2

{code}

*The Host (AWS) configurations are:*

RAM: 7.65GB
Cores: 4

Now, our solr works perfectly fine for hours and sometimes for days but 
sometimes suddenly memory jumps up and the GC kicks in causing long big pauses 
with not much to recover. We are seeing this happening most often when one or 
multiple segments gets added or deleted post a hard commit. It doesn't matter 
how many documents got indexed. The images attached shows that just 1 document 
was indexed, causing an addition of one segment and it all got messed up till 
we restarted the Solr.

Here are the images from NewRelic and Sematext (Kindly click on the links to 
view):

JVM Heap Memory Image : [https://i.stack.imgur.com/9dQAy.png]
1 Document and 1 Segment addition Image: [https://i.stack.imgur.com/6N4FC.png]

Update: Here is the JMap output when SOLR last died, we have now increased the 
JVM memory to xmx of 12GB:

 
{code:java}
 num #instances #bytes  class name
  --
  1:  11210921 1076248416  
org.apache.lucene.codecs.lucene50.Lucene50PostingsFormat$IntBlockTermState
  2:  10623486  934866768  [Lorg.apache.lucene.index.TermState;
  3:  15567646  475873992  [B
  4:  10623485  424939400  
org.apache.lucene.search.spans.SpanTermQuery$SpanTermWeight
  5:  15508972  372215328  org.apache.lucene.util.BytesRef
  6:  15485834  371660016  org.apache.lucene.index.Term
  7:  15477679  371464296  org.apache.lucene.search.spans.SpanTermQuery
  8:  10623486  339951552  org.apache.lucene.index.TermContext
  9:   1516724  150564320  [Ljava.lang.Object;
 10:724486   50948800  [C
 11:   1528110   36674640  java.util.ArrayList
 12:849884   27196288  org.apache.lucene.search.spans.SpanNearQuery
 13:582008   23280320  
org.apache.lucene.search.spans.SpanNearQuery$SpanNearWeight
 14:481601   23116848  org.apache.lucene.document.FieldType
 15:623073   19938336  org.apache.lucene.document.StoredField
 16:721649   17319576  java.lang.String
 17: 327297329640  [J
 18: 146435788376  [F
{code}


The load on Solr is not much - max it goes to 2000 requests per minute. The 
indexing load can sometimes be in burst but most of the time its pretty low. 
But as mentioned above sometimes even a single document indexing can put solr 
into tizzy and sometimes it just works like a charm.

  was:
Please note, this issue does not occurs on Solr-6.1.0 while the same occurs on 
Solr-6.5.0 and above. To fix this we had to move back to Solr-6.1.0 version.

We have been hit by a Solr Behavior in production which we are unable to debug. 
To start with here are the configurations for solr:

Solr Version: 6.5, Master with 1 Slave of the same configuration as mentioned 
below.

*JVM Config:*

  
{code:java}
   -Xms2048m
 -Xmx4096m
 -XX:+ParallelRefProcEnabled
 -XX:+UseCMSInitiatingOccupancyOnly
 -XX:CMSInitiatingOccupancyFraction=50
{code}

Rest all are default values.

*Solr Config:*

 
{code:java}
   
  
  {solr.autoCommit.maxTime:30}
  false



  {solr.autoSoftCommit.maxTime:90}




  1024
  
  
  
  
  true
  20
  ${solr.query.max.docs:40}
  
  false
  2

{code}

*The Host (AWS) configurations are:*

RAM: 7.65GB
Cores: 4

Now, our solr works perfectly fine for hours and sometimes for days but 
sometimes suddenly memory jumps up and the GC kicks in causing long big pauses 
with not much to recover. We are seeing this happening most often when one or 
multiple segments gets added or deleted post a hard commit. It doesn't matter 
how many documents got indexed. The images attached shows that just 1 document 
was indexed, causing an addition of one segment and it all got messed up 

[jira] [Updated] (SOLR-11196) Solr 6.5.0 consuming entire Heap suddenly while working smoothly on Solr 6.1.0

[Amit (JIRA)]

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

Amit updated SOLR-11196:

Description: 
Please note, this issue does not occurs on Solr-6.1.0 while the same occurs on 
Solr-6.5.0 and above. To fix this we had to move back to Solr-6.1.0 version.

We have been hit by a Solr Behavior in production which we are unable to debug. 
To start with here are the configurations for solr:

Solr Version: 6.5, Master with 1 Slave of the same configuration as mentioned 
below.

*JVM Config:*

  
{code:java}
   -Xms2048m
 -Xmx4096m
 -XX:+ParallelRefProcEnabled
 -XX:+UseCMSInitiatingOccupancyOnly
 -XX:CMSInitiatingOccupancyFraction=50
{code}

Rest all are default values.

*Solr Config:*

 
{code:java}
   
  
  {solr.autoCommit.maxTime:30}
  false



  {solr.autoSoftCommit.maxTime:90}




  1024
  
  
  
  
  true
  20
  ${solr.query.max.docs:40}
  
  false
  2

{code}

*The Host (AWS) configurations are:*

RAM: 7.65GB
Cores: 4

Now, our solr works perfectly fine for hours and sometimes for days but 
sometimes suddenly memory jumps up and the GC kicks in causing long big pauses 
with not much to recover. We are seeing this happening most often when one or 
multiple segments gets added or deleted post a hard commit. It doesn't matter 
how many documents got indexed. The images attached shows that just 1 document 
was indexed, causing an addition of one segment and it all got messed up till 
we restarted the Solr.

Here are the images from NewRelic and Sematext (Kindly click on the links to 
view):

JVM Heap Memory Image : [https://i.stack.imgur.com/9dQAy.png]
1 Document and 1 Segment addition Image: [https://i.stack.imgur.com/6N4FC.png]

Update: Here is the JMap output when SOLR last died, we have now increased the 
JVM memory to xmx of 12GB:

 
{code:java}
 num #instances #bytes  class name
  --
  1:  11210921 1076248416  
org.apache.lucene.codecs.lucene50.Lucene50PostingsFormat$IntBlockTermState
  2:  10623486  934866768  [Lorg.apache.lucene.index.TermState;
  3:  15567646  475873992  [B
  4:  10623485  424939400  
org.apache.lucene.search.spans.SpanTermQuery$SpanTermWeight
  5:  15508972  372215328  org.apache.lucene.util.BytesRef
  6:  15485834  371660016  org.apache.lucene.index.Term
  7:  15477679  371464296  org.apache.lucene.search.spans.SpanTermQuery
  8:  10623486  339951552  org.apache.lucene.index.TermContext
  9:   1516724  150564320  [Ljava.lang.Object;
 10:724486   50948800  [C
 11:   1528110   36674640  java.util.ArrayList
 12:849884   27196288  org.apache.lucene.search.spans.SpanNearQuery
 13:582008   23280320  
org.apache.lucene.search.spans.SpanNearQuery$SpanNearWeight
 14:481601   23116848  org.apache.lucene.document.FieldType
 15:623073   19938336  org.apache.lucene.document.StoredField
 16:721649   17319576  java.lang.String
 17: 327297329640  [J
 18: 146435788376  [F
{code}


The load on Solr is not much - max it goes to 2000 requests per minute. The 
indexing load can sometimes be in burst but most of the time its pretty low. 
But as mentioned above sometimes even a single document indexing can put solr 
into tizzy and sometimes it just works like a charm.

  was:
Please note, this issue does not occurs on Solr-6.1.0 while the same occurs on 
Solr-6.5.0 and above. To fix this we had to move back to Solr-6.1.0 version.

We have been hit by a Solr Behavior in production which we are unable to debug. 
To start with here are the configurations for solr:

Solr Version: 6.5, Master with 1 Slave of the same configuration as mentioned 
below.

*JVM Config:*

 -Xms2048m
 -Xmx4096m
 -XX:+ParallelRefProcEnabled
 -XX:+UseCMSInitiatingOccupancyOnly
 -XX:CMSInitiatingOccupancyFraction=50
Rest all are default values.

*Solr Config:*

 
{code:java}
   
  
  {solr.autoCommit.maxTime:30}
  false



  {solr.autoSoftCommit.maxTime:90}


{code}



  1024
  
  
  
  
  true
  20
  ${solr.query.max.docs:40}
  
  false
  2


*The Host (AWS) configurations are:*

RAM: 7.65GB
Cores: 4

Now, our solr works perfectly fine for hours and sometimes for days but 
sometimes suddenly memory jumps up and the GC kicks in causing long big pauses 
with not much to recover. We are seeing this happening most often when one or 
multiple segments gets added or deleted post a hard commit. It doesn't matter 
how many documents got indexed. The images attached shows that just 1 document 
was indexed, causing an addition of one segment and it all got messed up till 
we restarted 

[jira] [Updated] (SOLR-11196) Solr 6.5.0 consuming entire Heap suddenly while working smoothly on Solr 6.1.0

[Amit (JIRA)]

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

Amit updated SOLR-11196:

Description: 
Please note, this issue does not occurs on Solr-6.1.0 while the same occurs on 
Solr-6.5.0 and above. To fix this we had to move back to Solr-6.1.0 version.

We have been hit by a Solr Behavior in production which we are unable to debug. 
To start with here are the configurations for solr:

Solr Version: 6.5, Master with 1 Slave of the same configuration as mentioned 
below.

*JVM Config:*

 -Xms2048m
 -Xmx4096m
 -XX:+ParallelRefProcEnabled
 -XX:+UseCMSInitiatingOccupancyOnly
 -XX:CMSInitiatingOccupancyFraction=50
Rest all are default values.

*Solr Config:*

 
{code:java}
   
  
  {solr.autoCommit.maxTime:30}
  false



  {solr.autoSoftCommit.maxTime:90}


{code}



  1024
  
  
  
  
  true
  20
  ${solr.query.max.docs:40}
  
  false
  2


*The Host (AWS) configurations are:*

RAM: 7.65GB
Cores: 4

Now, our solr works perfectly fine for hours and sometimes for days but 
sometimes suddenly memory jumps up and the GC kicks in causing long big pauses 
with not much to recover. We are seeing this happening most often when one or 
multiple segments gets added or deleted post a hard commit. It doesn't matter 
how many documents got indexed. The images attached shows that just 1 document 
was indexed, causing an addition of one segment and it all got messed up till 
we restarted the Solr.

Here are the images from NewRelic and Sematext (Kindly click on the links to 
view):

JVM Heap Memory Image : [https://i.stack.imgur.com/9dQAy.png]
1 Document and 1 Segment addition Image: [https://i.stack.imgur.com/6N4FC.png]

Update: Here is the JMap output when SOLR last died, we have now increased the 
JVM memory to xmx of 12GB:

  num #instances #bytes  class name
  --
  1:  11210921 1076248416  
org.apache.lucene.codecs.lucene50.Lucene50PostingsFormat$IntBlockTermState
  2:  10623486  934866768  [Lorg.apache.lucene.index.TermState;
  3:  15567646  475873992  [B
  4:  10623485  424939400  
org.apache.lucene.search.spans.SpanTermQuery$SpanTermWeight
  5:  15508972  372215328  org.apache.lucene.util.BytesRef
  6:  15485834  371660016  org.apache.lucene.index.Term
  7:  15477679  371464296  org.apache.lucene.search.spans.SpanTermQuery
  8:  10623486  339951552  org.apache.lucene.index.TermContext
  9:   1516724  150564320  [Ljava.lang.Object;
 10:724486   50948800  [C
 11:   1528110   36674640  java.util.ArrayList
 12:849884   27196288  org.apache.lucene.search.spans.SpanNearQuery
 13:582008   23280320  
org.apache.lucene.search.spans.SpanNearQuery$SpanNearWeight
 14:481601   23116848  org.apache.lucene.document.FieldType
 15:623073   19938336  org.apache.lucene.document.StoredField
 16:721649   17319576  java.lang.String
 17: 327297329640  [J
 18: 146435788376  [F

The load on Solr is not much - max it goes to 2000 requests per minute. The 
indexing load can sometimes be in burst but most of the time its pretty low. 
But as mentioned above sometimes even a single document indexing can put solr 
into tizzy and sometimes it just works like a charm.

  was:
Please note, this issue does not occurs on Solr-6.1.0 while the same occurs on 
Solr-6.5.0 and above. To fix this we had to move back to Solr-6.1.0 version.

We have been hit by a Solr Behavior in production which we are unable to debug. 
To start with here are the configurations for solr:

Solr Version: 6.5, Master with 1 Slave of the same configuration as mentioned 
below.

*JVM Config:*

 -Xms2048m
 -Xmx4096m
 -XX:+ParallelRefProcEnabled
 -XX:+UseCMSInitiatingOccupancyOnly
 -XX:CMSInitiatingOccupancyFraction=50
Rest all are default values.

*Solr Config:*


  
  {solr.autoCommit.maxTime:30}
  false



  {solr.autoSoftCommit.maxTime:90}




  1024
  
  
  
  
  true
  20
  ${solr.query.max.docs:40}
  
  false
  2


*The Host (AWS) configurations are:*

RAM: 7.65GB
Cores: 4

Now, our solr works perfectly fine for hours and sometimes for days but 
sometimes suddenly memory jumps up and the GC kicks in causing long big pauses 
with not much to recover. We are seeing this happening most often when one or 
multiple segments gets added or deleted post a hard commit. It doesn't matter 
how many documents got indexed. The images attached shows that just 1 document 
was indexed, causing an addition of one segment and it all got messed up till 
we restarted the Solr.

Here are the images from NewRelic and Sematext 

[jira] [Updated] (SOLR-11196) Solr 6.5.0 consuming entire Heap suddenly while working smoothly on Solr 6.1.0

[Amit (JIRA)]

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

Amit updated SOLR-11196:

Description: 
Please note, this issue does not occurs on Solr-6.1.0 while the same occurs on 
Solr-6.5.0 and above. To fix this we had to move back to Solr-6.1.0 version.

We have been hit by a Solr Behavior in production which we are unable to debug. 
To start with here are the configurations for solr:

Solr Version: 6.5, Master with 1 Slave of the same configuration as mentioned 
below.

*JVM Config:*

 -Xms2048m
 -Xmx4096m
 -XX:+ParallelRefProcEnabled
 -XX:+UseCMSInitiatingOccupancyOnly
 -XX:CMSInitiatingOccupancyFraction=50
Rest all are default values.

*Solr Config:*


  
  {solr.autoCommit.maxTime:30}
  false



  {solr.autoSoftCommit.maxTime:90}




  1024
  
  
  
  
  true
  20
  ${solr.query.max.docs:40}
  
  false
  2


*The Host (AWS) configurations are:*

RAM: 7.65GB
Cores: 4

Now, our solr works perfectly fine for hours and sometimes for days but 
sometimes suddenly memory jumps up and the GC kicks in causing long big pauses 
with not much to recover. We are seeing this happening most often when one or 
multiple segments gets added or deleted post a hard commit. It doesn't matter 
how many documents got indexed. The images attached shows that just 1 document 
was indexed, causing an addition of one segment and it all got messed up till 
we restarted the Solr.

Here are the images from NewRelic and Sematext (Kindly click on the links to 
view):

JVM Heap Memory Image : [https://i.stack.imgur.com/9dQAy.png]
1 Document and 1 Segment addition Image: [https://i.stack.imgur.com/6N4FC.png]

Update: Here is the JMap output when SOLR last died, we have now increased the 
JVM memory to xmx of 12GB:

  num #instances #bytes  class name
  --
  1:  11210921 1076248416  
org.apache.lucene.codecs.lucene50.Lucene50PostingsFormat$IntBlockTermState
  2:  10623486  934866768  [Lorg.apache.lucene.index.TermState;
  3:  15567646  475873992  [B
  4:  10623485  424939400  
org.apache.lucene.search.spans.SpanTermQuery$SpanTermWeight
  5:  15508972  372215328  org.apache.lucene.util.BytesRef
  6:  15485834  371660016  org.apache.lucene.index.Term
  7:  15477679  371464296  org.apache.lucene.search.spans.SpanTermQuery
  8:  10623486  339951552  org.apache.lucene.index.TermContext
  9:   1516724  150564320  [Ljava.lang.Object;
 10:724486   50948800  [C
 11:   1528110   36674640  java.util.ArrayList
 12:849884   27196288  org.apache.lucene.search.spans.SpanNearQuery
 13:582008   23280320  
org.apache.lucene.search.spans.SpanNearQuery$SpanNearWeight
 14:481601   23116848  org.apache.lucene.document.FieldType
 15:623073   19938336  org.apache.lucene.document.StoredField
 16:721649   17319576  java.lang.String
 17: 327297329640  [J
 18: 146435788376  [F

The load on Solr is not much - max it goes to 2000 requests per minute. The 
indexing load can sometimes be in burst but most of the time its pretty low. 
But as mentioned above sometimes even a single document indexing can put solr 
into tizzy and sometimes it just works like a charm.

  was:
Please note, this issue does not occurs on Solr-6.1.0 while the same occurs on 
Solr-6.5.0 and above. To fix this we had to move back to Solr-6.1.0 version.

We have been hit by a Solr Behavior in production which we are unable to debug. 
To start with here are the configurations for solr:

Solr Version: 6.5, Master with 1 Slave of the same configuration as mentioned 
below.

*JVM Config:*

 -Xms2048m
 -Xmx4096m
 -XX:+ParallelRefProcEnabled
 -XX:+UseCMSInitiatingOccupancyOnly
 -XX:CMSInitiatingOccupancyFraction=50
Rest all are default values.

*Solr Config:*


  
  {solr.autoCommit.maxTime:30}
  false



  {solr.autoSoftCommit.maxTime:90}




  1024
  
  
  
  
  true
  20
  ${solr.query.max.docs:40}
  
  false
  2


*The Host (AWS) configurations are:*

RAM: 7.65GB
Cores: 4

Now, our solr works perfectly fine for hours and sometimes for days but 
sometimes suddenly memory jumps up and the GC kicks in causing long big pauses 
with not much to recover. We are seeing this happening most often when one or 
multiple segments gets added or deleted post a hard commit. It doesn't matter 
how many documents got indexed. The images attached shows that just 1 document 
was indexed, causing an addition of one segment and it all got messed up till 
we restarted the Solr.

Here are the images from NewRelic and Sematext (Kindly click on the links 

[jira] [Updated] (SOLR-11196) Solr 6.5.0 consuming entire Heap suddenly while working smoothly on Solr 6.1.0

[Amit (JIRA)]

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

Amit updated SOLR-11196:

Description: 
Please note, this issue does not occurs on Solr-6.1.0 while the same occurs on 
Solr-6.5.0 and above. To fix this we had to move back to Solr-6.1.0 version.

We have been hit by a Solr Behavior in production which we are unable to debug. 
To start with here are the configurations for solr:

Solr Version: 6.5, Master with 1 Slave of the same configuration as mentioned 
below.

*JVM Config:*

 -Xms2048m
 -Xmx4096m
 -XX:+ParallelRefProcEnabled
 -XX:+UseCMSInitiatingOccupancyOnly
 -XX:CMSInitiatingOccupancyFraction=50
Rest all are default values.

*Solr Config:*


  
  {solr.autoCommit.maxTime:30}
  false



  {solr.autoSoftCommit.maxTime:90}




  1024
  
  
  
  
  true
  20
  ${solr.query.max.docs:40}
  
  false
  2


*The Host (AWS) configurations are:*

RAM: 7.65GB
Cores: 4

Now, our solr works perfectly fine for hours and sometimes for days but 
sometimes suddenly memory jumps up and the GC kicks in causing long big pauses 
with not much to recover. We are seeing this happening most often when one or 
multiple segments gets added or deleted post a hard commit. It doesn't matter 
how many documents got indexed. The images attached shows that just 1 document 
was indexed, causing an addition of one segment and it all got messed up till 
we restarted the Solr.

Here are the images from NewRelic and Sematext (Kindly click on the links to 
view):

[JVM Heap Memory Image][https://i.stack.imgur.com/9dQAy.png]


[1 Document and 1 Segment addition Image][2]

 [1]: https://i.stack.imgur.com/9dQAy.png
 [2]: https://i.stack.imgur.com/6N4FC.png

Update: Here is the JMap output when SOLR last died, we have now increased the 
JVM memory to xmx of 12GB:

  num #instances #bytes  class name
  --
  1:  11210921 1076248416  
org.apache.lucene.codecs.lucene50.Lucene50PostingsFormat$IntBlockTermState
  2:  10623486  934866768  [Lorg.apache.lucene.index.TermState;
  3:  15567646  475873992  [B
  4:  10623485  424939400  
org.apache.lucene.search.spans.SpanTermQuery$SpanTermWeight
  5:  15508972  372215328  org.apache.lucene.util.BytesRef
  6:  15485834  371660016  org.apache.lucene.index.Term
  7:  15477679  371464296  org.apache.lucene.search.spans.SpanTermQuery
  8:  10623486  339951552  org.apache.lucene.index.TermContext
  9:   1516724  150564320  [Ljava.lang.Object;
 10:724486   50948800  [C
 11:   1528110   36674640  java.util.ArrayList
 12:849884   27196288  org.apache.lucene.search.spans.SpanNearQuery
 13:582008   23280320  
org.apache.lucene.search.spans.SpanNearQuery$SpanNearWeight
 14:481601   23116848  org.apache.lucene.document.FieldType
 15:623073   19938336  org.apache.lucene.document.StoredField
 16:721649   17319576  java.lang.String
 17: 327297329640  [J
 18: 146435788376  [F

The load on Solr is not much - max it goes to 2000 requests per minute. The 
indexing load can sometimes be in burst but most of the time its pretty low. 
But as mentioned above sometimes even a single document indexing can put solr 
into tizzy and sometimes it just works like a charm.

  was:
Please note, this issue does not occurs on Solr-6.1.0 while the same occurs on 
Solr-6.5.0 and above. To fix this we had to move back to Solr-6.1.0 version.

We have been hit by a Solr Behavior in production which we are unable to debug. 
To start with here are the configurations for solr:

Solr Version: 6.5, Master with 1 Slave of the same configuration as mentioned 
below.

*JVM Config:*

 -Xms2048m
 -Xmx4096m
 -XX:+ParallelRefProcEnabled
 -XX:+UseCMSInitiatingOccupancyOnly
 -XX:CMSInitiatingOccupancyFraction=50
Rest all are default values.

*Solr Config:*


  
  {solr.autoCommit.maxTime:30}
  false



  {solr.autoSoftCommit.maxTime:90}




  1024
  
  
  
  
  true
  20
  ${solr.query.max.docs:40}
  
  false
  2


*The Host (AWS) configurations are:*

RAM: 7.65GB
Cores: 4

Now, our solr works perfectly fine for hours and sometimes for days but 
sometimes suddenly memory jumps up and the GC kicks in causing long big pauses 
with not much to recover. We are seeing this happening most often when one or 
multiple segments gets added or deleted post a hard commit. It doesn't matter 
how many documents got indexed. The images attached shows that just 1 document 
was indexed, causing an addition of one segment and it all got messed up till 
we restarted the Solr.

Here are the images 

[jira] [Updated] (SOLR-11196) Solr 6.5.0 consuming entire Heap suddenly while working smoothly on Solr 6.1.0

[Amit (JIRA)]

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

Amit updated SOLR-11196:

Description: 
Please note, this issue does not occurs on Solr-6.1.0 while the same occurs on 
Solr-6.5.0 and above. To fix this we had to move back to Solr-6.1.0 version.

We have been hit by a Solr Behavior in production which we are unable to debug. 
To start with here are the configurations for solr:

Solr Version: 6.5, Master with 1 Slave of the same configuration as mentioned 
below.

*JVM Config:*

 -Xms2048m
 -Xmx4096m
 -XX:+ParallelRefProcEnabled
 -XX:+UseCMSInitiatingOccupancyOnly
 -XX:CMSInitiatingOccupancyFraction=50
Rest all are default values.

*Solr Config:*


  
  {solr.autoCommit.maxTime:30}
  false



  {solr.autoSoftCommit.maxTime:90}




  1024
  
  
  
  
  true
  20
  ${solr.query.max.docs:40}
  
  false
  2


*The Host (AWS) configurations are:*

RAM: 7.65GB
Cores: 4

Now, our solr works perfectly fine for hours and sometimes for days but 
sometimes suddenly memory jumps up and the GC kicks in causing long big pauses 
with not much to recover. We are seeing this happening most often when one or 
multiple segments gets added or deleted post a hard commit. It doesn't matter 
how many documents got indexed. The images attached shows that just 1 document 
was indexed, causing an addition of one segment and it all got messed up till 
we restarted the Solr.

Here are the images from NewRelic and Sematext (Kindly click on the links to 
view):

[#JVM Heap Memory Image]


[1 Document and 1 Segment addition Image][2]

 [1]: https://i.stack.imgur.com/9dQAy.png
 [2]: https://i.stack.imgur.com/6N4FC.png

Update: Here is the JMap output when SOLR last died, we have now increased the 
JVM memory to xmx of 12GB:

  num #instances #bytes  class name
  --
  1:  11210921 1076248416  
org.apache.lucene.codecs.lucene50.Lucene50PostingsFormat$IntBlockTermState
  2:  10623486  934866768  [Lorg.apache.lucene.index.TermState;
  3:  15567646  475873992  [B
  4:  10623485  424939400  
org.apache.lucene.search.spans.SpanTermQuery$SpanTermWeight
  5:  15508972  372215328  org.apache.lucene.util.BytesRef
  6:  15485834  371660016  org.apache.lucene.index.Term
  7:  15477679  371464296  org.apache.lucene.search.spans.SpanTermQuery
  8:  10623486  339951552  org.apache.lucene.index.TermContext
  9:   1516724  150564320  [Ljava.lang.Object;
 10:724486   50948800  [C
 11:   1528110   36674640  java.util.ArrayList
 12:849884   27196288  org.apache.lucene.search.spans.SpanNearQuery
 13:582008   23280320  
org.apache.lucene.search.spans.SpanNearQuery$SpanNearWeight
 14:481601   23116848  org.apache.lucene.document.FieldType
 15:623073   19938336  org.apache.lucene.document.StoredField
 16:721649   17319576  java.lang.String
 17: 327297329640  [J
 18: 146435788376  [F

The load on Solr is not much - max it goes to 2000 requests per minute. The 
indexing load can sometimes be in burst but most of the time its pretty low. 
But as mentioned above sometimes even a single document indexing can put solr 
into tizzy and sometimes it just works like a charm.

  was:
Please note, this issue does not occurs on Solr-6.1.0 while the same occurs on 
Solr-6.5.0 and above. To fix this we had to move back to Solr-6.1.0 version.

We have been hit by a Solr Behavior in production which we are unable to debug. 
To start with here are the configurations for solr:

Solr Version: 6.5, Master with 1 Slave of the same configuration as mentioned 
below.

*JVM Config:*

 -Xms2048m
 -Xmx4096m
 -XX:+ParallelRefProcEnabled
 -XX:+UseCMSInitiatingOccupancyOnly
 -XX:CMSInitiatingOccupancyFraction=50
Rest all are default values.

*Solr Config:*


  
  {solr.autoCommit.maxTime:30}
  false



  {solr.autoSoftCommit.maxTime:90}




  1024
  
  
  
  
  true
  20
  ${solr.query.max.docs:40}
  
  false
  2


*The Host (AWS) configurations are:*

RAM: 7.65GB
Cores: 4

Now, our solr works perfectly fine for hours and sometimes for days but 
sometimes suddenly memory jumps up and the GC kicks in causing long big pauses 
with not much to recover. We are seeing this happening most often when one or 
multiple segments gets added or deleted post a hard commit. It doesn't matter 
how many documents got indexed. The images attached shows that just 1 document 
was indexed, causing an addition of one segment and it all got messed up till 
we restarted the Solr.

Here are the images from NewRelic and Sematext (Kindly 

[jira] [Updated] (SOLR-11196) Solr 6.5.0 consuming entire Heap suddenly while working smoothly on Solr 6.1.0

[Amit (JIRA)]

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

Amit updated SOLR-11196:

Description: 
Please note, this issue does not occurs on Solr-6.1.0 while the same occurs on 
Solr-6.5.0 and above. To fix this we had to move back to Solr-6.1.0 version.

We have been hit by a Solr Behavior in production which we are unable to debug. 
To start with here are the configurations for solr:

Solr Version: 6.5, Master with 1 Slave of the same configuration as mentioned 
below.

*JVM Config:*

 -Xms2048m
 -Xmx4096m
 -XX:+ParallelRefProcEnabled
 -XX:+UseCMSInitiatingOccupancyOnly
 -XX:CMSInitiatingOccupancyFraction=50
Rest all are default values.

*Solr Config:*


  
  {solr.autoCommit.maxTime:30}
  false



  {solr.autoSoftCommit.maxTime:90}




  1024
  
  
  
  
  true
  20
  ${solr.query.max.docs:40}
  
  false
  2


*The Host (AWS) configurations are:*

RAM: 7.65GB
Cores: 4

Now, our solr works perfectly fine for hours and sometimes for days but 
sometimes suddenly memory jumps up and the GC kicks in causing long big pauses 
with not much to recover. We are seeing this happening most often when one or 
multiple segments gets added or deleted post a hard commit. It doesn't matter 
how many documents got indexed. The images attached shows that just 1 document 
was indexed, causing an addition of one segment and it all got messed up till 
we restarted the Solr.

Here are the images from NewRelic and Sematext (Kindly click on the links to 
view):

[JVM Heap Memory Image]: https://i.stack.imgur.com/9dQAy.png


[1 Document and 1 Segment addition Image][2]

 [1]: https://i.stack.imgur.com/9dQAy.png
 [2]: https://i.stack.imgur.com/6N4FC.png

Update: Here is the JMap output when SOLR last died, we have now increased the 
JVM memory to xmx of 12GB:

  num #instances #bytes  class name
  --
  1:  11210921 1076248416  
org.apache.lucene.codecs.lucene50.Lucene50PostingsFormat$IntBlockTermState
  2:  10623486  934866768  [Lorg.apache.lucene.index.TermState;
  3:  15567646  475873992  [B
  4:  10623485  424939400  
org.apache.lucene.search.spans.SpanTermQuery$SpanTermWeight
  5:  15508972  372215328  org.apache.lucene.util.BytesRef
  6:  15485834  371660016  org.apache.lucene.index.Term
  7:  15477679  371464296  org.apache.lucene.search.spans.SpanTermQuery
  8:  10623486  339951552  org.apache.lucene.index.TermContext
  9:   1516724  150564320  [Ljava.lang.Object;
 10:724486   50948800  [C
 11:   1528110   36674640  java.util.ArrayList
 12:849884   27196288  org.apache.lucene.search.spans.SpanNearQuery
 13:582008   23280320  
org.apache.lucene.search.spans.SpanNearQuery$SpanNearWeight
 14:481601   23116848  org.apache.lucene.document.FieldType
 15:623073   19938336  org.apache.lucene.document.StoredField
 16:721649   17319576  java.lang.String
 17: 327297329640  [J
 18: 146435788376  [F

The load on Solr is not much - max it goes to 2000 requests per minute. The 
indexing load can sometimes be in burst but most of the time its pretty low. 
But as mentioned above sometimes even a single document indexing can put solr 
into tizzy and sometimes it just works like a charm.

  was:
Please note, this issue does not occurs on Solr-6.1.0 while the same occurs on 
Solr-6.5.0 and above. To fix this we had to move back to Solr-6.1.0 version.

We have been hit by a Solr Behavior in production which we are unable to debug. 
To start with here are the configurations for solr:

Solr Version: 6.5, Master with 1 Slave of the same configuration as mentioned 
below.

*JVM Config:*

 -Xms2048m
 -Xmx4096m
 -XX:+ParallelRefProcEnabled
 -XX:+UseCMSInitiatingOccupancyOnly
 -XX:CMSInitiatingOccupancyFraction=50
Rest all are default values.

*Solr Config:*


  
  {solr.autoCommit.maxTime:30}
  false



  {solr.autoSoftCommit.maxTime:90}




  1024
  
  
  
  
  true
  20
  ${solr.query.max.docs:40}
  
  false
  2


*The Host (AWS) configurations are:*

RAM: 7.65GB
Cores: 4

Now, our solr works perfectly fine for hours and sometimes for days but 
sometimes suddenly memory jumps up and the GC kicks in causing long big pauses 
with not much to recover. We are seeing this happening most often when one or 
multiple segments gets added or deleted post a hard commit. It doesn't matter 
how many documents got indexed. The images attached shows that just 1 document 
was indexed, causing an addition of one segment and it all got messed up till 
we restarted the Solr.

Here are the images 

[jira] [Created] (SOLR-11196) Solr 6.5.0 consuming entire Heap suddenly while working smoothly on Solr 6.1.0

[Amit (JIRA)]

Amit created SOLR-11196:
---

 Summary: Solr 6.5.0 consuming entire Heap suddenly while working 
smoothly on Solr 6.1.0
 Key: SOLR-11196
 URL: https://issues.apache.org/jira/browse/SOLR-11196
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.6, 6.5
Reporter: Amit
Priority: Critical


Please note, this issue does not occurs on Solr-6.1.0 while the same occurs on 
Solr-6.5.0 and above. To fix this we had to move back to Solr-6.1.0 version.

We have been hit by a Solr Behavior in production which we are unable to debug. 
To start with here are the configurations for solr:

Solr Version: 6.5, Master with 1 Slave of the same configuration as mentioned 
below.

*JVM Config:*

 -Xms2048m
 -Xmx4096m
 -XX:+ParallelRefProcEnabled
 -XX:+UseCMSInitiatingOccupancyOnly
 -XX:CMSInitiatingOccupancyFraction=50
Rest all are default values.

*Solr Config:*


  
  {solr.autoCommit.maxTime:30}
  false



  {solr.autoSoftCommit.maxTime:90}




  1024
  
  
  
  
  true
  20
  ${solr.query.max.docs:40}
  
  false
  2


*The Host (AWS) configurations are:*

RAM: 7.65GB
Cores: 4

Now, our solr works perfectly fine for hours and sometimes for days but 
sometimes suddenly memory jumps up and the GC kicks in causing long big pauses 
with not much to recover. We are seeing this happening most often when one or 
multiple segments gets added or deleted post a hard commit. It doesn't matter 
how many documents got indexed. The images attached shows that just 1 document 
was indexed, causing an addition of one segment and it all got messed up till 
we restarted the Solr.

Here are the images from NewRelic and Sematext (Kindly click on the links to 
view):

[JVM Heap Memory Image][1]


[1 Document and 1 Segment addition Image][2]

 [1]: https://i.stack.imgur.com/9dQAy.png
 [2]: https://i.stack.imgur.com/6N4FC.png

Update: Here is the JMap output when SOLR last died, we have now increased the 
JVM memory to xmx of 12GB:

  num #instances #bytes  class name
  --
  1:  11210921 1076248416  
org.apache.lucene.codecs.lucene50.Lucene50PostingsFormat$IntBlockTermState
  2:  10623486  934866768  [Lorg.apache.lucene.index.TermState;
  3:  15567646  475873992  [B
  4:  10623485  424939400  
org.apache.lucene.search.spans.SpanTermQuery$SpanTermWeight
  5:  15508972  372215328  org.apache.lucene.util.BytesRef
  6:  15485834  371660016  org.apache.lucene.index.Term
  7:  15477679  371464296  org.apache.lucene.search.spans.SpanTermQuery
  8:  10623486  339951552  org.apache.lucene.index.TermContext
  9:   1516724  150564320  [Ljava.lang.Object;
 10:724486   50948800  [C
 11:   1528110   36674640  java.util.ArrayList
 12:849884   27196288  org.apache.lucene.search.spans.SpanNearQuery
 13:582008   23280320  
org.apache.lucene.search.spans.SpanNearQuery$SpanNearWeight
 14:481601   23116848  org.apache.lucene.document.FieldType
 15:623073   19938336  org.apache.lucene.document.StoredField
 16:721649   17319576  java.lang.String
 17: 327297329640  [J
 18: 146435788376  [F

The load on Solr is not much - max it goes to 2000 requests per minute. The 
indexing load can sometimes be in burst but most of the time its pretty low. 
But as mentioned above sometimes even a single document indexing can put solr 
into tizzy and sometimes it just works like a charm.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7918) Give access to members of a composite shape

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7918:
-

[~ivera] I like the generics approach very much; I just want to be sure it 
passes precommit before going ahead.  And yes, I'm seeing exactly what you're 
seeing with the precommit. :-(


> Give access to members of a composite shape
> ---
>
> Key: LUCENE-7918
> URL: https://issues.apache.org/jira/browse/LUCENE-7918
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7918.patch
>
>
> Hi [~daddywri],
> I hope this is my last point in my wish list. In order to serialize objects I 
> need to access the members of a composite geoshape. This is currently not 
> possible so I was wondering if it is possible to add to more methods to the 
> class GeoCompositeMembershipShape:
> public int size()
> public GeoMembershipShape getShape(int index)
> Thanks,
> Ignacio



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7918) Give access to members of a composite shape

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7918:
-

[~ivera], there is no requirement in Lucene that all classes need a toString() 
method, but I do find it is very helpful, and all the concrete object classes 
in Geo3D have one.  So I think that the composite classes should too.  They can 
rely on the members' toString() methods as needed.


> Give access to members of a composite shape
> ---
>
> Key: LUCENE-7918
> URL: https://issues.apache.org/jira/browse/LUCENE-7918
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7918.patch
>
>
> Hi [~daddywri],
> I hope this is my last point in my wish list. In order to serialize objects I 
> need to access the members of a composite geoshape. This is currently not 
> possible so I was wondering if it is possible to add to more methods to the 
> class GeoCompositeMembershipShape:
> public int size()
> public GeoMembershipShape getShape(int index)
> Thanks,
> Ignacio



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7916) CompositeBreakIterator is brittle under ICU4J upgrade.

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7916:


+1 to [~rcmuir]'s patch: that's what ICU docs recommend instead.

> CompositeBreakIterator is brittle under ICU4J upgrade.
> --
>
> Key: LUCENE-7916
> URL: https://issues.apache.org/jira/browse/LUCENE-7916
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/analysis
>Affects Versions: 6.6
>Reporter: Chris Koenig
> Attachments: LUCENE-7916.patch, LUCENE-7916.patch
>
>
> We use lucene-analyzers-icu version 6.6.0 in our project. Lucene 6.6.0 is 
> built against ICU4J version 56.1, but our use case requires us to use the 
> latest version of ICU4J, 59.1.
> The problem that we have encountered is that 
> CompositeBreakIterator.getBreakIterator(int scriptCode) throws an 
> ArrayIndexOutOfBoundsException for script codes higher than 167. In ICU4J 
> 56.1 the highest possible script code is 166, but in ICU4j 59.1 it is 174.
> Internally, CompositeBreakIterator is creating an array of size 
> UScript.CODE_LIMIT, but the value of CODE_LIMIT from ICU4J 56.1 is being 
> baked into the bytecode by the compiler. So even after overriding the version 
> of the ICU4J dependency to 59.1 in our project, this array will still be size 
> 167, which is too small.
> {code}
> final class CompositeBreakIterator {
>   private final ICUTokenizerConfig config;
>   private final BreakIteratorWrapper wordBreakers[] = new 
> BreakIteratorWrapper[UScript.CODE_LIMIT];
> {code}
> Output of javap run on CompositeBreakIterator.class from 
> lucene-analyzers-icu-6.6.0.jar
> {code}
> Compiled from "CompositeBreakIterator.java"
> final class 
> org.apache.lucene.analysis.icu.segmentation.CompositeBreakIterator {
>   
> org.apache.lucene.analysis.icu.segmentation.CompositeBreakIterator(org.apache.lucene.analysis.icu.segmentation.ICUTokenizerConfig);
> descriptor: 
> (Lorg/apache/lucene/analysis/icu/segmentation/ICUTokenizerConfig;)V
> Code:
>0: aload_0
>1: invokespecial #1  // Method 
> java/lang/Object."":()V
>4: aload_0
>5: sipush167
>8: anewarray #3  // class 
> org/apache/lucene/analysis/icu/segmentation/BreakIteratorWrapper
> {code}
> In our case, the ArrayIndexOutOfBoundsException was triggered when we 
> encountered a stray character of the Bhaiksuki script (script code 168) in a 
> chunk of text that we processed.
> CompositeBreakIterator can be made more resilient by changing the type of 
> wordBreakers from an array to a Map and no longer relying on the value of 
> UScript.CODE_LIMIT.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (LUCENE-7918) Give access to members of a composite shape

[Ignacio Vera (JIRA)]

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

Ignacio Vera updated LUCENE-7918:
-
Attachment: LUCENE-7918.patch

Hi [~daddywri],

I am sorry of hearing that. I will be running the precommit in this patch 
although it seems I am getting the same errors as you are getting (Lots of  
Unescaped symbol "->" on line #). I will try to see if I can fix it somewhat.

I think I found a good solution. I am using Generic abstract classes and the 
exposing in the API the concretization of those classes. I attach the solution 
in case you have any comments.

I wonder if it makes sense to have a generic interface for those composite 
classes

Another issue I am having, is that I am not sure what I should do with the 
toString() methods.

Thanks again!

Ignacio

> Give access to members of a composite shape
> ---
>
> Key: LUCENE-7918
> URL: https://issues.apache.org/jira/browse/LUCENE-7918
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7918.patch
>
>
> Hi [~daddywri],
> I hope this is my last point in my wish list. In order to serialize objects I 
> need to access the members of a composite geoshape. This is currently not 
> possible so I was wondering if it is possible to add to more methods to the 
> class GeoCompositeMembershipShape:
> public int size()
> public GeoMembershipShape getShape(int index)
> Thanks,
> Ignacio



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11195) require class attribute for SolrShardReporter and SolrClusterReporter configurations

[Christine Poerschke (JIRA)]

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

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

Attaching proposed patch.

> require class attribute for SolrShardReporter and SolrClusterReporter 
> configurations
> 
>
> Key: SOLR-11195
> URL: https://issues.apache.org/jira/browse/SOLR-11195
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-11195.patch
>
>
> This brings the two classes in line with the 
> https://lucene.apache.org/solr/guide/6_6/metrics-reporting.html 
> documentation. In doing so it also tidies up the (private) 
> _SolrMetricManager.preparePlugin_ logic which currently would reject class 
> attribute values other than the base _SolrShardReporter_ and 
> _SolrClusterReporter_ classes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11195) require class attribute for SolrShardReporter and SolrClusterReporter configurations

[Christine Poerschke (JIRA)]

Christine Poerschke created SOLR-11195:
--

 Summary: require class attribute for SolrShardReporter and 
SolrClusterReporter configurations
 Key: SOLR-11195
 URL: https://issues.apache.org/jira/browse/SOLR-11195
 Project: Solr
  Issue Type: Task
Reporter: Christine Poerschke
Assignee: Christine Poerschke
Priority: Minor


This brings the two classes in line with the 
https://lucene.apache.org/solr/guide/6_6/metrics-reporting.html documentation. 
In doing so it also tidies up the (private) _SolrMetricManager.preparePlugin_ 
logic which currently would reject class attribute values other than the base 
_SolrShardReporter_ and _SolrClusterReporter_ classes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11194) Suggester BlendedInfixLookupFactory to support HDFS store for indexwriter

[Peter Szantai-Kis (JIRA)]

Peter Szantai-Kis created SOLR-11194:


 Summary: Suggester BlendedInfixLookupFactory to support HDFS store 
for indexwriter
 Key: SOLR-11194
 URL: https://issues.apache.org/jira/browse/SOLR-11194
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Suggester
Affects Versions: 6.6
Reporter: Peter Szantai-Kis
Priority: Minor


When relative path is used for indexPath in the LookupFactory, the solr cores 
DataDir is used as a prefix, but still will be created in the working directory 
of the process. Unfortunately both the BlendedInfixLookupFactory and it's 
parent AnalyzingInfixLookupFactory uses a store implementation that does not 
support HDFS. So in case the data dir is on hdfs then the "hdfs:/" prefix will 
be ignored and because of the missing leading forward slash it will be treated 
as a relative path. It seems hdfs wasn't really considered as an option when 
these Suggesters were implemented.

One possible solution is to  use the SolrCores' own DirectoryFactory to lookup 
the data dir which dynamically will return the proper store in case of HDFS is 
used



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (LUCENE-7827) disable "textgrams" when minPrefixChars=0 AnalyzingInfixSuggester

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated LUCENE-7827:
-
Attachment: LUCENE-7827.patch

> disable "textgrams" when minPrefixChars=0 AnalyzingInfixSuggester 
> --
>
> Key: LUCENE-7827
> URL: https://issues.apache.org/jira/browse/LUCENE-7827
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Mikhail Khludnev
>Priority: Minor
> Attachments: LUCENE-7827.patch, LUCENE-7827.patch, LUCENE-7827.patch
>
>
> The current code allows to set minPrefixChars=0, but it creates an 
> unnecessary {{textgrams}} field, and might bring significant footprint.  
> Bypassing it keeps existing tests green.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11178) Change error handling in AutoScalingHandler to be consistent w/ other APIs

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-11178:
---

Not yet. It will be committed soon

> Change error handling in AutoScalingHandler to be consistent w/ other APIs
> --
>
> Key: SOLR-11178
> URL: https://issues.apache.org/jira/browse/SOLR-11178
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-11178.patch
>
>
> AutoScalingHandler throws errors for each single error in the payload. 
> config, schema and security API doesn't behave like that. They throw one 
> single error which contains all the errors in the payload. This should be 
> fixed in 7.0 as well because it will break backward compatibility in clients .



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11178) Change error handling in AutoScalingHandler to be consistent w/ other APIs

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-11178:
--

[~noble.paul] -- was this also committed to master and branch_7x? I don't see 
the commit notification

> Change error handling in AutoScalingHandler to be consistent w/ other APIs
> --
>
> Key: SOLR-11178
> URL: https://issues.apache.org/jira/browse/SOLR-11178
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-11178.patch
>
>
> AutoScalingHandler throws errors for each single error in the payload. 
> config, schema and security API doesn't behave like that. They throw one 
> single error which contains all the errors in the payload. This should be 
> fixed in 7.0 as well because it will break backward compatibility in clients .



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7918) Give access to members of a composite shape

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7918:
-

Hi [~ivera],
A word of warning: There's a great deal of concern when we add to the public 
API of anything in Lucene.  This has to be thought out carefully.  The addition 
of GeoCompositeAreaShape was barely OK, and caused precommit errors that I was 
scrambling around to fix for seven hours yesterday.

I would therefore like to revisit the public method signature of 
GeoCompositeAreaShape as part of this request.  The public API for 
GeoCompositeAreaShape should accept GeoAreaShape for its add method, and the 
public API for GeoCompositeMembershipShape should accept GeoMembershipShape for 
its add method.  I strongly suggest that both of these classes be derived from 
a base class with package scope that has protected methods in it only, and some 
care is made to keep the public API consistent with the classes that define 
them.  For example, your getShape() method needs to return GeoAreaShape for 
GeoCompositeAreaShape, and GeoMembershipShape for GeoCompositeMembershipShape.  
Does this make sense?

Finally, the patch has to pass "ant precommit" (runnable only at the topmost 
level of the Lucene/Solr tree).  Unfortunately due to a bug in one of the 
checks I cannot run this on my setup so I will need to rely on you to do it 
before a patch can be committed.

Thanks!!


> Give access to members of a composite shape
> ---
>
> Key: LUCENE-7918
> URL: https://issues.apache.org/jira/browse/LUCENE-7918
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>
> Hi [~daddywri],
> I hope this is my last point in my wish list. In order to serialize objects I 
> need to access the members of a composite geoshape. This is currently not 
> possible so I was wondering if it is possible to add to more methods to the 
> class GeoCompositeMembershipShape:
> public int size()
> public GeoMembershipShape getShape(int index)
> Thanks,
> Ignacio



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (LUCENE-7914) Add safeguards to RegExp.toAutomaton and Operations

[Jim Ferenczi (JIRA)]

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

Jim Ferenczi resolved LUCENE-7914.
--
Resolution: Fixed

Thanks [~rcmuir] and [~jpountz] !

> Add safeguards to RegExp.toAutomaton and Operations
> ---
>
> Key: LUCENE-7914
> URL: https://issues.apache.org/jira/browse/LUCENE-7914
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Jim Ferenczi
> Fix For: master (8.0), 7.1
>
> Attachments: LUCENE-7914.patch, LUCENE-7914.patch, LUCENE-7914.patch, 
> LUCENE-7914.patch, LUCENE-7914.patch
>
>
> When creating an automaton from a regexp, some operators can create more 
> states than maxDeterminizedStates:
> {code}
> a{1}
> {code}
> The example above creates a single path with 10k states already 
> determinized so maxDeterminizedStates is not checked. 
> Some operations on automaton like Operations.isFinite or 
> Operations.topoSortStates are recursive and the maximum level of recursion 
> depends on the longest path in the automaton. So a large automaton like above 
> can exceed java's stack.
> In most of the cases we are covered by maxDeterminizedStates but there will 
> always be adversarial cases where a large automaton is created from a small 
> input so I think we should also have safeguards in the recursive methods. 
> I've attached a patch that adds a max recursion level to Operations.isFinite 
> and Operations.topoSortStates in order to limit stack overflows. The limit is 
> set to 1000 so any automaton with a path bigger than 1000 would throw an 
> IllegalStateException.
> The patch also uses maxDeterminizedStates to limit the number of states that 
> a repeat operator can create and throw a TooComplex..Exception when this 
> limit is reached.
> Finally the patch adds the ability to skip Operations.isFinite on 
> AutomatonQuery and uses this as an optimization for PrefixQuery that uses 
> infinite automatons only.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7914) Add safeguards to RegExp.toAutomaton and Operations

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7914: Add a maximum recursion level in automaton recursive functions 
(Operations.isFinite and Operations.topsortState) to prevent large automaton to 
overflow the stack.


> Add safeguards to RegExp.toAutomaton and Operations
> ---
>
> Key: LUCENE-7914
> URL: https://issues.apache.org/jira/browse/LUCENE-7914
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Jim Ferenczi
> Fix For: master (8.0), 7.1
>
> Attachments: LUCENE-7914.patch, LUCENE-7914.patch, LUCENE-7914.patch, 
> LUCENE-7914.patch, LUCENE-7914.patch
>
>
> When creating an automaton from a regexp, some operators can create more 
> states than maxDeterminizedStates:
> {code}
> a{1}
> {code}
> The example above creates a single path with 10k states already 
> determinized so maxDeterminizedStates is not checked. 
> Some operations on automaton like Operations.isFinite or 
> Operations.topoSortStates are recursive and the maximum level of recursion 
> depends on the longest path in the automaton. So a large automaton like above 
> can exceed java's stack.
> In most of the cases we are covered by maxDeterminizedStates but there will 
> always be adversarial cases where a large automaton is created from a small 
> input so I think we should also have safeguards in the recursive methods. 
> I've attached a patch that adds a max recursion level to Operations.isFinite 
> and Operations.topoSortStates in order to limit stack overflows. The limit is 
> set to 1000 so any automaton with a path bigger than 1000 would throw an 
> IllegalStateException.
> The patch also uses maxDeterminizedStates to limit the number of states that 
> a repeat operator can create and throw a TooComplex..Exception when this 
> limit is reached.
> Finally the patch adds the ability to skip Operations.isFinite on 
> AutomatonQuery and uses this as an optimization for PrefixQuery that uses 
> infinite automatons only.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7914) Add safeguards to RegExp.toAutomaton and Operations

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7914: Add a maximum recursion level in automaton recursive functions 
(Operations.isFinite and Operations.topsortState) to prevent large automaton to 
overflow the stack.


> Add safeguards to RegExp.toAutomaton and Operations
> ---
>
> Key: LUCENE-7914
> URL: https://issues.apache.org/jira/browse/LUCENE-7914
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Jim Ferenczi
> Fix For: master (8.0), 7.1
>
> Attachments: LUCENE-7914.patch, LUCENE-7914.patch, LUCENE-7914.patch, 
> LUCENE-7914.patch, LUCENE-7914.patch
>
>
> When creating an automaton from a regexp, some operators can create more 
> states than maxDeterminizedStates:
> {code}
> a{1}
> {code}
> The example above creates a single path with 10k states already 
> determinized so maxDeterminizedStates is not checked. 
> Some operations on automaton like Operations.isFinite or 
> Operations.topoSortStates are recursive and the maximum level of recursion 
> depends on the longest path in the automaton. So a large automaton like above 
> can exceed java's stack.
> In most of the cases we are covered by maxDeterminizedStates but there will 
> always be adversarial cases where a large automaton is created from a small 
> input so I think we should also have safeguards in the recursive methods. 
> I've attached a patch that adds a max recursion level to Operations.isFinite 
> and Operations.topoSortStates in order to limit stack overflows. The limit is 
> set to 1000 so any automaton with a path bigger than 1000 would throw an 
> IllegalStateException.
> The patch also uses maxDeterminizedStates to limit the number of states that 
> a repeat operator can create and throw a TooComplex..Exception when this 
> limit is reached.
> Finally the patch adds the ability to skip Operations.isFinite on 
> AutomatonQuery and uses this as an optimization for PrefixQuery that uses 
> infinite automatons only.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (LUCENE-7914) Add safeguards to RegExp.toAutomaton and Operations

[Jim Ferenczi (JIRA)]

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

Jim Ferenczi updated LUCENE-7914:
-
Fix Version/s: 7.1
   master (8.0)

> Add safeguards to RegExp.toAutomaton and Operations
> ---
>
> Key: LUCENE-7914
> URL: https://issues.apache.org/jira/browse/LUCENE-7914
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Jim Ferenczi
> Fix For: master (8.0), 7.1
>
> Attachments: LUCENE-7914.patch, LUCENE-7914.patch, LUCENE-7914.patch, 
> LUCENE-7914.patch, LUCENE-7914.patch
>
>
> When creating an automaton from a regexp, some operators can create more 
> states than maxDeterminizedStates:
> {code}
> a{1}
> {code}
> The example above creates a single path with 10k states already 
> determinized so maxDeterminizedStates is not checked. 
> Some operations on automaton like Operations.isFinite or 
> Operations.topoSortStates are recursive and the maximum level of recursion 
> depends on the longest path in the automaton. So a large automaton like above 
> can exceed java's stack.
> In most of the cases we are covered by maxDeterminizedStates but there will 
> always be adversarial cases where a large automaton is created from a small 
> input so I think we should also have safeguards in the recursive methods. 
> I've attached a patch that adds a max recursion level to Operations.isFinite 
> and Operations.topoSortStates in order to limit stack overflows. The limit is 
> set to 1000 so any automaton with a path bigger than 1000 would throw an 
> IllegalStateException.
> The patch also uses maxDeterminizedStates to limit the number of states that 
> a repeat operator can create and throw a TooComplex..Exception when this 
> limit is reached.
> Finally the patch adds the ability to skip Operations.isFinite on 
> AutomatonQuery and uses this as an optimization for PrefixQuery that uses 
> infinite automatons only.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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