[jira] [Commented] (SOLR-14788) Solr: The Next Big Thing
[
https://issues.apache.org/jira/browse/SOLR-14788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236624#comment-17236624
]
Mark Robert Miller commented on SOLR-14788:
---
Holy wow, people are not going to believe these tests. They are moving on to
extraordinary. It would and will be impossible to achieve, I believe, with more
collaboration, so I will be taking plenty of pictures and lots of trips to the
zoo before it’s gone.
I’m in love with the idea that i might just be making some optimizations, some
faster tests, or completely destabilizing the hardened and well protected
master/8x branches for short vids of apparently fast running tests. That it’s
all just some lengthy work looking at some hotspots and my bombastic narration
is an oddity that can perhaps be tolerated by some but likely is just displaced
with reality, perhaps because of whatever mental break may have occurred and
caused me to be honest about Solr. Well, the mental break occurred at like age
5, and bombástico i am not ;) Ive got some tests to go and the vetting is
grueling, but the phase 1 end is just right over there. Happy thanksgiving,
I’ll be socially distancing in CarPlay equities RV for the week.
> Solr: The Next Big Thing
>
>
> Key: SOLR-14788
> URL: https://issues.apache.org/jira/browse/SOLR-14788
> Project: Solr
> Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Critical
>
> h3.
> [!https://www.unicode.org/consortium/aacimg/1F46E.png!|https://www.unicode.org/consortium/adopted-characters.html#b1F46E]{color:#00875a}*The
> Policeman is on duty!*{color}
> {quote}_{color:#de350b}*When The Policeman is on duty, sit back, relax, and
> have some fun. Try to make some progress. Don't stress too much about the
> impact of your changes or maintaining stability and performance and
> correctness so much. Until the end of phase 1, I've got your back. I have a
> variety of tools and contraptions I have been building over the years and I
> will continue training them on this branch. I will review your changes and
> peer out across the land and course correct where needed. As Mike D will be
> thinking, "Sounds like a bottleneck Mark." And indeed it will be to some
> extent. Which is why once stage one is completed, I will flip The Policeman
> to off duty. When off duty, I'm always* {color:#de350b}*occasionally*{color}
> *down for some vigilante justice, but I won't be walking the beat, all that
> stuff about sit back and relax goes out the window.*{color}_
> {quote}
>
> I have stolen this title from Ishan or Noble and Ishan.
> This issue is meant to capture the work of a small team that is forming to
> push Solr and SolrCloud to the next phase.
> I have kicked off the work with an effort to create a very fast and solid
> base. That work is not 100% done, but it's ready to join the fight.
> Tim Potter has started giving me a tremendous hand in finishing up. Ishan and
> Noble have already contributed support and testing and have plans for
> additional work to shore up some of our current shortcomings.
> Others have expressed an interest in helping and hopefully they will pop up
> here as well.
> Let's organize and discuss our efforts here and in various sub issues.
--
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-14788) Solr: The Next Big Thing
[
https://issues.apache.org/jira/browse/SOLR-14788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236624#comment-17236624
]
Mark Robert Miller edited comment on SOLR-14788 at 11/21/20, 9:50 AM:
--
Holy wow, people are not going to believe these tests. They are moving on to
extraordinary. It would and will be impossible to achieve, I believe, with more
collaboration, so I will be taking plenty of pictures and lots of trips to the
zoo before it’s gone.
I’m in love with the idea that i might just be making some optimizations, some
faster tests, or completely destabilizing the hardened and well protected
master/8x branches for short vids of apparently fast running tests. That it’s
all just some lengthy work looking at some hotspots and my bombastic narration
is an oddity that can perhaps be tolerated by some but likely is just displaced
with reality, perhaps because of whatever mental break may have occurred and
caused me to be honest about Solr. Well, the mental break occurred at like age
5, and bombástico i am not ;)
Ive got some tests to go and the vetting is grueling, but the phase 1 end is
just right over there. Happy thanksgiving, I’ll be socially distancing in a
CarPlay equipped RV for the week.
was (Author: markrmiller):
Holy wow, people are not going to believe these tests. They are moving on to
extraordinary. It would and will be impossible to achieve, I believe, with more
collaboration, so I will be taking plenty of pictures and lots of trips to the
zoo before it’s gone.
I’m in love with the idea that i might just be making some optimizations, some
faster tests, or completely destabilizing the hardened and well protected
master/8x branches for short vids of apparently fast running tests. That it’s
all just some lengthy work looking at some hotspots and my bombastic narration
is an oddity that can perhaps be tolerated by some but likely is just displaced
with reality, perhaps because of whatever mental break may have occurred and
caused me to be honest about Solr. Well, the mental break occurred at like age
5, and bombástico i am not ;) Ive got some tests to go and the vetting is
grueling, but the phase 1 end is just right over there. Happy thanksgiving,
I’ll be socially distancing in CarPlay equities RV for the week.
> Solr: The Next Big Thing
>
>
> Key: SOLR-14788
> URL: https://issues.apache.org/jira/browse/SOLR-14788
> Project: Solr
> Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Critical
>
> h3.
> [!https://www.unicode.org/consortium/aacimg/1F46E.png!|https://www.unicode.org/consortium/adopted-characters.html#b1F46E]{color:#00875a}*The
> Policeman is on duty!*{color}
> {quote}_{color:#de350b}*When The Policeman is on duty, sit back, relax, and
> have some fun. Try to make some progress. Don't stress too much about the
> impact of your changes or maintaining stability and performance and
> correctness so much. Until the end of phase 1, I've got your back. I have a
> variety of tools and contraptions I have been building over the years and I
> will continue training them on this branch. I will review your changes and
> peer out across the land and course correct where needed. As Mike D will be
> thinking, "Sounds like a bottleneck Mark." And indeed it will be to some
> extent. Which is why once stage one is completed, I will flip The Policeman
> to off duty. When off duty, I'm always* {color:#de350b}*occasionally*{color}
> *down for some vigilante justice, but I won't be walking the beat, all that
> stuff about sit back and relax goes out the window.*{color}_
> {quote}
>
> I have stolen this title from Ishan or Noble and Ishan.
> This issue is meant to capture the work of a small team that is forming to
> push Solr and SolrCloud to the next phase.
> I have kicked off the work with an effort to create a very fast and solid
> base. That work is not 100% done, but it's ready to join the fight.
> Tim Potter has started giving me a tremendous hand in finishing up. Ishan and
> Noble have already contributed support and testing and have plans for
> additional work to shore up some of our current shortcomings.
> Others have expressed an interest in helping and hopefully they will pop up
> here as well.
> Let's organize and discuss our efforts here and in various sub issues.
--
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-15010) Missing jstack warning is alarming, when using bin/solr as client interface to solr
David Eric Pugh created SOLR-15010:
--
Summary: Missing jstack warning is alarming, when using bin/solr
as client interface to solr
Key: SOLR-15010
URL: https://issues.apache.org/jira/browse/SOLR-15010
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 8.7
Reporter: David Eric Pugh
In SOLR-14442 we added a warning if jstack wasn't found. I notice that I use
the bin/solr command a lot as a client, so bin solr zk or bin solr healthcheck.
For example:
{{docker exec solr1 solr zk cp /security.json zk:security.json -z zoo1:2181}}
All of these emit the message:
The currently defined JAVA_HOME (/usr/local/openjdk-11) refers to a location
where java was found but jstack was not found. Continuing.
This is somewhat alarming, and then becomes annoying. Thoughts on maybe only
conducting this check if you are running {{bin/solr start}} or one of the other
commands that is actually starting Solr as a process?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15010) Missing jstack warning is alarming, when using bin/solr as client interface to solr
[
https://issues.apache.org/jira/browse/SOLR-15010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236647#comment-17236647
]
David Eric Pugh commented on SOLR-15010:
@cpoerschke you were invovled in SOLR-14442, what do you think?
> Missing jstack warning is alarming, when using bin/solr as client interface
> to solr
> ---
>
> Key: SOLR-15010
> URL: https://issues.apache.org/jira/browse/SOLR-15010
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.7
>Reporter: David Eric Pugh
>Priority: Minor
>
> In SOLR-14442 we added a warning if jstack wasn't found. I notice that I
> use the bin/solr command a lot as a client, so bin solr zk or bin solr
> healthcheck.
> For example:
> {{docker exec solr1 solr zk cp /security.json zk:security.json -z zoo1:2181}}
> All of these emit the message:
> The currently defined JAVA_HOME (/usr/local/openjdk-11) refers to a location
> where java was found but jstack was not found. Continuing.
> This is somewhat alarming, and then becomes annoying. Thoughts on maybe
> only conducting this check if you are running {{bin/solr start}} or one of
> the other commands that is actually starting Solr as a process?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-15010) Missing jstack warning is alarming, when using bin/solr as client interface to solr
[
https://issues.apache.org/jira/browse/SOLR-15010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236647#comment-17236647
]
David Eric Pugh edited comment on SOLR-15010 at 11/21/20, 11:36 AM:
[~cpoerschke] you were invovled in SOLR-14442, what do you think?
was (Author: epugh):
@cpoerschke you were invovled in SOLR-14442, what do you think?
> Missing jstack warning is alarming, when using bin/solr as client interface
> to solr
> ---
>
> Key: SOLR-15010
> URL: https://issues.apache.org/jira/browse/SOLR-15010
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.7
>Reporter: David Eric Pugh
>Priority: Minor
>
> In SOLR-14442 we added a warning if jstack wasn't found. I notice that I
> use the bin/solr command a lot as a client, so bin solr zk or bin solr
> healthcheck.
> For example:
> {{docker exec solr1 solr zk cp /security.json zk:security.json -z zoo1:2181}}
> All of these emit the message:
> The currently defined JAVA_HOME (/usr/local/openjdk-11) refers to a location
> where java was found but jstack was not found. Continuing.
> This is somewhat alarming, and then becomes annoying. Thoughts on maybe
> only conducting this check if you are running {{bin/solr start}} or one of
> the other commands that is actually starting Solr as a process?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14788) Solr: The Next Big Thing
[
https://issues.apache.org/jira/browse/SOLR-14788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236719#comment-17236719
]
Mark Robert Miller commented on SOLR-14788:
---
So when I get back I’ll dump the final bits in after a little bit of wrap up
and vetting and tests. It’s important to bring up the distinction of this “next
big thing” issue and the ref branch ‘stage one’ issue that I’m finally
completing. As people look at the code, it’s important to remember that it and
the design and any individual change has no value to me. I’d personally do a
lot of things differently myself.
The value is in the state of things. So your ideas, your changes, god willing
your cleanup and fancy targeted code, are all still in the mix. This branch is
not about me doing things my way. My way is the scalable, stable, impressive
way. So whatever changes and additions and deletions that those that drink the
cool aid will want to make, are totally available. But if they make the system
less stable, less scalable, less efficient, I will prefer whatever I’ve hack
together to make this thing work.
There is a lot of room to explore from a *much* more stable base. There will
always be a role for solid overseer type nodes, but can you fit CAS in that
system as well? I can imagine you could or that maybe it wouldn’t bring enough
value. But the door is open, the barrier on this branch will be the results of
the change.
> Solr: The Next Big Thing
>
>
> Key: SOLR-14788
> URL: https://issues.apache.org/jira/browse/SOLR-14788
> Project: Solr
> Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Critical
> Time Spent: 4h
> Remaining Estimate: 0h
>
> h3.
> [!https://www.unicode.org/consortium/aacimg/1F46E.png!|https://www.unicode.org/consortium/adopted-characters.html#b1F46E]{color:#00875a}*The
> Policeman is on duty!*{color}
> {quote}_{color:#de350b}*When The Policeman is on duty, sit back, relax, and
> have some fun. Try to make some progress. Don't stress too much about the
> impact of your changes or maintaining stability and performance and
> correctness so much. Until the end of phase 1, I've got your back. I have a
> variety of tools and contraptions I have been building over the years and I
> will continue training them on this branch. I will review your changes and
> peer out across the land and course correct where needed. As Mike D will be
> thinking, "Sounds like a bottleneck Mark." And indeed it will be to some
> extent. Which is why once stage one is completed, I will flip The Policeman
> to off duty. When off duty, I'm always* {color:#de350b}*occasionally*{color}
> *down for some vigilante justice, but I won't be walking the beat, all that
> stuff about sit back and relax goes out the window.*{color}_
> {quote}
>
> I have stolen this title from Ishan or Noble and Ishan.
> This issue is meant to capture the work of a small team that is forming to
> push Solr and SolrCloud to the next phase.
> I have kicked off the work with an effort to create a very fast and solid
> base. That work is not 100% done, but it's ready to join the fight.
> Tim Potter has started giving me a tremendous hand in finishing up. Ishan and
> Noble have already contributed support and testing and have plans for
> additional work to shore up some of our current shortcomings.
> Others have expressed an interest in helping and hopefully they will pop up
> here as well.
> Let's organize and discuss our efforts here and in various sub issues.
--
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-9614) Implement KNN Query
[ https://issues.apache.org/jira/browse/LUCENE-9614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236727#comment-17236727 ] Michael Sokolov commented on LUCENE-9614: - OK, thought about this a bit, and I guess I see the point a little better. This query is weird because if (say) we were to add some new vectors to the index, suddenly a vector that previously matched might no longer match. I guess I have been thinking of a Query as a convenience for plugging in to the typical scoring / execution framework provided by IndexSearcher. Let me sketch out the use case I have in mind, because I'm not sure how we would handle it in the non-Query implementation(s). We'd like to be able to blend matches derived from postings (full text search) along with matches derived from vectors, using some kind of scoring function that balances vector scores and text relevance scores. Both kinds of matches also need to satisfy other constraints, embodied in a Query. If we present KNN matches as a Query, I think this can all be done by the Collectors in the usual way, but if we have a different API, say something on IndexSearcher, or a static method on a KNN class, then that blending will require its own custom implementation - I think? > Implement KNN Query > --- > > Key: LUCENE-9614 > URL: https://issues.apache.org/jira/browse/LUCENE-9614 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Michael Sokolov >Priority: Major > > Now we have a vector index format, and one vector indexing/KNN search > implementation, but the interface is low-level: you can search across a > single segment only. We would like to expose a Query implementation. > Initially, we want to support a usage where the KnnVectorQuery selects the > k-nearest neighbors without regard to any other constraints, and these can > then be filtered as part of an enclosing Boolean or other query. > Later we will want to explore some kind of filtering *while* performing > vector search, or a re-entrant search process that can yield further results. > Because of the nature of knn search (all documents having any vector value > match), it is more like a ranking than a filtering operation, and it doesn't > really make sense to provide an iterator interface that can be merged in the > usual way, in docid order, skipping ahead. It's not yet clear how to satisfy > a query that is "k nearest neighbors satsifying some arbitrary Query", at > least not without realizing a complete bitset for the Query. But this is for > a later issue; *this* issue is just about performing the knn search in > isolation, computing a set of (some given) K nearest neighbors, and providing > an iterator over those. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy commented on pull request #1769: SOLR-14789: Absorb the docker-solr repo.
janhoy commented on pull request #1769: URL: https://github.com/apache/lucene-solr/pull/1769#issuecomment-731611355 Yea, add the image hash to download page and document how to check each jar file. 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 pull request #2010: SOLR-12182: Don't persist base_url in ZK as the scheme is variable, compute from node_name instead
noblepaul commented on pull request #2010: URL: https://github.com/apache/lucene-solr/pull/2010#issuecomment-731661638 > we don't want to promise the community a zero-downtime upgrade to enable TLS, because it is a hard thing to promise I don't have a problem if there is a downtime when you upgrade from one schem to another. I only worry if the scheme remains same and a rolling restart is not posisble. 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 edited a comment on pull request #2010: SOLR-12182: Don't persist base_url in ZK as the scheme is variable, compute from node_name instead
noblepaul edited a comment on pull request #2010: URL: https://github.com/apache/lucene-solr/pull/2010#issuecomment-731661638 > we don't want to promise the community a zero-downtime upgrade to enable TLS, because it is a hard thing to promise I don't have a problem if there is a downtime when you upgrade from one schem to another. I only worry if the scheme remains same and a rolling restart is not possible. 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 pull request #2010: SOLR-12182: Don't persist base_url in ZK as the scheme is variable, compute from node_name instead
noblepaul commented on pull request #2010: URL: https://github.com/apache/lucene-solr/pull/2010#issuecomment-731661859 LGTM 👍 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] zhaih closed pull request #2090: LUCENE-9618: demo unit test
zhaih closed pull request #2090: URL: https://github.com/apache/lucene-solr/pull/2090 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
