A115: disable priority LB child policy retention cache by apolcyn · Pull Request #541 · grpc/proposal

apolcyn · 2026-03-17T21:45:23Z

Update on https://github.com/grpc/proposal/blob/master/A56-priority-lb-policy.md#child-lifetime-management

A115-remove-priority-lb-child-policy-cache.md

markdroth

Thanks for writing this up!

Please let me know if you have any questions.

A56-update-remove-priority-lb-child-policy-cache.md

markdroth · 2026-03-18T01:31:31Z

A115-remove-priority-lb-child-policy-cache.md

+
+## Abstract
+
+[A56](https://github.com/grpc/proposal/blob/master/A56-priority-lb-policy.md) describes


This statement is misleading. A56 specifies that the caching mechanism will be used in two cases:

When a higher priority child becomes reachable, we deactive the lower-priority children and eventually remove them.

When a child is removed from the LB policy config.

This gRFC is removing case (2) only. We did not discuss removing case (1), and I don't think it makes sense to do so.

added these points

Removing the caching only for case (2) is not going to as simple as setting an integer (at least in Go), as discussed today.

To give a little bit more context, we use a balancergroup, which is a helper that manages a bunch of LB policies and one can add and remove policies from the balancergroup and it allows the caller to control aggregating state updates from these policies. Our caching is implemented in the balancergroup. And this balancergroup is used by a bunch of LB policies like priority, rls, weightedtarget and clustermanager.

We could add a flavor of the Remove method that supports caching and one that doesn't. But I'm wondering how the other languages implement this caching and how easy/hard it is going to be to support this only for case (2).

cc @markdroth about this

I don't think we want to disable caching for case (1). If Go needs more work to do that, then we need to do that work.

FWIW, in C-core, we don't have any shared code for the policies you listed. The priority policy deactivates the child here for case 1 and here for case 2. So all we would need to do to remove this functionality for case 2 is to change the latter to immediately remove the child instead of deactivating it.

I can understand why Go might have used shared code for the priority, weighted_target, and xds_cluster_manager LB policies, since they all have this caching behavior. But I will note that the RLS policy was never supposed to have this caching behavior, so it seems strange to me that you'd also use it there.

A115-remove-priority-lb-child-policy-cache.md

markdroth · 2026-03-18T19:37:13Z

A115-remove-priority-lb-child-policy-cache.md

+
+## Abstract
+
+[A56](https://github.com/grpc/proposal/blob/master/A56-priority-lb-policy.md) describes


I don't think we want to disable caching for case (1). If Go needs more work to do that, then we need to do that work.

FWIW, in C-core, we don't have any shared code for the policies you listed. The priority policy deactivates the child here for case 1 and here for case 2. So all we would need to do to remove this functionality for case 2 is to change the latter to immediately remove the child instead of deactivating it.

I can understand why Go might have used shared code for the priority, weighted_target, and xds_cluster_manager LB policies, since they all have this caching behavior. But I will note that the RLS policy was never supposed to have this caching behavior, so it seems strange to me that you'd also use it there.

A115-remove-priority-lb-child-policy-cache.md

markdroth · 2026-03-18T19:55:30Z

A115-remove-priority-lb-child-policy-cache.md

-[[AA, BB, CC], [DD]] => [priority-0-3 priority-0-4]
+[[BB, CC], [AA, DD]] => [priority-0-0 priority-0-1]
+[[AA, BB, CC], [DD, EE]] => [priority-0-1 priority-0-2]
+[[BB, CC], [AA, DD]] => [priority-0-2 priority-0-3]


I think the algorithm should be sticking with child numbers 1 and 2 in this last step.

I've sent you grpc/grpc#41896 to add tests demonstrating the algorithm's behavior in C-core.

hmm the original text is what Go was doing (i tagged you on an internal doc to illustrate)

but maybe that was specific to Go

Changed to your original suggestion

In the case you have now in the gRFC, in the third update, the algorithm will use child number 3 for [AA, BB] and reuse child number 2 for [CC, DD], because it was already using that number for [CC] in the second update.

If what you're seeing in Go matches what you currently have in the doc, then I suspect Go's implementation of this algorithm isn't quite right. @easwars

Will take a look and get back asap.

A115-remove-priority-lb-child-policy-cache.md

ejona86

Do we (all of us) have a plan for cluster_manager? Are we going to make a separate gRFC for that?

A115-remove-priority-lb-child-policy-cache.md

markdroth · 2026-03-19T15:54:22Z

Do we (all of us) have a plan for cluster_manager? Are we going to make a separate gRFC for that?

I don't think we need any changes there at this point. Arguably, the caching there is a gray area, because I don't think any gRFC ever specified that we would actually have caching there, but all of our implementations actually do. But on the other hand, I don't think the caching in that policy is actually causing any problems right now. So my inclination is to wait until we have a problem before changing that.

markdroth · 2026-03-19T20:48:13Z

A115-remove-priority-lb-child-policy-cache.md

-[[AA, BB, CC], [DD]] => [priority-0-3 priority-0-4]
+[[BB, CC], [AA, DD]] => [priority-0-0 priority-0-1]
+[[AA, BB, CC], [DD, EE]] => [priority-0-1 priority-0-2]
+[[BB, CC], [AA, DD]] => [priority-0-2 priority-0-3]


In the case you have now in the gRFC, in the third update, the algorithm will use child number 3 for [AA, BB] and reuse child number 2 for [CC, DD], because it was already using that number for [CC] in the second update.

If what you're seeing in Go matches what you currently have in the doc, then I suspect Go's implementation of this algorithm isn't quite right. @easwars

markdroth · 2026-03-19T20:48:41Z

A115-remove-priority-lb-child-policy-cache.md

+Note this should be done for Java and Go only.
+
+For C-core, we are actually potentially getting benefit from this
+behavior due to subchannel sharing, so we're not planning to drop


s/sharing/pooling/, just to be precise.

apolcyn assigned markdroth, ejona86, dfawley and easwars Mar 17, 2026

apolcyn changed the title ~~Disable priority LB child cache~~ A56 update: disable priority LB child cache Mar 17, 2026

apolcyn changed the title ~~A56 update: disable priority LB child cache~~ A56 update: disable priority LB child policy retention cache Mar 17, 2026

A56 update: disable priority LB child policy retention cache

5798457

apolcyn force-pushed the remove_cache branch from 49a3cdc to 5798457 Compare March 17, 2026 22:00

easwars reviewed Mar 18, 2026

View reviewed changes

A115-remove-priority-lb-child-policy-cache.md Show resolved Hide resolved

specify env var

f4ff35a

markdroth changed the title ~~A56 update: disable priority LB child policy retention cache~~ A115: disable priority LB child policy retention cache Mar 18, 2026

markdroth reviewed Mar 18, 2026

View reviewed changes

apolcyn added 4 commits March 18, 2026 05:01

rename grfc

5b2a3fc

add updated header

0063acd

updates

27826d1

add updates

ed5414a

markdroth reviewed Mar 18, 2026

View reviewed changes

A115-remove-priority-lb-child-policy-cache.md Outdated Show resolved Hide resolved

markdroth reviewed Mar 18, 2026

View reviewed changes

A115-remove-priority-lb-child-policy-cache.md Outdated Show resolved Hide resolved

ejona86 reviewed Mar 19, 2026

View reviewed changes

A115-remove-priority-lb-child-policy-cache.md Outdated Show resolved Hide resolved

A115-remove-priority-lb-child-policy-cache.md Show resolved Hide resolved

review comments

a063941

apolcyn marked this pull request as ready for review March 19, 2026 19:15

markdroth reviewed Mar 19, 2026

View reviewed changes

apolcyn added 2 commits March 20, 2026 07:56

address comments

1850df2

address comments

926c692

easwars mentioned this pull request Mar 20, 2026

cdsbalancer: priority LB name generation logic creates new names everytime when the EDS resource has no localities grpc/grpc-go#8994

Open


		## Abstract

		[A56](https://github.com/grpc/proposal/blob/master/A56-priority-lb-policy.md) describes

Conversation

apolcyn commented Mar 17, 2026

Uh oh!

Uh oh!

markdroth left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

markdroth Mar 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

markdroth Mar 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

ejona86 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

markdroth commented Mar 19, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

markdroth Mar 18, 2026 •

edited

Loading

markdroth Mar 18, 2026 •

edited

Loading