I've got an umbrella Jira started here: https://issues.apache.org/jira/browse/SOLR-17270. Feel free to add into it as anyone comes across things.
On Fri, May 3, 2024 at 12:10 PM Cassandra Targett <casstarg...@gmail.com> wrote: > I haven’t followed what PRS even is or what its benefits are supposed to > be so can’t comment on whether it should/coud be a default. I may be alone > in that since I haven’t had bandwidth to pay attention to very many recent > Solr changes, but I do note that there is only one entry in the Solr Ref > Guide for “perReplicaState” (and none for “PRS” or alternate spellings I > could come up with), which is a single sentence describing it as a > parameter one can set when creating a collection. > > > https://solr.apache.org/guide/solr/latest/deployment-guide/collection-management.html#create-parameters > (scroll > down a ways) > > I think integrating some overview information of this mode and how it’s > expected to work in the Ref Guide would help adoption before v10 (to find > bugs in more use cases) and expose it to more people who aren’t staying up > to date with the flow of issues and commits. > > On May 2, 2024 at 4:22:03 PM, David Smiley <dsmi...@apache.org> wrote: > > > Thanks for the update and willingness to help on this journey, Justin! > > Maybe an umbrella JIRA would make sense for tracking purposes, and > > link child issues or do sub-tasks. Perhaps the goal is "PRS enabled > > by default". > > > > I don't know if this thread is the best place to discuss it but having > > the PRS znode be ephemeral would be really beneficial to dramatically > > strengthen the goals of PRS by efficiently handling restarts. No need > > to mark a node's replicas as down! > > > > On Thu, May 2, 2024 at 3:45 PM Justin Sweeney > > <justin.sweene...@gmail.com> wrote: > > > > > > We (Fullstory) have been running PRS for quite a while now with great > > > > stability and a huge performance benefit for us particularly in terms of > > > > cluster restarts. That said, our use case certainly isn't everyone's use > > > > case. We run large clusters with lots of cores so we get a particular > > > > benefit. My expectation in the current state is that as far as > performance > > > > it will help some use cases without hurting any use case. > > > > > > I don't know what timing will look like but I am +1 with David on moving > to > > > > PRS in Solr 10 as it would make code maintenance much better going > forward. > > > > Both myself and other devs at Fullstory can definitely make contributions > > > > toward getting PRS to a state where others also are getting the > performance > > > > benefits and feel comfortable with this decision. > > > > > > I can look at adding some Jira's along these lines and would be happy to > > > > discuss more along the way. > > > > > > On Thu, May 2, 2024 at 1:59 PM Houston Putman <hous...@apache.org> > wrote: > > > > > > > I'm all for moving towards it if it has both (or at least a good > tradeoff > > > > > between): > > > > > > > > > > - A proven stability, like the current implementation > > > > > - A noted increase in performance for common use cases > > > > > > > > > > It seems to me that without the performance benefits, the loss in > > stability > > > > > (PRS has had a few bad bugs in 9x releases) is worrisome. > > > > > I'd be very happy to move to PRS if we can improve it to give us > concrete > > > > > benefits, but until then I'm not in favor of making it the default. > > > > > > > > > > Maybe the ephemeral node for replica state > > > > > <https://github.com/apache/solr/pull/2432#discussion_r1586811114> is > the > > > > > logic we really need to make PRS "pop", but I haven't thought about it > > > > > a ton. > > > > > > > > > > - Houston > > > > > > > > > > On Thu, May 2, 2024 at 12:52 PM David Smiley <dsmi...@apache.org> > wrote: > > > > > > > > > > > Note that PRS has existed for all of the 9x series. I say in 10, > > > > > > let's finally move on. Be bold. > > > > > > > > > > > > On Thu, May 2, 2024 at 1:19 PM Ilan Ginzburg <ilans...@gmail.com> > > wrote: > > > > > > > > > > > > > > There is no plan to remove the non PRS way to manage replica state > > > > > before > > > > > > > making PRS the default way to manage replica state (in addition to > > the > > > > > > > current state.json option) then letting PRS bake for a while with > all > > > > > new > > > > > > > deployments (for example a whole release), right? > > > > > > > > > > > > > > Ilan > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, May 2, 2024 at 6:25 PM David Smiley <dsmi...@apache.org> > > > > > wrote: > > > > > > > > > > > > > > > In the meetup, my colleague Aparna shared her explorative > findings > > of > > > > > > > > enabling PRS, which uncovered 2 matters that seem to defeat much > of > > > > > > > > PRS's idealized benefits: > > > > > > > > * Shard leader elections still touch state.json > > > > > > > > * Replica state is still in state.json > > > > > > > > Given those two matters, we didn't notice any improvement (or > > > > > > > > regression). Some FullStory devs, who use this mode in > production, > > > > > > > > shared that the first matter wasn't noticed by them because they > > only > > > > > > > > run with one replica per shard. The other... was unclear why; > > maybe > > > > > > > > for backwards-compatibility? In my mind, there shouldn't be > such a > > > > > > > > concern as it's enabled per-collection and you'd only do this > once > > > > > all > > > > > > > > servers are known to be PRS-enabled (e.g. have a modern Solr > > > > > version). > > > > > > > > > > > > > > > > If we can identify JIRA issues to capture the work involved, we > > could > > > > > > > > converse more and track the work to completion. I think it's > > > > > > > > important to get to a future in Solr 10 where there is one mode > > (PRS) > > > > > > > > not two. > > > > > > > > > > > > > > > > ~ David Smiley > > > > > > > > Apache Lucene/Solr Search Developer > > > > > > > > http://www.linkedin.com/in/davidwsmiley > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > For additional commands, e-mail: dev-h...@solr.apache.org > > > > >
