[jira] [Commented] (SOLR-14781) Remove unused classes
[ https://issues.apache.org/jira/browse/SOLR-14781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17239892#comment-17239892 ] David Smiley commented on SOLR-14781: - I'm super pleased you will take this up [~najlak] :-) Consider me a mentor for any guidance you may need. Yes, "removing classes and running tests". > Remove unused classes > - > > Key: SOLR-14781 > URL: https://issues.apache.org/jira/browse/SOLR-14781 > Project: Solr > Issue Type: Improvement >Reporter: David Smiley >Priority: Minor > Labels: newdev > Attachments: unused.xml > > > There are a number of lingering classes in Solr that are not used anymore, > lingering after long-gone refactorings or who knows what. They should be > removed, of course. -- 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-14781) Remove unused classes
[ https://issues.apache.org/jira/browse/SOLR-14781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17239889#comment-17239889 ] Najeeb Lakhani edited comment on SOLR-14781 at 11/28/20, 5:17 AM: -- [~dsmiley] Hey I am a new developer looking to contribute. I have been "search"-ing for a ticket to work on and this feels like a good fit. Seems like removing the classes and running tests is the work that needs to be done? was (Author: najlak): [~dsmiley] Hey I am a new developer looking to contribute. I have been looking for a ticket to work on and this feels like a good fit. Seems like removing the classes and running tests is the work that needs to be done? > Remove unused classes > - > > Key: SOLR-14781 > URL: https://issues.apache.org/jira/browse/SOLR-14781 > Project: Solr > Issue Type: Improvement >Reporter: David Smiley >Priority: Minor > Labels: newdev > Attachments: unused.xml > > > There are a number of lingering classes in Solr that are not used anymore, > lingering after long-gone refactorings or who knows what. They should be > removed, of course. -- 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-14781) Remove unused classes
[ https://issues.apache.org/jira/browse/SOLR-14781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17239889#comment-17239889 ] Najeeb Lakhani commented on SOLR-14781: --- [~dsmiley] Hey I am a new developer looking to contribute. I have been looking for a ticket to work on and this feels like a good fit. Seems like removing the classes and running tests is the work that needs to be done? > Remove unused classes > - > > Key: SOLR-14781 > URL: https://issues.apache.org/jira/browse/SOLR-14781 > Project: Solr > Issue Type: Improvement >Reporter: David Smiley >Priority: Minor > Labels: newdev > Attachments: unused.xml > > > There are a number of lingering classes in Solr that are not used anymore, > lingering after long-gone refactorings or who knows what. They should be > removed, of course. -- 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] janhoy opened a new pull request #2103: Reconcile upgrade notes in master
janhoy opened a new pull request #2103: URL: https://github.com/apache/lucene-solr/pull/2103 The upgrade notes in ref-guide tends to sometimes be updated in 8.x branches only and not synced to master branch. This is an attempt, inspired by and fixes #2102 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] [Resolved] (SOLR-14915) Prometheus-exporter should not depend on Solr-core
[ https://issues.apache.org/jira/browse/SOLR-14915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley resolved SOLR-14915. - Fix Version/s: master (9.0) Resolution: Fixed > Prometheus-exporter should not depend on Solr-core > -- > > Key: SOLR-14915 > URL: https://issues.apache.org/jira/browse/SOLR-14915 > Project: Solr > Issue Type: Improvement > Components: contrib - prometheus-exporter >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Fix For: master (9.0) > > Attachments: patch.patch > > Time Spent: 2.5h > Remaining Estimate: 0h > > I think it's *crazy* that our Prometheus exporter depends on Solr-core -- > this thing is a _client_ of Solr; it does not live within Solr. The exporter > ought to be fairly lean. One consequence of this dependency is that, for > example, security vulnerabilities reported against Solr (e.g. Jetty) can (and > do, where I work) wind up being reported against this module even though > Prometheus isn't using Jetty. > From my evaluation today of what's going on, it appears the crux of the > problem is that the prometheus exporter uses some utility mechanisms in > Solr-core like XmlConfig (which depends on SolrResourceLoader and the rabbit > hole goes deeper...) and DOMUtils (further depends on PropertiesUtil). It > can easy be made to not use XmlConfig. DOMUtils & PropertiesUtil could move > to SolrJ which already has lots of little dependency-free utilities needed by > SolrJ and Solr-core alike. -- 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-14915) Prometheus-exporter should not depend on Solr-core
[ https://issues.apache.org/jira/browse/SOLR-14915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17239832#comment-17239832 ] ASF subversion and git services commented on SOLR-14915: Commit 021de9f45f56259b3d1461595bc6530189255a2a in lucene-solr's branch refs/heads/master from David Smiley [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=021de9f ] SOLR-14915: Prometheus-exporter should not depend on Solr-core (#1972) * Reduced dependencies from Solr server down to just SolrJ. Don't add WEB-INF/lib. * Was missing some dependencies in lib/; now has all except SolrJ & logging. * Can run via gradle, "gradlew run" * Has own log4j2.xml now Has own CHANGES.md now. > Prometheus-exporter should not depend on Solr-core > -- > > Key: SOLR-14915 > URL: https://issues.apache.org/jira/browse/SOLR-14915 > Project: Solr > Issue Type: Improvement > Components: contrib - prometheus-exporter >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Attachments: patch.patch > > Time Spent: 2h 20m > Remaining Estimate: 0h > > I think it's *crazy* that our Prometheus exporter depends on Solr-core -- > this thing is a _client_ of Solr; it does not live within Solr. The exporter > ought to be fairly lean. One consequence of this dependency is that, for > example, security vulnerabilities reported against Solr (e.g. Jetty) can (and > do, where I work) wind up being reported against this module even though > Prometheus isn't using Jetty. > From my evaluation today of what's going on, it appears the crux of the > problem is that the prometheus exporter uses some utility mechanisms in > Solr-core like XmlConfig (which depends on SolrResourceLoader and the rabbit > hole goes deeper...) and DOMUtils (further depends on PropertiesUtil). It > can easy be made to not use XmlConfig. DOMUtils & PropertiesUtil could move > to SolrJ which already has lots of little dependency-free utilities needed by > SolrJ and Solr-core alike. -- 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] dsmiley merged pull request #1972: SOLR-14915: Prometheus-exporter does not depend on Solr-core any longer
dsmiley merged pull request #1972: URL: https://github.com/apache/lucene-solr/pull/1972 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] [Resolved] (SOLR-15001) Docker: require init_var_solr.sh; don't init in Dockerfile
[ https://issues.apache.org/jira/browse/SOLR-15001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley resolved SOLR-15001. - Fix Version/s: master (9.0) Resolution: Fixed > Docker: require init_var_solr.sh; don't init in Dockerfile > -- > > Key: SOLR-15001 > URL: https://issues.apache.org/jira/browse/SOLR-15001 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Docker >Reporter: David Smiley >Assignee: David Smiley >Priority: Major > Fix For: master (9.0) > > Time Spent: 1h 10m > Remaining Estimate: 0h > > I propose removing initialization of /var/solr from the Dockerfile, thus > leaving only init_var_solr to do this. The fact that it's in two places means > that the image has two solr.xml, two zoo.cfg, two log4j2.xml. This > initialization itself must be maintained twice. That leads to confusion (it > did with my colleagues and I) about which copy is going to be used. Imagine > you are basing your company Solr Dockerfile on top of this one (i.e. official > is the FROM) and need to do modifications. Do you modify > /opt/solr/server/solr/solr.xml? Surprise surprise, sometimes it is copied to > /var/solr/data/ by the init_var_solr script but _sometimes_ it isn't because > the Dockerfile here will do it, thus ignoring the customizations made to > solr.xml in the next image layer. > After making this change, our wonderful tests exposed that solr-demo wasn't > invoking init_var_solr. > THIS ISSUE IS COPIED FROM https://github.com/docker-solr/docker-solr/pull/354 -- 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-15001) Docker: require init_var_solr.sh; don't init in Dockerfile
[ https://issues.apache.org/jira/browse/SOLR-15001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17239828#comment-17239828 ] ASF subversion and git services commented on SOLR-15001: Commit 1e0ae2fb74884aa1813e69813f30a972afe55885 in lucene-solr's branch refs/heads/master from David Smiley [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1e0ae2f ] SOLR-15001 Docker: require init_var_solr.sh (#2083) The Dockerfile should not initialize /var/solr's contents because this is confusing and redundant with init_var_solr.sh. No need for init_var_solr.sh to echo what it does; VERBOSE can be used to accomplish that. Separate CHANGES.md for Docker and contrib modules. > Docker: require init_var_solr.sh; don't init in Dockerfile > -- > > Key: SOLR-15001 > URL: https://issues.apache.org/jira/browse/SOLR-15001 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Docker >Reporter: David Smiley >Assignee: David Smiley >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > I propose removing initialization of /var/solr from the Dockerfile, thus > leaving only init_var_solr to do this. The fact that it's in two places means > that the image has two solr.xml, two zoo.cfg, two log4j2.xml. This > initialization itself must be maintained twice. That leads to confusion (it > did with my colleagues and I) about which copy is going to be used. Imagine > you are basing your company Solr Dockerfile on top of this one (i.e. official > is the FROM) and need to do modifications. Do you modify > /opt/solr/server/solr/solr.xml? Surprise surprise, sometimes it is copied to > /var/solr/data/ by the init_var_solr script but _sometimes_ it isn't because > the Dockerfile here will do it, thus ignoring the customizations made to > solr.xml in the next image layer. > After making this change, our wonderful tests exposed that solr-demo wasn't > invoking init_var_solr. > THIS ISSUE IS COPIED FROM https://github.com/docker-solr/docker-solr/pull/354 -- 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] dsmiley merged pull request #2083: SOLR-15001 Docker: require init_var_solr.sh
dsmiley merged pull request #2083: URL: https://github.com/apache/lucene-solr/pull/2083 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] msfroh commented on pull request #2088: LUCENE-9617: Reset lowestUnassignedFieldNumber in FieldNumbers.clear()
msfroh commented on pull request #2088: URL: https://github.com/apache/lucene-solr/pull/2088#issuecomment-734951667 > Well, that is spooky -- this looks like a pre-existing bug in `IndexWriter`'s `abort`! But I don't think we must fix that before committing this fix? Can you open a new issue for it? https://issues.apache.org/jira/browse/LUCENE-9621 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-9621) pendingNumDocs doesn't match totalMaxDoc if tragedy on flush()
[
https://issues.apache.org/jira/browse/LUCENE-9621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Froh updated LUCENE-9621:
-
Description:
While implementing a test to trigger an OutOfMemoryError on flush() in
https://github.com/apache/lucene-solr/pull/2088, I noticed that the OOME was
followed by an assertion failure on rollback with the following stacktrace:
{{java.lang.AssertionError: pendingNumDocs 1 != 0 totalMaxDoc
at
__randomizedtesting.SeedInfo.seed([ABBF17C4E0FCDEE5:DDC8E99910AFC8FF]:0)
at
org.apache.lucene.index.IndexWriter.rollbackInternal(IndexWriter.java:2398)
at
org.apache.lucene.index.IndexWriter.maybeCloseOnTragicEvent(IndexWriter.java:5196)
at
org.apache.lucene.index.IndexWriter.tragicEvent(IndexWriter.java:5186)
at org.apache.lucene.index.IndexWriter.doFlush(IndexWriter.java:3932)
at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:3874)
at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:3853)
at
org.apache.lucene.index.TestIndexWriterDelete.testDeleteAllRepeated(TestIndexWriterDelete.java:496)}}
We should probably look into how exactly we behave with this kind of tragedy on
flush().
was:
While implementing a test to trigger an OutOfMemoryError on flush() in
https://github.com/apache/lucene-solr/pull/2088, I noticed that the OOME was
followed by an assertion failure on rollback with the following stacktrace:
{{
java.lang.AssertionError: pendingNumDocs 1 != 0 totalMaxDoc
at
__randomizedtesting.SeedInfo.seed([ABBF17C4E0FCDEE5:DDC8E99910AFC8FF]:0)
at
org.apache.lucene.index.IndexWriter.rollbackInternal(IndexWriter.java:2398)
at
org.apache.lucene.index.IndexWriter.maybeCloseOnTragicEvent(IndexWriter.java:5196)
at
org.apache.lucene.index.IndexWriter.tragicEvent(IndexWriter.java:5186)
at org.apache.lucene.index.IndexWriter.doFlush(IndexWriter.java:3932)
at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:3874)
at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:3853)
at
org.apache.lucene.index.TestIndexWriterDelete.testDeleteAllRepeated(TestIndexWriterDelete.java:496)
}}
We should probably look into how exactly we behave with this kind of tragedy on
flush().
> pendingNumDocs doesn't match totalMaxDoc if tragedy on flush()
> --
>
> Key: LUCENE-9621
> URL: https://issues.apache.org/jira/browse/LUCENE-9621
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/index
>Affects Versions: 8.6.3
>Reporter: Michael Froh
>Priority: Major
>
> While implementing a test to trigger an OutOfMemoryError on flush() in
> https://github.com/apache/lucene-solr/pull/2088, I noticed that the OOME was
> followed by an assertion failure on rollback with the following stacktrace:
> {{java.lang.AssertionError: pendingNumDocs 1 != 0 totalMaxDoc
> at
> __randomizedtesting.SeedInfo.seed([ABBF17C4E0FCDEE5:DDC8E99910AFC8FF]:0)
> at
> org.apache.lucene.index.IndexWriter.rollbackInternal(IndexWriter.java:2398)
> at
> org.apache.lucene.index.IndexWriter.maybeCloseOnTragicEvent(IndexWriter.java:5196)
> at
> org.apache.lucene.index.IndexWriter.tragicEvent(IndexWriter.java:5186)
> at org.apache.lucene.index.IndexWriter.doFlush(IndexWriter.java:3932)
> at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:3874)
> at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:3853)
> at
> org.apache.lucene.index.TestIndexWriterDelete.testDeleteAllRepeated(TestIndexWriterDelete.java:496)}}
> We should probably look into how exactly we behave with this kind of tragedy
> on flush().
--
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-9621) pendingNumDocs doesn't match totalMaxDoc if tragedy on flush()
[
https://issues.apache.org/jira/browse/LUCENE-9621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Froh updated LUCENE-9621:
-
Description:
While implementing a test to trigger an OutOfMemoryError on flush() in
https://github.com/apache/lucene-solr/pull/2088, I noticed that the OOME was
followed by an assertion failure on rollback with the following stacktrace:
{code:java}
java.lang.AssertionError: pendingNumDocs 1 != 0 totalMaxDoc
at
__randomizedtesting.SeedInfo.seed([ABBF17C4E0FCDEE5:DDC8E99910AFC8FF]:0)
at
org.apache.lucene.index.IndexWriter.rollbackInternal(IndexWriter.java:2398)
at
org.apache.lucene.index.IndexWriter.maybeCloseOnTragicEvent(IndexWriter.java:5196)
at
org.apache.lucene.index.IndexWriter.tragicEvent(IndexWriter.java:5186)
at org.apache.lucene.index.IndexWriter.doFlush(IndexWriter.java:3932)
at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:3874)
at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:3853)
at
org.apache.lucene.index.TestIndexWriterDelete.testDeleteAllRepeated(TestIndexWriterDelete.java:496)
{code}
We should probably look into how exactly we behave with this kind of tragedy on
flush().
was:
While implementing a test to trigger an OutOfMemoryError on flush() in
https://github.com/apache/lucene-solr/pull/2088, I noticed that the OOME was
followed by an assertion failure on rollback with the following stacktrace:
{{java.lang.AssertionError: pendingNumDocs 1 != 0 totalMaxDoc
at
__randomizedtesting.SeedInfo.seed([ABBF17C4E0FCDEE5:DDC8E99910AFC8FF]:0)
at
org.apache.lucene.index.IndexWriter.rollbackInternal(IndexWriter.java:2398)
at
org.apache.lucene.index.IndexWriter.maybeCloseOnTragicEvent(IndexWriter.java:5196)
at
org.apache.lucene.index.IndexWriter.tragicEvent(IndexWriter.java:5186)
at org.apache.lucene.index.IndexWriter.doFlush(IndexWriter.java:3932)
at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:3874)
at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:3853)
at
org.apache.lucene.index.TestIndexWriterDelete.testDeleteAllRepeated(TestIndexWriterDelete.java:496)}}
We should probably look into how exactly we behave with this kind of tragedy on
flush().
> pendingNumDocs doesn't match totalMaxDoc if tragedy on flush()
> --
>
> Key: LUCENE-9621
> URL: https://issues.apache.org/jira/browse/LUCENE-9621
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/index
>Affects Versions: 8.6.3
>Reporter: Michael Froh
>Priority: Major
>
> While implementing a test to trigger an OutOfMemoryError on flush() in
> https://github.com/apache/lucene-solr/pull/2088, I noticed that the OOME was
> followed by an assertion failure on rollback with the following stacktrace:
> {code:java}
> java.lang.AssertionError: pendingNumDocs 1 != 0 totalMaxDoc
> at
> __randomizedtesting.SeedInfo.seed([ABBF17C4E0FCDEE5:DDC8E99910AFC8FF]:0)
> at
> org.apache.lucene.index.IndexWriter.rollbackInternal(IndexWriter.java:2398)
> at
> org.apache.lucene.index.IndexWriter.maybeCloseOnTragicEvent(IndexWriter.java:5196)
> at
> org.apache.lucene.index.IndexWriter.tragicEvent(IndexWriter.java:5186)
> at org.apache.lucene.index.IndexWriter.doFlush(IndexWriter.java:3932)
> at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:3874)
> at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:3853)
> at
> org.apache.lucene.index.TestIndexWriterDelete.testDeleteAllRepeated(TestIndexWriterDelete.java:496)
> {code}
> We should probably look into how exactly we behave with this kind of tragedy
> on flush().
--
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-9621) pendingNumDocs doesn't match totalMaxDoc if tragedy on flush()
Michael Froh created LUCENE-9621:
Summary: pendingNumDocs doesn't match totalMaxDoc if tragedy on
flush()
Key: LUCENE-9621
URL: https://issues.apache.org/jira/browse/LUCENE-9621
Project: Lucene - Core
Issue Type: Bug
Components: core/index
Affects Versions: 8.6.3
Reporter: Michael Froh
While implementing a test to trigger an OutOfMemoryError on flush() in
https://github.com/apache/lucene-solr/pull/2088, I noticed that the OOME was
followed by an assertion failure on rollback with the following stacktrace:
{{
java.lang.AssertionError: pendingNumDocs 1 != 0 totalMaxDoc
at
__randomizedtesting.SeedInfo.seed([ABBF17C4E0FCDEE5:DDC8E99910AFC8FF]:0)
at
org.apache.lucene.index.IndexWriter.rollbackInternal(IndexWriter.java:2398)
at
org.apache.lucene.index.IndexWriter.maybeCloseOnTragicEvent(IndexWriter.java:5196)
at
org.apache.lucene.index.IndexWriter.tragicEvent(IndexWriter.java:5186)
at org.apache.lucene.index.IndexWriter.doFlush(IndexWriter.java:3932)
at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:3874)
at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:3853)
at
org.apache.lucene.index.TestIndexWriterDelete.testDeleteAllRepeated(TestIndexWriterDelete.java:496)
}}
We should probably look into how exactly we behave with this kind of tragedy on
flush().
--
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] sarcanon opened a new pull request #2102: SOLR-14977: Fix typo in solr-upgrade-notes.adoc
sarcanon opened a new pull request #2102: URL: https://github.com/apache/lucene-solr/pull/2102 # Description Fixed small typo in release notes. Should refer to 8.7, not 8.6.x. 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-15021) Fix Typo in 8.7 Release Notes
Scott Vanderbilt created SOLR-15021: --- Summary: Fix Typo in 8.7 Release Notes Key: SOLR-15021 URL: https://issues.apache.org/jira/browse/SOLR-15021 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: documentation Affects Versions: 8.7 Reporter: Scott Vanderbilt Line 46 should refer to 8.7, not 8.6.x: -- 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-15020) Fix Typo in 8.7 Release Notes
Scott Vanderbilt created SOLR-15020: --- Summary: Fix Typo in 8.7 Release Notes Key: SOLR-15020 URL: https://issues.apache.org/jira/browse/SOLR-15020 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: documentation Affects Versions: 8.7 Reporter: Scott Vanderbilt Line 46 should refer to 8.7, not 8.6.x: -- 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-14851) Http2SolrClient doesn't handle keystore type correctly
[
https://issues.apache.org/jira/browse/SOLR-14851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-14851:
---
Fix Version/s: 8.8
Assignee: Jan Høydahl (was: Kevin Risden)
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Http2SolrClient doesn't handle keystore type correctly
> --
>
> Key: SOLR-14851
> URL: https://issues.apache.org/jira/browse/SOLR-14851
> Project: Solr
> Issue Type: Bug
> Components: Server
>Reporter: Andras Salamon
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.8
>
> Attachments: SOLR-14851-01.patch, SOLR-14851-02.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I wanted to use Solr SSL using bcfks keystore type. Even after specifying the
> following JVM properties, Solr was not able to start:
> {{-Djavax.net.ssl.keyStoreType=bcfks -Djavax.net.ssl.trustStoreType=bcfks
> -Dsolr.jetty.truststore.type=bcfks -Dsolr.jetty.keystore.type=bcfks}}
> The error message in the log:
> {noformat}2020-09-07 14:42:29.429 ERROR (main) [ ] o.a.s.c.SolrCore
> null:org.apache.solr.common.SolrException: Error instantiating
> shardHandlerFactory class [HttpShardHandlerFactory]: java.io.IOException:
> Invalid keystore format
> at
> org.apache.solr.handler.component.ShardHandlerFactory.newInstance(ShardHandlerFactory.java:56)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:660)
> at
> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:262)
> at
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:182)
> at
> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:134)
> at
> org.eclipse.jetty.servlet.ServletHandler.lambda$initialize$0(ServletHandler.java:751)
> at
> java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at
> java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:742)
> at
> java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:742)
> at
> java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:647)
> at
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:744)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:360)
> at
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1445)
> at
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1409)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:822)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:275)
> at
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:524)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:46)
> at
> org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:188)
> at
> org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:513)
> at
> org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:154)
> at
> org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:173)
> at
> org.eclipse.jetty.deploy.providers.WebAppProvider.fileAdded(WebAppProvider.java:447)
> at
> org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:66)
> at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:784)
> at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:753)
> at org.eclipse.jetty.util.Scanner.scan(Scanner.java:641)
> at org.eclipse.jetty.util.Scanner.doStart(Scanner.java:540)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(ScanningAppProvider.java:146)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.deploy.DeploymentManager.startAppProvider(DeploymentManager.java:599)
> at
> org.eclipse.jetty.deploy.DeploymentManager.doStart(DeploymentManager.java:249)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at org.eclipse.jetty.server.Server.start(Server.java:407)
> at
[jira] [Commented] (SOLR-14851) Http2SolrClient doesn't handle keystore type correctly
[
https://issues.apache.org/jira/browse/SOLR-14851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17239729#comment-17239729
]
ASF subversion and git services commented on SOLR-14851:
Commit 2ae48c4c42e35d549fe1aed8b1c624330f67830d in lucene-solr's branch
refs/heads/branch_8x from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2ae48c4 ]
SOLR-14851 Http2SolrClient doesn't handle keystore type (#2098)
Signed-off-by: Jan Høydahl
Co-authored-by: Andras Salamon
(cherry picked from commit 99c38eee491aee637abd1761015e51783cb4ba01)
> Http2SolrClient doesn't handle keystore type correctly
> --
>
> Key: SOLR-14851
> URL: https://issues.apache.org/jira/browse/SOLR-14851
> Project: Solr
> Issue Type: Bug
> Components: Server
>Reporter: Andras Salamon
>Assignee: Kevin Risden
>Priority: Major
> Attachments: SOLR-14851-01.patch, SOLR-14851-02.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I wanted to use Solr SSL using bcfks keystore type. Even after specifying the
> following JVM properties, Solr was not able to start:
> {{-Djavax.net.ssl.keyStoreType=bcfks -Djavax.net.ssl.trustStoreType=bcfks
> -Dsolr.jetty.truststore.type=bcfks -Dsolr.jetty.keystore.type=bcfks}}
> The error message in the log:
> {noformat}2020-09-07 14:42:29.429 ERROR (main) [ ] o.a.s.c.SolrCore
> null:org.apache.solr.common.SolrException: Error instantiating
> shardHandlerFactory class [HttpShardHandlerFactory]: java.io.IOException:
> Invalid keystore format
> at
> org.apache.solr.handler.component.ShardHandlerFactory.newInstance(ShardHandlerFactory.java:56)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:660)
> at
> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:262)
> at
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:182)
> at
> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:134)
> at
> org.eclipse.jetty.servlet.ServletHandler.lambda$initialize$0(ServletHandler.java:751)
> at
> java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at
> java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:742)
> at
> java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:742)
> at
> java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:647)
> at
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:744)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:360)
> at
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1445)
> at
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1409)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:822)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:275)
> at
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:524)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:46)
> at
> org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:188)
> at
> org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:513)
> at
> org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:154)
> at
> org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:173)
> at
> org.eclipse.jetty.deploy.providers.WebAppProvider.fileAdded(WebAppProvider.java:447)
> at
> org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:66)
> at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:784)
> at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:753)
> at org.eclipse.jetty.util.Scanner.scan(Scanner.java:641)
> at org.eclipse.jetty.util.Scanner.doStart(Scanner.java:540)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(ScanningAppProvider.java:146)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.deploy.DeploymentManager.startAppProvider(DeploymentManager.java:599)
> at
> org.eclipse.jetty.deploy.DeploymentManager.doStart(DeploymentManager.ja
[GitHub] [lucene-solr] mikemccand commented on pull request #2088: LUCENE-9617: Reset lowestUnassignedFieldNumber in FieldNumbers.clear()
mikemccand commented on pull request #2088: URL: https://github.com/apache/lucene-solr/pull/2088#issuecomment-734887851 > Curiously, the test wasn't failing on the OOME itself, but rather we fail an assertion when trying to rollback on tragedy (where the tragedy was the OOME). Here's that stack trace: Well, that is spooky -- this looks like a pre-existing bug in `IndexWriter`'s `abort`! But I don't think we must fix that before committing this fix? Can you open a new issue for it? 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-14851) Http2SolrClient doesn't handle keystore type correctly
[
https://issues.apache.org/jira/browse/SOLR-14851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17239722#comment-17239722
]
ASF subversion and git services commented on SOLR-14851:
Commit 99c38eee491aee637abd1761015e51783cb4ba01 in lucene-solr's branch
refs/heads/master from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=99c38ee ]
SOLR-14851 Http2SolrClient doesn't handle keystore type (#2098)
Signed-off-by: Jan Høydahl
Co-authored-by: Andras Salamon
> Http2SolrClient doesn't handle keystore type correctly
> --
>
> Key: SOLR-14851
> URL: https://issues.apache.org/jira/browse/SOLR-14851
> Project: Solr
> Issue Type: Bug
> Components: Server
>Reporter: Andras Salamon
>Assignee: Kevin Risden
>Priority: Major
> Attachments: SOLR-14851-01.patch, SOLR-14851-02.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I wanted to use Solr SSL using bcfks keystore type. Even after specifying the
> following JVM properties, Solr was not able to start:
> {{-Djavax.net.ssl.keyStoreType=bcfks -Djavax.net.ssl.trustStoreType=bcfks
> -Dsolr.jetty.truststore.type=bcfks -Dsolr.jetty.keystore.type=bcfks}}
> The error message in the log:
> {noformat}2020-09-07 14:42:29.429 ERROR (main) [ ] o.a.s.c.SolrCore
> null:org.apache.solr.common.SolrException: Error instantiating
> shardHandlerFactory class [HttpShardHandlerFactory]: java.io.IOException:
> Invalid keystore format
> at
> org.apache.solr.handler.component.ShardHandlerFactory.newInstance(ShardHandlerFactory.java:56)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:660)
> at
> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:262)
> at
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:182)
> at
> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:134)
> at
> org.eclipse.jetty.servlet.ServletHandler.lambda$initialize$0(ServletHandler.java:751)
> at
> java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at
> java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:742)
> at
> java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:742)
> at
> java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:647)
> at
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:744)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:360)
> at
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1445)
> at
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1409)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:822)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:275)
> at
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:524)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:46)
> at
> org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:188)
> at
> org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:513)
> at
> org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:154)
> at
> org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:173)
> at
> org.eclipse.jetty.deploy.providers.WebAppProvider.fileAdded(WebAppProvider.java:447)
> at
> org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:66)
> at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:784)
> at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:753)
> at org.eclipse.jetty.util.Scanner.scan(Scanner.java:641)
> at org.eclipse.jetty.util.Scanner.doStart(Scanner.java:540)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(ScanningAppProvider.java:146)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.deploy.DeploymentManager.startAppProvider(DeploymentManager.java:599)
> at
> org.eclipse.jetty.deploy.DeploymentManager.doStart(DeploymentManager.java:249)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycl
[GitHub] [lucene-solr] janhoy merged pull request #2098: SOLR-14851 Http2SolrClient doesn't handle keystore type
janhoy merged pull request #2098: URL: https://github.com/apache/lucene-solr/pull/2098 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] muse-dev[bot] commented on a change in pull request #2101: SOLR-15016 Replica placement plugins should use container plugins API / configs
muse-dev[bot] commented on a change in pull request #2101:
URL: https://github.com/apache/lucene-solr/pull/2101#discussion_r531588535
##
File path:
solr/core/src/java/org/apache/solr/cluster/placement/plugins/AffinityPlacementFactory.java
##
@@ -0,0 +1,537 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.cluster.placement.plugins;
+
+import com.google.common.annotations.VisibleForTesting;
+import com.google.common.collect.Ordering;
+import com.google.common.collect.TreeMultimap;
+import org.apache.solr.api.ConfigurablePlugin;
+import org.apache.solr.cluster.*;
+import org.apache.solr.cluster.placement.*;
+import org.apache.solr.common.util.Pair;
+import org.apache.solr.common.util.SuppressForbidden;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import java.lang.invoke.MethodHandles;
+import java.util.*;
+import java.util.stream.Collectors;
+
+/**
+ * This factory is instantiated by config from its class name. Using it is
the only way to create instances of
+ * {@link AffinityPlacementPlugin}.
+ *
+ * In order to configure this plugin to be used for placement decisions,
the following {@code curl} command (or something
+ * equivalent) has to be executed once the cluster is already running in order
to set
+ * the appropriate Zookeeper stored configuration. Replace {@code
localhost:8983} by one of your servers' IP address and port.
+ *
+ *
+ *
+ * curl -X POST -H 'Content-type:application/json' -d '{
+ * "set-placement-plugin": {
+ * "class":
"org.apache.solr.cluster.placement.plugins.AffinityPlacementFactory",
+ * "minimalFreeDiskGB": 10,
+ * "prioritizedFreeDiskGB": 50
+ * }
+ * }' http://localhost:8983/api/cluster
+ *
+ *
+ * The consequence will be the creation of an element in the Zookeeper file
{@code /clusterprops.json} as follows:
+ *
+ *
+ *
+ * "placement-plugin":{
+ *
"class":"org.apache.solr.cluster.placement.plugins.AffinityPlacementFactory",
+ * "minimalFreeDiskGB":10,
+ * "prioritizedFreeDiskGB":50}
+ *
+ *
+ * In order to delete the placement-plugin section from {@code
/clusterprops.json} (and to fallback to either Legacy
+ * or rule based placement if configured for a collection), execute:
+ *
+ *
+ *
+ * curl -X POST -H 'Content-type:application/json' -d '{
+ * "set-placement-plugin" : null
+ * }' http://localhost:8983/api/cluster
+ *
+ *
+ *
+ * {@link AffinityPlacementPlugin} implements placing replicas in a way
that replicate past Autoscaling config defined
+ * https://github.com/lucidworks/fusion-cloud-native/blob/master/policy.json#L16";>here.
+ *
+ * This specification is doing the following:
+ * Spread replicas per shard as evenly as possible across multiple
availability zones (given by a sys prop),
+ * assign replicas based on replica type to specific kinds of nodes (another
sys prop), and avoid having more than
+ * one replica per shard on the same node.
+ * Only after these constraints are satisfied do minimize cores per node or
disk usage.
+ *
+ * Overall strategy of this plugin:
+ *
+ * The set of nodes in the cluster is obtained and transformed into 3
independent sets (that can overlap) of nodes
+ * accepting each of the three replica types.
+ *
+ * For each shard on which placing replicas is required and then for each
replica type to place (starting with NRT,
+ * then TLOG then PULL):
+ * The set of candidates nodes corresponding to the replica type
is used and from that set are removed nodes
+ * that already have a replica (of any type) for that shard
+ * If there are not enough nodes, an error is thrown (this is
checked further down during processing).
+ * The number of (already existing) replicas of the current type
on each Availability Zone is collected.
+ * Separate the set of available nodes to as many subsets
(possibly some are empty) as there are Availability Zones
+ * defined for the candidate nodes
+ * In each AZ nodes subset, sort the nodes by increasing total
number of cores count, with possibly a condition
+ * that pushes nodes with low disk space to the end of the list? Or a
weighted combination of the relative
+ * im
[GitHub] [lucene-solr] dweiss commented on pull request #2094: LUCENE-9047: Move the Directory APIs to be little endian
dweiss commented on pull request #2094: URL: https://github.com/apache/lucene-solr/pull/2094#issuecomment-734754136 I created a PR which kind of shows what I had in mind, it's here (won't compile, it's a PoC only to convey the idea). https://github.com/apache/lucene-solr/pull/2100 The byte-order data type reader is acquired from DataInput (and subclasses) with a method that takes byte order as an argument. https://github.com/apache/lucene-solr/pull/2100/files#diff-f07fa6b85566fe26f4da99bae2f7b7ab416899c7de849ec924a8ac2e51e046a0R126 This default method returns the byte-order-sensitive "typed" reader that implements delegates proper endianness and delegates to the source DataInput class. Subclasses can either reimplementing it fully if they can optimize byte-order access (as shown in ByteArrayDataInput) or can implement just one selected endianness (and the other one is provided via the wrapper). The same idea could be pulled up so that DataInput itself contains the byte-order, without any separate interface (TypedReader) but I think it's actually beneficial not to do so. In fact, a separate "typed reader" view makes it more elegant to delegate low-level methods to actual data source rather than overriding multiple methods from the superclass. This does seem like a lengthy effort but I wanted to show this to you for consideration. 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] sigram commented on pull request #2101: SOLR-15016 Replica placement plugins should use container plugins API / configs
sigram commented on pull request #2101: URL: https://github.com/apache/lucene-solr/pull/2101#issuecomment-734742963 This branch includes changes in branch `jira/solr-15004`. 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] sigram opened a new pull request #2101: SOLR-15016 Replica placement plugins should use container plugins API / configs
sigram opened a new pull request #2101: URL: https://github.com/apache/lucene-solr/pull/2101 See Jira for more details. 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 opened a new pull request #2100: LUCENE-9047: PoC of some ideas regarding transparent, efficient handling of byte order
dweiss opened a new pull request #2100: URL: https://github.com/apache/lucene-solr/pull/2100 Not for merging. 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] sigram commented on pull request #2099: SOLR-14977: improved plugin configuration
sigram commented on pull request #2099: URL: https://github.com/apache/lucene-solr/pull/2099#issuecomment-734731292 Gah, typos & autocorrect 😃 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
