-
Notifications
You must be signed in to change notification settings - Fork 15
Allow invalidating SweepStrategyManager cache #4770
Conversation
Useful to change the sweep strategy on an existing table without bouncing the service.
Generate changelog in
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+2
There is technically a race condition when invalidating if we also try to reload at the same time, but I don't think we'd realistically hit it
@Override | ||
public void invalidateCaches(Set<TableReference> tableRefs) { | ||
sweepStrategySupplierLoadingCache.get().invalidateAll(tableRefs); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/**
* Discards any cached values for the {@code keys}. The behavior of this operation is undefined
* for an entry that is being loaded (or reloaded) and is otherwise not present.
*
* @param keys the keys whose associated values are to be removed
* @throws NullPointerException if the specified collection is null or contains a null element
*/
void invalidateAll(@NonNull Iterable<?> keys);
Invalidating something that's not there looks like it could end up either way. It's a bit nasty, but should we take a read-write lock?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussed offline: The "undefined-ness" here just means that load and invalidate could race and end up either way. This is fine for the internal use case we have planned here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 Looks good!
Released 0.218.3 |
This is pretty sketchy because it's not HA safe. Is this a problem? |
@j-baker good question. Discussed it with Jeremy, and it's not a problem for our use case at least. The node that calls this is the same node that will delete a cell and thus put it in the thorough sweep queue; the targeted sweeper background thread on a different node might not have its cache invalidated, but it trusts whatever's in the queue and will delete it appropriately. I was imagining that whatever application called this would be responsible for ensuring it gets called on all relevant nodes, but could add docs here to ensure future callers realize the implication. Does that sound reasonable? |
Goals (and why):
Useful to change the sweep strategy on an existing table without
bouncing the service.
Implementation Description (bullets):
Just expose a new method that allows cache invalidation.
Testing (What was existing testing like? What have you done to improve it?):
Concerns (what feedback would you like?):
Where should we start reviewing?:
Priority (whenever / two weeks / yesterday):