[jira] [Updated] (SOLR-14042) Fix 7 Varargs methods should only override or be overridden by other varargs methods warnings

[Andras Salamon (Jira)]

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

Andras Salamon updated SOLR-14042:
--
Status: Patch Available  (was: Open)

> Fix 7 Varargs methods should only override or be overridden by other varargs 
> methods warnings
> -
>
> Key: SOLR-14042
> URL: https://issues.apache.org/jira/browse/SOLR-14042
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Andras Salamon
>Priority: Minor
> Attachments: SOLR-14042-01.patch
>
>
> Precommit lists 7 quite similar varargs related warnings:
> {noformat}
> [ecj-lint] 1. WARNING in 
> /Users/andrassalamon/src/lucene-solr-upstream/solr/solrj/src/java/org/apache/solr/client/solrj/io/eval/ConcatEvaluator.java
>  (at line 46)
>  [ecj-lint]     public Object doWork(Object values[]) throws IOException {
>  [ecj-lint]                   ^^
>  [ecj-lint] Varargs methods should only override or be overridden by other 
> varargs methods unlike ConcatEvaluator.doWork(Object[]) and 
> ManyValueWorker.doWork(Object...)
> --
>  [ecj-lint] 2. WARNING in 
> /Users/andrassalamon/src/lucene-solr-upstream/solr/solrj/src/java/org/apache/solr/client/solrj/io/eval/DateEvaluator.java
>  (at line 44)
>  [ecj-lint]     public Object doWork(Object values[]) throws IOException {
>  [ecj-lint]                   ^^
>  [ecj-lint] Varargs methods should only override or be overridden by other 
> varargs methods unlike DateEvaluator.doWork(Object[]) and 
> ManyValueWorker.doWork(Object...)
> --
>  [ecj-lint] 3. WARNING in 
> /Users/andrassalamon/src/lucene-solr-upstream/solr/solrj/src/java/org/apache/solr/client/solrj/io/eval/DbscanEvaluator.java
>  (at line 44)
>  [ecj-lint]     public Object doWork(Object values[]) throws IOException {
>  [ecj-lint]                   ^^
>  [ecj-lint] Varargs methods should only override or be overridden by other 
> varargs methods unlike DbscanEvaluator.doWork(Object[]) and 
> ManyValueWorker.doWork(Object...)
> --
>  [ecj-lint] 4. WARNING in 
> /Users/andrassalamon/src/lucene-solr-upstream/solr/solrj/src/java/org/apache/solr/client/solrj/io/eval/EmpiricalDistributionEvaluator.java
>  (at line 41)
>  [ecj-lint]     public Object doWork(Object[] values) throws IOException {
>  [ecj-lint]                   ^^
>  [ecj-lint] Varargs methods should only override or be overridden by other 
> varargs methods unlike EmpiricalDistributionEvaluator.doWork(Object[]) and 
> ManyValueWorker.doWork(Object...)
> --
>  [ecj-lint] 5. WARNING in 
> /Users/andrassalamon/src/lucene-solr-upstream/solr/solrj/src/java/org/apache/solr/client/solrj/io/eval/MatchesEvaluator.java
>  (at line 39)
>  [ecj-lint]     public Object doWork(Object[] values) throws IOException {
>  [ecj-lint]                   ^^
>  [ecj-lint] Varargs methods should only override or be overridden by other 
> varargs methods unlike MatchesEvaluator.doWork(Object[]) and 
> ManyValueWorker.doWork(Object...)
> --
>  [ecj-lint] 6. WARNING in 
> /Users/andrassalamon/src/lucene-solr-upstream/solr/solrj/src/java/org/apache/solr/client/solrj/io/eval/MatchesEvaluator.java
>  (at line 39)
>  [ecj-lint]     public Object doWork(Object[] values) throws IOException {
>  [ecj-lint]                   ^^
>  [ecj-lint] Varargs methods should only override or be overridden by other 
> varargs methods unlike MatchesEvaluator.doWork(Object[]) and 
> RecursiveBooleanEvaluator.doWork(Object...)
> --
>  [ecj-lint] 7. WARNING in 
> /Users/andrassalamon/src/lucene-solr-upstream/solr/solrj/src/java/org/apache/solr/client/solrj/io/eval/PivotEvaluator.java
>  (at line 45)
>  [ecj-lint]     public Object doWork(Object[] values) throws IOException {
>  [ecj-lint]                   ^^
>  [ecj-lint] Varargs methods should only override or be overridden by other 
> varargs methods unlike PivotEvaluator.doWork(Object[]) and 
> ManyValueWorker.doWork(Object...) {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (SOLR-14042) Fix 7 Varargs methods should only override or be overridden by other varargs methods warnings

[Andras Salamon (Jira)]

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

Andras Salamon updated SOLR-14042:
--
Attachment: SOLR-14042-01.patch
Status: Open  (was: Open)

> Fix 7 Varargs methods should only override or be overridden by other varargs 
> methods warnings
> -
>
> Key: SOLR-14042
> URL: https://issues.apache.org/jira/browse/SOLR-14042
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Andras Salamon
>Priority: Minor
> Attachments: SOLR-14042-01.patch
>
>
> Precommit lists 7 quite similar varargs related warnings:
> {noformat}
> [ecj-lint] 1. WARNING in 
> /Users/andrassalamon/src/lucene-solr-upstream/solr/solrj/src/java/org/apache/solr/client/solrj/io/eval/ConcatEvaluator.java
>  (at line 46)
>  [ecj-lint]     public Object doWork(Object values[]) throws IOException {
>  [ecj-lint]                   ^^
>  [ecj-lint] Varargs methods should only override or be overridden by other 
> varargs methods unlike ConcatEvaluator.doWork(Object[]) and 
> ManyValueWorker.doWork(Object...)
> --
>  [ecj-lint] 2. WARNING in 
> /Users/andrassalamon/src/lucene-solr-upstream/solr/solrj/src/java/org/apache/solr/client/solrj/io/eval/DateEvaluator.java
>  (at line 44)
>  [ecj-lint]     public Object doWork(Object values[]) throws IOException {
>  [ecj-lint]                   ^^
>  [ecj-lint] Varargs methods should only override or be overridden by other 
> varargs methods unlike DateEvaluator.doWork(Object[]) and 
> ManyValueWorker.doWork(Object...)
> --
>  [ecj-lint] 3. WARNING in 
> /Users/andrassalamon/src/lucene-solr-upstream/solr/solrj/src/java/org/apache/solr/client/solrj/io/eval/DbscanEvaluator.java
>  (at line 44)
>  [ecj-lint]     public Object doWork(Object values[]) throws IOException {
>  [ecj-lint]                   ^^
>  [ecj-lint] Varargs methods should only override or be overridden by other 
> varargs methods unlike DbscanEvaluator.doWork(Object[]) and 
> ManyValueWorker.doWork(Object...)
> --
>  [ecj-lint] 4. WARNING in 
> /Users/andrassalamon/src/lucene-solr-upstream/solr/solrj/src/java/org/apache/solr/client/solrj/io/eval/EmpiricalDistributionEvaluator.java
>  (at line 41)
>  [ecj-lint]     public Object doWork(Object[] values) throws IOException {
>  [ecj-lint]                   ^^
>  [ecj-lint] Varargs methods should only override or be overridden by other 
> varargs methods unlike EmpiricalDistributionEvaluator.doWork(Object[]) and 
> ManyValueWorker.doWork(Object...)
> --
>  [ecj-lint] 5. WARNING in 
> /Users/andrassalamon/src/lucene-solr-upstream/solr/solrj/src/java/org/apache/solr/client/solrj/io/eval/MatchesEvaluator.java
>  (at line 39)
>  [ecj-lint]     public Object doWork(Object[] values) throws IOException {
>  [ecj-lint]                   ^^
>  [ecj-lint] Varargs methods should only override or be overridden by other 
> varargs methods unlike MatchesEvaluator.doWork(Object[]) and 
> ManyValueWorker.doWork(Object...)
> --
>  [ecj-lint] 6. WARNING in 
> /Users/andrassalamon/src/lucene-solr-upstream/solr/solrj/src/java/org/apache/solr/client/solrj/io/eval/MatchesEvaluator.java
>  (at line 39)
>  [ecj-lint]     public Object doWork(Object[] values) throws IOException {
>  [ecj-lint]                   ^^
>  [ecj-lint] Varargs methods should only override or be overridden by other 
> varargs methods unlike MatchesEvaluator.doWork(Object[]) and 
> RecursiveBooleanEvaluator.doWork(Object...)
> --
>  [ecj-lint] 7. WARNING in 
> /Users/andrassalamon/src/lucene-solr-upstream/solr/solrj/src/java/org/apache/solr/client/solrj/io/eval/PivotEvaluator.java
>  (at line 45)
>  [ecj-lint]     public Object doWork(Object[] values) throws IOException {
>  [ecj-lint]                   ^^
>  [ecj-lint] Varargs methods should only override or be overridden by other 
> varargs methods unlike PivotEvaluator.doWork(Object[]) and 
> ManyValueWorker.doWork(Object...) {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-14022) Remove CDCR from Solr

[Ishan Chattopadhyaya (Jira)]

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

Ishan Chattopadhyaya commented on SOLR-14022:
-

+1 to this ticket; CDCR needs to go for the sake of the health of the project.
Maybe, we can deprecate it now in 8x and remove it in 9x or 10x?
Also, if someone has time to spend can move it away from core and into a 
contrib module, then we can keep it around for whoever is using it as an 
optional package.

> Remove CDCR from Solr
> -
>
> Key: SOLR-14022
> URL: https://issues.apache.org/jira/browse/SOLR-14022
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Reporter: Joel Bernstein
>Priority: Major
>
> This ticket will remove CDCR from Solr



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-13904) Make Analytics component aware of timeAllowed

[Houston Putman (Jira)]

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

Houston Putman commented on SOLR-13904:
---

[~mkhl], I might be missing something, but I don't see my changes in the latest 
patch that you uploaded.

> Make Analytics component aware of timeAllowed
> -
>
> Key: SOLR-13904
> URL: https://issues.apache.org/jira/browse/SOLR-13904
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-13904.patch, SOLR-13904.patch, SOLR-13904.patch, 
> SOLR-13904.patch, SOLR-13904.patch, SOLR-13904.patch, SOLR-13904.patch
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-14022) Remove CDCR from Solr

[David Smiley (Jira)]

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

David Smiley commented on SOLR-14022:
-

I love the idea of it moving to a opt-in contrib module, or when the package 
system matures then potentially elsewhere.  A Solr strength is it's 
plug-ability.

> Remove CDCR from Solr
> -
>
> Key: SOLR-14022
> URL: https://issues.apache.org/jira/browse/SOLR-14022
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Reporter: Joel Bernstein
>Priority: Major
>
> This ticket will remove CDCR from Solr



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-14022) Remove CDCR from Solr

[Joel Bernstein (Jira)]

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

Joel Bernstein commented on SOLR-14022:
---

I like the idea of deprecating in 8x and removing in a 9x release.

> Remove CDCR from Solr
> -
>
> Key: SOLR-14022
> URL: https://issues.apache.org/jira/browse/SOLR-14022
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Reporter: Joel Bernstein
>Priority: Major
>
> This ticket will remove CDCR from Solr



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-14036) TermsComponent distributed search (shards) doesn't work with SolrCloud

[David Smiley (Jira)]

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

David Smiley commented on SOLR-14036:
-

I found the issue that introduced setting distrib=false in the config -- 
SOLR-3645 (linked).  Though it contains no real explanation, just an example 
but it was unclear why the example didn't work as the user expected.

> TermsComponent distributed search (shards) doesn't work with SolrCloud
> --
>
> Key: SOLR-14036
> URL: https://issues.apache.org/jira/browse/SOLR-14036
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SearchComponents - other
>Reporter: David Smiley
>Priority: Major
>
> My colleagues [~bruno.roustant] and [~antogruz] attempted to use the 
> {{TermsComponent}} in SolrCloud on a collection with multiple shards.  The 
> results were inconsistent depending on which shard the client was talking 
> with.  Looking at the prepare() method, I can see this component reads the 
> "shards" param.  It should not have been coded that way; the SearchHandler or 
> related machinery is responsible for parsing/processing that.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-14041) [SIP-1] Streamline Config/Schema APIs

[Jira]

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

Jan Høydahl commented on SOLR-14041:


Here is Solr's page 
[https://cwiki.apache.org/confluence/display/SOLR/Solr+Improvement+Proposals] 

You'll also find a template that you can start from.

> [SIP-1] Streamline Config/Schema APIs
> -
>
> Key: SOLR-14041
> URL: https://issues.apache.org/jira/browse/SOLR-14041
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Priority: Major
>
> Here's a JIRA for linking to confluence/Github pages etc. where we'll host 
> our SIPs going forward. We can add a link to an actual SIP draft as soon as 
> it is ready. [~dsmiley], [~janhoy], please suggest how/where we can have the 
> discussions around this.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-14036) TermsComponent distributed search (shards) doesn't work with SolrCloud

[Antoine Gruzelle (Jira)]

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

Antoine Gruzelle commented on SOLR-14036:
-

[~munendrasn]

Thank you for your answer. 

I replaced the *distrib=false* by *distrib=true* in solr configuration for the 
terms request handler. It worked as you predicted, and my request showed me the 
merged lists of my two shards.

 

> TermsComponent distributed search (shards) doesn't work with SolrCloud
> --
>
> Key: SOLR-14036
> URL: https://issues.apache.org/jira/browse/SOLR-14036
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SearchComponents - other
>Reporter: David Smiley
>Priority: Major
>
> My colleagues [~bruno.roustant] and [~antogruz] attempted to use the 
> {{TermsComponent}} in SolrCloud on a collection with multiple shards.  The 
> results were inconsistent depending on which shard the client was talking 
> with.  Looking at the prepare() method, I can see this component reads the 
> "shards" param.  It should not have been coded that way; the SearchHandler or 
> related machinery is responsible for parsing/processing that.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (SOLR-13904) Make Analytics component aware of timeAllowed

[Mikhail Khludnev (Jira)]

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

Mikhail Khludnev updated SOLR-13904:

Attachment: (was: SOLR-13904.patch)

> Make Analytics component aware of timeAllowed
> -
>
> Key: SOLR-13904
> URL: https://issues.apache.org/jira/browse/SOLR-13904
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-13904.patch, SOLR-13904.patch, SOLR-13904.patch, 
> SOLR-13904.patch, SOLR-13904.patch, SOLR-13904.patch
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Resolved] (SOLR-14036) TermsComponent distributed search (shards) doesn't work with SolrCloud

[David Smiley (Jira)]

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

David Smiley resolved SOLR-14036.
-
Resolution: Invalid

> TermsComponent distributed search (shards) doesn't work with SolrCloud
> --
>
> Key: SOLR-14036
> URL: https://issues.apache.org/jira/browse/SOLR-14036
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SearchComponents - other
>Reporter: David Smiley
>Priority: Major
>
> My colleagues [~bruno.roustant] and [~antogruz] attempted to use the 
> {{TermsComponent}} in SolrCloud on a collection with multiple shards.  The 
> results were inconsistent depending on which shard the client was talking 
> with.  Looking at the prepare() method, I can see this component reads the 
> "shards" param.  It should not have been coded that way; the SearchHandler or 
> related machinery is responsible for parsing/processing that.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Closed] (SOLR-14036) TermsComponent distributed search (shards) doesn't work with SolrCloud

[David Smiley (Jira)]

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

David Smiley closed SOLR-14036.
---

> TermsComponent distributed search (shards) doesn't work with SolrCloud
> --
>
> Key: SOLR-14036
> URL: https://issues.apache.org/jira/browse/SOLR-14036
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SearchComponents - other
>Reporter: David Smiley
>Priority: Major
>
> My colleagues [~bruno.roustant] and [~antogruz] attempted to use the 
> {{TermsComponent}} in SolrCloud on a collection with multiple shards.  The 
> results were inconsistent depending on which shard the client was talking 
> with.  Looking at the prepare() method, I can see this component reads the 
> "shards" param.  It should not have been coded that way; the SearchHandler or 
> related machinery is responsible for parsing/processing that.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-13957) Add sensible defaults for the facet, random, facet2D, timeseries, stats and update Streaming Expressions

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-13957:


Commit 57761f5b536cf4fbd5ca797367272d7a88ccff41 in lucene-solr's branch 
refs/heads/branch_8x from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=57761f5 ]

SOLR-13957: Add sensible defaults for the facet, random, facet2D, timeseries, 
stats and update Streaming Expressions


> Add sensible defaults for the facet, random, facet2D, timeseries, stats and 
> update Streaming Expressions
> 
>
> Key: SOLR-13957
> URL: https://issues.apache.org/jira/browse/SOLR-13957
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Affects Versions: 8.3
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Minor
> Fix For: 8.4
>
> Attachments: SOLR-13957.patch
>
>
> This ticket will add sensible defaults to the *facet*, *random, facet2D, 
> timeseries, stats* and *update* streaming expressions so that users can type 
> in fewer parameters and receive sensible results. This is part of an overall 
> set of changes designed to make Streaming Expressions and Math Expressions as 
> easy as possible to use to drive adoption.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Created] (LUCENE-9089) FST.Builder with fluent-style constructor

[Bruno Roustant (Jira)]

Bruno Roustant created LUCENE-9089:
--

 Summary: FST.Builder with fluent-style constructor
 Key: LUCENE-9089
 URL: https://issues.apache.org/jira/browse/LUCENE-9089
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Bruno Roustant
Assignee: Bruno Roustant






--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (SOLR-13904) Make Analytics component aware of timeAllowed

[Mikhail Khludnev (Jira)]

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

Mikhail Khludnev updated SOLR-13904:

Attachment: SOLR-13904.patch
Status: Patch Available  (was: Patch Available)

> Make Analytics component aware of timeAllowed
> -
>
> Key: SOLR-13904
> URL: https://issues.apache.org/jira/browse/SOLR-13904
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-13904.patch, SOLR-13904.patch, SOLR-13904.patch, 
> SOLR-13904.patch, SOLR-13904.patch, SOLR-13904.patch, SOLR-13904.patch
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (LUCENE-9089) FST.Builder with fluent-style constructor

[Bruno Roustant (Jira)]

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

Bruno Roustant updated LUCENE-9089:
---
Description: 
A first step in a try to make the FST code easier to read and evolve. This step 
is just about the FST Builder constructor.

By making it fluent, the many calls to it are simplified and it becomes easy to 
spot the intent and special param tuning.

No functional change.

> FST.Builder with fluent-style constructor
> -
>
> Key: LUCENE-9089
> URL: https://issues.apache.org/jira/browse/LUCENE-9089
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Bruno Roustant
>Assignee: Bruno Roustant
>Priority: Minor
>
> A first step in a try to make the FST code easier to read and evolve. This 
> step is just about the FST Builder constructor.
> By making it fluent, the many calls to it are simplified and it becomes easy 
> to spot the intent and special param tuning.
> No functional change.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-13947) Documentation on configuring StreamHandler incorrect

[Joel Bernstein (Jira)]

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

Joel Bernstein commented on SOLR-13947:
---

Thanks for contributions [~epugh] and the commit [~tflobbe]!

> Documentation on configuring StreamHandler incorrect
> 
>
> Key: SOLR-13947
> URL: https://issues.apache.org/jira/browse/SOLR-13947
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Affects Versions: 8.3
>Reporter: David Eric Pugh
>Priority: Minor
> Fix For: master (9.0), 8.4
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> The JavaDocs for {{StreamHandler}} are not correct for how to add additional 
> Streaming Expressions.   It refers to a .
> This configuration DOES work for {{GraphHandler}}, who is configured 
> differently than {{StreamHandler}}, and maybe is a seperate bug!



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-14041) [SIP-1] Streamline Config/Schema APIs

[Ishan Chattopadhyaya (Jira)]

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

Ishan Chattopadhyaya commented on SOLR-14041:
-

Thanks [~janhoy], that page looks fantastic. I think instead of mailing list, 
we should optionally be able to use a JIRA (as it supports attachments, 
formatting etc.).

> [SIP-1] Streamline Config/Schema APIs
> -
>
> Key: SOLR-14041
> URL: https://issues.apache.org/jira/browse/SOLR-14041
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Priority: Major
>
> Here's a JIRA for linking to confluence/Github pages etc. where we'll host 
> our SIPs going forward. We can add a link to an actual SIP draft as soon as 
> it is ready. [~dsmiley], [~janhoy], please suggest how/where we can have the 
> discussions around this.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-13904) Make Analytics component aware of timeAllowed

[Mikhail Khludnev (Jira)]

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

Mikhail Khludnev commented on SOLR-13904:
-

Sorry. Thank you, [~houston]. Attached the right one. 

> Make Analytics component aware of timeAllowed
> -
>
> Key: SOLR-13904
> URL: https://issues.apache.org/jira/browse/SOLR-13904
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-13904.patch, SOLR-13904.patch, SOLR-13904.patch, 
> SOLR-13904.patch, SOLR-13904.patch, SOLR-13904.patch, SOLR-13904.patch
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-8834) NPE for BlockJoinFacetComponent and facet.prefix not working

[Munendra S N (Jira)]

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

Munendra S N commented on SOLR-8834:


Recently, I came across SOLR-14031 which is related to BlockJoinFacetComponent. 
With improvements in JSON facet child rollup SOLR-8998 and child exclusions in 
SOLR-9510, should we deprecate this component in 8x and remove in 9.0?
Is there anything supported by this component which is not yet supported in 
JSON facet module.
[~mkhl] WDYT?

> NPE for BlockJoinFacetComponent and facet.prefix not working
> 
>
> Key: SOLR-8834
> URL: https://issues.apache.org/jira/browse/SOLR-8834
> Project: Solr
>  Issue Type: Bug
>  Components: faceting
>Affects Versions: 5.5
>Reporter: Vijay Sekhri
>Priority: Minor
> Attachments: SOLR-8834.patch
>
>
> Sometime for some types of queries a NPE is thrown .  This is the code where 
> it was happening.
> {code}
> 14:00:20,751 ERROR [org.apache.solr.servlet.HttpSolrCall] 
> (http-/10.235.43.43:8580-82) null:java.lang.NullPointerException
> at 
> org.apache.solr.search.join.BlockJoinFacetCollector.incrementFacets(BlockJoinFacetCollector.java:100)
> at 
> org.apache.solr.search.join.BlockJoinFacetCollector.collect(BlockJoinFacetCollector.java:87)
> {code}
> It could be related to stats query that does not even have any 
> ToParentBlockJoin syntax . Here is one example
> {code}
> 15:07:56,736 INFO  [org.apache.solr.core.SolrCore.Request] 
> (http-/10.235.43.43:8580-143) [core1]  webapp=/solr path=/select 
> params={shards.qt=searchStandard&tie=0.01&stats=true&distrib=false&q.alt=*:*&originIP=10.235.52.131&collection=search1&shards.tolerant=true&version=2&NOW=1454360876733&shard.url=http://solrx331p.qa.ch3.s.com:8580/solr/core1/|http://solrx351p.qa.ch3.s.com:8580/solr/core1/&fl=id&fl=score&bf=%0a&timeAllowed=1&qt=searchStandard&fsv=true&fq=catalogs:(("10104"))&fq=searchableAttributes:(("Metal%3DTri+color"))&fq=brand:("Black+Hills+Gold")&fq=discount:("70")&fq=primaryCategory:("10104_3_Jewelry_Diamonds_Rings")&mm=%0a2<-1+5<-2+6<-50%25%0a&hasOrigCategories=1&qf=%0a+primaryLnames^5.0+partnumber^11.0+itemnumber^11.0+fullmfpartno^5.0+mfpartno^5.0+xref^10.0+storeOriginSearchable^3.0+nameSearchable^10.0+brandSearchable^5.0++searchPhrase^1.0++searchableAttributesSearchable^1.0%0a&wt=javabin&rows=0&pf=%0a+++primaryLnames^0.5+nameSearchable^1.0+storeOriginSearchable^0.3+brandSearchable^0.5++xref^1.1+searchableAttributesSearchable^0.1%0a&shards.purpose=516&start=0&q=white+diamonds+diamonds+elizabeth+taylor+body+lotion&bot=true&stats.field=price_10151_f&isShard=true&ps=100}
>  hits=0 status=0 QTime=0
> 15:07:56,758 ERROR [org.apache.solr.handler.RequestHandlerBase] 
> (http-/10.235.43.43:8580-26) java.lang.NullPointerException
> at 
> org.apache.solr.search.join.BlockJoinFacetCollector.incrementFacets(BlockJoinFacetCollector.java:100)
> at 
> org.apache.solr.search.join.BlockJoinFacetCollector.collect(BlockJoinFacetCollector.java:87)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:1153)
> at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:350)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:273)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)
> {code}
> Furthermore,
> when facet.prefix is passed it is not being honored by child.facet.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[GitHub] [lucene-solr] kwatters commented on a change in pull request #976: SOLR-13749: Implement support for joining across collections with multiple shards

[GitBox]

kwatters commented on a change in pull request #976: SOLR-13749: Implement 
support for joining across collections with multiple shards
URL: https://github.com/apache/lucene-solr/pull/976#discussion_r356117937
 
 

 ##
 File path: solr/core/src/java/org/apache/solr/search/join/XCJFQParser.java
 ##
 @@ -46,17 +46,25 @@
   QueryParsing.TYPE, QueryParsing.V, ZK_HOST, SOLR_URL, COLLECTION, 
FROM, TO, ROUTED_BY_JOIN_KEY, TTL));
 
   private final String routerField;
+  private final Set solrUrlWhitelist;
 
-  public XCJFQParser(String qstr, SolrParams localParams, SolrParams params, 
SolrQueryRequest req, String routerField) {
+  public XCJFQParser(String qstr, SolrParams localParams, SolrParams params, 
SolrQueryRequest req, String routerField, Set solrUrlWhiteList) {
 super(qstr, localParams, params, req);
 this.routerField = routerField;
+// If specified in the config, this will limit which solr url's the parser 
can connect to.
+this.solrUrlWhitelist = solrUrlWhiteList;
   }
 
   @Override
   public Query parse() throws SyntaxError {
 String query = localParams.get(QueryParsing.V);
 String zkHost = localParams.get(ZK_HOST);
 String solrUrl = localParams.get(SOLR_URL);
+// Test if this is a valid solr url.
 
 Review comment:
   I'm ok with that.  Thanks gus!


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: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-13749) Implement support for joining across collections with multiple shards ( XCJF )

[Kevin Watters (Jira)]

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

Kevin Watters commented on SOLR-13749:
--

Under the covers, this query parser does use a streaming expression to get back 
the full set of join keys from the remote collection.  
Here's the stream creation:  
[https://github.com/apache/lucene-solr/pull/976/files#diff-6f5d64d0defefc8535e889677b3a7ed1R233]

 

> Implement support for joining across collections with multiple shards ( XCJF )
> --
>
> Key: SOLR-13749
> URL: https://issues.apache.org/jira/browse/SOLR-13749
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Kevin Watters
>Assignee: Gus Heck
>Priority: Major
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> This ticket includes 2 query parsers.
> The first one is the "Cross collection join filter"  (XCJF) parser. This is 
> the "Cross-collection join filter" query parser. It can do a call out to a 
> remote collection to get a set of join keys to be used as a filter against 
> the local collection.
> The second one is the Hash Range query parser that you can specify a field 
> name and a hash range, the result is that only the documents that would have 
> hashed to that range will be returned.
> This query parser will do an intersection based on join keys between 2 
> collections.
> The local collection is the collection that you are searching against.
> The remote collection is the collection that contains the join keys that you 
> want to use as a filter.
> Each shard participating in the distributed request will execute a query 
> against the remote collection.  If the local collection is setup with the 
> compositeId router to be routed on the join key field, a hash range query is 
> applied to the remote collection query to only match the documents that 
> contain a potential match for the documents that are in the local shard/core. 
>  
>  
> Here's some vocab to help with the descriptions of the various parameters.
> ||Term||Description||
> |Local Collection|This is the main collection that is being queried.|
> |Remote Collection|This is the collection that the XCJFQuery will query to 
> resolve the join keys.|
> |XCJFQuery|The lucene query that executes a search to get back a set of join 
> keys from a remote collection|
> |HashRangeQuery|The lucene query that matches only the documents whose hash 
> code on a field falls within a specified range.|
>  
>  
> ||Param ||Required ||Description||
> |collection|Required|The name of the external Solr collection to be queried 
> to retrieve the set of join key values ( required )|
> |zkHost|Optional|The connection string to be used to connect to Zookeeper.  
> zkHost and solrUrl are both optional parameters, and at most one of them 
> should be specified.  
> If neither of zkHost or solrUrl are specified, the local Zookeeper cluster 
> will be used. ( optional )|
> |solrUrl|Optional|The URL of the external Solr node to be queried ( optional 
> )|
> |from|Required|The join key field name in the external collection ( required 
> )|
> |to|Required|The join key field name in the local collection|
> |v|See Note|The query to be executed against the external Solr collection to 
> retrieve the set of join key values.  
> Note:  The original query can be passed at the end of the string or as the 
> "v" parameter.  
> It's recommended to use query parameter substitution with the "v" parameter 
> to ensure no issues arise with the default query parsers.|
> |routed| |true / false.  If true, the XCJF query will use each shard's hash 
> range to determine the set of join keys to retrieve for that shard.
> This parameter improves the performance of the cross-collection join, but 
> it depends on the local collection being routed by the toField.  If this 
> parameter is not specified, 
> the XCJF query will try to determine the correct value automatically.|
> |ttl| |The length of time that an XCJF query in the cache will be considered 
> valid, in seconds.  Defaults to 3600 (one hour).  
> The XCJF query will not be aware of changes to the remote collection, so 
> if the remote collection is updated, cached XCJF queries may give inaccurate 
> results.  
> After the ttl period has expired, the XCJF query will re-execute the join 
> against the remote collection.|
> |_All others_| |Any normal Solr parameter can also be specified as a local 
> param.|
>  
> Example Solr Config.xml changes:
>  
>  {{<}}{{cache}} {{name}}{{=}}{{"hash_vin"}}
>  {{   }}{{class}}{{=}}{{"solr.LRUCache"}}
>  {{   }}{{size}}{{=}}{{"128"}}
>  {{   }}{{initialSize}}{{=}}{{"0"}}
>  {{   }}{{regenerator}}{{=}}{{"solr.NoOpRegen

[jira] [Commented] (SOLR-13999) Ref Guide is missing the ZKHost parameter for TopicStream

[David Eric Pugh (Jira)]

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

David Eric Pugh commented on SOLR-13999:


[~gerlowskija]any edits/comments that I should make to make this comittable?

> Ref Guide is missing the ZKHost parameter for TopicStream
> -
>
> Key: SOLR-13999
> URL: https://issues.apache.org/jira/browse/SOLR-13999
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation, streaming expressions
>Affects Versions: 8.3
>Reporter: David Eric Pugh
>Assignee: Jason Gerlowski
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> During a discussion about if you can use Streaming expressions across 
> seperate Solr clusters, noticed that the `search` expression supports passing 
> in a ZK Host, but `topic` doesn't.   However, investigating the code, you can 
> pass in your own zk host to register a tpic on another Solr cluster.  This is 
> to fix the docs.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[GitHub] [lucene-solr] risdenk commented on issue #1068: SOLR-14033: Fix Hadoop tests with security manager

[GitBox]

risdenk commented on issue #1068: SOLR-14033: Fix Hadoop tests with security 
manager
URL: https://github.com/apache/lucene-solr/pull/1068#issuecomment-564102265
 
 
   Found a better way to do it. Set core-site.xml on the default test resources 
so it gets picked up for all `new Configuration()`. Currently just setting the 
the group mapping that config.


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: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Created] (SOLR-14043) The allow precision Math Expression to operate on matrices

[Joel Bernstein (Jira)]

Joel Bernstein created SOLR-14043:
-

 Summary: The allow precision Math Expression to operate on matrices
 Key: SOLR-14043
 URL: https://issues.apache.org/jira/browse/SOLR-14043
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: streaming expressions
Reporter: Joel Bernstein


The *precision* function currently operates on a number and on a vector. This 
ticket will allow it operate on a matrix. When applied to a matrix each value 
in the matrix will have it's precision adjusted.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (SOLR-14043) The allow precision Math Expression to operate on matrices

[Joel Bernstein (Jira)]

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

Joel Bernstein updated SOLR-14043:
--
Description: The *precision* function currently operates on a number and on 
a vector. This ticket will allow it operate on a matrix. When applied to a 
matrix each value in the matrix will have its precision adjusted in place. This 
is to avoid unnecessary copying of large matrices.   (was: The *precision* 
function currently operates on a number and on a vector. This ticket will allow 
it operate on a matrix. When applied to a matrix each value in the matrix will 
have it's precision adjusted.)

> The allow precision Math Expression to operate on matrices
> --
>
> Key: SOLR-14043
> URL: https://issues.apache.org/jira/browse/SOLR-14043
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Priority: Minor
>
> The *precision* function currently operates on a number and on a vector. This 
> ticket will allow it operate on a matrix. When applied to a matrix each value 
> in the matrix will have its precision adjusted in place. This is to avoid 
> unnecessary copying of large matrices. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[GitHub] [lucene-solr] risdenk commented on issue #1068: SOLR-14033: Fix Hadoop tests with security manager

[GitBox]

risdenk commented on issue #1068: SOLR-14033: Fix Hadoop tests with security 
manager
URL: https://github.com/apache/lucene-solr/pull/1068#issuecomment-564104338
 
 
   @chatman @gerlowskija FYI based on 
https://the-asf.slack.com/archives/CEKUCUNE9/p1575957768305100


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: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[GitHub] [lucene-solr] risdenk commented on issue #1068: SOLR-14033: Fix Hadoop tests with security manager

[GitBox]

risdenk commented on issue #1068: SOLR-14033: Fix Hadoop tests with security 
manager
URL: https://github.com/apache/lucene-solr/pull/1068#issuecomment-564104718
 
 
   This is passing tests pretty regularly on Mac. Better than before where all 
tests were failing. 


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: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (LUCENE-9077) Gradle build

[Kevin Risden (Jira)]

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

Kevin Risden commented on LUCENE-9077:
--

SOLR-14033 should undo the security manager hacks for Hadoop to unblock this as 
well.

> Gradle build
> 
>
> Key: LUCENE-9077
> URL: https://issues.apache.org/jira/browse/LUCENE-9077
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Major
> Fix For: master (9.0)
>
>
> This task focuses on providing gradle-based build equivalent for Lucene and 
> Solr (on master branch). See notes below on why this respin is needed.
> The code lives on *gradle-master* branch. It is kept with sync with *master*. 
> Try running the following to see an overview of helper guides concerning 
> typical workflow, testing and ant-migration helpers:
> gradlew :help
> A list of items that needs to be added or requires work. If you'd like to 
> work on any of these, please add your name to the list. Once you have a 
> patch/ pull request let me (dweiss) know - I'll try to coordinate the merges.
>  * (/) Apply forbiddenAPIs
>  * (/) Generate hardware-aware gradle defaults for parallelism (count of 
> workers and test JVMs).
>  * (/) Fail the build if --tests filter is applied and no tests execute 
> during the entire build (this allows for an empty set of filtered tests at 
> single project level).
>  * (/) Port other settings and randomizations from common-build.xml
>  * (/) Configure security policy/ sandboxing for tests.
>  * (/) test's console output on -Ptests.verbose=true
>  * (/) add a :helpDeps explanation to how the dependency system works 
> (palantir plugin, lockfile) and how to retrieve structured information about 
> current dependencies of a given module (in a tree-like output).
>  * jar checksums, jar checksum computation and validation. This should be 
> done without intermediate folders (directly on dependency sets).
>  * identify and list precommit tasks so that they can be ported one by one. 
> (Mark's branch has some of this stuff already implemented)
>  * Repro-line for failed tests/ runs.
> Hard-to-implement stuff already investigated:
>  * (!) Printing console output of failed tests. There doesn't seem to be any 
> way to do this in a reasonably efficient way. There are onOutput listeners 
> but they're slow to operate and solr tests emit *tons* of output so it's an 
> overkill. The only solution I think would be feasible is to parse test report 
> XMLs after the tests are complete and collect the output of failed tests from 
> there. The downside is that XMLs contain separated sysout/syserr.
> Of lesser importance:
>  * add rendering of javadocs (gradlew javadoc) and attaching them to maven 
> publications.
>  * Add test 'beasting' (rerunning the same suite multiple times). I'm afraid 
> it'll be difficult to run it sensibly because gradle doesn't offer cwd 
> separation for the forked test runners.
>  * if you diff solr packaged distribution against ant-created distribution 
> there are minor differences in library versions and some JARs are excluded/ 
> moved around. I didn't try to force these as everything seems to work (tests, 
> etc.) – perhaps these differences should  be fixed in the ant build instead.
>  * identify and port any other "check" utilities that may be called from ant. 
> (Mark's branch has some of this stuff already implemented)
>  * [EOE] identify and port various "regenerate" tasks from ant builds 
> (javacc, precompiled automata, etc.)
>  * fill in POM details in gradle/defaults-maven.gradle so that they reflect 
> the previous content better (dependencies aside).
>  * Add any IDE integration layers that should be added (I use IntelliJ and it 
> imports the project out of the box, without the need for any special tuning).
>  * *Clean up dependencies, especially for Solr*: any \{ transitive = false } 
> should just explicitly exclude whatever they don't need (and their 
> dependencies currently declared explicitly should be folded). Figure out 
> which scope to import a dependency to.
>  * Add Solr packaging for docs/* (see TODO in packaging/build.gradle; 
> currently XSLT...)
>  * I didn't bother adding Solr dist/test-framework to packaging (who'd use it 
> from a binary distribution? 
>  
> *{color:#ff}Note:{color}* this builds on the work done by Mark Miller and 
> Cao Mạnh Đạt but also applies lessons learned from those two efforts:
>  * *Do not try to do too many things at once*. If we deviate too far from 
> master, the branch will be hard to merge.
>  * *Do everything in baby-steps* and add small, independent build fragments 
> replacing the old ant infrastructure.
>  * *Try to engage people to run, test and contribute early*. It can't be a 
> one-man effort. The mo

[jira] [Updated] (SOLR-14043) The allow the precision Stream Evaluator to operate on matrices

[Joel Bernstein (Jira)]

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

Joel Bernstein updated SOLR-14043:
--
Summary: The allow the precision Stream Evaluator to operate on matrices  
(was: The allow precision Math Expression to operate on matrices)

> The allow the precision Stream Evaluator to operate on matrices
> ---
>
> Key: SOLR-14043
> URL: https://issues.apache.org/jira/browse/SOLR-14043
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Priority: Minor
>
> The *precision* function currently operates on a number and on a vector. This 
> ticket will allow it operate on a matrix. When applied to a matrix each value 
> in the matrix will have its precision adjusted in place. This is to avoid 
> unnecessary copying of large matrices. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (SOLR-14043) Allow the precision Stream Evaluator to operate on matrices

[Joel Bernstein (Jira)]

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

Joel Bernstein updated SOLR-14043:
--
Summary: Allow the precision Stream Evaluator to operate on matrices  (was: 
The allow the precision Stream Evaluator to operate on matrices)

> Allow the precision Stream Evaluator to operate on matrices
> ---
>
> Key: SOLR-14043
> URL: https://issues.apache.org/jira/browse/SOLR-14043
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Priority: Minor
>
> The *precision* function currently operates on a number and on a vector. This 
> ticket will allow it operate on a matrix. When applied to a matrix each value 
> in the matrix will have its precision adjusted in place. This is to avoid 
> unnecessary copying of large matrices. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[GitHub] [lucene-solr] risdenk commented on issue #1068: SOLR-14033: Fix Hadoop tests with security manager

[GitBox]

risdenk commented on issue #1068: SOLR-14033: Fix Hadoop tests with security 
manager
URL: https://github.com/apache/lucene-solr/pull/1068#issuecomment-564109405
 
 
   @rmuir can you take another look over this? I think this is close to ready 
to merge. I plan to squash the commits and update the commit message. Figure 
its easier to review in smaller commits though.


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: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14043) Allow the precision Stream Evaluator to operate on matrices

[Joel Bernstein (Jira)]

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

Joel Bernstein commented on SOLR-14043:
---

A test for this is coming shortly.

> Allow the precision Stream Evaluator to operate on matrices
> ---
>
> Key: SOLR-14043
> URL: https://issues.apache.org/jira/browse/SOLR-14043
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Priority: Minor
> Attachments: SOLR-14043.patch
>
>
> The *precision* function currently operates on a number and on a vector. This 
> ticket will allow it operate on a matrix. When applied to a matrix each value 
> in the matrix will have its precision adjusted in place. This is to avoid 
> unnecessary copying of large matrices. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (SOLR-14043) Allow the precision Stream Evaluator to operate on matrices

[Joel Bernstein (Jira)]

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

Joel Bernstein updated SOLR-14043:
--
Attachment: SOLR-14043.patch

> Allow the precision Stream Evaluator to operate on matrices
> ---
>
> Key: SOLR-14043
> URL: https://issues.apache.org/jira/browse/SOLR-14043
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Priority: Minor
> Attachments: SOLR-14043.patch
>
>
> The *precision* function currently operates on a number and on a vector. This 
> ticket will allow it operate on a matrix. When applied to a matrix each value 
> in the matrix will have its precision adjusted in place. This is to avoid 
> unnecessary copying of large matrices. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Resolved] (SOLR-13563) SPLITSHARD - Using LINK method fails on disk usage checks

[Andrzej Bialecki (Jira)]

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

Andrzej Bialecki resolved SOLR-13563.
-
Resolution: Fixed

> SPLITSHARD - Using LINK method fails on disk usage checks
> -
>
> Key: SOLR-13563
> URL: https://issues.apache.org/jira/browse/SOLR-13563
> Project: Solr
>  Issue Type: Bug
>  Components: AutoScaling, SolrCloud
>Affects Versions: 7.7.2
>Reporter: Andrew Kettmann
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 8.4
>
> Attachments: disk_check.patch
>
>
> Raised this on the mailing list and was told to open an issue, copy/pasting 
> the context here:
>  
> Using Solr 7.7.2 Docker image, testing some of the new autoscale features, 
> huge fan so far. Tested with the link method on a 2GB core and found that it 
> took less than 1MB of additional space. Filled the core quite a bit larger, 
> 12GB of a 20GB PVC, and now splitting the shard fails with the following 
> error message on my overseer:
>  
>  
>  
> {code:java}
> 2019-06-18 16:27:41.754 ERROR 
> (OverseerThreadFactory-49-thread-5-processing-n:10.0.192.74:8983_solr) 
> [c:test_autoscale s:shard1  ] 
> o.a.s.c.a.c.OverseerCollectionMessageHandler Collection: test_autoscale 
> operation: splitshard
> failed:org.apache.solr.common.SolrException: not enough free disk space 
> to perform index split on node 10.0.193.23:8983_solr, required: 
> 23.35038321465254, available: 7.811378479003906
>     at 
> org.apache.solr.cloud.api.collections.SplitShardCmd.checkDiskSpace(SplitShardCmd.java:567)
>     at 
> org.apache.solr.cloud.api.collections.SplitShardCmd.split(SplitShardCmd.java:138)
>     at 
> org.apache.solr.cloud.api.collections.SplitShardCmd.call(SplitShardCmd.java:94)
>     at 
> org.apache.solr.cloud.api.collections.OverseerCollectionMessageHandler.processMessage(OverseerCollectionMessageHandler.java:294)
>     at 
> org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:505)
>     at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
>     at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>     at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>     at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
>  
>  
> I attempted sending the request to the node itself to see if it did anything 
> different, but no luck. My parameters are (Note Python formatting as that is 
> my language of choice):
>  
> {code:java}
> splitparams = {'action':'SPLITSHARD',
>'collection':'test_autoscale',
>'shard':'shard1',
>'splitMethod':'link',
>'timing':'true',
>'async':'shardsplitasync'}{code}
>  
>  
> And this is confirmed by the log message from the node itself:
>  
> {code:java}
> 2019-06-18 16:27:41.730 INFO  
> (qtp1107530534-16) [c:test_autoscale   ] o.a.s.s.HttpSolrCall [admin] 
> webapp=null path=/admin/collections 
> params={async=shardsplitasync&timing=true&action=SPLITSHARD&collection=test_autoscale&shard=shard1&splitMethod=link}
> status=0 QTime=20{code}
>  
>  
> While it is true I do not have enough space if I were using the rewrite 
> method, the link method on a 2GB core used an additional less than 1MB of 
> space. Is there something I am missing here? is there an option to disable 
> the disk space check that I need to pass? I can't find anything in the 
> documentation at this point.
>  
> --
>  
> After this initial email, I found the issue and compiled with the attached 
> patch and running the modification on the overseer only resolved the issue, 
> as the overseer is what runs the check.
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Assigned] (SOLR-14043) Allow the precision Stream Evaluator to operate on matrices

[Joel Bernstein (Jira)]

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

Joel Bernstein reassigned SOLR-14043:
-

Assignee: Joel Bernstein

> Allow the precision Stream Evaluator to operate on matrices
> ---
>
> Key: SOLR-14043
> URL: https://issues.apache.org/jira/browse/SOLR-14043
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Minor
> Attachments: SOLR-14043.patch
>
>
> The *precision* function currently operates on a number and on a vector. This 
> ticket will allow it operate on a matrix. When applied to a matrix each value 
> in the matrix will have its precision adjusted in place. This is to avoid 
> unnecessary copying of large matrices. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (SOLR-14043) Allow the precision Stream Evaluator to operate on matrices

[Joel Bernstein (Jira)]

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

Joel Bernstein updated SOLR-14043:
--
Attachment: SOLR-14043.patch

> Allow the precision Stream Evaluator to operate on matrices
> ---
>
> Key: SOLR-14043
> URL: https://issues.apache.org/jira/browse/SOLR-14043
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Minor
> Attachments: SOLR-14043.patch, SOLR-14043.patch
>
>
> The *precision* function currently operates on a number and on a vector. This 
> ticket will allow it operate on a matrix. When applied to a matrix each value 
> in the matrix will have its precision adjusted in place. This is to avoid 
> unnecessary copying of large matrices. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-14019) Inconsistent HTML escaping with highlighters

[Jira]

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

Nándor Mátravölgyi commented on SOLR-14019:
---

Alright, thanks for your input. I should have opened it under the Lucene 
project since the code to be modified is in that domain.

> Inconsistent HTML escaping with highlighters
> 
>
> Key: SOLR-14019
> URL: https://issues.apache.org/jira/browse/SOLR-14019
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: highlighter
>Reporter: Nándor Mátravölgyi
>Priority: Minor
>
> The unified highlighter does not use the 
> *org.apache.lucene.search.highlight.SimpleHTMLEncoder* through 
> *org.apache.solr.highlight.HtmlEncoder*. It has the HTML escaping feature 
> re-implemented and embedded in the  
> *org.apache.lucene.search.uhighlight.DefaultPassageFormatter*.
> The HTML escaping done by the unified highlighter escapes characters that do 
> not need it. This makes the result payload 50%+ more heavy with no benefit.
> Here is a highlight snippet using the original highlighter:
> {noformat}
> A filter that stems words using a Snowball-generated stemmer. 
> Available stemmers & x are listed in org.tartarus.snowball.ext. Note: 
> This filter is aware of the KeywordAttribute.
> {noformat}
> Here is the same highlight snippet using the unified highlighter:
> {noformat}
> A filter that stems words using a Snowball-generated stemmer. Available stemmers & x are listed in org.tartarus.snowball.ext. Note: This filter is aware of the KeywordAttribute.
> {noformat}
> Maybe I'm missing the point why this is done the way it is. If this behaviour 
> is desired for some use-case it should be a separate encoder, and the HTML 
> encoder should only escape the necessary characters.
> Affects all versions of Solr. Here are the lines where the escaping are 
> implemented differently:
> * [Escaping by the unified 
> highlighter|https://github.com/apache/lucene-solr/blob/2387bb9d60ae44eeeb4fbcb2f2877f46be5303a0/lucene/highlighter/src/java/org/apache/lucene/search/uhighlight/DefaultPassageFormatter.java#L132]
> * [Escaping by the other 
> highlighters|https://github.com/apache/lucene-solr/blob/2387bb9d60ae44eeeb4fbcb2f2877f46be5303a0/lucene/highlighter/src/java/org/apache/lucene/search/highlight/SimpleHTMLEncoder.java#L69]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Assigned] (SOLR-13985) bind to localhost by default

[Jason Gerlowski (Jira)]

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

Jason Gerlowski reassigned SOLR-13985:
--

Assignee: Jason Gerlowski

> bind to localhost by default
> 
>
> Key: SOLR-13985
> URL: https://issues.apache.org/jira/browse/SOLR-13985
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Robert Muir
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-13985.patch, SOLR-13985.patch
>
>
> Currently solr binds to all interfaces by default. 
> The default should be safer, so that e.g. the user is not exposed to the 
> internet until they make an explicit step to do so.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (SOLR-13985) bind to localhost by default

[Jason Gerlowski (Jira)]

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

Jason Gerlowski updated SOLR-13985:
---
Attachment: SOLR-13985.patch

> bind to localhost by default
> 
>
> Key: SOLR-13985
> URL: https://issues.apache.org/jira/browse/SOLR-13985
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Robert Muir
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-13985.patch, SOLR-13985.patch
>
>
> Currently solr binds to all interfaces by default. 
> The default should be safer, so that e.g. the user is not exposed to the 
> internet until they make an explicit step to do so.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[GitHub] [lucene-solr] nknize commented on issue #872: LUCENE-8620: LatLonShape contains

[GitBox]

nknize commented on issue #872: LUCENE-8620: LatLonShape contains
URL: https://github.com/apache/lucene-solr/pull/872#issuecomment-564152141
 
 
   Dug into this quite a bit and it LGTM. I think we can probably iterate on 
the API but the overall logic looks good.


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: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[GitHub] [lucene-solr] rmuir commented on issue #1068: SOLR-14033: Fix Hadoop tests with security manager

[GitBox]

rmuir commented on issue #1068: SOLR-14033: Fix Hadoop tests with security 
manager
URL: https://github.com/apache/lucene-solr/pull/1068#issuecomment-564152624
 
 
   I will test it on mac and linux this evening and look over what you have 
done. thanks 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: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-13985) bind to localhost by default

[Jira]

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

Jan Høydahl commented on SOLR-13985:


Should we name the SOLR_JETTY_HOST something else, such as SOLR_BIND_HOST or 
SOLR_BIND_IP? I like how Elasticsearch accepts special values {{_en0_}}, 
{{_local_}}, {{_site_}} and {{_global_}} as an alternative to knowing the IP 
address up front. You may only know the hostname, but such convenience settings 
could come later.

In your patch you still have 0.0.0.0 set in one of the solr.in files.

You have duplicated the same paragraphs in securing-solr.adoc and 
taking-solr-to-production.adoc.

> bind to localhost by default
> 
>
> Key: SOLR-13985
> URL: https://issues.apache.org/jira/browse/SOLR-13985
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Robert Muir
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-13985.patch, SOLR-13985.patch
>
>
> Currently solr binds to all interfaces by default. 
> The default should be safer, so that e.g. the user is not exposed to the 
> internet until they make an explicit step to do so.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (SOLR-13985) bind to localhost by default

[Jira]

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

Jan Høydahl edited comment on SOLR-13985 at 12/10/19 5:59 PM:
--

Should we name the SOLR_JETTY_HOST something else, such as SOLR_BIND_HOST or 
SOLR_BIND_IP? I like how Elasticsearch accepts special values {{\_en0_}}, 
{{\_local_}}, {{\_site_}} and {{\_global_}} as an alternative to knowing the IP 
address up front. You may only know the hostname, but such convenience settings 
could come later.

In your patch you still have 0.0.0.0 set in one of the solr.in files.

You have duplicated the same paragraphs in securing-solr.adoc and 
taking-solr-to-production.adoc.


was (Author: janhoy):
Should we name the SOLR_JETTY_HOST something else, such as SOLR_BIND_HOST or 
SOLR_BIND_IP? I like how Elasticsearch accepts special values {{_en0_}}, 
{{_local_}}, {{_site_}} and {{_global_}} as an alternative to knowing the IP 
address up front. You may only know the hostname, but such convenience settings 
could come later.

In your patch you still have 0.0.0.0 set in one of the solr.in files.

You have duplicated the same paragraphs in securing-solr.adoc and 
taking-solr-to-production.adoc.

> bind to localhost by default
> 
>
> Key: SOLR-13985
> URL: https://issues.apache.org/jira/browse/SOLR-13985
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Robert Muir
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-13985.patch, SOLR-13985.patch
>
>
> Currently solr binds to all interfaces by default. 
> The default should be safer, so that e.g. the user is not exposed to the 
> internet until they make an explicit step to do so.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-13985) bind to localhost by default

[Jason Gerlowski (Jira)]

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

Jason Gerlowski commented on SOLR-13985:


I'm assigning this to myself so I can move this forward a bit.  If I'm 
"stealing" this from you [~rcmuir], let me know and it's all yours :P

The latest patch has {{bin/solr}}, {{bin/solr.cmd}} logic to read a 
SOLR_JETTY_HOST value if set in {{solr.in.sh}}/{{solr.in.cmd}}.

It also takes a first pass at docs for this.  I've added larger blurbs about 
this on the "Taking Solr to Production" and "Securing Solr" pages.  I added a 
smaller warning-style note on the "Getting Started with SolrCloud" page that 
talks about the need to loosen this setting to allow Solr nodes to talk to each 
other.  Presumably there's a lot of other places in the docs that might benefit 
from a similar note.  I'm not sure how much is overdoing it though.  

This seems like a change that will impact a lot of deployments so maybe we 
should target 9.0 for this.  You could argue that the security benefits are 
important enough to trump our breaking-change policy - I don't think I really 
buy that yet, but I'm open to the argument if someone wants to make it.

I have _not_ tested the Windows changes yet.  Hoping to set up a VM to do so 
soon, but if anyone else has a Windows environment handy, I'd appreciate a 
double check there.

Anyone have thoughts?

> bind to localhost by default
> 
>
> Key: SOLR-13985
> URL: https://issues.apache.org/jira/browse/SOLR-13985
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Robert Muir
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-13985.patch, SOLR-13985.patch
>
>
> Currently solr binds to all interfaces by default. 
> The default should be safer, so that e.g. the user is not exposed to the 
> internet until they make an explicit step to do so.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-13985) bind to localhost by default

[Robert Muir (Jira)]

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

Robert Muir commented on SOLR-13985:


{quote}
If I'm "stealing" this from you Robert Muir, let me know and it's all yours
{quote}

Please, steal. You clearly have a better idea of how to get it going!

> bind to localhost by default
> 
>
> Key: SOLR-13985
> URL: https://issues.apache.org/jira/browse/SOLR-13985
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Robert Muir
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-13985.patch, SOLR-13985.patch
>
>
> Currently solr binds to all interfaces by default. 
> The default should be safer, so that e.g. the user is not exposed to the 
> internet until they make an explicit step to do so.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[GitHub] [lucene-solr] msokolov commented on issue #892: LUCENE-8972: Add ICUTransformCharFilter, to support pre-tokenizer ICU text transformation

[GitBox]

msokolov commented on issue #892: LUCENE-8972: Add ICUTransformCharFilter, to 
support pre-tokenizer ICU text transformation
URL: https://github.com/apache/lucene-solr/pull/892#issuecomment-564156997
 
 
   OK, so you are good with the change I posted? If you don't see any issues,
   I will go ahead and commit after beasting again to make sure there are no
   more test failures due to randomization -- I think I was able to root them
   out.
   
   Regarding further automatic performance optimization, I think that is very
   ambitious and maybe too much magic. But let's see if it is needed in
   practice; if  a common "manual" pattern develops we can encode it as a
   convenience later.
   
   -Mike
   
   On Mon, Dec 9, 2019 at 7:30 AM Michael Gibney 
   wrote:
   
   > Ah, I see. The refactoring looks good.
   >
   > Separately (and wrt the test-failures induced by randomization): the
   > withoutUnicodeNormalization randomization provides a good opportunity to
   > make some documentation more explicit (and/or build more nuance/complexity
   > into the handling of the assumeExternalUnicodeNormalization flag.
   >
   > The assumeExternalUnicodeNormalization arg cannot simply be flipped in
   > isolation without affecting behavior. My conception of this arg is as an
   > "expert" option that can significantly improve performance, but requires
   > users to know (and externally compensate for, with specific
   > ICUNormalizer2CharFilters in the top-level analysis chain) the specific
   > type of input and output unicode normalization applied by a *particular*
   > transliterator.
   >
   > It's true that this makes it possible for users to "shoot themselves in
   > the foot". One alternative would be to parse unicode normalization out of
   > the Transliterator and effectively "rewrite" the analysis chain, pulling
   > internal unicode normalization out to the top level as offset-aware
   > ICUNormalizer2CharFilters. Pulling at this thread though leads to other
   > potential considerations, such as:
   >
   >1. I looked, and couldn't find any precedent for this type of
   >under-the-hood analysis-chain rewriting.
   >2. Should we prune redundant unicode normalization induced by such
   >rewriting? Particularly if the redundancy is introduced by rewriting
   >adjacent Transliterators?
   >3. The more we attempt to handle for the user, the more we encourage
   >users to think that this is a one-size-fits-all drop-in replacement. I
   >actually *do* think it would be possible to design in this way, but
   >I'm not sure I'd be prepared to guarantee it and my sense is that really
   >doing it "right" -- flattening, respecting nested filters, propagating
   >offsets -- could become quite complex.
   >
   > Might we consider proceeding in two phases? One with
   > assumeExternalUnicodeNormalization conceived as an expert option that
   > doesn't attempt anything more than disabling transliterator i/o
   > normailzation, and a potential future step that would attempt rewriting
   > composite (potentially hierarchical) Transliterators as top-level
   > CharFilters (with all the complexity that might entail)? For the first
   > phase, that could mean leaving tests as they were before the patch
   > introducing the randomized disabling of normalization, and adding
   > additional tests that explicitly disable normalization and compensate with
   > top-level normalization as appropriate for the associated transliterator.
   >
   > —
   > You are receiving this because you were mentioned.
   > Reply to this email directly, view it on GitHub
   > 
,
   > or unsubscribe
   > 

   > .
   >
   


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: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8620) Add CONTAINS support for LatLonShape

[Lucene/Solr QA (Jira)]

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

Lucene/Solr QA commented on LUCENE-8620:


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


This message was automatically generated.



> Add CONTAINS support for LatLonShape
> 
>
> Key: LUCENE-8620
> URL: https://issues.apache.org/jira/browse/LUCENE-8620
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/sandbox
>Reporter: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8620.patch, LUCENE-8620.patch
>
>  Time Spent: 7h 20m
>  Remaining Estimate: 0h
>
> Currently the only spatial operation that cannot be performed using 
> {{LatLonShape}} is CONTAINS. This issue will add such capability by tracking 
> if an edge of a generated triangle from the {{Tessellator}} is an edge of the 
> polygon.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-14043) Allow the precision Stream Evaluator to operate on matrices

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-14043:


Commit 8c6a2640ed3cffacb7f4cb5a7aa71ec06f5d44f2 in lucene-solr's branch 
refs/heads/master from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8c6a264 ]

SOLR-14043: Allow the precision Stream Evaluator to operate on matrices


> Allow the precision Stream Evaluator to operate on matrices
> ---
>
> Key: SOLR-14043
> URL: https://issues.apache.org/jira/browse/SOLR-14043
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Minor
> Attachments: SOLR-14043.patch, SOLR-14043.patch
>
>
> The *precision* function currently operates on a number and on a vector. This 
> ticket will allow it operate on a matrix. When applied to a matrix each value 
> in the matrix will have its precision adjusted in place. This is to avoid 
> unnecessary copying of large matrices. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-13985) bind to localhost by default

[Jason Gerlowski (Jira)]

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

Jason Gerlowski commented on SOLR-13985:


Hey, review comments before I could post my description of the patch.  Thanks 
for the quick feedback Jan.

bq. you still have 0.0.0.0 set in one of the solr.in files.
Leftover from testing.  Fixed

bq. You have duplicated the same paragraphs in securing-solr.adoc and 
taking-solr-to-production.adoc.
That was intentional, but I'm not happy about it and would love any suggestions 
you had.  The information in those 2-3 paragraphs seemed relevant in both 
places.  Initially I put a link from taking-solr-to-production.adoc to the 
material in securing-solr.adoc, but it ended up that I was taking a sentence or 
two to provide a link to a sentence or two.  Seemed a little weird, so I just 
duplicated the paragraphs.  I'm happy to go back to linking to it though if you 
prefer.

 bq. Should we name the SOLR_JETTY_HOST something else, such as SOLR_BIND_HOST 
or SOLR_BIND_IP?
I chose SOLR_JETTY_HOST because it mirrored the values already in our 
jetty.xml's.  But I don't have any particular attachment to the name if there's 
consensus on one of the others.  I'm not familiar with those Elastic settings, 
but I'll take a look and get back to you.

> bind to localhost by default
> 
>
> Key: SOLR-13985
> URL: https://issues.apache.org/jira/browse/SOLR-13985
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Robert Muir
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-13985.patch, SOLR-13985.patch
>
>
> Currently solr binds to all interfaces by default. 
> The default should be safer, so that e.g. the user is not exposed to the 
> internet until they make an explicit step to do so.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (SOLR-13985) bind to localhost by default

[Jason Gerlowski (Jira)]

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

Jason Gerlowski updated SOLR-13985:
---
Attachment: SOLR-13985.patch

> bind to localhost by default
> 
>
> Key: SOLR-13985
> URL: https://issues.apache.org/jira/browse/SOLR-13985
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Robert Muir
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-13985.patch, SOLR-13985.patch, SOLR-13985.patch
>
>
> Currently solr binds to all interfaces by default. 
> The default should be safer, so that e.g. the user is not exposed to the 
> internet until they make an explicit step to do so.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-14020) move hadoop hacks out of lucene TestSecurityManager into a solr one

[Chris M. Hostetter (Jira)]

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

Chris M. Hostetter commented on SOLR-14020:
---

Do we know why there are still a lot of tests using MiniDFSCluster that fail on 
jenkins (and reproduce locally for me on linux) with Security Exceptions 
related to {{org.apache.hadoop.util.Shell}}  ... even though 
SolrSecurityManager seems to be explicitly allowing all of these code paths?

The stacktraces for these AccessControlExceptions don't even seem to indicate 
that SolrSecurityManager is involved in the call stack?

 
{code:java}
  /**
   * {@inheritDoc}
   * This method implements hacks to workaround hadoop's garbage Shell and 
FileUtil code
   */
  @Override
  public void checkExec(String cmd) {
// NOTE: it would be tempting to just allow anything from hadoop's Shell 
class, but then
// that would just give an easy vector for RCE (use hadoop Shell instead of 
e.g. ProcessBuilder)
// so we whitelist actual caller impl methods instead.
for (StackTraceElement element : Thread.currentThread().getStackTrace()) {
  // hadoop insists on shelling out to get the user's supplementary groups?
  if 
("org.apache.hadoop.security.ShellBasedUnixGroupsMapping".equals(element.getClassName())
 &&
  "getGroups".equals(element.getMethodName())) {
return;
  }
  // hadoop insists on shelling out to parse 'df' command instead of using 
FileStore?
  if ("org.apache.hadoop.fs.DF".equals(element.getClassName()) &&
  "getFilesystem".equals(element.getMethodName())) {
return;
  }
...
{code}
[http://fucit.org/solr-jenkins-reports/job-data/apache/Lucene-Solr-Tests-master/3939]
{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestSolrCloudWithSecureImpersonation -Dtests.seed=3B693D41330FAB89 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=os-GE 
-Dtests.timezone=America/Antigua -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII
   [junit4] ERROR   0.00s J0 | TestSolrCloudWithSecureImpersonation (suite) <<<
   [junit4]> Throwable #1: 
com.google.common.util.concurrent.UncheckedExecutionException: 
java.security.AccessControlException: access denied ("java.io.FilePermission" 
"<>" "execute")
...
   [junit4]> Caused by: java.security.AccessControlException: access denied 
("java.io.FilePermission" "<>" "execute")
   [junit4]>at 
java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
   [junit4]>at 
java.base/java.security.AccessController.checkPermission(AccessController.java:897)
   [junit4]>at 
java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:322)
   [junit4]>at 
java.base/java.lang.SecurityManager.checkExec(SecurityManager.java:572)
   [junit4]>at 
java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1096)
   [junit4]>at 
java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1071)
   [junit4]>at 
org.apache.hadoop.util.Shell.runCommand(Shell.java:938)
   [junit4]>at org.apache.hadoop.util.Shell.run(Shell.java:901)
   [junit4]>at 
org.apache.hadoop.util.Shell$ShellCommandExecutor.execute(Shell.java:1213)
   [junit4]>at 
org.apache.hadoop.security.ShellBasedUnixGroupsMapping.getUnixGroups(ShellBasedUnixGroupsMapping.java:200)

...

   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=CheckHdfsIndexTest 
-Dtests.seed=3B693D41330FAB89 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=en-SI -Dtests.timezone=America/Panama -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII
   [junit4] ERROR   0.00s J1 | CheckHdfsIndexTest (suite) <<<
   [junit4]> Throwable #1: java.security.AccessControlException: access 
denied ("java.io.FilePermission" "<>" "execute")
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([3B693D41330FAB89]:0)
   [junit4]>at 
java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
   [junit4]>at 
java.base/java.security.AccessController.checkPermission(AccessController.java:897)
   [junit4]>at 
java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:322)
   [junit4]>at 
java.base/java.lang.SecurityManager.checkExec(SecurityManager.java:572)
   [junit4]>at 
java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1096)
   [junit4]>at 
java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1071)
   [junit4]>at 
org.apache.hadoop.util.Shell.runCommand(Shell.java:938)
   [junit4]>at org.apache.hadoop.util.Shell.run(Shell.java:901)
   [junit4]>at org.apache.hadoop.fs.DF.getFilesystem(DF.java:74)

...

{noformat}
[http://fucit.org/solr-jenkins-reports/job-data/th

[jira] [Commented] (SOLR-13970) Collapse/Expand and Grouping are not designed to work together, we should fail requests that specify both gracefully

[Joel Bernstein (Jira)]

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

Joel Bernstein commented on SOLR-13970:
---

Let's definitely get something committed that stops people from combining 
collapse and grouping. 

I think if possible we should throw the exception from inside the 
CollapsingQParserPlugin.  I believe we should be able to do this.

I'll work on a patch for this today.

> Collapse/Expand and Grouping are not designed to work together, we should 
> fail requests that specify both gracefully
> 
>
> Key: SOLR-13970
> URL: https://issues.apache.org/jira/browse/SOLR-13970
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-13970.patch
>
>
> Expand/Collapse was conceived as orthogonal to grouping, and there are odd 
> interactions when both are specified. If these two options are specified, we 
> should reject the query with an informative message.
> Shorter term, making this explicit in the documents would be helpful.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-14020) move hadoop hacks out of lucene TestSecurityManager into a solr one

[Kevin Risden (Jira)]

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

Kevin Risden commented on SOLR-14020:
-

[~hossman] - SOLR-14033 has fix for that.

> move hadoop hacks out of lucene TestSecurityManager into a solr one
> ---
>
> Key: SOLR-14020
> URL: https://issues.apache.org/jira/browse/SOLR-14020
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Robert Muir
>Priority: Major
> Attachments: SOLR-14020.patch
>
>
> The hadoop hacks here have a heavy toll: because we have to override some 
> methods like checkRead, it inserts non-jdk stack frame and breaks a lot of 
> JDK doPriv calls. So for example, it means permissions must be added to stuff 
> like /dev/random or windows fonts or all kinds of other nonsense.
> This is a price only solr should pay, not lucene. Lets split the stuff out.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-14043) Allow the precision Stream Evaluator to operate on matrices

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-14043:


Commit 10cfb08a38117e708e7c114a9b732978311fa4ae in lucene-solr's branch 
refs/heads/branch_8x from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=10cfb08 ]

SOLR-14043: Allow the precision Stream Evaluator to operate on matrices


> Allow the precision Stream Evaluator to operate on matrices
> ---
>
> Key: SOLR-14043
> URL: https://issues.apache.org/jira/browse/SOLR-14043
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Minor
> Attachments: SOLR-14043.patch, SOLR-14043.patch
>
>
> The *precision* function currently operates on a number and on a vector. This 
> ticket will allow it operate on a matrix. When applied to a matrix each value 
> in the matrix will have its precision adjusted in place. This is to avoid 
> unnecessary copying of large matrices. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Created] (SOLR-14044) Support shard/collection deletion in shared storage

[Andy Vuong (Jira)]

Andy Vuong created SOLR-14044:
-

 Summary: Support shard/collection deletion in shared storage
 Key: SOLR-14044
 URL: https://issues.apache.org/jira/browse/SOLR-14044
 Project: Solr
  Issue Type: Sub-task
  Components: SolrCloud
Reporter: Andy Vuong


The Solr Cloud deletion APIs for collections and shards are not currently 
supported by shared storage but are an essential functionality required by the 
shared storage design. Deletion of objects from shared storage currently only 
happens in the indexing path (on pushes) and after the index file listings 
between the local solr process and external store have been resolved.

 

This task is to track supporting the delete shard/collection API commands and 
its scope does not include cleaning up so called “orphaned” index files from 
blob (i.e. files that are no longer referenced by any core.metadata file on the 
external store). This will be designed/covered in another subtask.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (LUCENE-9082) Upgrade Apache Ivy version to 2.5.0

[Namgyu Kim (Jira)]

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

Namgyu Kim commented on LUCENE-9082:


Thank you for your reply and sorry for late, [~sarowe] :)

Since the new Ivy version came out after a long time(2.4.0 was released at Dec 
26, 2014), I thought it would not be bad to update because of bug patches and 
so on.
In fact, I didn't see all Ivy patches, but I approached them for that reason.

But I agree with you that this work is not necessary if we can move completely 
to the Gradle build soon.

> Upgrade Apache Ivy version to 2.5.0
> ---
>
> Key: LUCENE-9082
> URL: https://issues.apache.org/jira/browse/LUCENE-9082
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Namgyu Kim
>Assignee: Namgyu Kim
>Priority: Major
> Fix For: 8.x, master (9.0)
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Not long ago, Apache Ivy 2.5.0 was released. (Oct 24, 2019)
> Apache Ivy 2.5.0 can be worked with Java 7 or later.
> ([https://ant.apache.org/ivy/history/2.5.0/compatibility.html])
> So there is no problem with our current Lucene version(8.x and 9.0).
> This patch will be merged to +master+ and +branch_8x+ and +gradle-master+ 
> branch.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (SOLR-13970) Collapse/Expand and Grouping are not designed to work together, we should fail requests that specify both gracefully

[Joel Bernstein (Jira)]

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

Joel Bernstein updated SOLR-13970:
--
Attachment: SOLR-13970.patch

> Collapse/Expand and Grouping are not designed to work together, we should 
> fail requests that specify both gracefully
> 
>
> Key: SOLR-13970
> URL: https://issues.apache.org/jira/browse/SOLR-13970
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-13970.patch, SOLR-13970.patch
>
>
> Expand/Collapse was conceived as orthogonal to grouping, and there are odd 
> interactions when both are specified. If these two options are specified, we 
> should reject the query with an informative message.
> Shorter term, making this explicit in the documents would be helpful.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-13970) Collapse/Expand and Grouping are not designed to work together, we should fail requests that specify both gracefully

[Joel Bernstein (Jira)]

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

Joel Bernstein commented on SOLR-13970:
---

I attached a patch which I think gets the job done. I'll take the test from 
prior patch and test it out.

 

> Collapse/Expand and Grouping are not designed to work together, we should 
> fail requests that specify both gracefully
> 
>
> Key: SOLR-13970
> URL: https://issues.apache.org/jira/browse/SOLR-13970
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-13970.patch, SOLR-13970.patch
>
>
> Expand/Collapse was conceived as orthogonal to grouping, and there are odd 
> interactions when both are specified. If these two options are specified, we 
> should reject the query with an informative message.
> Shorter term, making this explicit in the documents would be helpful.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (LUCENE-9084) circular synchronization wait (potential deadlock) in AnalyzingInfixSuggester

[Paul Ward (Jira)]

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

Paul Ward commented on LUCENE-9084:
---

Hi Mikhail,

Thanks for spending time with the step-through debugging on this.

It sounds like (in that test or in general?) the caller or a callee of 
{{build()}} keeps state and throws that exception (because 
{{AnalyzingInfixSuggester}} class itself does not).

I think the caller/callee keeps state because the circular wait is done with 
{{synchronized}}, which by itself does not have support for deadlock detection.

This is good news.

However, it seems dangerous to circularly acquire synchronization and rely on 
all callers/callees to check state.

Because {{build()}}, {{add()}}, {{update()}} are public methods and this is a 
potential circular wait situation, I would err on the safe side here, 
especially as the fix is simple.

Your call.


> circular synchronization wait (potential deadlock) in AnalyzingInfixSuggester
> -
>
> Key: LUCENE-9084
> URL: https://issues.apache.org/jira/browse/LUCENE-9084
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Reporter: Paul Ward
>Priority: Major
> Attachments: LUCENE-9084.patch
>
>
> h1. Github Pull Request  
> I created a pull request on github for this:
> [https://github.com/apache/lucene-solr/pull/1064]
> h1. Bug Description
> Detailed code (snippets and links) are in the sections after this overview 
> (section **Detailed Code** and **This Patch's Code**).
> Method {{ensureOpen()}} is {{synchronized}} (acquires {{this}}) and its body 
> contains a {{synchronized (searcherMgrLock)}} block (i.e., then acquires 
> {{searcherMgrLock}}).
> Method {{ensureOpen()}} is called two times from public methods {{add()}} and 
> {{update()}}.
> A thread calling public methods {{add()}} or {{update()}} will acquire locks 
> in order:
> {code:java}
> this -> searcherMgrLock
> {code}
> Public method {{build()}} has a {{synchronized (searcherMgrLock)}} block in 
> which it calls method {{add()}}. Method {{add()}}, as described above, calls 
> method {{ensureOpen()}}.
> Therefore, a thread calling public method {{build()}} will acquire locks in 
> order:
> {code:java}
> searcherMgrLock -> this -> searcherMgrLock
> {code}
> 2 threads can acquire locks in different order which may cause a circular 
> wait (deadlock).
> I do not know which threads call these methods, but there is a lot of 
> synchronization in these methods and in this file, so I think these methods 
> must be called concurrently.
> One thread can acquire:
> {{this -> searcherMgrLock}} (the first order above)
> and the other thread can acquire:
> {{searcherMgrLock -> this}} (the second order above).
> Note how the above 2 orders lead to a circular wait.
> h1. Detailed Code
> Method {{ensureOpen()}} is {{synchronized}} and its body contains a 
> {{synchronized (searcherMgrLock)}}:
> {code:java}
>   private synchronized void ensureOpen() throws IOException { <<< see 
> the synchronized keyword
> if (writer == null) {
>   if (DirectoryReader.indexExists(dir)) {
> // Already built; open it:
> writer = new IndexWriter(dir, getIndexWriterConfig(getGramAnalyzer(), 
> IndexWriterConfig.OpenMode.APPEND));
>   } else {
> writer = new IndexWriter(dir, getIndexWriterConfig(getGramAnalyzer(), 
> IndexWriterConfig.OpenMode.CREATE));
>   }
>   synchronized (searcherMgrLock) { <<<
> {code}
> [https://github.com/apache/lucene-solr/blob/master/lucene/suggest/src/java/org/apache/lucene/search/suggest/analyzing/AnalyzingInfixSuggester.java#L371-L379]
> Method {{ensureOpen()}} is called two times from public methods {{add()}} and 
> {{update()}}:
> {code:java}
>   public void add(BytesRef text, Set contexts, long weight, 
> BytesRef payload) throws IOException {
> ensureOpen(); <<
> {code}
> [https://github.com/apache/lucene-solr/blob/master/lucene/suggest/src/java/org/apache/lucene/search/suggest/analyzing/AnalyzingInfixSuggester.java#L394-L395]
> {code:java}
>   public void update(BytesRef text, Set contexts, long weight, 
> BytesRef payload) throws IOException {
> ensureOpen(); 
> {code}
> [https://github.com/apache/lucene-solr/blob/master/lucene/suggest/src/java/org/apache/lucene/search/suggest/analyzing/AnalyzingInfixSuggester.java#L406-L407]
> Public method {{build()}} has a {{synchronized (searcherMgrLock)}} block in 
> which it calls method {{add()}}:
> {code:java}
>   @Override
>   public void build(InputIterator iter) throws IOException {
> 
> synchronized (searcherMgrLock) { 
>   if (searcherMgr != null) {
> searcherMg

[jira] [Updated] (SOLR-13806) SolrJ QueryResponse._explainMap is incorrectly typed

[Andrzej Bialecki (Jira)]

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

Andrzej Bialecki updated SOLR-13806:

Fix Version/s: 8.4

> SolrJ QueryResponse._explainMap is incorrectly typed
> 
>
> Key: SOLR-13806
> URL: https://issues.apache.org/jira/browse/SOLR-13806
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.3
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
>  Labels: newdev
> Fix For: 8.4
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> This field, and the corresponding getter, and the code that extracts debug 
> information from the NamedList response in {{extractDebugInfo}}, all use a 
> {{Map}} type.
> However, when {{debug.explain.structured=true}} is used the values returned 
> in response are not String-s, instead they are {{SimpleOrderedMap}}-s. This 
> causes the following exception to be thrown:
> {code}
> java.lang.ClassCastException: class 
> org.apache.solr.common.util.SimpleOrderedMap cannot be cast to class 
> java.lang.String (org.apache.solr.common.util.SimpleOrderedMap is in unnamed 
> module of loader 'app'; java.lang.String is in module java.base of loader 
> 'bootstrap')
>   at 
> __randomizedtesting.SeedInfo.seed([1D6FB4036A639051:173F5FF19E860E6F]:0)
>   at 
> org.apache.solr.client.solrj.response.QueryResponse.extractDebugInfo(QueryResponse.java:246)
>   at 
> org.apache.solr.client.solrj.response.QueryResponse.setResponse(QueryResponse.java:143)
>   at 
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207)
>   at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:987)
> ...
> {code}
> The simple fix is to change the type of this field to {{Map}} 
> but this would change the public API of {{QueryResponse.getExplainMap()}} in 
> incompatible way. Still, I would argue it's worth to change it - AFAIK this 
> getter is not used anywhere in the Solr's codebase, and the change makes it 
> more consistent with other getters.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[GitHub] [lucene-solr] gerlowskija commented on issue #1068: SOLR-14033: Fix Hadoop tests with security manager

[GitBox]

gerlowskija commented on issue #1068: SOLR-14033: Fix Hadoop tests with 
security manager
URL: https://github.com/apache/lucene-solr/pull/1068#issuecomment-564179891
 
 
   The duplication of the Hadoop Java files here seems ugly, though I'm sure 
you're only doing it because there's no other recourse : (
   
   Is it worth putting some sort of header or class-level comment on all these 
copied-over files to indicate that they were copied verbatim from whatever 
particular hadoop package?  Or alternatively maybe we should have a comment in 
ant/ivy where we declare our Hadoop dependency that all these files should be 
updated whenever we change our hadoop version?
   
   I'm running tests now and will post later when they're done as well.


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: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Assigned] (SOLR-13806) SolrJ QueryResponse._explainMap is incorrectly typed

[Andrzej Bialecki (Jira)]

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

Andrzej Bialecki reassigned SOLR-13806:
---

Assignee: Andrzej Bialecki

> SolrJ QueryResponse._explainMap is incorrectly typed
> 
>
> Key: SOLR-13806
> URL: https://issues.apache.org/jira/browse/SOLR-13806
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.3
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
>  Labels: newdev
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> This field, and the corresponding getter, and the code that extracts debug 
> information from the NamedList response in {{extractDebugInfo}}, all use a 
> {{Map}} type.
> However, when {{debug.explain.structured=true}} is used the values returned 
> in response are not String-s, instead they are {{SimpleOrderedMap}}-s. This 
> causes the following exception to be thrown:
> {code}
> java.lang.ClassCastException: class 
> org.apache.solr.common.util.SimpleOrderedMap cannot be cast to class 
> java.lang.String (org.apache.solr.common.util.SimpleOrderedMap is in unnamed 
> module of loader 'app'; java.lang.String is in module java.base of loader 
> 'bootstrap')
>   at 
> __randomizedtesting.SeedInfo.seed([1D6FB4036A639051:173F5FF19E860E6F]:0)
>   at 
> org.apache.solr.client.solrj.response.QueryResponse.extractDebugInfo(QueryResponse.java:246)
>   at 
> org.apache.solr.client.solrj.response.QueryResponse.setResponse(QueryResponse.java:143)
>   at 
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207)
>   at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:987)
> ...
> {code}
> The simple fix is to change the type of this field to {{Map}} 
> but this would change the public API of {{QueryResponse.getExplainMap()}} in 
> incompatible way. Still, I would argue it's worth to change it - AFAIK this 
> getter is not used anywhere in the Solr's codebase, and the change makes it 
> more consistent with other getters.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (SOLR-5230) Call DelegatingCollector.finish() during grouping

[Joel Bernstein (Jira)]

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

Joel Bernstein updated SOLR-5230:
-
Attachment: SOLR-13970.patch

> Call DelegatingCollector.finish() during grouping
> -
>
> Key: SOLR-5230
> URL: https://issues.apache.org/jira/browse/SOLR-5230
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Affects Versions: 4.4
>Reporter: Joel Bernstein
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: 4.7, 6.0
>
> Attachments: SOLR-5230.patch, SOLR-5230.patch
>
>
> This is an add-on to SOLR-5020 to call the new DelegatingCollector.finish() 
> method from inside the grouping flow. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (SOLR-5230) Call DelegatingCollector.finish() during grouping

[Joel Bernstein (Jira)]

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

Joel Bernstein updated SOLR-5230:
-
Attachment: (was: SOLR-13970.patch)

> Call DelegatingCollector.finish() during grouping
> -
>
> Key: SOLR-5230
> URL: https://issues.apache.org/jira/browse/SOLR-5230
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Affects Versions: 4.4
>Reporter: Joel Bernstein
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: 4.7, 6.0
>
> Attachments: SOLR-5230.patch, SOLR-5230.patch
>
>
> This is an add-on to SOLR-5020 to call the new DelegatingCollector.finish() 
> method from inside the grouping flow. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (SOLR-13970) Collapse/Expand and Grouping are not designed to work together, we should fail requests that specify both gracefully

[Joel Bernstein (Jira)]

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

Joel Bernstein updated SOLR-13970:
--
Attachment: SOLR-13970.patch

> Collapse/Expand and Grouping are not designed to work together, we should 
> fail requests that specify both gracefully
> 
>
> Key: SOLR-13970
> URL: https://issues.apache.org/jira/browse/SOLR-13970
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-13970.patch, SOLR-13970.patch, SOLR-13970.patch
>
>
> Expand/Collapse was conceived as orthogonal to grouping, and there are odd 
> interactions when both are specified. If these two options are specified, we 
> should reject the query with an informative message.
> Shorter term, making this explicit in the documents would be helpful.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-6736) A collections-like request handler to manage solr configurations on zookeeper

[David Smiley (Jira)]

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

David Smiley commented on SOLR-6736:


[~ichattopadhyaya] can you please comment as to why the approach here stores 
this {{trusted}} setting in a new "configSet _flags_" place instead of using 
the existing "configSet _properties_"? In ZK the distinction is the ZK node for 
the config itself (ZK dirs can themselves be a file) vs "configsetprops.json". 
*I think it's a complexity burden to have both.* Perhaps there might be a 
security concern to configsetprops.json but I would rather approach this by 
consolidating them at the node and make it impossible to upload a configset 
with this file. It's internal-only any way. BTW it appears the only use of 
configsetprops.json is for {{immutable}}.

> A collections-like request handler to manage solr configurations on zookeeper
> -
>
> Key: SOLR-6736
> URL: https://issues.apache.org/jira/browse/SOLR-6736
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Reporter: Varun Rajput
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 6.6, 7.0
>
> Attachments: SOLR-6736-newapi.patch, SOLR-6736-newapi.patch, 
> SOLR-6736-newapi.patch, SOLR-6736.doc.patch, SOLR-6736.patch, 
> SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch, 
> SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch, 
> SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch, newzkconf.zip, 
> newzkconf.zip, test_private.pem, test_pub.der, zkconfighandler.zip, 
> zkconfighandler.zip
>
>
> Managing Solr configuration files on zookeeper becomes cumbersome while using 
> solr in cloud mode, especially while trying out changes in the 
> configurations. 
> It will be great if there is a request handler that can provide an API to 
> manage the configurations similar to the collections handler that would allow 
> actions like uploading new configurations, linking them to a collection, 
> deleting configurations, etc.
> example : 
> {code}
> #use the following command to upload a new configset called mynewconf. This 
> will fail if there is alredy a conf called 'mynewconf'. The file could be a 
> jar , zip or a tar file which contains all the files for the this conf.
> curl -X POST -H 'Content-Type: application/octet-stream' --data-binary 
> @testconf.zip 
> http://localhost:8983/solr/admin/configs/mynewconf?sig=
> {code}
> A GET to http://localhost:8983/solr/admin/configs will give a list of configs 
> available
> A GET to http://localhost:8983/solr/admin/configs/mynewconf would give the 
> list of files in mynewconf



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (SOLR-13970) Collapse/Expand and Grouping are not designed to work together, we should fail requests that specify both gracefully

[Joel Bernstein (Jira)]

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

Joel Bernstein edited comment on SOLR-13970 at 12/10/19 7:31 PM:
-

Added a test, and removed a test that was specifically exercising collapse and 
grouping.

That test was way back in Solr 4.7 as part this ticket: 
https://issues.apache.org/jira/browse/SOLR-5230.

Back then it was probably fine to have collapse and grouping together because 
the caches they rely on had a random access API. When the DocValues went to the 
iterator API collapse and grouping no longer worked anymore because grouping 
calls the same postfilter twice without resetting the internal state of the 
DocValues cache, which breaks things.

In a separate ticket we should inventory which postfilters use the DocValues 
caches during collect() and make sure they all throw exceptions when used with 
grouping.


was (Author: joel.bernstein):
Added a test, and removed a test that was specifically exercising collapse and 
grouping.

That test was way back in Solr 4.7 as part this ticket: 
https://issues.apache.org/jira/browse/SOLR-5230.

Back then it was probably fine to have collapse and grouping together because 
the caches they rely on had a random access API. When the DocValues went to the 
iterator API collapse and grouping no longer worked anymore because grouping 
calls the same postfilter twice without resetting the internal state of the 
DocValues cache, which breaks things.

In a separate ticket we should inventory which postfilters use the DocValues 
caches during collect() and make sure they are through exceptions when used 
with grouping.

> Collapse/Expand and Grouping are not designed to work together, we should 
> fail requests that specify both gracefully
> 
>
> Key: SOLR-13970
> URL: https://issues.apache.org/jira/browse/SOLR-13970
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-13970.patch, SOLR-13970.patch, SOLR-13970.patch
>
>
> Expand/Collapse was conceived as orthogonal to grouping, and there are odd 
> interactions when both are specified. If these two options are specified, we 
> should reject the query with an informative message.
> Shorter term, making this explicit in the documents would be helpful.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-13970) Collapse/Expand and Grouping are not designed to work together, we should fail requests that specify both gracefully

[Joel Bernstein (Jira)]

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

Joel Bernstein commented on SOLR-13970:
---

Added a test, and removed a test that was specifically exercising collapse and 
grouping.

That test was way back in Solr 4.7 as part this ticket: 
https://issues.apache.org/jira/browse/SOLR-5230.

Back then it was probably fine to have collapse and grouping together because 
the caches they rely on had a random access API. When the DocValues went to the 
iterator API collapse and grouping no longer worked anymore because grouping 
calls the same postfilter twice without resetting the internal state of the 
DocValues cache, which breaks things.

In a separate ticket we should inventory which postfilters use the DocValues 
caches during collect() and make sure they are through exceptions when used 
with grouping.

> Collapse/Expand and Grouping are not designed to work together, we should 
> fail requests that specify both gracefully
> 
>
> Key: SOLR-13970
> URL: https://issues.apache.org/jira/browse/SOLR-13970
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-13970.patch, SOLR-13970.patch, SOLR-13970.patch
>
>
> Expand/Collapse was conceived as orthogonal to grouping, and there are odd 
> interactions when both are specified. If these two options are specified, we 
> should reject the query with an informative message.
> Shorter term, making this explicit in the documents would be helpful.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (SOLR-13970) Collapse/Expand and Grouping are not designed to work together, we should fail requests that specify both gracefully

[Joel Bernstein (Jira)]

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

Joel Bernstein edited comment on SOLR-13970 at 12/10/19 7:32 PM:
-

Added a test, and removed a test that was specifically exercising collapse and 
grouping.

That test was added way back in Solr 4.7 as part this ticket:  
https://issues.apache.org/jira/browse/SOLR-5230.

Back then it was probably fine to have collapse and grouping together because 
the caches they rely on had a random access API. When DocValues went to the 
iterator API collapse and grouping no longer worked anymore because grouping 
calls the same postfilter twice without resetting the internal state of the 
DocValues cache, which breaks things.

In a separate ticket we should inventory which postfilters use the DocValues 
caches during collect() and make sure they all throw exceptions when used with 
grouping.


was (Author: joel.bernstein):
Added a test, and removed a test that was specifically exercising collapse and 
grouping.

That test was way back in Solr 4.7 as part this ticket: 
https://issues.apache.org/jira/browse/SOLR-5230.

Back then it was probably fine to have collapse and grouping together because 
the caches they rely on had a random access API. When the DocValues went to the 
iterator API collapse and grouping no longer worked anymore because grouping 
calls the same postfilter twice without resetting the internal state of the 
DocValues cache, which breaks things.

In a separate ticket we should inventory which postfilters use the DocValues 
caches during collect() and make sure they all throw exceptions when used with 
grouping.

> Collapse/Expand and Grouping are not designed to work together, we should 
> fail requests that specify both gracefully
> 
>
> Key: SOLR-13970
> URL: https://issues.apache.org/jira/browse/SOLR-13970
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-13970.patch, SOLR-13970.patch, SOLR-13970.patch
>
>
> Expand/Collapse was conceived as orthogonal to grouping, and there are odd 
> interactions when both are specified. If these two options are specified, we 
> should reject the query with an informative message.
> Shorter term, making this explicit in the documents would be helpful.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-13970) Collapse/Expand and Grouping are not designed to work together, we should fail requests that specify both gracefully

[Joel Bernstein (Jira)]

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

Joel Bernstein commented on SOLR-13970:
---

If people are OK with this patch I'll commit so it can be in the 8.4 release.

> Collapse/Expand and Grouping are not designed to work together, we should 
> fail requests that specify both gracefully
> 
>
> Key: SOLR-13970
> URL: https://issues.apache.org/jira/browse/SOLR-13970
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-13970.patch, SOLR-13970.patch, SOLR-13970.patch
>
>
> Expand/Collapse was conceived as orthogonal to grouping, and there are odd 
> interactions when both are specified. If these two options are specified, we 
> should reject the query with an informative message.
> Shorter term, making this explicit in the documents would be helpful.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-13999) Ref Guide is missing the ZKHost parameter for TopicStream

[Jason Gerlowski (Jira)]

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

Jason Gerlowski commented on SOLR-13999:


The docs look good.  I'm mostly just doing a little digging into any potential 
limitations to using zkHost before I merge.  From what I can tell the code uses 
zkHost to create a SolrClient, and then that client is used for both the data 
and "checkpoint" collections.  So both of those collections have to be on the 
same Solr cluster currently.  Have you tested this out at all?

> Ref Guide is missing the ZKHost parameter for TopicStream
> -
>
> Key: SOLR-13999
> URL: https://issues.apache.org/jira/browse/SOLR-13999
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation, streaming expressions
>Affects Versions: 8.3
>Reporter: David Eric Pugh
>Assignee: Jason Gerlowski
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> During a discussion about if you can use Streaming expressions across 
> seperate Solr clusters, noticed that the `search` expression supports passing 
> in a ZK Host, but `topic` doesn't.   However, investigating the code, you can 
> pass in your own zk host to register a tpic on another Solr cluster.  This is 
> to fix the docs.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-13806) SolrJ QueryResponse._explainMap is incorrectly typed

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-13806:


Commit 6d03baa485711283d61306fcac022e47aa263f4c in lucene-solr's branch 
refs/heads/master from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6d03baa ]

SOLR-13806: SolrJ QueryResponse._explainMap is incorrectly typed.


> SolrJ QueryResponse._explainMap is incorrectly typed
> 
>
> Key: SOLR-13806
> URL: https://issues.apache.org/jira/browse/SOLR-13806
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.3
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
>  Labels: newdev
> Fix For: 8.4
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> This field, and the corresponding getter, and the code that extracts debug 
> information from the NamedList response in {{extractDebugInfo}}, all use a 
> {{Map}} type.
> However, when {{debug.explain.structured=true}} is used the values returned 
> in response are not String-s, instead they are {{SimpleOrderedMap}}-s. This 
> causes the following exception to be thrown:
> {code}
> java.lang.ClassCastException: class 
> org.apache.solr.common.util.SimpleOrderedMap cannot be cast to class 
> java.lang.String (org.apache.solr.common.util.SimpleOrderedMap is in unnamed 
> module of loader 'app'; java.lang.String is in module java.base of loader 
> 'bootstrap')
>   at 
> __randomizedtesting.SeedInfo.seed([1D6FB4036A639051:173F5FF19E860E6F]:0)
>   at 
> org.apache.solr.client.solrj.response.QueryResponse.extractDebugInfo(QueryResponse.java:246)
>   at 
> org.apache.solr.client.solrj.response.QueryResponse.setResponse(QueryResponse.java:143)
>   at 
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207)
>   at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:987)
> ...
> {code}
> The simple fix is to change the type of this field to {{Map}} 
> but this would change the public API of {{QueryResponse.getExplainMap()}} in 
> incompatible way. Still, I would argue it's worth to change it - AFAIK this 
> getter is not used anywhere in the Solr's codebase, and the change makes it 
> more consistent with other getters.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (SOLR-14036) TermsComponent distributed search (shards) doesn't work with SolrCloud

[David Smiley (Jira)]

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

David Smiley updated SOLR-14036:

Status: Reopened  (was: Closed)

> TermsComponent distributed search (shards) doesn't work with SolrCloud
> --
>
> Key: SOLR-14036
> URL: https://issues.apache.org/jira/browse/SOLR-14036
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SearchComponents - other
>Reporter: David Smiley
>Priority: Major
>
> My colleagues [~bruno.roustant] and [~antogruz] attempted to use the 
> {{TermsComponent}} in SolrCloud on a collection with multiple shards.  The 
> results were inconsistent depending on which shard the client was talking 
> with.  Looking at the prepare() method, I can see this component reads the 
> "shards" param.  It should not have been coded that way; the SearchHandler or 
> related machinery is responsible for parsing/processing that.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-14026) Upgrade Jetty to 9.4.24.v20191120 and dropwizard to 4.1.2

[Jira]

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

Jan Høydahl commented on SOLR-14026:


Erick, if the traffic is now HTTP2 I guess asserting HTTP/1.1 is legacy, so 
feel free to just replace the string or if possible assert on code. 

> Upgrade Jetty to 9.4.24.v20191120 and dropwizard to 4.1.2
> -
>
> Key: SOLR-14026
> URL: https://issues.apache.org/jira/browse/SOLR-14026
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> Prompted by the linked JIRA.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-13985) bind to localhost by default

[Jira]

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

Jan Høydahl commented on SOLR-13985:


I'd perhaps prefer a shorter text in taking-solr-to-production with a link to 
the securing-solr page? Alternatively it should be possible to tag the 
paragraphs in securing-solr in some way so that you can include them with a 
reference in taking-solr-to-production. Then there is no duplication of text. 
You'll find examples of this elsewhere in the guide.

> bind to localhost by default
> 
>
> Key: SOLR-13985
> URL: https://issues.apache.org/jira/browse/SOLR-13985
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Robert Muir
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-13985.patch, SOLR-13985.patch, SOLR-13985.patch
>
>
> Currently solr binds to all interfaces by default. 
> The default should be safer, so that e.g. the user is not exposed to the 
> internet until they make an explicit step to do so.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Created] (SOLR-14045) Test and review all PostFilters with grouping

[Joel Bernstein (Jira)]

Joel Bernstein created SOLR-14045:
-

 Summary: Test and review all PostFilters with grouping
 Key: SOLR-14045
 URL: https://issues.apache.org/jira/browse/SOLR-14045
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Joel Bernstein


SOLR-13970 throws an exception if collapsing and grouping are combined. The 
issue here is that the CollapsingQParserPlugin is a postfilter that uses 
DocValues during the collect. Grouping calls the postfilter twice during it's 
two part grouping logic. When DocValues moved to the iterator API it was no 
longer valid to call the same postfilter twice without resetting the internal 
state of the DocValues caches. So, collapsing and grouping stopped working. For 
the time being throwing an exception ensures that people don't uses these 
features together, because unfortunately sometimes they work and sometimes they 
break depending on the situation. So it's possible to get fooled into thinking 
collapse and grouping work together.

We need to check the other postfilters to see if they have the same problem and 
either fix them so they can be can be called repeatedly or throw exceptions 
when used with grouping.

 

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-14036) TermsComponent distributed search (shards) doesn't work with SolrCloud

[David Smiley (Jira)]

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

David Smiley commented on SOLR-14036:
-

I'm re-opening.  SOLR-3645 claims it doesn't work but it's not evident in what 
circumstances.  Maybe it didn't ever work but in the intervening years suddenly 
did.  [~antogruz] tried it and he said it did work, although it's not clear if 
the results are truly correct.  Maybe.  (use-case was index introspection in 
dev setting).  I truly don't know; I'm not working with it.  I don't like:
* that prepare() is referencing shards but IMO it shouldn't care.  It needed 
maintenance once related to security.
* that the default config has distrib=false and no comment as to why
* that the documentation says anything about distributed search; it should 
simply work like all the other components do, which is the default presumption.

> TermsComponent distributed search (shards) doesn't work with SolrCloud
> --
>
> Key: SOLR-14036
> URL: https://issues.apache.org/jira/browse/SOLR-14036
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SearchComponents - other
>Reporter: David Smiley
>Priority: Major
>
> My colleagues [~bruno.roustant] and [~antogruz] attempted to use the 
> {{TermsComponent}} in SolrCloud on a collection with multiple shards.  The 
> results were inconsistent depending on which shard the client was talking 
> with.  Looking at the prepare() method, I can see this component reads the 
> "shards" param.  It should not have been coded that way; the SearchHandler or 
> related machinery is responsible for parsing/processing that.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (SOLR-14045) Test and review all PostFilters with grouping

[Joel Bernstein (Jira)]

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

Joel Bernstein updated SOLR-14045:
--
Description: 
SOLR-13970 throws an exception if collapsing and grouping are combined. The 
issue here is that the CollapsingQParserPlugin is a postfilter that uses 
DocValues during the collect. Grouping calls postfilters twice during its two 
part grouping logic. When DocValues moved to the iterator API it was no longer 
valid to call the same postfilter twice without resetting the internal state of 
the DocValues caches. So, collapsing and grouping stopped working. For the time 
being throwing an exception ensures that people don't uses these features 
together, because unfortunately sometimes they work and sometimes they break 
depending on the situation. So it's possible to get fooled into thinking 
collapse and grouping work together.

We need to check the other postfilters to see if they have the same problem and 
either fix them so they can be can be called repeatedly or throw exceptions 
when used with grouping.

 

 

  was:
SOLR-13970 throws an exception if collapsing and grouping are combined. The 
issue here is that the CollapsingQParserPlugin is a postfilter that uses 
DocValues during the collect. Grouping calls the postfilter twice during it's 
two part grouping logic. When DocValues moved to the iterator API it was no 
longer valid to call the same postfilter twice without resetting the internal 
state of the DocValues caches. So, collapsing and grouping stopped working. For 
the time being throwing an exception ensures that people don't uses these 
features together, because unfortunately sometimes they work and sometimes they 
break depending on the situation. So it's possible to get fooled into thinking 
collapse and grouping work together.

We need to check the other postfilters to see if they have the same problem and 
either fix them so they can be can be called repeatedly or throw exceptions 
when used with grouping.

 

 


> Test and review all PostFilters with grouping
> -
>
> Key: SOLR-14045
> URL: https://issues.apache.org/jira/browse/SOLR-14045
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Priority: Major
>
> SOLR-13970 throws an exception if collapsing and grouping are combined. The 
> issue here is that the CollapsingQParserPlugin is a postfilter that uses 
> DocValues during the collect. Grouping calls postfilters twice during its two 
> part grouping logic. When DocValues moved to the iterator API it was no 
> longer valid to call the same postfilter twice without resetting the internal 
> state of the DocValues caches. So, collapsing and grouping stopped working. 
> For the time being throwing an exception ensures that people don't uses these 
> features together, because unfortunately sometimes they work and sometimes 
> they break depending on the situation. So it's possible to get fooled into 
> thinking collapse and grouping work together.
> We need to check the other postfilters to see if they have the same problem 
> and either fix them so they can be can be called repeatedly or throw 
> exceptions when used with grouping.
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[GitHub] [lucene-solr] magibney commented on issue #892: LUCENE-8972: Add ICUTransformCharFilter, to support pre-tokenizer ICU text transformation

[GitBox]

magibney commented on issue #892: LUCENE-8972: Add ICUTransformCharFilter, to 
support pre-tokenizer ICU text transformation
URL: https://github.com/apache/lucene-solr/pull/892#issuecomment-564217729
 
 
   > Regarding further automatic performance optimization, I think that is very 
ambitious and maybe too much magic.
   
   Agreed.
   
   The only issue I have with the change you recently posted is the 
randomization of `assumeExternalUnicodeNormalization`. The tests _shouldn't_ 
generally pass with that arg randomly flipped, unless accompanied by a 
complementary, transliterator-specific top-level normalization change. If the 
tests pass with that arg randomized, that's dependent on the specific 
transliterator being used, and I'm concerned that even if the tests happen pass 
as written, randomly flipping that arg in tests conveys the impression that 
that's something one should be able to generally.
   
   Would you object to reverting/removing (from the proposed patch) the 
randomized form of `getTransliterator(String)` in `TestICUTransformCharFilter`? 
Could be replaced with additional test variants that _explicitly_ disable 
bundled normalization (and specifically add corresponding top-level -- i.e., 
`ICUNormalizer2CharFilter` -- normalization if necessary)?
   


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: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[GitHub] [lucene-solr] gerlowskija commented on issue #1068: SOLR-14033: Fix Hadoop tests with security manager

[GitBox]

gerlowskija commented on issue #1068: SOLR-14033: Fix Hadoop tests with 
security manager
URL: https://github.com/apache/lucene-solr/pull/1068#issuecomment-56440
 
 
   Tests still fail for me with this PR.
   
   To double check, here's how I applied it:
   ```
   git checkout master
   git pull
   git checkout -b apply_1068
   wget https://github.com/apache/lucene-solr/pull/1068
   patch -p1 -i 1068.patch
   ant clean compile && cd solr && ant server && cd ..
   ant clean test -Dtests.iters=5 -Dtestcase=HdfsBackupRepositoryTest
   ```
   
   And here's my Java version.  Not sure if it's relevant, but...
   ```
   openjdk version "11.0.2" 2019-01-15
   OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
   OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
   ```
   
   
[ant-output.txt](https://github.com/apache/lucene-solr/files/3946894/ant-output.txt)
   
   Attaching the ant output as well.


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: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[GitHub] [lucene-solr] gerlowskija edited a comment on issue #1068: SOLR-14033: Fix Hadoop tests with security manager

[GitBox]

gerlowskija edited a comment on issue #1068: SOLR-14033: Fix Hadoop tests with 
security manager
URL: https://github.com/apache/lucene-solr/pull/1068#issuecomment-56440
 
 
   Tests still fail for me with this PR.
   
   To double check, here's how I applied it:
   ```
   git checkout master
   git pull
   git checkout -b apply_1068
   wget https://github.com/apache/lucene-solr/pull/1068.patch
   patch -p1 -i 1068.patch
   ant clean compile && cd solr && ant server && cd ..
   ant clean test -Dtests.iters=5 -Dtestcase=HdfsBackupRepositoryTest
   ```
   
   And here's my Java version.  Not sure if it's relevant, but...
   ```
   openjdk version "11.0.2" 2019-01-15
   OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
   OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
   ```
   
   
[ant-output.txt](https://github.com/apache/lucene-solr/files/3946894/ant-output.txt)
   
   Attaching the ant output as well.


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: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-14045) Test and review all PostFilters with grouping

[Joel Bernstein (Jira)]

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

Joel Bernstein updated SOLR-14045:
--
Description: 
SOLR-13970 throws an exception if collapsing and grouping are combined. The 
issue here is that the CollapsingQParserPlugin is a postfilter that uses 
DocValues during the collect. Grouping calls postfilters twice during its two 
part grouping logic. When DocValues moved to the iterator API it was no longer 
valid to call the same postfilter twice without resetting the internal state of 
the DocValues caches. So, collapsing and grouping stopped working. For the time 
being throwing an exception ensures that people don't use these features 
together, because unfortunately sometimes they work and sometimes they break 
depending on the situation. So it's possible to get fooled into thinking 
collapse and grouping work together.

We need to check the other postfilters to see if they have the same problem and 
either fix them so they can be can be called repeatedly or throw exceptions 
when used with grouping.

 

 

  was:
SOLR-13970 throws an exception if collapsing and grouping are combined. The 
issue here is that the CollapsingQParserPlugin is a postfilter that uses 
DocValues during the collect. Grouping calls postfilters twice during its two 
part grouping logic. When DocValues moved to the iterator API it was no longer 
valid to call the same postfilter twice without resetting the internal state of 
the DocValues caches. So, collapsing and grouping stopped working. For the time 
being throwing an exception ensures that people don't uses these features 
together, because unfortunately sometimes they work and sometimes they break 
depending on the situation. So it's possible to get fooled into thinking 
collapse and grouping work together.

We need to check the other postfilters to see if they have the same problem and 
either fix them so they can be can be called repeatedly or throw exceptions 
when used with grouping.

 

 


> Test and review all PostFilters with grouping
> -
>
> Key: SOLR-14045
> URL: https://issues.apache.org/jira/browse/SOLR-14045
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Priority: Major
>
> SOLR-13970 throws an exception if collapsing and grouping are combined. The 
> issue here is that the CollapsingQParserPlugin is a postfilter that uses 
> DocValues during the collect. Grouping calls postfilters twice during its two 
> part grouping logic. When DocValues moved to the iterator API it was no 
> longer valid to call the same postfilter twice without resetting the internal 
> state of the DocValues caches. So, collapsing and grouping stopped working. 
> For the time being throwing an exception ensures that people don't use these 
> features together, because unfortunately sometimes they work and sometimes 
> they break depending on the situation. So it's possible to get fooled into 
> thinking collapse and grouping work together.
> We need to check the other postfilters to see if they have the same problem 
> and either fix them so they can be can be called repeatedly or throw 
> exceptions when used with grouping.
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[GitHub] [lucene-solr] gerlowskija edited a comment on issue #1068: SOLR-14033: Fix Hadoop tests with security manager

[GitBox]

gerlowskija edited a comment on issue #1068: SOLR-14033: Fix Hadoop tests with 
security manager
URL: https://github.com/apache/lucene-solr/pull/1068#issuecomment-56440
 
 
   Tests still fail for me with this PR.
   
   I don't pull down PRs often, so double-check how I applied it please:
   ```
   git checkout master
   git pull
   git checkout -b apply_1068
   wget https://github.com/apache/lucene-solr/pull/1068.patch
   patch -p1 -i 1068.patch
   ant clean compile && cd solr && ant server && cd ..
   ant clean test -Dtests.iters=5 -Dtestcase=HdfsBackupRepositoryTest
   ```
   
   And here's my Java version.  Not sure if it's relevant, but some of the 
comments above indicate we might be playing with classloading-order here, so 
figured it's worth mentioning.
   ```
   openjdk version "11.0.2" 2019-01-15
   OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
   OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
   ```
   
   
[ant-output.txt](https://github.com/apache/lucene-solr/files/3946894/ant-output.txt)
   
   Attaching the ant output as well.


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: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[GitHub] [lucene-solr] gerlowskija edited a comment on issue #1068: SOLR-14033: Fix Hadoop tests with security manager

[GitBox]

gerlowskija edited a comment on issue #1068: SOLR-14033: Fix Hadoop tests with 
security manager
URL: https://github.com/apache/lucene-solr/pull/1068#issuecomment-56440
 
 
   Tests still fail for me with this PR.
   
   I don't pull down PRs often, so double-check how I applied it please:
   ```
   git checkout master
   git pull
   git checkout -b apply_1068
   wget https://github.com/apache/lucene-solr/pull/1068.patch
   patch -p1 -i 1068.patch
   ant clean compile && cd solr && ant server && cd ..
   ant clean test -Dtests.iters=5 -Dtestcase=HdfsBackupRepositoryTest
   ```
   
   And here's my Java version.  Not sure if it's relevant, but some of the 
comments above indicate we might be playing with classloading-order here, so 
figured it's worth mentioning.
   ```
   openjdk version "11.0.2" 2019-01-15
   OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
   OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
   ```
   
   
[ant-output.txt](https://github.com/apache/lucene-solr/files/3946894/ant-output.txt)
   
   Attaching the ant output as well.  I neglected to save the whole list of 
failures from a full test run...there was more than just 
HdfsBackupRepositoryTest.  But the other test failures also looked like a 
similar NoClassDefFound issue.


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: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-13806) SolrJ QueryResponse._explainMap is incorrectly typed

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-13806:


Commit 7362a76e6e681e21642c21f23c89bb7cfad5561b in lucene-solr's branch 
refs/heads/branch_8x from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7362a76 ]

SOLR-13806: SolrJ QueryResponse._explainMap is incorrectly typed.


> SolrJ QueryResponse._explainMap is incorrectly typed
> 
>
> Key: SOLR-13806
> URL: https://issues.apache.org/jira/browse/SOLR-13806
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.3
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
>  Labels: newdev
> Fix For: 8.4
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> This field, and the corresponding getter, and the code that extracts debug 
> information from the NamedList response in {{extractDebugInfo}}, all use a 
> {{Map}} type.
> However, when {{debug.explain.structured=true}} is used the values returned 
> in response are not String-s, instead they are {{SimpleOrderedMap}}-s. This 
> causes the following exception to be thrown:
> {code}
> java.lang.ClassCastException: class 
> org.apache.solr.common.util.SimpleOrderedMap cannot be cast to class 
> java.lang.String (org.apache.solr.common.util.SimpleOrderedMap is in unnamed 
> module of loader 'app'; java.lang.String is in module java.base of loader 
> 'bootstrap')
>   at 
> __randomizedtesting.SeedInfo.seed([1D6FB4036A639051:173F5FF19E860E6F]:0)
>   at 
> org.apache.solr.client.solrj.response.QueryResponse.extractDebugInfo(QueryResponse.java:246)
>   at 
> org.apache.solr.client.solrj.response.QueryResponse.setResponse(QueryResponse.java:143)
>   at 
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207)
>   at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:987)
> ...
> {code}
> The simple fix is to change the type of this field to {{Map}} 
> but this would change the public API of {{QueryResponse.getExplainMap()}} in 
> incompatible way. Still, I would argue it's worth to change it - AFAIK this 
> getter is not used anywhere in the Solr's codebase, and the change makes it 
> more consistent with other getters.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Resolved] (SOLR-13806) SolrJ QueryResponse._explainMap is incorrectly typed

[Andrzej Bialecki (Jira)]

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

Andrzej Bialecki resolved SOLR-13806.
-
Resolution: Fixed

Fixed - thanks [~kgsdora] for the patch!

> SolrJ QueryResponse._explainMap is incorrectly typed
> 
>
> Key: SOLR-13806
> URL: https://issues.apache.org/jira/browse/SOLR-13806
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.3
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
>  Labels: newdev
> Fix For: 8.4
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> This field, and the corresponding getter, and the code that extracts debug 
> information from the NamedList response in {{extractDebugInfo}}, all use a 
> {{Map}} type.
> However, when {{debug.explain.structured=true}} is used the values returned 
> in response are not String-s, instead they are {{SimpleOrderedMap}}-s. This 
> causes the following exception to be thrown:
> {code}
> java.lang.ClassCastException: class 
> org.apache.solr.common.util.SimpleOrderedMap cannot be cast to class 
> java.lang.String (org.apache.solr.common.util.SimpleOrderedMap is in unnamed 
> module of loader 'app'; java.lang.String is in module java.base of loader 
> 'bootstrap')
>   at 
> __randomizedtesting.SeedInfo.seed([1D6FB4036A639051:173F5FF19E860E6F]:0)
>   at 
> org.apache.solr.client.solrj.response.QueryResponse.extractDebugInfo(QueryResponse.java:246)
>   at 
> org.apache.solr.client.solrj.response.QueryResponse.setResponse(QueryResponse.java:143)
>   at 
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207)
>   at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:987)
> ...
> {code}
> The simple fix is to change the type of this field to {{Map}} 
> but this would change the public API of {{QueryResponse.getExplainMap()}} in 
> incompatible way. Still, I would argue it's worth to change it - AFAIK this 
> getter is not used anywhere in the Solr's codebase, and the change makes it 
> more consistent with other getters.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (LUCENE-9088) JapaneseNumberFilter uses inaccurate PartOfSpeechAttribute

[Jim Ferenczi (Jira)]

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

Jim Ferenczi commented on LUCENE-9088:
--

I don't think this behavior is documented. The javadocs says: 

{noformat}
 * Also notice that token attributes such as
* \{@link org.apache.lucene.analysis.ja.tokenattributes.PartOfSpeechAttribute},
* \{@link org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute},
* \{@link org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute} and
* \{@link org.apache.lucene.analysis.ja.tokenattributes.BaseFormAttribute} are 
left
* unchanged and will inherit the values of the last token used to compose the 
normalized
* number and can be wrong. Hence, for １０万 (1), we will have
* \{@link org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute}
* set to マン. This is a known issue and is subject to a future improvement.
* 
{noformat}

but that doesn't explain why we use the POS of the token following a grouped 
number. IMO this is a bug that we should fix in order to ensure that the POS 
stop filter can be used to remove the punctuations that was needed to detect 
the numbers.

 

> JapaneseNumberFilter uses inaccurate PartOfSpeechAttribute
> --
>
> Key: LUCENE-9088
> URL: https://issues.apache.org/jira/browse/LUCENE-9088
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/analysis
>Reporter: Christoph Büscher
>Priority: Major
>
> According to the JapaneseNumberFilter javadocs, it uses the attribute values 
> of the last token used to compose the normalized number, which can be wrong. 
> While this is documented it leads to a number of incompatibilities with other 
> japanese token filters.
> For example, the PartOfSpeechAttribute of the last token used for an input 
> text of "2008 2009" will lead to an the following output (some attributes 
> left out...):
> ```
> {
>  "token" : "2008",
>  "start_offset" : 0,
>  "end_offset" : 4,
>  "type" : "word",
> [...]
> "partOfSpeech" : "記号-空白",
>  "partOfSpeech (en)" : "symbol-space"
> [...]
>  },
>  {
>  "token" : " ",
>  "start_offset" : 4,
>  "end_offset" : 5,
>  "type" : "word",
> [...]
> "partOfSpeech" : "記号-空白",
>  "partOfSpeech (en)" : "symbol-space",
> [...]
>  },
>  {
>  "token" : "2009",
>  "start_offset" : 5,
>  "end_offset" : 9,
>  "type" : "word",
> ...
>  "partOfSpeech" : "名詞-数",
>  "partOfSpeech (en)" : "noun-numeric",
>  }
> ```
> so that e.g. a following `{color:#1d1c1d}kuromoji_part_of_speech{color}` 
> filter will eliminate the "2008" token erroneously tagged as "symbol-space".
> Even without fixing the other token attrobutes, the POS attributes should 
> IMHO be set to "noun-numeric", since that's what the filter is supposed to 
> detect.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-13966) LatLonPointSpatialField doesn't work with RealTimeGetComponent

[Jira]

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

Thomas Wöckinger commented on SOLR-13966:
-

[~dsmiley] Found a small issue during review your commit 
[NestedAtomicUpdateTest.java:|https://github.com/apache/lucene-solr/commit/87aa11baf83f59365a30b12e2e41048bd8394182#diff-da0588524488fa7ae0433126c1d687a8]

Line 694:

doc = sdoc("id", "1", "child1", Collections.singletonMap("set", null));

should be:

doc = sdoc("id", "1", "child1", Collections.singletonMap("set", empty ? new 
ArrayList<>() : null));

Was also wrong in my last PR, sorry for that.

> LatLonPointSpatialField doesn't work with RealTimeGetComponent
> --
>
> Key: SOLR-13966
> URL: https://issues.apache.org/jira/browse/SOLR-13966
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis, UpdateRequestProcessors
>Affects Versions: master (9.0), 8.3, 8.3.1
>Reporter: Thomas Wöckinger
>Assignee: David Smiley
>Priority: Major
> Fix For: 8.4
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> LatLonDocValuesField is used by LatLonPointSpatialField field type to store 
> doc values. It does this by encoding the two double values into a long. If 
> the field is part of a document which takes place within a atomic update 
> operation RealTimeGetComponent is used to load the field values from the 
> index. 
> If the request is a nested request (line number 654: isNestedRequest is set 
> by DistributedUpdateProcessor to Resolution.ROOT_WITH_CHILDREN) all field 
> values from the schema are copied into a SolrInputDocument (line 678).
> The copy is implemented by toSolrInputDocument method (line 728 of 
> RealTimeGetComponent). The method retrieves the FieldType of the SchemaField 
> and calls the toObject method (line 740). In case of LatLonPointSpatialField 
> type, when docValues is set to true and stored is set to false, the fieldData 
> is stored by a  LatLonDocValuesField instance.
> The toObject method is implemented by the base class FieldType toExternal 
> with the LatLonDocValuesField instance (line 373). In line 359 the method 
> stringValue of the Field is called. The default implementation (line 259) 
> checks if the fieldsData is either CharSequence or a Number and calls 
> fieldsData.toString.
> Because fieldsData is of type Long in LatLonDocValuesField class the value is 
> not decoded correctly.
> From my opinion LatLonDocValuesField must implement (override) the 
> stringValue method and return the decoded value.
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Created] (SOLR-14046) Add y-domain parameter to facet2D Stream Evaluator

[Joel Bernstein (Jira)]

Joel Bernstein created SOLR-14046:
-

 Summary: Add y-domain parameter to facet2D Stream Evaluator
 Key: SOLR-14046
 URL: https://issues.apache.org/jira/browse/SOLR-14046
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: streaming expressions
Reporter: Joel Bernstein


The y-domain parameter will allow the facet2D function change the query for the 
*y* dimension in a facet2D aggregation:

Syntax:
{code:java}
facet2D(stocks, q="ticker_s:jpm", x="yearMonthDay", y="ticker_s", 
y-domain="*:*", max(change_d)) {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[GitHub] [lucene-solr] rmuir commented on issue #1068: SOLR-14033: Fix Hadoop tests with security manager

[GitBox]

rmuir commented on issue #1068: SOLR-14033: Fix Hadoop tests with security 
manager
URL: https://github.com/apache/lucene-solr/pull/1068#issuecomment-564246790
 
 
   Hi @gerlowskija thank you for helping test.
   
   Can you run this for me from your command shell: `echo $HADOOP_HOME` I want 
to see if it is set to something. it looks to me like hadoop is installed via 
homebrew or similar mechanism.
   
   If you look at the exception, it happens because code tries to access 
`/usr/local/Cellar/hadoop/3.1.1` on your local machine, which is not even the 
correct one for solr tests.
   
   From the stacktrace you find relevant code here:
   
   
https://github.com/apache/hadoop/blob/release-3.2.0-RC1/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/util/Shell.java#L417-L440
   
   If this has been really happening, good that its caught now. We may have to 
explicitly clear this environment variable in tests (or ensure sysprop is set) 
from the build system or similar.


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: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-14046) Add y-domain parameter to facet2D Stream Evaluator

[Joel Bernstein (Jira)]

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

Joel Bernstein updated SOLR-14046:
--
Description: 
The y-domain parameter will allow the facet2D function to change the query for 
the *y* dimension in a facet2D aggregation:

Syntax:
{code:java}
facet2D(stocks, 
q="ticker_s:jpm", 
x="yearMonthDay", 
y="ticker_s", 
y-domain="*:*", 
dimensions="50, 50",
max(change_d)) {code}
The example above changes the query for y-dimension to be "*:*". The main query 
is still applied to the x-dimension.

 

  was:
The y-domain parameter will allow the facet2D function change the query for the 
*y* dimension in a facet2D aggregation:

Syntax:
{code:java}
facet2D(stocks, q="ticker_s:jpm", x="yearMonthDay", y="ticker_s", 
y-domain="*:*", max(change_d)) {code}


> Add y-domain parameter to facet2D Stream Evaluator
> --
>
> Key: SOLR-14046
> URL: https://issues.apache.org/jira/browse/SOLR-14046
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Priority: Major
>
> The y-domain parameter will allow the facet2D function to change the query 
> for the *y* dimension in a facet2D aggregation:
> Syntax:
> {code:java}
> facet2D(stocks, 
> q="ticker_s:jpm", 
> x="yearMonthDay", 
> y="ticker_s", 
> y-domain="*:*", 
> dimensions="50, 50",
> max(change_d)) {code}
> The example above changes the query for y-dimension to be "*:*". The main 
> query is still applied to the x-dimension.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (SOLR-14046) Add y-domain parameter to facet2D Stream Evaluator

[Joel Bernstein (Jira)]

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

Joel Bernstein updated SOLR-14046:
--
Description: 
The y-domain parameter will allow the facet2D function to change the query for 
the *y* dimension in a facet2D aggregation:

Syntax:
{code:java}
facet2D(stocks, 
q="ticker_s:jpm", 
x="yearMonthDay", 
y="ticker_s", 
y-domain="*:*", 
dimensions="50, 50",
max(change_d)) {code}
The example above changes the query for the y-dimension to be
{code:java}
*:* {code}
The main query is still applied to the x-dimension.

 

  was:
The y-domain parameter will allow the facet2D function to change the query for 
the *y* dimension in a facet2D aggregation:

Syntax:
{code:java}
facet2D(stocks, 
q="ticker_s:jpm", 
x="yearMonthDay", 
y="ticker_s", 
y-domain="*:*", 
dimensions="50, 50",
max(change_d)) {code}
The example above changes the query for the y-dimension to be `*:*`. The main 
query is still applied to the x-dimension.

 


> Add y-domain parameter to facet2D Stream Evaluator
> --
>
> Key: SOLR-14046
> URL: https://issues.apache.org/jira/browse/SOLR-14046
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Priority: Major
>
> The y-domain parameter will allow the facet2D function to change the query 
> for the *y* dimension in a facet2D aggregation:
> Syntax:
> {code:java}
> facet2D(stocks, 
> q="ticker_s:jpm", 
> x="yearMonthDay", 
> y="ticker_s", 
> y-domain="*:*", 
> dimensions="50, 50",
> max(change_d)) {code}
> The example above changes the query for the y-dimension to be
> {code:java}
> *:* {code}
> The main query is still applied to the x-dimension.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (SOLR-14046) Add y-domain parameter to facet2D Stream Evaluator

[Joel Bernstein (Jira)]

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

Joel Bernstein updated SOLR-14046:
--
Description: 
The y-domain parameter will allow the facet2D function to change the query for 
the *y* dimension in a facet2D aggregation:

Syntax:
{code:java}
facet2D(stocks, 
q="ticker_s:jpm", 
x="yearMonthDay", 
y="ticker_s", 
y-domain="*:*", 
dimensions="50, 50",
max(change_d)) {code}
The example above changes the query for the y-dimension to be `*:*`. The main 
query is still applied to the x-dimension.

 

  was:
The y-domain parameter will allow the facet2D function to change the query for 
the *y* dimension in a facet2D aggregation:

Syntax:
{code:java}
facet2D(stocks, 
q="ticker_s:jpm", 
x="yearMonthDay", 
y="ticker_s", 
y-domain="*:*", 
dimensions="50, 50",
max(change_d)) {code}
The example above changes the query for y-dimension to be "*:*". The main query 
is still applied to the x-dimension.

 


> Add y-domain parameter to facet2D Stream Evaluator
> --
>
> Key: SOLR-14046
> URL: https://issues.apache.org/jira/browse/SOLR-14046
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Priority: Major
>
> The y-domain parameter will allow the facet2D function to change the query 
> for the *y* dimension in a facet2D aggregation:
> Syntax:
> {code:java}
> facet2D(stocks, 
> q="ticker_s:jpm", 
> x="yearMonthDay", 
> y="ticker_s", 
> y-domain="*:*", 
> dimensions="50, 50",
> max(change_d)) {code}
> The example above changes the query for the y-dimension to be `*:*`. The main 
> query is still applied to the x-dimension.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (SOLR-14046) Add y-domain parameter to facet2D Stream Evaluator

[Joel Bernstein (Jira)]

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

Joel Bernstein updated SOLR-14046:
--
Description: 
The y-domain parameter will allow the facet2D function to change the query for 
the *y* dimension in a facet2D aggregation:

Syntax:
{code:java}
facet2D(stocks, 
q="ticker_s:jpm", 
x="yearMonthDay", 
y="ticker_s", 
y-domain="*:*", 
dimensions="50, 50",
max(change_d)) {code}
The example above changes the query for the y-dimension to be
{code:java}
*:* {code}
The main query is still applied to the x-dimension.

This aggregation behavior creates graph adjacency matrices that can be mined 
for correlations. 

  was:
The y-domain parameter will allow the facet2D function to change the query for 
the *y* dimension in a facet2D aggregation:

Syntax:
{code:java}
facet2D(stocks, 
q="ticker_s:jpm", 
x="yearMonthDay", 
y="ticker_s", 
y-domain="*:*", 
dimensions="50, 50",
max(change_d)) {code}
The example above changes the query for the y-dimension to be
{code:java}
*:* {code}
The main query is still applied to the x-dimension.

 


> Add y-domain parameter to facet2D Stream Evaluator
> --
>
> Key: SOLR-14046
> URL: https://issues.apache.org/jira/browse/SOLR-14046
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Priority: Major
>
> The y-domain parameter will allow the facet2D function to change the query 
> for the *y* dimension in a facet2D aggregation:
> Syntax:
> {code:java}
> facet2D(stocks, 
> q="ticker_s:jpm", 
> x="yearMonthDay", 
> y="ticker_s", 
> y-domain="*:*", 
> dimensions="50, 50",
> max(change_d)) {code}
> The example above changes the query for the y-dimension to be
> {code:java}
> *:* {code}
> The main query is still applied to the x-dimension.
> This aggregation behavior creates graph adjacency matrices that can be mined 
> for correlations. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[GitHub] [lucene-solr] rmuir commented on issue #1068: SOLR-14033: Fix Hadoop tests with security manager

[GitBox]

rmuir commented on issue #1068: SOLR-14033: Fix Hadoop tests with security 
manager
URL: https://github.com/apache/lucene-solr/pull/1068#issuecomment-564248672
 
 
   If this environment variable doesn't yield anything, could you run `env` and 
manually look for anything suspicious such as `JAVA_TOOL_OPTIONS=` that might 
contain hadoop related sysprops? I want to know why its looking on that place 
in your filesystem.


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: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-13975) ConcurrentUpdateSolrClient connection stall prevention

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-13975:


Commit c4f0c3363828c088eefa2b99783178848c2f1f7a in lucene-solr's branch 
refs/heads/master from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c4f0c33 ]

SOLR-13975, SOLR-13896: ConcurrentUpdateSolrClient connection stall prevention.


> ConcurrentUpdateSolrClient connection stall prevention
> --
>
> Key: SOLR-13975
> URL: https://issues.apache.org/jira/browse/SOLR-13975
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.3, 8.4
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 8.4
>
> Attachments: SOLR-13975.patch, SOLR-13975.patch
>
>
> When a Solr process, which hosts replicas of a collection, is suspended - 
> that is, the OS process is suspended using eg. {{kill -STOP }} - a long 
> stall may occur in CUSC until a socket timeout is reached.
> During this stall updates from the leader are not forwarded to any replica, 
> even though other replicas are still active and can receive updates.  If the 
> sender uses CUSC (eg. via {{CloudSolrClient}}) then it becomes stalled 
> because the leader stops processing updates, too.
> This situation is caused by several issues:
> * when a process is suspended its sockets remain open - so there is no 
> immediate disconnect as if the process died, but the process becomes 
> unresponsive. Eventually, a socket timeout will be reached 
> (distribUpdateSoTimeout) - but in the default version of {{solr.xml}} this is 
> set to 10 min. During this time all indexing to that shard will be stuck.
> * there are several infinite {{for}} loops in CUSC (eg. in 
> {{blockUntilFinished}}, {{waitForEmptyQueue}} and even in {{request}}), which 
> rely either on the relatively quick success of the call or an exception to be 
> thrown. However, in this situation neither happens quickly - the call is 
> stuck waiting for the remote end until soTimeout expires.
> This issue proposes to add a stall prevention logic, which would break these 
> infinite loops long before the socket timeout occurs based on the progress of 
> the queue processing.
> This is a follow-up to SOLR-13896.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-13896) Paused a non-leader node can cause recovery on other nodes

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-13896:


Commit c4f0c3363828c088eefa2b99783178848c2f1f7a in lucene-solr's branch 
refs/heads/master from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c4f0c33 ]

SOLR-13975, SOLR-13896: ConcurrentUpdateSolrClient connection stall prevention.


> Paused a non-leader node can cause recovery on other nodes
> --
>
> Key: SOLR-13896
> URL: https://issues.apache.org/jira/browse/SOLR-13896
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Andrzej Bialecki
>Priority: Major
> Attachments: SOLR-13896.patch
>
>
> All stacktraces below based on 7.5 branch. This problem still exist at 8.x 
> branches. Here is the scenario, we have 3 replicas
>  * L: the leader replica
>  * R: the normal replica
>  * P: the poor one which was paused then resumed
> L is trying to send data to R, P during that P get paused, here is what 
> happen at L's threads.
>  * Thread 1 is stucking at this line of StreamingSolrClients
> {code:java}
> public synchronized void blockUntilFinished() {
>   for (ConcurrentUpdateSolrClient client : solrClients.values()) {
> client.blockUntilFinished();
>   }
> } {code}
> basically this thread is trying to wait for other sender threads to finish. 
> Let's assume that this is the content of *solrClients.values : [clientToP, 
> clientToR]*
>  * Thread 2 coressponds to *clientToP* since P is paused, it doesn't close 
> the connection. it just keep the connection and never return any data backs 
> to L. So this thread stuck with this stack trace, waiting for response data 
> from *P* (with timeout=60ms)*.* Therefore it cause the thread1 stuck at 
> *clientToP.blockUntilFinished()*
> {code:java}
>     java.lang.Thread.State: RUNNABLE   java.lang.Thread.State: RUNNABLE at 
> java.net.SocketInputStream.socketRead0(Native Method) at 
> java.net.SocketInputStream.socketRead(SocketInputStream.java:116) at 
> java.net.SocketInputStream.read(SocketInputStream.java:171) at 
> java.net.SocketInputStream.read(SocketInputStream.java:141) at 
> org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137)
>  at 
> org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153)
>  at 
> org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:282)
>  at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138)
>  at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56)
>  at 
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259)
>  at 
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163)
>  at 
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:165)
>  at 
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)
>  at 
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
>  at 
> org.apache.solr.util.stats.InstrumentedHttpRequestExecutor.execute(InstrumentedHttpRequestExecutor.java:120)
>  at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272)
>  at 
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185) at 
> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89) at 
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111) at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
>  at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
>  at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56)
>  at 
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$Runner.sendUpdateStream(ConcurrentUpdateSolrClient.java:347){code}
>  * Since *clientToR* is the second element of the array,   is never get 
> called (or at least after the timeout). This problem cause Thread 3, to stuck 
> at this line
> {code:java}
> upd = queue.poll(pollQueueTime, TimeUnit.MILLISECONDS); {code}
> note that pollQueueTime == Integer.MAX_VALUE (this set by 
> StreamingSolrClients). Therefore unless clientToR.blockUntilFinished() is 
> called (which interrupt Thread 3) this Thread 3 will stuck at above line 
> forever
>  * because *clientToR* is sending data to R but never close the outputstream, 
> so basically R just waiting forever (until timeout at 12

[jira] [Commented] (SOLR-14033) Fix Hadoop tests with security manager

[Chris M. Hostetter (Jira)]

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

Chris M. Hostetter commented on SOLR-14033:
---

Cursory (linux) testing suggests that this fixes the bulk of the jenkins 
failures we've been seeing lately related to HDFS/Hadoop/DelegateToken testing.

it seems like we should probably also add:
* some dev docs (package level javadocs?) explaining the whole 
{{org.apache.hadoop}} "shadow" class impls
* ideally include some hook in {{HdfsTestUtil}} that causes it to fail fast if 
it can detect that the classloader didn't pick up our modified classes? .. 
maybe by adding a new {{public static final Object 
SOLR_HACK_FOR_CLASS_VERIFICATION = new Object}} to each 
{{org.apache.hadoop.\*\*}} that it could check for via reflection?

...but those (and discussion of those) could easily be defered to their own 
JIras.

+1 to commiting this ASAP (unless you know of some reason to wait that i don't 
see)

> Fix Hadoop tests with security manager
> --
>
> Key: SOLR-14033
> URL: https://issues.apache.org/jira/browse/SOLR-14033
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Hadoop Integration, hdfs, Tests
>Reporter: Kevin Risden
>Assignee: Kevin Risden
>Priority: Major
> Attachments: SOLR-14033.patch
>
>  Time Spent: 5.5h
>  Remaining Estimate: 0h
>
> SOLR-14000 and SOLR-14002 have been cleaning this up. Seeing some HDFS suite 
> failures due to missing nulling out static variables and Hadoop being stupid 
> with the security manager.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[GitHub] [lucene-solr] gerlowskija commented on issue #1068: SOLR-14033: Fix Hadoop tests with security manager

[GitBox]

gerlowskija commented on issue #1068: SOLR-14033: Fix Hadoop tests with 
security manager
URL: https://github.com/apache/lucene-solr/pull/1068#issuecomment-564252562
 
 
   Good thinking.
   
   ```
   ➜  lucene-solr-1 git:(SOLR-13999) ✗ echo $HADOOP_HOME
   /usr/local/Cellar/hadoop/3.1.1
   ```
   
   +1 for adding something to unset that env-var if present, though idk where 
that would happen.


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: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org