Houston, I really appreciate the offer to take a look. I would be happy to raise another PR to the sandbox repo if you think that this will help get some community usage/feedback before it is polished enough to be merged in the main project.
David, I totally agree with the naming. Speaking from experience, searching for "solr lucene monitor" (and any variation thereof) on the Internet was a real pain so not sure why I wanted to pass that hardship on to anyone else! In all seriousness, I wanted to be consistent with the naming of the lucene feature that this "mapped to". Clearly, from the feedback received so far, this is not a good enough reason to cascade such a poor name. Now regarding the sandbox/solr.cool point.. I'll start by saying you probably have the best intuition regarding what is useful enough to meet the threshold of being maintained in the core project. If this doesn't meet that threshold then there is not much more I can say. Having said that, I have some skepticism regarding this project being useful outside of solr (even with a link in solr.cool or the like). Take for example this solr.cool-advertised one https://github.com/SOLR4189/solcolator which implements saved search in a less integrated way (and IMO in a less robust way). It hasn't been touched in four years and even if it were, any user deciding on developing a saved search/alerting platform will trust such a project less than if it were maintained in the core project. This hurts adoption and makes it more likely to be relegated to the "attic". The other reasons I can think of merging this idea into the core project are 1. Elastic supports this feature as part of its core offering and 2. (as Houston stated) this is a feature that is supported in the core lucene project. This makes me think it has enough traction (or it did at some point at least). I'll also add that I am currently trying to convince folks at my company to adopt this approach so hopefully I'll soon have a more concrete sense about the potential here. Bloomberg is a big user of solr and also has a large footprint of custom-built, saved-search platforms, some of which painfully depend on solr without reaping any of the benefits regarding its distributed state management. Luke From: dev@solr.apache.org At: 04/18/24 10:50:23 UTC-4:00To: dev@solr.apache.org Subject: Re: solr query alerting Thanks for the work here Luke! I tried to work on something similar years ago and it was far more work than I initially thought to do it right, so I'm so glad someone is coming and giving it a go finally! I'll be able to do some review in a few weeks, but will be on vacation myself for the next week. As per the Solr sandbox or http://solr.cool, I think it's fine to add this in the sandbox for now, but given that this is making a Lucene functionality available in Solr, I see no reason why it can't eventually reside in the project. There are issues with maintenance burden, but that burden exists whether it is in Solr or outside of it. So given that this is a very cool feature, that I have heard lots of requests for, I think it's worth having inside. - Houston On Thu, Apr 18, 2024 at 9:10 AM David Smiley <dsmi...@apache.org> wrote: > I'm probably not a great reviewer of this TBH as I have only heard & > read about lucene-monitor/percolator; haven't used such a thing yet. > > I did a *quick* review to see how the PR touches the codebase. It's > wonderful that it is purely isolated; it requires no changes of Solr > itself. I might argue why is it here vs the Solr sandbox or somewhere > else with publicity in http://solr.cool > > The name "Monitor" sounds like an infrastructure monitoring feature. > > p.s. I'm on vacation this week with minimal time to collaborate > > On Mon, Apr 15, 2024 at 10:27 AM Luke Kot-Zaniewski (BLOOMBERG/ 919 > 3RD A) <lkotzanie...@bloomberg.net> wrote: > > > > Hey David, > > > > Just wanted to bump this. I appreciate you taking a look, and wanted to > stress that I am looking for even just higher level feedback at this point. > > > > Basically, I am questioning the direction I am going in which involves > exposing some of the lucene-monitor internals (so currently have an > implicit dependence on a lucene change). OTOH I couldn't figure out a > better way to apply the lucene-monitor optimizations while still utilizing > solr's sophisticated index management and scaling. Lucene-monitor is a very > sealed interface and the way it manages the index and caching (via Monitor > interface) is not easy to integrate on its own. > > > > Again, I'd appreciate any feedback, even partial, that you may have! > > > > Thanks, > > Luke > > > > From: dev@solr.apache.org At: 04/08/24 13:43:52 UTC-4:00To: > dev@solr.apache.org > > Subject: Re: solr query alerting > > > > I'm so glad someone has started this! Thanks for contributing. I'll > > take a look > > > > On Mon, Apr 1, 2024 at 3:53 PM Luke Kot-Zaniewski (BLOOMBERG/ 919 3RD > > A) <lkotzanie...@bloomberg.net> wrote: > > > > > > Hi All, > > > > > > A few months ago I wrote the user list about potentially integrating > lucene > > monitor into solr. I have raised this PR with a first attempt at > implementing > > this integration. I'd greatly appreciate any feedback on this even > though I > > still have it marked as draft. I want to make sure I'm heading in the > right > > direction here so input from solr dev community would be extremely > valuable :-) > > > > > > Many thanks, > > > Luke > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > For additional commands, e-mail: dev-h...@solr.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > >
