* Shard leader elections are not supposed to cause changes to state.json.
If it does, it is a bug. I'm sure there is even a test case to test that
* Having the state stored in state.json is not a problem at all bcause it
is never updated. It is left there for backcompat reasons
Performance and st
+1 to move ahead with PRS as default in 10x.
Thanks for bringing this up, David. I shall respond in detail next week
when I am back from vacation.
On Fri, 3 May 2024 at 22:22, Justin Sweeney
wrote:
> I've got an umbrella Jira started here:
> https://issues.apache.org/jira/browse/SOLR-17270. Feel
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
wrote:
> I haven’t followed what PRS even is or what its benefits are supposed to
> be so can’t com
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
Gu
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 PR
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 e
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
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 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
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 a
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 im
10 matches
Mail list logo
