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
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
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
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
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
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
May I propose Query Index?
On Thu, May 2, 2024 at 3:03 PM Gus Heck wrote:
> It detects documents that match a set of queries, so maybe "detector"?
>
> On Thu, May 2, 2024 at 4:30 AM Jan Høydahl wrote:
>
> > Alerting, while overloaded is probably the most precise name we could
> > choose -
It detects documents that match a set of queries, so maybe "detector"?
On Thu, May 2, 2024 at 4:30 AM Jan Høydahl wrote:
> Alerting, while overloaded is probably the most precise name we could
> choose - documentation would help explain the scope.
> And if someone made an example project with a
Alerting, while overloaded is probably the most precise name we could choose -
documentation would help explain the scope.
And if someone made an example project with a UI for experimentation that would
make the feature much more approachable.
Jan
> 2. mai 2024 kl. 03:18 skrev Walter Underwood
