fix: concurrency groundwork for the multi-user client and features repository - #234
Open
madhuchavva wants to merge 9 commits into
Open
madhuchavva wants to merge 9 commits into
madhuchavva wants to merge 9 commits into
Conversation
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Concurrency groundwork for the multi-user client and features repository
Summary
What's included
InMemoryStickyBucketServiceImpl— new no-arg constructor backed byConcurrentHashMap, used byOptions.setInMemoryStickyBucketService(). The previous plainHashMapis a structural data race (not just a lost update) when one client's concurrent evaluations save assignments in parallel. The map-injecting constructor is unchanged; its Javadoc now states the thread-safety requirement.GrowthBookClient—assignedis now aConcurrentHashMapandcallbacksaCopyOnWriteArrayList(both were plain collections mutated perrun()/subscribe()). The assigned-variation change-check and publish infireSubscriptionsare now one atomiccomputestep, so two concurrentrun()calls can no longer both observe a stale value and double-fire subscriptions; callbacks still run outside the map lock.GBFeaturesRepositorycallback dispatch —refreshCallbackswas a plainArrayList: adds were synchronized but the dispatch iteration on the poll/SSE/retry background threads was not, so registering a callback during a refresh could throwConcurrentModificationException. NowCopyOnWriteArrayList(the fixNativeJavaGbFeatureRepositoryalready uses).GBFeaturesRepositorypolling thread — the SWR poll scheduler used the default (non-daemon) thread factory: the only non-daemon thread in the SDK, and it keeps the JVM alive if an application exits without callingshutdown(). Now a named daemon thread (growthbook-feature-poll), matching the SSE retry factory.FeatureSnapshot—featuresJson/savedGroupsJson/parsedFeatures/parsedSavedGroupswere four independently assigned volatile fields, read separately byGrowthBookClient.buildGlobalContext, so a refresh landing between two reads produced a context with new features + old saved groups. They are now captured together in one immutableFeatureSnapshotswapped through a singleAtomicReference; existing getters delegate, andbuildGlobalContextreads the snapshot once. New publicgetFeatureSnapshot().What's NOT changed:
GrowthBookinternals (single-threaded by design; ).