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
