[jira] [Commented] (SOLR-13289) Support for BlockMax WAND
[ https://issues.apache.org/jira/browse/SOLR-13289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17089241#comment-17089241 ] Munendra S N commented on SOLR-13289: - [~tflobbe] Sure, please go ahead > Support for BlockMax WAND > - > > Key: SOLR-13289 > URL: https://issues.apache.org/jira/browse/SOLR-13289 > Project: Solr > Issue Type: New Feature >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Major > Attachments: SOLR-13289.patch, SOLR-13289.patch > > > LUCENE-8135 introduced BlockMax WAND as a major speed improvement. Need to > expose this via Solr. When enabled, the numFound returned will not be exact. -- 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-14365) CollapsingQParser - Avoiding always allocate int[] and float[] with size equals to number of unique values
[
https://issues.apache.org/jira/browse/SOLR-14365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar resolved SOLR-14365.
--
Fix Version/s: 8.6
master (9.0)
Resolution: Fixed
> CollapsingQParser - Avoiding always allocate int[] and float[] with size
> equals to number of unique values
> --
>
> Key: SOLR-14365
> URL: https://issues.apache.org/jira/browse/SOLR-14365
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.4.1
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (9.0), 8.6
>
> Attachments: SOLR-14365.patch
>
> Time Spent: 8h 10m
> Remaining Estimate: 0h
>
> Since Collapsing is a PostFilter, documents reach Collapsing must match with
> all filters and queries, so the number of documents Collapsing need to
> collect/compute score is a small fraction of the total number documents in
> the index. So why do we need to always consume the memory (for int[] and
> float[] array) for all unique values of the collapsed field? If the number of
> unique values of the collapsed field found in the documents that match
> queries and filters is 300 then we only need int[] and float[] array with
> size of 300 and not 1.2 million in size. However, we don't know which value
> of the collapsed field will show up in the results so we cannot use a smaller
> array.
> The easy fix for this problem is using as much as we need by using IntIntMap
> and IntFloatMap that hold primitives and are much more space efficient than
> the Java HashMap. These maps can be slower (10x or 20x) than plain int[] and
> float[] if matched documents is large (almost all documents matched queries
> and other filters). But our belief is that does not happen that frequently
> (how frequently do we run collapsing on the entire index?).
> For this issue I propose adding 2 methods for collapsing which is
> * array : which is current implementation
> * hash : which is new approach and will be default method
> later we can add another method {{smart}} which is automatically pick method
> based on comparision between {{number of docs matched queries and filters}}
> and {{number of unique values of the field}}
--
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-14365) CollapsingQParser - Avoiding always allocate int[] and float[] with size equals to number of unique values
[
https://issues.apache.org/jira/browse/SOLR-14365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17089201#comment-17089201
]
ASF subversion and git services commented on SOLR-14365:
Commit 1e1ef7f074503771172218a28282494a9faa97e5 in lucene-solr's branch
refs/heads/branch_8x from Shalin Shekhar Mangar
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1e1ef7f ]
SOLR-14365: CollapsingQParser - Avoiding always allocate int[] and float[] with
size equals to number of unique values (#1395)
(cherry picked from commit adbd714b37d794e9aa7615e61c431e42162c1d3c)
(cherry picked from commit 71d335ff688982cef10a648c914623c81ced)
> CollapsingQParser - Avoiding always allocate int[] and float[] with size
> equals to number of unique values
> --
>
> Key: SOLR-14365
> URL: https://issues.apache.org/jira/browse/SOLR-14365
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.4.1
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Attachments: SOLR-14365.patch
>
> Time Spent: 8h 10m
> Remaining Estimate: 0h
>
> Since Collapsing is a PostFilter, documents reach Collapsing must match with
> all filters and queries, so the number of documents Collapsing need to
> collect/compute score is a small fraction of the total number documents in
> the index. So why do we need to always consume the memory (for int[] and
> float[] array) for all unique values of the collapsed field? If the number of
> unique values of the collapsed field found in the documents that match
> queries and filters is 300 then we only need int[] and float[] array with
> size of 300 and not 1.2 million in size. However, we don't know which value
> of the collapsed field will show up in the results so we cannot use a smaller
> array.
> The easy fix for this problem is using as much as we need by using IntIntMap
> and IntFloatMap that hold primitives and are much more space efficient than
> the Java HashMap. These maps can be slower (10x or 20x) than plain int[] and
> float[] if matched documents is large (almost all documents matched queries
> and other filters). But our belief is that does not happen that frequently
> (how frequently do we run collapsing on the entire index?).
> For this issue I propose adding 2 methods for collapsing which is
> * array : which is current implementation
> * hash : which is new approach and will be default method
> later we can add another method {{smart}} which is automatically pick method
> based on comparision between {{number of docs matched queries and filters}}
> and {{number of unique values of the field}}
--
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-14365) CollapsingQParser - Avoiding always allocate int[] and float[] with size equals to number of unique values
[
https://issues.apache.org/jira/browse/SOLR-14365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17089177#comment-17089177
]
Shalin Shekhar Mangar commented on SOLR-14365:
--
I think this is ready to be cherry picked to branch_8x. I'll do that today
unless there are any objections.
> CollapsingQParser - Avoiding always allocate int[] and float[] with size
> equals to number of unique values
> --
>
> Key: SOLR-14365
> URL: https://issues.apache.org/jira/browse/SOLR-14365
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.4.1
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Attachments: SOLR-14365.patch
>
> Time Spent: 8h 10m
> Remaining Estimate: 0h
>
> Since Collapsing is a PostFilter, documents reach Collapsing must match with
> all filters and queries, so the number of documents Collapsing need to
> collect/compute score is a small fraction of the total number documents in
> the index. So why do we need to always consume the memory (for int[] and
> float[] array) for all unique values of the collapsed field? If the number of
> unique values of the collapsed field found in the documents that match
> queries and filters is 300 then we only need int[] and float[] array with
> size of 300 and not 1.2 million in size. However, we don't know which value
> of the collapsed field will show up in the results so we cannot use a smaller
> array.
> The easy fix for this problem is using as much as we need by using IntIntMap
> and IntFloatMap that hold primitives and are much more space efficient than
> the Java HashMap. These maps can be slower (10x or 20x) than plain int[] and
> float[] if matched documents is large (almost all documents matched queries
> and other filters). But our belief is that does not happen that frequently
> (how frequently do we run collapsing on the entire index?).
> For this issue I propose adding 2 methods for collapsing which is
> * array : which is current implementation
> * hash : which is new approach and will be default method
> later we can add another method {{smart}} which is automatically pick method
> based on comparision between {{number of docs matched queries and filters}}
> and {{number of unique values of the field}}
--
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-8393) Component for Solr resource usage planning
[ https://issues.apache.org/jira/browse/SOLR-8393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17089176#comment-17089176 ] Isabelle Giguere commented on SOLR-8393: Attached patch, off current Git master. Same patch as was proposed in 2017, Solr 6.6 at the time > Component for Solr resource usage planning > -- > > Key: SOLR-8393 > URL: https://issues.apache.org/jira/browse/SOLR-8393 > Project: Solr > Issue Type: Improvement >Reporter: Steve Molloy >Priority: Major > Attachments: SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch, > SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch, > SOLR-8393.patch, SOLR-8393_tag_7.5.0.patch > > > One question that keeps coming back is how much disk and RAM do I need to run > Solr. The most common response is that it highly depends on your data. While > true, it makes for frustrated users trying to plan their deployments. > The idea I'm bringing is to create a new component that will attempt to > extrapolate resources needed in the future by looking at resources currently > used. By adding a parameter for the target number of documents, current > resources are adapted by a ratio relative to current number of documents. -- 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-14414) New Admin UI
[
https://issues.apache.org/jira/browse/SOLR-14414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17089175#comment-17089175
]
Marcus Eagan commented on SOLR-14414:
-
[~dsmiley] Awesome. Thanks for your collaborative input and thoroughness.
> New Admin UI
>
>
> Key: SOLR-14414
> URL: https://issues.apache.org/jira/browse/SOLR-14414
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Major
>
> We have had a lengthy discussion in the mailing list about the need to build
> a modern UI that is both more security and does not depend on deprecated, end
> of life code. In this ticket, I intend to familiarize the community with the
> efforts of the community to do just that that. While we are nearing feature
> parity, but not there yet as many have suggested we could complete this task
> in iterations, here is an attempt to get the ball rolling. I have mostly
> worked on it in weekend nights on the occasion that I could find the time.
> Angular is certainly not my specialty, and this is my first attempt at using
> TypeScript besides a few brief learning exercises here and there. However, I
> will be engaging experts in both of these areas for consultation as our
> community tries to pull our UI into another era.
> Many of the components here can improve. One or two them need to be
> rewritten, and there are even at least three essential components to the app
> missing, along with some tests. A couple other things missing are the V2 API,
> which I found difficult to build with in this context because it is not
> documented on the web. I understand that it is "self-documenting," but the
> most easy-to-use APIs are still documented on the web. Maybe it is entirely
> documented on the web, and I had trouble finding it. Forgive me, as that
> could be an area of assistance. Another area where I need assistance is
> packaging this application as a Solr package. I understand this app is not in
> the right place for that today, but it can be. There are still many
> improvements to be made in this Jira and certainly in this code.
> The project is located in {{lucene-solr/solr/webapp2}}, where there is a
> README for information on running the app.
> The app can be started from the this directory with {{npm start}} for now. It
> can quickly be modified to start as a part of the typical start commands as
> it approaches parity. I expect there will be a lot of opinions. I welcome
> them, of course. The community input should drive the project's success.
--
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-8393) Component for Solr resource usage planning
[ https://issues.apache.org/jira/browse/SOLR-8393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Isabelle Giguere updated SOLR-8393: --- Attachment: SOLR-8393.patch > Component for Solr resource usage planning > -- > > Key: SOLR-8393 > URL: https://issues.apache.org/jira/browse/SOLR-8393 > Project: Solr > Issue Type: Improvement >Reporter: Steve Molloy >Priority: Major > Attachments: SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch, > SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch, > SOLR-8393.patch, SOLR-8393_tag_7.5.0.patch > > > One question that keeps coming back is how much disk and RAM do I need to run > Solr. The most common response is that it highly depends on your data. While > true, it makes for frustrated users trying to plan their deployments. > The idea I'm bringing is to create a new component that will attempt to > extrapolate resources needed in the future by looking at resources currently > used. By adding a parameter for the target number of documents, current > resources are adapted by a ratio relative to current number of documents. -- 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-14414) New Admin UI
[
https://issues.apache.org/jira/browse/SOLR-14414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17089170#comment-17089170
]
David Smiley commented on SOLR-14414:
-
For the record I'm not against this new UI being developed within this
codebase, I just _prefer_ a separate project. That's all. I sense Noble is
adamant.
bq. Adding to a very heavy codebase is going to make it even more unhealthy.
I think we are talking about _replacing_ the admin UI with one that has tests
and is generally more maintainable. Thus I think we'll be in a better place
then we are today no matter where this UI lives!
bq. We need to have bug fix releases for all of them.
Unfortunately, I think this problem won't go away if the UI is a separate
project since it'd ship with Solr still. Shipping it with Solr means its bugs
become our concern as well. And there will actually be more pain on this point
because it will necessitate a new release on the dependency. Come to think of
it, I think this is enough of a pain point for me to prefer keeping the UI code
with the Solr project. But I'll be happy with either outcome. No vetoes from
me on this point!
> New Admin UI
>
>
> Key: SOLR-14414
> URL: https://issues.apache.org/jira/browse/SOLR-14414
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Major
>
> We have had a lengthy discussion in the mailing list about the need to build
> a modern UI that is both more security and does not depend on deprecated, end
> of life code. In this ticket, I intend to familiarize the community with the
> efforts of the community to do just that that. While we are nearing feature
> parity, but not there yet as many have suggested we could complete this task
> in iterations, here is an attempt to get the ball rolling. I have mostly
> worked on it in weekend nights on the occasion that I could find the time.
> Angular is certainly not my specialty, and this is my first attempt at using
> TypeScript besides a few brief learning exercises here and there. However, I
> will be engaging experts in both of these areas for consultation as our
> community tries to pull our UI into another era.
> Many of the components here can improve. One or two them need to be
> rewritten, and there are even at least three essential components to the app
> missing, along with some tests. A couple other things missing are the V2 API,
> which I found difficult to build with in this context because it is not
> documented on the web. I understand that it is "self-documenting," but the
> most easy-to-use APIs are still documented on the web. Maybe it is entirely
> documented on the web, and I had trouble finding it. Forgive me, as that
> could be an area of assistance. Another area where I need assistance is
> packaging this application as a Solr package. I understand this app is not in
> the right place for that today, but it can be. There are still many
> improvements to be made in this Jira and certainly in this code.
> The project is located in {{lucene-solr/solr/webapp2}}, where there is a
> README for information on running the app.
> The app can be started from the this directory with {{npm start}} for now. It
> can quickly be modified to start as a part of the typical start commands as
> it approaches parity. I expect there will be a lot of opinions. I welcome
> them, of course. The community input should drive the project's success.
--
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-14259) backport SOLR-14013 to Solr 7.7
[ https://issues.apache.org/jira/browse/SOLR-14259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17089150#comment-17089150 ] Anshum Gupta commented on SOLR-14259: - I really think we should never back port commits to release branches without them going through master and corresponding stable branches - of course, unless it is impossible to do so. > backport SOLR-14013 to Solr 7.7 > --- > > Key: SOLR-14259 > URL: https://issues.apache.org/jira/browse/SOLR-14259 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.7 >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Fix For: 7.7.3 > > Time Spent: 40m > Remaining Estimate: 0h > -- 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-13289) Support for BlockMax WAND
[ https://issues.apache.org/jira/browse/SOLR-13289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17089141#comment-17089141 ] Tomas Eduardo Fernandez Lobbe commented on SOLR-13289: -- I'd like to take a look at this if you are not working on it, [~munendrasn] > Support for BlockMax WAND > - > > Key: SOLR-13289 > URL: https://issues.apache.org/jira/browse/SOLR-13289 > Project: Solr > Issue Type: New Feature >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Major > Attachments: SOLR-13289.patch, SOLR-13289.patch > > > LUCENE-8135 introduced BlockMax WAND as a major speed improvement. Need to > expose this via Solr. When enabled, the numFound returned will not be exact. -- 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-14414) New Admin UI
[
https://issues.apache.org/jira/browse/SOLR-14414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17089133#comment-17089133
]
Noble Paul commented on SOLR-14414:
---
{quote}I don't think today it supports an admin UI sort of plugin.
{quote}
well, we're almost there. There is a
[PR|[https://github.com/apache/lucene-solr/pull/1432]] which is almost ready to
go (SOLR-14404)
> New Admin UI
>
>
> Key: SOLR-14414
> URL: https://issues.apache.org/jira/browse/SOLR-14414
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Major
>
> We have had a lengthy discussion in the mailing list about the need to build
> a modern UI that is both more security and does not depend on deprecated, end
> of life code. In this ticket, I intend to familiarize the community with the
> efforts of the community to do just that that. While we are nearing feature
> parity, but not there yet as many have suggested we could complete this task
> in iterations, here is an attempt to get the ball rolling. I have mostly
> worked on it in weekend nights on the occasion that I could find the time.
> Angular is certainly not my specialty, and this is my first attempt at using
> TypeScript besides a few brief learning exercises here and there. However, I
> will be engaging experts in both of these areas for consultation as our
> community tries to pull our UI into another era.
> Many of the components here can improve. One or two them need to be
> rewritten, and there are even at least three essential components to the app
> missing, along with some tests. A couple other things missing are the V2 API,
> which I found difficult to build with in this context because it is not
> documented on the web. I understand that it is "self-documenting," but the
> most easy-to-use APIs are still documented on the web. Maybe it is entirely
> documented on the web, and I had trouble finding it. Forgive me, as that
> could be an area of assistance. Another area where I need assistance is
> packaging this application as a Solr package. I understand this app is not in
> the right place for that today, but it can be. There are still many
> improvements to be made in this Jira and certainly in this code.
> The project is located in {{lucene-solr/solr/webapp2}}, where there is a
> README for information on running the app.
> The app can be started from the this directory with {{npm start}} for now. It
> can quickly be modified to start as a part of the typical start commands as
> it approaches parity. I expect there will be a lot of opinions. I welcome
> them, of course. The community input should drive the project's success.
--
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-14259) backport SOLR-14013 to Solr 7.7
[ https://issues.apache.org/jira/browse/SOLR-14259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-14259. --- Resolution: Fixed > backport SOLR-14013 to Solr 7.7 > --- > > Key: SOLR-14259 > URL: https://issues.apache.org/jira/browse/SOLR-14259 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.7 >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Fix For: 7.7.3 > > Time Spent: 40m > Remaining Estimate: 0h > -- 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-14414) New Admin UI
[
https://issues.apache.org/jira/browse/SOLR-14414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17089106#comment-17089106
]
Marcus Eagan edited comment on SOLR-14414 at 4/21/20, 10:40 PM:
[~dsmiley] I don't think the Admin UI, such a use-case specific and widely used
functionality, falls in the same category as these other generic and external
tools. As for the gap discussion, I will leave to [~ichattopadhyaya].
Solr deciding to keep the old UI in favor of a new UI that is secure will have
bad consequences for its users. For one, many of them working in highly
scrutinizing or secure environments will never be able to run it. If they wish
to, they will be bogged down by months of approvals and paperwork. Secondly, an
external UI application will likely not be a part of Apache's CI pipeline. I am
happy to maintain a CI pipeline for the UI, though, I suppose.
was (Author: marcussorealheis):
[~dsmiley] I don't think the Admin UI, such a use-case specific and widely used
functionality, falls in the same category as these other generic and external
tools. As for the gap discussion, I will leave to [~ichattopadhyaya].
Solr deciding to keep the old UI in favor of a new UI that is secure will have
bad consequences for its users. For one, many of them working in highly secure
environments will never be able to run it. If they wish to, they will be bogged
down by months of approvals and paperwork. Secondly, an external UI application
will likely not be a part of Apache's CI pipeline. I am happy to maintain a CI
pipeline for the UI, though, I suppose.
> New Admin UI
>
>
> Key: SOLR-14414
> URL: https://issues.apache.org/jira/browse/SOLR-14414
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Major
>
> We have had a lengthy discussion in the mailing list about the need to build
> a modern UI that is both more security and does not depend on deprecated, end
> of life code. In this ticket, I intend to familiarize the community with the
> efforts of the community to do just that that. While we are nearing feature
> parity, but not there yet as many have suggested we could complete this task
> in iterations, here is an attempt to get the ball rolling. I have mostly
> worked on it in weekend nights on the occasion that I could find the time.
> Angular is certainly not my specialty, and this is my first attempt at using
> TypeScript besides a few brief learning exercises here and there. However, I
> will be engaging experts in both of these areas for consultation as our
> community tries to pull our UI into another era.
> Many of the components here can improve. One or two them need to be
> rewritten, and there are even at least three essential components to the app
> missing, along with some tests. A couple other things missing are the V2 API,
> which I found difficult to build with in this context because it is not
> documented on the web. I understand that it is "self-documenting," but the
> most easy-to-use APIs are still documented on the web. Maybe it is entirely
> documented on the web, and I had trouble finding it. Forgive me, as that
> could be an area of assistance. Another area where I need assistance is
> packaging this application as a Solr package. I understand this app is not in
> the right place for that today, but it can be. There are still many
> improvements to be made in this Jira and certainly in this code.
> The project is located in {{lucene-solr/solr/webapp2}}, where there is a
> README for information on running the app.
> The app can be started from the this directory with {{npm start}} for now. It
> can quickly be modified to start as a part of the typical start commands as
> it approaches parity. I expect there will be a lot of opinions. I welcome
> them, of course. The community input should drive the project's success.
--
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-14414) New Admin UI
[
https://issues.apache.org/jira/browse/SOLR-14414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17089106#comment-17089106
]
Marcus Eagan commented on SOLR-14414:
-
[~dsmiley] I don't think the Admin UI, such a use-case specific and widely used
functionality, falls in the same category as these other tools. As for the gap
discussion, I will leave to [~ichattopadhyaya].
Solr deciding to keep the old UI in favor of a new UI that is secure will have
bad consequences for its users. For one, many of them working in highly secure
environments will never be able to run it. If they wish to, they will be bogged
down by months of approvals and paperwork. Secondly, an external UI application
will likely not be a part of Apache's CI pipeline. I am happy to maintain a CI
pipeline for the UI, though, I suppose.
> New Admin UI
>
>
> Key: SOLR-14414
> URL: https://issues.apache.org/jira/browse/SOLR-14414
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Major
>
> We have had a lengthy discussion in the mailing list about the need to build
> a modern UI that is both more security and does not depend on deprecated, end
> of life code. In this ticket, I intend to familiarize the community with the
> efforts of the community to do just that that. While we are nearing feature
> parity, but not there yet as many have suggested we could complete this task
> in iterations, here is an attempt to get the ball rolling. I have mostly
> worked on it in weekend nights on the occasion that I could find the time.
> Angular is certainly not my specialty, and this is my first attempt at using
> TypeScript besides a few brief learning exercises here and there. However, I
> will be engaging experts in both of these areas for consultation as our
> community tries to pull our UI into another era.
> Many of the components here can improve. One or two them need to be
> rewritten, and there are even at least three essential components to the app
> missing, along with some tests. A couple other things missing are the V2 API,
> which I found difficult to build with in this context because it is not
> documented on the web. I understand that it is "self-documenting," but the
> most easy-to-use APIs are still documented on the web. Maybe it is entirely
> documented on the web, and I had trouble finding it. Forgive me, as that
> could be an area of assistance. Another area where I need assistance is
> packaging this application as a Solr package. I understand this app is not in
> the right place for that today, but it can be. There are still many
> improvements to be made in this Jira and certainly in this code.
> The project is located in {{lucene-solr/solr/webapp2}}, where there is a
> README for information on running the app.
> The app can be started from the this directory with {{npm start}} for now. It
> can quickly be modified to start as a part of the typical start commands as
> it approaches parity. I expect there will be a lot of opinions. I welcome
> them, of course. The community input should drive the project's success.
--
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] madrob commented on a change in pull request #1432: SOLR-14404 CoreContainer level custom requesthandlers
madrob commented on a change in pull request #1432:
URL: https://github.com/apache/lucene-solr/pull/1432#discussion_r412493389
##
File path: solr/core/src/java/org/apache/solr/api/CustomContainerPlugins.java
##
@@ -0,0 +1,283 @@
+/*
+ * 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.api;
+
+import java.io.Closeable;
+import java.io.IOException;
+import java.lang.invoke.MethodHandles;
+import java.lang.reflect.Constructor;
+import java.lang.reflect.Modifier;
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.HashSet;
+import java.util.List;
+import java.util.Map;
+import java.util.Objects;
+import java.util.Set;
+
+import com.fasterxml.jackson.databind.ObjectMapper;
+import org.apache.solr.client.solrj.request.beans.PluginMeta;
+import org.apache.solr.common.MapWriter;
+import org.apache.solr.common.annotation.JsonProperty;
+import org.apache.solr.common.cloud.ClusterPropertiesListener;
+import org.apache.solr.common.util.Pair;
+import org.apache.solr.common.util.ReflectMapWriter;
+import org.apache.solr.common.util.StrUtils;
+import org.apache.solr.common.util.Utils;
+import org.apache.solr.core.CoreContainer;
+import org.apache.solr.handler.admin.ContainerPluginsApi;
+import org.apache.solr.pkg.PackageLoader;
+import org.apache.solr.request.SolrQueryRequest;
+import org.apache.solr.response.SolrQueryResponse;
+import org.apache.solr.util.SolrJacksonAnnotationInspector;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import static org.apache.lucene.util.IOUtils.closeWhileHandlingException;
+
+public class CustomContainerPlugins implements MapWriter,
ClusterPropertiesListener {
+ private ObjectMapper mapper =
SolrJacksonAnnotationInspector.createObjectMapper();
+ private static final Logger log =
LoggerFactory.getLogger(MethodHandles.lookup().lookupClass());
+
+ final CoreContainer coreContainer;
+ final ApiBag containerApiBag;
+ private Map plugins = new HashMap<>();
+ private Map pluginNameVsPath = new HashMap<>();
+
+ @Override
+ public boolean onChange(Map properties) {
+refresh(null);
+return false;
+ }
+
+ @Override
+ public void writeMap(EntryWriter ew) {
+plugins.forEach((s, apiHolder) -> ew.putNoEx(s, apiHolder.apiInfo));
+ }
+
+ public CustomContainerPlugins(CoreContainer coreContainer, ApiBag apiBag) {
+this.coreContainer = coreContainer;
+this.containerApiBag = apiBag;
+ }
+
+ public void refresh(Map pluginInfos) {
+try {
+ pluginInfos =
ContainerPluginsApi.plugins(coreContainer.zkClientSupplier);
+} catch (IOException e) {
+ log.error("Could not read plugins data", e);
+ return;
+}
+if(pluginInfos.isEmpty()) return;
+
+for (Map.Entry e : pluginInfos.entrySet()) {
+ PluginMeta info = null;
+ try {
+info = mapper.readValue(Utils.toJSON(e.getValue()), PluginMeta.class);
+ } catch (IOException ioException) {
+log.error("Invalid apiInfo configuration :", ioException);
+ }
+
+ ApiInfo apiInfo = null;
+ try {
+List errs = new ArrayList<>();
+apiInfo = new ApiInfo(info, errs);
+if (!errs.isEmpty()) {
+ log.error(StrUtils.join(errs, ','));
+ continue;
+}
+ } catch (Exception ex) {
+log.error("unable to instantiate apiInfo ", ex);
+continue;
+ }
+
+ String path = pluginNameVsPath.get(e.getKey());
+ if (path == null) {
+// there is a new apiInfo . let's register it
+try {
+ apiInfo.init();
+ ApiHolder holder = new ApiHolder(apiInfo);
+ plugins.put(holder.key, holder);
+ pluginNameVsPath.put(apiInfo.info.name, holder.key);
+ containerApiBag.register(holder, Collections.EMPTY_MAP);
Review comment:
prefer Collections.emptyMap()
##
File path: solr/core/src/java/org/apache/solr/api/CustomContainerPlugins.java
##
@@ -0,0 +1,283 @@
+/*
+ * 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
[jira] [Commented] (LUCENE-9337) CMS might miss to pickup pending merges when maxMergeCount changes while merges are running
[
https://issues.apache.org/jira/browse/LUCENE-9337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17089085#comment-17089085
]
Simon Willnauer commented on LUCENE-9337:
-
here is a PR https://github.com/apache/lucene-solr/pull/1443/
> CMS might miss to pickup pending merges when maxMergeCount changes while
> merges are running
> ---
>
> Key: LUCENE-9337
> URL: https://issues.apache.org/jira/browse/LUCENE-9337
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Simon Willnauer
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We found a test hanging on an IW#forceMerge on elastics CI on an innocent
> looking test:
> {noformat}
> 14:52:06[junit4] 2> at
> java.base@11.0.2/java.lang.Object.wait(Native Method)
> 14:52:06[junit4] 2> at
> app//org.apache.lucene.index.IndexWriter.doWait(IndexWriter.java:4722)
> 14:52:06[junit4] 2> at
> app//org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:2034)
> 14:52:06[junit4] 2> at
> app//org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1960)
> 14:52:06[junit4] 2> at
> app//org.apache.lucene.index.RandomIndexWriter.forceMerge(RandomIndexWriter.java:500)
> 14:52:06[junit4] 2> at
> app//org.apache.lucene.index.BaseDocValuesFormatTestCase.doTestNumericsVsStoredFields(BaseDocValuesFormatTestCase.java:1301)
> 14:52:06[junit4] 2> at
> app//org.apache.lucene.index.BaseDocValuesFormatTestCase.doTestNumericsVsStoredFields(BaseDocValuesFormatTestCase.java:1258)
> 14:52:06[junit4] 2> at
> app//org.apache.lucene.index.BaseDocValuesFormatTestCase.testZeroOrMin(BaseDocValuesFormatTestCase.java:2423)
> {noformat}
> after spending quite some time trying to reproduce without any luck I tried
> to review all involved code again to understand possible threading issues.
> What I found is that if maxMergeCount gets changed on CMS while there are
> merges running and the forceMerge gets kicked off at the same time the
> running merges return we might miss to pick up the final pending merges which
> causes the forceMerge to hang. I was able to build a test-case that is very
> likely to fail on every run without the fix. While I think this is not a
> critical bug from how likely it is to happen in practice, if it happens it's
> basically a deadlock unless the IW sees any other change that kicks off a
> merge.
> Lemme walk through the issue. Lets say we have 1 pending merge and 2 merge
> threads running on CMS. The forceMerge is already waiting for merges to
> finish. Once the first merge thread finishes we try to check if we need to
> stall it
> [here|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.5.1/lucene/core/src/java/org/apache/lucene/index/ConcurrentMergeScheduler.java#L580]
> but since it's a merge thread we return
> [here|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.5.1/lucene/core/src/java/org/apache/lucene/index/ConcurrentMergeScheduler.java#L596]
> and don't pick up another merge
> [here|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.5.1/lucene/core/src/java/org/apache/lucene/index/ConcurrentMergeScheduler.java#L526].
>
> Now the second running merge thread checks the condition
> [here|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.5.1/lucene/core/src/java/org/apache/lucene/index/ConcurrentMergeScheduler.java#L580]
> while the first one is finishing up. But before it can actually update the
> internal datastructures
> [here|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.5.1/lucene/core/src/java/org/apache/lucene/index/ConcurrentMergeScheduler.java#L688]
> it releases the CMS lock and the calculation in the stall method on how many
> threads are running is off causing the second thread also to step out of the
> maybeStall method not picking up the pending merge.
--
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] s1monw opened a new pull request #1443: LUCENE-9337: Ensure CMS updates it's thread accounting datastructures consistently
s1monw opened a new pull request #1443: URL: https://github.com/apache/lucene-solr/pull/1443 CMS today releases it's lock after finishing a merge before it re-acquires it to update the thread accounting datastructures. This causes threading issues where concurrently finishing threads fail to pick up pending merges causing potential thread starvation on forceMerge calls. 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] (LUCENE-9337) CMS might miss to pickup pending merges when maxMergeCount changes while merges are running
Simon Willnauer created LUCENE-9337:
---
Summary: CMS might miss to pickup pending merges when
maxMergeCount changes while merges are running
Key: LUCENE-9337
URL: https://issues.apache.org/jira/browse/LUCENE-9337
Project: Lucene - Core
Issue Type: Bug
Reporter: Simon Willnauer
We found a test hanging on an IW#forceMerge on elastics CI on an innocent
looking test:
{noformat}
14:52:06[junit4] 2> at
java.base@11.0.2/java.lang.Object.wait(Native Method)
14:52:06[junit4] 2> at
app//org.apache.lucene.index.IndexWriter.doWait(IndexWriter.java:4722)
14:52:06[junit4] 2> at
app//org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:2034)
14:52:06[junit4] 2> at
app//org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1960)
14:52:06[junit4] 2> at
app//org.apache.lucene.index.RandomIndexWriter.forceMerge(RandomIndexWriter.java:500)
14:52:06[junit4] 2> at
app//org.apache.lucene.index.BaseDocValuesFormatTestCase.doTestNumericsVsStoredFields(BaseDocValuesFormatTestCase.java:1301)
14:52:06[junit4] 2> at
app//org.apache.lucene.index.BaseDocValuesFormatTestCase.doTestNumericsVsStoredFields(BaseDocValuesFormatTestCase.java:1258)
14:52:06[junit4] 2> at
app//org.apache.lucene.index.BaseDocValuesFormatTestCase.testZeroOrMin(BaseDocValuesFormatTestCase.java:2423)
{noformat}
after spending quite some time trying to reproduce without any luck I tried to
review all involved code again to understand possible threading issues. What I
found is that if maxMergeCount gets changed on CMS while there are merges
running and the forceMerge gets kicked off at the same time the running merges
return we might miss to pick up the final pending merges which causes the
forceMerge to hang. I was able to build a test-case that is very likely to fail
on every run without the fix. While I think this is not a critical bug from how
likely it is to happen in practice, if it happens it's basically a deadlock
unless the IW sees any other change that kicks off a merge.
Lemme walk through the issue. Lets say we have 1 pending merge and 2 merge
threads running on CMS. The forceMerge is already waiting for merges to finish.
Once the first merge thread finishes we try to check if we need to stall it
[here|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.5.1/lucene/core/src/java/org/apache/lucene/index/ConcurrentMergeScheduler.java#L580]
but since it's a merge thread we return
[here|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.5.1/lucene/core/src/java/org/apache/lucene/index/ConcurrentMergeScheduler.java#L596]
and don't pick up another merge
[here|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.5.1/lucene/core/src/java/org/apache/lucene/index/ConcurrentMergeScheduler.java#L526].
Now the second running merge thread checks the condition
[here|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.5.1/lucene/core/src/java/org/apache/lucene/index/ConcurrentMergeScheduler.java#L580]
while the first one is finishing up. But before it can actually update the
internal datastructures
[here|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.5.1/lucene/core/src/java/org/apache/lucene/index/ConcurrentMergeScheduler.java#L688]
it releases the CMS lock and the calculation in the stall method on how many
threads are running is off causing the second thread also to step out of the
maybeStall method not picking up the pending merge.
--
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] mayya-sharipova commented on issue #1351: LUCENE-9280: Collectors to skip noncompetitive documents
mayya-sharipova commented on issue #1351: URL: https://github.com/apache/lucene-solr/pull/1351#issuecomment-617422262 @mikemccand Thanks for looking at this > Do you know why you are seeing these warnings? WARNING: cat=HighTermDayOfYearSort: hit counts differ: 541658 vs 541658+ WARNING: cat=TermDTSort: hit counts differ: 68644 vs 68644+ ... the optimization did not wind up skipping any hits (though, it thought it may have, hence the added +) Indeed, we set up `totalHitsRelation` to `GREATER_THAN_OR_EQUAL_TO` when we try to run the optimization, but the optimization may end up not skipping any documents if it is not selective enough. It looks like some Scorers behave the same way in updating competitive scores (e.g LongDistanceFeatureQuery#DistanceScorer). 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] mayya-sharipova commented on a change in pull request #1351: LUCENE-9280: Collectors to skip noncompetitive documents
mayya-sharipova commented on a change in pull request #1351:
URL: https://github.com/apache/lucene-solr/pull/1351#discussion_r412496102
##
File path:
lucene/core/src/java/org/apache/lucene/search/FilteringFieldComparator.java
##
@@ -0,0 +1,350 @@
+/*
+ * 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.lucene.search;
+
+import org.apache.lucene.document.LongPoint;
+import org.apache.lucene.document.IntPoint;
+import org.apache.lucene.document.DoublePoint;
+import org.apache.lucene.document.FloatPoint;
+import org.apache.lucene.index.LeafReaderContext;
+import org.apache.lucene.index.PointValues;
+import org.apache.lucene.util.DocIdSetBuilder;
+
+import java.io.IOException;
+import java.util.Arrays;
+
+/**
+ * Decorates a wrapped FieldComparator to add a functionality to skip over
non-competitive docs.
+ * FilteringFieldComparator provides two additional functions for a
FieldComparator:
+ * 1) {@code competitiveIterator()} that returns an iterator over
+ * competitive docs that are stronger than already collected docs.
+ * 2) {@code setCanUpdateIterator()} that notifies the comparator when it is
ok to start updating its internal iterator.
+ * This method is called from a collector to inform the comparator to start
updating its iterator.
+ */
+public abstract class FilteringFieldComparator extends FieldComparator {
+final FieldComparator in;
+protected DocIdSetIterator iterator = null;
+
+public FilteringFieldComparator(FieldComparator in) {
+this.in = in;
+}
+
+protected abstract void setCanUpdateIterator() throws IOException;
+
+@Override
+public int compare(int slot1, int slot2) {
+return in.compare(slot1, slot2);
+}
+
+@Override
+public T value(int slot) {
+return in.value(slot);
+}
+
+@Override
+public void setTopValue(T value) {
+in.setTopValue(value);
+}
+
+@Override
+public int compareValues(T first, T second) {
+return in.compareValues(first, second);
+}
+
+/**
+ * Returns an iterator over competitive documents
+ */
+public DocIdSetIterator competitiveIterator() {
+if (iterator == null) return null;
+return new DocIdSetIterator() {
+private int doc;
+@Override
+public int nextDoc() throws IOException {
+return doc = iterator.nextDoc();
+}
+
+@Override
+public int docID() {
+return doc;
+}
+
+@Override
+public long cost() {
+return iterator.cost();
+}
+
+@Override
+public int advance(int target) throws IOException {
+return doc = iterator.advance(target);
+}
+};
+}
+
+/**
+ * Try to wrap a given field comparator to add to it a functionality to
skip over non-competitive docs.
+ * If for the given comparator the skip functionality is not implemented,
return the comparator itself.
+ */
+public static FieldComparator
wrapToFilteringComparator(FieldComparator comparator, boolean reverse) {
+if (comparator instanceof FieldComparator.LongComparator){
+return new
FilteringFieldComparator.FilteringLongComparator((FieldComparator.LongComparator)
comparator, reverse);
+}
+if (comparator instanceof FieldComparator.IntComparator){
+return new
FilteringFieldComparator.FilteringIntComparator((FieldComparator.IntComparator)
comparator, reverse);
+}
+if (comparator instanceof FieldComparator.DoubleComparator){
+return new
FilteringFieldComparator.FilteringDoubleComparator((FieldComparator.DoubleComparator)
comparator, reverse);
+}
+if (comparator instanceof FieldComparator.FloatComparator){
+return new
FilteringFieldComparator.FilteringFloatComparator((FieldComparator.FloatComparator)
comparator, reverse);
+}
+return comparator;
+}
+
+/**
+ * A wrapper over {@code NumericComparator} that adds a functionality to
filter non-competitive docs.
+ */
+public static abstract class
[GitHub] [lucene-solr] mayya-sharipova commented on a change in pull request #1351: LUCENE-9280: Collectors to skip noncompetitive documents
mayya-sharipova commented on a change in pull request #1351:
URL: https://github.com/apache/lucene-solr/pull/1351#discussion_r412496313
##
File path:
lucene/core/src/java/org/apache/lucene/search/FilteringFieldComparator.java
##
@@ -0,0 +1,350 @@
+/*
+ * 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.lucene.search;
+
+import org.apache.lucene.document.LongPoint;
+import org.apache.lucene.document.IntPoint;
+import org.apache.lucene.document.DoublePoint;
+import org.apache.lucene.document.FloatPoint;
+import org.apache.lucene.index.LeafReaderContext;
+import org.apache.lucene.index.PointValues;
+import org.apache.lucene.util.DocIdSetBuilder;
+
+import java.io.IOException;
+import java.util.Arrays;
+
+/**
+ * Decorates a wrapped FieldComparator to add a functionality to skip over
non-competitive docs.
+ * FilteringFieldComparator provides two additional functions for a
FieldComparator:
+ * 1) {@code competitiveIterator()} that returns an iterator over
+ * competitive docs that are stronger than already collected docs.
+ * 2) {@code setCanUpdateIterator()} that notifies the comparator when it is
ok to start updating its internal iterator.
+ * This method is called from a collector to inform the comparator to start
updating its iterator.
+ */
+public abstract class FilteringFieldComparator extends FieldComparator {
+final FieldComparator in;
+protected DocIdSetIterator iterator = null;
+
+public FilteringFieldComparator(FieldComparator in) {
+this.in = in;
+}
+
+protected abstract void setCanUpdateIterator() throws IOException;
+
+@Override
+public int compare(int slot1, int slot2) {
+return in.compare(slot1, slot2);
+}
+
+@Override
+public T value(int slot) {
+return in.value(slot);
+}
+
+@Override
+public void setTopValue(T value) {
+in.setTopValue(value);
+}
+
+@Override
+public int compareValues(T first, T second) {
+return in.compareValues(first, second);
+}
+
+/**
+ * Returns an iterator over competitive documents
+ */
+public DocIdSetIterator competitiveIterator() {
+if (iterator == null) return null;
+return new DocIdSetIterator() {
+private int doc;
+@Override
+public int nextDoc() throws IOException {
+return doc = iterator.nextDoc();
+}
+
+@Override
+public int docID() {
+return doc;
+}
+
+@Override
+public long cost() {
+return iterator.cost();
+}
+
+@Override
+public int advance(int target) throws IOException {
+return doc = iterator.advance(target);
+}
+};
+}
+
+/**
+ * Try to wrap a given field comparator to add to it a functionality to
skip over non-competitive docs.
+ * If for the given comparator the skip functionality is not implemented,
return the comparator itself.
+ */
+public static FieldComparator
wrapToFilteringComparator(FieldComparator comparator, boolean reverse) {
+if (comparator instanceof FieldComparator.LongComparator){
+return new
FilteringFieldComparator.FilteringLongComparator((FieldComparator.LongComparator)
comparator, reverse);
+}
+if (comparator instanceof FieldComparator.IntComparator){
+return new
FilteringFieldComparator.FilteringIntComparator((FieldComparator.IntComparator)
comparator, reverse);
+}
+if (comparator instanceof FieldComparator.DoubleComparator){
+return new
FilteringFieldComparator.FilteringDoubleComparator((FieldComparator.DoubleComparator)
comparator, reverse);
+}
+if (comparator instanceof FieldComparator.FloatComparator){
+return new
FilteringFieldComparator.FilteringFloatComparator((FieldComparator.FloatComparator)
comparator, reverse);
+}
+return comparator;
+}
+
+/**
+ * A wrapper over {@code NumericComparator} that adds a functionality to
filter non-competitive docs.
+ */
+public static abstract class
[GitHub] [lucene-solr] mayya-sharipova commented on a change in pull request #1351: LUCENE-9280: Collectors to skip noncompetitive documents
mayya-sharipova commented on a change in pull request #1351:
URL: https://github.com/apache/lucene-solr/pull/1351#discussion_r412495892
##
File path:
lucene/core/src/java/org/apache/lucene/search/FilteringFieldComparator.java
##
@@ -0,0 +1,350 @@
+/*
+ * 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.lucene.search;
+
+import org.apache.lucene.document.LongPoint;
+import org.apache.lucene.document.IntPoint;
+import org.apache.lucene.document.DoublePoint;
+import org.apache.lucene.document.FloatPoint;
+import org.apache.lucene.index.LeafReaderContext;
+import org.apache.lucene.index.PointValues;
+import org.apache.lucene.util.DocIdSetBuilder;
+
+import java.io.IOException;
+import java.util.Arrays;
+
+/**
+ * Decorates a wrapped FieldComparator to add a functionality to skip over
non-competitive docs.
+ * FilteringFieldComparator provides two additional functions for a
FieldComparator:
+ * 1) {@code competitiveIterator()} that returns an iterator over
+ * competitive docs that are stronger than already collected docs.
+ * 2) {@code setCanUpdateIterator()} that notifies the comparator when it is
ok to start updating its internal iterator.
+ * This method is called from a collector to inform the comparator to start
updating its iterator.
+ */
+public abstract class FilteringFieldComparator extends FieldComparator {
+final FieldComparator in;
+protected DocIdSetIterator iterator = null;
Review comment:
addressed in 24c94ff
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] mayya-sharipova commented on a change in pull request #1351: LUCENE-9280: Collectors to skip noncompetitive documents
mayya-sharipova commented on a change in pull request #1351:
URL: https://github.com/apache/lucene-solr/pull/1351#discussion_r412493986
##
File path:
lucene/core/src/java/org/apache/lucene/search/FilteringFieldComparator.java
##
@@ -0,0 +1,350 @@
+/*
+ * 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.lucene.search;
+
+import org.apache.lucene.document.LongPoint;
+import org.apache.lucene.document.IntPoint;
+import org.apache.lucene.document.DoublePoint;
+import org.apache.lucene.document.FloatPoint;
+import org.apache.lucene.index.LeafReaderContext;
+import org.apache.lucene.index.PointValues;
+import org.apache.lucene.util.DocIdSetBuilder;
+
+import java.io.IOException;
+import java.util.Arrays;
+
+/**
+ * Decorates a wrapped FieldComparator to add a functionality to skip over
non-competitive docs.
+ * FilteringFieldComparator provides two additional functions for a
FieldComparator:
+ * 1) {@code competitiveIterator()} that returns an iterator over
+ * competitive docs that are stronger than already collected docs.
+ * 2) {@code setCanUpdateIterator()} that notifies the comparator when it is
ok to start updating its internal iterator.
+ * This method is called from a collector to inform the comparator to start
updating its iterator.
+ */
+public abstract class FilteringFieldComparator extends FieldComparator {
+final FieldComparator in;
+protected DocIdSetIterator iterator = null;
+
+public FilteringFieldComparator(FieldComparator in) {
+this.in = in;
+}
+
+protected abstract void setCanUpdateIterator() throws IOException;
+
+@Override
+public int compare(int slot1, int slot2) {
+return in.compare(slot1, slot2);
+}
+
+@Override
+public T value(int slot) {
+return in.value(slot);
+}
+
+@Override
+public void setTopValue(T value) {
+in.setTopValue(value);
+}
+
+@Override
+public int compareValues(T first, T second) {
+return in.compareValues(first, second);
+}
+
+/**
+ * Returns an iterator over competitive documents
+ */
+public DocIdSetIterator competitiveIterator() {
+if (iterator == null) return null;
+return new DocIdSetIterator() {
+private int doc;
+@Override
+public int nextDoc() throws IOException {
+return doc = iterator.nextDoc();
+}
+
+@Override
+public int docID() {
+return doc;
+}
+
+@Override
+public long cost() {
+return iterator.cost();
+}
+
+@Override
+public int advance(int target) throws IOException {
+return doc = iterator.advance(target);
+}
+};
+}
+
+/**
+ * Try to wrap a given field comparator to add to it a functionality to
skip over non-competitive docs.
+ * If for the given comparator the skip functionality is not implemented,
return the comparator itself.
+ */
+public static FieldComparator
wrapToFilteringComparator(FieldComparator comparator, boolean reverse) {
+if (comparator instanceof FieldComparator.LongComparator){
+return new
FilteringFieldComparator.FilteringLongComparator((FieldComparator.LongComparator)
comparator, reverse);
+}
+if (comparator instanceof FieldComparator.IntComparator){
+return new
FilteringFieldComparator.FilteringIntComparator((FieldComparator.IntComparator)
comparator, reverse);
+}
+if (comparator instanceof FieldComparator.DoubleComparator){
+return new
FilteringFieldComparator.FilteringDoubleComparator((FieldComparator.DoubleComparator)
comparator, reverse);
+}
+if (comparator instanceof FieldComparator.FloatComparator){
+return new
FilteringFieldComparator.FilteringFloatComparator((FieldComparator.FloatComparator)
comparator, reverse);
+}
+return comparator;
+}
+
+/**
+ * A wrapper over {@code NumericComparator} that adds a functionality to
filter non-competitive docs.
+ */
+public static abstract class
[GitHub] [lucene-solr] madrob commented on a change in pull request #1432: SOLR-14404 CoreContainer level custom requesthandlers
madrob commented on a change in pull request #1432:
URL: https://github.com/apache/lucene-solr/pull/1432#discussion_r412490678
##
File path: solr/core/src/java/org/apache/solr/pkg/PackageListeners.java
##
@@ -63,13 +63,13 @@ public synchronized void removeListener(Listener listener) {
}
synchronized void packagesUpdated(List pkgs) {
-MDCLoggingContext.setCore(core);
Review comment:
I was under the impression that it setCore/clear still work even if the
core was null.
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-14424) RequestHandler with startup=lazy can't implement SolrCoreAware
David Smiley created SOLR-14424: --- Summary: RequestHandler with startup=lazy can't implement SolrCoreAware Key: SOLR-14424 URL: https://issues.apache.org/jira/browse/SOLR-14424 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: David Smiley Request handlers configured to load lazily (on-demand) will not have the SolrCoreAware callback invoked. It ought to be supported. Too bad current behavior isn't an error; instead it's who-knows-what depending on what the inform method does for the handler in question. -- 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-14423) static caches in StreamHandler ought to move to CoreContainer lifecycle
[ https://issues.apache.org/jira/browse/SOLR-14423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17089049#comment-17089049 ] David Smiley commented on SOLR-14423: - I propose we add a general purpose enhancement to CoreContainer to help multiple plugins that might want to have core-wide facilities. Imagine the CoreContainer offering a ConcurrentMap keyed by class and value is an instance of the class. On CoreContainer shutdown, these are examined to see which are closeable, and they are then closed. The typed nature would mean you can't usefully add something generic like a String but I think that's a fine trade-off for some type safety. > static caches in StreamHandler ought to move to CoreContainer lifecycle > --- > > Key: SOLR-14423 > URL: https://issues.apache.org/jira/browse/SOLR-14423 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: streaming expressions >Reporter: David Smiley >Priority: Major > > StreamHandler (at "/stream") has several statically declared caches. I think > this is problematic, such as in testing wherein multiple nodes could be in > the same JVM. One of them is more serious -- SolrClientCache which is > closed/cleared via a SolrCore close hook. That's bad for performance but > also dangerous since another core might want to use one of these clients! > CC [~jbernste] -- 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-14423) static caches in StreamHandler ought to move to CoreContainer lifecycle
David Smiley created SOLR-14423: --- Summary: static caches in StreamHandler ought to move to CoreContainer lifecycle Key: SOLR-14423 URL: https://issues.apache.org/jira/browse/SOLR-14423 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: streaming expressions Reporter: David Smiley StreamHandler (at "/stream") has several statically declared caches. I think this is problematic, such as in testing wherein multiple nodes could be in the same JVM. One of them is more serious -- SolrClientCache which is closed/cleared via a SolrCore close hook. That's bad for performance but also dangerous since another core might want to use one of these clients! CC [~jbernste] -- 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-7642) Should launching Solr in cloud mode using a ZooKeeper chroot create the chroot znode if it doesn't exist?
[
https://issues.apache.org/jira/browse/SOLR-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17089039#comment-17089039
]
Gus Heck commented on SOLR-7642:
Looking at the patch I began to wonder about the other conditions in that if
statement... it appears we have two entirely undocumented system properties
coded in as magic values. The third one one (zkRunOnly) appears to be
primarily there to support old cloud scripts that I removed in SOLR-11492, so
it seems that there's half a dozen places where zkRunOnly is used that the code
could be simplified. That's all fodder for another ticket however.
As for this patch, +1 on all of Jan's points, system prop is good enough.
> Should launching Solr in cloud mode using a ZooKeeper chroot create the
> chroot znode if it doesn't exist?
> -
>
> Key: SOLR-7642
> URL: https://issues.apache.org/jira/browse/SOLR-7642
> Project: Solr
> Issue Type: Improvement
>Reporter: Timothy Potter
>Priority: Minor
> Attachments: SOLR-7642.patch, SOLR-7642.patch, SOLR-7642.patch,
> SOLR-7642_tag_7.5.0.patch, SOLR-7642_tag_7.5.0_proposition.patch
>
>
> If you launch Solr for the first time in cloud mode using a ZooKeeper
> connection string that includes a chroot leads to the following
> initialization error:
> {code}
> ERROR - 2015-06-05 17:15:50.410; [ ] org.apache.solr.common.SolrException;
> null:org.apache.solr.common.cloud.ZooKeeperException: A chroot was specified
> in ZkHost but the znode doesn't exist. localhost:2181/lan
> at
> org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:113)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:339)
> at
> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:140)
> at
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:110)
> at
> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:138)
> at
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:852)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:298)
> at
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> at
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
> at
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
> {code}
> The work-around for this is to use the scripts/cloud-scripts/zkcli.sh script
> to create the chroot znode (bootstrap action does this).
> I'm wondering if we shouldn't just create the znode if it doesn't exist? Or
> is that some violation of using a chroot?
--
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-13779) Use the safe fork of simple-xml for clustering contrib
[ https://issues.apache.org/jira/browse/SOLR-13779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088976#comment-17088976 ] Dawid Weiss commented on SOLR-13779: Right - thanks Cassandra. > Use the safe fork of simple-xml for clustering contrib > -- > > Key: SOLR-13779 > URL: https://issues.apache.org/jira/browse/SOLR-13779 > Project: Solr > Issue Type: Improvement >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: 7.7.3, 8.3 > > Time Spent: 40m > Remaining Estimate: 0h > -- 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-13779) Use the safe fork of simple-xml for clustering contrib
[ https://issues.apache.org/jira/browse/SOLR-13779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated SOLR-13779: --- Fix Version/s: 7.7.3 > Use the safe fork of simple-xml for clustering contrib > -- > > Key: SOLR-13779 > URL: https://issues.apache.org/jira/browse/SOLR-13779 > Project: Solr > Issue Type: Improvement >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: 7.7.3, 8.3 > > Time Spent: 40m > Remaining Estimate: 0h > -- 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-9321) Port documentation task to gradle
[ https://issues.apache.org/jira/browse/LUCENE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088974#comment-17088974 ] Dawid Weiss commented on LUCENE-9321: - I like the idea of moving gradle scripts under "documentation", Tomoko. > Port documentation task to gradle > - > > Key: LUCENE-9321 > URL: https://issues.apache.org/jira/browse/LUCENE-9321 > Project: Lucene - Core > Issue Type: Sub-task > Components: general/build >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Major > > This is a placeholder issue for porting ant "documentation" task to gradle. > The generated documents should be able to be published on lucene.apache.org > web site on "as-is" basis. -- 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-14259) backport SOLR-14013 to Solr 7.7
[ https://issues.apache.org/jira/browse/SOLR-14259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088944#comment-17088944 ] Cassandra Targett commented on SOLR-14259: -- [~noble.paul], Shouldn't this be resolved since the VOTE for 7.7.3 is underway and this is included in the CHANGES.txt for it? > backport SOLR-14013 to Solr 7.7 > --- > > Key: SOLR-14259 > URL: https://issues.apache.org/jira/browse/SOLR-14259 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.7 >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Fix For: 7.7.3 > > Time Spent: 40m > Remaining Estimate: 0h > -- 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-13779) Use the safe fork of simple-xml for clustering contrib
[ https://issues.apache.org/jira/browse/SOLR-13779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088933#comment-17088933 ] Cassandra Targett commented on SOLR-13779: -- The PR in the last comment here appears to have been merged into branch_7_7 and it is mentioned in CHANGES.txt for 7.7.3 - so we should update this issue to include 7.7.3 version? [~dweiss]? > Use the safe fork of simple-xml for clustering contrib > -- > > Key: SOLR-13779 > URL: https://issues.apache.org/jira/browse/SOLR-13779 > Project: Solr > Issue Type: Improvement >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: 8.3 > > Time Spent: 40m > Remaining Estimate: 0h > -- 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-14105) Http2SolrClient SSL not working in branch_8x
[
https://issues.apache.org/jira/browse/SOLR-14105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088913#comment-17088913
]
Akhmad Amirov commented on SOLR-14105:
--
So what version of jetty has the bug fix? It seems 8.5.1 Solr version comes
with Server jetty-9.4.24.v20191120; built: 2019-11-20T21:37:49.771Z; git:
363d5f2df3a8a28de40604320230664b9c793c16; jvm 1.8.0_241-b07.
> Http2SolrClient SSL not working in branch_8x
>
>
> Key: SOLR-14105
> URL: https://issues.apache.org/jira/browse/SOLR-14105
> Project: Solr
> Issue Type: Bug
>Affects Versions: 8.5
>Reporter: Jan Høydahl
>Assignee: Kevin Risden
>Priority: Major
> Attachments: SOLR-14105.patch
>
>
> In branch_8x we upgraded to Jetty 9.4.24. This causes the following
> exceptions when attempting to start server with SSL:
> {noformat}
> 2019-12-17 14:46:16.646 ERROR (main) [ ] o.a.s.c.SolrCore
> null:org.apache.solr.common.SolrException: Error instantiating
> shardHandlerFactory class [HttpShardHandlerFactory]:
> java.lang.UnsupportedOperationException: X509ExtendedKeyManager only
> supported on Server
> at
> org.apache.solr.handler.component.ShardHandlerFactory.newInstance(ShardHandlerFactory.java:56)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:633)
> ...
> Caused by: java.lang.RuntimeException:
> java.lang.UnsupportedOperationException: X509ExtendedKeyManager only
> supported on Server
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.createHttpClient(Http2SolrClient.java:224)
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.(Http2SolrClient.java:154)
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient$Builder.build(Http2SolrClient.java:833)
> at
> org.apache.solr.handler.component.HttpShardHandlerFactory.init(HttpShardHandlerFactory.java:321)
> at
> org.apache.solr.handler.component.ShardHandlerFactory.newInstance(ShardHandlerFactory.java:51)
> ... 50 more
> Caused by: java.lang.UnsupportedOperationException: X509ExtendedKeyManager
> only supported on Server
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.newSniX509ExtendedKeyManager(SslContextFactory.java:1273)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.getKeyManagers(SslContextFactory.java:1255)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.load(SslContextFactory.java:374)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.doStart(SslContextFactory.java:245)
> {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
[GitHub] [lucene-solr] jpountz commented on a change in pull request #1440: LUCENE-9330: Make SortFields responsible for index sorting and serialization
jpountz commented on a change in pull request #1440:
URL: https://github.com/apache/lucene-solr/pull/1440#discussion_r412317472
##
File path: lucene/core/src/java/org/apache/lucene/search/SortField.java
##
@@ -120,6 +126,99 @@ public SortField(String field, Type type, boolean reverse)
{
this.reverse = reverse;
}
+ /** A SortFieldProvider for field sorts */
+ public static final class Provider extends SortFieldProvider {
+
+/** The name this Provider is registered under */
+public static final String NAME = "field";
Review comment:
maybe reuse the class name like we do for codecs, ie. `SortField`?
##
File path:
lucene/core/src/java/org/apache/lucene/index/DefaultIndexingChain.java
##
@@ -527,45 +589,61 @@ private void indexPoint(PerField fp, IndexableField
field) throws IOException {
fp.pointValuesWriter.addPackedValue(docState.docID, field.binaryValue());
}
- private void validateIndexSortDVType(Sort indexSort, String fieldName,
DocValuesType dvType) {
+ private void validateIndexSortDVType(Sort indexSort, String fieldToValidate,
DocValuesType dvType) throws IOException {
for (SortField sortField : indexSort.getSort()) {
- if (sortField.getField().equals(fieldName)) {
-switch (dvType) {
- case NUMERIC:
-if (sortField.getType().equals(SortField.Type.INT) == false &&
- sortField.getType().equals(SortField.Type.LONG) == false &&
- sortField.getType().equals(SortField.Type.FLOAT) == false &&
- sortField.getType().equals(SortField.Type.DOUBLE) == false) {
- throw new IllegalArgumentException("invalid doc value type:" +
dvType + " for sortField:" + sortField);
-}
-break;
+ IndexSorter sorter = sortField.getIndexSorter();
+ assert sorter != null;
Review comment:
should it be an actual exception instead of an assertion? Or are we
checking it up-front already?
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] jpountz commented on a change in pull request #1440: LUCENE-9330: Make SortFields responsible for index sorting and serialization
jpountz commented on a change in pull request #1440:
URL: https://github.com/apache/lucene-solr/pull/1440#discussion_r412317591
##
File path:
lucene/core/src/java/org/apache/lucene/search/SortedNumericSortField.java
##
@@ -83,6 +89,80 @@ public SortedNumericSortField(String field, SortField.Type
type, boolean reverse
this.type = type;
}
+ /** A SortFieldProvider for this sort field */
+ public static final class Provider extends SortFieldProvider {
+
+/** The name this provider is registered under */
+public static final String NAME = "sortedNumericField";
Review comment:
maybe reuse the class name?
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] jpountz commented on a change in pull request #1440: LUCENE-9330: Make SortFields responsible for index sorting and serialization
jpountz commented on a change in pull request #1440:
URL: https://github.com/apache/lucene-solr/pull/1440#discussion_r412304782
##
File path:
lucene/codecs/src/java/org/apache/lucene/codecs/simpletext/SimpleTextSegmentInfoFormat.java
##
@@ -171,133 +168,17 @@ public SegmentInfo read(Directory directory, String
segmentName, byte[] segmentI
SortField[] sortField = new SortField[numSortFields];
for (int i = 0; i < numSortFields; ++i) {
SimpleTextUtil.readLine(input, scratch);
-assert StringHelper.startsWith(scratch.get(), SI_SORT_FIELD);
-final String field = readString(SI_SORT_FIELD.length, scratch);
+assert StringHelper.startsWith(scratch.get(), SI_SORT_NAME);
+final String provider = readString(SI_SORT_NAME.length, scratch);
SimpleTextUtil.readLine(input, scratch);
assert StringHelper.startsWith(scratch.get(), SI_SORT_TYPE);
-final String typeAsString = readString(SI_SORT_TYPE.length, scratch);
-
-final SortField.Type type;
-SortedSetSelector.Type selectorSet = null;
-SortedNumericSelector.Type selectorNumeric = null;
-switch (typeAsString) {
- case "string":
-type = SortField.Type.STRING;
-break;
- case "long":
-type = SortField.Type.LONG;
-break;
- case "int":
-type = SortField.Type.INT;
-break;
- case "double":
-type = SortField.Type.DOUBLE;
-break;
- case "float":
-type = SortField.Type.FLOAT;
-break;
- case "multi_valued_string":
-type = SortField.Type.STRING;
-selectorSet = readSetSelector(input, scratch);
-break;
- case "multi_valued_long":
-type = SortField.Type.LONG;
-selectorNumeric = readNumericSelector(input, scratch);
-break;
- case "multi_valued_int":
-type = SortField.Type.INT;
-selectorNumeric = readNumericSelector(input, scratch);
-break;
- case "multi_valued_double":
-type = SortField.Type.DOUBLE;
-selectorNumeric = readNumericSelector(input, scratch);
-break;
- case "multi_valued_float":
-type = SortField.Type.FLOAT;
-selectorNumeric = readNumericSelector(input, scratch);
-break;
- default:
-throw new CorruptIndexException("unable to parse sort type string:
" + typeAsString, input);
-}
SimpleTextUtil.readLine(input, scratch);
-assert StringHelper.startsWith(scratch.get(), SI_SORT_REVERSE);
-final boolean reverse =
Boolean.parseBoolean(readString(SI_SORT_REVERSE.length, scratch));
-
-SimpleTextUtil.readLine(input, scratch);
-assert StringHelper.startsWith(scratch.get(), SI_SORT_MISSING);
-final String missingLastAsString = readString(SI_SORT_MISSING.length,
scratch);
-final Object missingValue;
-switch (type) {
- case STRING:
-switch (missingLastAsString) {
- case "null":
-missingValue = null;
-break;
- case "first":
-missingValue = SortField.STRING_FIRST;
-break;
- case "last":
-missingValue = SortField.STRING_LAST;
-break;
- default:
-throw new CorruptIndexException("unable to parse missing
string: " + typeAsString, input);
-}
-break;
- case LONG:
-switch (missingLastAsString) {
- case "null":
-missingValue = null;
-break;
- default:
-missingValue = Long.parseLong(missingLastAsString);
-break;
-}
-break;
- case INT:
-switch (missingLastAsString) {
- case "null":
-missingValue = null;
-break;
- default:
-missingValue = Integer.parseInt(missingLastAsString);
-break;
-}
-break;
- case DOUBLE:
-switch (missingLastAsString) {
- case "null":
-missingValue = null;
-break;
- default:
-missingValue = Double.parseDouble(missingLastAsString);
-break;
-}
-break;
- case FLOAT:
-switch (missingLastAsString) {
- case "null":
-missingValue = null;
-break;
- default:
-missingValue = Float.parseFloat(missingLastAsString);
-break;
-}
-break;
- default:
-throw new AssertionError();
-}
-if (selectorSet != null) {
-
[GitHub] [lucene-solr] jpountz commented on a change in pull request #1440: LUCENE-9330: Make SortFields responsible for index sorting and serialization
jpountz commented on a change in pull request #1440:
URL: https://github.com/apache/lucene-solr/pull/1440#discussion_r412312883
##
File path:
lucene/core/src/java/org/apache/lucene/index/DefaultIndexingChain.java
##
@@ -94,29 +89,100 @@ public DefaultIndexingChain(DocumentsWriterPerThread
docWriter) {
termsHash = new FreqProxTermsWriter(docWriter, termVectorsWriter);
}
+ private LeafReader getDocValuesReader(int maxDoc) {
+return new DocValuesReader() {
+ @Override
+ public NumericDocValues getNumericDocValues(String field) throws
IOException {
+PerField pf = getPerField(field);
+if (pf == null) {
+ return null;
+}
+if (pf.fieldInfo.getDocValuesType() == DocValuesType.NUMERIC) {
+ return (NumericDocValues) pf.docValuesWriter.getDocValues();
+}
+return null;
+ }
+
+ @Override
+ public BinaryDocValues getBinaryDocValues(String field) throws
IOException {
+PerField pf = getPerField(field);
+if (pf == null) {
+ return null;
+}
+if (pf.fieldInfo.getDocValuesType() == DocValuesType.BINARY) {
+ return (BinaryDocValues) pf.docValuesWriter.getDocValues();
+}
+return null;
+ }
+
+ @Override
+ public SortedDocValues getSortedDocValues(String field) throws
IOException {
+PerField pf = getPerField(field);
+if (pf == null) {
+ return null;
+}
+if (pf.fieldInfo.getDocValuesType() == DocValuesType.SORTED) {
+ return (SortedDocValues) pf.docValuesWriter.getDocValues();
+}
+return null;
+ }
+
+ @Override
+ public SortedNumericDocValues getSortedNumericDocValues(String field)
throws IOException {
+PerField pf = getPerField(field);
+if (pf == null) {
+ return null;
+}
+if (pf.fieldInfo.getDocValuesType() == DocValuesType.SORTED_NUMERIC) {
+ return (SortedNumericDocValues) pf.docValuesWriter.getDocValues();
+}
+return null;
+ }
+
+ @Override
+ public SortedSetDocValues getSortedSetDocValues(String field) throws
IOException {
+PerField pf = getPerField(field);
+if (pf == null) {
+ return null;
+}
+if (pf.fieldInfo.getDocValuesType() == DocValuesType.SORTED_SET) {
+ return (SortedSetDocValues) pf.docValuesWriter.getDocValues();
+}
+return null;
+ }
+
+ @Override
+ public FieldInfos getFieldInfos() {
+return fieldInfos.finish();
+ }
+
+ @Override
+ public int maxDoc() {
+return maxDoc;
+ }
+};
+ }
+
private Sorter.DocMap maybeSortSegment(SegmentWriteState state) throws
IOException {
Sort indexSort = state.segmentInfo.getIndexSort();
if (indexSort == null) {
return null;
}
-List comparators = new ArrayList<>();
+LeafReader docValuesReader =
getDocValuesReader(state.segmentInfo.maxDoc());
+
+List comparators = new ArrayList<>();
for (int i = 0; i < indexSort.getSort().length; i++) {
SortField sortField = indexSort.getSort()[i];
- PerField perField = getPerField(sortField.getField());
- if (perField != null && perField.docValuesWriter != null &&
- finishedDocValues.contains(perField.fieldInfo.name) == false) {
- perField.docValuesWriter.finish(state.segmentInfo.maxDoc());
- Sorter.DocComparator cmp =
perField.docValuesWriter.getDocComparator(state.segmentInfo.maxDoc(),
sortField);
- comparators.add(cmp);
- finishedDocValues.add(perField.fieldInfo.name);
- } else {
-// safe to ignore, sort field with no values or already seen before
+ IndexSorter sorter = sortField.getIndexSorter();
+ if (sorter == null) {
+throw new UnsupportedOperationException("Cannot sort index using sort
field " + sortField);
}
+ comparators.add(sorter.getDocComparator(docValuesReader));
}
Sorter sorter = new Sorter(indexSort);
// returns null if the documents are already sorted
-return sorter.sort(state.segmentInfo.maxDoc(), comparators.toArray(new
Sorter.DocComparator[comparators.size()]));
+return sorter.sort(state.segmentInfo.maxDoc(), comparators.toArray(new
IndexSorter.DocComparator[0]));
Review comment:
There is an even nicer syntax now.
```suggestion
return sorter.sort(state.segmentInfo.maxDoc(),
comparators.toArray(IndexSorter.DocComparator[]::new));
```
##
File path: lucene/core/src/java/org/apache/lucene/index/DocValuesWriter.java
##
@@ -21,12 +21,10 @@
import org.apache.lucene.codecs.DocValuesConsumer;
import org.apache.lucene.search.DocIdSetIterator;
-import org.apache.lucene.search.SortField;
-abstract class DocValuesWriter {
- abstract void finish(int numDoc);
+abstract class DocValuesWriter {
abstract void
[GitHub] [lucene-solr] jpountz commented on a change in pull request #1440: LUCENE-9330: Make SortFields responsible for index sorting and serialization
jpountz commented on a change in pull request #1440:
URL: https://github.com/apache/lucene-solr/pull/1440#discussion_r412319671
##
File path: lucene/core/src/java/org/apache/lucene/index/IndexSorter.java
##
@@ -0,0 +1,500 @@
+/*
+ * 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.lucene.index;
+
+import java.io.IOException;
+import java.util.Arrays;
+import java.util.Comparator;
+import java.util.List;
+
+import org.apache.lucene.search.FieldComparator;
+import org.apache.lucene.search.SortField;
+import org.apache.lucene.store.DataInput;
+import org.apache.lucene.store.DataOutput;
+import org.apache.lucene.util.LongValues;
+import org.apache.lucene.util.NumericUtils;
+import org.apache.lucene.util.packed.PackedInts;
+
+import static org.apache.lucene.search.DocIdSetIterator.NO_MORE_DOCS;
+
+/**
+ * Handles how documents should be sorted in an index, both within a segment
and between
+ * segments.
+ *
+ * Implementers must provide the following methods:
+ * {@link #getDocComparator(LeafReader)} - an object that determines how
documents within a segment are to be sorted
+ * {@link #getComparableProviders(List)} - an array of objects that return a
sortable long value per document and segment
+ * {@link #serialize(DataOutput)} - how the sort should be written into the
segment header
+ * {@link #getProviderName()} - the SPI-registered name of a {@link
SortFieldProvider} to deserialize the sort
+ *
+ * The companion {@link SortFieldProvider} should be registered with SPI via
{@code META-INF/services}
+ */
+public interface IndexSorter {
+
+ /** Used for sorting documents across segments */
+ public interface ComparableProvider {
+/**
+ * Returns a long so that the natural ordering of long values matches the
+ * ordering of doc IDs for the given comparator
+ */
+long getAsComparableLong(int docID) throws IOException;
+ }
+
+ /** A comparator of doc IDs, used for sorting documents within a segment */
+ public interface DocComparator {
+/** Compare docID1 against docID2. The contract for the return value is the
+ * same as {@link Comparator#compare(Object, Object)}. */
+int compare(int docID1, int docID2);
+ }
+
+ /**
+ * Get an array of {@link ComparableProvider}, one per segment, for merge
sorting documents in different segments
+ * @param readers the readers to be merged
+ */
+ public abstract ComparableProvider[] getComparableProviders(List readers) throws IOException;
+
+ /**
+ * Get a comparator that determines the sort order of docs within a single
Reader.
+ *
+ * NB We cannot simply use the {@link FieldComparator} API because it
requires docIDs to be sent
+ * in-order. The default implementations allocate array[maxDoc] to hold
native values for comparison,
+ * but 1) they are transient (only alive while sorting this one segment) and
2) in the typical
+ * index sorting case, they are only used to sort newly flushed segments,
which will be smaller
+ * than merged segments
+ *
+ * @param reader the Reader to sort
+ */
+ public abstract DocComparator getDocComparator(LeafReader reader) throws
IOException;
+
+ /**
+ * Serializes the parent SortField. This is used to write Sort information
into the Segment header
+ *
+ * @see SortFieldProvider#loadSortField(DataInput)
+ */
+ public abstract void serialize(DataOutput out) throws IOException;
+
+ /**
+ * The SPI-registered name of a {@link SortFieldProvider} that will
deserialize the parent SortField
+ */
+ public abstract String getProviderName();
+
+ /**
+ * Provide a NumericDocValues instance for a LeafReader
+ */
+ public interface NumericDocValuesProvider {
+/**
+ * Returns the NumericDocValues instance for this LeafReader
+ */
+NumericDocValues get(LeafReader reader) throws IOException;
+ }
+
+ /**
+ * Provide a SortedDocValues instance for a LeafReader
+ */
+ public interface SortedDocValuesProvider {
+/**
+ * Returns the SortedDocValues instance for this LeafReader
+ */
+SortedDocValues get(LeafReader reader) throws IOException;
+ }
+
+ /**
+ * Serialize an object into a DataOutput
+ */
+ public interface Serializer
[jira] [Resolved] (LUCENE-9191) Fix linefiledocs compression or replace in tests
[ https://issues.apache.org/jira/browse/LUCENE-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-9191. Fix Version/s: 8.6 Resolution: Fixed Thanks [~rcmuir]! I posted larger line file docs sources (see links above) in case developers want to download to run tests on more diverse collections. > Fix linefiledocs compression or replace in tests > > > Key: LUCENE-9191 > URL: https://issues.apache.org/jira/browse/LUCENE-9191 > Project: Lucene - Core > Issue Type: Task >Reporter: Robert Muir >Assignee: Michael McCandless >Priority: Major > Fix For: 8.6 > > Attachments: LUCENE-9191.patch, LUCENE-9191.patch > > > LineFileDocs(random) is very slow, even to open. It does a very slow "random > skip" through a gzip compressed file. > For the analyzers tests, in LUCENE-9186 I simply removed its usage, since > TestUtil.randomAnalysisString is superior, and fast. But we should address > other tests using it, since LineFileDocs(random) is slow! > I think it is also the case that every lucene test has probably tested every > LineFileDocs line many times now, whereas randomAnalysisString will invent > new ones. > Alternatively, we could "fix" LineFileDocs(random), e.g. special compression > options (in blocks)... deflate supports such stuff. But it would make it even > hairier than it is now. -- 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-9191) Fix linefiledocs compression or replace in tests
[ https://issues.apache.org/jira/browse/LUCENE-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088836#comment-17088836 ] ASF subversion and git services commented on LUCENE-9191: - Commit 722df4ff758f89a5961863ec805e3d3f75041a48 in lucene-solr's branch refs/heads/branch_8x from Michael McCandless [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=722df4f ] LUCENE-9191: make LineFileDocs random seeking more efficient by recording safe skip points in the concatenated gzip'd chunks > Fix linefiledocs compression or replace in tests > > > Key: LUCENE-9191 > URL: https://issues.apache.org/jira/browse/LUCENE-9191 > Project: Lucene - Core > Issue Type: Task >Reporter: Robert Muir >Assignee: Michael McCandless >Priority: Major > Attachments: LUCENE-9191.patch, LUCENE-9191.patch > > > LineFileDocs(random) is very slow, even to open. It does a very slow "random > skip" through a gzip compressed file. > For the analyzers tests, in LUCENE-9186 I simply removed its usage, since > TestUtil.randomAnalysisString is superior, and fast. But we should address > other tests using it, since LineFileDocs(random) is slow! > I think it is also the case that every lucene test has probably tested every > LineFileDocs line many times now, whereas randomAnalysisString will invent > new ones. > Alternatively, we could "fix" LineFileDocs(random), e.g. special compression > options (in blocks)... deflate supports such stuff. But it would make it even > hairier than it is now. -- 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-9191) Fix linefiledocs compression or replace in tests
[ https://issues.apache.org/jira/browse/LUCENE-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088825#comment-17088825 ] ASF subversion and git services commented on LUCENE-9191: - Commit e0c06ee6a6db925efa40b6633869c800d5745261 in lucene-solr's branch refs/heads/master from Michael McCandless [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e0c06ee ] LUCENE-9191: make LineFileDocs random seeking more efficient by recording safe skip points in the concatenated gzip'd chunks > Fix linefiledocs compression or replace in tests > > > Key: LUCENE-9191 > URL: https://issues.apache.org/jira/browse/LUCENE-9191 > Project: Lucene - Core > Issue Type: Task >Reporter: Robert Muir >Assignee: Michael McCandless >Priority: Major > Attachments: LUCENE-9191.patch, LUCENE-9191.patch > > > LineFileDocs(random) is very slow, even to open. It does a very slow "random > skip" through a gzip compressed file. > For the analyzers tests, in LUCENE-9186 I simply removed its usage, since > TestUtil.randomAnalysisString is superior, and fast. But we should address > other tests using it, since LineFileDocs(random) is slow! > I think it is also the case that every lucene test has probably tested every > LineFileDocs line many times now, whereas randomAnalysisString will invent > new ones. > Alternatively, we could "fix" LineFileDocs(random), e.g. special compression > options (in blocks)... deflate supports such stuff. But it would make it even > hairier than it is now. -- 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-14420) Address AuthenticationPlugin TODO redeclare params as HttpServletRequest & HttpServletResponse
[ https://issues.apache.org/jira/browse/SOLR-14420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088810#comment-17088810 ] Mike Drob commented on SOLR-14420: -- Yea, added link to the PR at https://github.com/apache/lucene-solr/pull/1442 no idea why it didn't get linked automatically... > Address AuthenticationPlugin TODO redeclare params as HttpServletRequest & > HttpServletResponse > -- > > Key: SOLR-14420 > URL: https://issues.apache.org/jira/browse/SOLR-14420 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: security >Reporter: Mike Drob >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > This was noted in SOLR-11692 and then I think the surrounding code change > more in SOLR-12290, but the TODO remained unaddressed. We can declare this as > HttpServletRequest/Response and all of the usages still work. There are > plenty of implementations where we just do a cast anyway, and don't even do > instanced checks. > I noticed this change for an external auth plugin that I'm working on that > appears to have issues handling casts between ServletRequest and the > CloseShield wrapper classes. -- 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-9321) Port documentation task to gradle
[ https://issues.apache.org/jira/browse/LUCENE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088778#comment-17088778 ] Tomoko Uchida commented on LUCENE-9321: --- In 2020 we could have some modern template engine framework instead of XSL, will try to look for it, but have no strong opinion about replacing it. > Port documentation task to gradle > - > > Key: LUCENE-9321 > URL: https://issues.apache.org/jira/browse/LUCENE-9321 > Project: Lucene - Core > Issue Type: Sub-task > Components: general/build >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Major > > This is a placeholder issue for porting ant "documentation" task to gradle. > The generated documents should be able to be published on lucene.apache.org > web site on "as-is" basis. -- 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-14105) Http2SolrClient SSL not working in branch_8x
[
https://issues.apache.org/jira/browse/SOLR-14105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088776#comment-17088776
]
Akhmad Amirov commented on SOLR-14105:
--
I just followed the doc to enable SSL:
[https://lucene.apache.org/solr/guide/8_5/enabling-ssl.html]. I have only 1
cert in keystore, and the error is from log right after Solr start
> Http2SolrClient SSL not working in branch_8x
>
>
> Key: SOLR-14105
> URL: https://issues.apache.org/jira/browse/SOLR-14105
> Project: Solr
> Issue Type: Bug
>Affects Versions: 8.5
>Reporter: Jan Høydahl
>Assignee: Kevin Risden
>Priority: Major
> Attachments: SOLR-14105.patch
>
>
> In branch_8x we upgraded to Jetty 9.4.24. This causes the following
> exceptions when attempting to start server with SSL:
> {noformat}
> 2019-12-17 14:46:16.646 ERROR (main) [ ] o.a.s.c.SolrCore
> null:org.apache.solr.common.SolrException: Error instantiating
> shardHandlerFactory class [HttpShardHandlerFactory]:
> java.lang.UnsupportedOperationException: X509ExtendedKeyManager only
> supported on Server
> at
> org.apache.solr.handler.component.ShardHandlerFactory.newInstance(ShardHandlerFactory.java:56)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:633)
> ...
> Caused by: java.lang.RuntimeException:
> java.lang.UnsupportedOperationException: X509ExtendedKeyManager only
> supported on Server
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.createHttpClient(Http2SolrClient.java:224)
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.(Http2SolrClient.java:154)
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient$Builder.build(Http2SolrClient.java:833)
> at
> org.apache.solr.handler.component.HttpShardHandlerFactory.init(HttpShardHandlerFactory.java:321)
> at
> org.apache.solr.handler.component.ShardHandlerFactory.newInstance(ShardHandlerFactory.java:51)
> ... 50 more
> Caused by: java.lang.UnsupportedOperationException: X509ExtendedKeyManager
> only supported on Server
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.newSniX509ExtendedKeyManager(SslContextFactory.java:1273)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.getKeyManagers(SslContextFactory.java:1255)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.load(SslContextFactory.java:374)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.doStart(SslContextFactory.java:245)
> {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] (LUCENE-9321) Port documentation task to gradle
[
https://issues.apache.org/jira/browse/LUCENE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088767#comment-17088767
]
Tomoko Uchida commented on LUCENE-9321:
---
Thank you for the feedback. I have a few experiences with XSL and XSLT (quite a
long time ago) and don't hate them; the stuff that confused me here were the
ant magics to extract the parameters that are passed to from the
codebase, and macro. I think I got the points (maybe). Let me see if
I can do the job.
I think the gradle scripts for "documentation" can be placed into
{{gradle/documentation}} folder and this could look like:
{code}
gradle/documentation
|- documentation.gradle (a parent or placeholder task)
|- changes-to-html.gradle
|- process-index-html.gradle
|- process-text-to-html.gradle
{code}
> Port documentation task to gradle
> -
>
> Key: LUCENE-9321
> URL: https://issues.apache.org/jira/browse/LUCENE-9321
> Project: Lucene - Core
> Issue Type: Sub-task
> Components: general/build
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Major
>
> This is a placeholder issue for porting ant "documentation" task to gradle.
> The generated documents should be able to be published on lucene.apache.org
> web site on "as-is" basis.
--
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-9336) RegExp.java - add support for character classes like \w
Mark Harwood created LUCENE-9336: Summary: RegExp.java - add support for character classes like \w Key: LUCENE-9336 URL: https://issues.apache.org/jira/browse/LUCENE-9336 Project: Lucene - Core Issue Type: Improvement Components: core/other Reporter: Mark Harwood Assignee: Mark Harwood Character classes commonly used in regular expressions like \s for whitespace are not currently supported and may well be returning false negatives because they don't throw any "unsupported" errors. The proposal is that the RegExp class add support for the set of character classes [defined by Java's Pattern API|https://docs.oracle.com/javase/tutorial/essential/regex/pre_char_classes.html] I can work on a patch if we think this is something we want to consider. -- 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-14422) Solr 8.5 Admin UI shows Angular placeholders on first load / refresh
[ https://issues.apache.org/jira/browse/SOLR-14422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088749#comment-17088749 ] Colvin Cowie edited comment on SOLR-14422 at 4/21/20, 2:37 PM: --- np. It looks like it would work on the `` but I don't _think_ you can go more granular than that (without adding another div) was (Author: cjcowie): np. It looks like it would work on the `` but I don't _think_ you can go more granular than that > Solr 8.5 Admin UI shows Angular placeholders on first load / refresh > > > Key: SOLR-14422 > URL: https://issues.apache.org/jira/browse/SOLR-14422 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 8.5, 8.5.1 >Reporter: Colvin Cowie >Priority: Minor > Attachments: SOLR-14422.patch, image-2020-04-21-14-51-18-923.png > > > When loading / refreshing the Admin UI in 8.5.1, it briefly but _visibly_ > shows a placeholder for the "SolrCore Initialization Failures" error message, > with a lot of redness. It looks like there is a real problem. Obviously the > message then disappears, and it can be ignored. > However, if I was a first time user, it would not give me confidence that > everything is okay. In a way, an error message that appears briefly then > disappears before I can finish reading it is worse than one which just stays > there. > > Here's a screenshot of what I mean !image-2020-04-21-14-51-18-923.png! > > I suspect that SOLR-14132 will have caused this > > From a (very) brief googling it seems like using the ng-cloak attribute is > the right way to fix this, and it certainly seems to work for me. > https://docs.angularjs.org/api/ng/directive/ngCloak > I will attach a patch with it, but if someone who actually knows Angular etc > has a better approach then please go for 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] [Comment Edited] (SOLR-14422) Solr 8.5 Admin UI shows Angular placeholders on first load / refresh
[ https://issues.apache.org/jira/browse/SOLR-14422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088734#comment-17088734 ] Kevin Risden edited comment on SOLR-14422 at 4/21/20, 2:24 PM: --- Thanks [~cjcowie]! Sorry if I caused this upgrading Angular :( The patch looks reasonable at first glance. I'm not sure if ngCloak can be put on a smaller dom element than the body like the docs say. I'm not super familiar with it. I'll try to take look soon. was (Author: risdenk): Thanks [~cjcowie]! Sorry if I caused this upgrading Angular :( The patch looks reasonable at first glane. I'm not sure if ngCloak can be put on a smaller dom element than the body like the docs say. I'm not super familiar with it. I'll try to take look soon. > Solr 8.5 Admin UI shows Angular placeholders on first load / refresh > > > Key: SOLR-14422 > URL: https://issues.apache.org/jira/browse/SOLR-14422 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 8.5, 8.5.1 >Reporter: Colvin Cowie >Priority: Minor > Attachments: SOLR-14422.patch, image-2020-04-21-14-51-18-923.png > > > When loading / refreshing the Admin UI in 8.5.1, it briefly but _visibly_ > shows a placeholder for the "SolrCore Initialization Failures" error message, > with a lot of redness. It looks like there is a real problem. Obviously the > message then disappears, and it can be ignored. > However, if I was a first time user, it would not give me confidence that > everything is okay. In a way, an error message that appears briefly then > disappears before I can finish reading it is worse than one which just stays > there. > > Here's a screenshot of what I mean !image-2020-04-21-14-51-18-923.png! > > I suspect that SOLR-14132 will have caused this > > From a (very) brief googling it seems like using the ng-cloak attribute is > the right way to fix this, and it certainly seems to work for me. > https://docs.angularjs.org/api/ng/directive/ngCloak > I will attach a patch with it, but if someone who actually knows Angular etc > has a better approach then please go for 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-7642) Should launching Solr in cloud mode using a ZooKeeper chroot create the chroot znode if it doesn't exist?
[
https://issues.apache.org/jira/browse/SOLR-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088728#comment-17088728
]
Jan Høydahl commented on SOLR-7642:
---
I'll not block it.
The patch needs refguide docs.
Should it also be documented in bin/solr -h?
Should "/solr" be an always-whitelisted path?
Nipick: Consider terminology - is it zkRoot or zkChRoot?
> Should launching Solr in cloud mode using a ZooKeeper chroot create the
> chroot znode if it doesn't exist?
> -
>
> Key: SOLR-7642
> URL: https://issues.apache.org/jira/browse/SOLR-7642
> Project: Solr
> Issue Type: Improvement
>Reporter: Timothy Potter
>Priority: Minor
> Attachments: SOLR-7642.patch, SOLR-7642.patch, SOLR-7642.patch,
> SOLR-7642_tag_7.5.0.patch, SOLR-7642_tag_7.5.0_proposition.patch
>
>
> If you launch Solr for the first time in cloud mode using a ZooKeeper
> connection string that includes a chroot leads to the following
> initialization error:
> {code}
> ERROR - 2015-06-05 17:15:50.410; [ ] org.apache.solr.common.SolrException;
> null:org.apache.solr.common.cloud.ZooKeeperException: A chroot was specified
> in ZkHost but the znode doesn't exist. localhost:2181/lan
> at
> org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:113)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:339)
> at
> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:140)
> at
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:110)
> at
> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:138)
> at
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:852)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:298)
> at
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> at
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
> at
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
> {code}
> The work-around for this is to use the scripts/cloud-scripts/zkcli.sh script
> to create the chroot znode (bootstrap action does this).
> I'm wondering if we shouldn't just create the znode if it doesn't exist? Or
> is that some violation of using a chroot?
--
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-14422) Solr 8.5 Admin UI shows Angular placeholders on first load / refresh
[ https://issues.apache.org/jira/browse/SOLR-14422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colvin Cowie updated SOLR-14422: Status: Patch Available (was: Open) > Solr 8.5 Admin UI shows Angular placeholders on first load / refresh > > > Key: SOLR-14422 > URL: https://issues.apache.org/jira/browse/SOLR-14422 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 8.5, 8.5.1 >Reporter: Colvin Cowie >Priority: Minor > Attachments: SOLR-14422.patch, image-2020-04-21-14-51-18-923.png > > > When loading / refreshing the Admin UI in 8.5.1, it briefly but _visibly_ > shows a placeholder for the "SolrCore Initialization Failures" error message, > with a lot of redness. It looks like there is a real problem. Obviously the > message then disappears, and it can be ignored. > However, if I was a first time user, it would not give me confidence that > everything is okay. In a way, an error message that appears briefly then > disappears before I can finish reading it is worse than one which just stays > there. > > Here's a screenshot of what I mean !image-2020-04-21-14-51-18-923.png! > > I suspect that SOLR-14132 will have caused this > > From a (very) brief googling it seems like using the ng-cloak attribute is > the right way to fix this, and it certainly seems to work for me. > https://docs.angularjs.org/api/ng/directive/ngCloak > I will attach a patch with it, but if someone who actually knows Angular etc > has a better approach then please go for 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-14422) Solr 8.5 Admin UI shows Angular placeholders on first load / refresh
[ https://issues.apache.org/jira/browse/SOLR-14422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088719#comment-17088719 ] Colvin Cowie commented on SOLR-14422: - Hi [~rcmuir] [~krisden] can you check this? Thanks. > Solr 8.5 Admin UI shows Angular placeholders on first load / refresh > > > Key: SOLR-14422 > URL: https://issues.apache.org/jira/browse/SOLR-14422 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 8.5, 8.5.1 >Reporter: Colvin Cowie >Priority: Minor > Attachments: SOLR-14422.patch, image-2020-04-21-14-51-18-923.png > > > When loading / refreshing the Admin UI in 8.5.1, it briefly but _visibly_ > shows a placeholder for the "SolrCore Initialization Failures" error message, > with a lot of redness. It looks like there is a real problem. Obviously the > message then disappears, and it can be ignored. > However, if I was a first time user, it would not give me confidence that > everything is okay. In a way, an error message that appears briefly then > disappears before I can finish reading it is worse than one which just stays > there. > > Here's a screenshot of what I mean !image-2020-04-21-14-51-18-923.png! > > I suspect that SOLR-14132 will have caused this > > From a (very) brief googling it seems like using the ng-cloak attribute is > the right way to fix this, and it certainly seems to work for me. > https://docs.angularjs.org/api/ng/directive/ngCloak > I will attach a patch with it, but if someone who actually knows Angular etc > has a better approach then please go for 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] [Updated] (SOLR-14422) Solr 8.5 Admin UI shows Angular placeholders on first load / refresh
[ https://issues.apache.org/jira/browse/SOLR-14422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colvin Cowie updated SOLR-14422: Attachment: SOLR-14422.patch > Solr 8.5 Admin UI shows Angular placeholders on first load / refresh > > > Key: SOLR-14422 > URL: https://issues.apache.org/jira/browse/SOLR-14422 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 8.5, 8.5.1 >Reporter: Colvin Cowie >Priority: Minor > Attachments: SOLR-14422.patch, image-2020-04-21-14-51-18-923.png > > > When loading / refreshing the Admin UI in 8.5.1, it briefly but _visibly_ > shows a placeholder for the "SolrCore Initialization Failures" error message, > with a lot of redness. It looks like there is a real problem. Obviously the > message then disappears, and it can be ignored. > However, if I was a first time user, it would not give me confidence that > everything is okay. In a way, an error message that appears briefly then > disappears before I can finish reading it is worse than one which just stays > there. > > Here's a screenshot of what I mean !image-2020-04-21-14-51-18-923.png! > > I suspect that SOLR-14132 will have caused this > > From a (very) brief googling it seems like using the ng-cloak attribute is > the right way to fix this, and it certainly seems to work for me. > https://docs.angularjs.org/api/ng/directive/ngCloak > I will attach a patch with it, but if someone who actually knows Angular etc > has a better approach then please go for 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] [Comment Edited] (SOLR-12182) Can not switch urlScheme in 7x if there are any cores in the cluster
[ https://issues.apache.org/jira/browse/SOLR-12182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088708#comment-17088708 ] Gus Heck edited comment on SOLR-12182 at 4/21/20, 1:58 PM: --- Another thought about testing... Such a script should rely on invoking a java class to do most of the work. This can then be invoked on a zookeeper that is brought up in a test and the result checked for the presence of http:// (or https for the alternate conversion) Also, I'm not sue a simple global regex/replace on the state.json is safe, since I can imagine security.json might have URL's to authentication services (not sure there). But if one grabs the list of URL's from state.json, the scheme through machine:port section is probably safe for global replace. was (Author: gus_heck): Another thought about testing... Such a script should rely on invoking a java class to do most of the work. This can then be invoked on a zookeeper that is brought up in a test and the result checked for the presence of http:// (or https for the alternate conversion) > Can not switch urlScheme in 7x if there are any cores in the cluster > > > Key: SOLR-12182 > URL: https://issues.apache.org/jira/browse/SOLR-12182 > Project: Solr > Issue Type: Bug >Affects Versions: 7.0, 7.1, 7.2 >Reporter: Anshum Gupta >Priority: Major > Attachments: SOLR-12182.patch > > > I was trying to enable TLS on a cluster that was already in use i.e. had > existing collections and ended up with down cores, that wouldn't come up and > the following core init errors in the logs: > *org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: > replica with coreNodeName core_node4 exists but with a different name or > base_url.* > What is happening here is that the core/replica is defined in the > clusterstate with the urlScheme as part of it's base URL e.g. > *"base_url":"http:hostname:port/solr"*. > Switching the urlScheme in Solr breaks this convention as the host now uses > HTTPS instead. > Actually, I ran into this with an older version because I was running with > *legacyCloud=false* and then realized that we switched that to the default > behavior only in 7x i.e while most users did not hit this issue with older > versions, unless they overrode the legacyCloud value explicitly, users > running 7x are bound to run into this more often. > Switching the value of legacyCloud to true, bouncing the cluster so that the > clusterstate gets flushed, and then setting it back to false is a workaround > but a bit risky one if you don't know if you have any old cores lying around. > Ideally, I think we shouldn't prepend the urlScheme to the base_url value and > use the urlScheme on the fly to construct 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-7642) Should launching Solr in cloud mode using a ZooKeeper chroot create the chroot znode if it doesn't exist?
[
https://issues.apache.org/jira/browse/SOLR-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088716#comment-17088716
]
David Eric Pugh commented on SOLR-7642:
---
So [~gus] [~janhoy] is there enough consensus on solving this? I'd be
interested in testing out [~igiguere] patch and commiting it if you think this
is a reasonable approach.
> Should launching Solr in cloud mode using a ZooKeeper chroot create the
> chroot znode if it doesn't exist?
> -
>
> Key: SOLR-7642
> URL: https://issues.apache.org/jira/browse/SOLR-7642
> Project: Solr
> Issue Type: Improvement
>Reporter: Timothy Potter
>Priority: Minor
> Attachments: SOLR-7642.patch, SOLR-7642.patch, SOLR-7642.patch,
> SOLR-7642_tag_7.5.0.patch, SOLR-7642_tag_7.5.0_proposition.patch
>
>
> If you launch Solr for the first time in cloud mode using a ZooKeeper
> connection string that includes a chroot leads to the following
> initialization error:
> {code}
> ERROR - 2015-06-05 17:15:50.410; [ ] org.apache.solr.common.SolrException;
> null:org.apache.solr.common.cloud.ZooKeeperException: A chroot was specified
> in ZkHost but the znode doesn't exist. localhost:2181/lan
> at
> org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:113)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:339)
> at
> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:140)
> at
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:110)
> at
> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:138)
> at
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:852)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:298)
> at
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> at
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
> at
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
> {code}
> The work-around for this is to use the scripts/cloud-scripts/zkcli.sh script
> to create the chroot znode (bootstrap action does this).
> I'm wondering if we shouldn't just create the znode if it doesn't exist? Or
> is that some violation of using a chroot?
--
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-14422) Solr 8.5 Admin UI shows Angular placeholders on first load / refresh
Colvin Cowie created SOLR-14422: --- Summary: Solr 8.5 Admin UI shows Angular placeholders on first load / refresh Key: SOLR-14422 URL: https://issues.apache.org/jira/browse/SOLR-14422 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: Admin UI Affects Versions: 8.5.1, 8.5 Reporter: Colvin Cowie Attachments: image-2020-04-21-14-51-18-923.png When loading / refreshing the Admin UI in 8.5.1, it briefly but _visibly_ shows a placeholder for the "SolrCore Initialization Failures" error message, with a lot of redness. It looks like there is a real problem. Obviously the message then disappears, and it can be ignored. However, if I was a first time user, it would not give me confidence that everything is okay. In a way, an error message that appears briefly then disappears before I can finish reading it is worse than one which just stays there. Here's a screenshot of what I mean !image-2020-04-21-14-51-18-923.png! I suspect that SOLR-14132 will have caused this >From a (very) brief googling it seems like using the ng-cloak attribute is the >right way to fix this, and it certainly seems to work for me. >https://docs.angularjs.org/api/ng/directive/ngCloak I will attach a patch with it, but if someone who actually knows Angular etc has a better approach then please go for 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-12182) Can not switch urlScheme in 7x if there are any cores in the cluster
[ https://issues.apache.org/jira/browse/SOLR-12182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088708#comment-17088708 ] Gus Heck commented on SOLR-12182: - Another thought about testing... Such a script should rely on invoking a java class to do most of the work. This can then be invoked on a zookeeper that is brought up in a test and the result checked for the presence of http:// (or https for the alternate conversion) > Can not switch urlScheme in 7x if there are any cores in the cluster > > > Key: SOLR-12182 > URL: https://issues.apache.org/jira/browse/SOLR-12182 > Project: Solr > Issue Type: Bug >Affects Versions: 7.0, 7.1, 7.2 >Reporter: Anshum Gupta >Priority: Major > Attachments: SOLR-12182.patch > > > I was trying to enable TLS on a cluster that was already in use i.e. had > existing collections and ended up with down cores, that wouldn't come up and > the following core init errors in the logs: > *org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: > replica with coreNodeName core_node4 exists but with a different name or > base_url.* > What is happening here is that the core/replica is defined in the > clusterstate with the urlScheme as part of it's base URL e.g. > *"base_url":"http:hostname:port/solr"*. > Switching the urlScheme in Solr breaks this convention as the host now uses > HTTPS instead. > Actually, I ran into this with an older version because I was running with > *legacyCloud=false* and then realized that we switched that to the default > behavior only in 7x i.e while most users did not hit this issue with older > versions, unless they overrode the legacyCloud value explicitly, users > running 7x are bound to run into this more often. > Switching the value of legacyCloud to true, bouncing the cluster so that the > clusterstate gets flushed, and then setting it back to false is a workaround > but a bit risky one if you don't know if you have any old cores lying around. > Ideally, I think we shouldn't prepend the urlScheme to the base_url value and > use the urlScheme on the fly to construct 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] [Comment Edited] (SOLR-14408) Refactor MoreLikeThisHandler Implementation
[ https://issues.apache.org/jira/browse/SOLR-14408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17083995#comment-17083995 ] Nazerke Seidan edited comment on SOLR-14408 at 4/21/20, 1:27 PM: - [~alessandro.benedetti] I've linked the PR was (Author: seidan): just linked the PR > Refactor MoreLikeThisHandler Implementation > --- > > Key: SOLR-14408 > URL: https://issues.apache.org/jira/browse/SOLR-14408 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: MoreLikeThis >Reporter: Nazerke Seidan >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > The main goal of this refactoring is for readability and accessibility of > MoreLikeThisHandler class. Current MoreLikeThisHandler class consists of two > static subclasses and accessing them later in MoreLikeThisComponent. I > propose to have them as separate public classes. > cc: [~abenedetti], as you have had the recent commit for MLT, what do you > think about this? Anyway, the code is ready for review. > > > -- 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-12182) Can not switch urlScheme in 7x if there are any cores in the cluster
[
https://issues.apache.org/jira/browse/SOLR-12182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088685#comment-17088685
]
Gus Heck commented on SOLR-12182:
-
The suggested scheme-less base url is going to imply additional string
manipulation and at least one more string object of garbage per shard per
request. If we try to cache the manipulated string somewhere other than
zookeeper that's bad duplicated state. I think this should be solved with a
combination of
# a script to upgrade all URLs zookeeper
# tolerant code that only runs if a cluster property is set (default not set)
Something like
{code:java}/bin/solr migrate (http|https){code}
Thus the upgrade case is take the cluster down or set the cluster prop, run
the upgrade and then unset the cluster property or reboot it. The bit I don't
know without a little research is how quickly the cluster property is likely to
get re-read by the nodes.
A quick scan of one existing system shows there are urls in state.json and
/leaders. I'm not sure off the top of my head if anywhere else might might
contain URL's that need adjusted, but that should be researched.
As I type this I wonder about the wisdom of the tolerant code state at all
(including not storing the scheme). It adds a rarely used code path to deal
with legacy/incorrect schemes that probably needs to be tested by setting the
cluster prop (or not) randomly on all tests to ensure we catch issues in the
cluster-prop case and may be quite difficult to test comprehensively in the
scheme-less case. As we accumulate more such randomized cases the number of
test runs to ensure a good build rises, especially if the randomized features
might only fail in cases where two specific random states are set. In any case
it's a code path very likely to be forgotten in implementation of future
features and still adds one (tiny) increment of processing.
Switching to (or away from) HTTPS is major change, and maybe it's just better
to require down time to keep the code simple. Any tolerant code needs to be
sure it is applied (as a utility function) to every area of the code that could
possibly want to read the URL, if we miss something, terrible subtle bugs might
arise.
Also, what if 3rd party code is checking the urls in zookeeper for custom
components/plugins? Scheme-less URL's could be a breaking change from that
perspective.
> Can not switch urlScheme in 7x if there are any cores in the cluster
>
>
> Key: SOLR-12182
> URL: https://issues.apache.org/jira/browse/SOLR-12182
> Project: Solr
> Issue Type: Bug
>Affects Versions: 7.0, 7.1, 7.2
>Reporter: Anshum Gupta
>Priority: Major
> Attachments: SOLR-12182.patch
>
>
> I was trying to enable TLS on a cluster that was already in use i.e. had
> existing collections and ended up with down cores, that wouldn't come up and
> the following core init errors in the logs:
> *org.apache.solr.common.SolrException:org.apache.solr.common.SolrException:
> replica with coreNodeName core_node4 exists but with a different name or
> base_url.*
> What is happening here is that the core/replica is defined in the
> clusterstate with the urlScheme as part of it's base URL e.g.
> *"base_url":"http:hostname:port/solr"*.
> Switching the urlScheme in Solr breaks this convention as the host now uses
> HTTPS instead.
> Actually, I ran into this with an older version because I was running with
> *legacyCloud=false* and then realized that we switched that to the default
> behavior only in 7x i.e while most users did not hit this issue with older
> versions, unless they overrode the legacyCloud value explicitly, users
> running 7x are bound to run into this more often.
> Switching the value of legacyCloud to true, bouncing the cluster so that the
> clusterstate gets flushed, and then setting it back to false is a workaround
> but a bit risky one if you don't know if you have any old cores lying around.
> Ideally, I think we shouldn't prepend the urlScheme to the base_url value and
> use the urlScheme on the fly to construct 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] [Updated] (SOLR-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
[
https://issues.apache.org/jira/browse/SOLR-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-14421:
---
Resolution: Fixed
Status: Resolved (was: Patch Available)
Thanks for the patch and the review :)
> New examples in solr.in.cmd in Solr 8.5 don't work as provided
> --
>
> Key: SOLR-14421
> URL: https://issues.apache.org/jira/browse/SOLR-14421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: 8.6
>
> Attachments: SOLR-14421.patch
>
>
>
> These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
> surrounded with quotes
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199]
> {noformat}
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
> REM Specifies the path to a common library directory that will be shared
> across all cores.
> REM Any JAR files in this directory will be added to the search path for Solr
> plugins.
> REM If the specified path is not absolute, it will be relative to
> `%SOLR_HOME%`.
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
> {noformat}
> Without set you will get "_'SOLR_OPTS' is not recognized as an internal or
> external command, operable program or batch file_."
> After adding _set,_ with the quotes you get _"-Dsolr.environment=prod was
> unexpected at this time."_
> I'll attach a 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-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
[
https://issues.apache.org/jira/browse/SOLR-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088669#comment-17088669
]
ASF subversion and git services commented on SOLR-14421:
Commit 606cb7e5342cc905f54ad4335f0e79ce6731282e in lucene-solr's branch
refs/heads/branch_8x from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=606cb7e ]
SOLR-14421: Fix non-working examples in solr.in.cmd
(cherry picked from commit c9cd623a62c56d8f5f9ac88d341395d9cb2cb3ce)
> New examples in solr.in.cmd in Solr 8.5 don't work as provided
> --
>
> Key: SOLR-14421
> URL: https://issues.apache.org/jira/browse/SOLR-14421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: 8.6
>
> Attachments: SOLR-14421.patch
>
>
>
> These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
> surrounded with quotes
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199]
> {noformat}
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
> REM Specifies the path to a common library directory that will be shared
> across all cores.
> REM Any JAR files in this directory will be added to the search path for Solr
> plugins.
> REM If the specified path is not absolute, it will be relative to
> `%SOLR_HOME%`.
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
> {noformat}
> Without set you will get "_'SOLR_OPTS' is not recognized as an internal or
> external command, operable program or batch file_."
> After adding _set,_ with the quotes you get _"-Dsolr.environment=prod was
> unexpected at this time."_
> I'll attach a 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-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
[
https://issues.apache.org/jira/browse/SOLR-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088666#comment-17088666
]
ASF subversion and git services commented on SOLR-14421:
Commit c9cd623a62c56d8f5f9ac88d341395d9cb2cb3ce in lucene-solr's branch
refs/heads/master from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c9cd623 ]
SOLR-14421: Fix non-working examples in solr.in.cmd
> New examples in solr.in.cmd in Solr 8.5 don't work as provided
> --
>
> Key: SOLR-14421
> URL: https://issues.apache.org/jira/browse/SOLR-14421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: 8.6
>
> Attachments: SOLR-14421.patch
>
>
>
> These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
> surrounded with quotes
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199]
> {noformat}
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
> REM Specifies the path to a common library directory that will be shared
> across all cores.
> REM Any JAR files in this directory will be added to the search path for Solr
> plugins.
> REM If the specified path is not absolute, it will be relative to
> `%SOLR_HOME%`.
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
> {noformat}
> Without set you will get "_'SOLR_OPTS' is not recognized as an internal or
> external command, operable program or batch file_."
> After adding _set,_ with the quotes you get _"-Dsolr.environment=prod was
> unexpected at this time."_
> I'll attach a 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
[GitHub] [lucene-solr] noblepaul commented on a change in pull request #1432: SOLR-14404 CoreContainer level custom requesthandlers
noblepaul commented on a change in pull request #1432:
URL: https://github.com/apache/lucene-solr/pull/1432#discussion_r412151606
##
File path: solr/core/src/test-files/runtimecode/MyPlugin.java
##
@@ -0,0 +1,43 @@
+/*
+ * 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.handler;
+
+import org.apache.solr.api.Command;
+import org.apache.solr.api.EndPoint;
+import org.apache.solr.client.solrj.SolrRequest.METHOD;
+import org.apache.solr.core.CoreContainer;
+import org.apache.solr.request.SolrQueryRequest;
+import org.apache.solr.response.SolrQueryResponse;
+import org.apache.solr.security.PermissionNameProvider;
+
+@EndPoint(path = "/plugin/my/path",
+method = METHOD.GET,
+permission = PermissionNameProvider.Name.CONFIG_READ_PERM)
+public class MyPlugin {
Review comment:
This is for documentation purposes for anyone who wants to know what the
code looks like. Yes, we could possibly have 2 files, but then , they will have
to be different files and the class name can't match the file name
> Can we do this some other way,
Unfortunately it's so hard. We need to ensure that these classes are never
in the classpath. If we try to compile it some other way, it may come under the
classpath and the purpose of the test is defeated. I'm not saying it is not
possible, but it is not easy
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] noblepaul commented on a change in pull request #1432: SOLR-14404 CoreContainer level custom requesthandlers
noblepaul commented on a change in pull request #1432:
URL: https://github.com/apache/lucene-solr/pull/1432#discussion_r412151606
##
File path: solr/core/src/test-files/runtimecode/MyPlugin.java
##
@@ -0,0 +1,43 @@
+/*
+ * 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.handler;
+
+import org.apache.solr.api.Command;
+import org.apache.solr.api.EndPoint;
+import org.apache.solr.client.solrj.SolrRequest.METHOD;
+import org.apache.solr.core.CoreContainer;
+import org.apache.solr.request.SolrQueryRequest;
+import org.apache.solr.response.SolrQueryResponse;
+import org.apache.solr.security.PermissionNameProvider;
+
+@EndPoint(path = "/plugin/my/path",
+method = METHOD.GET,
+permission = PermissionNameProvider.Name.CONFIG_READ_PERM)
+public class MyPlugin {
Review comment:
This is for documentation purposes for anyone who wants to know what the
code looks like. Yes, we could possibly have 2 files, but then , they will have
to be different files
> Can we do this some other way,
Unfortunately no. We need to have it compiled with an old version of java.
It has to be precreated
>
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] noblepaul commented on a change in pull request #1432: SOLR-14404 CoreContainer level custom requesthandlers
noblepaul commented on a change in pull request #1432:
URL: https://github.com/apache/lucene-solr/pull/1432#discussion_r412149820
##
File path: solr/core/src/java/org/apache/solr/pkg/PackageListeners.java
##
@@ -63,13 +63,13 @@ public synchronized void removeListener(Listener listener) {
}
synchronized void packagesUpdated(List pkgs) {
-MDCLoggingContext.setCore(core);
Review comment:
because we are calling a
`MDCLoggingContext.clear();` in finally
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-9317) Resolve package name conflicts for StandardAnalyzer to allow Java module system support
[
https://issues.apache.org/jira/browse/LUCENE-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088640#comment-17088640
]
Uwe Schindler commented on LUCENE-9317:
---
Hi,
why do you want to proxy the static methods? The idea behind the additional
class was just to allow code to extend the class without refactoring the code.
It's allowed in Java to call static methods also on subclasses. This is enough
as workaround.
In short: just add the abstract class with same name in util package as
@Deprecated and let it extend the original one class from one package higher.
Nothing else:
{code:java}
package org.apach.lucene.analysis.util;
@Deprecated
public abstract class TokenFilterFactory extends
org.apach.lucene.analysis.TokenFilterFactory {
// constructors, nothing else!
}
{code}
> Resolve package name conflicts for StandardAnalyzer to allow Java module
> system support
> ---
>
> Key: LUCENE-9317
> URL: https://issues.apache.org/jira/browse/LUCENE-9317
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/other
>Affects Versions: master (9.0)
>Reporter: David Ryan
>Priority: Major
> Labels: build, features
>
>
> To allow Lucene to be modularised there are a few preparatory tasks to be
> completed prior to this being possible. The Java module system requires that
> jars do not use the same package name in different jars. The lucene-core and
> lucene-analyzers-common both share the package
> org.apache.lucene.analysis.standard.
> Possible resolutions to this issue are discussed by Uwe on the mailing list
> here:
>
> [http://mail-archives.apache.org/mod_mbox/lucene-dev/202004.mbox/%3CCAM21Rt8FHOq_JeUSELhsQJH0uN0eKBgduBQX4fQKxbs49TLqzA%40mail.gmail.com%3E]
> {quote}About StandardAnalyzer: Unfortunately I aggressively complained a
> while back when Mike McCandless wanted to move standard analyzer out of the
> analysis package into core (“for convenience”). This was a bad step, and IMHO
> we should revert that or completely rename the packages and everything. The
> problem here is: As the analysis services are only part of lucene-analyzers,
> we had to leave the factory classes there, but move the implementation
> classes in core. The package has to be the same. The only way around that is
> to move the analysis factory framework also to core (I would not be against
> that). This would include all factory base classes and the service loading
> stuff. Then we can move standard analyzer and some of the filters/tokenizers
> including their factories to core an that problem would be solved.
> {quote}
> There are two options here, either move factory framework into core or revert
> StandardAnalyzer back to lucene-analyzers. In the email, the solution lands
> on reverting back as per the task list:
> {quote}Add some preparatory issues to cleanup class hierarchy: Move Analysis
> SPI to core / remove StandardAnalyzer and related classes out of core back to
> anaysis
> {quote}
>
>
>
>
--
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] noblepaul commented on a change in pull request #1432: SOLR-14404 CoreContainer level custom requesthandlers
noblepaul commented on a change in pull request #1432:
URL: https://github.com/apache/lucene-solr/pull/1432#discussion_r412148113
##
File path:
solr/core/src/java/org/apache/solr/handler/admin/ContainerPluginsApi.java
##
@@ -0,0 +1,178 @@
+/*
+ * 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.handler.admin;
+
+import java.io.IOException;
+import java.lang.invoke.MethodHandles;
+import java.util.ArrayList;
+import java.util.LinkedHashMap;
+import java.util.List;
+import java.util.Map;
+import java.util.function.Function;
+import java.util.function.Supplier;
+
+import org.apache.solr.api.AnnotatedApi;
+import org.apache.solr.api.Command;
+import org.apache.solr.api.CustomContainerPlugins;
+import org.apache.solr.api.EndPoint;
+import org.apache.solr.api.PayloadObj;
+import org.apache.solr.client.solrj.SolrRequest.METHOD;
+import org.apache.solr.client.solrj.request.beans.PluginMeta;
+import org.apache.solr.common.cloud.SolrZkClient;
+import org.apache.solr.common.cloud.ZkStateReader;
+import org.apache.solr.common.util.Utils;
+import org.apache.solr.core.CoreContainer;
+import org.apache.solr.request.SolrQueryRequest;
+import org.apache.solr.response.SolrQueryResponse;
+import org.apache.solr.security.PermissionNameProvider;
+import org.apache.zookeeper.KeeperException;
+import org.apache.zookeeper.data.Stat;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import static org.apache.lucene.util.IOUtils.closeWhileHandlingException;
+
+
+public class ContainerPluginsApi {
+ private static final Logger log =
LoggerFactory.getLogger(MethodHandles.lookup().lookupClass());
+
+ public static final String PLUGIN = "plugin";
+ private final Supplier zkClientSupplier;
+ private final CoreContainer coreContainer;
+ public final Read readAPI = new Read();
+ public final Edit editAPI = new Edit();
+
+ public ContainerPluginsApi(CoreContainer coreContainer) {
+this.zkClientSupplier = coreContainer.zkClientSupplier;
+this.coreContainer = coreContainer;
+ }
+
+ @EndPoint(method = METHOD.GET,
+ path = "/cluster/plugin",
+ permission = PermissionNameProvider.Name.COLL_READ_PERM)
+ public class Read {
+
+@Command
+public void list(SolrQueryRequest req, SolrQueryResponse rsp) throws
IOException {
+ rsp.add(PLUGIN, plugins(zkClientSupplier));
+}
+ }
+
+ @EndPoint(method = METHOD.POST,
+ path = "/cluster/plugin",
+ permission = PermissionNameProvider.Name.COLL_EDIT_PERM)
+ public class Edit {
+
+@Command(name = "add")
+public void add(SolrQueryRequest req, SolrQueryResponse rsp,
PayloadObj payload) throws IOException {
+ PluginMeta info = payload.get();
+ validateConfig(payload, info);
+ if(payload.hasError()) return;
+ persistPlugins(map -> {
+if (map.containsKey(info.name)) {
+ payload.addError(info.name + " already exists");
+ return null;
+}
+map.put(info.name, info);
+return map;
+ });
+}
+
+@Command(name = "remove")
+public void remove(SolrQueryRequest req, SolrQueryResponse rsp,
PayloadObj payload) throws IOException {
Review comment:
We could, but , this is the convention that we follow
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-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
[
https://issues.apache.org/jira/browse/SOLR-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088629#comment-17088629
]
Uwe Schindler commented on SOLR-14421:
--
I am fine with that. It's all commented out, so its up to the user to get it
running correctly depending on how his options looks like. The whitespace
should be no issue here. Nevertheless when file system paths are involved,
additional quoting may be required, but this is up to the user and not our deal
(this refers to the last setting that has some example path).
> New examples in solr.in.cmd in Solr 8.5 don't work as provided
> --
>
> Key: SOLR-14421
> URL: https://issues.apache.org/jira/browse/SOLR-14421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: 8.6
>
> Attachments: SOLR-14421.patch
>
>
>
> These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
> surrounded with quotes
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199]
> {noformat}
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
> REM Specifies the path to a common library directory that will be shared
> across all cores.
> REM Any JAR files in this directory will be added to the search path for Solr
> plugins.
> REM If the specified path is not absolute, it will be relative to
> `%SOLR_HOME%`.
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
> {noformat}
> Without set you will get "_'SOLR_OPTS' is not recognized as an internal or
> external command, operable program or batch file_."
> After adding _set,_ with the quotes you get _"-Dsolr.environment=prod was
> unexpected at this time."_
> I'll attach a 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] (LUCENE-9317) Resolve package name conflicts for StandardAnalyzer to allow Java module system support
[
https://issues.apache.org/jira/browse/LUCENE-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088607#comment-17088607
]
David Ryan commented on LUCENE-9317:
Hi [~uschindler]
I've just been looking at moving the factories from oal.analysis.util to
oal.analysis. As suggested I looked at creating some fake subclasses for the
factories in util. Like many things, this is actually more difficult than it
looks. The static methods in the factory are difficult to proxy back to the
moved factory. In particular look at the start of this test fake
TokenFilterFactory:
{code:java}
public abstract class TokenFilterFactory extends
org.apache.lucene.analysis.TokenFilterFactory {
// As this return a fake TokenFilterFactory we would need to wrap the real one
with a factory.
// To make this work ProxyTokenFilterFactory needs to proxy all methods through
to the real factory
public static TokenFilterFactory forName(String name, Map args) {
return new
ProxyTokenFilterFactory(org.apache.lucene.analysis.TokenFilterFactory.forName(name,
args));
}
// As the Class returned by this should extend the fake TokenFilterFactory this
is near impossible to fake.
// There's no real point changing this to return a Class of the real
TokenFilterFactory, because if the user
// tries to instantiate and cast it there will be an error if the class only
extends the moved TokenFilterFactory.
public static Class lookupClass(String name) {
// Type mismatch: cannot convert from Class to
// Class
return org.apache.lucene.analysis.TokenFilterFactory.lookupClass(name);
}
// This method has the same erasure as the parent so can't use the same method
name.
// Name clash: The method findSPIName(Class) of
type TokenFilterFactory
// has the same erasure as findSPIName(Class) of
type TokenFilterFactory
// but does not hide it
public static String findSPIName(Class
serviceClass) {
return org.apache.lucene.analysis.TokenFilterFactory.findSPIName(serviceClass);
}
}
{code}
Based on the above, I'd say there are the following options:
# Don't create the fake factory classes and describe changes required to
upgrade. Requires static methods and extend class package changes.
# -Create a minimal fake factory without any static methods. Allows the user
to continue to extend, but requires any static methods to be updated.- I just
tried this and it won't work as once you move ResourceLoader and
ResourceLoaderAware these can't be faked by extending the interface. May as
well not create the fake factory classes.
# Move the whole util package and as suggested previously and leave names as
is.
# Something else?
I'll leave it at that for today and see if I think of something new tomorrow.
If you'd be happy with option 1 let me know and I'll prepare commits
demonstrating changes.
> Resolve package name conflicts for StandardAnalyzer to allow Java module
> system support
> ---
>
> Key: LUCENE-9317
> URL: https://issues.apache.org/jira/browse/LUCENE-9317
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/other
>Affects Versions: master (9.0)
>Reporter: David Ryan
>Priority: Major
> Labels: build, features
>
>
> To allow Lucene to be modularised there are a few preparatory tasks to be
> completed prior to this being possible. The Java module system requires that
> jars do not use the same package name in different jars. The lucene-core and
> lucene-analyzers-common both share the package
> org.apache.lucene.analysis.standard.
> Possible resolutions to this issue are discussed by Uwe on the mailing list
> here:
>
> [http://mail-archives.apache.org/mod_mbox/lucene-dev/202004.mbox/%3CCAM21Rt8FHOq_JeUSELhsQJH0uN0eKBgduBQX4fQKxbs49TLqzA%40mail.gmail.com%3E]
> {quote}About StandardAnalyzer: Unfortunately I aggressively complained a
> while back when Mike McCandless wanted to move standard analyzer out of the
> analysis package into core (“for convenience”). This was a bad step, and IMHO
> we should revert that or completely rename the packages and everything. The
> problem here is: As the analysis services are only part of lucene-analyzers,
> we had to leave the factory classes there, but move the implementation
> classes in core. The package has to be the same. The only way around that is
> to move the analysis factory framework also to core (I would not be against
> that). This would include all factory base classes and the service loading
> stuff. Then we can move standard analyzer and some of the filters/tokenizers
> including their factories to core an that problem would be solved.
> {quote}
> There are two options here, either move factory framework into core or revert
> StandardAnalyzer back to lucene-analyzers. In
[jira] [Commented] (SOLR-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
[
https://issues.apache.org/jira/browse/SOLR-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088577#comment-17088577
]
Jan Høydahl commented on SOLR-14421:
[~uschindler] with your Windows + Whitespace glasses on, does this look sane?
:)
> New examples in solr.in.cmd in Solr 8.5 don't work as provided
> --
>
> Key: SOLR-14421
> URL: https://issues.apache.org/jira/browse/SOLR-14421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: 8.6
>
> Attachments: SOLR-14421.patch
>
>
>
> These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
> surrounded with quotes
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199]
> {noformat}
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
> REM Specifies the path to a common library directory that will be shared
> across all cores.
> REM Any JAR files in this directory will be added to the search path for Solr
> plugins.
> REM If the specified path is not absolute, it will be relative to
> `%SOLR_HOME%`.
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
> {noformat}
> Without set you will get "_'SOLR_OPTS' is not recognized as an internal or
> external command, operable program or batch file_."
> After adding _set,_ with the quotes you get _"-Dsolr.environment=prod was
> unexpected at this time."_
> I'll attach a 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
[GitHub] [lucene-solr] uschindler commented on issue #1440: LUCENE-9330: Make SortFields responsible for index sorting and serialization
uschindler commented on issue #1440: URL: https://github.com/apache/lucene-solr/pull/1440#issuecomment-617110513 Using SPI makes it much better now! Thanks. 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] (LUCENE-9335) Add a bulk scorer for disjunctions that does dynamic pruning
Adrien Grand created LUCENE-9335: Summary: Add a bulk scorer for disjunctions that does dynamic pruning Key: LUCENE-9335 URL: https://issues.apache.org/jira/browse/LUCENE-9335 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Lucene often gets benchmarked against other engines, e.g. against Tantivy and PISA at [https://tantivy-search.github.io/bench/] or against research prototypes in Table 1 of [https://cs.uwaterloo.ca/~jimmylin/publications/Grand_etal_ECIR2020_preprint.pdf]. Given that top-level disjunctions of term queries are commonly used for benchmarking, it would be nice to optimize this case a bit more, I suspect that we could make fewer per-document decisions by implementing a BulkScorer instead of a Scorer. -- 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-12182) Can not switch urlScheme in 7x if there are any cores in the cluster
[ https://issues.apache.org/jira/browse/SOLR-12182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088558#comment-17088558 ] Gézapeti commented on SOLR-12182: - I'm sorry [~martinentwistle], it looks like I've uploaded a corrupt patch file. It had some logic about leaving out the schema and the ports when doing the comparison in CloudUtil, but it didn't fix the issue. I'll try to dig up the patch, but I'm on a new machine since and I'm not sure it's there. Feel free to pick up the issue if you have the cycles to work on it. Unfortunately I don't, but I'm happy to help if you're stuck. > Can not switch urlScheme in 7x if there are any cores in the cluster > > > Key: SOLR-12182 > URL: https://issues.apache.org/jira/browse/SOLR-12182 > Project: Solr > Issue Type: Bug >Affects Versions: 7.0, 7.1, 7.2 >Reporter: Anshum Gupta >Priority: Major > Attachments: SOLR-12182.patch > > > I was trying to enable TLS on a cluster that was already in use i.e. had > existing collections and ended up with down cores, that wouldn't come up and > the following core init errors in the logs: > *org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: > replica with coreNodeName core_node4 exists but with a different name or > base_url.* > What is happening here is that the core/replica is defined in the > clusterstate with the urlScheme as part of it's base URL e.g. > *"base_url":"http:hostname:port/solr"*. > Switching the urlScheme in Solr breaks this convention as the host now uses > HTTPS instead. > Actually, I ran into this with an older version because I was running with > *legacyCloud=false* and then realized that we switched that to the default > behavior only in 7x i.e while most users did not hit this issue with older > versions, unless they overrode the legacyCloud value explicitly, users > running 7x are bound to run into this more often. > Switching the value of legacyCloud to true, bouncing the cluster so that the > clusterstate gets flushed, and then setting it back to false is a workaround > but a bit risky one if you don't know if you have any old cores lying around. > Ideally, I think we shouldn't prepend the urlScheme to the base_url value and > use the urlScheme on the fly to construct 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-9317) Resolve package name conflicts for StandardAnalyzer to allow Java module system support
[
https://issues.apache.org/jira/browse/LUCENE-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088557#comment-17088557
]
Uwe Schindler commented on LUCENE-9317:
---
Hi,
I agree with this plan. I am not yet 100% sure if we should move CustomAnalyzer
to core. I'd like to get some feedback by others.
Uwe
> Resolve package name conflicts for StandardAnalyzer to allow Java module
> system support
> ---
>
> Key: LUCENE-9317
> URL: https://issues.apache.org/jira/browse/LUCENE-9317
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/other
>Affects Versions: master (9.0)
>Reporter: David Ryan
>Priority: Major
> Labels: build, features
>
>
> To allow Lucene to be modularised there are a few preparatory tasks to be
> completed prior to this being possible. The Java module system requires that
> jars do not use the same package name in different jars. The lucene-core and
> lucene-analyzers-common both share the package
> org.apache.lucene.analysis.standard.
> Possible resolutions to this issue are discussed by Uwe on the mailing list
> here:
>
> [http://mail-archives.apache.org/mod_mbox/lucene-dev/202004.mbox/%3CCAM21Rt8FHOq_JeUSELhsQJH0uN0eKBgduBQX4fQKxbs49TLqzA%40mail.gmail.com%3E]
> {quote}About StandardAnalyzer: Unfortunately I aggressively complained a
> while back when Mike McCandless wanted to move standard analyzer out of the
> analysis package into core (“for convenience”). This was a bad step, and IMHO
> we should revert that or completely rename the packages and everything. The
> problem here is: As the analysis services are only part of lucene-analyzers,
> we had to leave the factory classes there, but move the implementation
> classes in core. The package has to be the same. The only way around that is
> to move the analysis factory framework also to core (I would not be against
> that). This would include all factory base classes and the service loading
> stuff. Then we can move standard analyzer and some of the filters/tokenizers
> including their factories to core an that problem would be solved.
> {quote}
> There are two options here, either move factory framework into core or revert
> StandardAnalyzer back to lucene-analyzers. In the email, the solution lands
> on reverting back as per the task list:
> {quote}Add some preparatory issues to cleanup class hierarchy: Move Analysis
> SPI to core / remove StandardAnalyzer and related classes out of core back to
> anaysis
> {quote}
>
>
>
>
--
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-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
[
https://issues.apache.org/jira/browse/SOLR-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088544#comment-17088544
]
Colvin Cowie commented on SOLR-14421:
-
It seems ok with the quotes stripped from all of them. Does make me slightly
uneasy, but that's the CMD way.
> New examples in solr.in.cmd in Solr 8.5 don't work as provided
> --
>
> Key: SOLR-14421
> URL: https://issues.apache.org/jira/browse/SOLR-14421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: 8.6
>
> Attachments: SOLR-14421.patch
>
>
>
> These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
> surrounded with quotes
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199]
> {noformat}
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
> REM Specifies the path to a common library directory that will be shared
> across all cores.
> REM Any JAR files in this directory will be added to the search path for Solr
> plugins.
> REM If the specified path is not absolute, it will be relative to
> `%SOLR_HOME%`.
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
> {noformat}
> Without set you will get "_'SOLR_OPTS' is not recognized as an internal or
> external command, operable program or batch file_."
> After adding _set,_ with the quotes you get _"-Dsolr.environment=prod was
> unexpected at this time."_
> I'll attach a 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-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
[
https://issues.apache.org/jira/browse/SOLR-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088527#comment-17088527
]
Jan Høydahl commented on SOLR-14421:
Thanks. Tip: You don't need to delete the previous patch, just add the updated
one with the same name and the old one will be greyed out.
> New examples in solr.in.cmd in Solr 8.5 don't work as provided
> --
>
> Key: SOLR-14421
> URL: https://issues.apache.org/jira/browse/SOLR-14421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: 8.6
>
> Attachments: SOLR-14421.patch
>
>
>
> These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
> surrounded with quotes
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199]
> {noformat}
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
> REM Specifies the path to a common library directory that will be shared
> across all cores.
> REM Any JAR files in this directory will be added to the search path for Solr
> plugins.
> REM If the specified path is not absolute, it will be relative to
> `%SOLR_HOME%`.
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
> {noformat}
> Without set you will get "_'SOLR_OPTS' is not recognized as an internal or
> external command, operable program or batch file_."
> After adding _set,_ with the quotes you get _"-Dsolr.environment=prod was
> unexpected at this time."_
> I'll attach a 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] (SOLR-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
[
https://issues.apache.org/jira/browse/SOLR-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14421:
Status: Patch Available (was: Open)
> New examples in solr.in.cmd in Solr 8.5 don't work as provided
> --
>
> Key: SOLR-14421
> URL: https://issues.apache.org/jira/browse/SOLR-14421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: 8.6
>
> Attachments: SOLR-14421.patch
>
>
>
> These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
> surrounded with quotes
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199]
> {noformat}
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
> REM Specifies the path to a common library directory that will be shared
> across all cores.
> REM Any JAR files in this directory will be added to the search path for Solr
> plugins.
> REM If the specified path is not absolute, it will be relative to
> `%SOLR_HOME%`.
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
> {noformat}
> Without set you will get "_'SOLR_OPTS' is not recognized as an internal or
> external command, operable program or batch file_."
> After adding _set,_ with the quotes you get _"-Dsolr.environment=prod was
> unexpected at this time."_
> I'll attach a 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] (SOLR-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
[
https://issues.apache.org/jira/browse/SOLR-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14421:
Status: Open (was: Patch Available)
> New examples in solr.in.cmd in Solr 8.5 don't work as provided
> --
>
> Key: SOLR-14421
> URL: https://issues.apache.org/jira/browse/SOLR-14421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: 8.6
>
> Attachments: SOLR-14421.patch
>
>
>
> These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
> surrounded with quotes
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199]
> {noformat}
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
> REM Specifies the path to a common library directory that will be shared
> across all cores.
> REM Any JAR files in this directory will be added to the search path for Solr
> plugins.
> REM If the specified path is not absolute, it will be relative to
> `%SOLR_HOME%`.
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
> {noformat}
> Without set you will get "_'SOLR_OPTS' is not recognized as an internal or
> external command, operable program or batch file_."
> After adding _set,_ with the quotes you get _"-Dsolr.environment=prod was
> unexpected at this time."_
> I'll attach a 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] (SOLR-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
[
https://issues.apache.org/jira/browse/SOLR-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14421:
Attachment: SOLR-14421.patch
> New examples in solr.in.cmd in Solr 8.5 don't work as provided
> --
>
> Key: SOLR-14421
> URL: https://issues.apache.org/jira/browse/SOLR-14421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: 8.6
>
> Attachments: SOLR-14421.patch
>
>
>
> These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
> surrounded with quotes
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199]
> {noformat}
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
> REM Specifies the path to a common library directory that will be shared
> across all cores.
> REM Any JAR files in this directory will be added to the search path for Solr
> plugins.
> REM If the specified path is not absolute, it will be relative to
> `%SOLR_HOME%`.
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
> {noformat}
> Without set you will get "_'SOLR_OPTS' is not recognized as an internal or
> external command, operable program or batch file_."
> After adding _set,_ with the quotes you get _"-Dsolr.environment=prod was
> unexpected at this time."_
> I'll attach a 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] (SOLR-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
[
https://issues.apache.org/jira/browse/SOLR-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14421:
Attachment: (was: SOLR-14421.patch)
> New examples in solr.in.cmd in Solr 8.5 don't work as provided
> --
>
> Key: SOLR-14421
> URL: https://issues.apache.org/jira/browse/SOLR-14421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: 8.6
>
> Attachments: SOLR-14421.patch
>
>
>
> These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
> surrounded with quotes
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199]
> {noformat}
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
> REM Specifies the path to a common library directory that will be shared
> across all cores.
> REM Any JAR files in this directory will be added to the search path for Solr
> plugins.
> REM If the specified path is not absolute, it will be relative to
> `%SOLR_HOME%`.
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
> {noformat}
> Without set you will get "_'SOLR_OPTS' is not recognized as an internal or
> external command, operable program or batch file_."
> After adding _set,_ with the quotes you get _"-Dsolr.environment=prod was
> unexpected at this time."_
> I'll attach a 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-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
[
https://issues.apache.org/jira/browse/SOLR-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088500#comment-17088500
]
Colvin Cowie commented on SOLR-14421:
-
There were others as well, so I'm just going to check that the updated examples
actually work.
> New examples in solr.in.cmd in Solr 8.5 don't work as provided
> --
>
> Key: SOLR-14421
> URL: https://issues.apache.org/jira/browse/SOLR-14421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: 8.6
>
> Attachments: SOLR-14421.patch
>
>
>
> These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
> surrounded with quotes
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199]
> {noformat}
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
> REM Specifies the path to a common library directory that will be shared
> across all cores.
> REM Any JAR files in this directory will be added to the search path for Solr
> plugins.
> REM If the specified path is not absolute, it will be relative to
> `%SOLR_HOME%`.
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
> {noformat}
> Without set you will get "_'SOLR_OPTS' is not recognized as an internal or
> external command, operable program or batch file_."
> After adding _set,_ with the quotes you get _"-Dsolr.environment=prod was
> unexpected at this time."_
> I'll attach a 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-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
[
https://issues.apache.org/jira/browse/SOLR-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088492#comment-17088492
]
Colvin Cowie commented on SOLR-14421:
-
Missed another one on the shardsWhitelist
> New examples in solr.in.cmd in Solr 8.5 don't work as provided
> --
>
> Key: SOLR-14421
> URL: https://issues.apache.org/jira/browse/SOLR-14421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: 8.6
>
> Attachments: SOLR-14421.patch
>
>
>
> These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
> surrounded with quotes
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199]
> {noformat}
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
> REM Specifies the path to a common library directory that will be shared
> across all cores.
> REM Any JAR files in this directory will be added to the search path for Solr
> plugins.
> REM If the specified path is not absolute, it will be relative to
> `%SOLR_HOME%`.
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
> {noformat}
> Without set you will get "_'SOLR_OPTS' is not recognized as an internal or
> external command, operable program or batch file_."
> After adding _set,_ with the quotes you get _"-Dsolr.environment=prod was
> unexpected at this time."_
> I'll attach a 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-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
[
https://issues.apache.org/jira/browse/SOLR-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088491#comment-17088491
]
Jan Høydahl commented on SOLR-14421:
Thanks. I must admit I never tested this on Windows when I added them. Have a
hard time remembering all the crazy quoting rules for CMD.
I'll commit this immediately if you are happy with the fix.
> New examples in solr.in.cmd in Solr 8.5 don't work as provided
> --
>
> Key: SOLR-14421
> URL: https://issues.apache.org/jira/browse/SOLR-14421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: 8.6
>
> Attachments: SOLR-14421.patch
>
>
>
> These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
> surrounded with quotes
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199]
> {noformat}
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
> REM Specifies the path to a common library directory that will be shared
> across all cores.
> REM Any JAR files in this directory will be added to the search path for Solr
> plugins.
> REM If the specified path is not absolute, it will be relative to
> `%SOLR_HOME%`.
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
> {noformat}
> Without set you will get "_'SOLR_OPTS' is not recognized as an internal or
> external command, operable program or batch file_."
> After adding _set,_ with the quotes you get _"-Dsolr.environment=prod was
> unexpected at this time."_
> I'll attach a 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] [Assigned] (SOLR-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
[
https://issues.apache.org/jira/browse/SOLR-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl reassigned SOLR-14421:
--
Assignee: Jan Høydahl
> New examples in solr.in.cmd in Solr 8.5 don't work as provided
> --
>
> Key: SOLR-14421
> URL: https://issues.apache.org/jira/browse/SOLR-14421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Jan Høydahl
>Priority: Trivial
> Attachments: SOLR-14421.patch
>
>
>
> These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
> surrounded with quotes
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199]
> {noformat}
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
> REM Specifies the path to a common library directory that will be shared
> across all cores.
> REM Any JAR files in this directory will be added to the search path for Solr
> plugins.
> REM If the specified path is not absolute, it will be relative to
> `%SOLR_HOME%`.
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
> {noformat}
> Without set you will get "_'SOLR_OPTS' is not recognized as an internal or
> external command, operable program or batch file_."
> After adding _set,_ with the quotes you get _"-Dsolr.environment=prod was
> unexpected at this time."_
> I'll attach a 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] (SOLR-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
[
https://issues.apache.org/jira/browse/SOLR-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-14421:
---
Fix Version/s: 8.6
> New examples in solr.in.cmd in Solr 8.5 don't work as provided
> --
>
> Key: SOLR-14421
> URL: https://issues.apache.org/jira/browse/SOLR-14421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: 8.6
>
> Attachments: SOLR-14421.patch
>
>
>
> These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
> surrounded with quotes
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199]
> {noformat}
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
> REM Specifies the path to a common library directory that will be shared
> across all cores.
> REM Any JAR files in this directory will be added to the search path for Solr
> plugins.
> REM If the specified path is not absolute, it will be relative to
> `%SOLR_HOME%`.
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
> {noformat}
> Without set you will get "_'SOLR_OPTS' is not recognized as an internal or
> external command, operable program or batch file_."
> After adding _set,_ with the quotes you get _"-Dsolr.environment=prod was
> unexpected at this time."_
> I'll attach a 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] [Comment Edited] (SOLR-12182) Can not switch urlScheme in 7x if there are any cores in the cluster
[
https://issues.apache.org/jira/browse/SOLR-12182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088469#comment-17088469
]
Martin Entwistle edited comment on SOLR-12182 at 4/21/20, 9:18 AM:
---
I am having issues applying this patch though, it does not look complete to me,
and git says:
{{Only garbage was found in the patch input.}}
Can anyone else try this out and let me know if it is possible to apply the
patch (and to what branch)
was (Author: martinentwistle):
I am having issues applying this patch though, it does not look complete to me,
and git says
Only garbage was found in the patch input.
Can anyone else try this out and let me know if it is possible to apply the
patch (and to what branch)
> Can not switch urlScheme in 7x if there are any cores in the cluster
>
>
> Key: SOLR-12182
> URL: https://issues.apache.org/jira/browse/SOLR-12182
> Project: Solr
> Issue Type: Bug
>Affects Versions: 7.0, 7.1, 7.2
>Reporter: Anshum Gupta
>Priority: Major
> Attachments: SOLR-12182.patch
>
>
> I was trying to enable TLS on a cluster that was already in use i.e. had
> existing collections and ended up with down cores, that wouldn't come up and
> the following core init errors in the logs:
> *org.apache.solr.common.SolrException:org.apache.solr.common.SolrException:
> replica with coreNodeName core_node4 exists but with a different name or
> base_url.*
> What is happening here is that the core/replica is defined in the
> clusterstate with the urlScheme as part of it's base URL e.g.
> *"base_url":"http:hostname:port/solr"*.
> Switching the urlScheme in Solr breaks this convention as the host now uses
> HTTPS instead.
> Actually, I ran into this with an older version because I was running with
> *legacyCloud=false* and then realized that we switched that to the default
> behavior only in 7x i.e while most users did not hit this issue with older
> versions, unless they overrode the legacyCloud value explicitly, users
> running 7x are bound to run into this more often.
> Switching the value of legacyCloud to true, bouncing the cluster so that the
> clusterstate gets flushed, and then setting it back to false is a workaround
> but a bit risky one if you don't know if you have any old cores lying around.
> Ideally, I think we shouldn't prepend the urlScheme to the base_url value and
> use the urlScheme on the fly to construct 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-12182) Can not switch urlScheme in 7x if there are any cores in the cluster
[ https://issues.apache.org/jira/browse/SOLR-12182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088469#comment-17088469 ] Martin Entwistle commented on SOLR-12182: - I am having issues applying this patch though, it does not look complete to me, and git says Only garbage was found in the patch input. Can anyone else try this out and let me know if it is possible to apply the patch (and to what branch) > Can not switch urlScheme in 7x if there are any cores in the cluster > > > Key: SOLR-12182 > URL: https://issues.apache.org/jira/browse/SOLR-12182 > Project: Solr > Issue Type: Bug >Affects Versions: 7.0, 7.1, 7.2 >Reporter: Anshum Gupta >Priority: Major > Attachments: SOLR-12182.patch > > > I was trying to enable TLS on a cluster that was already in use i.e. had > existing collections and ended up with down cores, that wouldn't come up and > the following core init errors in the logs: > *org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: > replica with coreNodeName core_node4 exists but with a different name or > base_url.* > What is happening here is that the core/replica is defined in the > clusterstate with the urlScheme as part of it's base URL e.g. > *"base_url":"http:hostname:port/solr"*. > Switching the urlScheme in Solr breaks this convention as the host now uses > HTTPS instead. > Actually, I ran into this with an older version because I was running with > *legacyCloud=false* and then realized that we switched that to the default > behavior only in 7x i.e while most users did not hit this issue with older > versions, unless they overrode the legacyCloud value explicitly, users > running 7x are bound to run into this more often. > Switching the value of legacyCloud to true, bouncing the cluster so that the > clusterstate gets flushed, and then setting it back to false is a workaround > but a bit risky one if you don't know if you have any old cores lying around. > Ideally, I think we shouldn't prepend the urlScheme to the base_url value and > use the urlScheme on the fly to construct 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-12182) Can not switch urlScheme in 7x if there are any cores in the cluster
[ https://issues.apache.org/jira/browse/SOLR-12182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088466#comment-17088466 ] Martin Entwistle commented on SOLR-12182: - I would like to try and address this issue as it is hitting us. We would like to be able to create collections and test them out, then turn on SSL later. > Can not switch urlScheme in 7x if there are any cores in the cluster > > > Key: SOLR-12182 > URL: https://issues.apache.org/jira/browse/SOLR-12182 > Project: Solr > Issue Type: Bug >Affects Versions: 7.0, 7.1, 7.2 >Reporter: Anshum Gupta >Priority: Major > Attachments: SOLR-12182.patch > > > I was trying to enable TLS on a cluster that was already in use i.e. had > existing collections and ended up with down cores, that wouldn't come up and > the following core init errors in the logs: > *org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: > replica with coreNodeName core_node4 exists but with a different name or > base_url.* > What is happening here is that the core/replica is defined in the > clusterstate with the urlScheme as part of it's base URL e.g. > *"base_url":"http:hostname:port/solr"*. > Switching the urlScheme in Solr breaks this convention as the host now uses > HTTPS instead. > Actually, I ran into this with an older version because I was running with > *legacyCloud=false* and then realized that we switched that to the default > behavior only in 7x i.e while most users did not hit this issue with older > versions, unless they overrode the legacyCloud value explicitly, users > running 7x are bound to run into this more often. > Switching the value of legacyCloud to true, bouncing the cluster so that the > clusterstate gets flushed, and then setting it back to false is a workaround > but a bit risky one if you don't know if you have any old cores lying around. > Ideally, I think we shouldn't prepend the urlScheme to the base_url value and > use the urlScheme on the fly to construct 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] [Created] (LUCENE-9334) Require consistency between data-structures on a per-field basis
Adrien Grand created LUCENE-9334: Summary: Require consistency between data-structures on a per-field basis Key: LUCENE-9334 URL: https://issues.apache.org/jira/browse/LUCENE-9334 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Follow-up of https://lists.apache.org/thread.html/r747de568afd7502008c45783b74cc3aeb31dab8aa60fcafaf65d5431%40%3Cdev.lucene.apache.org%3E. We would like to start requiring consitency across data-structures on a per-field basis in order to make it easier to do the right thing by default: range queries can run faster if doc values are enabled, sorted queries can run faster if points by indexed, etc. This would be a big change, so it should be rolled out in a major. Strict validation is tricky to implement, but we should still implement best-effort validation: - Documents all use the same data-structures, e.g. it is illegal for a document to only enable points and another document to only enable doc values, - When possible, check whether values are consistent too. -- 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-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
[
https://issues.apache.org/jira/browse/SOLR-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14421:
Description:
These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
surrounded with quotes
[https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199]
{noformat}
REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
REM Specifies the path to a common library directory that will be shared across
all cores.
REM Any JAR files in this directory will be added to the search path for Solr
plugins.
REM If the specified path is not absolute, it will be relative to `%SOLR_HOME%`.
REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
{noformat}
Without set you will get "_'SOLR_OPTS' is not recognized as an internal or
external command, operable program or batch file_."
After adding _set,_ with the quotes you get _"-Dsolr.environment=prod was
unexpected at this time."_
I'll attach a patch
was:
These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
surrounded with quotes
https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199
{noformat}
REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
REM Specifies the path to a common library directory that will be shared across
all cores.
REM Any JAR files in this directory will be added to the search path for Solr
plugins.
REM If the specified path is not absolute, it will be relative to `%SOLR_HOME%`.
REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
{noformat}
I'll attach a patch
> New examples in solr.in.cmd in Solr 8.5 don't work as provided
> --
>
> Key: SOLR-14421
> URL: https://issues.apache.org/jira/browse/SOLR-14421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Priority: Trivial
> Attachments: SOLR-14421.patch
>
>
>
> These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
> surrounded with quotes
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199]
> {noformat}
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
> REM Specifies the path to a common library directory that will be shared
> across all cores.
> REM Any JAR files in this directory will be added to the search path for Solr
> plugins.
> REM If the specified path is not absolute, it will be relative to
> `%SOLR_HOME%`.
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
> {noformat}
> Without set you will get "_'SOLR_OPTS' is not recognized as an internal or
> external command, operable program or batch file_."
> After adding _set,_ with the quotes you get _"-Dsolr.environment=prod was
> unexpected at this time."_
> I'll attach a 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] (SOLR-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
[
https://issues.apache.org/jira/browse/SOLR-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14421:
Status: Patch Available (was: Open)
> New examples in solr.in.cmd in Solr 8.5 don't work as provided
> --
>
> Key: SOLR-14421
> URL: https://issues.apache.org/jira/browse/SOLR-14421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Priority: Trivial
> Attachments: SOLR-14421.patch
>
>
>
> These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
> surrounded with quotes
> https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199
> {noformat}
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
> REM Specifies the path to a common library directory that will be shared
> across all cores.
> REM Any JAR files in this directory will be added to the search path for Solr
> plugins.
> REM If the specified path is not absolute, it will be relative to
> `%SOLR_HOME%`.
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
> {noformat}
> I'll attach a 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] (SOLR-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
[
https://issues.apache.org/jira/browse/SOLR-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14421:
Attachment: SOLR-14421.patch
> New examples in solr.in.cmd in Solr 8.5 don't work as provided
> --
>
> Key: SOLR-14421
> URL: https://issues.apache.org/jira/browse/SOLR-14421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Priority: Trivial
> Attachments: SOLR-14421.patch
>
>
>
> These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
> surrounded with quotes
> https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199
> {noformat}
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
> REM Specifies the path to a common library directory that will be shared
> across all cores.
> REM Any JAR files in this directory will be added to the search path for Solr
> plugins.
> REM If the specified path is not absolute, it will be relative to
> `%SOLR_HOME%`.
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
> {noformat}
> I'll attach a 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] (SOLR-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
[
https://issues.apache.org/jira/browse/SOLR-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14421:
Attachment: SOLR-14421.patch
> New examples in solr.in.cmd in Solr 8.5 don't work as provided
> --
>
> Key: SOLR-14421
> URL: https://issues.apache.org/jira/browse/SOLR-14421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Priority: Trivial
> Attachments: SOLR-14421.patch
>
>
>
> These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
> surrounded with quotes
> https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199
> {noformat}
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
> REM Specifies the path to a common library directory that will be shared
> across all cores.
> REM Any JAR files in this directory will be added to the search path for Solr
> plugins.
> REM If the specified path is not absolute, it will be relative to
> `%SOLR_HOME%`.
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
> {noformat}
> I'll attach a 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] (SOLR-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
[
https://issues.apache.org/jira/browse/SOLR-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14421:
Attachment: (was: SOLR-14421.patch)
> New examples in solr.in.cmd in Solr 8.5 don't work as provided
> --
>
> Key: SOLR-14421
> URL: https://issues.apache.org/jira/browse/SOLR-14421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Priority: Trivial
> Attachments: SOLR-14421.patch
>
>
>
> These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
> surrounded with quotes
> https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199
> {noformat}
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
> REM Specifies the path to a common library directory that will be shared
> across all cores.
> REM Any JAR files in this directory will be added to the search path for Solr
> plugins.
> REM If the specified path is not absolute, it will be relative to
> `%SOLR_HOME%`.
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
> {noformat}
> I'll attach a 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] [Created] (SOLR-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
Colvin Cowie created SOLR-14421:
---
Summary: New examples in solr.in.cmd in Solr 8.5 don't work as
provided
Key: SOLR-14421
URL: https://issues.apache.org/jira/browse/SOLR-14421
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 8.5.1, 8.5
Reporter: Colvin Cowie
These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
surrounded with quotes
https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199
{noformat}
REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
REM Specifies the path to a common library directory that will be shared across
all cores.
REM Any JAR files in this directory will be added to the search path for Solr
plugins.
REM If the specified path is not absolute, it will be relative to `%SOLR_HOME%`.
REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
{noformat}
I'll attach a 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-14420) Address AuthenticationPlugin TODO redeclare params as HttpServletRequest & HttpServletResponse
[ https://issues.apache.org/jira/browse/SOLR-14420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088359#comment-17088359 ] Uwe Schindler commented on SOLR-14420: -- Do you have a PR already? It's long ago since I argued about this. I have to first understand this again. > Address AuthenticationPlugin TODO redeclare params as HttpServletRequest & > HttpServletResponse > -- > > Key: SOLR-14420 > URL: https://issues.apache.org/jira/browse/SOLR-14420 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: security >Reporter: Mike Drob >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > This was noted in SOLR-11692 and then I think the surrounding code change > more in SOLR-12290, but the TODO remained unaddressed. We can declare this as > HttpServletRequest/Response and all of the usages still work. There are > plenty of implementations where we just do a cast anyway, and don't even do > instanced checks. > I noticed this change for an external auth plugin that I'm working on that > appears to have issues handling casts between ServletRequest and the > CloseShield wrapper classes. -- 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
