apache / apache/accumulo

Add mechanism for invalidating property cache in server processes

Open
#4,995 1 comment 0 reactions 0 assignees View on GitHub
enhancement
Dominant language
Java
Stars
1.2k
Forks
487
Avg merge
4d 5h
Merged PRs (30d)
13

Description

**Is your feature request related to a problem? Please describe.**

When table configuration and system configuration is updated in zookeeper there is no way to know when all servers in the cluster have seen this update. This can lead to problems like the following.

1. Table config is updated this could be table iterators, classloader context, etc
2. Scans are started that access tables where the config update was made
3. Only a subset of the tablet/scan servers have seen the config update when the scan request comes in.

PR #4990 is a very narrow fix for a single situation.

**Describe the solution you'd like**

Create a new server RPC that allows invalidating specified property caches (like system or specific tables) if the versions on those are below a certain level. Would need to consider that the version is an int that can wrap if doing this.

Unsure of the best way to expose this new server RPC for use. Below are some possible ways this could be done.

1. Always call this new RPC after setting a property. This could make something like setting 10 properties in the shell much slower as it would reach out to all servers after setting each property.
2. Add a new API like `invalidatePropertyCache(Set servers)` which would work well with the changes in #4851 and could be called after making many property updates on a subset of servers. This would make an RPC to each server. However this API does not narrow what caches are cleared, for example may want to clear a single table. This would need an associated shell command.
3. Create new property mutation API methods that allow specifying if caches should be invalidated, possibly on which servers. This would need options on the shell command to set properties.

Option 3 seems to offer a good balance between correctness and performance. Option 1 is good for correctness, but could cause performance problems for existing code. Option 2 seems good for performance, but not correctness.

Contributor guide

Open the contributing guide

Research direction

Start by reviewing PR #4990 and the changes in #4851, then trace the existing property mutation, server RPC, and shell command paths. Define how specified caches and minimum versions are selected, how version wraparound is handled, and how callers request invalidation. Done means an agreed API and shell exposure that preserves correctness without invalidating unnecessarily.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
backend-api-design, distributed-systems
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.