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

[Apache Jenkins Server]

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

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

Error Message:
Timeout occurred while waiting response from server at: https://127.0.0.1:33513

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occurred while 
waiting response from server at: https://127.0.0.1:33513
at 
__randomizedtesting.SeedInfo.seed([6BC03C5786310F84:E394038D28CD627C]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:667)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1128)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228)
at 
org.apache.solr.cloud.RollingRestartTest.restartWithRolesTest(RollingRestartTest.java:74)
at 
org.apache.solr.cloud.RollingRestartTest.test(RollingRestartTest.java:53)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
a

[jira] [Commented] (SOLR-13568) Expand component should not cache group queries in the filter cache

[Ludovic Boutros (JIRA)]

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

Ludovic Boutros commented on SOLR-13568:


The PR is done on the 8x branch. Is it the good one or would you prefer on the 
master ?
[~joel.bernstein], I think your are the master of collapsing/expand features. :)
Would you like to take a look at this please ?

Thank you !

> Expand component should not cache group queries in the filter cache
> ---
>
> Key: SOLR-13568
> URL: https://issues.apache.org/jira/browse/SOLR-13568
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7.2, 8.1.1
>Reporter: Ludovic Boutros
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently the expand component is creating queries (bit sets) from the 
> current page document ids.
> These queries are sadly put in the filter cache.
> This behavior floods the filter cache and it becomes inefficient.
> Therefore, the group query should be wrapped in a query with its cache flag 
> disabled.
> This is a tiny little thing to do. The PR will follow very soon.



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

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

[jira] [Commented] (SOLR-12866) Reproducing TestLocalFSCloudBackupRestore and TestHdfsCloudBackupRestore failures

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12866:


Commit e7fea2899de326845effb6289e5f56af629ba290 in lucene-solr's branch 
refs/heads/branch_8x from Mikhail Khludnev
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e7fea28 ]

SOLR-12866: Turn TestHdfsCloudBackupRestore ON. No changes yet.


> Reproducing TestLocalFSCloudBackupRestore and TestHdfsCloudBackupRestore 
> failures
> -
>
> Key: SOLR-12866
> URL: https://issues.apache.org/jira/browse/SOLR-12866
> Project: Solr
>  Issue Type: Task
>Reporter: Steve Rowe
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12866.patch, SOLR-12866.patch, SOLR-12866.patch, 
> SOLR-12866.patch, screenshot-1.png
>
>
> From [https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-7.x/185/], 
> both tests failed 10/10 iterations for me on branch_7x with the seed:
> {noformat}
> Checking out Revision 37fdcb02d87ec44293ec4942c75a3cb709c45418 
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestLocalFSCloudBackupRestore -Dtests.method=test 
> -Dtests.seed=3CD4284489C09DB4 -Dtests.multiplier=2 -Dtests.slow=true 
> -Dtests.badapples=true -Dtests.locale=mk-MK 
> -Dtests.timezone=Pacific/Kiritimati -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 10.8s J2 | TestLocalFSCloudBackupRestore.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Node 
> 127.0.0.1:43864_solr has 3 replicas. Expected num replicas : 2. state: 
>[junit4]> 
> DocCollection(backuprestore_restored//collections/backuprestore_restored/state.json/9)={
>[junit4]>   "pullReplicas":0,
>[junit4]>   "replicationFactor":1,
>[junit4]>   "shards":{
>[junit4]> "shard2":{
>[junit4]>   "range":"0-7fff",
>[junit4]>   "state":"active",
>[junit4]>   "replicas":{"core_node62":{
>[junit4]>   "core":"backuprestore_restored_shard2_replica_n61",
>[junit4]>   "base_url":"https://127.0.0.1:43864/solr";,
>[junit4]>   "node_name":"127.0.0.1:43864_solr",
>[junit4]>   "state":"active",
>[junit4]>   "type":"NRT",
>[junit4]>   "force_set_state":"false",
>[junit4]>   "leader":"true"}},
>[junit4]>   "stateTimestamp":"1539459703266853250"},
>[junit4]> "shard1_1":{
>[junit4]>   "range":"c000-",
>[junit4]>   "state":"active",
>[junit4]>   "replicas":{"core_node64":{
>[junit4]>   
> "core":"backuprestore_restored_shard1_1_replica_n63",
>[junit4]>   "base_url":"https://127.0.0.1:43864/solr";,
>[junit4]>   "node_name":"127.0.0.1:43864_solr",
>[junit4]>   "state":"active",
>[junit4]>   "type":"NRT",
>[junit4]>   "force_set_state":"false",
>[junit4]>   "leader":"true"}},
>[junit4]>   "stateTimestamp":"1539459703266887720"},
>[junit4]> "shard1_0":{
>[junit4]>   "range":"8000-bfff",
>[junit4]>   "state":"active",
>[junit4]>   "replicas":{"core_node66":{
>[junit4]>   
> "core":"backuprestore_restored_shard1_0_replica_n65",
>[junit4]>   "base_url":"https://127.0.0.1:43864/solr";,
>[junit4]>   "node_name":"127.0.0.1:43864_solr",
>[junit4]>   "state":"active",
>[junit4]>   "type":"NRT",
>[junit4]>   "force_set_state":"false",
>[junit4]>   "leader":"true"}},
>[junit4]>   "stateTimestamp":"1539459703266910800"}},
>[junit4]>   "router":{
>[junit4]> "name":"compositeId",
>[junit4]> "field":"shard_s"},
>[junit4]>   "maxShardsPerNode":"-1",
>[junit4]>   "autoAddReplicas":"false",
>[junit4]>   "nrtReplicas":1,
>[junit4]>   "tlogReplicas":0}
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([3CD4284489C09DB4:B480179E273CF04C]:0)
>[junit4]>  at 
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.lambda$testBackupAndRestore$1(AbstractCloudBackupRestoreTestCase.java:339)
>[junit4]>  at java.util.HashMap.forEach(HashMap.java:1289)
>[junit4]>  at 
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.testBackupAndRestore(AbstractCloudBackupRestoreTestCase.java:338)
>[junit4]>  at 
> org.apache.solr.cloud.api.c

Re: Propose CHANGES.txt releases begin with the categories (empty)

[Mikhail Khludnev]

It's fine, David.

On Tue, Jun 25, 2019 at 7:40 AM David Smiley 
wrote:

> Looking at Solr's CHANGES.txt for 8.2 I see we have some sections:
> "Upgrade Notes", "New Features", "Bug Fixes", and "Other Changes".  There
> is no "Improvements" so no surprise here, the New Features category has
> issues that ought to be listed as such.  I think the order vary as well.  I
> propose that on new releases, the initial state of the next release in
> CHANGES.txt have these sections.  They can easily be removed at the
> upcoming release if there are no such sections, or they could stay as
> empty.  It seems addVersion.py is the code that sets this up.  Any opinions?
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>


-- 
Sincerely yours
Mikhail Khludnev

[GitHub] [lucene-solr] iverase opened a new pull request #741: LUCENE-8879: Improve BKDRadixSelector tests

[GitBox]

iverase opened a new pull request #741: LUCENE-8879: Improve BKDRadixSelector 
tests
URL: https://github.com/apache/lucene-solr/pull/741
 
 
   This issue just add some test specifically for the sorting capability of 
class BKDRadixSelector and improves the existing ones for the selection 
capabilities.


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


With regards,
Apache Git Services

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

[jira] [Commented] (SOLR-12866) Reproducing TestLocalFSCloudBackupRestore and TestHdfsCloudBackupRestore failures

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12866:


Commit 4589bbe47bd2ae46eb5418a3b538c020d9122ad3 in lucene-solr's branch 
refs/heads/master from Mikhail Khludnev
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4589bbe ]

SOLR-12866: Turn TestHdfsCloudBackupRestore ON. No changes yet.


> Reproducing TestLocalFSCloudBackupRestore and TestHdfsCloudBackupRestore 
> failures
> -
>
> Key: SOLR-12866
> URL: https://issues.apache.org/jira/browse/SOLR-12866
> Project: Solr
>  Issue Type: Task
>Reporter: Steve Rowe
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12866.patch, SOLR-12866.patch, SOLR-12866.patch, 
> SOLR-12866.patch, screenshot-1.png
>
>
> From [https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-7.x/185/], 
> both tests failed 10/10 iterations for me on branch_7x with the seed:
> {noformat}
> Checking out Revision 37fdcb02d87ec44293ec4942c75a3cb709c45418 
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestLocalFSCloudBackupRestore -Dtests.method=test 
> -Dtests.seed=3CD4284489C09DB4 -Dtests.multiplier=2 -Dtests.slow=true 
> -Dtests.badapples=true -Dtests.locale=mk-MK 
> -Dtests.timezone=Pacific/Kiritimati -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 10.8s J2 | TestLocalFSCloudBackupRestore.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Node 
> 127.0.0.1:43864_solr has 3 replicas. Expected num replicas : 2. state: 
>[junit4]> 
> DocCollection(backuprestore_restored//collections/backuprestore_restored/state.json/9)={
>[junit4]>   "pullReplicas":0,
>[junit4]>   "replicationFactor":1,
>[junit4]>   "shards":{
>[junit4]> "shard2":{
>[junit4]>   "range":"0-7fff",
>[junit4]>   "state":"active",
>[junit4]>   "replicas":{"core_node62":{
>[junit4]>   "core":"backuprestore_restored_shard2_replica_n61",
>[junit4]>   "base_url":"https://127.0.0.1:43864/solr";,
>[junit4]>   "node_name":"127.0.0.1:43864_solr",
>[junit4]>   "state":"active",
>[junit4]>   "type":"NRT",
>[junit4]>   "force_set_state":"false",
>[junit4]>   "leader":"true"}},
>[junit4]>   "stateTimestamp":"1539459703266853250"},
>[junit4]> "shard1_1":{
>[junit4]>   "range":"c000-",
>[junit4]>   "state":"active",
>[junit4]>   "replicas":{"core_node64":{
>[junit4]>   
> "core":"backuprestore_restored_shard1_1_replica_n63",
>[junit4]>   "base_url":"https://127.0.0.1:43864/solr";,
>[junit4]>   "node_name":"127.0.0.1:43864_solr",
>[junit4]>   "state":"active",
>[junit4]>   "type":"NRT",
>[junit4]>   "force_set_state":"false",
>[junit4]>   "leader":"true"}},
>[junit4]>   "stateTimestamp":"1539459703266887720"},
>[junit4]> "shard1_0":{
>[junit4]>   "range":"8000-bfff",
>[junit4]>   "state":"active",
>[junit4]>   "replicas":{"core_node66":{
>[junit4]>   
> "core":"backuprestore_restored_shard1_0_replica_n65",
>[junit4]>   "base_url":"https://127.0.0.1:43864/solr";,
>[junit4]>   "node_name":"127.0.0.1:43864_solr",
>[junit4]>   "state":"active",
>[junit4]>   "type":"NRT",
>[junit4]>   "force_set_state":"false",
>[junit4]>   "leader":"true"}},
>[junit4]>   "stateTimestamp":"1539459703266910800"}},
>[junit4]>   "router":{
>[junit4]> "name":"compositeId",
>[junit4]> "field":"shard_s"},
>[junit4]>   "maxShardsPerNode":"-1",
>[junit4]>   "autoAddReplicas":"false",
>[junit4]>   "nrtReplicas":1,
>[junit4]>   "tlogReplicas":0}
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([3CD4284489C09DB4:B480179E273CF04C]:0)
>[junit4]>  at 
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.lambda$testBackupAndRestore$1(AbstractCloudBackupRestoreTestCase.java:339)
>[junit4]>  at java.util.HashMap.forEach(HashMap.java:1289)
>[junit4]>  at 
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.testBackupAndRestore(AbstractCloudBackupRestoreTestCase.java:338)
>[junit4]>  at 
> org.apache.solr.cloud.api.coll

[jira] [Created] (LUCENE-8879) Add tests for BKDRadixSelector#sort

[Ignacio Vera (JIRA)]

Ignacio Vera created LUCENE-8879:


 Summary: Add tests for BKDRadixSelector#sort
 Key: LUCENE-8879
 URL: https://issues.apache.org/jira/browse/LUCENE-8879
 Project: Lucene - Core
  Issue Type: Test
Reporter: Ignacio Vera


This issue just add some test specifically for the sorting capability of class 
BKDRadixSelector and improves the existing ones for the selection capabilities.



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

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

[jira] [Issue Comment Deleted] (SOLR-12866) Reproducing TestLocalFSCloudBackupRestore and TestHdfsCloudBackupRestore failures

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-12866:

Comment: was deleted

(was: {quote}
   [junit4] Suite: 
org.apache.solr.cloud.api.collections.TestHdfsCloudBackupRestore
   [junit4] Completed [555/866] on J1 in 85.68s, 2 tests
{quote}
It seems it works. Let's bring it back!)

> Reproducing TestLocalFSCloudBackupRestore and TestHdfsCloudBackupRestore 
> failures
> -
>
> Key: SOLR-12866
> URL: https://issues.apache.org/jira/browse/SOLR-12866
> Project: Solr
>  Issue Type: Task
>Reporter: Steve Rowe
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12866.patch, SOLR-12866.patch, SOLR-12866.patch, 
> SOLR-12866.patch, screenshot-1.png
>
>
> From [https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-7.x/185/], 
> both tests failed 10/10 iterations for me on branch_7x with the seed:
> {noformat}
> Checking out Revision 37fdcb02d87ec44293ec4942c75a3cb709c45418 
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestLocalFSCloudBackupRestore -Dtests.method=test 
> -Dtests.seed=3CD4284489C09DB4 -Dtests.multiplier=2 -Dtests.slow=true 
> -Dtests.badapples=true -Dtests.locale=mk-MK 
> -Dtests.timezone=Pacific/Kiritimati -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 10.8s J2 | TestLocalFSCloudBackupRestore.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Node 
> 127.0.0.1:43864_solr has 3 replicas. Expected num replicas : 2. state: 
>[junit4]> 
> DocCollection(backuprestore_restored//collections/backuprestore_restored/state.json/9)={
>[junit4]>   "pullReplicas":0,
>[junit4]>   "replicationFactor":1,
>[junit4]>   "shards":{
>[junit4]> "shard2":{
>[junit4]>   "range":"0-7fff",
>[junit4]>   "state":"active",
>[junit4]>   "replicas":{"core_node62":{
>[junit4]>   "core":"backuprestore_restored_shard2_replica_n61",
>[junit4]>   "base_url":"https://127.0.0.1:43864/solr";,
>[junit4]>   "node_name":"127.0.0.1:43864_solr",
>[junit4]>   "state":"active",
>[junit4]>   "type":"NRT",
>[junit4]>   "force_set_state":"false",
>[junit4]>   "leader":"true"}},
>[junit4]>   "stateTimestamp":"1539459703266853250"},
>[junit4]> "shard1_1":{
>[junit4]>   "range":"c000-",
>[junit4]>   "state":"active",
>[junit4]>   "replicas":{"core_node64":{
>[junit4]>   
> "core":"backuprestore_restored_shard1_1_replica_n63",
>[junit4]>   "base_url":"https://127.0.0.1:43864/solr";,
>[junit4]>   "node_name":"127.0.0.1:43864_solr",
>[junit4]>   "state":"active",
>[junit4]>   "type":"NRT",
>[junit4]>   "force_set_state":"false",
>[junit4]>   "leader":"true"}},
>[junit4]>   "stateTimestamp":"1539459703266887720"},
>[junit4]> "shard1_0":{
>[junit4]>   "range":"8000-bfff",
>[junit4]>   "state":"active",
>[junit4]>   "replicas":{"core_node66":{
>[junit4]>   
> "core":"backuprestore_restored_shard1_0_replica_n65",
>[junit4]>   "base_url":"https://127.0.0.1:43864/solr";,
>[junit4]>   "node_name":"127.0.0.1:43864_solr",
>[junit4]>   "state":"active",
>[junit4]>   "type":"NRT",
>[junit4]>   "force_set_state":"false",
>[junit4]>   "leader":"true"}},
>[junit4]>   "stateTimestamp":"1539459703266910800"}},
>[junit4]>   "router":{
>[junit4]> "name":"compositeId",
>[junit4]> "field":"shard_s"},
>[junit4]>   "maxShardsPerNode":"-1",
>[junit4]>   "autoAddReplicas":"false",
>[junit4]>   "nrtReplicas":1,
>[junit4]>   "tlogReplicas":0}
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([3CD4284489C09DB4:B480179E273CF04C]:0)
>[junit4]>  at 
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.lambda$testBackupAndRestore$1(AbstractCloudBackupRestoreTestCase.java:339)
>[junit4]>  at java.util.HashMap.forEach(HashMap.java:1289)
>[junit4]>  at 
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.testBackupAndRestore(AbstractCloudBackupRestoreTestCase.java:338)
>[junit4]>  at 
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.test(AbstractCloudBackupRestoreTestCase.java:144)
>[junit

[jira] [Commented] (SOLR-12866) Reproducing TestLocalFSCloudBackupRestore and TestHdfsCloudBackupRestore failures

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-12866:
-

{quote}
   [junit4] Suite: 
org.apache.solr.cloud.api.collections.TestHdfsCloudBackupRestore
   [junit4] Completed [555/866] on J1 in 85.68s, 2 tests
{quote}
It seems it works. Let's bring it back!

> Reproducing TestLocalFSCloudBackupRestore and TestHdfsCloudBackupRestore 
> failures
> -
>
> Key: SOLR-12866
> URL: https://issues.apache.org/jira/browse/SOLR-12866
> Project: Solr
>  Issue Type: Task
>Reporter: Steve Rowe
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12866.patch, SOLR-12866.patch, SOLR-12866.patch, 
> SOLR-12866.patch, screenshot-1.png
>
>
> From [https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-7.x/185/], 
> both tests failed 10/10 iterations for me on branch_7x with the seed:
> {noformat}
> Checking out Revision 37fdcb02d87ec44293ec4942c75a3cb709c45418 
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestLocalFSCloudBackupRestore -Dtests.method=test 
> -Dtests.seed=3CD4284489C09DB4 -Dtests.multiplier=2 -Dtests.slow=true 
> -Dtests.badapples=true -Dtests.locale=mk-MK 
> -Dtests.timezone=Pacific/Kiritimati -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 10.8s J2 | TestLocalFSCloudBackupRestore.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Node 
> 127.0.0.1:43864_solr has 3 replicas. Expected num replicas : 2. state: 
>[junit4]> 
> DocCollection(backuprestore_restored//collections/backuprestore_restored/state.json/9)={
>[junit4]>   "pullReplicas":0,
>[junit4]>   "replicationFactor":1,
>[junit4]>   "shards":{
>[junit4]> "shard2":{
>[junit4]>   "range":"0-7fff",
>[junit4]>   "state":"active",
>[junit4]>   "replicas":{"core_node62":{
>[junit4]>   "core":"backuprestore_restored_shard2_replica_n61",
>[junit4]>   "base_url":"https://127.0.0.1:43864/solr";,
>[junit4]>   "node_name":"127.0.0.1:43864_solr",
>[junit4]>   "state":"active",
>[junit4]>   "type":"NRT",
>[junit4]>   "force_set_state":"false",
>[junit4]>   "leader":"true"}},
>[junit4]>   "stateTimestamp":"1539459703266853250"},
>[junit4]> "shard1_1":{
>[junit4]>   "range":"c000-",
>[junit4]>   "state":"active",
>[junit4]>   "replicas":{"core_node64":{
>[junit4]>   
> "core":"backuprestore_restored_shard1_1_replica_n63",
>[junit4]>   "base_url":"https://127.0.0.1:43864/solr";,
>[junit4]>   "node_name":"127.0.0.1:43864_solr",
>[junit4]>   "state":"active",
>[junit4]>   "type":"NRT",
>[junit4]>   "force_set_state":"false",
>[junit4]>   "leader":"true"}},
>[junit4]>   "stateTimestamp":"1539459703266887720"},
>[junit4]> "shard1_0":{
>[junit4]>   "range":"8000-bfff",
>[junit4]>   "state":"active",
>[junit4]>   "replicas":{"core_node66":{
>[junit4]>   
> "core":"backuprestore_restored_shard1_0_replica_n65",
>[junit4]>   "base_url":"https://127.0.0.1:43864/solr";,
>[junit4]>   "node_name":"127.0.0.1:43864_solr",
>[junit4]>   "state":"active",
>[junit4]>   "type":"NRT",
>[junit4]>   "force_set_state":"false",
>[junit4]>   "leader":"true"}},
>[junit4]>   "stateTimestamp":"1539459703266910800"}},
>[junit4]>   "router":{
>[junit4]> "name":"compositeId",
>[junit4]> "field":"shard_s"},
>[junit4]>   "maxShardsPerNode":"-1",
>[junit4]>   "autoAddReplicas":"false",
>[junit4]>   "nrtReplicas":1,
>[junit4]>   "tlogReplicas":0}
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([3CD4284489C09DB4:B480179E273CF04C]:0)
>[junit4]>  at 
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.lambda$testBackupAndRestore$1(AbstractCloudBackupRestoreTestCase.java:339)
>[junit4]>  at java.util.HashMap.forEach(HashMap.java:1289)
>[junit4]>  at 
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.testBackupAndRestore(AbstractCloudBackupRestoreTestCase.java:338)
>[junit4]>  at 
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.test(AbstractCloudBackupRestoreTestC

[jira] [Commented] (SOLR-12866) Reproducing TestLocalFSCloudBackupRestore and TestHdfsCloudBackupRestore failures

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-12866:
-

{quote}
   [junit4] Suite: 
org.apache.solr.cloud.api.collections.TestHdfsCloudBackupRestore
   [junit4] Completed [555/866] on J1 in 85.68s, 2 tests
{quote}
It seems it works. Let's bring it back!

> Reproducing TestLocalFSCloudBackupRestore and TestHdfsCloudBackupRestore 
> failures
> -
>
> Key: SOLR-12866
> URL: https://issues.apache.org/jira/browse/SOLR-12866
> Project: Solr
>  Issue Type: Task
>Reporter: Steve Rowe
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12866.patch, SOLR-12866.patch, SOLR-12866.patch, 
> SOLR-12866.patch, screenshot-1.png
>
>
> From [https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-7.x/185/], 
> both tests failed 10/10 iterations for me on branch_7x with the seed:
> {noformat}
> Checking out Revision 37fdcb02d87ec44293ec4942c75a3cb709c45418 
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestLocalFSCloudBackupRestore -Dtests.method=test 
> -Dtests.seed=3CD4284489C09DB4 -Dtests.multiplier=2 -Dtests.slow=true 
> -Dtests.badapples=true -Dtests.locale=mk-MK 
> -Dtests.timezone=Pacific/Kiritimati -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 10.8s J2 | TestLocalFSCloudBackupRestore.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Node 
> 127.0.0.1:43864_solr has 3 replicas. Expected num replicas : 2. state: 
>[junit4]> 
> DocCollection(backuprestore_restored//collections/backuprestore_restored/state.json/9)={
>[junit4]>   "pullReplicas":0,
>[junit4]>   "replicationFactor":1,
>[junit4]>   "shards":{
>[junit4]> "shard2":{
>[junit4]>   "range":"0-7fff",
>[junit4]>   "state":"active",
>[junit4]>   "replicas":{"core_node62":{
>[junit4]>   "core":"backuprestore_restored_shard2_replica_n61",
>[junit4]>   "base_url":"https://127.0.0.1:43864/solr";,
>[junit4]>   "node_name":"127.0.0.1:43864_solr",
>[junit4]>   "state":"active",
>[junit4]>   "type":"NRT",
>[junit4]>   "force_set_state":"false",
>[junit4]>   "leader":"true"}},
>[junit4]>   "stateTimestamp":"1539459703266853250"},
>[junit4]> "shard1_1":{
>[junit4]>   "range":"c000-",
>[junit4]>   "state":"active",
>[junit4]>   "replicas":{"core_node64":{
>[junit4]>   
> "core":"backuprestore_restored_shard1_1_replica_n63",
>[junit4]>   "base_url":"https://127.0.0.1:43864/solr";,
>[junit4]>   "node_name":"127.0.0.1:43864_solr",
>[junit4]>   "state":"active",
>[junit4]>   "type":"NRT",
>[junit4]>   "force_set_state":"false",
>[junit4]>   "leader":"true"}},
>[junit4]>   "stateTimestamp":"1539459703266887720"},
>[junit4]> "shard1_0":{
>[junit4]>   "range":"8000-bfff",
>[junit4]>   "state":"active",
>[junit4]>   "replicas":{"core_node66":{
>[junit4]>   
> "core":"backuprestore_restored_shard1_0_replica_n65",
>[junit4]>   "base_url":"https://127.0.0.1:43864/solr";,
>[junit4]>   "node_name":"127.0.0.1:43864_solr",
>[junit4]>   "state":"active",
>[junit4]>   "type":"NRT",
>[junit4]>   "force_set_state":"false",
>[junit4]>   "leader":"true"}},
>[junit4]>   "stateTimestamp":"1539459703266910800"}},
>[junit4]>   "router":{
>[junit4]> "name":"compositeId",
>[junit4]> "field":"shard_s"},
>[junit4]>   "maxShardsPerNode":"-1",
>[junit4]>   "autoAddReplicas":"false",
>[junit4]>   "nrtReplicas":1,
>[junit4]>   "tlogReplicas":0}
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([3CD4284489C09DB4:B480179E273CF04C]:0)
>[junit4]>  at 
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.lambda$testBackupAndRestore$1(AbstractCloudBackupRestoreTestCase.java:339)
>[junit4]>  at java.util.HashMap.forEach(HashMap.java:1289)
>[junit4]>  at 
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.testBackupAndRestore(AbstractCloudBackupRestoreTestCase.java:338)
>[junit4]>  at 
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.test(AbstractCloudBackupRestoreTestC

[jira] [Updated] (SOLR-12979) CollapseQParser: inconsistent error handling when a field is indexed=false docValues=false

[Munendra S N (JIRA)]

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

Munendra S N updated SOLR-12979:

   Resolution: Fixed
Fix Version/s: 8.2
   Status: Resolved  (was: Patch Available)

> CollapseQParser: inconsistent error handling when a field is indexed=false 
> docValues=false
> --
>
> Key: SOLR-12979
> URL: https://issues.apache.org/jira/browse/SOLR-12979
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Munendra S N
>Priority: Major
> Fix For: 8.2
>
> Attachments: SOLR-12979.patch, SOLR-12979.patch, SOLR-12979.patch, 
> SOLR-12979.patch
>
>
> The CollapseQParser behaves oddly and gives inconsistent error messages if 
> you try to use it on a field that is {{indexed="false docValues="false"}} -- 
> particularly when {{hint=top_fc}} is also used and a NullPointerException 
> gets thrown.



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

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

[GitHub] [lucene-solr] iverase commented on issue #730: LUCENE-8868: New storing strategy for BKD tree leaves with low cardinality

[GitBox]

iverase commented on issue #730: LUCENE-8868: New storing strategy for BKD tree 
leaves with low cardinality
URL: https://github.com/apache/lucene-solr/pull/730#issuecomment-505284364
 
 
   Tests trigger the new approachbut it is true not as often as they should. I 
have added a new test that exercise the new code more often.


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


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] iverase edited a comment on issue #730: LUCENE-8868: New storing strategy for BKD tree leaves with low cardinality

[GitBox]

iverase edited a comment on issue #730: LUCENE-8868: New storing strategy for 
BKD tree leaves with low cardinality
URL: https://github.com/apache/lucene-solr/pull/730#issuecomment-505284364
 
 
   Tests trigger the new approach but it is true not as often as they should. I 
have added a new test that exercise the new code more often.


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


With regards,
Apache Git Services

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

[jira] [Commented] (SOLR-12979) CollapseQParser: inconsistent error handling when a field is indexed=false docValues=false

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12979:


Commit 438364ab94d937a450ed8bd62bc09eedab915f6e in lucene-solr's branch 
refs/heads/branch_8x from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=438364a ]

SOLR-12979: fail fast when collapse field is non-docValued & non-uninvertible

* Improve error message when collapse field is non-docValued & non-uninvertible.
  Return error code 400 instead of 500 in the above case


> CollapseQParser: inconsistent error handling when a field is indexed=false 
> docValues=false
> --
>
> Key: SOLR-12979
> URL: https://issues.apache.org/jira/browse/SOLR-12979
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-12979.patch, SOLR-12979.patch, SOLR-12979.patch, 
> SOLR-12979.patch
>
>
> The CollapseQParser behaves oddly and gives inconsistent error messages if 
> you try to use it on a field that is {{indexed="false docValues="false"}} -- 
> particularly when {{hint=top_fc}} is also used and a NullPointerException 
> gets thrown.



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

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

Propose CHANGES.txt releases begin with the categories (empty)

[David Smiley]

Looking at Solr's CHANGES.txt for 8.2 I see we have some sections: "Upgrade
Notes", "New Features", "Bug Fixes", and "Other Changes".  There is no
"Improvements" so no surprise here, the New Features category has
issues that ought to be listed as such.  I think the order vary as well.  I
propose that on new releases, the initial state of the next release in
CHANGES.txt have these sections.  They can easily be removed at the
upcoming release if there are no such sections, or they could stay as
empty.  It seems addVersion.py is the code that sets this up.  Any opinions?

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

[jira] [Commented] (SOLR-12979) CollapseQParser: inconsistent error handling when a field is indexed=false docValues=false

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12979:


Commit e0e5296abcef97e3cba4bcf35c415d5a2351dc0c in lucene-solr's branch 
refs/heads/master from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e0e5296 ]

SOLR-12979: fail fast when collapse field is non-docValued & non-uninvertible

* Improve error message when collapse field is non-docValued & non-uninvertible.
  Return error code 400 instead of 500 in the above case


> CollapseQParser: inconsistent error handling when a field is indexed=false 
> docValues=false
> --
>
> Key: SOLR-12979
> URL: https://issues.apache.org/jira/browse/SOLR-12979
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-12979.patch, SOLR-12979.patch, SOLR-12979.patch, 
> SOLR-12979.patch
>
>
> The CollapseQParser behaves oddly and gives inconsistent error messages if 
> you try to use it on a field that is {{indexed="false docValues="false"}} -- 
> particularly when {{hint=top_fc}} is also used and a NullPointerException 
> gets thrown.



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

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

[jira] [Commented] (SOLR-12866) Reproducing TestLocalFSCloudBackupRestore and TestHdfsCloudBackupRestore failures

[Lucene/Solr QA (JIRA)]

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

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

| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 2 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  5m 
10s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  4m 
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  4m 
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  3m 13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  2m 58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  2m 58s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 94m  
4s{color} | {color:green} core in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 14m 
37s{color} | {color:green} solrj in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black}122m 51s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12866 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12972771/SOLR-12866.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP 
Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / 689fa58 |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 20 2018 |
| Default Java | LTS |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/459/testReport/ |
| modules | C: solr/core solr/solrj U: solr |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/459/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Reproducing TestLocalFSCloudBackupRestore and TestHdfsCloudBackupRestore 
> failures
> -
>
> Key: SOLR-12866
> URL: https://issues.apache.org/jira/browse/SOLR-12866
> Project: Solr
>  Issue Type: Task
>Reporter: Steve Rowe
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12866.patch, SOLR-12866.patch, SOLR-12866.patch, 
> SOLR-12866.patch, screenshot-1.png
>
>
> From [https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-7.x/185/], 
> both tests failed 10/10 iterations for me on branch_7x with the seed:
> {noformat}
> Checking out Revision 37fdcb02d87ec44293ec4942c75a3cb709c45418 
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestLocalFSCloudBackupRestore -Dtests.method=test 
> -Dtests.seed=3CD4284489C09DB4 -Dtests.multiplier=2 -Dtests.slow=true 
> -Dtests.badapples=true -Dtests.locale=mk-MK 
> -Dtests.timezone=Pacific/Kiritimati -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 10.8s J2 | TestLocalFSCloudBackupRestore.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Node 
> 127.0.0.1:43864_solr has 3 replicas. Expected num replicas : 2. state: 
>[junit4]> 
> DocCollection(backuprestore_restored//collections/backuprestore_restored/state.json/9)={
>[junit4]>   "pullReplicas":0,
>[junit4]>   "replicationFactor":1,
>[junit4]>   "shards":{
>[junit4]> "shard2":{
>[junit4]>   "range":"0-7fff",
>[junit4]>   "state":"active",
>[junit4]>   "replicas":{"core_node62":{
>[junit4]>   "core":"backuprestore_restored_shard2_replica_n61",
>[junit4]>   "base_url":"https://127.0.0.1:43864/solr";,
>[junit4]>   "node_name":"127.0.0.1:43864_solr",
>[junit4]>   "state

[jira] [Commented] (SOLR-13375) Dimensional Routed Aliases

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-13375:
-

Which "a SolrParams wrapper instance" is this?

> Dimensional Routed Aliases
> --
>
> Key: SOLR-13375
> URL: https://issues.apache.org/jira/browse/SOLR-13375
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Affects Versions: master (9.0)
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Major
> Attachments: SOLR-13375.patch
>
>
> Current available routed aliases are restricted to a single field. This 
> feature will allow Solr to provide data driven collection access, creation 
> and management based on multiple fields in a document. The collections will 
> be queried and updated in a unified manner via an alias. Current routing is 
> restricted to the values of a single field. The particularly useful 
> combination at this time will be Category X Time routing but Category X 
> Category may also be useful. More importantly, if additional routing schemes 
> are created in the future (either as contributions or as custom code by 
> users) combination among these should be supported. 
> It is expected that not all combinations will be useful, and that 
> determination of usefulness I expect to leave up to the user. Some Routing 
> schemes may need to be limited to be the leaf/last routing scheme for 
> technical reasons, though I'm not entirely convinced of that yet. If so, a 
> flag will be added to the RoutedAlias interface.
> Initial desire is to support two levels, though if arbitrary levels can be 
> supported easily that will be done.
> This could also have been called CompositeRoutedAlias, but that creates a TLA 
> clash with CategoryRoutedAlias.



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

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

[jira] [Resolved] (SOLR-13367) Highlighting fails for Range queries on Multi-valued String fields

[David Smiley (JIRA)]

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

David Smiley resolved SOLR-13367.
-
   Resolution: Fixed
Fix Version/s: 8.2

I know this is debatable but I categorized this in CHANGES.txt under new 
features instead of as a bug, because I think of highlighting's support for 
certain queries as this way.  "Improvement" would have been my first choice but 
I didn't see a category for it on this release; I may raise an issue about that.

> Highlighting fails for Range queries on Multi-valued String fields
> --
>
> Key: SOLR-13367
> URL: https://issues.apache.org/jira/browse/SOLR-13367
> Project: Solr
>  Issue Type: Bug
>  Components: highlighter
>Affects Versions: 7.5, 7.7.1
> Environment: RedHat Linux v7
> Java 1.8.0_201
>Reporter: Karl Wolf
>Assignee: David Smiley
>Priority: Major
> Fix For: 8.2
>
> Attachments: SOLR-13367.patch, SOLR-13367.patch, SOLR-13367.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Range queries against multi-valued string fields produces useless 
> highlighting, even though "hl.highlightMultiTerm":"true"
> I have uncovered what I believe is a bug. At the very lease it is a 
> difference in behavior between Solr v5.1.0 and v7.5.0 (and v7.7.1).
> I have a multi-valued string Field defined in my schema as:
>  
>   multiValued="true" />
> I am using a query containing a Range clause and I am using highlighting to 
> get the list of values that actually matched the range query.
> All examples below were using the appropriate Solr Admin Server SolrCore 
> Query page.
>  



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

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

[jira] [Commented] (SOLR-13367) Highlighting fails for Range queries on Multi-valued String fields

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13367:


Commit 5259e964b5665d726ccd1391925057a1cab39ef2 in lucene-solr's branch 
refs/heads/branch_8x from David Wayne Smiley
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=5259e96 ]

SOLR-13367: Range queries will now highlight in hl.method=unified mode.
Lucene MatchesUtils.disjunction method for disjunction over
 BytesRefIterator terms.


> Highlighting fails for Range queries on Multi-valued String fields
> --
>
> Key: SOLR-13367
> URL: https://issues.apache.org/jira/browse/SOLR-13367
> Project: Solr
>  Issue Type: Bug
>  Components: highlighter
>Affects Versions: 7.5, 7.7.1
> Environment: RedHat Linux v7
> Java 1.8.0_201
>Reporter: Karl Wolf
>Assignee: David Smiley
>Priority: Major
> Attachments: SOLR-13367.patch, SOLR-13367.patch, SOLR-13367.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Range queries against multi-valued string fields produces useless 
> highlighting, even though "hl.highlightMultiTerm":"true"
> I have uncovered what I believe is a bug. At the very lease it is a 
> difference in behavior between Solr v5.1.0 and v7.5.0 (and v7.7.1).
> I have a multi-valued string Field defined in my schema as:
>  
>   multiValued="true" />
> I am using a query containing a Range clause and I am using highlighting to 
> get the list of values that actually matched the range query.
> All examples below were using the appropriate Solr Admin Server SolrCore 
> Query page.
>  



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

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

[jira] [Commented] (SOLR-13367) Highlighting fails for Range queries on Multi-valued String fields

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13367:


Commit 85ec39d931c742b68cc1873da2fe17800eefda23 in lucene-solr's branch 
refs/heads/master from David Wayne Smiley
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=85ec39d ]

SOLR-13367: Range queries will now highlight in hl.method=unified mode.
Lucene MatchesUtils.disjunction method for disjunction over
 BytesRefIterator terms.


> Highlighting fails for Range queries on Multi-valued String fields
> --
>
> Key: SOLR-13367
> URL: https://issues.apache.org/jira/browse/SOLR-13367
> Project: Solr
>  Issue Type: Bug
>  Components: highlighter
>Affects Versions: 7.5, 7.7.1
> Environment: RedHat Linux v7
> Java 1.8.0_201
>Reporter: Karl Wolf
>Assignee: David Smiley
>Priority: Major
> Attachments: SOLR-13367.patch, SOLR-13367.patch, SOLR-13367.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Range queries against multi-valued string fields produces useless 
> highlighting, even though "hl.highlightMultiTerm":"true"
> I have uncovered what I believe is a bug. At the very lease it is a 
> difference in behavior between Solr v5.1.0 and v7.5.0 (and v7.7.1).
> I have a multi-valued string Field defined in my schema as:
>  
>   multiValued="true" />
> I am using a query containing a Range clause and I am using highlighting to 
> get the list of values that actually matched the range query.
> All examples below were using the appropriate Solr Admin Server SolrCore 
> Query page.
>  



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

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

[jira] [Updated] (SOLR-13375) Dimensional Routed Aliases

[Gus Heck (JIRA)]

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

Gus Heck updated SOLR-13375:

Attachment: SOLR-13375.patch

> Dimensional Routed Aliases
> --
>
> Key: SOLR-13375
> URL: https://issues.apache.org/jira/browse/SOLR-13375
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Affects Versions: master (9.0)
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Major
> Attachments: SOLR-13375.patch
>
>
> Current available routed aliases are restricted to a single field. This 
> feature will allow Solr to provide data driven collection access, creation 
> and management based on multiple fields in a document. The collections will 
> be queried and updated in a unified manner via an alias. Current routing is 
> restricted to the values of a single field. The particularly useful 
> combination at this time will be Category X Time routing but Category X 
> Category may also be useful. More importantly, if additional routing schemes 
> are created in the future (either as contributions or as custom code by 
> users) combination among these should be supported. 
> It is expected that not all combinations will be useful, and that 
> determination of usefulness I expect to leave up to the user. Some Routing 
> schemes may need to be limited to be the leaf/last routing scheme for 
> technical reasons, though I'm not entirely convinced of that yet. If so, a 
> flag will be added to the RoutedAlias interface.
> Initial desire is to support two levels, though if arbitrary levels can be 
> supported easily that will be done.
> This could also have been called CompositeRoutedAlias, but that creates a TLA 
> clash with CategoryRoutedAlias.



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

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

[jira] [Commented] (SOLR-13375) Dimensional Routed Aliases

[Gus Heck (JIRA)]

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

Gus Heck commented on SOLR-13375:
-

Attaching patch with WIP initial concept of the V1 api for this working to the 
point of creating an alias that thinks it's a DRA (but fails with a not yet 
implemented exception message if you try to send it data) API looks like this:
{code:java}
http://localhost:8983/solr/admin/collections?action=CREATEALIAS
  &name=dra_test
  &router.name=Dimensional[category,time]
  &router.0.field=myCategory_s
  &router.0.maxCardinality=20
  &router.1.field=myDate_tdt
  &router.1.start=2019-01-01T00:00:00Z/MONTH
  &router.1.interval=%2B1MONTH
  &router.1.maxFutureMs=60
  &create-collection.collection.configName=_default
  &create-collection.numShards=2
 {code}
This is not mapped into the V2 API yet because although I want to do this:
{code:java}
"routerList": {
  "type": "array",
  "description": "A list of router property sets to be used with 
router type Dimensional[foo,bar] where foo and bar are valid router type names 
(i.e. time or category). The order must correspond to the type specification in 
[] in the Dimensional type, so Dimensional[category,time] would require the 
first set of router properties to be valid for a category routed alias, and the 
second set to be valid for a time routed alias. In these sets of properties, 
router.name will be ignored in favor of the type specified in the top level 
Dimensional[] router.name",
  "items": {
"type": "object",
"additionalProperties": true
  }
}
 {code}
enabling this v2 api JSON:
{code:java}
{
"create-alias":{
"name":"dra_test2",
"router": {
"name": "Dimensional[category,time]",
"routerList" : [{
"field":"myCategory_s",
 "maxCardinality":20
}, {
"field":"myDate_tdt",
"start":"2019-01-01T00:00:00Z",
"interval":"+1MONTH",
"maxFutureMs":60
}]
},
"create-collection": {
"collection.configName":"_default",
"numShards":2
}
}
}
 {code}
this todo/assumption from SOLR-11913 is getting in the way ([~dsmiley]):
{code:java}
  public void writeMap(EntryWriter ew) throws IOException {
//TODO don't call toNamedList; more efficiently implement here
//note: multiple values, if present, are a String[] under 1 key
toNamedList().forEach((k, v) -> {
 {code}
And throwing:
{code:java}
"error": {
"metadata": [
"error-class",
"org.apache.solr.common.SolrException",
"root-error-class",
"java.lang.ArrayStoreException"
],
"msg": "java.lang.ArrayStoreException: arraycopy: element type 
mismatch: can not cast one of the elements of java.lang.Object[] to the type of 
the destination array, java.lang.String",
"code": 400
}
 {code}
The reason for this is that my configuration results in a SolrParams wrapper 
instance that has non-string (List) values in the map variable ( which carried 
along by the lambda as backing for getParams(), which returns String[] and uses 
List.toArray() with a String array parameter)... I may be able to work around 
this by not using toMap() but that's probably going to be messier

> Dimensional Routed Aliases
> --
>
> Key: SOLR-13375
> URL: https://issues.apache.org/jira/browse/SOLR-13375
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Affects Versions: master (9.0)
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Major
>
> Current available routed aliases are restricted to a single field. This 
> feature will allow Solr to provide data driven collection access, creation 
> and management based on multiple fields in a document. The collections will 
> be queried and updated in a unified manner via an alias. Current routing is 
> restricted to the values of a single field. The particularly useful 
> combination at this time will be Category X Time routing but Category X 
> Category may also be useful. More importantly, if additional routing schemes 
> are created in the future (either as contributions or as custom code by 
> users) combination among these should be supported. 
> It is expected that not all combinations will be useful, and that 
> determination of usefulness I expect to leave up to the user. Some Routing 
> schemes may n

[jira] [Commented] (SOLR-12979) CollapseQParser: inconsistent error handling when a field is indexed=false docValues=false

[Lucene/Solr QA (JIRA)]

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

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

| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 1 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  2m  
8s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  2m  
8s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  2m  
8s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  2m  8s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  2m  8s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  2m  8s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 50m 
45s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 57m 59s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12979 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12972763/SOLR-12979.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene1-us-west 4.4.0-137-generic #163~14.04.1-Ubuntu SMP Mon 
Sep 24 17:14:57 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / 689fa58 |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on July 24 2018 |
| Default Java | LTS |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/458/testReport/ |
| modules | C: solr solr/core U: solr |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/458/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> CollapseQParser: inconsistent error handling when a field is indexed=false 
> docValues=false
> --
>
> Key: SOLR-12979
> URL: https://issues.apache.org/jira/browse/SOLR-12979
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-12979.patch, SOLR-12979.patch, SOLR-12979.patch, 
> SOLR-12979.patch
>
>
> The CollapseQParser behaves oddly and gives inconsistent error messages if 
> you try to use it on a field that is {{indexed="false docValues="false"}} -- 
> particularly when {{hint=top_fc}} is also used and a NullPointerException 
> gets thrown.



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

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

[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 395 - Failure

[Apache Jenkins Server]

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

65 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.analytics.function.field.FloatFieldsTest

Error Message:
Test (or randomization for this seed) wants to use SSL, but SSL is known to 
fail on your JVM: Java HotSpot(TM) 64-Bit Server VM / 11.0.1+13-LTS

Stack Trace:
org.junit.AssumptionViolatedException: Test (or randomization for this seed) 
wants to use SSL, but SSL is known to fail on your JVM: Java HotSpot(TM) 64-Bit 
Server VM / 11.0.1+13-LTS
at __randomizedtesting.SeedInfo.seed([9FFC88A32C65748C]:0)
at 
com.carrotsearch.randomizedtesting.RandomizedTest.assumeTrue(RandomizedTest.java:725)
at 
com.carrotsearch.randomizedtesting.RandomizedTest.assumeFalse(RandomizedTest.java:733)
at 
org.apache.solr.util.SSLTestConfig.assumeSslIsSafeToTest(SSLTestConfig.java:354)
at org.apache.solr.util.SSLTestConfig.(SSLTestConfig.java:110)
at org.apache.solr.util.SSLTestConfig.(SSLTestConfig.java:82)
at 
org.apache.solr.util.RandomizeSSL$SSLRandomizer.createSSLTestConfig(RandomizeSSL.java:113)
at 
org.apache.solr.SolrTestCaseJ4.buildSSLConfig(SolrTestCaseJ4.java:503)
at 
org.apache.solr.SolrTestCaseJ4.setupTestCases(SolrTestCaseJ4.java:308)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:878)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:834)


FAILED:  
junit.framework.TestSuite.org.apache.solr.analytics.function.field.FloatFieldsTest

Error Message:


Stack Trace:
java.lang.NullPointerException
at __randomizedtesting.SeedInfo.seed([9FFC88A32C65748C]:0)
at 
org.apache.solr.analytics.function.field.AbstractAnalyticsFieldTest.closeSearcher(AbstractAnalyticsFieldTest.java:227)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:901)
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(A

[JENKINS] Lucene-Solr-8.x-Windows (64bit/jdk-11.0.3) - Build # 329 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/329/
Java: 64bit/jdk-11.0.3 -XX:+UseCompressedOops -XX:+UseSerialGC

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

Error Message:
null

Stack Trace:
java.lang.NumberFormatException: null
at 
__randomizedtesting.SeedInfo.seed([E954D24DC2CBC44:D66289C077F77E18]:0)
at java.base/java.lang.Integer.parseInt(Integer.java:614)
at java.base/java.lang.Integer.parseInt(Integer.java:770)
at 
org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:682)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:834)


FAILED:  
org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart

Error Message:
null

Stack Trace:
java.lang.NumberFormatException: null
at 
__randomizedtesting.SeedInfo.seed([E954D24DC2CBC44:D66289C077F77E18]:0)
at java.base/java.lang.Integer.parseInt(Integ

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24285/
Java: 64bit/jdk-11.0.3 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.cloud.SystemCollectionCompatTest.testBackCompat

Error Message:
Error from server at http://127.0.0.1:40327/solr/.system: Error reading input 
String Can't find resource 'schema.xml' in classpath or '/configs/.system', 
cwd=/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J1

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:40327/solr/.system: Error reading input String 
Can't find resource 'schema.xml' in classpath or '/configs/.system', 
cwd=/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J1
at 
__randomizedtesting.SeedInfo.seed([623BF1266CD045BC:12CE528F0C18ECCA]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:656)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1128)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.cloud.SystemCollectionCompatTest.setupSystemCollection(SystemCollectionCompatTest.java:104)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:972)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.Statement

[jira] [Updated] (LUCENE-8878) Provide alternative sorting utility from SortField other than FieldComparator

[Tony Xu (JIRA)]

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

Tony Xu updated LUCENE-8878:

Description: 
The `FieldComparator` has many responsibilities and users get all of them at 
once. At high level the main functionalities of `FieldComparator` are
 * Provide LeafFieldComparator
 * Allocate storage for requested number of hits
 * Read the values from DocValues/Custom source etc.
 * Compare two values

There are two major areas for improvement
 # The logic of reading values and storing them are coupled.
 # User need to specify the size in order to create a `FieldComparator` but 
sometimes the size is unknown upfront.
 # From `FieldComparator`'s API, one can't reason about thread-safety so it is 
not suitable for concurrent search.
 E.g. Can two concurrent thread use the same `FieldComparator` to call 
`getLeafComparator` for two different segments they are working on? In fact, 
almost all existing implementations of `FieldComparator` are not thread-safe.

The proposal is to enhance `SortField` with two APIs
 # {color:#14892c}int compare(Object v1, Object v2){color} – this is to compare 
two values from different docs for this field
 # {color:#14892c}ValueAccessor newValueAccessor(LeafReaderContext leaf){color} 
– This encapsulate the logic for obtaining the right implementation in order to 
read the field values.
 `ValueAccessor` should be accessed in a similar way as `DocValues` to provide 
the sort value for a document in an advance & read fashion.

With this API, hopefully we can reduce the memory usage when using 
`FieldComparator` because the users either store the sort values or at least 
the slot number besides the storage allocated by `FieldComparator` itself. 
Ideally, only once copy of the values should be stored.

The proposed API is also more friendly to concurrent search since it provides 
the `ValueAccessor` per leaf. Although same `ValueAccessor` can't be shared if 
there are more than one thread working on the same leaf, at least they can 
initialize their own `ValueAccessor`.

  was:
The `FieldComparator` has many responsibilities and users get all of them at 
once. At high level the main functionalities of `FieldComparator` are
* Manage LeafFieldComparator
* Allocate storage for requested number of hits
* Read the values from DocValues/Custom source etc.
* Compare two values 

There are two major areas for improvement
# 1. The logic of reading values and storing them are coupled.
# 2. From `FieldComparator`'s API, one can't reason about thread-safety so it 
is not suitable for concurrent search. 
E.g. Can two concurrent thread use the same `FieldComparator` to call 
`getLeafComparator` for two different segments they are working on? In fact, 
almost all existing implementations of `FieldComparator` are not thread-safe.


The proposal is to enhance `SortField` with two APIs
#1. int compare(Object v1, Object v2) -- this is to compare two values from 
different docs for this field
#2. ValueAccessor newValueAccessor(LeafReaderContext leaf) -- This encapsulate 
the logic for obtaining the right implementation in order to read the field 
values.
`ValueAccessor` should be accessed in a similar way as `DocValues` to provide 
the sort value for a document in an advance & read fashion.


With this API, hopefully we can reduce the memory usage when using 
`FieldComparator` because the users either store the sort values or at least 
the slot number besides the storage allocated by `FieldComparator` itself. 
Ideally, only once copy of the values should be stored.

The proposed API is also more friendly to concurrent search since it provides 
the `ValueAccessor` per leaf. Although same `ValueAccessor` can't be shared if 
there are more than one thread working on the same leaf, at least they can 
initialize their own `ValueAccessor`.


> Provide alternative sorting utility from SortField other than FieldComparator
> -
>
> Key: LUCENE-8878
> URL: https://issues.apache.org/jira/browse/LUCENE-8878
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Affects Versions: 8.1.1
>Reporter: Tony Xu
>Priority: Major
>
> The `FieldComparator` has many responsibilities and users get all of them at 
> once. At high level the main functionalities of `FieldComparator` are
>  * Provide LeafFieldComparator
>  * Allocate storage for requested number of hits
>  * Read the values from DocValues/Custom source etc.
>  * Compare two values
> There are two major areas for improvement
>  # The logic of reading values and storing them are coupled.
>  # User need to specify the size in order to create a `FieldComparator` but 
> sometimes the size is unknown upfront.
>  # From `FieldComparator`'s API, one can't reason about thread-safety so i

[jira] [Created] (LUCENE-8878) Provide alternative sorting utility from SortField other than FieldComparator

[Tony Xu (JIRA)]

Tony Xu created LUCENE-8878:
---

 Summary: Provide alternative sorting utility from SortField other 
than FieldComparator
 Key: LUCENE-8878
 URL: https://issues.apache.org/jira/browse/LUCENE-8878
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/search
Affects Versions: 8.1.1
Reporter: Tony Xu


The `FieldComparator` has many responsibilities and users get all of them at 
once. At high level the main functionalities of `FieldComparator` are
* Manage LeafFieldComparator
* Allocate storage for requested number of hits
* Read the values from DocValues/Custom source etc.
* Compare two values 

There are two major areas for improvement
# 1. The logic of reading values and storing them are coupled.
# 2. From `FieldComparator`'s API, one can't reason about thread-safety so it 
is not suitable for concurrent search. 
E.g. Can two concurrent thread use the same `FieldComparator` to call 
`getLeafComparator` for two different segments they are working on? In fact, 
almost all existing implementations of `FieldComparator` are not thread-safe.


The proposal is to enhance `SortField` with two APIs
#1. int compare(Object v1, Object v2) -- this is to compare two values from 
different docs for this field
#2. ValueAccessor newValueAccessor(LeafReaderContext leaf) -- This encapsulate 
the logic for obtaining the right implementation in order to read the field 
values.
`ValueAccessor` should be accessed in a similar way as `DocValues` to provide 
the sort value for a document in an advance & read fashion.


With this API, hopefully we can reduce the memory usage when using 
`FieldComparator` because the users either store the sort values or at least 
the slot number besides the storage allocated by `FieldComparator` itself. 
Ideally, only once copy of the values should be stored.

The proposed API is also more friendly to concurrent search since it provides 
the `ValueAccessor` per leaf. Although same `ValueAccessor` can't be shared if 
there are more than one thread working on the same leaf, at least they can 
initialize their own `ValueAccessor`.



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

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

[JENKINS-EA] Lucene-Solr-master-Windows (64bit/jdk-13-ea+26) - Build # 8015 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/8015/
Java: 64bit/jdk-13-ea+26 -XX:+UseCompressedOops -XX:+UseSerialGC

16 tests failed.
FAILED:  
org.apache.solr.update.processor.ParsingFieldUpdateProcessorsTest.testParseDoubleNonRootLocale

Error Message:


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


FAILED:  
org.apache.solr.update.processor.ParsingFieldUpdateProcessorsTest.testParseFloatNonRootLocale

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([FB9781B636943F8F:E04B7C679631C39

Re: 8.1.2 bug fix release

[Steve Rowe]

Hi Đạt, I re-enabled the ASF Jenkins 8.1 jobs. - Steve

> On Jun 24, 2019, at 8:09 AM, Đạt Cao Mạnh  wrote:
> 
> Hi Uwe, Steve.
> 
> Can Jenkins on branch_8_1 be resumed for 8.1.2 release? I am not sure how to 
> enable them on https://builds.apache.org/view/L/view/Lucene/ 
>  
> 
> Thanks.
> 
> On Thu, Jun 13, 2019 at 10:51 AM Ishan Chattopadhyaya 
> mailto:ichattopadhy...@gmail.com>> wrote:
> Sure Dat, sounds good.
> 
> On Thu, Jun 13, 2019 at 2:11 PM Đạt Cao Mạnh  > wrote:
> >
> > Hi Ishan,
> >
> > If upgrade Jetty seems too much for a bug fix release, I will try to 
> > upgrade only part that affect SOLR-13413 (one module). Then see how tests 
> > will behave then. Does that sound good?
> >
> > On Thu, Jun 13, 2019 at 4:51 AM Ishan Chattopadhyaya 
> > mailto:ichattopadhy...@gmail.com>> wrote:
> >>
> >> Have we vetted all other changes to Jetty? Are we sure that they don't 
> >> introduce a different regression?
> >>
> >> On Thu, 13 Jun, 2019, 4:16 AM Kevin Risden,  >> > wrote:
> >>>
> >>> +1 to 8.1.2 and the Jetty upgrade. FYI Erick created 
> >>> https://issues.apache.org/jira/browse/SOLR-13541 
> >>>  specifically for the 
> >>> Jetty upgrade.
> >>>
> >>> Kevin Risden
> >>>
> >>>
> >>> On Wed, Jun 12, 2019 at 4:47 PM Đạt Cao Mạnh  >>> > wrote:
> 
>  Hi David, yeah sure, that bug fix seems important.
>  I also want to do the upgrade Jetty 9.4.19 for 8.1.2 (fix: SOLR-13413). 
>  Do you guys have any objections?
> 
>  On Wed, Jun 12, 2019 at 3:40 PM David Smiley   > wrote:
> >
> > Yes thanks for volunteering.  Also, lets get this serious bug fix in:  
> > https://issues.apache.org/jira/browse/SOLR-13523 
> > 
> >
> > ~ David Smiley
> > Apache Lucene/Solr Search Developer
> > http://www.linkedin.com/in/davidwsmiley 
> > 
> >
> >
> > On Wed, Jun 12, 2019 at 9:27 AM Đạt Cao Mạnh  > > wrote:
> >>
> >> Hi,
> >>
> >> Just right after the 8.1.1 release has been published we’ve discovered 
> >> a serious bug in BasicAuthentication which affect all released 
> >> versions of Solr including 8.0, 8.1, 8.1.1. Details of the bug can be 
> >> found in SOLR-13510.
> >>
> >> I’m volunteering to do this release, if there are no objections, and 
> >> I’d like to create a RC early next week.
> >>
> >> --
> >> Best regards,
> >> Cao Mạnh Đạt
> >> E-mail: caomanhdat...@gmail.com 
> 
> 
> 
>  --
>  Best regards,
>  Cao Mạnh Đạt
>  E-mail: caomanhdat...@gmail.com 
> >
> >
> >
> > --
> > Best regards,
> > Cao Mạnh Đạt
> > E-mail: caomanhdat...@gmail.com 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> 
> 
> 
> 
> -- 
> Best regards,
> Cao Mạnh Đạt
> E-mail: caomanhdat...@gmail.com 

[jira] [Commented] (SOLR-12988) Known OpenJDK >= 11 SSL (TLSv1.3) bugs can cause problems with Solr

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-12988:
-

bq. This reverts commit 6d6f14d39123512b8734d63c584bceb9d7bd832f.

Sorry about that -- i inadvertently pushed a commit i was testing locally 
before it was ready -- SOLR-13574 needs fixed first before this is viable.

> Known OpenJDK >= 11 SSL (TLSv1.3) bugs can cause problems with Solr
> ---
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
>  Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
>  Labels: Java11, Java12, Java13
> Attachments: SOLR-12988.patch, SOLR-12988.patch, SOLR-12988.patch, 
> SOLR-13413.patch
>
>
> There are several known OpenJDK JVM bugs (begining with Java11, when TLS v1.3 
> support was first added) that are known to affect Solr's SSL support, and 
> have caused numerous test failures -- notably early "testing" builds of 
> OpenJDK 11, 12, & 13, as well as the officially released OpenJDK 11, 11.0.1, 
> and 11.0.2.
> From the standpoint of the Solr project, there is very little we can do to 
> mitigate these bugs, and have taken steps to ensure any code using our 
> {{SSLTestConfig}} / {{RandomizeSSL}} test-framework classes will be "SKIPed" 
> with an {{AssumptionViolatedException}} when used on JVMs that are known to 
> be problematic.
> Users who encounter any of the types of failures described below, or 
> developers who encounter test runs that "SKIP" with a message refering to 
> this issue ID, are encouraged to Upgrade their JVM. (or as a last resort: try 
> disabling "TLSv1.3" in your JVM security properties)
> 
> Examples of known bugs as they have manifested in Solr tests...
> * https://bugs.openjdk.java.net/browse/JDK-8212885
> ** "TLS 1.3 resumed session does not retain peer certificate chain"
> ** affects users with {{checkPeerNames=true}} in your SSL configuration
> ** causes 100% failure rate in Solr's 
> {{TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName}}
> ** can result in exceptions for SolrJ users, or in solr cloud server logs 
> when making intra-node requests, with a root cause of 
> "javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated"
> ** {noformat}
>[junit4]   2> Caused by: javax.net.ssl.SSLPeerUnverifiedException: peer 
> not authenticated
>[junit4]   2>  at 
> java.base/sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:526)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.verifyHostname(SSLConnectionSocketFactory.java:464)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:397)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:355)
>[junit4]   2>  at 
> org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
>[junit4]   2>  at 
> org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:359)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:381)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:237)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111)
>[junit4]   2>  at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
>[junit4]   2>  at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
>[junit4]   2>  at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56)
>[junit4]   2>  at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:542)
> {noformat}
> * https://bugs.openjdk.java.net/browse/JDK-8213202
> ** "Possible race condition in TLS 1.3 session resumption"
> ** May affect any and all Solr SSL users, although noted only in tests when 
> "clientAuth" was configured to be false
> ** Causes non-reproducing test failures, and sporadic end user exceptions 
> with a root cause of "javax.net.ssl.SSLException: Received fatal alert: 
> internal_error "
> ** SSL Debugging may indicate "Fatal (INTERNAL_ERROR): Session has no PSK"
> ** {noformat}
>[junit4]   2> Caused by: javax.ne

[jira] [Created] (SOLR-13574) harden tests that fail (usually NPE) during After/AfterClas methods if there is an assumption violation in Before/BeforeClass methods

[Hoss Man (JIRA)]

Hoss Man created SOLR-13574:
---

 Summary: harden tests that fail (usually NPE) during 
After/AfterClas methods if there is an assumption violation in 
Before/BeforeClass methods
 Key: SOLR-13574
 URL: https://issues.apache.org/jira/browse/SOLR-13574
 Project: Solr
  Issue Type: Task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man
Assignee: Hoss Man


We have a bunch of tests that blindly try to call cleanup methods on objects 
w/o sanity checking if the object exists and the cleanup is actually neccessary 
-- which may not be true, particularly there was an Assumption failure during a 
Before/BeforeClass method



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

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

[jira] [Commented] (SOLR-12988) Known OpenJDK >= 11 SSL (TLSv1.3) bugs can cause problems with Solr

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12988:


Commit 689fa583a04d3aad56dba55abdff7ef968a8feff in lucene-solr's branch 
refs/heads/master from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=689fa58 ]

Revert "SOLR-12988: SSLTestConfig has been changed to throw 
AssumptionViolatedException when tests/seeds request SSL but the JVM appears to 
be an OpenJDK version known to have SSL bugs"

This reverts commit 6d6f14d39123512b8734d63c584bceb9d7bd832f.

Reason for revert: after doing more testing I realized there are tests I 
overlooked which can (with randomized SSL usage) trigger NullPointerException
(or other related failures) in After/AfterClass due assumptions about cleanup 
that isn't actaully neccessary due to the AssumptionFailure
that may occur during Before/BeforeClass


> Known OpenJDK >= 11 SSL (TLSv1.3) bugs can cause problems with Solr
> ---
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
>  Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
>  Labels: Java11, Java12, Java13
> Attachments: SOLR-12988.patch, SOLR-12988.patch, SOLR-12988.patch, 
> SOLR-13413.patch
>
>
> There are several known OpenJDK JVM bugs (begining with Java11, when TLS v1.3 
> support was first added) that are known to affect Solr's SSL support, and 
> have caused numerous test failures -- notably early "testing" builds of 
> OpenJDK 11, 12, & 13, as well as the officially released OpenJDK 11, 11.0.1, 
> and 11.0.2.
> From the standpoint of the Solr project, there is very little we can do to 
> mitigate these bugs, and have taken steps to ensure any code using our 
> {{SSLTestConfig}} / {{RandomizeSSL}} test-framework classes will be "SKIPed" 
> with an {{AssumptionViolatedException}} when used on JVMs that are known to 
> be problematic.
> Users who encounter any of the types of failures described below, or 
> developers who encounter test runs that "SKIP" with a message refering to 
> this issue ID, are encouraged to Upgrade their JVM. (or as a last resort: try 
> disabling "TLSv1.3" in your JVM security properties)
> 
> Examples of known bugs as they have manifested in Solr tests...
> * https://bugs.openjdk.java.net/browse/JDK-8212885
> ** "TLS 1.3 resumed session does not retain peer certificate chain"
> ** affects users with {{checkPeerNames=true}} in your SSL configuration
> ** causes 100% failure rate in Solr's 
> {{TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName}}
> ** can result in exceptions for SolrJ users, or in solr cloud server logs 
> when making intra-node requests, with a root cause of 
> "javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated"
> ** {noformat}
>[junit4]   2> Caused by: javax.net.ssl.SSLPeerUnverifiedException: peer 
> not authenticated
>[junit4]   2>  at 
> java.base/sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:526)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.verifyHostname(SSLConnectionSocketFactory.java:464)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:397)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:355)
>[junit4]   2>  at 
> org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
>[junit4]   2>  at 
> org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:359)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:381)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:237)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111)
>[junit4]   2>  at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
>[junit4]   2>  at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
>[junit4]   2>  at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56)
>[junit4]   2>  at 
> org.apache.solr.client.solrj.impl.HttpSo

[jira] [Updated] (SOLR-13573) Add getters to SolrRangeQuery for lower and upper values

[Brian Rhees (JIRA)]

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

Brian Rhees updated SOLR-13573:
---
Attachment: (was: SOLR-13573.patch)

> Add getters to SolrRangeQuery for lower and upper values
> 
>
> Key: SOLR-13573
> URL: https://issues.apache.org/jira/browse/SOLR-13573
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7, 8.1.1
>Reporter: Brian Rhees
>Priority: Minor
> Attachments: SOLR-13573.patch
>
>
> SolrRangeQuery has no getters for the lower/upper values once set (other than 
> calling toString).  Adding getters will help users extract those values after 
> an object has been created.



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

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

[jira] [Updated] (SOLR-13573) Add getters to SolrRangeQuery for lower and upper values

[Brian Rhees (JIRA)]

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

Brian Rhees updated SOLR-13573:
---
Attachment: SOLR-13573.patch

> Add getters to SolrRangeQuery for lower and upper values
> 
>
> Key: SOLR-13573
> URL: https://issues.apache.org/jira/browse/SOLR-13573
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7, 8.1.1
>Reporter: Brian Rhees
>Priority: Minor
> Attachments: SOLR-13573.patch, SOLR-13573.patch
>
>
> SolrRangeQuery has no getters for the lower/upper values once set (other than 
> calling toString).  Adding getters will help users extract those values after 
> an object has been created.



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

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

[jira] [Updated] (SOLR-13573) Add getters to SolrRangeQuery for lower and upper values

[Brian Rhees (JIRA)]

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

Brian Rhees updated SOLR-13573:
---
Attachment: SOLR-13573.patch

> Add getters to SolrRangeQuery for lower and upper values
> 
>
> Key: SOLR-13573
> URL: https://issues.apache.org/jira/browse/SOLR-13573
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7, 8.1.1
>Reporter: Brian Rhees
>Priority: Minor
> Attachments: SOLR-13573.patch
>
>
> SolrRangeQuery has no getters for the lower/upper values once set (other than 
> calling toString).  Adding getters will help users extract those values after 
> an object has been created.



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

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

[jira] [Updated] (SOLR-13573) Add getters to SolrRangeQuery for lower and upper values

[Brian Rhees (JIRA)]

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

Brian Rhees updated SOLR-13573:
---
Status: Patch Available  (was: Open)

> Add getters to SolrRangeQuery for lower and upper values
> 
>
> Key: SOLR-13573
> URL: https://issues.apache.org/jira/browse/SOLR-13573
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7, 8.1.1
>Reporter: Brian Rhees
>Priority: Minor
> Attachments: SOLR-13573.patch
>
>
> SolrRangeQuery has no getters for the lower/upper values once set (other than 
> calling toString).  Adding getters will help users extract those values after 
> an object has been created.



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

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

[jira] [Commented] (LUCENE-8865) Use incoming thread for execution if IndexSearcher has an executor

[Tony Xu (JIRA)]

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

Tony Xu commented on LUCENE-8865:
-

I randomly came across the issue, this is a nice change! Were you able to 
measure the improvement?

>  Use incoming thread for execution if IndexSearcher has an executor
> ---
>
> Key: LUCENE-8865
> URL: https://issues.apache.org/jira/browse/LUCENE-8865
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Simon Willnauer
>Priority: Major
> Fix For: master (9.0), 8.2
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> Today we don't utilize the incoming thread for a search when IndexSearcher
> has an executor. This thread is only idleing but can be used to execute a 
> search
> once all other collectors are dispatched.



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

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

[jira] [Created] (SOLR-13573) Add getters to SolrRangeQuery for lower and upper values

[Brian Rhees (JIRA)]

Brian Rhees created SOLR-13573:
--

 Summary: Add getters to SolrRangeQuery for lower and upper values
 Key: SOLR-13573
 URL: https://issues.apache.org/jira/browse/SOLR-13573
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 8.1.1, 7.7
Reporter: Brian Rhees


SolrRangeQuery has no getters for the lower/upper values once set (other than 
calling toString).  Adding getters will help users extract those values after 
an object has been created.



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

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

[jira] [Commented] (SOLR-12988) Known OpenJDK >= 11 SSL (TLSv1.3) bugs can cause problems with Solr

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12988:


Commit 6d6f14d39123512b8734d63c584bceb9d7bd832f in lucene-solr's branch 
refs/heads/master from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6d6f14d ]

SOLR-12988: SSLTestConfig has been changed to throw AssumptionViolatedException 
when tests/seeds request SSL but the JVM appears to be an OpenJDK version known 
to have SSL bugs


> Known OpenJDK >= 11 SSL (TLSv1.3) bugs can cause problems with Solr
> ---
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
>  Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
>  Labels: Java11, Java12, Java13
> Attachments: SOLR-12988.patch, SOLR-12988.patch, SOLR-12988.patch, 
> SOLR-13413.patch
>
>
> There are several known OpenJDK JVM bugs (begining with Java11, when TLS v1.3 
> support was first added) that are known to affect Solr's SSL support, and 
> have caused numerous test failures -- notably early "testing" builds of 
> OpenJDK 11, 12, & 13, as well as the officially released OpenJDK 11, 11.0.1, 
> and 11.0.2.
> From the standpoint of the Solr project, there is very little we can do to 
> mitigate these bugs, and have taken steps to ensure any code using our 
> {{SSLTestConfig}} / {{RandomizeSSL}} test-framework classes will be "SKIPed" 
> with an {{AssumptionViolatedException}} when used on JVMs that are known to 
> be problematic.
> Users who encounter any of the types of failures described below, or 
> developers who encounter test runs that "SKIP" with a message refering to 
> this issue ID, are encouraged to Upgrade their JVM. (or as a last resort: try 
> disabling "TLSv1.3" in your JVM security properties)
> 
> Examples of known bugs as they have manifested in Solr tests...
> * https://bugs.openjdk.java.net/browse/JDK-8212885
> ** "TLS 1.3 resumed session does not retain peer certificate chain"
> ** affects users with {{checkPeerNames=true}} in your SSL configuration
> ** causes 100% failure rate in Solr's 
> {{TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName}}
> ** can result in exceptions for SolrJ users, or in solr cloud server logs 
> when making intra-node requests, with a root cause of 
> "javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated"
> ** {noformat}
>[junit4]   2> Caused by: javax.net.ssl.SSLPeerUnverifiedException: peer 
> not authenticated
>[junit4]   2>  at 
> java.base/sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:526)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.verifyHostname(SSLConnectionSocketFactory.java:464)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:397)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:355)
>[junit4]   2>  at 
> org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
>[junit4]   2>  at 
> org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:359)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:381)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:237)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111)
>[junit4]   2>  at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
>[junit4]   2>  at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
>[junit4]   2>  at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56)
>[junit4]   2>  at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:542)
> {noformat}
> * https://bugs.openjdk.java.net/browse/JDK-8213202
> ** "Possible race condition in TLS 1.3 session resumption"
> ** May affect any and all Solr SSL users, although noted only in tests when 
> "clientAuth" was configured to be false
> ** Causes non-reproducing test failures, and sporadic end user exceptions 
> with a root cause of "javax.ne

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-13-ea+26) - Build # 24284 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24284/
Java: 64bit/jdk-13-ea+26 -XX:-UseCompressedOops -XX:+UseParallelGC

8 tests failed.
FAILED:  
org.apache.solr.update.processor.ParsingFieldUpdateProcessorsTest.testParseFloatNonRootLocale

Error Message:


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


FAILED:  
org.apache.solr.update.processor.ParsingFieldUpdateProcessorsTest.testParseDoubleNonRootLocale

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([ADD588C2EEAA984F:BA2E4525EAD2F2AD

[jira] [Commented] (SOLR-13472) HTTP requests to a node that does not hold a core of the collection are unauthorized

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-13472:
-

I am able to reproduce this problem and looking at possible causes.

> HTTP requests to a node that does not hold a core of the collection are 
> unauthorized
> 
>
> Key: SOLR-13472
> URL: https://issues.apache.org/jira/browse/SOLR-13472
> Project: Solr
>  Issue Type: Bug
>  Components: Authorization
>Affects Versions: 7.7.1, 8.0
>Reporter: adfel
>Assignee: Ishan Chattopadhyaya
>Priority: Minor
>  Labels: security
>
> When creating collection in SolrCloud, collection is available for queries 
> and updates through all Solr nodes, in particular nodes that does not hold 
> one of collection's cores. This is expected behaviour that works when using 
> SolrJ client or HTTP requests.
> When enabling authorization rules it seems that this behaviour is broken for 
> HTTP requests:
>  - executing request to a node that holds part of the collection (core) obey 
> to authorization rules as expected.
>  - other nodes respond with code 403 - unauthorized request.
> SolrJ still works as expected.
> Tested both with BasicAuthPlugin and KerberosPlugin authentication plugins.
> +Steps for reproduce:+
> 1. Create a cloud made of 2 nodes (node_1, node_2).
> 2. Configure authentication and authorization by uploading following 
> security.json file to zookeeper:
>  
> {code:java}
> {
>  "authentication": {
>"blockUnknown": true,
>"class": "solr.BasicAuthPlugin",
>"credentials": {
>  "solr": "'solr' user password_hash",
>  "indexer_app": "'indexer_app' password_hash",
>  "read_user": "'read_user' password_hash"
>}
>  },
>  "authorization": {
>"class": "solr.RuleBasedAuthorizationPlugin",
>"permissions": [
>  {
>"name": "read",
>"role": "*"
>  },
>  {
>"name": "update",
>"role": [
>  "indexer",
>  "admin"
>]
>  },
>  {
>"name": "all",
>"role": "admin"
>  }
>],
>"user-role": {
>  "solr": "admin",
>  "indexer_app": "indexer"
>}
>  }
> }{code}
>  
> 3. create 'test' collection with one shard on *node_1*.
> -- 
> The following requests expected to succeed but return 403 status 
> (unauthorized request):
> {code:java}
> curl -u read_user:read_user "http://node_2/solr/test/select?q=*:*";
> curl -u indexer_app:indexer_app "http://node_2/solr/test/select?q=*:*";
> curl -u indexer_app:indexer_app "http://node_2/solr/test/update?commit=true";
> {code}
>  
> Authenticated '_solr_' user requests works as expected. My guess is due to 
> the special '_all_' role.



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

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

[jira] [Commented] (SOLR-7189) Allow DIH to extract content from embedded documents via Tika

[Nicolas Larcipretti (JIRA)]

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

Nicolas Larcipretti commented on SOLR-7189:
---

Does this solution works with PDF's as well? I was able to extract text from 
images (png) and images within docx, but could not with images within PDF's.

 

Here's some info:



Solr version: 8.1.1 

Tesseract version: 3.04.01

PDF parser: "X-Parsed-By", [ "org.apache.tika.parser.DefaultParser", 
"org.apache.tika.parser.pdf.PDFParser" ]

 

> Allow DIH to extract content from embedded documents via Tika
> -
>
> Key: SOLR-7189
> URL: https://issues.apache.org/jira/browse/SOLR-7189
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 5.0
>Reporter: Tim Allison
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: 5.1, 6.0
>
> Attachments: SOLR-7189.patch, test_recursive_embedded.docx
>
>
> DIH's TikaEntityProcessor doesn't currently extract content from embedded 
> documents/attachments within a file.  It might be useful if users could 
> configure whether or not to include extraction of content from embedded 
> documents.



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

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

[jira] [Commented] (SOLR-13404) group.query doesn't work in distrib mode when group.format=simple

[Lucene/Solr QA (JIRA)]

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

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

| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 1 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
55s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
55s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m 
55s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  1m 55s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  1m 55s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  1m 55s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 49m 
56s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 56m 38s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-13404 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12972742/SOLR-13404.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene1-us-west 4.4.0-137-generic #163~14.04.1-Ubuntu SMP Mon 
Sep 24 17:14:57 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / 9cfba4a |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on July 24 2018 |
| Default Java | LTS |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/457/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/457/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> group.query doesn't work in distrib mode when group.format=simple
> -
>
> Key: SOLR-13404
> URL: https://issues.apache.org/jira/browse/SOLR-13404
> Project: Solr
>  Issue Type: Bug
>Reporter: Munendra S N
>Priority: Major
> Attachments: SOLR-13404.patch, SOLR-13404.patch
>
>
> While working on SOLR-12248, found that for group.query response is returned 
> only when group.format=grouped(default format) in distrib mode. For 
> group.main=true, request fails with AIOOE and for group.format=simple, no 
> grouped is returned



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

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

[jira] [Commented] (LUCENE-8875) Should TopScoreDocCollector Always Populate Sentinel Values?

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8875:
--

Aggregates don't have this issue since they don't track top hits?

+1 to having a separate collector for large N values in sandbox.

> Should TopScoreDocCollector Always Populate Sentinel Values?
> 
>
> Key: LUCENE-8875
> URL: https://issues.apache.org/jira/browse/LUCENE-8875
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Major
>
> TopScoreDocCollector always initializes HitQueue as the PQ implementation, 
> and instruct HitQueue to populate with sentinels. While this is a great 
> safety mechanism, for very large datasets where the query's selectivity is 
> high, the sentinel population can be redundant and can become a large enough 
> bottleneck in itself. Does it make sense to introduce a new parameter in 
> TopScoreDocCollector which uses a heuristic (say number of hits > 10k) and 
> does not populate sentinels?



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

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

[jira] [Commented] (SOLR-12979) CollapseQParser: inconsistent error handling when a field is indexed=false docValues=false

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-12979:
-

+1

> CollapseQParser: inconsistent error handling when a field is indexed=false 
> docValues=false
> --
>
> Key: SOLR-12979
> URL: https://issues.apache.org/jira/browse/SOLR-12979
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-12979.patch, SOLR-12979.patch, SOLR-12979.patch, 
> SOLR-12979.patch
>
>
> The CollapseQParser behaves oddly and gives inconsistent error messages if 
> you try to use it on a field that is {{indexed="false docValues="false"}} -- 
> particularly when {{hint=top_fc}} is also used and a NullPointerException 
> gets thrown.



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

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

[jira] [Updated] (SOLR-12866) Reproducing TestLocalFSCloudBackupRestore and TestHdfsCloudBackupRestore failures

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-12866:

Attachment: SOLR-12866.patch

> Reproducing TestLocalFSCloudBackupRestore and TestHdfsCloudBackupRestore 
> failures
> -
>
> Key: SOLR-12866
> URL: https://issues.apache.org/jira/browse/SOLR-12866
> Project: Solr
>  Issue Type: Task
>Reporter: Steve Rowe
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12866.patch, SOLR-12866.patch, SOLR-12866.patch, 
> SOLR-12866.patch, screenshot-1.png
>
>
> From [https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-7.x/185/], 
> both tests failed 10/10 iterations for me on branch_7x with the seed:
> {noformat}
> Checking out Revision 37fdcb02d87ec44293ec4942c75a3cb709c45418 
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestLocalFSCloudBackupRestore -Dtests.method=test 
> -Dtests.seed=3CD4284489C09DB4 -Dtests.multiplier=2 -Dtests.slow=true 
> -Dtests.badapples=true -Dtests.locale=mk-MK 
> -Dtests.timezone=Pacific/Kiritimati -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 10.8s J2 | TestLocalFSCloudBackupRestore.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Node 
> 127.0.0.1:43864_solr has 3 replicas. Expected num replicas : 2. state: 
>[junit4]> 
> DocCollection(backuprestore_restored//collections/backuprestore_restored/state.json/9)={
>[junit4]>   "pullReplicas":0,
>[junit4]>   "replicationFactor":1,
>[junit4]>   "shards":{
>[junit4]> "shard2":{
>[junit4]>   "range":"0-7fff",
>[junit4]>   "state":"active",
>[junit4]>   "replicas":{"core_node62":{
>[junit4]>   "core":"backuprestore_restored_shard2_replica_n61",
>[junit4]>   "base_url":"https://127.0.0.1:43864/solr";,
>[junit4]>   "node_name":"127.0.0.1:43864_solr",
>[junit4]>   "state":"active",
>[junit4]>   "type":"NRT",
>[junit4]>   "force_set_state":"false",
>[junit4]>   "leader":"true"}},
>[junit4]>   "stateTimestamp":"1539459703266853250"},
>[junit4]> "shard1_1":{
>[junit4]>   "range":"c000-",
>[junit4]>   "state":"active",
>[junit4]>   "replicas":{"core_node64":{
>[junit4]>   
> "core":"backuprestore_restored_shard1_1_replica_n63",
>[junit4]>   "base_url":"https://127.0.0.1:43864/solr";,
>[junit4]>   "node_name":"127.0.0.1:43864_solr",
>[junit4]>   "state":"active",
>[junit4]>   "type":"NRT",
>[junit4]>   "force_set_state":"false",
>[junit4]>   "leader":"true"}},
>[junit4]>   "stateTimestamp":"1539459703266887720"},
>[junit4]> "shard1_0":{
>[junit4]>   "range":"8000-bfff",
>[junit4]>   "state":"active",
>[junit4]>   "replicas":{"core_node66":{
>[junit4]>   
> "core":"backuprestore_restored_shard1_0_replica_n65",
>[junit4]>   "base_url":"https://127.0.0.1:43864/solr";,
>[junit4]>   "node_name":"127.0.0.1:43864_solr",
>[junit4]>   "state":"active",
>[junit4]>   "type":"NRT",
>[junit4]>   "force_set_state":"false",
>[junit4]>   "leader":"true"}},
>[junit4]>   "stateTimestamp":"1539459703266910800"}},
>[junit4]>   "router":{
>[junit4]> "name":"compositeId",
>[junit4]> "field":"shard_s"},
>[junit4]>   "maxShardsPerNode":"-1",
>[junit4]>   "autoAddReplicas":"false",
>[junit4]>   "nrtReplicas":1,
>[junit4]>   "tlogReplicas":0}
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([3CD4284489C09DB4:B480179E273CF04C]:0)
>[junit4]>  at 
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.lambda$testBackupAndRestore$1(AbstractCloudBackupRestoreTestCase.java:339)
>[junit4]>  at java.util.HashMap.forEach(HashMap.java:1289)
>[junit4]>  at 
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.testBackupAndRestore(AbstractCloudBackupRestoreTestCase.java:338)
>[junit4]>  at 
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.test(AbstractCloudBackupRestoreTestCase.java:144)
>[junit4]>  at 
> org.apache.solr.cloud.api.collections.TestLocalFSCloudBackupRestore.test(TestLocalFSCloudBackupRestore.java:64)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> 

[jira] [Commented] (SOLR-12866) Reproducing TestLocalFSCloudBackupRestore and TestHdfsCloudBackupRestore failures

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-12866:
-

it seems like it passed 
 !screenshot-1.png! 
I'm going to bring hdfs backup test back 
 

> Reproducing TestLocalFSCloudBackupRestore and TestHdfsCloudBackupRestore 
> failures
> -
>
> Key: SOLR-12866
> URL: https://issues.apache.org/jira/browse/SOLR-12866
> Project: Solr
>  Issue Type: Task
>Reporter: Steve Rowe
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12866.patch, SOLR-12866.patch, SOLR-12866.patch, 
> screenshot-1.png
>
>
> From [https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-7.x/185/], 
> both tests failed 10/10 iterations for me on branch_7x with the seed:
> {noformat}
> Checking out Revision 37fdcb02d87ec44293ec4942c75a3cb709c45418 
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestLocalFSCloudBackupRestore -Dtests.method=test 
> -Dtests.seed=3CD4284489C09DB4 -Dtests.multiplier=2 -Dtests.slow=true 
> -Dtests.badapples=true -Dtests.locale=mk-MK 
> -Dtests.timezone=Pacific/Kiritimati -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 10.8s J2 | TestLocalFSCloudBackupRestore.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Node 
> 127.0.0.1:43864_solr has 3 replicas. Expected num replicas : 2. state: 
>[junit4]> 
> DocCollection(backuprestore_restored//collections/backuprestore_restored/state.json/9)={
>[junit4]>   "pullReplicas":0,
>[junit4]>   "replicationFactor":1,
>[junit4]>   "shards":{
>[junit4]> "shard2":{
>[junit4]>   "range":"0-7fff",
>[junit4]>   "state":"active",
>[junit4]>   "replicas":{"core_node62":{
>[junit4]>   "core":"backuprestore_restored_shard2_replica_n61",
>[junit4]>   "base_url":"https://127.0.0.1:43864/solr";,
>[junit4]>   "node_name":"127.0.0.1:43864_solr",
>[junit4]>   "state":"active",
>[junit4]>   "type":"NRT",
>[junit4]>   "force_set_state":"false",
>[junit4]>   "leader":"true"}},
>[junit4]>   "stateTimestamp":"1539459703266853250"},
>[junit4]> "shard1_1":{
>[junit4]>   "range":"c000-",
>[junit4]>   "state":"active",
>[junit4]>   "replicas":{"core_node64":{
>[junit4]>   
> "core":"backuprestore_restored_shard1_1_replica_n63",
>[junit4]>   "base_url":"https://127.0.0.1:43864/solr";,
>[junit4]>   "node_name":"127.0.0.1:43864_solr",
>[junit4]>   "state":"active",
>[junit4]>   "type":"NRT",
>[junit4]>   "force_set_state":"false",
>[junit4]>   "leader":"true"}},
>[junit4]>   "stateTimestamp":"1539459703266887720"},
>[junit4]> "shard1_0":{
>[junit4]>   "range":"8000-bfff",
>[junit4]>   "state":"active",
>[junit4]>   "replicas":{"core_node66":{
>[junit4]>   
> "core":"backuprestore_restored_shard1_0_replica_n65",
>[junit4]>   "base_url":"https://127.0.0.1:43864/solr";,
>[junit4]>   "node_name":"127.0.0.1:43864_solr",
>[junit4]>   "state":"active",
>[junit4]>   "type":"NRT",
>[junit4]>   "force_set_state":"false",
>[junit4]>   "leader":"true"}},
>[junit4]>   "stateTimestamp":"1539459703266910800"}},
>[junit4]>   "router":{
>[junit4]> "name":"compositeId",
>[junit4]> "field":"shard_s"},
>[junit4]>   "maxShardsPerNode":"-1",
>[junit4]>   "autoAddReplicas":"false",
>[junit4]>   "nrtReplicas":1,
>[junit4]>   "tlogReplicas":0}
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([3CD4284489C09DB4:B480179E273CF04C]:0)
>[junit4]>  at 
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.lambda$testBackupAndRestore$1(AbstractCloudBackupRestoreTestCase.java:339)
>[junit4]>  at java.util.HashMap.forEach(HashMap.java:1289)
>[junit4]>  at 
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.testBackupAndRestore(AbstractCloudBackupRestoreTestCase.java:338)
>[junit4]>  at 
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.test(AbstractCloudBackupRestoreTestCase.java:144)
>[junit4]>  at 
> org.apache.solr.cloud.api.collections.TestLocalFSCloudBackupRestore.test(TestLocal

[jira] [Commented] (SOLR-13197) NullPointerException in org/apache/solr/handler/component/StatsField.java[251]

[Munendra S N (JIRA)]

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

Munendra S N commented on SOLR-13197:
-

Thanks [~erickerickson], marked it as resolved

> NullPointerException in org/apache/solr/handler/component/StatsField.java[251]
> --
>
> Key: SOLR-13197
> URL: https://issues.apache.org/jira/browse/SOLR-13197
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> *  Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s 
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection
> We followed [Exercise 
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from 
> the [Solr 
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html]. The 
> attached file ({{home.zip}}) gives the contents of folder {{/tmp/home}} that 
> you will obtain by following the steps below:
> {noformat}
> mkdir -p /tmp/home
> echo '' > 
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no 
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field": 
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}' 
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary 
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}' 
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> {noformat}
>Reporter: Marek
>Assignee: Munendra S N
>Priority: Minor
>  Labels: diffblue, newdev
> Fix For: 8.2
>
> Attachments: home.zip
>
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?stats=true&stats.field={!cardinalit}
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> ERROR (qtp689401025-17) [   x:films] o.a.s.s.HttpSolrCall 
> null:java.lang.NullPointerException
>   at 
> org.apache.solr.handler.component.StatsField.(StatsField.java:251)
>   at 
> org.apache.solr.handler.component.StatsInfo.(StatsComponent.java:194)
>   at 
> org.apache.solr.handler.component.StatsComponent.prepare(StatsComponent.java:47)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:272)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2559)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:394)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   [...]
> {noformat}
> There is called method 'createParser' on local variable 'qplug' which is set 
> to null on the previous line (i.e. 250). The value null is set to the local 
> variable 'qplug', because of failure in finding the sting "cardinalit" in the 
> field 'registry' of the class org.apache.solr.core.PluginBag (at line 
> org/apache/solr/core/PluginBag.java[167]).
> We found this bug using [Diffblue Microservices 
> Testing|https://www.diffblue.com/labs/?utm_source=solr-br]. Find more 
> information on this [fuzz testing 
> campaign|https://www.diffblue.com/blog/2018/12/19/diffblue-microservice-testing-a-sneak-peek-at-our-early-product-and-results?utm_source=solr-br].



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

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

[jira] [Updated] (SOLR-12866) Reproducing TestLocalFSCloudBackupRestore and TestHdfsCloudBackupRestore failures

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-12866:

Attachment: screenshot-1.png

> Reproducing TestLocalFSCloudBackupRestore and TestHdfsCloudBackupRestore 
> failures
> -
>
> Key: SOLR-12866
> URL: https://issues.apache.org/jira/browse/SOLR-12866
> Project: Solr
>  Issue Type: Task
>Reporter: Steve Rowe
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12866.patch, SOLR-12866.patch, SOLR-12866.patch, 
> screenshot-1.png
>
>
> From [https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-7.x/185/], 
> both tests failed 10/10 iterations for me on branch_7x with the seed:
> {noformat}
> Checking out Revision 37fdcb02d87ec44293ec4942c75a3cb709c45418 
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestLocalFSCloudBackupRestore -Dtests.method=test 
> -Dtests.seed=3CD4284489C09DB4 -Dtests.multiplier=2 -Dtests.slow=true 
> -Dtests.badapples=true -Dtests.locale=mk-MK 
> -Dtests.timezone=Pacific/Kiritimati -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 10.8s J2 | TestLocalFSCloudBackupRestore.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Node 
> 127.0.0.1:43864_solr has 3 replicas. Expected num replicas : 2. state: 
>[junit4]> 
> DocCollection(backuprestore_restored//collections/backuprestore_restored/state.json/9)={
>[junit4]>   "pullReplicas":0,
>[junit4]>   "replicationFactor":1,
>[junit4]>   "shards":{
>[junit4]> "shard2":{
>[junit4]>   "range":"0-7fff",
>[junit4]>   "state":"active",
>[junit4]>   "replicas":{"core_node62":{
>[junit4]>   "core":"backuprestore_restored_shard2_replica_n61",
>[junit4]>   "base_url":"https://127.0.0.1:43864/solr";,
>[junit4]>   "node_name":"127.0.0.1:43864_solr",
>[junit4]>   "state":"active",
>[junit4]>   "type":"NRT",
>[junit4]>   "force_set_state":"false",
>[junit4]>   "leader":"true"}},
>[junit4]>   "stateTimestamp":"1539459703266853250"},
>[junit4]> "shard1_1":{
>[junit4]>   "range":"c000-",
>[junit4]>   "state":"active",
>[junit4]>   "replicas":{"core_node64":{
>[junit4]>   
> "core":"backuprestore_restored_shard1_1_replica_n63",
>[junit4]>   "base_url":"https://127.0.0.1:43864/solr";,
>[junit4]>   "node_name":"127.0.0.1:43864_solr",
>[junit4]>   "state":"active",
>[junit4]>   "type":"NRT",
>[junit4]>   "force_set_state":"false",
>[junit4]>   "leader":"true"}},
>[junit4]>   "stateTimestamp":"1539459703266887720"},
>[junit4]> "shard1_0":{
>[junit4]>   "range":"8000-bfff",
>[junit4]>   "state":"active",
>[junit4]>   "replicas":{"core_node66":{
>[junit4]>   
> "core":"backuprestore_restored_shard1_0_replica_n65",
>[junit4]>   "base_url":"https://127.0.0.1:43864/solr";,
>[junit4]>   "node_name":"127.0.0.1:43864_solr",
>[junit4]>   "state":"active",
>[junit4]>   "type":"NRT",
>[junit4]>   "force_set_state":"false",
>[junit4]>   "leader":"true"}},
>[junit4]>   "stateTimestamp":"1539459703266910800"}},
>[junit4]>   "router":{
>[junit4]> "name":"compositeId",
>[junit4]> "field":"shard_s"},
>[junit4]>   "maxShardsPerNode":"-1",
>[junit4]>   "autoAddReplicas":"false",
>[junit4]>   "nrtReplicas":1,
>[junit4]>   "tlogReplicas":0}
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([3CD4284489C09DB4:B480179E273CF04C]:0)
>[junit4]>  at 
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.lambda$testBackupAndRestore$1(AbstractCloudBackupRestoreTestCase.java:339)
>[junit4]>  at java.util.HashMap.forEach(HashMap.java:1289)
>[junit4]>  at 
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.testBackupAndRestore(AbstractCloudBackupRestoreTestCase.java:338)
>[junit4]>  at 
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.test(AbstractCloudBackupRestoreTestCase.java:144)
>[junit4]>  at 
> org.apache.solr.cloud.api.collections.TestLocalFSCloudBackupRestore.test(TestLocalFSCloudBackupRestore.java:64)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> {noformat}
> {nofo

[jira] [Resolved] (SOLR-13197) NullPointerException in org/apache/solr/handler/component/StatsField.java[251]

[Munendra S N (JIRA)]

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

Munendra S N resolved SOLR-13197.
-
   Resolution: Fixed
Fix Version/s: 8.2

> NullPointerException in org/apache/solr/handler/component/StatsField.java[251]
> --
>
> Key: SOLR-13197
> URL: https://issues.apache.org/jira/browse/SOLR-13197
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> *  Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s 
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection
> We followed [Exercise 
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from 
> the [Solr 
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html]. The 
> attached file ({{home.zip}}) gives the contents of folder {{/tmp/home}} that 
> you will obtain by following the steps below:
> {noformat}
> mkdir -p /tmp/home
> echo '' > 
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no 
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field": 
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}' 
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary 
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}' 
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> {noformat}
>Reporter: Marek
>Assignee: Munendra S N
>Priority: Minor
>  Labels: diffblue, newdev
> Fix For: 8.2
>
> Attachments: home.zip
>
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?stats=true&stats.field={!cardinalit}
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> ERROR (qtp689401025-17) [   x:films] o.a.s.s.HttpSolrCall 
> null:java.lang.NullPointerException
>   at 
> org.apache.solr.handler.component.StatsField.(StatsField.java:251)
>   at 
> org.apache.solr.handler.component.StatsInfo.(StatsComponent.java:194)
>   at 
> org.apache.solr.handler.component.StatsComponent.prepare(StatsComponent.java:47)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:272)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2559)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:394)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   [...]
> {noformat}
> There is called method 'createParser' on local variable 'qplug' which is set 
> to null on the previous line (i.e. 250). The value null is set to the local 
> variable 'qplug', because of failure in finding the sting "cardinalit" in the 
> field 'registry' of the class org.apache.solr.core.PluginBag (at line 
> org/apache/solr/core/PluginBag.java[167]).
> We found this bug using [Diffblue Microservices 
> Testing|https://www.diffblue.com/labs/?utm_source=solr-br]. Find more 
> information on this [fuzz testing 
> campaign|https://www.diffblue.com/blog/2018/12/19/diffblue-microservice-testing-a-sneak-peek-at-our-early-product-and-results?utm_source=solr-br].



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

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

[jira] [Updated] (SOLR-13187) NullPointerException at o.a.solr.search.QParser.getParser

[Munendra S N (JIRA)]

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

Munendra S N updated SOLR-13187:

   Resolution: Fixed
Fix Version/s: 8.2
   Status: Resolved  (was: Patch Available)

> NullPointerException at o.a.solr.search.QParser.getParser
> -
>
> Key: SOLR-13187
> URL: https://issues.apache.org/jira/browse/SOLR-13187
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> *  Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s 
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection
> We followed [Exercise 
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from 
> the [Solr 
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html]. The 
> attached file ({{home.zip}}) gives the contents of folder {{/tmp/home}} that 
> you will obtain by following the steps below:
> {noformat}
> mkdir -p /tmp/home
> echo '' > 
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no 
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field": 
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}' 
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary 
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}' 
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> {noformat}
>Reporter: Cesar Rodriguez
>Assignee: Munendra S N
>Priority: Minor
>  Labels: diffblue, newdev
> Fix For: 8.2
>
> Attachments: SOLR-13187.patch, SOLR-13187.patch, SOLR-13187.patch, 
> home.zip
>
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?fq={!a}
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> java.lang.NullPointerException
>   at org.apache.solr.search.QParser.getParser(QParser.java:367)
>   at org.apache.solr.search.QParser.getParser(QParser.java:319)
>   at org.apache.solr.search.QParser.getParser(QParser.java:309)
>   at 
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:203)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:272)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2559)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:394)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
> [...]
> {noformat}
> The call to {{getQueryPlugin}} from 
> {{org.apache.solr.search.QParser.getParser()}}, at line 366, can return a 
> null pointer, as witnessed by the URL above. Method {{getParser}} should 
> probably check for this.
> We found this bug using [Diffblue Microservices 
> Testing|https://www.diffblue.com/labs/]. Find more information on this [fuzz 
> testing 
> campaign|https://www.diffblue.com/blog/2018/12/19/diffblue-microservice-testing-a-sneak-peek-at-our-early-product-and-results].



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

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

[jira] [Updated] (SOLR-13318) JsonFacetingResponse classes should record provide access to count fields as longs

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski updated SOLR-13318:
---
Fix Version/s: 8.1

> JsonFacetingResponse classes should record  provide access to count fields as 
> longs
> ---
>
> Key: SOLR-13318
> URL: https://issues.apache.org/jira/browse/SOLR-13318
> Project: Solr
>  Issue Type: Bug
>  Components: SolrJ
>Affects Versions: 7.7.1
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Fix For: 8.1
>
> Attachments: SOLR-13318-branch_8x.patch, SOLR-13318.patch, 
> SOLR-13318.patch
>
>
> JsonFacetingResponse and its series of dependent classes hold a variety of 
> count fields for bucket counts and various optional properties 
> ({{allBuckets}}, {{numBuckets}}, etc.).  Currently, some of the code that 
> parses these values out of the originating NamedList either stores or casts 
> the values as ints.  When doc counts are low this works fine.  But when the 
> doc counts become larger and stray into "long" territory, SolrJ is liable to 
> blow up with ClassCastExceptions.
> A user on the list reported on of these with the partial stack trace:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to 
> java.lang.Integer
>   at 
> org.apache.solr.client.solrj.response.json.NestableJsonFacet.(NestableJsonFacet.java:52)
>   at 
> org.apache.solr.client.solrj.response.QueryResponse.extractJsonFacetingInfo(QueryResponse.java:200)
>   at 
> org.apache.solr.client.solrj.response.QueryResponse.getJsonFacetingResponse(QueryResponse.java:571)
> {code}
> We should fix this so that these classes can be used without incident for any 
> doc counts.



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

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

[jira] [Assigned] (SOLR-13553) Node level custom RequestHandlers

[Noble Paul (JIRA)]

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

Noble Paul reassigned SOLR-13553:
-

Assignee: Noble Paul

> Node level custom RequestHandlers
> -
>
> Key: SOLR-13553
> URL: https://issues.apache.org/jira/browse/SOLR-13553
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>
> These components 
> * Available on every node
> * deployed at the {{CoreContainer}} level
> * Available at {{/solr/admin/ or {{/api/node/}} (v2 
> style)
> * Should implement the {{SolrRequestHandler}} interface
> The configuration looks as follows in {{solr.xml}} same as the configuration 
> in {{solrconfig.xml}}
> {code:xml}
> 
> {code}



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

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

[jira] [Commented] (SOLR-13318) JsonFacetingResponse classes should record provide access to count fields as longs

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski commented on SOLR-13318:


Thanks for bringing this up again.

It probably still makes sense to backport.  I'm not sure what the odds of a 
7.7.3 release are, but the effort required to backport this is low, and if one 
occurs, it would be nice to offer this fix to people in it.

I can put it on my todo list for this week, and will make sure I follow up this 
time.

> JsonFacetingResponse classes should record  provide access to count fields as 
> longs
> ---
>
> Key: SOLR-13318
> URL: https://issues.apache.org/jira/browse/SOLR-13318
> Project: Solr
>  Issue Type: Bug
>  Components: SolrJ
>Affects Versions: 7.7.1
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-13318-branch_8x.patch, SOLR-13318.patch, 
> SOLR-13318.patch
>
>
> JsonFacetingResponse and its series of dependent classes hold a variety of 
> count fields for bucket counts and various optional properties 
> ({{allBuckets}}, {{numBuckets}}, etc.).  Currently, some of the code that 
> parses these values out of the originating NamedList either stores or casts 
> the values as ints.  When doc counts are low this works fine.  But when the 
> doc counts become larger and stray into "long" territory, SolrJ is liable to 
> blow up with ClassCastExceptions.
> A user on the list reported on of these with the partial stack trace:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to 
> java.lang.Integer
>   at 
> org.apache.solr.client.solrj.response.json.NestableJsonFacet.(NestableJsonFacet.java:52)
>   at 
> org.apache.solr.client.solrj.response.QueryResponse.extractJsonFacetingInfo(QueryResponse.java:200)
>   at 
> org.apache.solr.client.solrj.response.QueryResponse.getJsonFacetingResponse(QueryResponse.java:571)
> {code}
> We should fix this so that these classes can be used without incident for any 
> doc counts.



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

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

[jira] [Commented] (SOLR-13122) Ability to query aliases in Solr Admin UI

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-13122:
--

bq. Is it so now that every collection created now has an alias with the same 
name pointing to it? If so, perhaps skip these aliases in the list?
It was an accidental change (mis-feature?) that slipped in into 8.1.0, fixed in 
8.1.1.

bq. Would the schema endpoint work for aliases?
If "work" means you can access / modify the schema for a collection using its 
alias, then yes.

> Ability to query aliases in Solr Admin UI
> -
>
> Key: SOLR-13122
> URL: https://issues.apache.org/jira/browse/SOLR-13122
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Reporter: mosh
>Assignee: Jan Høydahl
>Priority: Major
>  Labels: UI
>
> After having recently toyed with Time Routed Alias in SolrCloud,
> we have noticed there is no way to query an alias from the admin UI,
> since the combo box only contains the current collection in the cluster.
> Solr Admin UI ought to have a way to query these aliases, for better 
> convenience.



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

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

[jira] [Comment Edited] (SOLR-13122) Ability to query aliases in Solr Admin UI

[Gus Heck (JIRA)]

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

Gus Heck edited comment on SOLR-13122 at 6/24/19 6:26 PM:
--

{quote}
Is it so now that every collection created now has an alias with the same name 
pointing to it? If so, perhaps skip these aliases in the list?
{quote}

Not unless I've missed a recent change

{quote}
Would the schema endpoint work for aliases? Other endpoints that make sense to 
show for aliases
{quote}
[~ab] recently made a change to make aliases that refer to single collections 
work with most commands, so I expect so but he probably knows for sure

{quote}
Should we make any special treatment of an alias X that point to exactly one 
collection Y? Versus those that point to multiple collections? For clarity I 
think treating all aliases the same and not trying to be smart routing some 
requests to the alias and some to the underlying collection is the best choice
{quote}
As noted in my last comment multi-collection and routed aliases are not 
supported in many commands, because the logic becomes unclear so you probably 
do need to handle them differently. 

Documents can be enabled for single collection aliases and routed aliases to 
since you can send updates to those types of aliases. 



was (Author: gus_heck):
{quote}
Is it so now that every collection created now has an alias with the same name 
pointing to it? If so, perhaps skip these aliases in the list?
{quote}

Not unless I've missed a recent change

{quote}
Would the schema endpoint work for aliases? Other endpoints that make sense to 
show for aliases
{quote}
[~a...@getopt.org] recently made a change to make aliases that refer to single 
collections work with most commands, so I expect so but he probably knows for 
sure

{quote}
Should we make any special treatment of an alias X that point to exactly one 
collection Y? Versus those that point to multiple collections? For clarity I 
think treating all aliases the same and not trying to be smart routing some 
requests to the alias and some to the underlying collection is the best choice
{quote}
As noted in my last comment multi-collection and routed aliases are not 
supported in many commands, because the logic becomes unclear so you probably 
do need to handle them differently. 

Documents can be enabled for single collection aliases and routed aliases to 
since you can send updates to those types of aliases. 


> Ability to query aliases in Solr Admin UI
> -
>
> Key: SOLR-13122
> URL: https://issues.apache.org/jira/browse/SOLR-13122
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Reporter: mosh
>Assignee: Jan Høydahl
>Priority: Major
>  Labels: UI
>
> After having recently toyed with Time Routed Alias in SolrCloud,
> we have noticed there is no way to query an alias from the admin UI,
> since the combo box only contains the current collection in the cluster.
> Solr Admin UI ought to have a way to query these aliases, for better 
> convenience.



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

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

[jira] [Commented] (SOLR-13122) Ability to query aliases in Solr Admin UI

[Gus Heck (JIRA)]

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

Gus Heck commented on SOLR-13122:
-

{quote}
Is it so now that every collection created now has an alias with the same name 
pointing to it? If so, perhaps skip these aliases in the list?
{quote}

Not unless I've missed a recent change

{quote}
Would the schema endpoint work for aliases? Other endpoints that make sense to 
show for aliases
{quote}
[~a...@getopt.org] recently made a change to make aliases that refer to single 
collections work with most commands, so I expect so but he probably knows for 
sure

{quote}
Should we make any special treatment of an alias X that point to exactly one 
collection Y? Versus those that point to multiple collections? For clarity I 
think treating all aliases the same and not trying to be smart routing some 
requests to the alias and some to the underlying collection is the best choice
{quote}
As noted in my last comment multi-collection and routed aliases are not 
supported in many commands, because the logic becomes unclear so you probably 
do need to handle them differently. 

Documents can be enabled for single collection aliases and routed aliases to 
since you can send updates to those types of aliases. 


> Ability to query aliases in Solr Admin UI
> -
>
> Key: SOLR-13122
> URL: https://issues.apache.org/jira/browse/SOLR-13122
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Reporter: mosh
>Assignee: Jan Høydahl
>Priority: Major
>  Labels: UI
>
> After having recently toyed with Time Routed Alias in SolrCloud,
> we have noticed there is no way to query an alias from the admin UI,
> since the combo box only contains the current collection in the cluster.
> Solr Admin UI ought to have a way to query these aliases, for better 
> convenience.



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

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

[jira] [Updated] (SOLR-12979) CollapseQParser: inconsistent error handling when a field is indexed=false docValues=false

[Munendra S N (JIRA)]

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

Munendra S N updated SOLR-12979:

Attachment: SOLR-12979.patch

> CollapseQParser: inconsistent error handling when a field is indexed=false 
> docValues=false
> --
>
> Key: SOLR-12979
> URL: https://issues.apache.org/jira/browse/SOLR-12979
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Priority: Major
> Attachments: SOLR-12979.patch, SOLR-12979.patch, SOLR-12979.patch, 
> SOLR-12979.patch
>
>
> The CollapseQParser behaves oddly and gives inconsistent error messages if 
> you try to use it on a field that is {{indexed="false docValues="false"}} -- 
> particularly when {{hint=top_fc}} is also used and a NullPointerException 
> gets thrown.



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

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

[jira] [Commented] (SOLR-12979) CollapseQParser: inconsistent error handling when a field is indexed=false docValues=false

[Munendra S N (JIRA)]

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

Munendra S N commented on SOLR-12979:
-

 [^SOLR-12979.patch] 
* With changes entry

> CollapseQParser: inconsistent error handling when a field is indexed=false 
> docValues=false
> --
>
> Key: SOLR-12979
> URL: https://issues.apache.org/jira/browse/SOLR-12979
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Priority: Major
> Attachments: SOLR-12979.patch, SOLR-12979.patch, SOLR-12979.patch, 
> SOLR-12979.patch
>
>
> The CollapseQParser behaves oddly and gives inconsistent error messages if 
> you try to use it on a field that is {{indexed="false docValues="false"}} -- 
> particularly when {{hint=top_fc}} is also used and a NullPointerException 
> gets thrown.



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

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

[jira] [Assigned] (SOLR-12979) CollapseQParser: inconsistent error handling when a field is indexed=false docValues=false

[Munendra S N (JIRA)]

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

Munendra S N reassigned SOLR-12979:
---

Assignee: Munendra S N

> CollapseQParser: inconsistent error handling when a field is indexed=false 
> docValues=false
> --
>
> Key: SOLR-12979
> URL: https://issues.apache.org/jira/browse/SOLR-12979
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-12979.patch, SOLR-12979.patch, SOLR-12979.patch, 
> SOLR-12979.patch
>
>
> The CollapseQParser behaves oddly and gives inconsistent error messages if 
> you try to use it on a field that is {{indexed="false docValues="false"}} -- 
> particularly when {{hint=top_fc}} is also used and a NullPointerException 
> gets thrown.



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

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

[jira] [Commented] (SOLR-12866) Reproducing TestLocalFSCloudBackupRestore and TestHdfsCloudBackupRestore failures

[Lucene/Solr QA (JIRA)]

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

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

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m  
7s{color} | {color:blue} Precommit patch detected. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 2 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  4m 
44s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  4m 
54s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  4m 
54s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  4m 42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  4m 36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  4m 36s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  2m 
44s{color} | {color:green} core in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}  0m 54s{color} 
| {color:red} solrj in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 18m 41s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12866 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12972726/SOLR-12866.patch |
| Optional Tests |  validatesourcepatterns  compile  javac  unit  ratsources  
checkforbiddenapis  |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP 
Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / 9cfba4a |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 20 2018 |
| Default Java | LTS |
| unit | 
https://builds.apache.org/job/PreCommit-SOLR-Build/456/artifact/out/patch-unit-solr_solrj.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/456/testReport/ |
| modules | C: solr/core solr/solrj U: solr |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/456/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Reproducing TestLocalFSCloudBackupRestore and TestHdfsCloudBackupRestore 
> failures
> -
>
> Key: SOLR-12866
> URL: https://issues.apache.org/jira/browse/SOLR-12866
> Project: Solr
>  Issue Type: Task
>Reporter: Steve Rowe
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12866.patch, SOLR-12866.patch, SOLR-12866.patch
>
>
> From [https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-7.x/185/], 
> both tests failed 10/10 iterations for me on branch_7x with the seed:
> {noformat}
> Checking out Revision 37fdcb02d87ec44293ec4942c75a3cb709c45418 
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestLocalFSCloudBackupRestore -Dtests.method=test 
> -Dtests.seed=3CD4284489C09DB4 -Dtests.multiplier=2 -Dtests.slow=true 
> -Dtests.badapples=true -Dtests.locale=mk-MK 
> -Dtests.timezone=Pacific/Kiritimati -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 10.8s J2 | TestLocalFSCloudBackupRestore.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Node 
> 127.0.0.1:43864_solr has 3 replicas. Expected num replicas : 2. state: 
>[junit4]> 
> DocCollection(backuprestore_restored//collections/backuprestore_restored/state.json/9)={
>[junit4]>   "pullReplicas":0,
>[junit4]>   "replicationFactor":1,
>[junit4]>   "shards":{
>[junit4]> "shard2":{
>[junit4]>   "range":"0-7fff",
>[junit4]>   "state":"active",
>[junit4]>   "replicas":{"core_node62":{
>[junit4]>   "core":"backuprestore_restored_s

[jira] [Commented] (SOLR-13197) NullPointerException in org/apache/solr/handler/component/StatsField.java[251]

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-13197:
---

I know it's just been a few minutes, but should this be closed?

> NullPointerException in org/apache/solr/handler/component/StatsField.java[251]
> --
>
> Key: SOLR-13197
> URL: https://issues.apache.org/jira/browse/SOLR-13197
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> *  Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s 
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection
> We followed [Exercise 
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from 
> the [Solr 
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html]. The 
> attached file ({{home.zip}}) gives the contents of folder {{/tmp/home}} that 
> you will obtain by following the steps below:
> {noformat}
> mkdir -p /tmp/home
> echo '' > 
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no 
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field": 
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}' 
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary 
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}' 
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> {noformat}
>Reporter: Marek
>Assignee: Munendra S N
>Priority: Minor
>  Labels: diffblue, newdev
> Attachments: home.zip
>
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?stats=true&stats.field={!cardinalit}
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> ERROR (qtp689401025-17) [   x:films] o.a.s.s.HttpSolrCall 
> null:java.lang.NullPointerException
>   at 
> org.apache.solr.handler.component.StatsField.(StatsField.java:251)
>   at 
> org.apache.solr.handler.component.StatsInfo.(StatsComponent.java:194)
>   at 
> org.apache.solr.handler.component.StatsComponent.prepare(StatsComponent.java:47)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:272)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2559)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:394)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   [...]
> {noformat}
> There is called method 'createParser' on local variable 'qplug' which is set 
> to null on the previous line (i.e. 250). The value null is set to the local 
> variable 'qplug', because of failure in finding the sting "cardinalit" in the 
> field 'registry' of the class org.apache.solr.core.PluginBag (at line 
> org/apache/solr/core/PluginBag.java[167]).
> We found this bug using [Diffblue Microservices 
> Testing|https://www.diffblue.com/labs/?utm_source=solr-br]. Find more 
> information on this [fuzz testing 
> campaign|https://www.diffblue.com/blog/2018/12/19/diffblue-microservice-testing-a-sneak-peek-at-our-early-product-and-results?utm_source=solr-br].



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

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

[jira] [Commented] (LUCENE-8875) Should TopScoreDocCollector Always Populate Sentinel Values?

[Atri Sharma (JIRA)]

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

Atri Sharma commented on LUCENE-8875:
-

I meant Elasticsearch aggregates (although I am not sure if  this new proposed 
collector has a direct improvement in that front,  on second thought).

The meat of the point here is that I believe it is the path of minimal invasion 
if we introduced a new collector which clearly calls out that it is meant for 
cases when N is very large (>10k?), and lists out the benefits and trade offs 
clearly.

Are there any catches that are applicable here?

> Should TopScoreDocCollector Always Populate Sentinel Values?
> 
>
> Key: LUCENE-8875
> URL: https://issues.apache.org/jira/browse/LUCENE-8875
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Major
>
> TopScoreDocCollector always initializes HitQueue as the PQ implementation, 
> and instruct HitQueue to populate with sentinels. While this is a great 
> safety mechanism, for very large datasets where the query's selectivity is 
> high, the sentinel population can be redundant and can become a large enough 
> bottleneck in itself. Does it make sense to introduce a new parameter in 
> TopScoreDocCollector which uses a heuristic (say number of hits > 10k) and 
> does not populate sentinels?



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

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

[jira] [Assigned] (SOLR-13565) Node level runtime libs loaded from remote urls

[Noble Paul (JIRA)]

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

Noble Paul reassigned SOLR-13565:
-

Assignee: Noble Paul

> Node level runtime libs loaded from remote urls
> ---
>
> Key: SOLR-13565
> URL: https://issues.apache.org/jira/browse/SOLR-13565
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>
> All components loaded in CoreContainer like, AuthenticationPlugin, 
> AuthorizationPlugin, CollectionHandler, InfoHandler etc etc can have access 
> to this classloader.
> How to configure this?
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
>   "set-obj-property": {
> "runtimeLib" : {
>   "lib-name" : {
>   "url" : "http://host:port/url/of/jar";
>   "sha512":""
>   }
> }
>   }
> }' http://localhost:8983/api/cluster
> {code}
> How to update your jars?
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
>   "set-obj-property": {
> "runtimeLib" : {
>   "lib-name" : {
>   "url" : "http://host:port/url/of/new/jar";
>   "sha512":""
>   }
> }
>   }
> }' http://localhost:8983/api/cluster
> {code}
> This only loads the components used in CoreContainer and it does not need to 
> restart the Solr node
> The configuration lives in the file {{/clusterprops.json}} in ZK.



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

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

[jira] [Assigned] (SOLR-13564) Runtime libs loaded from remote URLs should be available to all components

[Noble Paul (JIRA)]

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

Noble Paul reassigned SOLR-13564:
-

Assignee: Noble Paul

> Runtime libs loaded from remote URLs should be available to all components
> --
>
> Key: SOLR-13564
> URL: https://issues.apache.org/jira/browse/SOLR-13564
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>
> The runtime libs loaded from remote URLs are loaded at core startup. This 
> means we could make this classes visible to every component (including 
> components in {{schema.xml}})
> So, if there are runtime libs with the {{"url"}} attribute the classloader 
> will be created and that'll be the classloader for all components loaded in 
> the core.
> So what about legacy jars loaded from the {{.system}} collection?
> They will be visible only to the components specially marked with 
> {{runtimeLib="true"}} . Even those components can load classes from the jars 
> loaded from remote urls



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

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

[jira] [Commented] (LUCENE-8875) Should TopScoreDocCollector Always Populate Sentinel Values?

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8875:
--

What do you mean by bucket aggregates?

> Should TopScoreDocCollector Always Populate Sentinel Values?
> 
>
> Key: LUCENE-8875
> URL: https://issues.apache.org/jira/browse/LUCENE-8875
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Major
>
> TopScoreDocCollector always initializes HitQueue as the PQ implementation, 
> and instruct HitQueue to populate with sentinels. While this is a great 
> safety mechanism, for very large datasets where the query's selectivity is 
> high, the sentinel population can be redundant and can become a large enough 
> bottleneck in itself. Does it make sense to introduce a new parameter in 
> TopScoreDocCollector which uses a heuristic (say number of hits > 10k) and 
> does not populate sentinels?



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

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

[jira] [Commented] (SOLR-12866) Reproducing TestLocalFSCloudBackupRestore and TestHdfsCloudBackupRestore failures

[Lucene/Solr QA (JIRA)]

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

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

(!) A patch to the testing environment has been detected. 
Re-executing against the patched versions to perform further tests. 
The console is at 
https://builds.apache.org/job/PreCommit-SOLR-Build/456/console in case of 
problems.


> Reproducing TestLocalFSCloudBackupRestore and TestHdfsCloudBackupRestore 
> failures
> -
>
> Key: SOLR-12866
> URL: https://issues.apache.org/jira/browse/SOLR-12866
> Project: Solr
>  Issue Type: Task
>Reporter: Steve Rowe
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12866.patch, SOLR-12866.patch, SOLR-12866.patch
>
>
> From [https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-7.x/185/], 
> both tests failed 10/10 iterations for me on branch_7x with the seed:
> {noformat}
> Checking out Revision 37fdcb02d87ec44293ec4942c75a3cb709c45418 
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestLocalFSCloudBackupRestore -Dtests.method=test 
> -Dtests.seed=3CD4284489C09DB4 -Dtests.multiplier=2 -Dtests.slow=true 
> -Dtests.badapples=true -Dtests.locale=mk-MK 
> -Dtests.timezone=Pacific/Kiritimati -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 10.8s J2 | TestLocalFSCloudBackupRestore.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Node 
> 127.0.0.1:43864_solr has 3 replicas. Expected num replicas : 2. state: 
>[junit4]> 
> DocCollection(backuprestore_restored//collections/backuprestore_restored/state.json/9)={
>[junit4]>   "pullReplicas":0,
>[junit4]>   "replicationFactor":1,
>[junit4]>   "shards":{
>[junit4]> "shard2":{
>[junit4]>   "range":"0-7fff",
>[junit4]>   "state":"active",
>[junit4]>   "replicas":{"core_node62":{
>[junit4]>   "core":"backuprestore_restored_shard2_replica_n61",
>[junit4]>   "base_url":"https://127.0.0.1:43864/solr";,
>[junit4]>   "node_name":"127.0.0.1:43864_solr",
>[junit4]>   "state":"active",
>[junit4]>   "type":"NRT",
>[junit4]>   "force_set_state":"false",
>[junit4]>   "leader":"true"}},
>[junit4]>   "stateTimestamp":"1539459703266853250"},
>[junit4]> "shard1_1":{
>[junit4]>   "range":"c000-",
>[junit4]>   "state":"active",
>[junit4]>   "replicas":{"core_node64":{
>[junit4]>   
> "core":"backuprestore_restored_shard1_1_replica_n63",
>[junit4]>   "base_url":"https://127.0.0.1:43864/solr";,
>[junit4]>   "node_name":"127.0.0.1:43864_solr",
>[junit4]>   "state":"active",
>[junit4]>   "type":"NRT",
>[junit4]>   "force_set_state":"false",
>[junit4]>   "leader":"true"}},
>[junit4]>   "stateTimestamp":"1539459703266887720"},
>[junit4]> "shard1_0":{
>[junit4]>   "range":"8000-bfff",
>[junit4]>   "state":"active",
>[junit4]>   "replicas":{"core_node66":{
>[junit4]>   
> "core":"backuprestore_restored_shard1_0_replica_n65",
>[junit4]>   "base_url":"https://127.0.0.1:43864/solr";,
>[junit4]>   "node_name":"127.0.0.1:43864_solr",
>[junit4]>   "state":"active",
>[junit4]>   "type":"NRT",
>[junit4]>   "force_set_state":"false",
>[junit4]>   "leader":"true"}},
>[junit4]>   "stateTimestamp":"1539459703266910800"}},
>[junit4]>   "router":{
>[junit4]> "name":"compositeId",
>[junit4]> "field":"shard_s"},
>[junit4]>   "maxShardsPerNode":"-1",
>[junit4]>   "autoAddReplicas":"false",
>[junit4]>   "nrtReplicas":1,
>[junit4]>   "tlogReplicas":0}
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([3CD4284489C09DB4:B480179E273CF04C]:0)
>[junit4]>  at 
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.lambda$testBackupAndRestore$1(AbstractCloudBackupRestoreTestCase.java:339)
>[junit4]>  at java.util.HashMap.forEach(HashMap.java:1289)
>[junit4]>  at 
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.testBackupAndRestore(AbstractCloudBackupRestoreTestCase.java:338)
>[junit4]>  at 
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.test(AbstractCloudBackupRestoreTestCase.java

[jira] [Assigned] (SOLR-13197) NullPointerException in org/apache/solr/handler/component/StatsField.java[251]

[Munendra S N (JIRA)]

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

Munendra S N reassigned SOLR-13197:
---

Assignee: Munendra S N

> NullPointerException in org/apache/solr/handler/component/StatsField.java[251]
> --
>
> Key: SOLR-13197
> URL: https://issues.apache.org/jira/browse/SOLR-13197
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> *  Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s 
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection
> We followed [Exercise 
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from 
> the [Solr 
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html]. The 
> attached file ({{home.zip}}) gives the contents of folder {{/tmp/home}} that 
> you will obtain by following the steps below:
> {noformat}
> mkdir -p /tmp/home
> echo '' > 
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no 
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field": 
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}' 
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary 
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}' 
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> {noformat}
>Reporter: Marek
>Assignee: Munendra S N
>Priority: Minor
>  Labels: diffblue, newdev
> Attachments: home.zip
>
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?stats=true&stats.field={!cardinalit}
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> ERROR (qtp689401025-17) [   x:films] o.a.s.s.HttpSolrCall 
> null:java.lang.NullPointerException
>   at 
> org.apache.solr.handler.component.StatsField.(StatsField.java:251)
>   at 
> org.apache.solr.handler.component.StatsInfo.(StatsComponent.java:194)
>   at 
> org.apache.solr.handler.component.StatsComponent.prepare(StatsComponent.java:47)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:272)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2559)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:394)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   [...]
> {noformat}
> There is called method 'createParser' on local variable 'qplug' which is set 
> to null on the previous line (i.e. 250). The value null is set to the local 
> variable 'qplug', because of failure in finding the sting "cardinalit" in the 
> field 'registry' of the class org.apache.solr.core.PluginBag (at line 
> org/apache/solr/core/PluginBag.java[167]).
> We found this bug using [Diffblue Microservices 
> Testing|https://www.diffblue.com/labs/?utm_source=solr-br]. Find more 
> information on this [fuzz testing 
> campaign|https://www.diffblue.com/blog/2018/12/19/diffblue-microservice-testing-a-sneak-peek-at-our-early-product-and-results?utm_source=solr-br].



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

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

[jira] [Commented] (SOLR-13197) NullPointerException in org/apache/solr/handler/component/StatsField.java[251]

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13197:


Commit 3ef5c0ee74ec3fc939a530c7733e6632a98661a2 in lucene-solr's branch 
refs/heads/branch_8x from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3ef5c0e ]

SOLR-13187: Fix NPE when invalid qParser is specified

* When non-existent qParser is specified return 400 error code
* SOLR-13197: Fix NPE when createQParser is called in StatsField


> NullPointerException in org/apache/solr/handler/component/StatsField.java[251]
> --
>
> Key: SOLR-13197
> URL: https://issues.apache.org/jira/browse/SOLR-13197
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> *  Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s 
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection
> We followed [Exercise 
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from 
> the [Solr 
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html]. The 
> attached file ({{home.zip}}) gives the contents of folder {{/tmp/home}} that 
> you will obtain by following the steps below:
> {noformat}
> mkdir -p /tmp/home
> echo '' > 
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no 
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field": 
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}' 
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary 
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}' 
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> {noformat}
>Reporter: Marek
>Priority: Minor
>  Labels: diffblue, newdev
> Attachments: home.zip
>
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?stats=true&stats.field={!cardinalit}
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> ERROR (qtp689401025-17) [   x:films] o.a.s.s.HttpSolrCall 
> null:java.lang.NullPointerException
>   at 
> org.apache.solr.handler.component.StatsField.(StatsField.java:251)
>   at 
> org.apache.solr.handler.component.StatsInfo.(StatsComponent.java:194)
>   at 
> org.apache.solr.handler.component.StatsComponent.prepare(StatsComponent.java:47)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:272)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2559)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:394)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   [...]
> {noformat}
> There is called method 'createParser' on local variable 'qplug' which is set 
> to null on the previous line (i.e. 250). The value null is set to the local 
> variable 'qplug', because of failure in finding the sting "cardinalit" in the 
> field 'registry' of the class org.apache.solr.core.PluginBag (at line 
> org/apache/solr/core/PluginBag.java[167]).
> We found this bug using [Diffblue Microservices 
> Testing|https://www.diffblue.com/labs/?utm_source=solr-br]. Find more 
> information on this [fuzz testing 
> campaign|https://www.diffblue.com/blog/2018/12/19/diffblue-microservice-testing-a-sneak-peek-at-our-early-product-and-results?utm_source=solr-br].



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

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

[jira] [Commented] (SOLR-13187) NullPointerException at o.a.solr.search.QParser.getParser

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13187:


Commit 3ef5c0ee74ec3fc939a530c7733e6632a98661a2 in lucene-solr's branch 
refs/heads/branch_8x from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3ef5c0e ]

SOLR-13187: Fix NPE when invalid qParser is specified

* When non-existent qParser is specified return 400 error code
* SOLR-13197: Fix NPE when createQParser is called in StatsField


> NullPointerException at o.a.solr.search.QParser.getParser
> -
>
> Key: SOLR-13187
> URL: https://issues.apache.org/jira/browse/SOLR-13187
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> *  Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s 
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection
> We followed [Exercise 
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from 
> the [Solr 
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html]. The 
> attached file ({{home.zip}}) gives the contents of folder {{/tmp/home}} that 
> you will obtain by following the steps below:
> {noformat}
> mkdir -p /tmp/home
> echo '' > 
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no 
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field": 
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}' 
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary 
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}' 
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> {noformat}
>Reporter: Cesar Rodriguez
>Assignee: Munendra S N
>Priority: Minor
>  Labels: diffblue, newdev
> Attachments: SOLR-13187.patch, SOLR-13187.patch, SOLR-13187.patch, 
> home.zip
>
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?fq={!a}
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> java.lang.NullPointerException
>   at org.apache.solr.search.QParser.getParser(QParser.java:367)
>   at org.apache.solr.search.QParser.getParser(QParser.java:319)
>   at org.apache.solr.search.QParser.getParser(QParser.java:309)
>   at 
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:203)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:272)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2559)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:394)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
> [...]
> {noformat}
> The call to {{getQueryPlugin}} from 
> {{org.apache.solr.search.QParser.getParser()}}, at line 366, can return a 
> null pointer, as witnessed by the URL above. Method {{getParser}} should 
> probably check for this.
> We found this bug using [Diffblue Microservices 
> Testing|https://www.diffblue.com/labs/]. Find more information on this [fuzz 
> testing 
> campaign|https://www.diffblue.com/blog/2018/12/19/diffblue-microservice-testing-a-sneak-peek-at-our-early-product-and-results].



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

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

[jira] [Commented] (LUCENE-8875) Should TopScoreDocCollector Always Populate Sentinel Values?

[Atri Sharma (JIRA)]

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

Atri Sharma commented on LUCENE-8875:
-

While I do agree that too many hits are not what top N hits are intended for, 
but some increasing popular use cases are inclined in that direction (bucket 
aggregates?) I think it would be fair to allow such users to use a different 
Collector which optimises their case while not muddling with the commonly used 
code path. WDYT?

> Should TopScoreDocCollector Always Populate Sentinel Values?
> 
>
> Key: LUCENE-8875
> URL: https://issues.apache.org/jira/browse/LUCENE-8875
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Major
>
> TopScoreDocCollector always initializes HitQueue as the PQ implementation, 
> and instruct HitQueue to populate with sentinels. While this is a great 
> safety mechanism, for very large datasets where the query's selectivity is 
> high, the sentinel population can be redundant and can become a large enough 
> bottleneck in itself. Does it make sense to introduce a new parameter in 
> TopScoreDocCollector which uses a heuristic (say number of hits > 10k) and 
> does not populate sentinels?



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

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

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

[Policeman Jenkins Server]

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

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

Error Message:
must have failed

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


FAILED:  
org.apache.solr.update.processor.ParsingFieldUpdateProcessorsTest.testParseDoubleNonRootLocale

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([1B8BB1A4826DE5CC:C707C4386158F2E]:0)
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.A

[jira] [Updated] (SOLR-12988) Known OpenJDK >= 11 SSL (TLSv1.3) bugs can cause problems with Solr

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-12988:

Description: 
There are several known OpenJDK JVM bugs (begining with Java11, when TLS v1.3 
support was first added) that are known to affect Solr's SSL support, and have 
caused numerous test failures -- notably early "testing" builds of OpenJDK 11, 
12, & 13, as well as the officially released OpenJDK 11, 11.0.1, and 11.0.2.

>From the standpoint of the Solr project, there is very little we can do to 
>mitigate these bugs, and have taken steps to ensure any code using our 
>{{SSLTestConfig}} / {{RandomizeSSL}} test-framework classes will be "SKIPed" 
>with an {{AssumptionViolatedException}} when used on JVMs that are known to be 
>problematic.

Users who encounter any of the types of failures described below, or developers 
who encounter test runs that "SKIP" with a message refering to this issue ID, 
are encouraged to Upgrade their JVM. (or as a last resort: try disabling 
"TLSv1.3" in your JVM security properties)



Examples of known bugs as they have manifested in Solr tests...

* https://bugs.openjdk.java.net/browse/JDK-8212885
** "TLS 1.3 resumed session does not retain peer certificate chain"
** affects users with {{checkPeerNames=true}} in your SSL configuration
** causes 100% failure rate in Solr's 
{{TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName}}
** can result in exceptions for SolrJ users, or in solr cloud server logs when 
making intra-node requests, with a root cause of 
"javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated"
** {noformat}
   [junit4]   2> Caused by: javax.net.ssl.SSLPeerUnverifiedException: peer not 
authenticated
   [junit4]   2>at 
java.base/sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:526)
   [junit4]   2>at 
org.apache.http.conn.ssl.SSLConnectionSocketFactory.verifyHostname(SSLConnectionSocketFactory.java:464)
   [junit4]   2>at 
org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:397)
   [junit4]   2>at 
org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:355)
   [junit4]   2>at 
org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
   [junit4]   2>at 
org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:359)
   [junit4]   2>at 
org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:381)
   [junit4]   2>at 
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:237)
   [junit4]   2>at 
org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
   [junit4]   2>at 
org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
   [junit4]   2>at 
org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111)
   [junit4]   2>at 
org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
   [junit4]   2>at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
   [junit4]   2>at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56)
   [junit4]   2>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:542)
{noformat}
* https://bugs.openjdk.java.net/browse/JDK-8213202
** "Possible race condition in TLS 1.3 session resumption"
** May affect any and all Solr SSL users, although noted only in tests when 
"clientAuth" was configured to be false
** Causes non-reproducing test failures, and sporadic end user exceptions with 
a root cause of "javax.net.ssl.SSLException: Received fatal alert: 
internal_error "
** SSL Debugging may indicate "Fatal (INTERNAL_ERROR): Session has no PSK"
** {noformat}
   [junit4]   2> Caused by: javax.net.ssl.SSLException: Received fatal alert: 
internal_error
   [junit4]   2>at 
sun.security.ssl.Alert.createSSLException(Alert.java:129) ~[?:?]
   [junit4]   2>at 
sun.security.ssl.Alert.createSSLException(Alert.java:117) ~[?:?]
   [junit4]   2>at 
sun.security.ssl.TransportContext.fatal(TransportContext.java:308) ~[?:?]
   [junit4]   2>at 
sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) ~[?:?]
   [junit4]   2>at 
sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) ~[?:?]
   [junit4]   2>at 
sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) ~[?:?]
   [junit4]   2>at 
sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) ~[?:?]
   [junit4]   2>at 
sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) 
~[?:?]
   [junit4]   2>at 
sun.security.ssl.SSLSoc

BadApple report

[Erick Erickson]

I won’t change annotations again this week. Here’s the short from:

  **Annotations will be removed from the following tests because they haven't 
failed in the last 4 rollups.

  **Methods: 2
   FullSolrCloudDistribCmdsTest.test
   SolrZkClientTest.testSimpleUpdateACLs


Failures in Hoss' reports for the last 4 rollups.

There were 543 unannotated tests that failed in Hoss' rollups. Ordered by the 
date I downloaded the rollup file, newest->oldest. See above for the dates the 
files were collected 
These tests were NOT BadApple'd or AwaitsFix'd
All tests that failed 4 weeks running will be BadApple'd unless there are 
objections

Failures in the last 4 reports..
   Report   Pct runsfails   test
 0123   4.3  961 38  
AliasIntegrationTest.testClusterStateProviderAPI
 0123   4.8  994213  BasicAuthIntegrationTest.testBasicAuth
 0123   2.8  900 20  BasicDistributedZkTest.test
 0123   2.8  900 14  DistributedFacetPivotLargeTest.test
 0123  25.0   87 22  
HdfsAutoAddReplicasIntegrationTest.testSimple
 0123   0.9  911 11  HttpPartitionTest.test
 0123   1.4  930 14  NestedShardedAtomicUpdateTest.test
 0123   1.1  809  9  OverseerTest.testOverseerFailure
 0123   0.9  915  5  ReindexCollectionTest.testBasicReindexing
 0123   2.2  929 11  RollingRestartTest.test
 0123   0.9  960  7  ShardSplitTest.testSplitShardWithRule
 0123  13.6   88  9  ShardSplitTest.testSplitWithChaosMonkey
 0123   0.9  911  7  SystemCollectionCompatTest.testBackCompat
 0123   2.3  911 16  TestDocValuesRewriteMethod.testRegexps
 0123   0.5  901  5  TestDynamicLoading.testDynamicLoading
 0123   0.5  919 19  TestRegexpRandom2.testRegexps
 0123   1.3  913 12  
TestSimpleSearchEquivalence.testBooleanBoostPropagation
 0123   1.3  913 14  
TestSimpleSearchEquivalence.testBoostQuerySimplification
 0123   0.9  913  9  
TestSimpleSearchEquivalence.testSloppyPhraseRelativePositions
 0123   1.9  899 13  TestTopDocsMerge.testSort_1

Full report attached:
DO NOT ENABLE LIST:
MoveReplicaHDFSTest.testFailedMove
MoveReplicaHDFSTest.testNormalFailedMove
TestControlledRealTimeReopenThread.testCRTReopen
TestICUNormalizer2CharFilter.testRandomStrings
TestICUTokenizerCJK
TestImpersonationWithHadoopAuth.testForwarding
TestLTRReRankingPipeline.testDifferentTopN
TestRandomChains


DO NOT ANNOTATE LIST
CdcrBidirectionalTest.testBiDir
IndexSizeTriggerTest.testMergeIntegration
IndexSizeTriggerTest.testMixedBounds
IndexSizeTriggerTest.testSplitIntegration
IndexSizeTriggerTest.testTrigger
InfixSuggestersTest.testShutdownDuringBuild
ShardSplitTest.test
ShardSplitTest.testSplitMixedReplicaTypes
ShardSplitTest.testSplitWithChaosMonkey
TestLatLonShapeQueries.testRandomBig
TestRandomChains.testRandomChainsWithLargeStrings
TestTriggerIntegration.testSearchRate

Processing file (History bit 3): HOSS-2019-06-24.csv
Processing file (History bit 2): HOSS-2019-06-17.csv
Processing file (History bit 1): HOSS-2019-06-10.csv
Processing file (History bit 0): HOSS-2019-06-03.csv


**Annotated tests that didn't fail in the last 4 weeks.

  **Tests removed from the next two lists because they were specified in 
'doNotEnable' in the properties file
 MoveReplicaHDFSTest.testNormalFailedMove

  **Annotations will be removed from the following tests because they haven't 
failed in the last 4 rollups.

  **Methods: 2
   FullSolrCloudDistribCmdsTest.test
   SolrZkClientTest.testSimpleUpdateACLs


Failures in Hoss' reports for the last 4 rollups.

There were 543 unannotated tests that failed in Hoss' rollups. Ordered by the 
date I downloaded the rollup file, newest->oldest. See above for the dates the 
files were collected 
These tests were NOT BadApple'd or AwaitsFix'd
All tests that failed 4 weeks running will be BadApple'd unless there are 
objections

Failures in the last 4 reports..
   Report   Pct runsfails   test
 0123   4.3  961 38  
AliasIntegrationTest.testClusterStateProviderAPI
 0123   4.8  994213  BasicAuthIntegrationTest.testBasicAuth
 0123   2.8  900 20  BasicDistributedZkTest.test
 0123   2.8  900 14  DistributedFacetPivotLargeTest.test
 0123  25.0   87 22  
HdfsAutoAddReplicasIntegrationTest.testSimple
 0123   0.9  911 11  HttpPartitionTest.test
 0123   1.4  930 14  NestedShardedAtomicUpdateTest.test
 0123   1.1  809  9  OverseerTest.testOverseerFailure
 0123   0.9  915  5  ReindexCollectionTest.testBasicReindexing
 0123   2.2  929 11  RollingRestartTest.test
 0123   0.9 

RE: Need to upgrade jenkins jdk-11 jobs >= 11.0.3 to fix JVM SSL bugs

[Chris Hostetter]

: sorry for the delay, I updated JDK on Policeman Jenkins. But there are 
: some things to mention:

Thanks Uwe, appreciate it

: If the SSL errors are really coming from this and Users have to install 
: 11.0.3 at minimum, we have to mention this in release notes and on the 
: web page. Especially we have to tell people to either pay Oracle to get 

Agreed -- this is being tracked in SOLR-12988, so we should probably keep 
discussion of what/where/how to inform users there -- but for now the 
priority is getting SSL testing re-enabled on jenkins jdk11 (w/11.0.3) 
since it's been silently disabled in the test code for the past 6 months 
... that way we'll have some sanity check that there aren't *OTHER* java11 
+ SSL bugs we haven't found yet, before we tell people "use 11.0.3"


: * JDK 13-ea+26 was installed on Linux and Windows
: * JDK-13-ea+shipilev-fastdebug (nightly) was updated to yesterday’s 
build) on Linux

Unfortunately on friday I discovered that a *new* bug slipped into 
13-ea+26, which garuntees SSL failures in jetty/solr (JDK-8226649) and 
still has no fix, so it looks like we need to skip SSL testing on all 
13-ea builds (even if they are current nightly builds of OpenJDK) for now.

BTW: I still don't really understand what "13-ea+shipilev-fastdebug" is -- 
can you elaborate on that?



-Hoss
http://www.lucidworks.com/

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

[jira] [Commented] (SOLR-13187) NullPointerException at o.a.solr.search.QParser.getParser

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13187:


Commit 9cfba4a728e38a7e6c59c60a377420abc769be46 in lucene-solr's branch 
refs/heads/master from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9cfba4a ]

SOLR-13187: Fix NPE when invalid qParser is specified

* When non-existent qParser is specified return 400 error code
* SOLR-13197: Fix NPE when createQParser is called in StatsField


> NullPointerException at o.a.solr.search.QParser.getParser
> -
>
> Key: SOLR-13187
> URL: https://issues.apache.org/jira/browse/SOLR-13187
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> *  Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s 
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection
> We followed [Exercise 
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from 
> the [Solr 
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html]. The 
> attached file ({{home.zip}}) gives the contents of folder {{/tmp/home}} that 
> you will obtain by following the steps below:
> {noformat}
> mkdir -p /tmp/home
> echo '' > 
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no 
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field": 
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}' 
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary 
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}' 
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> {noformat}
>Reporter: Cesar Rodriguez
>Assignee: Munendra S N
>Priority: Minor
>  Labels: diffblue, newdev
> Attachments: SOLR-13187.patch, SOLR-13187.patch, SOLR-13187.patch, 
> home.zip
>
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?fq={!a}
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> java.lang.NullPointerException
>   at org.apache.solr.search.QParser.getParser(QParser.java:367)
>   at org.apache.solr.search.QParser.getParser(QParser.java:319)
>   at org.apache.solr.search.QParser.getParser(QParser.java:309)
>   at 
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:203)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:272)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2559)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:394)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
> [...]
> {noformat}
> The call to {{getQueryPlugin}} from 
> {{org.apache.solr.search.QParser.getParser()}}, at line 366, can return a 
> null pointer, as witnessed by the URL above. Method {{getParser}} should 
> probably check for this.
> We found this bug using [Diffblue Microservices 
> Testing|https://www.diffblue.com/labs/]. Find more information on this [fuzz 
> testing 
> campaign|https://www.diffblue.com/blog/2018/12/19/diffblue-microservice-testing-a-sneak-peek-at-our-early-product-and-results].



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

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

[jira] [Commented] (SOLR-13197) NullPointerException in org/apache/solr/handler/component/StatsField.java[251]

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13197:


Commit 9cfba4a728e38a7e6c59c60a377420abc769be46 in lucene-solr's branch 
refs/heads/master from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9cfba4a ]

SOLR-13187: Fix NPE when invalid qParser is specified

* When non-existent qParser is specified return 400 error code
* SOLR-13197: Fix NPE when createQParser is called in StatsField


> NullPointerException in org/apache/solr/handler/component/StatsField.java[251]
> --
>
> Key: SOLR-13197
> URL: https://issues.apache.org/jira/browse/SOLR-13197
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> *  Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s 
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection
> We followed [Exercise 
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from 
> the [Solr 
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html]. The 
> attached file ({{home.zip}}) gives the contents of folder {{/tmp/home}} that 
> you will obtain by following the steps below:
> {noformat}
> mkdir -p /tmp/home
> echo '' > 
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no 
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field": 
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}' 
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary 
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}' 
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> {noformat}
>Reporter: Marek
>Priority: Minor
>  Labels: diffblue, newdev
> Attachments: home.zip
>
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?stats=true&stats.field={!cardinalit}
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> ERROR (qtp689401025-17) [   x:films] o.a.s.s.HttpSolrCall 
> null:java.lang.NullPointerException
>   at 
> org.apache.solr.handler.component.StatsField.(StatsField.java:251)
>   at 
> org.apache.solr.handler.component.StatsInfo.(StatsComponent.java:194)
>   at 
> org.apache.solr.handler.component.StatsComponent.prepare(StatsComponent.java:47)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:272)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2559)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:394)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   [...]
> {noformat}
> There is called method 'createParser' on local variable 'qplug' which is set 
> to null on the previous line (i.e. 250). The value null is set to the local 
> variable 'qplug', because of failure in finding the sting "cardinalit" in the 
> field 'registry' of the class org.apache.solr.core.PluginBag (at line 
> org/apache/solr/core/PluginBag.java[167]).
> We found this bug using [Diffblue Microservices 
> Testing|https://www.diffblue.com/labs/?utm_source=solr-br]. Find more 
> information on this [fuzz testing 
> campaign|https://www.diffblue.com/blog/2018/12/19/diffblue-microservice-testing-a-sneak-peek-at-our-early-product-and-results?utm_source=solr-br].



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

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

[jira] [Updated] (SOLR-12988) Known OpenJDK >= 11 SSL (TLSv1.3) bugs can cause problems with Solr

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-12988:

Attachment: SOLR-12988.patch
Status: Open  (was: Open)

The JDK bug I found on friday is tracked as 
[JDK-8226649|https://bugs.openjdk.java.net/browse/JDK-8226649] which is already 
listed as a dup of 
[JDK-8226338|https://bugs.openjdk.java.net/browse/JDK-8226338] which does not 
yet have any substantive description, comments, or commits associated with it.

For the time being, i've updated the patch to outright skip SSL testing on any 
"13-ea" builds.

Uwe updated all the jenkins JVMs over the weekend, so if there aren't any 
objections i think this is probably safe to commit & backport now?

> Known OpenJDK >= 11 SSL (TLSv1.3) bugs can cause problems with Solr
> ---
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
>  Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
>  Labels: Java11, Java12, Java13
> Attachments: SOLR-12988.patch, SOLR-12988.patch, SOLR-12988.patch, 
> SOLR-13413.patch
>
>
> There are several known OpenJDK JVM bugs (begining with Java11, when TLS v1.3 
> support was first added) that are known to affect Solr's SSL support, and 
> have caused numerous test failures -- notably early "testing" builds of 
> OpenJDK 11, 12, & 13, as well as the officially released OpenJDK 11, 11.0.1, 
> and 11.0.2.
> From the standpoint of the Solr project, there is very little we can do to 
> mitigate these bugs, and have taken steps to ensure any code using our 
> {{SSLTestConfig}} / {{RandomizeSSL}} test-framework classes will be "SKIPed" 
> with an {{AssumptionViolatedException}} when used on JVMs that are known to 
> be problematic.
> Users who encounter any of the types of failures described below, or 
> developers who encounter test runs that "SKIP" with a message refering to 
> this issue ID, are encouraged to Upgrade their JVM. (or as a last resort: try 
> disabling "TLSv1.3" in your JVM security properties)
> 
> Examples of known bugs as they have manifested in Solr tests...
> * https://bugs.openjdk.java.net/browse/JDK-8212885
> ** "TLS 1.3 resumed session does not retain peer certificate chain"
> ** affects users with {{checkPeerNames=true}} in your SSL configuration
> ** causes 100% failure rate in Solr's 
> {{TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName}}
> ** can result in exceptions for SolrJ users, or in solr cloud server logs 
> when making intra-node requests, with a root cause of 
> "javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated"
> ** {noformat}
>[junit4]   2> Caused by: javax.net.ssl.SSLPeerUnverifiedException: peer 
> not authenticated
>[junit4]   2>  at 
> java.base/sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:526)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.verifyHostname(SSLConnectionSocketFactory.java:464)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:397)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:355)
>[junit4]   2>  at 
> org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
>[junit4]   2>  at 
> org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:359)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:381)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:237)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111)
>[junit4]   2>  at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
>[junit4]   2>  at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
>[junit4]   2>  at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56)
>[junit4]   2>  at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:542)
> {noformat}
> * https://bugs.openjdk.java.net/browse/JDK-8213202
> ** "Possible race condition in TLS 1.3 session resumption"
> ** May affect any and all Solr SSL users, although noted only in tests when 
> "clie

[JENKINS] Lucene-Solr-BadApples-Tests-8.x - Build # 135 - Unstable

[Apache Jenkins Server]

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

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

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

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




Build Log:
[...truncated 14601 lines...]
   [junit4] Suite: org.apache.solr.cloud.AliasIntegrationTest
   [junit4]   2> Creating dataDir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-8.x/solr/build/solr-core/test/J1/temp/solr.cloud.AliasIntegrationTe

[jira] [Commented] (SOLR-13187) NullPointerException at o.a.solr.search.QParser.getParser

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-13187:
-

Sure. Please go ahead. Separate handling make sense in this case. 

> NullPointerException at o.a.solr.search.QParser.getParser
> -
>
> Key: SOLR-13187
> URL: https://issues.apache.org/jira/browse/SOLR-13187
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> *  Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s 
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection
> We followed [Exercise 
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from 
> the [Solr 
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html]. The 
> attached file ({{home.zip}}) gives the contents of folder {{/tmp/home}} that 
> you will obtain by following the steps below:
> {noformat}
> mkdir -p /tmp/home
> echo '' > 
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no 
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field": 
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}' 
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary 
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}' 
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> {noformat}
>Reporter: Cesar Rodriguez
>Assignee: Munendra S N
>Priority: Minor
>  Labels: diffblue, newdev
> Attachments: SOLR-13187.patch, SOLR-13187.patch, SOLR-13187.patch, 
> home.zip
>
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?fq={!a}
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> java.lang.NullPointerException
>   at org.apache.solr.search.QParser.getParser(QParser.java:367)
>   at org.apache.solr.search.QParser.getParser(QParser.java:319)
>   at org.apache.solr.search.QParser.getParser(QParser.java:309)
>   at 
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:203)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:272)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2559)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:394)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
> [...]
> {noformat}
> The call to {{getQueryPlugin}} from 
> {{org.apache.solr.search.QParser.getParser()}}, at line 366, can return a 
> null pointer, as witnessed by the URL above. Method {{getParser}} should 
> probably check for this.
> We found this bug using [Diffblue Microservices 
> Testing|https://www.diffblue.com/labs/]. Find more information on this [fuzz 
> testing 
> campaign|https://www.diffblue.com/blog/2018/12/19/diffblue-microservice-testing-a-sneak-peek-at-our-early-product-and-results].



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

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

[jira] [Commented] (LUCENE-8875) Should TopScoreDocCollector Always Populate Sentinel Values?

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8875:
--

I like pre-populating the hit queue mostly because it makes the collector code 
simpler and likely a bit faster. As a comparison TopFieldCollector can't 
pre-populate the hit queue, which forces it to have different code paths for 
the case that the priority queue is full (common path) or that the queue is not 
full yet. In general I'm seeing large number of hits as an abuse case.

> Should TopScoreDocCollector Always Populate Sentinel Values?
> 
>
> Key: LUCENE-8875
> URL: https://issues.apache.org/jira/browse/LUCENE-8875
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Major
>
> TopScoreDocCollector always initializes HitQueue as the PQ implementation, 
> and instruct HitQueue to populate with sentinels. While this is a great 
> safety mechanism, for very large datasets where the query's selectivity is 
> high, the sentinel population can be redundant and can become a large enough 
> bottleneck in itself. Does it make sense to introduce a new parameter in 
> TopScoreDocCollector which uses a heuristic (say number of hits > 10k) and 
> does not populate sentinels?



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

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

[jira] [Assigned] (SOLR-13187) NullPointerException at o.a.solr.search.QParser.getParser

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev reassigned SOLR-13187:
---

Assignee: Munendra S N  (was: Mikhail Khludnev)

> NullPointerException at o.a.solr.search.QParser.getParser
> -
>
> Key: SOLR-13187
> URL: https://issues.apache.org/jira/browse/SOLR-13187
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> *  Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s 
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection
> We followed [Exercise 
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from 
> the [Solr 
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html]. The 
> attached file ({{home.zip}}) gives the contents of folder {{/tmp/home}} that 
> you will obtain by following the steps below:
> {noformat}
> mkdir -p /tmp/home
> echo '' > 
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no 
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field": 
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}' 
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary 
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}' 
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> {noformat}
>Reporter: Cesar Rodriguez
>Assignee: Munendra S N
>Priority: Minor
>  Labels: diffblue, newdev
> Attachments: SOLR-13187.patch, SOLR-13187.patch, SOLR-13187.patch, 
> home.zip
>
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?fq={!a}
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> java.lang.NullPointerException
>   at org.apache.solr.search.QParser.getParser(QParser.java:367)
>   at org.apache.solr.search.QParser.getParser(QParser.java:319)
>   at org.apache.solr.search.QParser.getParser(QParser.java:309)
>   at 
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:203)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:272)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2559)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:394)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
> [...]
> {noformat}
> The call to {{getQueryPlugin}} from 
> {{org.apache.solr.search.QParser.getParser()}}, at line 366, can return a 
> null pointer, as witnessed by the URL above. Method {{getParser}} should 
> probably check for this.
> We found this bug using [Diffblue Microservices 
> Testing|https://www.diffblue.com/labs/]. Find more information on this [fuzz 
> testing 
> campaign|https://www.diffblue.com/blog/2018/12/19/diffblue-microservice-testing-a-sneak-peek-at-our-early-product-and-results].



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

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

[jira] [Created] (LUCENE-8877) TopDocsCollector Should Not Depend on Priority Queue

[Atri Sharma (JIRA)]

Atri Sharma created LUCENE-8877:
---

 Summary: TopDocsCollector Should Not Depend on Priority Queue
 Key: LUCENE-8877
 URL: https://issues.apache.org/jira/browse/LUCENE-8877
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Atri Sharma


TopDocsCollector is tightly coupled to the notion of priority queue, which is 
not necessarily a good abstraction to have since the collector really just 
needs an interface to iterate on and hold docID and score, with possibly shard 
indexes.

 

We should rewrite this to a more simplistic interface with priority queue being 
the default implementation 



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

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

[jira] [Updated] (LUCENE-8855) Add Accountable to Query implementations

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated LUCENE-8855:
--
Attachment: LUCENE-8855.patch

> Add Accountable to Query implementations
> 
>
> Key: LUCENE-8855
> URL: https://issues.apache.org/jira/browse/LUCENE-8855
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: LUCENE-8855.patch, LUCENE-8855.patch, LUCENE-8855.patch, 
> LUCENE-8855.patch
>
>
> Query implementations should also support {{Accountable}} API in order to 
> monitor the memory consumption e.g. in caches where either keys or values are 
> {{Query}} instances.



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

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

[jira] [Updated] (LUCENE-8855) Add Accountable to Query implementations

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated LUCENE-8855:
--
Attachment: (was: LUCENE-8855.patch)

> Add Accountable to Query implementations
> 
>
> Key: LUCENE-8855
> URL: https://issues.apache.org/jira/browse/LUCENE-8855
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: LUCENE-8855.patch, LUCENE-8855.patch, LUCENE-8855.patch, 
> LUCENE-8855.patch
>
>
> Query implementations should also support {{Accountable}} API in order to 
> monitor the memory consumption e.g. in caches where either keys or values are 
> {{Query}} instances.



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

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

[jira] [Commented] (LUCENE-8855) Add Accountable to Query implementations

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on LUCENE-8855:
---

Updated patch:

* removed Accountable from PointRangeQuery, BytesRef and IntsRef.
* use a fixed (relatively large) constant for estimating the size of unknown 
query types.

> Add Accountable to Query implementations
> 
>
> Key: LUCENE-8855
> URL: https://issues.apache.org/jira/browse/LUCENE-8855
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: LUCENE-8855.patch, LUCENE-8855.patch, LUCENE-8855.patch, 
> LUCENE-8855.patch
>
>
> Query implementations should also support {{Accountable}} API in order to 
> monitor the memory consumption e.g. in caches where either keys or values are 
> {{Query}} instances.



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

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

[jira] [Comment Edited] (SOLR-13187) NullPointerException at o.a.solr.search.QParser.getParser

[Munendra S N (JIRA)]

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

Munendra S N edited comment on SOLR-13187 at 6/24/19 4:38 PM:
--

[~mkhludnev]
I'm planning to go-ahead with separate error handling. Can I reassign this and 
take it forward?


was (Author: munendrasn):
[~mkhludnev]
I'm planning to go-ahead with separate error handling. Can I take reassign this 
and take it forward?

> NullPointerException at o.a.solr.search.QParser.getParser
> -
>
> Key: SOLR-13187
> URL: https://issues.apache.org/jira/browse/SOLR-13187
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> *  Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s 
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection
> We followed [Exercise 
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from 
> the [Solr 
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html]. The 
> attached file ({{home.zip}}) gives the contents of folder {{/tmp/home}} that 
> you will obtain by following the steps below:
> {noformat}
> mkdir -p /tmp/home
> echo '' > 
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no 
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field": 
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}' 
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary 
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}' 
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> {noformat}
>Reporter: Cesar Rodriguez
>Assignee: Mikhail Khludnev
>Priority: Minor
>  Labels: diffblue, newdev
> Attachments: SOLR-13187.patch, SOLR-13187.patch, SOLR-13187.patch, 
> home.zip
>
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?fq={!a}
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> java.lang.NullPointerException
>   at org.apache.solr.search.QParser.getParser(QParser.java:367)
>   at org.apache.solr.search.QParser.getParser(QParser.java:319)
>   at org.apache.solr.search.QParser.getParser(QParser.java:309)
>   at 
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:203)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:272)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2559)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:394)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
> [...]
> {noformat}
> The call to {{getQueryPlugin}} from 
> {{org.apache.solr.search.QParser.getParser()}}, at line 366, can return a 
> null pointer, as witnessed by the URL above. Method {{getParser}} should 
> probably check for this.
> We found this bug using [Diffblue Microservices 
> Testing|https://www.diffblue.com/labs/]. Find more information on this [fuzz 
> testing 
> campaign|https://www.diffblue.com/blog/2018/12/19/diffblue-microservice-testing-a-sneak-peek-at-our-early-product-and-results].



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

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

[jira] [Updated] (LUCENE-8855) Add Accountable to Query implementations

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated LUCENE-8855:
--
Attachment: LUCENE-8855.patch

> Add Accountable to Query implementations
> 
>
> Key: LUCENE-8855
> URL: https://issues.apache.org/jira/browse/LUCENE-8855
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: LUCENE-8855.patch, LUCENE-8855.patch, LUCENE-8855.patch, 
> LUCENE-8855.patch
>
>
> Query implementations should also support {{Accountable}} API in order to 
> monitor the memory consumption e.g. in caches where either keys or values are 
> {{Query}} instances.



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

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

[jira] [Commented] (SOLR-13187) NullPointerException at o.a.solr.search.QParser.getParser

[Munendra S N (JIRA)]

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

Munendra S N commented on SOLR-13187:
-

[~mkhludnev]
I'm planning to go-ahead with separate error handling. Can I take reassign this 
and take it forward?

> NullPointerException at o.a.solr.search.QParser.getParser
> -
>
> Key: SOLR-13187
> URL: https://issues.apache.org/jira/browse/SOLR-13187
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> *  Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s 
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection
> We followed [Exercise 
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from 
> the [Solr 
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html]. The 
> attached file ({{home.zip}}) gives the contents of folder {{/tmp/home}} that 
> you will obtain by following the steps below:
> {noformat}
> mkdir -p /tmp/home
> echo '' > 
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no 
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field": 
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}' 
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary 
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}' 
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> {noformat}
>Reporter: Cesar Rodriguez
>Assignee: Mikhail Khludnev
>Priority: Minor
>  Labels: diffblue, newdev
> Attachments: SOLR-13187.patch, SOLR-13187.patch, SOLR-13187.patch, 
> home.zip
>
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?fq={!a}
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> java.lang.NullPointerException
>   at org.apache.solr.search.QParser.getParser(QParser.java:367)
>   at org.apache.solr.search.QParser.getParser(QParser.java:319)
>   at org.apache.solr.search.QParser.getParser(QParser.java:309)
>   at 
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:203)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:272)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2559)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:394)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
> [...]
> {noformat}
> The call to {{getQueryPlugin}} from 
> {{org.apache.solr.search.QParser.getParser()}}, at line 366, can return a 
> null pointer, as witnessed by the URL above. Method {{getParser}} should 
> probably check for this.
> We found this bug using [Diffblue Microservices 
> Testing|https://www.diffblue.com/labs/]. Find more information on this [fuzz 
> testing 
> campaign|https://www.diffblue.com/blog/2018/12/19/diffblue-microservice-testing-a-sneak-peek-at-our-early-product-and-results].



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

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

[jira] [Commented] (LUCENE-8870) Support numeric value in Field class

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8870:
--

I think this new constructor would be misleading. For instance it might be 
tempting to use if you wanted to index doubles. But the only thing you can 
index with this constructor is the string representation of the double values, 
which is unlikely to be helpful.

I wonder whether we should make this class abstract instead so that it can't be 
instantiated directly, and potentially enhance some of its sub classes to 
address use-cases that were only doable with this Field class until now, such 
as having a text field with term vectors enabled.

> Support numeric value in Field class
> 
>
> Key: LUCENE-8870
> URL: https://issues.apache.org/jira/browse/LUCENE-8870
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Namgyu Kim
>Priority: Major
> Attachments: LUCENE-8870.patch
>
>
> I checked the following comment in Field class.
> {code:java}
> // TODO: allow direct construction of int, long, float, double value too..?
> {code}
> We already have some fields like IntPoint and StoredField, but I think it's 
> okay.
> The test cases are set in the TestField class.



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

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

Re: Welcome Munendra S N as Lucene/Solr committer

[Adrien Grand]

Welcome Munendra!

On Fri, Jun 21, 2019 at 11:42 AM Ishan Chattopadhyaya
 wrote:
>
> Hi all,
>
> Please join me in welcoming Munendra as a Lucene/Solr committer!
>
> Munendra has been working on bug fixes and improvements in various
> parts of Solr.
>
> Congratulations and welcome! It is a tradition to introduce yourself
> with a brief bio, Munendra.
>
> Ishan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>


-- 
Adrien

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

[GitHub] [lucene-solr] jpountz commented on issue #730: LUCENE-8868: New storing strategy for BKD tree leaves with low cardinality

[GitBox]

jpountz commented on issue #730: LUCENE-8868: New storing strategy for BKD tree 
leaves with low cardinality
URL: https://github.com/apache/lucene-solr/pull/730#issuecomment-505076553
 
 
   Fair enough.
   
   > BKD tree is extensively tested already so there is no need to add new 
tests.
   
   Do we already have tests for the case that leaves have lots of duplicates?


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


With regards,
Apache Git Services

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

[jira] [Commented] (LUCENE-8806) WANDScorer should support two-phase iterator

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8806:
--

+1

Can you run luceneutil on some disjunctions of phrase queries to double check 
it helps?

> WANDScorer should support two-phase iterator
> 
>
> Key: LUCENE-8806
> URL: https://issues.apache.org/jira/browse/LUCENE-8806
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Jim Ferenczi
>Priority: Major
> Attachments: LUCENE-8806.patch, LUCENE-8806.patch
>
>
> Following https://issues.apache.org/jira/browse/LUCENE-8770 the WANDScorer 
> should leverage two-phase iterators in order to be faster when used in 
> conjunctions.



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

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

[jira] [Commented] (LUCENE-8876) EnglishMinimalStemmer does not implement s-stemmer paper correctly?

[Mark Harwood (JIRA)]

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

Mark Harwood commented on LUCENE-8876:
--

{quote} but then doesn't it mean that exceptions of the 2nd rule are always 
ignored?
{quote}
 

Good point. Rule 1 exceptions are odd too - I have not found a single common 
English word that ends in aies or eies.

> EnglishMinimalStemmer does not implement s-stemmer paper correctly?
> ---
>
> Key: LUCENE-8876
> URL: https://issues.apache.org/jira/browse/LUCENE-8876
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/analysis
>Reporter: Mark Harwood
>Priority: Minor
>
> The EnglishMinimalStemmer fails to stem ees suffixes like bees, trees and 
> employees.
> The [original 
> paper|[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.104.9828&rep=rep1&type=pdf]]
>  has this table of rules:
> !https://user-images.githubusercontent.com/170925/59616454-5dc7d580-911c-11e9-80b0-c7a59458c5a7.png!
> The notes accompanying the table state :
> {quote}"the first applicable rule encountered is the only one used"
> {quote}
>  
> For the {{ees}} and {{oes}} suffixes I think EnglishMinimalStemmer 
> misinterpreted the rule logic and consequently {{bees != bee}} and {{tomatoes 
> != tomato}}. The {{oes}} and {{ees}} suffixes are left intact.
> "The first applicable rule" for {{ees}} could be interpreted as rule 2 or 3 
> in the table depending on if you take {{applicable}} to mean "the THEN part 
> of the rule has fired" or just that the suffix was referenced in the rule. 
> EnglishMinimalStemmer has assumed the latter and I think it should be the 
> former. We should fall through into rule 3 for {{ees}} and {{oes}} (remove 
> any trailing S). That's certainly the conclusion I came to independently 
> testing on real data.
> There are some additional changes I'd like to see in a plural stemmer but I 
> won't list them here - the focus should be making the code here match the 
> original paper it references.



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

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

[jira] [Commented] (LUCENE-8876) EnglishMinimalStemmer does not implement s-stemmer paper correctly?

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8876:
--

I agree that the use of "applicable" suggests that the THEN part has fired, but 
then doesn't it mean that exceptions of the 2nd rule are always ignored?

> EnglishMinimalStemmer does not implement s-stemmer paper correctly?
> ---
>
> Key: LUCENE-8876
> URL: https://issues.apache.org/jira/browse/LUCENE-8876
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/analysis
>Reporter: Mark Harwood
>Priority: Minor
>
> The EnglishMinimalStemmer fails to stem ees suffixes like bees, trees and 
> employees.
> The [original 
> paper|[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.104.9828&rep=rep1&type=pdf]]
>  has this table of rules:
> !https://user-images.githubusercontent.com/170925/59616454-5dc7d580-911c-11e9-80b0-c7a59458c5a7.png!
> The notes accompanying the table state :
> {quote}"the first applicable rule encountered is the only one used"
> {quote}
>  
> For the {{ees}} and {{oes}} suffixes I think EnglishMinimalStemmer 
> misinterpreted the rule logic and consequently {{bees != bee}} and {{tomatoes 
> != tomato}}. The {{oes}} and {{ees}} suffixes are left intact.
> "The first applicable rule" for {{ees}} could be interpreted as rule 2 or 3 
> in the table depending on if you take {{applicable}} to mean "the THEN part 
> of the rule has fired" or just that the suffix was referenced in the rule. 
> EnglishMinimalStemmer has assumed the latter and I think it should be the 
> former. We should fall through into rule 3 for {{ees}} and {{oes}} (remove 
> any trailing S). That's certainly the conclusion I came to independently 
> testing on real data.
> There are some additional changes I'd like to see in a plural stemmer but I 
> won't list them here - the focus should be making the code here match the 
> original paper it references.



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

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

[jira] [Commented] (LUCENE-8871) Move Kuromoji DictionaryBuilder tool from src/tools to src/

[Mike Sokolov (JIRA)]

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

Mike Sokolov commented on LUCENE-8871:
--

This has been up for a day, and is I think pretty uncontroversial - just moving 
files, and some code hygiene. Unless there are objections, I'll push this later 
today

> Move Kuromoji DictionaryBuilder tool from src/tools to src/ 
> 
>
> Key: LUCENE-8871
> URL: https://issues.apache.org/jira/browse/LUCENE-8871
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Mike Sokolov
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently tests in tools directories are not run as part of the normal 
> testing done by {{ant test}} - you have to explicitly run {{test-tools}}, 
> which it seems people don't do (and it might not survivie translation to 
> gradle, who knows), so [~rcmuir] suggested we just move the tools into the 
> main source tree (under src/java and src/test)



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

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

[jira] [Commented] (SOLR-13187) NullPointerException at o.a.solr.search.QParser.getParser

[Lucene/Solr QA (JIRA)]

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

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

| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 1 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  2m  
1s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
56s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m 
56s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  1m 56s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  1m 56s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  1m 56s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 49m 
23s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 56m 19s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-13187 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12972684/SOLR-13187.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene1-us-west 4.4.0-137-generic #163~14.04.1-Ubuntu SMP Mon 
Sep 24 17:14:57 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / 54aff4a |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on July 24 2018 |
| Default Java | LTS |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/455/testReport/ |
| modules | C: solr solr/core U: solr |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/455/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> NullPointerException at o.a.solr.search.QParser.getParser
> -
>
> Key: SOLR-13187
> URL: https://issues.apache.org/jira/browse/SOLR-13187
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> *  Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s 
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection
> We followed [Exercise 
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from 
> the [Solr 
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html]. The 
> attached file ({{home.zip}}) gives the contents of folder {{/tmp/home}} that 
> you will obtain by following the steps below:
> {noformat}
> mkdir -p /tmp/home
> echo '' > 
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no 
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field": 
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}' 
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary 
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}' 
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> {noformat}
>Reporter: Cesar Rodriguez
>Assignee: Mikhail Khludnev
>Priority: Minor
>  Labels: diffblue, newdev
> Attachments: SOLR-13187.patch, SOLR-13187.pa

[jira] [Commented] (SOLR-13461) Update Parallel SQL docs to be very clear select * isn't supported.

[JIRA]

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

Jan Høydahl commented on SOLR-13461:


bq. I don't think that the Luke module gets us anything in this regard

Thanks. You’re probably right

> Update Parallel SQL docs to be very clear select * isn't supported.
> ---
>
> Key: SOLR-13461
> URL: https://issues.apache.org/jira/browse/SOLR-13461
> Project: Solr
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 8.0
>Reporter: Eric Pugh
>Assignee: Jason Gerlowski
>Priority: Minor
> Fix For: master (9.0), 8.2
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Small tweak to documentation to really highlight select * not supported.



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

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