[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields

[Atri Sharma (JIRA)]

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

Atri Sharma commented on LUCENE-8362:
-

[~jpountz] Another thought, BTW. Given how the patch is structured now, it 
should be simple to add support for other types of range queries (CROSSES et 
al). I have not added it in this iteration, but will post a follow up patch if 
you recommend. WDYT?

> Add DocValue support for RangeFields 
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-8362-approach2.patch, LUCENE-8362.patch, 
> LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to 
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range 
> fields already provide the methods for encoding ranges as a byte array I 
> think this could be as simple as adding syntactic sugar to existing range 
> fields that simply build an instance of {{BinaryDocValues}} using that same 
> encoding. I'm envisioning something like 
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit 
> other ideas or potential drawbacks to this approach.



--
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-13421) Intermittent error 401 with JSON Facet query to retrieve count all collections

[Edwin Yeo Zheng Lin (JIRA)]

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

Edwin Yeo Zheng Lin commented on SOLR-13421:


Thanks for the reply. So this likely falls on the authentication issue?

> Intermittent error 401 with JSON Facet query to retrieve count all collections
> --
>
> Key: SOLR-13421
> URL: https://issues.apache.org/jira/browse/SOLR-13421
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: 8.0
>Reporter: Edwin Yeo Zheng Lin
>Priority: Major
>  Labels: BasicAuth
>
> I am using the below JSON Facet to retrieve the count of all the different 
> collections in one query.
>   
>  
> [https://localhost:8983/solr/collection1/select?q=testing&shards=https://localhost:8983/solr/collection1,https://localhost:8983/solr/collection2,https://localhost:8983/solr/collection3,https://localhost:8983/solr/collection4,https://localhost:8983/solr/collection5,https://localhost:8983/solr/collection6&rows=0&json.facet={categories|https://localhost:8983/solr/collection1/select?q=testing&shards=https://localhost:8983/solr/collection1,https://localhost:8983/solr/collection2,https://localhost:8983/solr/collection3,https://localhost:8983/solr/collection4,https://localhost:8983/solr/collection5,https://localhost:8983/solr/collection6&rows=0&json.facet=%7Bcategories]
>  : \{type : terms,field : content_type,limit : 100}}
>   
>   
>  Previously, in Solr 7.6 and Solr 7.7, this query can work correctly and we 
> are able to produce the correct output.
>   
>  {
>    "responseHeader":
> {     "zkConnected":true,     "status":0,     "QTime":24}
> ,
>    "response":
> {"numFound":41200,"start":0,"maxScore":12.993215,"docs":[]   }
> ,
>    "facets":{
>      "count":41200,
>      "categories":{
>        "buckets":[
> {           "val":"collection1",           "count":26213}
> ,
>         
> {           "val":"collection2",           "count":12075}
> ,
>         
> {           "val":"collection3",           "count":1947}
> ,
>         
> {           "val":"collection4",           "count":850}
> ,
>         
> {           "val":"collection5",           "count":111}
> ,
>         
> {           "val":"collection6",           "count":4}
> ]}}}
>   
>   
>  However, in the new Solr 8.0.0, this query can only work if we put only one 
> collection in the shards (can be any collection). If we put 2 collections, 
> there will not be error 90% of the time (only 10% of the time the issue will 
> occur with the 'Error 401 require authentication').
> However, once we put 3 or more collections (can be any of the collections), 
> this issue of 'Error 401 require authentication' will keep occurring.
>  
>  {
>    "responseHeader":
> {     "zkConnected":true,     "status":401,     "QTime":11}
> ,
>    "error":{
>      "metadata":[
>        
> "error-class","org.apache.solr.client.solrj.impl.Http2SolrClient$RemoteSolrException",
>        
> "root-error-class","org.apache.solr.client.solrj.impl.Http2SolrClient$RemoteSolrException"],
>      "msg":"Error from server at null: Expected mime type 
> application/octet-stream but got text/html. \n\n http-equiv=\"Content-Type\" 
> content=\"text/html;charset=utf-8\"/>\nError 401 require 
> authentication\n\nHTTP ERROR 401\nProblem 
> accessing /solr/collection6/select. Reason:\n    require 
> authentication\n\n\n",
>      "code":401}}
>   
>  This issue does not occur in Solr 7.6 and Solr 7.7, even though I have set 
> up the same authentication for all the versions.
>   
>   
> Below is the format of my security.json:
>   
>  {
>  "authentication":
> {    "blockUnknown": true,    "class":"solr.BasicAuthPlugin",    
> "credentials":
> {"user1":"hyHXXuJSqcZdNgdSTGUvrQZRpqrYFUQ2ffmlWQ4GUTk= 
> E0w3/2FD+rlxulbPm2G7i9HZqT+2gMBzcyJCcGcMWwA="}
> },
>  "authorization":
> {    "class":"solr.RuleBasedAuthorizationPlugin",    "user-role":
> {"user1":"admin"}
> ,
>     "permissions":[
> {"name":"security-edit",                   "role":"admin"}
> ]
>  }}



--
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-13329) Placing exact number of replicas on a set of solr nodes, instead of each solr node.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13329:


Commit b6d20b6f1bb735fc55c751e9942393151a9dc35f in lucene-solr's branch 
refs/heads/master from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b6d20b6 ]

SOLR-13329: ref guide


> Placing exact number of replicas on a set of solr nodes, instead of each solr 
> node.
> ---
>
> Key: SOLR-13329
> URL: https://issues.apache.org/jira/browse/SOLR-13329
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Affects Versions: master (9.0)
>Reporter: Amrit Sarkar
>Priority: Major
>
> Let's say we have a requirement where we would like to place:
> {code}
> exact X replica on a set of solr nodes comprises of solr-node-1, solr-node-2, 
> ... solr-node-N.
> {code}
> e.g. exact 1 replica on either of the respective 3 solr nodes, solr-node-1, 
> solr-node-2, solr-node-3, and rest of the replicas can be placed on 
> corresponding solr nodes.
> Right now we don't have a straightforward manner of doing the same. 
> Autoscaling cluster policy also doesn't support such behavior, but instead 
> takes an array of solr node names and treat them as separate rules as per 
> https://lucene.apache.org/solr/guide/7_7/solrcloud-autoscaling-policy-preferences.html#sysprop-attribute.



--
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-13329) Placing exact number of replicas on a set of solr nodes, instead of each solr node.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13329:


Commit 776ae379572c936f29f8eb77ac0014ccd0e8c1d6 in lucene-solr's branch 
refs/heads/master from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=776ae37 ]

SOLR-13329: ref guide


> Placing exact number of replicas on a set of solr nodes, instead of each solr 
> node.
> ---
>
> Key: SOLR-13329
> URL: https://issues.apache.org/jira/browse/SOLR-13329
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Affects Versions: master (9.0)
>Reporter: Amrit Sarkar
>Priority: Major
>
> Let's say we have a requirement where we would like to place:
> {code}
> exact X replica on a set of solr nodes comprises of solr-node-1, solr-node-2, 
> ... solr-node-N.
> {code}
> e.g. exact 1 replica on either of the respective 3 solr nodes, solr-node-1, 
> solr-node-2, solr-node-3, and rest of the replicas can be placed on 
> corresponding solr nodes.
> Right now we don't have a straightforward manner of doing the same. 
> Autoscaling cluster policy also doesn't support such behavior, but instead 
> takes an array of solr node names and treat them as separate rules as per 
> https://lucene.apache.org/solr/guide/7_7/solrcloud-autoscaling-policy-preferences.html#sysprop-attribute.



--
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-8346) Upgrade Zookeeper to version 3.5.5

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-8346.
--
   Resolution: Fixed
Fix Version/s: 8.2
   master (9.0)

I wouldn't be surprised if this causes some changes in test results, hopefully 
for the better if some of our test failures are ZK related. I'll be triaging 
this starting tomorrow, all eyes welcome of course.

> Upgrade Zookeeper to version 3.5.5
> --
>
> Key: SOLR-8346
> URL: https://issues.apache.org/jira/browse/SOLR-8346
> Project: Solr
>  Issue Type: Task
>  Components: SolrCloud
>Reporter: Jan Høydahl
>Assignee: Erick Erickson
>Priority: Major
>  Labels: security, zookeeper
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-8346.patch, SOLR-8346.patch, SOLR-8346.patch, 
> SOLR-8346.patch, SOLR-8346.patch, SOLR_8346.patch
>
>
> Investigate upgrading ZooKeeper to 3.5.x, once released. Primary motivation 
> for this is SSL support. --Currently a 3.5.4-beta is released (2018-05-17).-- 
> Version 3.5.5 was released 2019-05-20



--
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 Namgyu Kim as Lucene/Solr committer

[Andi Vajda]

> On Jun 3, 2019, at 21:21, Milind Thombre  wrote:
> 
> I would like to contribute to PyLucene. Please guide me on the
>  next steps

Subscribe to pylucene-dev@ and start a new thread there (don't highjack an 
existing one).

Andi..

> 
>> On Mon, Jun 3, 2019 at 11:22 PM Adrien Grand  wrote:
>> Hi all,
>> 
>> Please join me in welcoming Namgyu Kim as Lucene/ Solr committer!
>> 
>> Kim has been helping address technical debt and fixing bugs in the
>> last year, including a cleanup to our DutchAnalyzer[0] and
>> improvements to the StoredFieldsVisitor API[1]. More recently he also
>> started improving our korean analyzer[2].
>> 
>> [0] https://issues.apache.org/jira/browse/LUCENE-8582
>> [1] https://issues.apache.org/jira/browse/LUCENE-8805
>> [2] https://issues.apache.org/jira/browse/LUCENE-8784
>> 
>> Congratulations and welcome! It is a tradition to introduce yourself
>> with a brief bio.
>> 
>> -- 
>> Adrien
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 

Re: Welcome Namgyu Kim as Lucene/Solr committer

[Milind Thombre]

I would like to contribute to PyLucene. Please guide me on the
 next steps

On Mon, Jun 3, 2019 at 11:22 PM Adrien Grand  wrote:

> Hi all,
>
> Please join me in welcoming Namgyu Kim as Lucene/ Solr committer!
>
> Kim has been helping address technical debt and fixing bugs in the
> last year, including a cleanup to our DutchAnalyzer[0] and
> improvements to the StoredFieldsVisitor API[1]. More recently he also
> started improving our korean analyzer[2].
>
> [0] https://issues.apache.org/jira/browse/LUCENE-8582
> [1] https://issues.apache.org/jira/browse/LUCENE-8805
> [2] https://issues.apache.org/jira/browse/LUCENE-8784
>
> Congratulations and welcome! It is a tradition to introduce yourself
> with a brief bio.
>
> --
> Adrien
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Commented] (SOLR-8346) Upgrade Zookeeper to version 3.5.5

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-8346:
---

Commit 045ee7c0fa06913c760742d4d17c15556bfe95da in lucene-solr's branch 
refs/heads/master from erick
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=045ee7c ]

SOLR-8346: Upgrade Zookeeper to version 3.5.5. Update solrj/ivy.xml to match 8x 
precommit fix


> Upgrade Zookeeper to version 3.5.5
> --
>
> Key: SOLR-8346
> URL: https://issues.apache.org/jira/browse/SOLR-8346
> Project: Solr
>  Issue Type: Task
>  Components: SolrCloud
>Reporter: Jan Høydahl
>Assignee: Erick Erickson
>Priority: Major
>  Labels: security, zookeeper
> Attachments: SOLR-8346.patch, SOLR-8346.patch, SOLR-8346.patch, 
> SOLR-8346.patch, SOLR-8346.patch, SOLR_8346.patch
>
>
> Investigate upgrading ZooKeeper to 3.5.x, once released. Primary motivation 
> for this is SSL support. --Currently a 3.5.4-beta is released (2018-05-17).-- 
> Version 3.5.5 was released 2019-05-20



--
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 Namgyu Kim as Lucene/Solr committer

[Shalin Shekhar Mangar]

Congratulations and welcome Namgyu!

On Mon, Jun 3, 2019 at 11:22 PM Adrien Grand  wrote:

> Hi all,
>
> Please join me in welcoming Namgyu Kim as Lucene/ Solr committer!
>
> Kim has been helping address technical debt and fixing bugs in the
> last year, including a cleanup to our DutchAnalyzer[0] and
> improvements to the StoredFieldsVisitor API[1]. More recently he also
> started improving our korean analyzer[2].
>
> [0] https://issues.apache.org/jira/browse/LUCENE-8582
> [1] https://issues.apache.org/jira/browse/LUCENE-8805
> [2] https://issues.apache.org/jira/browse/LUCENE-8784
>
> Congratulations and welcome! It is a tradition to introduce yourself
> with a brief bio.
>
> --
> Adrien
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
Regards,
Shalin Shekhar Mangar.

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24182/
Java: 64bit/jdk-13-ea+18 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.cloud.NestedShardedAtomicUpdateTest.test

Error Message:
Error from server at http://127.0.0.1:33521/qkl/collection1: non ok status: 
500, message:Server Error

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:33521/qkl/collection1: non ok status: 500, 
message:Server Error
at 
__randomizedtesting.SeedInfo.seed([C3D7A501822FBF6E:4B839ADB2CD3D296]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:579)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:224)
at 
org.apache.solr.BaseDistributedSearchTestCase.add(BaseDistributedSearchTestCase.java:576)
at 
org.apache.solr.cloud.NestedShardedAtomicUpdateTest.indexDocAndRandomlyCommit(NestedShardedAtomicUpdateTest.java:221)
at 
org.apache.solr.cloud.NestedShardedAtomicUpdateTest.sendWrongRouteParam(NestedShardedAtomicUpdateTest.java:191)
at 
org.apache.solr.cloud.NestedShardedAtomicUpdateTest.test(NestedShardedAtomicUpdateTest.java:55)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomi

[jira] [Commented] (SOLR-13512) Raw index data analysis tool

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-13512:
---

This is uber-cool. But everyone's a critic, I noticed some misspellings of 
"lengths" as "lenghts"

 "terms_lenghts_postings": 89626992, "terms_*lenghts*_impacts": 0,

But this is fantastic, we can finally give some guidance like "if you include 
norms" etc.

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



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

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

[jira] [Commented] (SOLR-8346) Upgrade Zookeeper to version 3.5.5

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-8346:
--

No, I'm not crazy. The change I had to make for 8x to pass precommit is _not_ 
necessary for trunk. OTOH, trunk also passes precommit with the change, so I'll 
update the trunk too

BTW, ran full precommit/test under Java 8 for 8x, so that might have some 
bearing, although what I can't imagine.

I wouldn't be surprised if this has an effect on some of our tests, I'll be 
looking extra closely at the test results starting tomorrow.

> Upgrade Zookeeper to version 3.5.5
> --
>
> Key: SOLR-8346
> URL: https://issues.apache.org/jira/browse/SOLR-8346
> Project: Solr
>  Issue Type: Task
>  Components: SolrCloud
>Reporter: Jan Høydahl
>Assignee: Erick Erickson
>Priority: Major
>  Labels: security, zookeeper
> Attachments: SOLR-8346.patch, SOLR-8346.patch, SOLR-8346.patch, 
> SOLR-8346.patch, SOLR-8346.patch, SOLR_8346.patch
>
>
> Investigate upgrading ZooKeeper to 3.5.x, once released. Primary motivation 
> for this is SSL support. --Currently a 3.5.4-beta is released (2018-05-17).-- 
> Version 3.5.5 was released 2019-05-20



--
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-8346) Upgrade Zookeeper to version 3.5.5

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-8346:
---

Commit d32334b199ffb9163d9b8ec7d08176c2d64b5ac9 in lucene-solr's branch 
refs/heads/branch_8x from Erick Erickson
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d32334b ]

SOLR-8346: Fix precommit failure on 8x


> Upgrade Zookeeper to version 3.5.5
> --
>
> Key: SOLR-8346
> URL: https://issues.apache.org/jira/browse/SOLR-8346
> Project: Solr
>  Issue Type: Task
>  Components: SolrCloud
>Reporter: Jan Høydahl
>Assignee: Erick Erickson
>Priority: Major
>  Labels: security, zookeeper
> Attachments: SOLR-8346.patch, SOLR-8346.patch, SOLR-8346.patch, 
> SOLR-8346.patch, SOLR-8346.patch, SOLR_8346.patch
>
>
> Investigate upgrading ZooKeeper to 3.5.x, once released. Primary motivation 
> for this is SSL support. --Currently a 3.5.4-beta is released (2018-05-17).-- 
> Version 3.5.5 was released 2019-05-20



--
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-8346) Upgrade Zookeeper to version 3.5.5

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-8346:
--

I've got some precommit error on 8x, I swear I ran precommit on master about 5 
times, fixing...

> Upgrade Zookeeper to version 3.5.5
> --
>
> Key: SOLR-8346
> URL: https://issues.apache.org/jira/browse/SOLR-8346
> Project: Solr
>  Issue Type: Task
>  Components: SolrCloud
>Reporter: Jan Høydahl
>Assignee: Erick Erickson
>Priority: Major
>  Labels: security, zookeeper
> Attachments: SOLR-8346.patch, SOLR-8346.patch, SOLR-8346.patch, 
> SOLR-8346.patch, SOLR-8346.patch, SOLR_8346.patch
>
>
> Investigate upgrading ZooKeeper to 3.5.x, once released. Primary motivation 
> for this is SSL support. --Currently a 3.5.4-beta is released (2018-05-17).-- 
> Version 3.5.5 was released 2019-05-20



--
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-8.x-Linux (64bit/jdk-13-ea+18) - Build # 659 - Unstable!

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.solr.cloud.NestedShardedAtomicUpdateTest.test

Error Message:
Error from server at http://127.0.0.1:44037/_fy/se/collection1: non ok status: 
500, message:Server Error

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:44037/_fy/se/collection1: non ok status: 500, 
message:Server Error
at 
__randomizedtesting.SeedInfo.seed([18047704CDCF82AD:905048DE6333EF55]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:579)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:224)
at 
org.apache.solr.BaseDistributedSearchTestCase.add(BaseDistributedSearchTestCase.java:576)
at 
org.apache.solr.cloud.NestedShardedAtomicUpdateTest.indexDocAndRandomlyCommit(NestedShardedAtomicUpdateTest.java:221)
at 
org.apache.solr.cloud.NestedShardedAtomicUpdateTest.sendWrongRouteParam(NestedShardedAtomicUpdateTest.java:191)
at 
org.apache.solr.cloud.NestedShardedAtomicUpdateTest.test(NestedShardedAtomicUpdateTest.java:55)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtes

[jira] [Commented] (SOLR-8346) Upgrade Zookeeper to version 3.5.5

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-8346:
---

Commit e8909803110f8466513a04841611baf03386485c in lucene-solr's branch 
refs/heads/branch_8x from Erick Erickson
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e890980 ]

SOLR-8346: Upgrade Zookeeper to version 3.5.5

(cherry picked from commit 7ebeab71f4b56d008835f0040468a07632024950)


> Upgrade Zookeeper to version 3.5.5
> --
>
> Key: SOLR-8346
> URL: https://issues.apache.org/jira/browse/SOLR-8346
> Project: Solr
>  Issue Type: Task
>  Components: SolrCloud
>Reporter: Jan Høydahl
>Assignee: Erick Erickson
>Priority: Major
>  Labels: security, zookeeper
> Attachments: SOLR-8346.patch, SOLR-8346.patch, SOLR-8346.patch, 
> SOLR-8346.patch, SOLR-8346.patch, SOLR_8346.patch
>
>
> Investigate upgrading ZooKeeper to 3.5.x, once released. Primary motivation 
> for this is SSL support. --Currently a 3.5.4-beta is released (2018-05-17).-- 
> Version 3.5.5 was released 2019-05-20



--
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-8346) Upgrade Zookeeper to version 3.5.5

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-8346:
---

Commit 7ebeab71f4b56d008835f0040468a07632024950 in lucene-solr's branch 
refs/heads/master from Erick Erickson
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7ebeab7 ]

SOLR-8346: Upgrade Zookeeper to version 3.5.5


> Upgrade Zookeeper to version 3.5.5
> --
>
> Key: SOLR-8346
> URL: https://issues.apache.org/jira/browse/SOLR-8346
> Project: Solr
>  Issue Type: Task
>  Components: SolrCloud
>Reporter: Jan Høydahl
>Assignee: Erick Erickson
>Priority: Major
>  Labels: security, zookeeper
> Attachments: SOLR-8346.patch, SOLR-8346.patch, SOLR-8346.patch, 
> SOLR-8346.patch, SOLR-8346.patch, SOLR_8346.patch
>
>
> Investigate upgrading ZooKeeper to 3.5.x, once released. Primary motivation 
> for this is SSL support. --Currently a 3.5.4-beta is released (2018-05-17).-- 
> Version 3.5.5 was released 2019-05-20



--
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-8346) Upgrade Zookeeper to version 3.5.5

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-8346:
--

Final patch

> Upgrade Zookeeper to version 3.5.5
> --
>
> Key: SOLR-8346
> URL: https://issues.apache.org/jira/browse/SOLR-8346
> Project: Solr
>  Issue Type: Task
>  Components: SolrCloud
>Reporter: Jan Høydahl
>Assignee: Erick Erickson
>Priority: Major
>  Labels: security, zookeeper
> Attachments: SOLR-8346.patch, SOLR-8346.patch, SOLR-8346.patch, 
> SOLR-8346.patch, SOLR-8346.patch, SOLR_8346.patch
>
>
> Investigate upgrading ZooKeeper to 3.5.x, once released. Primary motivation 
> for this is SSL support. --Currently a 3.5.4-beta is released (2018-05-17).-- 
> Version 3.5.5 was released 2019-05-20



--
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-8346) Upgrade Zookeeper to version 3.5.5

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-8346:
-
Attachment: SOLR-8346.patch

> Upgrade Zookeeper to version 3.5.5
> --
>
> Key: SOLR-8346
> URL: https://issues.apache.org/jira/browse/SOLR-8346
> Project: Solr
>  Issue Type: Task
>  Components: SolrCloud
>Reporter: Jan Høydahl
>Assignee: Erick Erickson
>Priority: Major
>  Labels: security, zookeeper
> Attachments: SOLR-8346.patch, SOLR-8346.patch, SOLR-8346.patch, 
> SOLR-8346.patch, SOLR-8346.patch, SOLR_8346.patch
>
>
> Investigate upgrading ZooKeeper to 3.5.x, once released. Primary motivation 
> for this is SSL support. --Currently a 3.5.4-beta is released (2018-05-17).-- 
> Version 3.5.5 was released 2019-05-20



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

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

[JENKINS] Lucene-Solr-NightlyTests-8.x - Build # 111 - Still unstable

[Apache Jenkins Server]

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

3 tests failed.
FAILED:  
org.apache.lucene.search.spans.TestSpanSearchEquivalence.testSpanTermVersusTerm

Error Message:
expected:<4273> but was:<5007>

Stack Trace:
java.lang.AssertionError: expected:<4273> but was:<5007>
at 
__randomizedtesting.SeedInfo.seed([825D18DC2008A78F:E767110042CE16E2]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:631)
at 
org.apache.lucene.search.SearchEquivalenceTestBase.assertSameScores(SearchEquivalenceTestBase.java:255)
at 
org.apache.lucene.search.SearchEquivalenceTestBase.assertSameScores(SearchEquivalenceTestBase.java:228)
at 
org.apache.lucene.search.spans.TestSpanSearchEquivalence.testSpanTermVersusTerm(TestSpanSearchEquivalence.java:42)
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.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  
org.apache.lucene.search.spans.TestSpanSearchEquivalence.testSpanBoostQuerySimplification

Error Message:
expected:<4422> but was:<5223>

Stack Trace:
java.lang.AssertionError: expected:<4422> but was:<5223>
at 
__randomizedtesting.SeedInfo.seed([825D18DC2008A78F:6E395A9E206C476E]:0)
at org.jun

Re: VOTE: Apache Solr Reference Guide for Solr 8.0

[Jan Høydahl]

Feel free as RM to release without these changes and fold into 8.1.
But here is a patch with re-phrasing of the two paragraphs I mentioned, as well 
as backport SOLR-12809, in case of a potential re-spin.
https://gist.github.com/ed99d0945de112e05e1d1ff2ce6a 

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

> 3. jun. 2019 kl. 14:54 skrev Cassandra Targett :
> 
> Jan, would you please suggest exact wording to correct the error you pointed 
> out (quoted below). Since I clearly don’t understand the change, and this is 
> months delayed already, that is likely be the fastest option to get a respin 
> started this week. Otherwise, it will need to wait for me to wade back into 
> the topic to see if I can understand what the correct wording should be.
> 
> Thank you,
> Cassandra 
> On May 31, 2019, 3:37 PM -0500, Jan Høydahl , wrote:
>> Viewed on a smartphone :)
>> 
>> Comments:
>> 
>> Major changes section:
>> 
>>> The Basic Authentication plugin now has an option forwardCredentials to 
>>> prevent Basic Auth headers from being sent for inter-node requests.
>> 
>> 
>> This is wrong. Basic Auth never sent basicauth headers inter-node, and 
>> adding the “forwardcredentials” option lets user-originated requests be 
>> forwarded with original basicauth credentials instead of PKI.
>>>  
> 

[jira] [Commented] (SOLR-13396) SolrCloud will delete the core data for any core that is not referenced in the clusterstate

[Koen De Groote (JIRA)]

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

Koen De Groote commented on SOLR-13396:
---

Just did some testing:

I created a `/solr` directory in zookeeper and put some test data in it.

If I delete the `version-2` folder, the solr data directories remain in place.

 

When restarting the containers, nothing changes. In fact, solr refuses to 
connect with zookeeper, with messages like this:

 

2019-06-03 22:18:08.648 WARN  (qtp574568002-28) [   ] o.e.j.s.HttpChannel /solr/
javax.servlet.ServletException: javax.servlet.UnavailableException: Error 
processing the request. CoreContainer is either not initialized or shutting 
down.

 

And

 

2019-06-03 22:04:10.654 ERROR 
(OverseerCollectionConfigSetProcessor-72057939225149443-localhost:8983_solr-n_01)
 [   ] o.a.s.c.OverseerTaskProcessor 
org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode = 
ConnectionLoss for /overseer_elect/leader

 

The problem of data directories being deleted really only occurs when I 
re-create the /solr chroot... which is then empty. They don't contain the data 
of the old ZK. So when I then restart solr, it connects to ZK, finds what it's 
looking for, namely `/solr`, sees that it is empty, and proceeds to make it so 
that the data on disk for solr is identical to what it found. In this case: 
empty.

 

I don't see how that problem can be fixed. Would really like some feedback on 
that.

> SolrCloud will delete the core data for any core that is not referenced in 
> the clusterstate
> ---
>
> Key: SOLR-13396
> URL: https://issues.apache.org/jira/browse/SOLR-13396
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.3.1, 8.0
>Reporter: Shawn Heisey
>Priority: Major
>
> SOLR-12066 is an improvement designed to delete core data for replicas that 
> were deleted while the node was down -- better cleanup.
> In practice, that change causes SolrCloud to delete all core data for cores 
> that are not referenced in the ZK clusterstate.  If all the ZK data gets 
> deleted or the Solr instance is pointed at a ZK ensemble with no data, it 
> will proceed to delete all of the cores in the solr home, with no possibility 
> of recovery.
> I do not think that Solr should ever delete core data unless an explicit 
> DELETE action has been made and the node is operational at the time of the 
> request.  If a core exists during startup that cannot be found in the ZK 
> clusterstate, it should be ignored (not started) and a helpful message should 
> be logged.  I think that message should probably be at WARN so that it shows 
> up in the admin UI logging tab with default settings.



--
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 Namgyu Kim as Lucene/Solr committer

[Joel Bernstein]

Welcome Namgyu!



Joel Bernstein
http://joelsolr.blogspot.com/


On Mon, Jun 3, 2019 at 5:05 PM Steve Rowe  wrote:

> Congrats and welcome Namgyu!
>
> --
> Steve
>
> > On Jun 3, 2019, at 1:52 PM, Adrien Grand  wrote:
> >
> > Hi all,
> >
> > Please join me in welcoming Namgyu Kim as Lucene/ Solr committer!
> >
> > Kim has been helping address technical debt and fixing bugs in the
> > last year, including a cleanup to our DutchAnalyzer[0] and
> > improvements to the StoredFieldsVisitor API[1]. More recently he also
> > started improving our korean analyzer[2].
> >
> > [0] https://issues.apache.org/jira/browse/LUCENE-8582
> > [1] https://issues.apache.org/jira/browse/LUCENE-8805
> > [2] https://issues.apache.org/jira/browse/LUCENE-8784
> >
> > Congratulations and welcome! It is a tradition to introduce yourself
> > with a brief bio.
> >
> > --
> > Adrien
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.ReindexCollectionTest.testSameTargetReindexing

Error Message:
Solr11035BandAid failed, counts differ after updates: expected:<199> but 
was:<200>

Stack Trace:
java.lang.AssertionError: Solr11035BandAid failed, counts differ after updates: 
expected:<199> but was:<200>
at 
__randomizedtesting.SeedInfo.seed([3AA9834C797D2016:8FD0689B7E1BB852]: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.SolrTestCaseJ4.Solr11035BandAid(SolrTestCaseJ4.java:3084)
at 
org.apache.solr.cloud.ReindexCollectionTest.testSameTargetReindexing(ReindexCollectionTest.java:183)
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:835)




Build Log:
[...truncated 12826 lines...]
   [j

[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-11.0.2) - Build # 7974 - Unstable!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.core.ExitableDirectoryReaderTest.testQueryResults

Error Message:
Should NOT have inserted partial results! expected:<4> but was:<5>

Stack Trace:
java.lang.AssertionError: Should NOT have inserted partial results! 
expected:<4> but was:<5>
at 
__randomizedtesting.SeedInfo.seed([2F9D8F0326ED:721938742D0878A6]: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.core.ExitableDirectoryReaderTest.testQueryResults(ExitableDirectoryReaderTest.java:143)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
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)




Build Log:
[...truncated 2038 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\

[jira] [Commented] (SOLR-13510) Intermittent 401's for internode requests with basicauth enabled

[JIRA]

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

Jan Høydahl commented on SOLR-13510:


[~gerlowskija] with your understanding of the situation, are you able to create 
a patch with a failing unit test? I tried creating 3 extra collections in 
BasicAuthIntegrationTest (which has 3 nodes) but it did not trigger any 
failures.

I wonder if there may be some interaction with HTTP2 and Http2SolrClient here? 
If the outside client uses HTTP1 and inter-node traffic is always HTTP2, then 
it could be that we fail to convey the credentials from the request as this is 
done in slightly different way, and probably not tested. The logic in asserting 
that PKIAuthPlugin registers its interceptor for HTTP1 and HTTP2 may also be 
fragile or slightly different. If setting {{-Dsolr.http1=true}} when starting 
Solr fixes the issue, then this theory is proven.

> Intermittent 401's for internode requests with basicauth enabled
> 
>
> Key: SOLR-13510
> URL: https://issues.apache.org/jira/browse/SOLR-13510
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Priority: Major
>
> We recently got a bug report on the mailing list:
> {quote}
> On Solr 8.1.1, using our previously working security.json, running queries
> (through the admin UI currently) I non-deterministically get 401 responses
> on queries when a collection has more than 1 shard. Increasing the number
> of shards in the collection makes the errors more likely.
> {
>   "responseHeader":{
> "zkConnected":true,
> "status":401,
> "QTime":30,
> "params":{
>   "q":"*:*",
>   "_":"1559474550365"}},
>   "error":{
> "metadata":[
> "error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException",
> "root-error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException"],
> "msg":"Error from server at null: Expected mime type
> application/octet-stream but got text/html. \n\n http-equiv=\"Content-Type\"
> content=\"text/html;charset=utf-8\"/>\nError 401 require
> authentication\n\nHTTP ERROR 401\nProblem
> accessing /solr/gettingstarted_shard4_replica_n6/select. Reason:\n
>  require authentication\n\n\n",
> "code":401}}
> {quote}
> The reporter (credit to Colvin Cowie) also gives reproduction steps:
> {quote}
># Extract solr 8.1.1.
># bin\solr start -e cloud
> 1 node / [default port] / [default collection name] / 4 shards / 1
> replica / [_default configuration]
># server\scripts\cloud-scripts\zkcli -zkhost localhost:9983 -cmd putfile
> /security.json 
> {
> "authentication": {
> "blockUnknown": true,
> "class": "solr.BasicAuthPlugin",
> "credentials": {
> "solradmin": "PIWZwkGnEKxKnqUs3X08xmbmYBaYyAeP3FiKp7fmeHc=
> Lnbp6bEbE7Ap8lXvQDKkUX2Xw53QDgP6Ae8QRT0P5/A="
> }
> },
> "authorization": {
> "class": "solr.RuleBasedAuthorizationPlugin",
> "permissions": [{ "name": "all", "role": "admin"} ],
> "user-role": {"solradmin": "admin"}
> }
> }
> {quote}
> (Minor edits for conciseness)
> I'm able to reproduce this bug as well.  Other auth issues (SOLR-13472) look 
> like they're impacted by the topography of the collection and cluster.  But 
> this doesn't seem affected by that at all (401's occur on inter-node requests 
> regardless of the recipient of the initial request, and even when all nodes 
> have a shard replica).



--
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 Namgyu Kim as Lucene/Solr committer

[Steve Rowe]

Congrats and welcome Namgyu!

--
Steve

> On Jun 3, 2019, at 1:52 PM, Adrien Grand  wrote:
> 
> Hi all,
> 
> Please join me in welcoming Namgyu Kim as Lucene/ Solr committer!
> 
> Kim has been helping address technical debt and fixing bugs in the
> last year, including a cleanup to our DutchAnalyzer[0] and
> improvements to the StoredFieldsVisitor API[1]. More recently he also
> started improving our korean analyzer[2].
> 
> [0] https://issues.apache.org/jira/browse/LUCENE-8582
> [1] https://issues.apache.org/jira/browse/LUCENE-8805
> [2] https://issues.apache.org/jira/browse/LUCENE-8784
> 
> Congratulations and welcome! It is a tradition to introduce yourself
> with a brief bio.
> 
> -- 
> Adrien
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

[jira] [Commented] (SOLR-13496) NullPointerException in JSONWriter.writeSolrDocument

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-13496:


{quote}The patch doesn't appear to include any new or modified tests. Please 
justify why no new tests are needed for this patch. Also please list what 
manual steps were performed to verify this patch.
{quote}
Just attached a patch which includes (a tidied up version of) my (new) 
{{ChaoticDistributedGroupingTest}} used to exercise the code path in question. 
The test configures a custom select handler which configures a 
{{TargettedChaosComponent}} search component which in its 
[modifyRequest|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/handler/component/SearchComponent.java#L73-L75]
 method potentially modifies the {{ids}} parameter of a shard request. That 
removal of an id value is to simulate a Solr cloud scenario where a document is 
deleted just before a 'get fields' request for it happens.

Having said all that (unless anyone strongly thinks otherwise) I'm not planning 
on including the new {{ChaoticDistributedGroupingTest}} in the commit for this 
ticket here since just under 200 lines of non-trivial test code for essentially 
a one-line change to add a null-check seems excessive?

> NullPointerException in JSONWriter.writeSolrDocument
> 
>
> Key: SOLR-13496
> URL: https://issues.apache.org/jira/browse/SOLR-13496
> Project: Solr
>  Issue Type: Bug
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-13496.patch, SOLR-13496.patch
>
>
> For non-grouped searches 
> [QueryComponent.regularFinishStage|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/handler/component/QueryComponent.java#L647-L655]
>  already considers the possibility of null {{SolrDocument}} values due to an 
> index change.
> For grouped searches 
> [GroupedEndResultTransformer.transform|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/endresulttransformer/GroupedEndResultTransformer.java#L94-L114]
>  potentially adds a null element to a {{SolrDocumentList}}.
> The 
> [TextResponseWriter.writeSolrDocumentList|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/response/TextResponseWriter.java#L170]
>  method passes any null {{SolrDocument}} through to the 
> [JSONWriter.writeSolrDocument|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/response/JSONWriter.java#L87]
>  method leading to a {{NullPointerException}} at line 87.



--
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-13496) NullPointerException in JSONWriter.writeSolrDocument

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-13496:
---
Attachment: SOLR-13496.patch

> NullPointerException in JSONWriter.writeSolrDocument
> 
>
> Key: SOLR-13496
> URL: https://issues.apache.org/jira/browse/SOLR-13496
> Project: Solr
>  Issue Type: Bug
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-13496.patch, SOLR-13496.patch
>
>
> For non-grouped searches 
> [QueryComponent.regularFinishStage|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/handler/component/QueryComponent.java#L647-L655]
>  already considers the possibility of null {{SolrDocument}} values due to an 
> index change.
> For grouped searches 
> [GroupedEndResultTransformer.transform|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/endresulttransformer/GroupedEndResultTransformer.java#L94-L114]
>  potentially adds a null element to a {{SolrDocumentList}}.
> The 
> [TextResponseWriter.writeSolrDocumentList|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/response/TextResponseWriter.java#L170]
>  method passes any null {{SolrDocument}} through to the 
> [JSONWriter.writeSolrDocument|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/response/JSONWriter.java#L87]
>  method leading to a {{NullPointerException}} at line 87.



--
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-13439) Make collection properties easier and safer to use in code

[JIRA]

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

Tomás Fernández Löbbe commented on SOLR-13439:
--

Thanks Gus, I was on vacations last week. I'll take a look.

> Make collection properties easier and safer to use in code
> --
>
> Key: SOLR-13439
> URL: https://issues.apache.org/jira/browse/SOLR-13439
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: master (9.0)
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Major
> Attachments: SOLR-13439.patch, SOLR-13439.patch, SOLR-13439.patch
>
>
> (breaking this out from SOLR-13420, please read there for further background)
> Before this patch the api is quite confusing (IMHO):
>  # any code that wanted to know what the properties for a collection are 
> could call zkStateReader.getCollectionProperties(collection) but this was a 
> dangerous and trappy API because that was a query to zookeeper every time. If 
> a naive user auto-completed that in their IDE without investigating, heavy 
> use of zookeeper would ensue.
>  # To "do it right" for any code that might get called on a per-doc or per 
> request basis one had to cause caching by registering a watcher. At which 
> point the getCollectionProperties(collection) magically becomes safe to use, 
> but the watcher pattern probably looks famillar induces a user who hasn't 
> read the solr code closely to create their own cache and update it when their 
> watcher is notified. If the caching side effect of watches isn't understood 
> this will lead to many in-memory copies of collection properties maintained 
> in user code.
>  # This also creates a task to be scheduled on a thread (PropsNotification) 
> and induces an extra thread-scheduling lag before the changes can be observed 
> by user code.
>  # The code that cares about collection properties needs to have a lifecycle 
> tied to either a collection or something other object with an even more 
> ephemeral life cycle such as an URP. The user now also has to remember to 
> ensure the watch is unregistered, or there is a leak.
> After this patch
>  # Calls to getCollectionProperties(collection) are always safe to use in any 
> code anywhere. Caching and cleanup are automatic.
>  # Code that really actually wants to know if a collection property changes 
> so it can wake up and do something (autoscaling?) still has the option of 
> registering a watcher that will asynchronously send them a notification.
>  # Updates can be observed sooner via getCollectionProperties with no need to 
> wait for a thread to run. (vs a cache held in user 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

Re: Welcome Namgyu Kim as Lucene/Solr committer

[Alan Woodward]

Congratulations and welcome!

> On 3 Jun 2019, at 18:52, Adrien Grand  wrote:
> 
> Hi all,
> 
> Please join me in welcoming Namgyu Kim as Lucene/ Solr committer!
> 
> Kim has been helping address technical debt and fixing bugs in the
> last year, including a cleanup to our DutchAnalyzer[0] and
> improvements to the StoredFieldsVisitor API[1]. More recently he also
> started improving our korean analyzer[2].
> 
> [0] https://issues.apache.org/jira/browse/LUCENE-8582
> [1] https://issues.apache.org/jira/browse/LUCENE-8805
> [2] https://issues.apache.org/jira/browse/LUCENE-8784
> 
> Congratulations and welcome! It is a tradition to introduce yourself
> with a brief bio.
> 
> -- 
> Adrien
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Re: Welcome Namgyu Kim as Lucene/Solr committer

[Gus Heck]

Welcome :)

On Mon, Jun 3, 2019, 3:31 PM Dawid Weiss  wrote:

> Congratulations and welcome, Namgyu!
>
> Dawid
>
> On Mon, Jun 3, 2019 at 8:23 PM Yonik Seeley  wrote:
> >
> > Congrats Namgyu!
> > -Yonik
> >
> >
> > On Mon, Jun 3, 2019 at 1:52 PM Adrien Grand  wrote:
> >>
> >> Hi all,
> >>
> >> Please join me in welcoming Namgyu Kim as Lucene/ Solr committer!
> >>
> >> Kim has been helping address technical debt and fixing bugs in the
> >> last year, including a cleanup to our DutchAnalyzer[0] and
> >> improvements to the StoredFieldsVisitor API[1]. More recently he also
> >> started improving our korean analyzer[2].
> >>
> >> [0] https://issues.apache.org/jira/browse/LUCENE-8582
> >> [1] https://issues.apache.org/jira/browse/LUCENE-8805
> >> [2] https://issues.apache.org/jira/browse/LUCENE-8784
> >>
> >> Congratulations and welcome! It is a tradition to introduce yourself
> >> with a brief bio.
> >>
> >> --
> >> Adrien
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: VOTE: Apache Solr Reference Guide for Solr 8.0

[Andrzej Białecki]

+1.

I noticed a minor grammar issue in the stream-decorator-reference section on 
“daemon”, where it explains the “list” command: "along with there current 
state” should use “their”.


> On 3 Jun 2019, at 06:37, Anshum Gupta  wrote:
> 
> +1
> 
> 
> On Fri, May 31, 2019 at 7:24 AM Cassandra Targett  > wrote:
> Please vote to release the Solr Reference Guide for 8.0.
> 
> The PDF artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-8.0-RC1/
>  
> 
> 
> $ cat apache-solr-ref-guide-8.0.pdf.sha512 
> c3d01089cb68fdbaa49dc94483a2643fba71ff9900840fbb1a6cc731f2116a9ce9994ab8b832429948f61c6caa7a52f1abfbc8c479c6958644076a8bf99a62f9
>   apache-solr-ref-guide-8.0.pdf
> 
> The online version is available at: https://lucene.apache.org/solr/guide/8_0/ 
> 
> 
> Here's my +1.
> 
> Cassandra
> 
> PS - The 8.1 Guide will follow along hopefully by next week.
> 
> 
> -- 
> Anshum Gupta

[jira] [Updated] (SOLR-13512) Raw index data analysis tool

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated SOLR-13512:
-
Attachment: rawSizeSummary.json

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



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

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

[jira] [Updated] (SOLR-13512) Raw index data analysis tool

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated SOLR-13512:
-
Attachment: rawSizeDetails.json

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



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

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

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

[Policeman Jenkins Server]

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

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

Error Message:
Timed out waiting for replica core_node12 (1559586574438) to replicate from 
leader core_node4 (0)

Stack Trace:
java.lang.AssertionError: Timed out waiting for replica core_node12 
(1559586574438) to replicate from leader core_node4 (0)
at 
__randomizedtesting.SeedInfo.seed([56C08625114A9229:DE94B9FFBFB6FFD1]:0)
at org.junit.Assert.fail(Assert.java:88)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForReplicationFromReplicas(AbstractFullDistribZkTestBase.java:2271)
at 
org.apache.solr.cloud.ChaosMonkeySafeLeaderWithPullReplicasTest.test(ChaosMonkeySafeLeaderWithPullReplicasTest.java:211)
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)
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 

Re: Welcome Namgyu Kim as Lucene/Solr committer

[Dawid Weiss]

Congratulations and welcome, Namgyu!

Dawid

On Mon, Jun 3, 2019 at 8:23 PM Yonik Seeley  wrote:
>
> Congrats Namgyu!
> -Yonik
>
>
> On Mon, Jun 3, 2019 at 1:52 PM Adrien Grand  wrote:
>>
>> Hi all,
>>
>> Please join me in welcoming Namgyu Kim as Lucene/ Solr committer!
>>
>> Kim has been helping address technical debt and fixing bugs in the
>> last year, including a cleanup to our DutchAnalyzer[0] and
>> improvements to the StoredFieldsVisitor API[1]. More recently he also
>> started improving our korean analyzer[2].
>>
>> [0] https://issues.apache.org/jira/browse/LUCENE-8582
>> [1] https://issues.apache.org/jira/browse/LUCENE-8805
>> [2] https://issues.apache.org/jira/browse/LUCENE-8784
>>
>> Congratulations and welcome! It is a tradition to introduce yourself
>> with a brief bio.
>>
>> --
>> Adrien
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>

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

Re: Welcome Namgyu Kim as Lucene/Solr committer

[Yonik Seeley]

Congrats Namgyu!
-Yonik


On Mon, Jun 3, 2019 at 1:52 PM Adrien Grand  wrote:

> Hi all,
>
> Please join me in welcoming Namgyu Kim as Lucene/ Solr committer!
>
> Kim has been helping address technical debt and fixing bugs in the
> last year, including a cleanup to our DutchAnalyzer[0] and
> improvements to the StoredFieldsVisitor API[1]. More recently he also
> started improving our korean analyzer[2].
>
> [0] https://issues.apache.org/jira/browse/LUCENE-8582
> [1] https://issues.apache.org/jira/browse/LUCENE-8805
> [2] https://issues.apache.org/jira/browse/LUCENE-8784
>
> Congratulations and welcome! It is a tradition to introduce yourself
> with a brief bio.
>
> --
> Adrien
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Commented] (SOLR-13512) Raw index data analysis tool

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-13512:
---

Hmmm, don't see the attachment.

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



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

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

Re: Welcome Namgyu Kim as Lucene/Solr committer

[Kevin Risden]

Congrats and welcome!

Kevin Risden


On Mon, Jun 3, 2019 at 2:14 PM Erick Erickson 
wrote:

> Welcome! Good to have you aboard.
>
> > On Jun 3, 2019, at 10:57 AM, David Smiley 
> wrote:
> >
> > Welcome Namgyu!
> >
> > ~ David Smiley
> > Apache Lucene/Solr Search Developer
> > http://www.linkedin.com/in/davidwsmiley
> >
> >
> > On Mon, Jun 3, 2019 at 1:52 PM Adrien Grand  wrote:
> > Hi all,
> >
> > Please join me in welcoming Namgyu Kim as Lucene/ Solr committer!
> >
> > Kim has been helping address technical debt and fixing bugs in the
> > last year, including a cleanup to our DutchAnalyzer[0] and
> > improvements to the StoredFieldsVisitor API[1]. More recently he also
> > started improving our korean analyzer[2].
> >
> > [0] https://issues.apache.org/jira/browse/LUCENE-8582
> > [1] https://issues.apache.org/jira/browse/LUCENE-8805
> > [2] https://issues.apache.org/jira/browse/LUCENE-8784
> >
> > Congratulations and welcome! It is a tradition to introduce yourself
> > with a brief bio.
> >
> > --
> > Adrien
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Welcome Namgyu Kim as Lucene/Solr committer

[Erick Erickson]

Welcome! Good to have you aboard.

> On Jun 3, 2019, at 10:57 AM, David Smiley  wrote:
> 
> Welcome Namgyu!
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
> 
> 
> On Mon, Jun 3, 2019 at 1:52 PM Adrien Grand  wrote:
> Hi all,
> 
> Please join me in welcoming Namgyu Kim as Lucene/ Solr committer!
> 
> Kim has been helping address technical debt and fixing bugs in the
> last year, including a cleanup to our DutchAnalyzer[0] and
> improvements to the StoredFieldsVisitor API[1]. More recently he also
> started improving our korean analyzer[2].
> 
> [0] https://issues.apache.org/jira/browse/LUCENE-8582
> [1] https://issues.apache.org/jira/browse/LUCENE-8805
> [2] https://issues.apache.org/jira/browse/LUCENE-8784
> 
> Congratulations and welcome! It is a tradition to introduce yourself
> with a brief bio.
> 
> -- 
> Adrien
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Re: Welcome Namgyu Kim as Lucene/Solr committer

[David Smiley]

Welcome Namgyu!

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


On Mon, Jun 3, 2019 at 1:52 PM Adrien Grand  wrote:

> Hi all,
>
> Please join me in welcoming Namgyu Kim as Lucene/ Solr committer!
>
> Kim has been helping address technical debt and fixing bugs in the
> last year, including a cleanup to our DutchAnalyzer[0] and
> improvements to the StoredFieldsVisitor API[1]. More recently he also
> started improving our korean analyzer[2].
>
> [0] https://issues.apache.org/jira/browse/LUCENE-8582
> [1] https://issues.apache.org/jira/browse/LUCENE-8805
> [2] https://issues.apache.org/jira/browse/LUCENE-8784
>
> Congratulations and welcome! It is a tradition to introduce yourself
> with a brief bio.
>
> --
> Adrien
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Use of JIRA fixVersion

[David Smiley]

Right JIRA fixVersion has its use, and that would satisfy this
use-case?  It's what Jan proposes to do this very thing as part of
generating release notes in a semi-automated way.

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


On Mon, Jun 3, 2019 at 11:38 AM Erick Erickson 
wrote:

>
>
> > On Jun 3, 2019, at 6:41 AM, David Smiley 
> wrote:
> >
> > If someone wants to know what branches an issue was committed to, then
> review the bot comments to find out.
>
> What if I want to form a query that shows me all JIRAs fixed in version
> X.Y.Z?
>
> A bot comments with “branch_5x” doesn’t tell me which minor version it’s
> in, 5.1? 5.5?
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Commented] (SOLR-13509) NullPointerException in JSON Facet if omitHeaders=true

[Munendra S N (JIRA)]

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

Munendra S N commented on SOLR-13509:
-

 [^SOLR-13509.patch] 
Corrected the test. Here, Always fetching response from the shards. Making sure 
that responseHeader is not returned to the user when omitHeade=true
I'm not sure if the test has been added in the right place.
[~mkhludnev]
Could you please review above approach?? Would this approach solve the issue or 
anything else needs to be done here??

> NullPointerException in JSON Facet if omitHeaders=true
> --
>
> Key: SOLR-13509
> URL: https://issues.apache.org/jira/browse/SOLR-13509
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Affects Versions: 8.1.1
> Environment: Solr 8.1.1 downloaded tar gz, started in cloud mode:
> {code:java}
> bin/solr start -e cloud -noprompt
> bin/solr create -c techproducts -s 2 -rf 2 -d 
> server/solr/configsets/sample_techproducts_configs/conf -n 
> sample_techproducts_configs
> bin/post -c techproducts example/exampledocs/*.xml{code}
>Reporter: Markus Kalkbrenner
>Priority: Major
> Attachments: SOLR-13509.patch, SOLR-13509.patch
>
>
> The error exists in Solr 8.1.1 and didn't occur in Solr 8.0 and 7.x.
> Running this simple JSON Facet against the techproducts example (in cloud 
> mode) succeeds as expected:
> {code:java}
> curl http://localhost:8983/solr/techproducts/select -d '
> q=*:*&
> omitHeader=false&
> json.facet={
>   "max_price" : "max(price)"
> }{code}
> But as soon you omit Headers it results in a NullPointerException (which 
> didn't happen in earlier Solr versions):
> {code:java}
> curl http://localhost:8983/solr/techproducts/select -d '
> q=*:*&
> omitHeader=true&
> json.facet={
>   "max_price" : "max(price)"
> }'
> {code}
> Exception:
> {noformat}
> 2019-06-03 12:40:11.446 ERROR (qtp67730604-361) [c:techproducts s:shard2 
> r:core_node7 x:techproducts_shard2_replica_n4] o.a.s.h.RequestHandlerBase 
> java.lang.NullPointerException
>     at 
> org.apache.solr.search.facet.FacetModule.handleResponses(FacetModule.java:284)
>     at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
>     at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
>     at org.apache.solr.core.SolrCore.execute(SolrCore.java:2566)
>     at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:756)
>     at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:542)
>     at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)
>     at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)
>     at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
>     at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
>     at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
>     at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
>     at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
>     at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
>     at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)
>     at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
>     at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
>     at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)
>     at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)
>     at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>     at 
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
>     at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>     at org.eclipse.jetty.server.Server.handle(Server.java:502)
>     at org.eclipse.jetty.server.HttpChannel.h

Welcome Namgyu Kim as Lucene/Solr committer

[Adrien Grand]

Hi all,

Please join me in welcoming Namgyu Kim as Lucene/ Solr committer!

Kim has been helping address technical debt and fixing bugs in the
last year, including a cleanup to our DutchAnalyzer[0] and
improvements to the StoredFieldsVisitor API[1]. More recently he also
started improving our korean analyzer[2].

[0] https://issues.apache.org/jira/browse/LUCENE-8582
[1] https://issues.apache.org/jira/browse/LUCENE-8805
[2] https://issues.apache.org/jira/browse/LUCENE-8784

Congratulations and welcome! It is a tradition to introduce yourself
with a brief bio.

-- 
Adrien

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

[jira] [Updated] (SOLR-13509) NullPointerException in JSON Facet if omitHeaders=true

[Munendra S N (JIRA)]

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

Munendra S N updated SOLR-13509:

Attachment: SOLR-13509.patch

> NullPointerException in JSON Facet if omitHeaders=true
> --
>
> Key: SOLR-13509
> URL: https://issues.apache.org/jira/browse/SOLR-13509
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Affects Versions: 8.1.1
> Environment: Solr 8.1.1 downloaded tar gz, started in cloud mode:
> {code:java}
> bin/solr start -e cloud -noprompt
> bin/solr create -c techproducts -s 2 -rf 2 -d 
> server/solr/configsets/sample_techproducts_configs/conf -n 
> sample_techproducts_configs
> bin/post -c techproducts example/exampledocs/*.xml{code}
>Reporter: Markus Kalkbrenner
>Priority: Major
> Attachments: SOLR-13509.patch, SOLR-13509.patch
>
>
> The error exists in Solr 8.1.1 and didn't occur in Solr 8.0 and 7.x.
> Running this simple JSON Facet against the techproducts example (in cloud 
> mode) succeeds as expected:
> {code:java}
> curl http://localhost:8983/solr/techproducts/select -d '
> q=*:*&
> omitHeader=false&
> json.facet={
>   "max_price" : "max(price)"
> }{code}
> But as soon you omit Headers it results in a NullPointerException (which 
> didn't happen in earlier Solr versions):
> {code:java}
> curl http://localhost:8983/solr/techproducts/select -d '
> q=*:*&
> omitHeader=true&
> json.facet={
>   "max_price" : "max(price)"
> }'
> {code}
> Exception:
> {noformat}
> 2019-06-03 12:40:11.446 ERROR (qtp67730604-361) [c:techproducts s:shard2 
> r:core_node7 x:techproducts_shard2_replica_n4] o.a.s.h.RequestHandlerBase 
> java.lang.NullPointerException
>     at 
> org.apache.solr.search.facet.FacetModule.handleResponses(FacetModule.java:284)
>     at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
>     at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
>     at org.apache.solr.core.SolrCore.execute(SolrCore.java:2566)
>     at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:756)
>     at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:542)
>     at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)
>     at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)
>     at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
>     at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
>     at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
>     at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
>     at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
>     at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
>     at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)
>     at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
>     at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
>     at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)
>     at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)
>     at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>     at 
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
>     at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>     at org.eclipse.jetty.server.Server.handle(Server.java:502)
>     at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)
>     at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)
>     at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
>     at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
>     at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)
>     at 
> 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=16854893#comment-16854893
 ] 

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

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 1 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  3m 
27s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  3m  
5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  3m  
5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  3m  5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  3m  5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  3m  5s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 88m 59s{color} 
| {color:red} core in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black}100m 20s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.cloud.OverseerTest |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-13187 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12970557/SOLR-13187.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 / 040340a |
| 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/405/artifact/out/patch-unit-solr_core.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/405/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/405/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
>  Security Level: Public(Default Security Level. Issues are Public) 
>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

[jira] [Commented] (SOLR-13512) Raw index data analysis tool

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-13512:
--

This patch contains an {{IndexSizeEstimator}} tool (which is both a 
command-line utility and a Solr component). It provides the functionality 
described above. The patch contains also extensions to 
{{/admin//segments}} and {{/admin/collections?action=COLSTATUS}} to 
efficiently report this data from live {{IndexReader}}-s of a collection.

Here's an example output of COLSTATUS that contains just the overview section 
(the collection contains a partial Wikipedia dump):

{code}
curl 
'http://localhost:8983/solr/admin/collections?action=COLSTATUS&rawSizeInfo=true'

{
"responseHeader": {
"status": 0,
"QTime": 49406
},
"gettingstarted": {
...
"shards": {
"shard1": {
...
"leader": {
...
"segInfos": {
...
"rawSize": {
"fieldsBySize": {
"761 MB": "revision.text",
"88.7 MB": "revision.text_str",
"29.4 MB": "revision",
"26.4 MB": "revision.sha1",
"24.8 MB": "revision.comment",
"18.9 MB": "revision.comment_str",
"13.5 MB": "title",
"12.5 MB": "revision.contributor",
"11.9 MB": "revision.sha1_str",
"9.2 MB": "revision.timestamp",
"8.8 MB": "revision.contributor.id",
"7.3 MB": "revision.format",
"7.1 MB": "id",
"6.8 MB": "revision.parentid",
"6.3 MB": "revision.contributor.username",
"6.1 MB": "revision.model",
"4.6 MB": "title_str",
"4.3 MB": "revision.format_str",
"3.8 MB": "revision.contributor.username_str",
"3.1 MB": "_version_",
"2.8 MB": "revision.model_str",
"2.7 MB": "revision.contributor_str",
...
}
}
}
}
},
"shard2": {
...
"leader": {
...
"segInfos": {
...
"rawSize": {
"fieldsBySize": {
"769.4 MB": "revision.text",
"89.2 MB": "revision.text_str",
"31.2 MB": "revision",
"28 MB": "revision.sha1",
"26.4 MB": "revision.comment",
"20.7 MB": "revision.comment_str",
"14.2 MB": "title",
"13.3 MB": "revision.contributor",
"12.6 MB": "revision.sha1_str",
"9.8 MB": "revision.timestamp",
"9.4 MB": "revision.contributor.id",
"7.7 MB": "revision.format",
"7.6 MB": "id",
"6.9 MB": "revision.parentid",
"6.7 MB": "revision.contributor.username",
"6.5 MB": "revision.model",
"4.7 MB": "title_str",
"4.5 MB": "revision.format_str",
"3.9 MB": "revision.contributor.username_str",
"3.3 MB": "_version_",
"2.9 MB": "revision.contributor_str",
...
}
}
}
}
}
}
}
}
{code}

I attached outputs from the command that provide a summary breakdown per type 
of data, and a really detailed breakdown including per-field and per-type 
statistical summary.

> Raw index data analysis tool
> 
>
> Key: SOLR-13512
> URL: https://issues.apache.org/jira/browse/SOLR-13512
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-13512.patch
>
>
> A common question from Solr users is how to determine how a given schema 
> field and all

[jira] [Commented] (SOLR-13512) Raw index data analysis tool

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-13512:
--

You bet :) It has to basically read in and decode all data from the whole 
index. Fortunately, COLSTATUS supports "async" so the request should complete 
without timeouts even for large indexes.

More details soon.

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



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

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

[jira] [Commented] (SOLR-13510) Intermittent 401's for internode requests with basicauth enabled

[JIRA]

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

Jan Høydahl commented on SOLR-13510:


Sounds like a possible bug in {{forwardCredentials}}. Let's try to create a 
failing unit test for this, involving more than one collection in same 
cluster...

> Intermittent 401's for internode requests with basicauth enabled
> 
>
> Key: SOLR-13510
> URL: https://issues.apache.org/jira/browse/SOLR-13510
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Priority: Major
>
> We recently got a bug report on the mailing list:
> {quote}
> On Solr 8.1.1, using our previously working security.json, running queries
> (through the admin UI currently) I non-deterministically get 401 responses
> on queries when a collection has more than 1 shard. Increasing the number
> of shards in the collection makes the errors more likely.
> {
>   "responseHeader":{
> "zkConnected":true,
> "status":401,
> "QTime":30,
> "params":{
>   "q":"*:*",
>   "_":"1559474550365"}},
>   "error":{
> "metadata":[
> "error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException",
> "root-error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException"],
> "msg":"Error from server at null: Expected mime type
> application/octet-stream but got text/html. \n\n http-equiv=\"Content-Type\"
> content=\"text/html;charset=utf-8\"/>\nError 401 require
> authentication\n\nHTTP ERROR 401\nProblem
> accessing /solr/gettingstarted_shard4_replica_n6/select. Reason:\n
>  require authentication\n\n\n",
> "code":401}}
> {quote}
> The reporter (credit to Colvin Cowie) also gives reproduction steps:
> {quote}
># Extract solr 8.1.1.
># bin\solr start -e cloud
> 1 node / [default port] / [default collection name] / 4 shards / 1
> replica / [_default configuration]
># server\scripts\cloud-scripts\zkcli -zkhost localhost:9983 -cmd putfile
> /security.json 
> {
> "authentication": {
> "blockUnknown": true,
> "class": "solr.BasicAuthPlugin",
> "credentials": {
> "solradmin": "PIWZwkGnEKxKnqUs3X08xmbmYBaYyAeP3FiKp7fmeHc=
> Lnbp6bEbE7Ap8lXvQDKkUX2Xw53QDgP6Ae8QRT0P5/A="
> }
> },
> "authorization": {
> "class": "solr.RuleBasedAuthorizationPlugin",
> "permissions": [{ "name": "all", "role": "admin"} ],
> "user-role": {"solradmin": "admin"}
> }
> }
> {quote}
> (Minor edits for conciseness)
> I'm able to reproduce this bug as well.  Other auth issues (SOLR-13472) look 
> like they're impacted by the topography of the collection and cluster.  But 
> this doesn't seem affected by that at all (401's occur on inter-node requests 
> regardless of the recipient of the initial request, and even when all nodes 
> have a shard replica).



--
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+18) - Build # 24180 - Unstable!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.NestedShardedAtomicUpdateTest.test

Error Message:
Error from server at http://127.0.0.1:43179/collection1: no servers hosting 
shard: shard1

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:43179/collection1: no servers hosting shard: 
shard1
at 
__randomizedtesting.SeedInfo.seed([F958EDD8F59C125E:710CD2025B607FA6]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:649)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:987)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:1002)
at 
org.apache.solr.cloud.NestedShardedAtomicUpdateTest.doNestedInplaceUpdateTest(NestedShardedAtomicUpdateTest.java:154)
at 
org.apache.solr.cloud.NestedShardedAtomicUpdateTest.test(NestedShardedAtomicUpdateTest.java:56)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
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)
   

[jira] [Commented] (SOLR-13512) Raw index data analysis tool

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-13512:
---

This would be waay  cool I'm guessing this would be a pretty lengthy 
operation?

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



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

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

[jira] [Comment Edited] (SOLR-13509) NullPointerException in JSON Facet if omitHeaders=true

[Munendra S N (JIRA)]

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

Munendra S N edited comment on SOLR-13509 at 6/3/19 5:20 PM:
-

[^SOLR-13509.patch]
Simple test demonstrating the problem(this test needs to be moved to better 
place). 
[This|https://github.com/apache/lucene-solr/blob/040340af4631dd3f7986ae9a2a8166315d90510e/solr/core/src/java/org/apache/solr/search/facet/FacetModule.java#L284]
 is throwing the NPE as omitHeader is set to true. Here, facets are checked but 
stats are not checked(I think it would be difficult do it)

Initially thought adding null check here would be suffice but what about other 
component?? Should the shardRequest always ask for responseHeader irrespective 
of omitHeader?


was (Author: munendrasn):
[^SOLR-13509.patch]
Simple test demonstrating the problem(this test needs to be moved to better 
place). 
[This|https://github.com/apache/lucene-solr/blob/040340af4631dd3f7986ae9a2a8166315d90510e/solr/core/src/java/org/apache/solr/search/facet/FacetModule.java#L284]
 is throwing the NPE as omitHeader is set to true. Here, facets are checked but 
stats are not checked(I think it would be difficult do it)

Initially thought adding null check here would be suffice but what about other 
component?? Should the shardRequest always ask for responseHeader irrespective 
of omitHeader

> NullPointerException in JSON Facet if omitHeaders=true
> --
>
> Key: SOLR-13509
> URL: https://issues.apache.org/jira/browse/SOLR-13509
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Affects Versions: 8.1.1
> Environment: Solr 8.1.1 downloaded tar gz, started in cloud mode:
> {code:java}
> bin/solr start -e cloud -noprompt
> bin/solr create -c techproducts -s 2 -rf 2 -d 
> server/solr/configsets/sample_techproducts_configs/conf -n 
> sample_techproducts_configs
> bin/post -c techproducts example/exampledocs/*.xml{code}
>Reporter: Markus Kalkbrenner
>Priority: Major
> Attachments: SOLR-13509.patch
>
>
> The error exists in Solr 8.1.1 and didn't occur in Solr 8.0 and 7.x.
> Running this simple JSON Facet against the techproducts example (in cloud 
> mode) succeeds as expected:
> {code:java}
> curl http://localhost:8983/solr/techproducts/select -d '
> q=*:*&
> omitHeader=false&
> json.facet={
>   "max_price" : "max(price)"
> }{code}
> But as soon you omit Headers it results in a NullPointerException (which 
> didn't happen in earlier Solr versions):
> {code:java}
> curl http://localhost:8983/solr/techproducts/select -d '
> q=*:*&
> omitHeader=true&
> json.facet={
>   "max_price" : "max(price)"
> }'
> {code}
> Exception:
> {noformat}
> 2019-06-03 12:40:11.446 ERROR (qtp67730604-361) [c:techproducts s:shard2 
> r:core_node7 x:techproducts_shard2_replica_n4] o.a.s.h.RequestHandlerBase 
> java.lang.NullPointerException
>     at 
> org.apache.solr.search.facet.FacetModule.handleResponses(FacetModule.java:284)
>     at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
>     at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
>     at org.apache.solr.core.SolrCore.execute(SolrCore.java:2566)
>     at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:756)
>     at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:542)
>     at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)
>     at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)
>     at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
>     at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
>     at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
>     at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
>     at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
>     at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
>     at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)
>     at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)
>     at 
> org.e

[jira] [Commented] (SOLR-13509) NullPointerException in JSON Facet if omitHeaders=true

[Munendra S N (JIRA)]

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

Munendra S N commented on SOLR-13509:
-

[^SOLR-13509.patch]
Simple test demonstrating the problem(this test needs to be moved to better 
place). 
[This|https://github.com/apache/lucene-solr/blob/040340af4631dd3f7986ae9a2a8166315d90510e/solr/core/src/java/org/apache/solr/search/facet/FacetModule.java#L284]
 is throwing the NPE as omitHeader is set to true. Here, facets are checked but 
stats are not checked(I think it would be difficult do it)

Initially thought adding null check here would be suffice but what about other 
component?? Should the shardRequest always ask for responseHeader irrespective 
of omitHeader

> NullPointerException in JSON Facet if omitHeaders=true
> --
>
> Key: SOLR-13509
> URL: https://issues.apache.org/jira/browse/SOLR-13509
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Affects Versions: 8.1.1
> Environment: Solr 8.1.1 downloaded tar gz, started in cloud mode:
> {code:java}
> bin/solr start -e cloud -noprompt
> bin/solr create -c techproducts -s 2 -rf 2 -d 
> server/solr/configsets/sample_techproducts_configs/conf -n 
> sample_techproducts_configs
> bin/post -c techproducts example/exampledocs/*.xml{code}
>Reporter: Markus Kalkbrenner
>Priority: Major
> Attachments: SOLR-13509.patch
>
>
> The error exists in Solr 8.1.1 and didn't occur in Solr 8.0 and 7.x.
> Running this simple JSON Facet against the techproducts example (in cloud 
> mode) succeeds as expected:
> {code:java}
> curl http://localhost:8983/solr/techproducts/select -d '
> q=*:*&
> omitHeader=false&
> json.facet={
>   "max_price" : "max(price)"
> }{code}
> But as soon you omit Headers it results in a NullPointerException (which 
> didn't happen in earlier Solr versions):
> {code:java}
> curl http://localhost:8983/solr/techproducts/select -d '
> q=*:*&
> omitHeader=true&
> json.facet={
>   "max_price" : "max(price)"
> }'
> {code}
> Exception:
> {noformat}
> 2019-06-03 12:40:11.446 ERROR (qtp67730604-361) [c:techproducts s:shard2 
> r:core_node7 x:techproducts_shard2_replica_n4] o.a.s.h.RequestHandlerBase 
> java.lang.NullPointerException
>     at 
> org.apache.solr.search.facet.FacetModule.handleResponses(FacetModule.java:284)
>     at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
>     at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
>     at org.apache.solr.core.SolrCore.execute(SolrCore.java:2566)
>     at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:756)
>     at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:542)
>     at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)
>     at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)
>     at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
>     at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
>     at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
>     at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
>     at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
>     at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
>     at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)
>     at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
>     at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
>     at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)
>     at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)
>     at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>     at 
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
>  

[jira] [Updated] (SOLR-13509) NullPointerException in JSON Facet if omitHeaders=true

[Munendra S N (JIRA)]

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

Munendra S N updated SOLR-13509:

Attachment: SOLR-13509.patch

> NullPointerException in JSON Facet if omitHeaders=true
> --
>
> Key: SOLR-13509
> URL: https://issues.apache.org/jira/browse/SOLR-13509
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Affects Versions: 8.1.1
> Environment: Solr 8.1.1 downloaded tar gz, started in cloud mode:
> {code:java}
> bin/solr start -e cloud -noprompt
> bin/solr create -c techproducts -s 2 -rf 2 -d 
> server/solr/configsets/sample_techproducts_configs/conf -n 
> sample_techproducts_configs
> bin/post -c techproducts example/exampledocs/*.xml{code}
>Reporter: Markus Kalkbrenner
>Priority: Major
> Attachments: SOLR-13509.patch
>
>
> The error exists in Solr 8.1.1 and didn't occur in Solr 8.0 and 7.x.
> Running this simple JSON Facet against the techproducts example (in cloud 
> mode) succeeds as expected:
> {code:java}
> curl http://localhost:8983/solr/techproducts/select -d '
> q=*:*&
> omitHeader=false&
> json.facet={
>   "max_price" : "max(price)"
> }{code}
> But as soon you omit Headers it results in a NullPointerException (which 
> didn't happen in earlier Solr versions):
> {code:java}
> curl http://localhost:8983/solr/techproducts/select -d '
> q=*:*&
> omitHeader=true&
> json.facet={
>   "max_price" : "max(price)"
> }'
> {code}
> Exception:
> {noformat}
> 2019-06-03 12:40:11.446 ERROR (qtp67730604-361) [c:techproducts s:shard2 
> r:core_node7 x:techproducts_shard2_replica_n4] o.a.s.h.RequestHandlerBase 
> java.lang.NullPointerException
>     at 
> org.apache.solr.search.facet.FacetModule.handleResponses(FacetModule.java:284)
>     at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
>     at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
>     at org.apache.solr.core.SolrCore.execute(SolrCore.java:2566)
>     at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:756)
>     at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:542)
>     at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)
>     at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)
>     at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
>     at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
>     at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
>     at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
>     at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
>     at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
>     at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)
>     at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
>     at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
>     at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)
>     at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)
>     at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>     at 
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
>     at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>     at org.eclipse.jetty.server.Server.handle(Server.java:502)
>     at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)
>     at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)
>     at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
>     at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
>     at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)
>     at 
> org.eclipse.jetty.uti

BadApple report

[Erick Erickson]

I probably won’t remove the annotations indicated this week, kinda busy. 
Overall looks like we’re getting gradually better.

Full report attached:

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

  **Methods: 3
   FullSolrCloudDistribCmdsTest.test
   SolrZkClientTest.testSimpleUpdateACLs
   TestCollectionStateWatchers.testCanWaitForNonexistantCollection


Failures in Hoss' reports for the last 4 rollups.

There were 199 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   5.2  902 30  
AliasIntegrationTest.testClusterStateProviderAPI
 0123  23.8   97 25  
HdfsAutoAddReplicasIntegrationTest.testSimple
 0123   0.5  848  8  
LegacyCloudClusterPropTest.testCreateCollectionSwitchLegacyCloud
 0123   1.8  861 11  NestedShardedAtomicUpdateTest.test
 0123   1.0  863 13  SolrRrdBackendFactoryTest.testBasic
 0123   0.5  842  7  SystemCollectionCompatTest.testBackCompat
 Will BadApple all tests above this line except ones listed at the 
top**

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-03.csv
Processing file (History bit 2): HOSS-2019-05-28.csv
Processing file (History bit 1): HOSS-2019-05-20.csv
Processing file (History bit 0): HOSS-2019-05-13.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: 3
   FullSolrCloudDistribCmdsTest.test
   SolrZkClientTest.testSimpleUpdateACLs
   TestCollectionStateWatchers.testCanWaitForNonexistantCollection


Failures in Hoss' reports for the last 4 rollups.

There were 199 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   5.2  902 30  
AliasIntegrationTest.testClusterStateProviderAPI
 0123  23.8   97 25  
HdfsAutoAddReplicasIntegrationTest.testSimple
 0123   0.5  848  8  
LegacyCloudClusterPropTest.testCreateCollectionSwitchLegacyCloud
 0123   1.8  861 11  NestedShardedAtomicUpdateTest.test
 0123   1.0  863 13  SolrRrdBackendFactoryTest.testBasic
 0123   0.5  842  7  SystemCollectionCompatTest.testBackCompat
 Will BadApple all tests above this line except ones listed at the 
top**



 0120.9  637  4  HttpPartitionTest.test
 0121.0  612  6  JWTAuthPluginIntegrationTest.testMetrics
 0124.3   70  4  ShardSplitTest.testSplitWithChaosMonkey
 0120.5  601  6  
StreamDecoratorTest.testParallelCommitStream
 0120.5  636  5  TestDynamicLoading.testDynamicLoading
 01 3   3.0  684 16  BasicAuthIntegrationTest.testBasicAuth
 01 3   1.0  643  4  DeleteReplicaTest.deleteLiveReplicaTest
 01 3   0.9  659  7  PeerSyncReplicationTest.test
 01 3   0.9  673  4  ShardSplitTest.testSplitShardWithRule
 01 3   1.0  627  4  TestCloudRecovery2.test
 01 3   0.6  542  3  
TestDelegationWithHadoopAuth.testDelegationTokenRenew
 01 0.5  420  2  
ActionThrottleTest.testAZeroNano

[jira] [Commented] (SOLR-13509) NullPointerException in JSON Facet if omitHeaders=true

[Munendra S N (JIRA)]

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

Munendra S N commented on SOLR-13509:
-

I think this is caused by SOLR-9882

> NullPointerException in JSON Facet if omitHeaders=true
> --
>
> Key: SOLR-13509
> URL: https://issues.apache.org/jira/browse/SOLR-13509
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Affects Versions: 8.1.1
> Environment: Solr 8.1.1 downloaded tar gz, started in cloud mode:
> {code:java}
> bin/solr start -e cloud -noprompt
> bin/solr create -c techproducts -s 2 -rf 2 -d 
> server/solr/configsets/sample_techproducts_configs/conf -n 
> sample_techproducts_configs
> bin/post -c techproducts example/exampledocs/*.xml{code}
>Reporter: Markus Kalkbrenner
>Priority: Major
>
> The error exists in Solr 8.1.1 and didn't occur in Solr 8.0 and 7.x.
> Running this simple JSON Facet against the techproducts example (in cloud 
> mode) succeeds as expected:
> {code:java}
> curl http://localhost:8983/solr/techproducts/select -d '
> q=*:*&
> omitHeader=false&
> json.facet={
>   "max_price" : "max(price)"
> }{code}
> But as soon you omit Headers it results in a NullPointerException (which 
> didn't happen in earlier Solr versions):
> {code:java}
> curl http://localhost:8983/solr/techproducts/select -d '
> q=*:*&
> omitHeader=true&
> json.facet={
>   "max_price" : "max(price)"
> }'
> {code}
> Exception:
> {noformat}
> 2019-06-03 12:40:11.446 ERROR (qtp67730604-361) [c:techproducts s:shard2 
> r:core_node7 x:techproducts_shard2_replica_n4] o.a.s.h.RequestHandlerBase 
> java.lang.NullPointerException
>     at 
> org.apache.solr.search.facet.FacetModule.handleResponses(FacetModule.java:284)
>     at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
>     at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
>     at org.apache.solr.core.SolrCore.execute(SolrCore.java:2566)
>     at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:756)
>     at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:542)
>     at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)
>     at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)
>     at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
>     at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
>     at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
>     at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
>     at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
>     at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
>     at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)
>     at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
>     at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)
>     at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
>     at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)
>     at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)
>     at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>     at 
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
>     at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>     at org.eclipse.jetty.server.Server.handle(Server.java:502)
>     at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)
>     at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)
>     at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
>     at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
>     at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)
>     at 
> or

[jira] [Updated] (SOLR-13512) Raw index data analysis tool

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated SOLR-13512:
-
Attachment: SOLR-13512.patch

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



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

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

[jira] [Created] (SOLR-13512) Raw index data analysis tool

[Andrzej Bialecki (JIRA)]

Andrzej Bialecki  created SOLR-13512:


 Summary: Raw index data analysis tool
 Key: SOLR-13512
 URL: https://issues.apache.org/jira/browse/SOLR-13512
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Andrzej Bialecki 
Assignee: Andrzej Bialecki 
 Attachments: SOLR-13512.patch

A common question from Solr users is how to determine how a given schema field 
and all its related index data contributes to the total index size.

It's possible to estimate this information by doing a single full pass through 
all index data, aggregating estimated sizes of terms, postings, doc values and 
stored fields. The totals represent of course the worst case scenario when 
there's no index compression at all, but still they should be useful for 
answering the questions above.



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

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

[jira] [Updated] (SOLR-12249) Better error message when grouping on a tokenized (non SortableText) field in SolrCloud

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-12249:
--
Summary: Better error message when grouping on a tokenized (non 
SortableText) field in SolrCloud  (was: Grouping on a solr.TextField works in 
stand-alone but not in SolrCloud)

> Better error message when grouping on a tokenized (non SortableText) field in 
> SolrCloud
> ---
>
> Key: SOLR-12249
> URL: https://issues.apache.org/jira/browse/SOLR-12249
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6.2, 8.0
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
>
> I didn't test this with master. Under the covers in stand-alone mode, the 
> "min" function is silently  substituted for the grouping, but that's not true 
> in SorlCloud mode. I broke this JIRA out separately to discuss whether it 
> _ever_ makes sense to group by a tokenized text field.
> Grouping by the min value in a field is at least consistent, but on a text 
> field I don't think it makes sense.
> I propose that we explicitly dis-allow this in both stand-alone and Cloud 
> mode, especially now that there's the SortableTextField.
> Comments?



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

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

[jira] [Resolved] (SOLR-13489) Stop the leader from trying to rejoin the election on session expiration and harden our zk reconnect code path.

[Mark Miller (JIRA)]

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

Mark Miller resolved SOLR-13489.

   Resolution: Fixed
Fix Version/s: 8.2
   master (9.0)

Thanks [~anshumg]!

> Stop the leader from trying to rejoin the election on session expiration and 
> harden our zk reconnect code path.
> ---
>
> Key: SOLR-13489
> URL: https://issues.apache.org/jira/browse/SOLR-13489
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0), 8.2
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>




--
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-13489) Stop the leader from trying to rejoin the election on session expiration and harden our zk reconnect code path.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13489:


Commit 96f000334ccacc211a6a277cfa7d283c4f80823c in lucene-solr's branch 
refs/heads/branch_8x from Mark Robert Miller
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=96f0003 ]

SOLR-13489: Stop the leader from trying to rejoin the election on session 
expiration and harden our zk reconnect code path.

# Conflicts:
#   solr/core/src/test/org/apache/solr/cloud/OverseerTest.java


> Stop the leader from trying to rejoin the election on session expiration and 
> harden our zk reconnect code path.
> ---
>
> Key: SOLR-13489
> URL: https://issues.apache.org/jira/browse/SOLR-13489
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>




--
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] markrmiller closed pull request #689: SOLR-13489: Stop the leader from trying to rejoin the election on ses…

[GitBox]

markrmiller closed pull request #689: SOLR-13489: Stop the leader from trying 
to rejoin the election on ses…
URL: https://github.com/apache/lucene-solr/pull/689
 
 
   


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] [Updated] (SOLR-13511) For SearchHandler, expose "new ResponseBuilder()" to allow override

[Ramsey Haddad (JIRA)]

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

Ramsey Haddad updated SOLR-13511:
-
Attachment: SOLR-13511.patch

> For SearchHandler, expose "new ResponseBuilder()" to allow override
> ---
>
> Key: SOLR-13511
> URL: https://issues.apache.org/jira/browse/SOLR-13511
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Ramsey Haddad
>Priority: Trivial
>  Labels: easyfix
> Attachments: SOLR-13511.patch
>
>
> This change is all we want upstream. To use this from our plugins, we intend:
> Extend ResponseBuilder to have additional state (and we think others might 
> want to as well).
> Use an extended SearchHandler that simply creates our ResponseBuilder instead 
> of the standard one.
> We also extend QueryComponent to do our extra behavior if it sees our 
> Response builder instead of the standard one.
> We then change config to use our Search Handler for requestHandler with 
> name="/select" and our QueryComponent for searchComponent with name="query".



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

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

[JENKINS] Lucene-Solr-Tests-7.7 - Build # 34 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.7/34/

3 tests failed.
FAILED:  
org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitShardWithRule

Error Message:
Error from server at http://127.0.0.1:38633/f_o: Could not find collection : 
shardSplitWithRule_rewrite

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:38633/f_o: Could not find collection : 
shardSplitWithRule_rewrite
at 
__randomizedtesting.SeedInfo.seed([E36EE48FAF16F228:6260353D32E4A903]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:484)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:414)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1110)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.cloud.api.collections.ShardSplitTest.doSplitShardWithRule(ShardSplitTest.java:661)
at 
org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitShardWithRule(ShardSplitTest.java:628)
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:1075)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1047)
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.rand

[jira] [Created] (SOLR-13511) For SearchHandler, expose "new ResponseBuilder()" to allow override

[Ramsey Haddad (JIRA)]

Ramsey Haddad created SOLR-13511:


 Summary: For SearchHandler, expose "new ResponseBuilder()" to 
allow override
 Key: SOLR-13511
 URL: https://issues.apache.org/jira/browse/SOLR-13511
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: search
Reporter: Ramsey Haddad


This change is all we want upstream. To use this from our plugins, we intend:

Extend ResponseBuilder to have additional state (and we think others might want 
to as well).
Use an extended SearchHandler that simply creates our ResponseBuilder instead 
of the standard one.
We also extend QueryComponent to do our extra behavior if it sees our Response 
builder instead of the standard one.
We then change config to use our Search Handler for requestHandler with 
name="/select" and our QueryComponent for searchComponent with name="query".



--
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: Use of JIRA fixVersion

[Erick Erickson]

> On Jun 3, 2019, at 6:41 AM, David Smiley  wrote:
> 
> If someone wants to know what branches an issue was committed to, then review 
> the bot comments to find out. 

What if I want to form a query that shows me all JIRAs fixed in version X.Y.Z? 

A bot comments with “branch_5x” doesn’t tell me which minor version it’s in, 
5.1? 5.5?
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13434) OpenTracing support for Solr

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat commented on SOLR-13434:
-

Hi [~janhoy], I see the PR get failed with {{JWTAuthPluginIntegrationTest}}, I 
did some modification in the test, so it can be passed, if you have time please 
taking a look at changes.

Basically, Http2SolrClient does not set attribute {{REQ_PRINCIPAL_KEY}} on 
update requests, so it uses PKI instead of JWT. But I think it should uses JWT 
whenever the listener is registered in Http2SolrClient and userPrincipal is not 
null.

> OpenTracing support for Solr
> 
>
> Key: SOLR-13434
> URL: https://issues.apache.org/jira/browse/SOLR-13434
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Shalin Shekhar Mangar
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13434.patch
>
>  Time Spent: 7.5h
>  Remaining Estimate: 0h
>
> [OpenTracing|https://opentracing.io/] is a vendor neutral API and 
> infrastructure for distributed tracing. Many OSS tracers just as Jaeger, 
> OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing 
> APIs. Ideally, we can implement it once and have integrations for popular 
> tracers like we have with metrics and prometheus.
> I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack 
> of activity so this is a fresh attempt at solving this problem.



--
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-8820) Download page must not redirect to mirror page

[JIRA]

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

Jan Høydahl commented on LUCENE-8820:
-

I was thinking to link to closer script, since "Download" means the PDF 
release. But more user friendly with a link to /guide.

Btw. The /solr/guide page has a link to 
[https://www.apache.org/dyn/closer.cgi/lucene/solr/ref-guide] but it is very 
hard to users to perform the SHA / PGP verification from that link, since they 
will have to know how to navigate to archive to find the sha512 and asc files 
etc. It's of course not that important for the ref-guide as for code, but what 
do you think about linking to the PDF alongside asc and sha files on the 
download page just as for the other artifacts? Then the /solr/guide page could 
instead link to the /solr/downloads.html page...

> Download page must not redirect to mirror page
> --
>
> Key: LUCENE-8820
> URL: https://issues.apache.org/jira/browse/LUCENE-8820
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/website
>Reporter: Sebb
>Assignee: Jan Høydahl
>Priority: Major
>
> The direct download page [1] currently redirects to the mirror system [2] 
> after a few seconds.
> I think that is wrong; users should be encouraged to verify the downloads, 
> but the redirect makes verification harder.
> The normal download page [3] is OK.
> [1] [http://lucene.apache.org/solr/mirrors-solr-latest-redir.html]
> [2] http://www.apache.org/dyn/closer.lua/lucene/solr/8.1.1
> [3] http://lucene.apache.org/solr/downloads.html



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

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

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

[Policeman Jenkins Server]

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

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

Error Message:
Error from server at http://127.0.0.1:34883: ADDREPLICA failed to create replica

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:34883: ADDREPLICA failed to create replica
at 
__randomizedtesting.SeedInfo.seed([3082729F9FC7B4CE:8841263F631C61BB]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:649)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1068)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:837)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:769)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:224)
at 
org.apache.solr.cloud.api.collections.ShardSplitTest.doSplitMixedReplicaTypes(ShardSplitTest.java:376)
at 
org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitMixedReplicaTypes(ShardSplitTest.java:348)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOve

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk-11.0.2) - Build # 5178 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/5178/
Java: 64bit/jdk-11.0.2 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitAfterFailedSplit

Error Message:
Shard split did not succeed after a previous failed split attempt left 
sub-shards in construction state

Stack Trace:
java.lang.AssertionError: Shard split did not succeed after a previous failed 
split attempt left sub-shards in construction state
at 
__randomizedtesting.SeedInfo.seed([8852DA125AF1ECF:F1C8BE0E19DA5345]:0)
at org.junit.Assert.fail(Assert.java:88)
at 
org.apache.solr.cloud.api.collections.ShardSplitTest.splitAfterFailedSplit(ShardSplitTest.java:328)
at 
org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitAfterFailedSplit(ShardSplitTest.java:290)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
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.eva

[jira] [Commented] (SOLR-13510) Intermittent 401's for internode requests with basicauth enabled

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-13510:
--

The same person commented about this behavior to SOLR-13421. The issues are 
possibly duplicates?

> Intermittent 401's for internode requests with basicauth enabled
> 
>
> Key: SOLR-13510
> URL: https://issues.apache.org/jira/browse/SOLR-13510
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Priority: Major
>
> We recently got a bug report on the mailing list:
> {quote}
> On Solr 8.1.1, using our previously working security.json, running queries
> (through the admin UI currently) I non-deterministically get 401 responses
> on queries when a collection has more than 1 shard. Increasing the number
> of shards in the collection makes the errors more likely.
> {
>   "responseHeader":{
> "zkConnected":true,
> "status":401,
> "QTime":30,
> "params":{
>   "q":"*:*",
>   "_":"1559474550365"}},
>   "error":{
> "metadata":[
> "error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException",
> "root-error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException"],
> "msg":"Error from server at null: Expected mime type
> application/octet-stream but got text/html. \n\n http-equiv=\"Content-Type\"
> content=\"text/html;charset=utf-8\"/>\nError 401 require
> authentication\n\nHTTP ERROR 401\nProblem
> accessing /solr/gettingstarted_shard4_replica_n6/select. Reason:\n
>  require authentication\n\n\n",
> "code":401}}
> {quote}
> The reporter (credit to Colvin Cowie) also gives reproduction steps:
> {quote}
># Extract solr 8.1.1.
># bin\solr start -e cloud
> 1 node / [default port] / [default collection name] / 4 shards / 1
> replica / [_default configuration]
># server\scripts\cloud-scripts\zkcli -zkhost localhost:9983 -cmd putfile
> /security.json 
> {
> "authentication": {
> "blockUnknown": true,
> "class": "solr.BasicAuthPlugin",
> "credentials": {
> "solradmin": "PIWZwkGnEKxKnqUs3X08xmbmYBaYyAeP3FiKp7fmeHc=
> Lnbp6bEbE7Ap8lXvQDKkUX2Xw53QDgP6Ae8QRT0P5/A="
> }
> },
> "authorization": {
> "class": "solr.RuleBasedAuthorizationPlugin",
> "permissions": [{ "name": "all", "role": "admin"} ],
> "user-role": {"solradmin": "admin"}
> }
> }
> {quote}
> (Minor edits for conciseness)
> I'm able to reproduce this bug as well.  Other auth issues (SOLR-13472) look 
> like they're impacted by the topography of the collection and cluster.  But 
> this doesn't seem affected by that at all (401's occur on inter-node requests 
> regardless of the recipient of the initial request, and even when all nodes 
> have a shard replica).



--
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-8823) IllegalStateException: wrong number of values added during doc values merge

[Michael McCandless (JIRA)]

Michael McCandless created LUCENE-8823:
--

 Summary: IllegalStateException: wrong number of values added 
during doc values merge
 Key: LUCENE-8823
 URL: https://issues.apache.org/jira/browse/LUCENE-8823
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: 7.6
Reporter: Michael McCandless


Here's another mysterious exception we hit in production, on Lucene 7.x 
snapshot release (near 7.6), OpenJDK 11:
{noformat}
2019-05-31T05:49:22,443 [ERROR] (Lucene Merge Thread #0) 
com.amazon.lucene.util.UncaughtExceptionHandler: Uncaught exception: 
org.apache.lucene.index.MergePolicy$MergeException: 
java.lang.IllegalStateException: Wrong number of values added, expected: 97006, 
got: 95784 in thread Thread[Lucene Merge Thread #0,5,main] 
org.apache.lucene.index.MergePolicy$MergeException: 
java.lang.IllegalStateException: Wrong number of values added, expected: 97006, 
got: 95784
at 
org.apache.lucene.index.ConcurrentMergeScheduler.handleMergeException(ConcurrentMergeScheduler.java:704)
at 
org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:684)
Caused by: java.lang.IllegalStateException: Wrong number of values added, 
expected: 97006, got: 95784
at org.apache.lucene.util.packed.DirectWriter.finish(DirectWriter.java:94)
at 
org.apache.lucene.codecs.lucene70.Lucene70DocValuesConsumer.writeValuesSingleBlock(Lucene70DocValuesConsumer.java:283)
at 
org.apache.lucene.codecs.lucene70.Lucene70DocValuesConsumer.writeValues(Lucene70DocValuesConsumer.java:263)
at 
org.apache.lucene.codecs.lucene70.Lucene70DocValuesConsumer.addNumericField(Lucene70DocValuesConsumer.java:110)
at 
org.apache.lucene.codecs.DocValuesConsumer.mergeNumericField(DocValuesConsumer.java:175)
at org.apache.lucene.codecs.DocValuesConsumer.merge(DocValuesConsumer.java:135)
at 
org.apache.lucene.codecs.perfield.PerFieldDocValuesFormat$FieldsWriter.merge(PerFieldDocValuesFormat.java:151)
at org.apache.lucene.index.SegmentMerger.mergeDocValues(SegmentMerger.java:182)
at org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:126)
at org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4438)
at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:4060)
at 
org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:625)
at 
com.amazon.lucene.index.ConcurrentMergeSchedulerWrapper.doMerge(ConcurrentMergeSchedulerWrapper.java:54)
at 
org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:662){noformat}
Merging of a numeric doc values field failed because too few values were added. 
 This may also be a JVM bug, though our doc values codec code is quite complex 
so it could also be a Lucene bug!



--
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-13510) Intermittent 401's for internode requests with basicauth enabled

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski commented on SOLR-13510:


The 401 appears to be on an inter-node request, which is odd since those 
typically use PKI for authentication.  Following up on this I added 
{{"forwardCredentials": "true}} as an authentication property in security.json, 
and the behavior goes away.  The behavior persists though if the 
"forwardCredentials" property is either "false", or missing entirely.

This seems like a bug in the handling of this new property.  It seems that 
sometimes requests are sent without PKI, even when forwardCredentials=false 
would indicate that they should be.

[~janhoy] do you have any guesses why this might be?  I think you were involved 
in the new "forwardCredentials" change.  It seems easy enough to reproduce if 
you get a few minutes to take a look.

> Intermittent 401's for internode requests with basicauth enabled
> 
>
> Key: SOLR-13510
> URL: https://issues.apache.org/jira/browse/SOLR-13510
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Priority: Major
>
> We recently got a bug report on the mailing list:
> {quote}
> On Solr 8.1.1, using our previously working security.json, running queries
> (through the admin UI currently) I non-deterministically get 401 responses
> on queries when a collection has more than 1 shard. Increasing the number
> of shards in the collection makes the errors more likely.
> {
>   "responseHeader":{
> "zkConnected":true,
> "status":401,
> "QTime":30,
> "params":{
>   "q":"*:*",
>   "_":"1559474550365"}},
>   "error":{
> "metadata":[
> "error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException",
> "root-error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException"],
> "msg":"Error from server at null: Expected mime type
> application/octet-stream but got text/html. \n\n http-equiv=\"Content-Type\"
> content=\"text/html;charset=utf-8\"/>\nError 401 require
> authentication\n\nHTTP ERROR 401\nProblem
> accessing /solr/gettingstarted_shard4_replica_n6/select. Reason:\n
>  require authentication\n\n\n",
> "code":401}}
> {quote}
> The reporter (credit to Colvin Cowie) also gives reproduction steps:
> {quote}
># Extract solr 8.1.1.
># bin\solr start -e cloud
> 1 node / [default port] / [default collection name] / 4 shards / 1
> replica / [_default configuration]
># server\scripts\cloud-scripts\zkcli -zkhost localhost:9983 -cmd putfile
> /security.json 
> {
> "authentication": {
> "blockUnknown": true,
> "class": "solr.BasicAuthPlugin",
> "credentials": {
> "solradmin": "PIWZwkGnEKxKnqUs3X08xmbmYBaYyAeP3FiKp7fmeHc=
> Lnbp6bEbE7Ap8lXvQDKkUX2Xw53QDgP6Ae8QRT0P5/A="
> }
> },
> "authorization": {
> "class": "solr.RuleBasedAuthorizationPlugin",
> "permissions": [{ "name": "all", "role": "admin"} ],
> "user-role": {"solradmin": "admin"}
> }
> }
> {quote}
> (Minor edits for conciseness)
> I'm able to reproduce this bug as well.  Other auth issues (SOLR-13472) look 
> like they're impacted by the topography of the collection and cluster.  But 
> this doesn't seem affected by that at all (401's occur on inter-node requests 
> regardless of the recipient of the initial request, and even when all nodes 
> have a shard replica).



--
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: Use of JIRA fixVersion

[David Smiley]

Thanks for raising this thread Jan.  I agree with Jan's proposal -- *it is
what I already do*.  And based on some responses here, what some others do
as well.  And as some others here have stated, I agree that we should try
to only populate the fixVersion when resolving the issue (what I already
do, usually.  This isn't a big deal though; I review this on every issue
resolution that I do.

An example where fixVersion=master that led to user confusion is here:
https://issues.apache.org/jira/browse/LUCENE-6863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16806254#comment-16806254

If someone wants to know what *branches* an issue was committed to, then
review the bot comments to find out.  This is what I do -- I trust those
comments more than I trust people to fill out JIRA metadata
accurately/meaningfully :-)

Mike Sokolov said:
> The main use I've had for this field: as a user, I want to know whether
this bug or feature has been fixed or is available in the version I am
using, and if not, which version I would need to upgrade to in order to get
it. For this use case I think it's important to list versions on each
branch it has been ported to, up to the first major version release that
included it.

Naturally this use case is important but I fail to see how our proposed
approach fails to address it.  Maybe your point is about your
intuition/assumptions on what fixVersion=7.2 (for example) *means *(to
you)?  Some will get that, and some won't... yet would be confused by also
fixVersion=master so I suppose it's impossible to satisfy everyone's
intuitions about what the semantics mean.

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


On Sun, Jun 2, 2019 at 1:35 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> I put in the fix version after commit as well.
>
> In fact, in SOLR-11876, someone had put in a fix version involving a
> backport before I committed (which I didn't notice) and I resolved it
> without actually backporting. It caused a confusion, and resulted in a
> backport release to go out without the fix. ☹️
>
> On Sun, 2 Jun, 2019, 8:29 PM Erick Erickson, 
> wrote:
>
>> bq. Currently we tag issues with fixVersion before commit, to indicate
>> what BRANCHES we intend to commit to
>>
>> I don’t ;). In fact, I’d favor requiring this to be blank until a fix is
>> committed. There are, as you’ve found, far too many instances where it’s
>> filled in and completely inaccurate.
>>
>> What I prefer to put in the fixVersion is the version numbers of all the
>> branches I ported the fix to. There are things we put in, say, 8x that
>> never get into the next major version. How would we know which ones those
>> are?
>>
>> Can the build tool get clever with a query about requiring the JIRA to be
>> closed before using fixVersion at all?
>>
>> Erick
>>
>> > On Jun 1, 2019, at 11:58 AM, Jan Høydahl  wrote:
>> >
>> > Currently we tag issues with fixVersion before commit, to indicate what
>> BRANCHES we intend to commit to
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>

[jira] [Created] (LUCENE-8822) UnsupportedOperationException: unused: not a comparsion-based sort during IndexWriter flush

[Michael McCandless (JIRA)]

Michael McCandless created LUCENE-8822:
--

 Summary: UnsupportedOperationException: unused: not a 
comparsion-based sort during IndexWriter flush
 Key: LUCENE-8822
 URL: https://issues.apache.org/jira/browse/LUCENE-8822
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: 7.6
Reporter: Michael McCandless


We hit this very strange exception in production 7.x snapshot (near 7.6), 
OpenJDK 11:
{noformat}
Caused by: java.lang.UnsupportedOperationException: unused: not a 
comparison-based sort
at org.apache.lucene.util.MSBRadixSorter.compare(MSBRadixSorter.java:115)
at org.apache.lucene.util.Sorter.siftDown(Sorter.java:235)
at org.apache.lucene.util.Sorter.heapify(Sorter.java:228)
at 
org.apache.lucene.util.MSBRadixSorter.computeCommonPrefixLengthAndBuildHistogram(MSBRadixSorter.java:209)
at org.apache.lucene.util.MSBRadixSorter.radixSort(MSBRadixSorter.java:148)
at org.apache.lucene.util.MSBRadixSorter.radixSort(MSBRadixSorter.java:155)
at org.apache.lucene.util.MSBRadixSorter.sort(MSBRadixSorter.java:128)
at org.apache.lucene.util.MSBRadixSorter.sort(MSBRadixSorter.java:121)
at 
org.apache.lucene.util.bkd.MutablePointsReaderUtils.sort(MutablePointsReaderUtils.java:90)
at org.apache.lucene.util.bkd.BKDWriter.writeField1Dim(BKDWriter.java:497)
at org.apache.lucene.util.bkd.BKDWriter.writeField(BKDWriter.java:427)
at 
org.apache.lucene.codecs.lucene60.Lucene60PointsWriter.writeField(Lucene60PointsWriter.java:105)
at org.apache.lucene.index.PointValuesWriter.flush(PointValuesWriter.java:183)
at 
org.apache.lucene.index.DefaultIndexingChain.writePoints(DefaultIndexingChain.java:206)
at 
org.apache.lucene.index.DefaultIndexingChain.flush(DefaultIndexingChain.java:141)
at 
org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:470)
at org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:554)
at 
org.apache.lucene.index.DocumentsWriter.flushOneDWPT(DocumentsWriter.java:257)
at org.apache.lucene.index.IndexWriter.flushNextBuffer(IndexWriter.java:3157)
at com.amazon.lucene.index.Indexer.lambda$commit$0(Indexer.java:1129){noformat}
The exception makes no sense to me: when I look at 
{{MSBRadixSorter.computeCommonPrefixLengthAndBuildHistogram}} at that line it 
does NOT invoke {{Sorter.heapify}} so I'm mystified.  Maybe this is a JVM bug 
...

 



--
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-13510) Intermittent 401's for internode requests with basicauth enabled

[Jason Gerlowski (JIRA)]

Jason Gerlowski created SOLR-13510:
--

 Summary: Intermittent 401's for internode requests with basicauth 
enabled
 Key: SOLR-13510
 URL: https://issues.apache.org/jira/browse/SOLR-13510
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Authentication
Affects Versions: master (9.0)
Reporter: Jason Gerlowski


We recently got a bug report on the mailing list:

{quote}
On Solr 8.1.1, using our previously working security.json, running queries
(through the admin UI currently) I non-deterministically get 401 responses
on queries when a collection has more than 1 shard. Increasing the number
of shards in the collection makes the errors more likely.

{
  "responseHeader":{
"zkConnected":true,
"status":401,
"QTime":30,
"params":{
  "q":"*:*",
  "_":"1559474550365"}},
  "error":{
"metadata":[

"error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException",

"root-error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException"],
"msg":"Error from server at null: Expected mime type
application/octet-stream but got text/html. \n\n\nError 401 require
authentication\n\nHTTP ERROR 401\nProblem
accessing /solr/gettingstarted_shard4_replica_n6/select. Reason:\n
 require authentication\n\n\n",
"code":401}}
{quote}

The reporter (credit to Colvin Cowie) also gives reproduction steps:

{quote}
   # Extract solr 8.1.1.
   # bin\solr start -e cloud
1 node / [default port] / [default collection name] / 4 shards / 1
replica / [_default configuration]
   # server\scripts\cloud-scripts\zkcli -zkhost localhost:9983 -cmd putfile
/security.json 

{
"authentication": {
"blockUnknown": true,
"class": "solr.BasicAuthPlugin",
"credentials": {
"solradmin": "PIWZwkGnEKxKnqUs3X08xmbmYBaYyAeP3FiKp7fmeHc=
Lnbp6bEbE7Ap8lXvQDKkUX2Xw53QDgP6Ae8QRT0P5/A="
}
},
"authorization": {
"class": "solr.RuleBasedAuthorizationPlugin",
"permissions": [{ "name": "all", "role": "admin"} ],
"user-role": {"solradmin": "admin"}
}
}
{quote}

(Minor edits for conciseness)

I'm able to reproduce this bug as well.  Other auth issues (SOLR-13472) look 
like they're impacted by the topography of the collection and cluster.  But 
this doesn't seem affected by that at all (401's occur on inter-node requests 
regardless of the recipient of the initial request, and even when all nodes 
have a shard replica).





--
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-13508) Solr.log file was not updating with latest information

[Gus Heck (JIRA)]

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

Gus Heck updated SOLR-13508:

Priority: Major  (was: Blocker)

> Solr.log file was not updating with latest information
> --
>
> Key: SOLR-13508
> URL: https://issues.apache.org/jira/browse/SOLR-13508
> Project: Solr
>  Issue Type: Wish
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: raja
>Priority: Major
>  Labels: solr.log
>
> Since last 4 months solr.log file was not updating/growing with the latest 
> solr logs information. we have properly configured the log4j.properties file 
> and log4j.xml files. whenever we are restarting the solr service the only 
> "solr-8983-console.log" updated with solr restart time stamp. we have 
> verified the solr.log file location on server level with find command but 
> it's showing only what we configured on .properties file location.
> Need your help on how solr admin console showing latest logs information and 
> From where it is pulling the latest logs from server.
> Solr version :7.5 Server type: linux



--
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-13508) Solr.log file was not updating with latest information

[Gus Heck (JIRA)]

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

Gus Heck resolved SOLR-13508.
-
Resolution: Invalid

> Solr.log file was not updating with latest information
> --
>
> Key: SOLR-13508
> URL: https://issues.apache.org/jira/browse/SOLR-13508
> Project: Solr
>  Issue Type: Wish
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: raja
>Priority: Blocker
>  Labels: solr.log
>
> Since last 4 months solr.log file was not updating/growing with the latest 
> solr logs information. we have properly configured the log4j.properties file 
> and log4j.xml files. whenever we are restarting the solr service the only 
> "solr-8983-console.log" updated with solr restart time stamp. we have 
> verified the solr.log file location on server level with find command but 
> it's showing only what we configured on .properties file location.
> Need your help on how solr admin console showing latest logs information and 
> From where it is pulling the latest logs from server.
> Solr version :7.5 Server type: linux



--
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] diegoceccarelli commented on a change in pull request #300: SOLR-11831: Skip second grouping step if group.limit is 1 (aka Las Vegas Patch)

[GitBox]

diegoceccarelli commented on a change in pull request #300: SOLR-11831: Skip 
second grouping step if group.limit is 1 (aka Las Vegas Patch)
URL: https://github.com/apache/lucene-solr/pull/300#discussion_r289842271
 
 

 ##
 File path: 
solr/core/src/java/org/apache/solr/handler/component/QueryComponent.java
 ##
 @@ -288,6 +328,13 @@ protected void prepareGrouping(ResponseBuilder rb) throws 
IOException {
 groupingSpec.setMain(params.getBool(GroupParams.GROUP_MAIN, false));
 groupingSpec.setNeedScore((rb.getFieldFlags() & 
SolrIndexSearcher.GET_SCORES) != 0);
 groupingSpec.setTruncateGroups(params.getBool(GroupParams.GROUP_TRUNCATE, 
false));
+
+
groupingSpec.setSkipSecondGroupingStep(params.getBool(GroupParams.GROUP_SKIP_DISTRIBUTED_SECOND,
 false));
+boolean isReranking = (rb.getRankQuery() != null);
+if (groupingSpec.isSkipSecondGroupingStep() & 
!allowSkipSecondGroupingStep(groupingSpec.getWithinGroupSortSpec(), 
groupingSpec.getGroupSortSpec(), isReranking)){
 
 Review comment:
   done in 725bfc


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] diegoceccarelli commented on a change in pull request #300: SOLR-11831: Skip second grouping step if group.limit is 1 (aka Las Vegas Patch)

[GitBox]

diegoceccarelli commented on a change in pull request #300: SOLR-11831: Skip 
second grouping step if group.limit is 1 (aka Las Vegas Patch)
URL: https://github.com/apache/lucene-solr/pull/300#discussion_r289842271
 
 

 ##
 File path: 
solr/core/src/java/org/apache/solr/handler/component/QueryComponent.java
 ##
 @@ -288,6 +328,13 @@ protected void prepareGrouping(ResponseBuilder rb) throws 
IOException {
 groupingSpec.setMain(params.getBool(GroupParams.GROUP_MAIN, false));
 groupingSpec.setNeedScore((rb.getFieldFlags() & 
SolrIndexSearcher.GET_SCORES) != 0);
 groupingSpec.setTruncateGroups(params.getBool(GroupParams.GROUP_TRUNCATE, 
false));
+
+
groupingSpec.setSkipSecondGroupingStep(params.getBool(GroupParams.GROUP_SKIP_DISTRIBUTED_SECOND,
 false));
+boolean isReranking = (rb.getRankQuery() != null);
+if (groupingSpec.isSkipSecondGroupingStep() & 
!allowSkipSecondGroupingStep(groupingSpec.getWithinGroupSortSpec(), 
groupingSpec.getGroupSortSpec(), isReranking)){
 
 Review comment:
   done in 725bfc8


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] diegoceccarelli commented on a change in pull request #300: SOLR-11831: Skip second grouping step if group.limit is 1 (aka Las Vegas Patch)

[GitBox]

diegoceccarelli commented on a change in pull request #300: SOLR-11831: Skip 
second grouping step if group.limit is 1 (aka Las Vegas Patch)
URL: https://github.com/apache/lucene-solr/pull/300#discussion_r289842271
 
 

 ##
 File path: 
solr/core/src/java/org/apache/solr/handler/component/QueryComponent.java
 ##
 @@ -288,6 +328,13 @@ protected void prepareGrouping(ResponseBuilder rb) throws 
IOException {
 groupingSpec.setMain(params.getBool(GroupParams.GROUP_MAIN, false));
 groupingSpec.setNeedScore((rb.getFieldFlags() & 
SolrIndexSearcher.GET_SCORES) != 0);
 groupingSpec.setTruncateGroups(params.getBool(GroupParams.GROUP_TRUNCATE, 
false));
+
+
groupingSpec.setSkipSecondGroupingStep(params.getBool(GroupParams.GROUP_SKIP_DISTRIBUTED_SECOND,
 false));
+boolean isReranking = (rb.getRankQuery() != null);
+if (groupingSpec.isSkipSecondGroupingStep() & 
!allowSkipSecondGroupingStep(groupingSpec.getWithinGroupSortSpec(), 
groupingSpec.getGroupSortSpec(), isReranking)){
 
 Review comment:
   done in fc8c9c7


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-13508) Solr.log file was not updating with latest information

[Gus Heck (JIRA)]

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

Gus Heck commented on SOLR-13508:
-

Apache's Jira is not a support portal, it's for development only. Any time you 
feel like writing the word "help" this is the wrong place to write it. Please 
use the mailing list.

Jira is for when:
 # You have (or will soon have) a patch or pull request with direct code 
changes that need review
 # You have steps to reproduce, (from a fresh install if possible).
 # You have proposed and discussed a new feature or bug fix on the list, got a 
positive reception and want to move to contributing that feature.

> Solr.log file was not updating with latest information
> --
>
> Key: SOLR-13508
> URL: https://issues.apache.org/jira/browse/SOLR-13508
> Project: Solr
>  Issue Type: Wish
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: raja
>Priority: Blocker
>  Labels: solr.log
>
> Since last 4 months solr.log file was not updating/growing with the latest 
> solr logs information. we have properly configured the log4j.properties file 
> and log4j.xml files. whenever we are restarting the solr service the only 
> "solr-8983-console.log" updated with solr restart time stamp. we have 
> verified the solr.log file location on server level with find command but 
> it's showing only what we configured on .properties file location.
> Need your help on how solr admin console showing latest logs information and 
> From where it is pulling the latest logs from server.
> Solr version :7.5 Server type: linux



--
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: VOTE: Apache Solr Reference Guide for Solr 8.0

[Đạt Cao Mạnh]

+1 Looks good to me.

On Mon, Jun 3, 2019 at 2:19 PM Joel Bernstein  wrote:

> +1
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
>
> On Mon, Jun 3, 2019 at 8:54 AM Cassandra Targett 
> wrote:
>
>> Jan, would you please suggest exact wording to correct the error you
>> pointed out (quoted below). Since I clearly don’t understand the change,
>> and this is months delayed already, that is likely be the fastest option to
>> get a respin started this week. Otherwise, it will need to wait for me to
>> wade back into the topic to see if I can understand what the correct
>> wording should be.
>>
>> Thank you,
>> Cassandra
>> On May 31, 2019, 3:37 PM -0500, Jan Høydahl ,
>> wrote:
>>
>> Viewed on a smartphone :)
>>
>> Comments:
>>
>> Major changes section:
>>
>> The Basic Authentication plugin now has an option forwardCredentials to
>> prevent Basic Auth headers from being sent for inter-node requests.
>>
>>
>> This is wrong. Basic Auth never sent basicauth headers inter-node, and
>> adding the “forwardcredentials” option lets user-originated requests be
>> forwarded with original basicauth credentials instead of PKI.
>>
>>
>>
>>
>>

-- 
*Best regards,*
*Cao Mạnh Đạt*
*E-mail: caomanhdat...@gmail.com *

Re: VOTE: Apache Solr Reference Guide for Solr 8.0

[Joel Bernstein]

+1

Joel Bernstein
http://joelsolr.blogspot.com/


On Mon, Jun 3, 2019 at 8:54 AM Cassandra Targett 
wrote:

> Jan, would you please suggest exact wording to correct the error you
> pointed out (quoted below). Since I clearly don’t understand the change,
> and this is months delayed already, that is likely be the fastest option to
> get a respin started this week. Otherwise, it will need to wait for me to
> wade back into the topic to see if I can understand what the correct
> wording should be.
>
> Thank you,
> Cassandra
> On May 31, 2019, 3:37 PM -0500, Jan Høydahl ,
> wrote:
>
> Viewed on a smartphone :)
>
> Comments:
>
> Major changes section:
>
> The Basic Authentication plugin now has an option forwardCredentials to
> prevent Basic Auth headers from being sent for inter-node requests.
>
>
> This is wrong. Basic Auth never sent basicauth headers inter-node, and
> adding the “forwardcredentials” option lets user-originated requests be
> forwarded with original basicauth credentials instead of PKI.
>
>
>
>
>

[jira] [Commented] (LUCENE-8819) org.apache.lucene.search.TestTopDocsMerge.testSort_1 failure

[Ignacio Vera (JIRA)]

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

Ignacio Vera commented on LUCENE-8819:
--

I set these two arguments in the VM configuration:
{code:java}
-Dtests.seed=E916688CE5BC9122 -Dtests.multiplier=3 {code}

> org.apache.lucene.search.TestTopDocsMerge.testSort_1 failure
> 
>
> Key: LUCENE-8819
> URL: https://issues.apache.org/jira/browse/LUCENE-8819
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8819.patch
>
>
> It can be reproduced with:
>  
> {code:java}
> ant test  -Dtestcase=TestTopDocsMerge -Dtests.method=testSort_1 
> -Dtests.seed=E916688CE5BC9122 -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=es-US -Dtests.timezone=Pacific/Johnston -Dtests.asserts=true 
> -Dtests.file.encoding=ISO-8859-1{code}
>  
> Test fails in master and branch 8.x but it does not fail in branch 8.1. 



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

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

[GitHub] [lucene-solr] diegoceccarelli commented on a change in pull request #300: SOLR-11831: Skip second grouping step if group.limit is 1 (aka Las Vegas Patch)

[GitBox]

diegoceccarelli commented on a change in pull request #300: SOLR-11831: Skip 
second grouping step if group.limit is 1 (aka Las Vegas Patch)
URL: https://github.com/apache/lucene-solr/pull/300#discussion_r289836805
 
 

 ##
 File path: solr/solrj/src/java/org/apache/solr/common/params/GroupParams.java
 ##
 @@ -66,5 +66,10 @@
   public static final String GROUP_DISTRIBUTED_SECOND = GROUP + 
".distributed.second";
 
   public static final String GROUP_DISTRIBUTED_TOPGROUPS_PREFIX = GROUP + 
".topgroups.";
+
+  /** activates optimization in case only one document per group.
+   * Setting this to true is only compatible with group.limit = 1
+   */
+  public static final String GROUP_SKIP_DISTRIBUTED_SECOND = GROUP + 
".skip.second.step";
 
 Review comment:
   Done in c5553ed


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] diegoceccarelli commented on a change in pull request #300: SOLR-11831: Skip second grouping step if group.limit is 1 (aka Las Vegas Patch)

[GitBox]

diegoceccarelli commented on a change in pull request #300: SOLR-11831: Skip 
second grouping step if group.limit is 1 (aka Las Vegas Patch)
URL: https://github.com/apache/lucene-solr/pull/300#discussion_r289836805
 
 

 ##
 File path: solr/solrj/src/java/org/apache/solr/common/params/GroupParams.java
 ##
 @@ -66,5 +66,10 @@
   public static final String GROUP_DISTRIBUTED_SECOND = GROUP + 
".distributed.second";
 
   public static final String GROUP_DISTRIBUTED_TOPGROUPS_PREFIX = GROUP + 
".topgroups.";
+
+  /** activates optimization in case only one document per group.
+   * Setting this to true is only compatible with group.limit = 1
+   */
+  public static final String GROUP_SKIP_DISTRIBUTED_SECOND = GROUP + 
".skip.second.step";
 
 Review comment:
   Done in c5553ed2ee5


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-8819) org.apache.lucene.search.TestTopDocsMerge.testSort_1 failure

[Atri Sharma (JIRA)]

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

Atri Sharma commented on LUCENE-8819:
-

[~ivera] I did set the seed in the test run (I am assuming you are also setting 
it in the VM configuration in test config setup?)

 

I do agree with you that 8757 is what changes the order of segments for 
parallel runs. I will dive deeper to see if I can find the root cause. Thanks 
for your investigation on this :)

> org.apache.lucene.search.TestTopDocsMerge.testSort_1 failure
> 
>
> Key: LUCENE-8819
> URL: https://issues.apache.org/jira/browse/LUCENE-8819
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8819.patch
>
>
> It can be reproduced with:
>  
> {code:java}
> ant test  -Dtestcase=TestTopDocsMerge -Dtests.method=testSort_1 
> -Dtests.seed=E916688CE5BC9122 -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=es-US -Dtests.timezone=Pacific/Johnston -Dtests.asserts=true 
> -Dtests.file.encoding=ISO-8859-1{code}
>  
> Test fails in master and branch 8.x but it does not fail in branch 8.1. 



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

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

[jira] [Commented] (LUCENE-8820) Download page must not redirect to mirror page

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on LUCENE-8820:
---

bq. For Solr I'm also considering a (non-versioned) link to ref-guide on the 
download page, what do others think?

The link would go to lucene.apache.org/solr/guide, you mean? That would be a 
good addition IMO.

> Download page must not redirect to mirror page
> --
>
> Key: LUCENE-8820
> URL: https://issues.apache.org/jira/browse/LUCENE-8820
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/website
>Reporter: Sebb
>Assignee: Jan Høydahl
>Priority: Major
>
> The direct download page [1] currently redirects to the mirror system [2] 
> after a few seconds.
> I think that is wrong; users should be encouraged to verify the downloads, 
> but the redirect makes verification harder.
> The normal download page [3] is OK.
> [1] [http://lucene.apache.org/solr/mirrors-solr-latest-redir.html]
> [2] http://www.apache.org/dyn/closer.lua/lucene/solr/8.1.1
> [3] http://lucene.apache.org/solr/downloads.html



--
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: CachingNaiveBayesClassifierTest failure locally

[David Smiley]

I've seen many cases where an IndexSearcher is created and there is no
value from the underlying query cache embedded in it.  Sometimes we
remember to disable it, sometimes not.  Tomasso, does
SimpleNaiveBayesClassifier benefit from that cache?

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


On Wed, May 29, 2019 at 10:44 PM Erick Erickson 
wrote:

> I’m pretty sure this has nothing to do with the upgrade to ZK since it’s a
> Lucene test case, but I ran across this and this hasn’t failed in Chris’
> rollups going back to last March so I thought people might want to see it.
> I have the full test log if anyone’s interested
>
>[junit4] Suite:
> org.apache.lucene.classification.CachingNaiveBayesClassifierTest
>[junit4]   2> NOTE: reproduce with: ant test
> -Dtestcase=CachingNaiveBayesClassifierTest -Dtests.method=testPerformance
> -Dtests.seed=A9F7A8BCC21AFCBA -Dtests.slow=true -Dtests.badapples=true
> -Dtests.locale=sq-AL -Dtests.timezone=America/Port-au-Prince
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] ERROR   5.10s J3 |
> CachingNaiveBayesClassifierTest.testPerformance <<<
>[junit4]> Throwable #1: java.lang.RuntimeException:
> java.util.concurrent.ExecutionException: java.lang.AssertionError
>[junit4]>at
> __randomizedtesting.SeedInfo.seed([A9F7A8BCC21AFCBA:6E165A9EA9AEC415]:0)
>[junit4]>at
> org.apache.lucene.classification.utils.ConfusionMatrixGenerator.getConfusionMatrix(ConfusionMatrixGenerator.java:131)
>[junit4]>at
> org.apache.lucene.classification.CachingNaiveBayesClassifierTest.testPerformance(CachingNaiveBayesClassifierTest.java:101)
>[junit4]>at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>[junit4]>at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]>at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]>at
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
>[junit4]>at java.base/java.lang.Thread.run(Thread.java:834)
>[junit4]> Caused by: java.util.concurrent.ExecutionException:
> java.lang.AssertionError
>[junit4]>at
> java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
>[junit4]>at
> java.base/java.util.concurrent.FutureTask.get(FutureTask.java:205)
>[junit4]>at
> org.apache.lucene.classification.utils.ConfusionMatrixGenerator.getConfusionMatrix(ConfusionMatrixGenerator.java:94)
>[junit4]>... 36 more
>[junit4]> Caused by: java.lang.AssertionError
>[junit4]>at
> java.base/java.util.HashMap$TreeNode.moveRootToFront(HashMap.java:1896)
>[junit4]>at
> java.base/java.util.HashMap$TreeNode.putTreeVal(HashMap.java:2061)
>[junit4]>at
> java.base/java.util.HashMap.putVal(HashMap.java:633)
>[junit4]>at
> java.base/java.util.HashMap.putIfAbsent(HashMap.java:1057)
>[junit4]>at
> org.apache.lucene.search.LRUQueryCache.putIfAbsent(LRUQueryCache.java:301)
>[junit4]>at
> org.apache.lucene.search.LRUQueryCache$CachingWrapperWeight.scorerSupplier(LRUQueryCache.java:745)
>[junit4]>at
> org.apache.lucene.search.BooleanWeight.scorerSupplier(BooleanWeight.java:361)
>[junit4]>at
> org.apache.lucene.search.BooleanWeight.scorer(BooleanWeight.java:327)
>[junit4]>at
> org.apache.lucene.search.Weight.bulkScorer(Weight.java:168)
>[junit4]>at
> org.apache.lucene.search.BooleanWeight.bulkScorer(BooleanWeight.java:321)
>[junit4]>at
> org.apache.lucene.search.LRUQueryCache$CachingWrapperWeight.cache(LRUQueryCache.java:693)
>[junit4]>at
> org.apache.lucene.search.LRUQueryCache$CachingWrapperWeight.bulkScorer(LRUQueryCache.java:825)
>[junit4]>at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:700)
>[junit4]>at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:494)
>[junit4]>at
> org.apache.lucene.classification.CachingNaiveBayesClassifier.getWordFreqForClassess(CachingNaiveBayesClassifier.java:170)
>[junit4]>at
> org.apache.lucene.classification.CachingNaiveBayesClassifier.calculateLogLikelihood(CachingNaiveBayesClassifier.java:100)
>[junit4]>at
> org.apache.lucene.classification.CachingNaiveBayesClassifier.assignClassNormalizedList(CachingNaiveBayesClassifier.java:83)
>[junit4]>at
> org.apache.lucene.classification.SimpleNaiveBayesClassifier.assignClass(SimpleNaiveBayesClassifier.java:103)
>[junit4]>at
> org.apache.lucene.classification.utils.ConfusionMatrixGenerator.lambda$getConfusionMatrix$0(ConfusionMatrixGenerator.ja

Re: VOTE: Apache Solr Reference Guide for Solr 8.0

[Cassandra Targett]

Jan, would you please suggest exact wording to correct the error you pointed 
out (quoted below). Since I clearly don’t understand the change, and this is 
months delayed already, that is likely be the fastest option to get a respin 
started this week. Otherwise, it will need to wait for me to wade back into the 
topic to see if I can understand what the correct wording should be.

Thank you,
Cassandra
On May 31, 2019, 3:37 PM -0500, Jan Høydahl , wrote:
> Viewed on a smartphone :)
>
> Comments:
>
> Major changes section:
>
> > The Basic Authentication plugin now has an option forwardCredentials to 
> > prevent Basic Auth headers from being sent for inter-node requests.
>
> This is wrong. Basic Auth never sent basicauth headers inter-node, and adding 
> the “forwardcredentials” option lets user-originated requests be forwarded 
> with original basicauth credentials instead of PKI.
> >

[jira] [Commented] (LUCENE-8819) org.apache.lucene.search.TestTopDocsMerge.testSort_1 failure

[Ignacio Vera (JIRA)]

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

Ignacio Vera commented on LUCENE-8819:
--

Note that you need to add the seed and the multiplier in IntelliJ. In that case 
I am able to reproduce it in the debugger.

What I observe is that documents come in different order and naively my best 
guess is that is due to the order of execution that 8757 has introduced, but I 
might be totally wrong :). 

> org.apache.lucene.search.TestTopDocsMerge.testSort_1 failure
> 
>
> Key: LUCENE-8819
> URL: https://issues.apache.org/jira/browse/LUCENE-8819
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8819.patch
>
>
> It can be reproduced with:
>  
> {code:java}
> ant test  -Dtestcase=TestTopDocsMerge -Dtests.method=testSort_1 
> -Dtests.seed=E916688CE5BC9122 -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=es-US -Dtests.timezone=Pacific/Johnston -Dtests.asserts=true 
> -Dtests.file.encoding=ISO-8859-1{code}
>  
> Test fails in master and branch 8.x but it does not fail in branch 8.1. 



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

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

[jira] [Created] (SOLR-13509) NullPointerException in JSON Facet if omitHeaders=true

[Markus Kalkbrenner (JIRA)]

Markus Kalkbrenner created SOLR-13509:
-

 Summary: NullPointerException in JSON Facet if omitHeaders=true
 Key: SOLR-13509
 URL: https://issues.apache.org/jira/browse/SOLR-13509
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Facet Module
Affects Versions: 8.1.1
 Environment: Solr 8.1.1 downloaded tar gz, started in cloud mode:
{code:java}
bin/solr start -e cloud -noprompt
bin/solr create -c techproducts -s 2 -rf 2 -d 
server/solr/configsets/sample_techproducts_configs/conf -n 
sample_techproducts_configs
bin/post -c techproducts example/exampledocs/*.xml{code}
Reporter: Markus Kalkbrenner


The error exists in Solr 8.1.1 and didn't occur in Solr 8.0 and 7.x.

Running this simple JSON Facet against the techproducts example (in cloud mode) 
succeeds as expected:
{code:java}
curl http://localhost:8983/solr/techproducts/select -d '
q=*:*&
omitHeader=false&
json.facet={
  "max_price" : "max(price)"
}{code}

But as soon you omit Headers it results in a NullPointerException (which didn't 
happen in earlier Solr versions):
{code:java}
curl http://localhost:8983/solr/techproducts/select -d '
q=*:*&
omitHeader=true&
json.facet={
  "max_price" : "max(price)"
}'
{code}
Exception:
{noformat}
2019-06-03 12:40:11.446 ERROR (qtp67730604-361) [c:techproducts s:shard2 
r:core_node7 x:techproducts_shard2_replica_n4] o.a.s.h.RequestHandlerBase 
java.lang.NullPointerException
    at 
org.apache.solr.search.facet.FacetModule.handleResponses(FacetModule.java:284)
    at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
    at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
    at org.apache.solr.core.SolrCore.execute(SolrCore.java:2566)
    at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:756)
    at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:542)
    at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)
    at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)
    at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
    at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)
    at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
    at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
    at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
    at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
    at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)
    at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
    at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)
    at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
    at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)
    at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)
    at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
    at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)
    at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
    at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)
    at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)
    at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
    at 
org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
    at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
    at org.eclipse.jetty.server.Server.handle(Server.java:502)
    at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)
    at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)
    at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
    at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
    at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)
    at 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
    at 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
    at 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
    at 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)
    at 
org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecuto

[GitHub] [lucene-solr] noblepaul commented on a change in pull request #681: Fix SOLR-13347

[GitBox]

noblepaul commented on a change in pull request #681: Fix SOLR-13347
URL: https://github.com/apache/lucene-solr/pull/681#discussion_r289826579
 
 

 ##
 File path: solr/core/src/java/org/apache/solr/update/TransactionLog.java
 ##
 @@ -102,6 +102,9 @@ public Object resolve(Object o, JavaBinCodec codec) throws 
IOException {
   };
 
   public class LogCodec extends JavaBinCodec {
+
+private static final byte UUID = 20;
 
 Review comment:
   There is a risk that somebody may accidently use the code `20` and break 
`LogCodec`. So, let's keep this static field in JavabinCodec and say "This is 
reserved to be used only in LogCodec"


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] noblepaul closed pull request #695: backporting SOLR-13504 & SOLR-13329

[GitBox]

noblepaul closed pull request #695: backporting SOLR-13504 & SOLR-13329
URL: https://github.com/apache/lucene-solr/pull/695
 
 
   


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] noblepaul opened a new pull request #695: backporting SOLR-13504 & SOLR-13329

[GitBox]

noblepaul opened a new pull request #695: backporting SOLR-13504 & SOLR-13329
URL: https://github.com/apache/lucene-solr/pull/695
 
 
   * SOLR-13504: In autoscaling policies, use an explicit 'nodeset' attribute 
for filtering
 nodes instead of using them directly at the toplevel (Generally available 
from SOLR 8.2)(noble)
   * SOLR-13329: In autoscaling policies, use an explicit 'put : on-each'
 to specify the the rules is applied on each node (Generally available from 
SOLR 8.2)(noble)
   


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-8819) org.apache.lucene.search.TestTopDocsMerge.testSort_1 failure

[Atri Sharma (JIRA)]

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

Atri Sharma commented on LUCENE-8819:
-

[~ivera] Hmm, I was working on the original forked branch for 8757, now rebased 
to master. Interestingly, the problem I described above does not occur in 
master, thanks to Adrien's replacement of the said code block.

 

Running the tests in IntelliJ did not reproduce the problem for me.Running from 
the commandline triggers the following assert. I am not sure if I understand 
how 8757 can affect this since 8757 primarily introduces two changes, one which 
is triggered only during building LeafSlice contexts (which in turn is invoked 
only for parallel search, and the failing tests do not do parallel segment 
reads AFAIK), and tightening up asserts in AssertingCollector (which are not 
getting tripped). Is this the same stack that you see in test failure for 
TestRegexpRandom2?:

 

 
{code:java}
at junit.framework.Assert.fail(Assert.java:57)
   [junit4]    > at 
org.apache.lucene.search.CheckHits.checkEqual(CheckHits.java:205)
   [junit4]    > at 
org.apache.lucene.search.TestRegexpRandom2.assertSame(TestRegexpRandom2.java:178)
   [junit4]    > at 
org.apache.lucene.search.TestRegexpRandom2.testRegexps(TestRegexpRandom2.java:164)
{code}
 

> org.apache.lucene.search.TestTopDocsMerge.testSort_1 failure
> 
>
> Key: LUCENE-8819
> URL: https://issues.apache.org/jira/browse/LUCENE-8819
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8819.patch
>
>
> It can be reproduced with:
>  
> {code:java}
> ant test  -Dtestcase=TestTopDocsMerge -Dtests.method=testSort_1 
> -Dtests.seed=E916688CE5BC9122 -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=es-US -Dtests.timezone=Pacific/Johnston -Dtests.asserts=true 
> -Dtests.file.encoding=ISO-8859-1{code}
>  
> Test fails in master and branch 8.x but it does not fail in branch 8.1. 



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

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

[GitHub] [lucene-solr] zsgyulavari commented on a change in pull request #685: SOLR-13434: OpenTracing support for Solr

[GitBox]

zsgyulavari commented on a change in pull request #685: SOLR-13434: OpenTracing 
support for Solr
URL: https://github.com/apache/lucene-solr/pull/685#discussion_r289819526
 
 

 ##
 File path: solr/core/src/java/org/apache/solr/util/tracing/GlobalTracer.java
 ##
 @@ -0,0 +1,82 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.util.tracing;
+
+import javax.servlet.http.HttpServletRequest;
+import java.util.Random;
+
+import io.opentracing.SpanContext;
+import io.opentracing.Tracer;
+import io.opentracing.noop.NoopTracerFactory;
+import io.opentracing.propagation.Format;
+
+public class GlobalTracer {
+  private static final Random RANDOM;
+  static {
+// We try to make things reproducible in the context of our tests by 
initializing the random instance
+// based on the current seed
+String seed = System.getProperty("tests.seed");
+if (seed == null) {
+  RANDOM = new Random();
+} else {
+  RANDOM = new Random(seed.hashCode());
+}
+  }
+
+  private static final Tracer NOOP_TRACER = NoopTracerFactory.create();
+  private static volatile Tracer TRACER = NOOP_TRACER;
+  private static volatile int rate;
+  private final static ThreadLocal threadLocal = new ThreadLocal<>();
+
+  public static void setup(Tracer tracer, double rate) {
+GlobalTracer.rate = (int) (rate * 10);
+GlobalTracer.TRACER = tracer;
+  }
+
+  public static boolean tracing() {
+return threadLocal.get() != null
+&& threadLocal.get() != NOOP_TRACER
+&& threadLocal.get().activeSpan() != null;
+  }
+
+  public static SpanContext extract(HttpServletRequest request) {
+SpanContext spanContext = TRACER.extract(Format.Builtin.HTTP_HEADERS, new 
HttpServletCarrier(request));
+if (spanContext != null) {
+  threadLocal.set(TRACER);
+}
+return spanContext;
+  }
+
+  public static Tracer get() {
+Tracer tracer = threadLocal.get();
+if (tracer != null)
+  return tracer;
+
+if (traced()) {
 
 Review comment:
   One last question regarding this:
   If the first node decided not to sample a trace is there a way to notify the 
subsequent nodes not to roll the dice again?


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-13347) Error writing Transaction log for UUIDField

[JIRA]

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

Thomas Wöckinger commented on SOLR-13347:
-

Pushed new implementation using LogCodec, added test to verify serialization 
and deserialization.

> Error writing Transaction log for UUIDField
> ---
>
> Key: SOLR-13347
> URL: https://issues.apache.org/jira/browse/SOLR-13347
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Server
>Affects Versions: 7.7, 7.7.1, 8.0
>Reporter: Thomas Wöckinger
>Priority: Major
>  Labels: pull-request-available, ready-to-commit, test
> Attachments: SOLR-13347.patch
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> When using Atomic Update, adding a value leads to following Exception
> org.apache.solr.common.SolrException: TransactionLog doesn't know how to 
> serialize class java.util.UUID; try implementing ObjectResolver?
>     at 
> org.apache.solr.update.TransactionLog$1.resolve(TransactionLog.java:100)
>     at 
> org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:263)
>     at 
> org.apache.solr.common.util.JavaBinCodec.writeArray(JavaBinCodec.java:770)
>     at 
> org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:369)
>     at 
> org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:362)
>     at 
> org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:252)
>     at 
> org.apache.solr.common.util.JavaBinCodec$BinEntryWriter.put(JavaBinCodec.java:437)
>     at 
> org.apache.solr.common.MapWriter$EntryWriter.putNoEx(MapWriter.java:100)
>     at 
> org.apache.solr.common.MapWriter$EntryWriter.lambda$getBiConsumer$0(MapWriter.java:160)
>     at java.base/java.util.LinkedHashMap.forEach(LinkedHashMap.java:684)
>     at 
> org.apache.solr.common.SolrInputDocument.writeMap(SolrInputDocument.java:51)
>     at 
> org.apache.solr.common.util.JavaBinCodec.writeSolrInputDocument(JavaBinCodec.java:657)
>     at org.apache.solr.update.TransactionLog.write(TransactionLog.java:371)
>     at org.apache.solr.update.UpdateLog.add(UpdateLog.java:573)
>     at org.apache.solr.update.UpdateLog.add(UpdateLog.java:552)
>     at 
> org.apache.solr.update.DirectUpdateHandler2.doNormalUpdate(DirectUpdateHandler2.java:351)
>     at 
> org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:289)
>     at 
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:236)
>     at 
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:76)
>     at 
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
>     at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:995)
>     at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1216)
>     at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:700)
>     at 
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)
>     at 
> org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:110)
>     at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:327)
>     at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readIterator(JavaBinUpdateRequestCodec.java:280)
>     at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:335)
>     at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:280)
>     at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readNamedList(JavaBinUpdateRequestCodec.java:235)
>     at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:300)
>     at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:280)
>     at 
> org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:193)
>     at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:126)
>     at 
> org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(JavabinLoader.java:123)
>     at 
> org.apache.solr.handler.loader.JavabinLoader.load(JavabinLoader.java:70)
>     at 
> org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:97)
>     at 
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68)
>     at 
> org.apache.solr.handler.RequestHandle