FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

Allow scheduling of CF completion in parallel by fxbonnet · Pull Request #277 · graphql-java/java-dataloader · GitHub

Allow scheduling of CF completion in parallel - #277

Open
fxbonnet wants to merge 4 commits into
graphql-java:masterfrom
fxbonnet:allow-scheduling-of-future-completions-in-parallel
Open

Allow scheduling of CF completion in parallel#277
fxbonnet wants to merge 4 commits into
graphql-java:masterfrom
fxbonnet:allow-scheduling-of-future-completions-in-parallel

Conversation

Copy link
Copy Markdown

When a batch loading function returns, we currently complete all CompletableFutures sequentially on the calling thread. Since CompletableFuture.complete(...) also executes any continuations attached via thenApply(...) or thenCompose(...), large batches can significantly delay the return of dispatch().

This PR introduces an option to execute these continuations in parallel instead.

clearCacheKeys.add(key);
}
} else {
future.complete(value);

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

This misses the Try path of completion

Copy link
Copy Markdown
Member

@fxbonnet I am not sure about this PR: with the new hook introduced by @bbakerman in #275 you can already offload every completion onto a new thread and hence it will run in parallel if you choose todo so. I have problems seeing how this approach is different/better.

fxbonnet force-pushed the allow-scheduling-of-future-completions-in-parallel branch from dd2af99 to e04c76d Compare May 18, 2026 22:29

Copy link
Copy Markdown
Author

@andimarek I created this PR after my comment on @bbakerman 's PR #275 (comment)
The PR allowed to offload the completions to a separate thread, but in case the batch load contains multiple keys, the completions for each key would still happen sequentially.
For clarity I just rebased this PR onto @bbakerman 's branch. The main change is that instead of passing a single Runnable to scheduleCompletion, we would pass a List<Runnable> (one for each key), giving the option to execute them in parallel.

}

List<K> clearCacheKeys = new ArrayList<>();
Collection<K> clearCacheKeys = new ConcurrentLinkedQueue<>();

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

clearCacheKeys may now be accessed concurrently by multiple thread if we execute the Runnables in parallel.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

good call - price of side effects outside a thread

andimarek left a comment
edited
Loading

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Requesting changes for a semantic regression around ValueCache hits and context-aware batch loaders.

I opened #278 as a small draft PR showing one possible fix: #278

The PR now constructs a BatchLoaderEnvironment before value-cache filtering:

BatchLoaderEnvironment environment = mkBatchLoaderEnv(keys, keyContexts);
CompletableFuture<List<V>> batchLoad = invokeLoader(environment, keys, keyContexts, queuedFutures, loaderOptions.cachingEnabled());

But invokeLoader(..., cachingEnabled=true) can then remove value-cache hits and invoke the actual batch loader with only missedKeys / missedKeyContexts while still passing the original environment:

CompletableFuture<List<V>> batchLoad = invokeLoader(environment, missedKeys, missedKeyContexts, missedQueuedFutures);

That breaks the existing semantics of BatchLoaderEnvironment: environment.getKeyContextsList() is expected to be aligned with the keys argument passed to the loader. A concrete failure case:

  1. The queued dispatch contains keys=[A, B] and keyContexts=[ctxA, ctxB].
  2. ValueCache returns a hit for A and a miss for B.
  3. The actual batch loader is invoked with keys=[B].
  4. The reused environment was built from [A, B], so environment.getKeyContextsList().get(0) is ctxA, not ctxB.

That means a BatchLoaderWithContext implementation that indexes environment.getKeyContextsList() alongside its keys argument can load B using A's context. This is observable behavior and can be a security/data-isolation issue if key contexts carry tenant, auth, locale, or request-scoped metadata.

Please build the BatchLoaderEnvironment from the actual key/context list passed to the concrete loader call after value-cache filtering, or otherwise preserve the invariant that environment.getKeyContextsList() is ordered and sized to match the loader's keys argument. This should also get a regression test with a partial ValueCache hit and a context-aware batch loader asserting that the missed key receives its own context.

PR #278 does exactly that by rebuilding the environment for missedKeys / missedKeyContexts before the concrete loader invocation and adding the regression test.

andimarek commented May 20, 2026
edited
Loading

Copy link
Copy Markdown
Member

I opened a small draft PR with one possible fix for the ValueCache / BatchLoaderEnvironment context alignment issue: #278

Copy link
Copy Markdown
Author

Thanks @andimarek I have added your commit to the PR

fxbonnet requested a review from andimarek May 21, 2026 07:12

Copy link
Copy Markdown
Member

This should now be ready - it has the extra fix @andimarek wanted

Copy link
Copy Markdown
Author

Hi @andimarek is there something I need to do for this PR to be ready to merge?

Copy link
Copy Markdown

Hello, this pull request has been inactive for 60 days, so we're marking it as stale. If you would like to continue working on this pull request, please make an update within the next 30 days, or we'll close the pull request.

github-actions Bot added the Stale label Aug 16, 2026
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

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants


Back | FazBrowse Home | New Git URL