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
