[GitHub] [lucene-solr] dweiss opened a new pull request #2001: Correct EOL at the end of sha for junit, branch_8x

2020-10-18 Thread GitBox 


dweiss opened a new pull request #2001:
URL: https://github.com/apache/lucene-solr/pull/2001


   



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



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

[GitHub] [lucene-solr] dweiss merged pull request #2001: Correct EOL at the end of sha for junit, branch_8x

2020-10-18 Thread GitBox 


dweiss merged pull request #2001:
URL: https://github.com/apache/lucene-solr/pull/2001


   



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



-
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 pull request #2001: Correct EOL at the end of sha for junit, branch_8x

2020-10-18 Thread GitBox 


msokolov commented on pull request #2001:
URL: https://github.com/apache/lucene-solr/pull/2001#issuecomment-711158205


   Thank you
   
   On Sun, Oct 18, 2020 at 3:49 AM Dawid Weiss 
   wrote:
   
   > Merged #2001  into
   > branch_8x.
   >
   > —
   > You are receiving this because you are subscribed to this thread.
   > 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



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

[jira] [Commented] (LUCENE-9322) Discussing a unified vectors format API

2020-10-18 Thread ASF subversion and git services (Jira) 


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

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

Commit c02f07f2d5db5c983c2eedf71febf9516189595d in lucene-solr's branch 
refs/heads/master from Michael Sokolov
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c02f07f ]

LUCENE-9322: Add Lucene90 codec, including VectorFormat

This commit adds support for dense floating point VectorFields.
The new VectorValues class provides access to the indexed vectors.


> Discussing a unified vectors format API
> ---
>
> Key: LUCENE-9322
> URL: https://issues.apache.org/jira/browse/LUCENE-9322
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Julie Tibshirani
>Priority: Major
>  Time Spent: 5h 20m
>  Remaining Estimate: 0h
>
> Two different approximate nearest neighbor approaches are currently being 
> developed, one based on HNSW (LUCENE-9004) and another based on coarse 
> quantization ([#LUCENE-9136]). Each prototype proposes to add a new format to 
> handle vectors. In LUCENE-9136 we discussed the possibility of a unified API 
> that could support both approaches. The two ANN strategies give different 
> trade-offs in terms of speed, memory, and complexity, and it’s likely that 
> we’ll want to support both. Vector search is also an active research area, 
> and it would be great to be able to prototype and incorporate new approaches 
> without introducing more formats.
> To me it seems like a good time to begin discussing a unified API. The 
> prototype for coarse quantization 
> ([https://github.com/apache/lucene-solr/pull/1314]) could be ready to commit 
> soon (this depends on everyone's feedback of course). The approach is simple 
> and shows solid search performance, as seen 
> [here|https://github.com/apache/lucene-solr/pull/1314#issuecomment-608645326].
>  I think this API discussion is an important step in moving that 
> implementation forward.
> The goals of the API would be
> # Support for storing and retrieving individual float vectors.
> # Support for approximate nearest neighbor search -- given a query vector, 
> return the indexed vectors that are closest to it.



--
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-9322) Discussing a unified vectors format API

2020-10-18 Thread ASF subversion and git services (Jira) 


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

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

Commit dbcbcd0ee8bc2dc2ba49b12b9b7d45c33baad061 in lucene-solr's branch 
refs/heads/master from Michael Sokolov
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=dbcbcd0 ]

Add CHANGES entry for LUCENE-9322


> Discussing a unified vectors format API
> ---
>
> Key: LUCENE-9322
> URL: https://issues.apache.org/jira/browse/LUCENE-9322
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Julie Tibshirani
>Priority: Major
>  Time Spent: 5h 20m
>  Remaining Estimate: 0h
>
> Two different approximate nearest neighbor approaches are currently being 
> developed, one based on HNSW (LUCENE-9004) and another based on coarse 
> quantization ([#LUCENE-9136]). Each prototype proposes to add a new format to 
> handle vectors. In LUCENE-9136 we discussed the possibility of a unified API 
> that could support both approaches. The two ANN strategies give different 
> trade-offs in terms of speed, memory, and complexity, and it’s likely that 
> we’ll want to support both. Vector search is also an active research area, 
> and it would be great to be able to prototype and incorporate new approaches 
> without introducing more formats.
> To me it seems like a good time to begin discussing a unified API. The 
> prototype for coarse quantization 
> ([https://github.com/apache/lucene-solr/pull/1314]) could be ready to commit 
> soon (this depends on everyone's feedback of course). The approach is simple 
> and shows solid search performance, as seen 
> [here|https://github.com/apache/lucene-solr/pull/1314#issuecomment-608645326].
>  I think this API discussion is an important step in moving that 
> implementation forward.
> The goals of the API would be
> # Support for storing and retrieving individual float vectors.
> # Support for approximate nearest neighbor search -- given a query vector, 
> return the indexed vectors that are closest to it.



--
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 closed pull request #1930: LUCENE-9322: add VectorValues to new Lucene90 codec

2020-10-18 Thread GitBox 


msokolov closed pull request #1930:
URL: https://github.com/apache/lucene-solr/pull/1930


   



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



-
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 pull request #1930: LUCENE-9322: add VectorValues to new Lucene90 codec

2020-10-18 Thread GitBox 


msokolov commented on pull request #1930:
URL: https://github.com/apache/lucene-solr/pull/1930#issuecomment-711171187


   I squashed, resolved conflicts and pushed using command line



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



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

[jira] [Updated] (LUCENE-9322) Discussing a unified vectors format API

2020-10-18 Thread Michael Sokolov (Jira) 


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

Michael Sokolov updated LUCENE-9322:

Fix Version/s: master (9.0)

> Discussing a unified vectors format API
> ---
>
> Key: LUCENE-9322
> URL: https://issues.apache.org/jira/browse/LUCENE-9322
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Julie Tibshirani
>Priority: Major
> Fix For: master (9.0)
>
>  Time Spent: 5h 40m
>  Remaining Estimate: 0h
>
> Two different approximate nearest neighbor approaches are currently being 
> developed, one based on HNSW (LUCENE-9004) and another based on coarse 
> quantization ([#LUCENE-9136]). Each prototype proposes to add a new format to 
> handle vectors. In LUCENE-9136 we discussed the possibility of a unified API 
> that could support both approaches. The two ANN strategies give different 
> trade-offs in terms of speed, memory, and complexity, and it’s likely that 
> we’ll want to support both. Vector search is also an active research area, 
> and it would be great to be able to prototype and incorporate new approaches 
> without introducing more formats.
> To me it seems like a good time to begin discussing a unified API. The 
> prototype for coarse quantization 
> ([https://github.com/apache/lucene-solr/pull/1314]) could be ready to commit 
> soon (this depends on everyone's feedback of course). The approach is simple 
> and shows solid search performance, as seen 
> [here|https://github.com/apache/lucene-solr/pull/1314#issuecomment-608645326].
>  I think this API discussion is an important step in moving that 
> implementation forward.
> The goals of the API would be
> # Support for storing and retrieving individual float vectors.
> # Support for approximate nearest neighbor search -- given a query vector, 
> return the indexed vectors that are closest to it.



--
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] (LUCENE-9322) Discussing a unified vectors format API

2020-10-18 Thread Michael Sokolov (Jira) 


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

Michael Sokolov resolved LUCENE-9322.
-
Resolution: Fixed

> Discussing a unified vectors format API
> ---
>
> Key: LUCENE-9322
> URL: https://issues.apache.org/jira/browse/LUCENE-9322
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Julie Tibshirani
>Priority: Major
> Fix For: master (9.0)
>
>  Time Spent: 5h 40m
>  Remaining Estimate: 0h
>
> Two different approximate nearest neighbor approaches are currently being 
> developed, one based on HNSW (LUCENE-9004) and another based on coarse 
> quantization ([#LUCENE-9136]). Each prototype proposes to add a new format to 
> handle vectors. In LUCENE-9136 we discussed the possibility of a unified API 
> that could support both approaches. The two ANN strategies give different 
> trade-offs in terms of speed, memory, and complexity, and it’s likely that 
> we’ll want to support both. Vector search is also an active research area, 
> and it would be great to be able to prototype and incorporate new approaches 
> without introducing more formats.
> To me it seems like a good time to begin discussing a unified API. The 
> prototype for coarse quantization 
> ([https://github.com/apache/lucene-solr/pull/1314]) could be ready to commit 
> soon (this depends on everyone's feedback of course). The approach is simple 
> and shows solid search performance, as seen 
> [here|https://github.com/apache/lucene-solr/pull/1314#issuecomment-608645326].
>  I think this API discussion is an important step in moving that 
> implementation forward.
> The goals of the API would be
> # Support for storing and retrieving individual float vectors.
> # Support for approximate nearest neighbor search -- given a query vector, 
> return the indexed vectors that are closest to it.



--
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-14943) Monitoring Solr with Prometheus and Grafana Ref Guide Page Needs Updates!

2020-10-18 Thread David Smiley (Jira) 


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

David Smiley commented on SOLR-14943:
-

At this point, it isn't experimental anymore.  That label is useful for new 
components so that we can make further changes without worrying much about 
backwards-incompatibility.

> Monitoring Solr with Prometheus and Grafana Ref Guide Page Needs Updates!
> -
>
> Key: SOLR-14943
> URL: https://issues.apache.org/jira/browse/SOLR-14943
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 8.7
>Reporter: David Eric Pugh
>Assignee: David Eric Pugh
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I am learning by following the refguide page Monitoring Solr with Prometheus 
> and Grafana, and it needs some updates based on my learning from a pretty 
> novice level about Prometheus and Grafana!  There are some incorrect ports in 
> the example commands, and or some paths that need updating that tripped me 
> up, and some transitions between sections would help onboard the next person.
> For example, it a LONG time to figure out that I needed to run a Prometheus 
> server as well as grafana as well as the exporter process ;-)



--
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] mocobeta commented on a change in pull request #2000: LUCENE-9318: Clean up package name conflicts for backward-codecs

2020-10-18 Thread GitBox 


mocobeta commented on a change in pull request #2000:
URL: https://github.com/apache/lucene-solr/pull/2000#discussion_r507173608



##
File path: lucene/core/src/java/org/apache/lucene/index/IndexUpgrader.java
##
@@ -77,9 +77,10 @@ private static void printUsage() {
   public static void main(String[] args) throws IOException {
 parseArgs(args).upgrade();
   }
-  
+
+  /** Parse arguments. */
   @SuppressForbidden(reason = "System.out required: command line tool")
-  static IndexUpgrader parseArgs(String[] args) throws IOException {
+  public static IndexUpgrader parseArgs(String[] args) throws IOException {

Review comment:
   It should be possible to just call `main()` instead of calling 
parseArgs() and upgrade() separately. Can we omit the assertion error regarding 
to `parseArgs()`?
   
   ```
   /*
   IndexUpgrader upgrader = null;
   try {
 upgrader = IndexUpgrader.parseArgs(args.toArray(new String[0]));
   } catch (Exception e) {
 throw new AssertionError("unable to parse args: " + args, e);
   }
   upgrader.upgrade();
*/
   // this could throw IOException. 
   // we cannot identify whether the error occurs in parseArgs() or 
upgrade()
   IndexUpgrader.main(args.toArray(new String[0]));
   ```





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



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

[jira] [Commented] (LUCENE-9576) nuke SSD detection: was IndexWriter::commit() hangs when the server has a stale NFS mount.

2020-10-18 Thread ASF subversion and git services (Jira) 


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

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

Commit 4c42cbc5c9a2788027997b1c05fca1cbe65e28fe in lucene-solr's branch 
refs/heads/master from Robert Muir
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4c42cbc ]

LUCENE-9576: give solr back its getFileStoreAttributes permission

Solr apparently needs this for its IndexFetcher.


> nuke SSD detection: was IndexWriter::commit() hangs when the server has a 
> stale NFS mount.
> --
>
> Key: LUCENE-9576
> URL: https://issues.apache.org/jira/browse/LUCENE-9576
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index
>Affects Versions: 8.5.2
>Reporter: Girish Nayak
>Assignee: Robert Muir
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: IndexWriter-commit.PNG, LUCENE-9576.patch, 
> LUCENE-9576.patch
>
>
> Noticed IndexWriter::commit() hangs when the server has one or more stale NFS 
> mounts.
>  



--
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] uschindler commented on a change in pull request #2000: LUCENE-9318: Clean up package name conflicts for backward-codecs

2020-10-18 Thread GitBox 


uschindler commented on a change in pull request #2000:
URL: https://github.com/apache/lucene-solr/pull/2000#discussion_r507185119



##
File path: lucene/core/src/java/org/apache/lucene/index/IndexUpgrader.java
##
@@ -77,9 +77,10 @@ private static void printUsage() {
   public static void main(String[] args) throws IOException {
 parseArgs(args).upgrade();
   }
-  
+
+  /** Parse arguments. */
   @SuppressForbidden(reason = "System.out required: command line tool")
-  static IndexUpgrader parseArgs(String[] args) throws IOException {
+  public static IndexUpgrader parseArgs(String[] args) throws IOException {

Review comment:
   I think so.





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



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

[GitHub] [lucene-solr] dsmiley opened a new pull request #2002: SOLR Mark only @deprecated tag, not @Deprecated annotation

2020-10-18 Thread GitBox 


dsmiley opened a new pull request #2002:
URL: https://github.com/apache/lucene-solr/pull/2002


   For DIH, HDFS, Velocity.
   These [will] *move* outside the Solr project, and are not disappearing from 
a user's standpoint.  Use of Deprecated annotation on a plugin will cause a 
warning on startup, which will needlessly alarm users for these plugins.
   
   
   
   
   # Description
   
   Please provide a short description of the changes you're making with this 
pull request.
   
   # Solution
   
   Please provide a short description of the approach taken to implement your 
solution.
   
   # Tests
   
   Please describe the tests you've developed or run to confirm this patch 
implements the feature or solves the problem.
   
   # Checklist
   
   Please review the following and check all that apply:
   
   - [ ] I have reviewed the guidelines for [How to 
Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms 
to the standards described there to the best of my ability.
   - [ ] I have created a Jira issue and added the issue ID to my pull request 
title.
   - [ ] I have given Solr maintainers 
[access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork)
 to contribute to my PR branch. (optional but recommended)
   - [ ] I have developed this patch against the `master` branch.
   - [ ] I have run `./gradlew check`.
   - [ ] I have added tests for my changes.
   - [ ] I have added documentation for the [Ref 
Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) 
(for Solr changes only).
   



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



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

[jira] [Created] (SOLR-14945) Improve compressed HTTP responses handling in SolrJ

2020-10-18 Thread Jira 
Samuel García Martínez created SOLR-14945:
-

 Summary: Improve compressed HTTP responses handling in SolrJ
 Key: SOLR-14945
 URL: https://issues.apache.org/jira/browse/SOLR-14945
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrJ
Reporter: Samuel García Martínez


After upgrading Jetty version to 9.4.32.v20200930 the suite 
BasicHttpSolrClientTest started to fail because of how the 
compression/decompression is handled on the client side.

Jetty changed its behaviour with this upgrade as part of the so for empty 
responses (Content-Length: 0) with Accept-Encoding: gzip it's still returning a 
Content-Encoding: gzip but with no gzip header bytes in the response.

Jetty's relevant issue: https://github.com/eclipse/jetty.project/issues/4824
Jetty's relevant code changes: 
https://github.com/eclipse/jetty.project/commit/d58da0f7d2e30c732f52a38feaba2974e299bf70#diff-e175032f6f83c7d41fb7bc1a66187f5aR232

Interceptors should be removed and BasicHttpSolrClient should use Apache 
HttpClient's provided processors decompress the HTTP responses.



--
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] samuelgmartinez opened a new pull request #2003: SOLR-14844: Upgrade Jetty to 9.4.32.v20200930

2020-10-18 Thread GitBox 


samuelgmartinez opened a new pull request #2003:
URL: https://github.com/apache/lucene-solr/pull/2003


   
   
   
   # Description
   
   Upgrades Jetty to 9.4.32.v20200930 as described in JIRA ticket.
   
   # Solution
   
   After upgrading the compression related tests started to fail, so some of 
the broken unit tests were modified also. The reasons behind the broken unit 
tests are described in the original ticket.
   
   Also, created SOLR-14945 to track the need to improve HttpSolrClient 
compression handling to avoid problems like this in the future.
   
   # Tests
   
   BasicHttpSolrClientTest had to be modified in order to match Jetty's new 
behaviour for empty responses.
   
   # Checklist
   
   Please review the following and check all that apply:
   
   - [ ] I have reviewed the guidelines for [How to 
Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms 
to the standards described there to the best of my ability.
   - [ ] I have created a Jira issue and added the issue ID to my pull request 
title.
   - [ ] I have given Solr maintainers 
[access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork)
 to contribute to my PR branch. (optional but recommended)
   - [ ] I have developed this patch against the `master` branch.
   - [ ] I have run `./gradlew check`.
   - [ ] I have added tests for my changes.
   - [ ] I have added documentation for the [Ref 
Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) 
(for Solr changes only).
   



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



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

[jira] [Commented] (SOLR-14935) Solr can forward request ( remoteQuery ) even if there are local cores present

2020-10-18 Thread Shawn Heisey (Jira) 


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

Shawn Heisey commented on SOLR-14935:
-

Are you using preferLocalShards=true on the request?  Are you finding that it 
ALWAYS picks a remote replica in this situation and doesn't even consider the 
local one?

> Solr can forward request ( remoteQuery ) even if there are local cores present
> --
>
> Key: SOLR-14935
> URL: https://issues.apache.org/jira/browse/SOLR-14935
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Priority: Major
>
> Noticed an odd interaction where search queries are being proxied ( treated 
> as remoteQuery ) even when there are cores from that alias on the querying 
> node
>  * Running Solr 7.7.3 and querying via CloudSolrClient
>  * We use aliases and query with the alias name in CloudSolrClient
>  * CloudSolrClient creates a list of all replicas from the alias ( after 
> resolving it ) and then shuffles the list picking one Solr node to query 
> against
>  * When Solr receives the request, it only looks at the first collection from 
> the alias and tries to find a local core
>  * Anytime that isn't the case, it makes a remoteQuery ,  proxying the 
> request to machineX which has a local core of the first collection from the 
> alias.
>  
> I think we can make Solr check against all collections in the alias to see if 
> there is a local node present without performance implications.



--
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-14844) Upgrade Jetty to 9.4.32.v20200930

2020-10-18 Thread Jira 


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

Samuel García Martínez commented on SOLR-14844:
---

While researching why doesn't fail for master branch I realised that Jetty is 
no longer returning the Content-Encoding: gzip header for the empty response.

{code:java}
curl -H 'Accept-Encoding:gzip'  - 
'http://127.0.0.1:58633/solr/debug/foo/select?q=test'
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 58633 (#0)
> GET /solr/debug/foo/select?q=test HTTP/1.1
> Host: 127.0.0.1:58633
> User-Agent: curl/7.64.1
> Accept: */*
> Accept-Encoding:gzip
>
< HTTP/1.1 200 OK
< Date: Sun, 18 Oct 2020 21:21:18 GMT
< Vary: Accept-Encoding, User-Agent
< Content-Length: 0
< Server: Jetty(9.4.32.v20200930)
<
* Connection #0 to host 127.0.0.1 left intact
* Closing connection 0
{code}

I'm still digging on why Jetty's bahviour changes even when the version is 
exactly the same.


> Upgrade Jetty to 9.4.32.v20200930
> -
>
> Key: SOLR-14844
> URL: https://issues.apache.org/jira/browse/SOLR-14844
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 8.6
>Reporter: Cassandra Targett
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-14844-master.patch, SOLR-14884-8x.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> A CVE was found in Jetty 9.4.27-9.4.29 that has some security scanning tools 
> raising red flags 
> ([https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17638]).
> Here's the Jetty issue: 
> [https://bugs.eclipse.org/bugs/show_bug.cgi?id=564984]. It's fixed in 
> 9.4.30+, so we should upgrade to that for 8.7
> -It has a simple mitigation (raise Jetty's responseHeaderSize to higher than 
> requestHeaderSize), but I don't know how Solr uses Jetty well enough to a) 
> know if this problem is even exploitable in Solr, or b) if the workaround 
> suggested is even possible in Solr.-
> In normal Solr installs, w/o jetty optimizations, this issue is largely 
> mitigated in 8.6.3: see SOLR-14896 (and linked bug fixes) for details.



--
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-14844) Upgrade Jetty to 9.4.32.v20200930

2020-10-18 Thread Jira 


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

Samuel García Martínez edited comment on SOLR-14844 at 10/18/20, 9:32 PM:
--

While researching why it doesn't fail for master branch I realised that Jetty 
is no longer returning the Content-Encoding: gzip header for the empty response.

{code:java}
curl -H 'Accept-Encoding:gzip'  - 
'http://127.0.0.1:58633/solr/debug/foo/select?q=test'
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 58633 (#0)
> GET /solr/debug/foo/select?q=test HTTP/1.1
> Host: 127.0.0.1:58633
> User-Agent: curl/7.64.1
> Accept: */*
> Accept-Encoding:gzip
>
< HTTP/1.1 200 OK
< Date: Sun, 18 Oct 2020 21:21:18 GMT
< Vary: Accept-Encoding, User-Agent
< Content-Length: 0
< Server: Jetty(9.4.32.v20200930)
<
* Connection #0 to host 127.0.0.1 left intact
* Closing connection 0
{code}

I'm still digging on why Jetty's bahviour changes even when the version is 
exactly the same.



was (Author: samuelgmartinez):
While researching why doesn't fail for master branch I realised that Jetty is 
no longer returning the Content-Encoding: gzip header for the empty response.

{code:java}
curl -H 'Accept-Encoding:gzip'  - 
'http://127.0.0.1:58633/solr/debug/foo/select?q=test'
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 58633 (#0)
> GET /solr/debug/foo/select?q=test HTTP/1.1
> Host: 127.0.0.1:58633
> User-Agent: curl/7.64.1
> Accept: */*
> Accept-Encoding:gzip
>
< HTTP/1.1 200 OK
< Date: Sun, 18 Oct 2020 21:21:18 GMT
< Vary: Accept-Encoding, User-Agent
< Content-Length: 0
< Server: Jetty(9.4.32.v20200930)
<
* Connection #0 to host 127.0.0.1 left intact
* Closing connection 0
{code}

I'm still digging on why Jetty's bahviour changes even when the version is 
exactly the same.


> Upgrade Jetty to 9.4.32.v20200930
> -
>
> Key: SOLR-14844
> URL: https://issues.apache.org/jira/browse/SOLR-14844
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 8.6
>Reporter: Cassandra Targett
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-14844-master.patch, SOLR-14884-8x.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> A CVE was found in Jetty 9.4.27-9.4.29 that has some security scanning tools 
> raising red flags 
> ([https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17638]).
> Here's the Jetty issue: 
> [https://bugs.eclipse.org/bugs/show_bug.cgi?id=564984]. It's fixed in 
> 9.4.30+, so we should upgrade to that for 8.7
> -It has a simple mitigation (raise Jetty's responseHeaderSize to higher than 
> requestHeaderSize), but I don't know how Solr uses Jetty well enough to a) 
> know if this problem is even exploitable in Solr, or b) if the workaround 
> suggested is even possible in Solr.-
> In normal Solr installs, w/o jetty optimizations, this issue is largely 
> mitigated in 8.6.3: see SOLR-14896 (and linked bug fixes) for details.



--
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] jtibshirani commented on a change in pull request #1948: LUCENE-9536: Optimize OrdinalMap when one segment contains all distinct values.

2020-10-18 Thread GitBox 


jtibshirani commented on a change in pull request #1948:
URL: https://github.com/apache/lucene-solr/pull/1948#discussion_r505869567



##
File path: lucene/core/src/java/org/apache/lucene/index/OrdinalMap.java
##
@@ -359,10 +375,9 @@ public long ramBytesUsed() {
   @Override
   public Collection getChildResources() {
 List resources = new ArrayList<>();
-resources.add(Accountables.namedAccountable("global ord deltas", 
globalOrdDeltas));
-resources.add(Accountables.namedAccountable("first segments", 
firstSegments));
 resources.add(Accountables.namedAccountable("segment map", segmentMap));
-// TODO: would be nice to return actual child segment deltas too, but the 
optimizations are confusing
+// TODO: would be nice to return the ordinal and segment maps too, but 
it's not straightforward
+//  because of optimizations.

Review comment:
   I think we'd need a cast here, since `LongValues` doesn't implement 
`Accountable`. Alternatively, we could consider a bigger change to have 
`LongValues` implement `Accountable`.
   
   Update: I just saw LUCENE-9387, it probably doesn't make sense to increase 
usage of `Accountable`.





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



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

[GitHub] [lucene-solr] jtibshirani commented on a change in pull request #1948: LUCENE-9536: Optimize OrdinalMap when one segment contains all distinct values.

2020-10-18 Thread GitBox 


jtibshirani commented on a change in pull request #1948:
URL: https://github.com/apache/lucene-solr/pull/1948#discussion_r505869567



##
File path: lucene/core/src/java/org/apache/lucene/index/OrdinalMap.java
##
@@ -359,10 +375,9 @@ public long ramBytesUsed() {
   @Override
   public Collection getChildResources() {
 List resources = new ArrayList<>();
-resources.add(Accountables.namedAccountable("global ord deltas", 
globalOrdDeltas));
-resources.add(Accountables.namedAccountable("first segments", 
firstSegments));
 resources.add(Accountables.namedAccountable("segment map", segmentMap));
-// TODO: would be nice to return actual child segment deltas too, but the 
optimizations are confusing
+// TODO: would be nice to return the ordinal and segment maps too, but 
it's not straightforward
+//  because of optimizations.

Review comment:
   I think we'd need a cast here, since `LongValues` doesn't implement 
`Accountable`. Alternatively, we could consider a bigger change to have 
`LongValues` implement `Accountable`.
   
   Update: I just saw LUCENE-9387, so it probably doesn't make sense to 
increase usage of `Accountable`.





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



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

[GitHub] [lucene-solr] epugh commented on pull request #2002: SOLR Mark only @deprecated tag, not @Deprecated annotation

2020-10-18 Thread GitBox 


epugh commented on pull request #2002:
URL: https://github.com/apache/lucene-solr/pull/2002#issuecomment-711435155


   Would it be possible to have those depredations have a link to the NEW home 
of these projects?   So the person who sees the tag knows where to go to?   



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



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