Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

[Feature]: Add invocation-owned executor isolation

Ouverte
  • Quelque chose ne va pas ?
#840 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@zhongkechen y travaille déjà.

Depuis le 25/9/2026.

  • #735 par @zhongkechen — ouverte

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
1/100
Type d'issue
Fonctionnalité
Clarté
Clairement spécifiée
Activité
À l'abandon
Stack technique
aws, java
Domaine
backend, distributed-systems

Piste de recherche

The issue says implementation is in PR #735 and should be resolved when that PR merges; inspect that PR and its validation results to understand the completed work. The issue lists the relevant configuration, executor lifecycle, and test controls, but the implementation is already underway, so there is no independent change to start here.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

enhancement pkg:sdk
Scope

This issue tracks the invocation-owned executor isolation implemented by open PR #735. Resolve this issue when #735 merges.

The change adds an opt-in executor ownership mode and the setup, shutdown, and failure-handling safeguards required by that mode. Main's task registry and owner/End ordering (#782/#731), and #733's deadline/cooperative-cancellation policy (#838), are prerequisites preserved by this PR.

Problem

withExecutorService(...) shares one caller-owned executor across every invocation using a DurableConfig. Concurrent LMI roots can exhaust a bounded pool while waiting for steps queued to that same pool. Applications need a way to give each native invocation its own execution capacity, without accidentally sharing that capacity or leaking the executor when setup, cancellation, result delivery, or cleanup fails.

Isolation must preserve caller-owned executor behavior and the selected invocation outcome. Executor callbacks can fail during state validation, shutdown, forced cleanup, termination waiting, or lease bookkeeping; those failures must not skip cleanup, stop another invocation's executor, erase the selected lifecycle failure or first JVM fatal, or lose delivery diagnostics.

Expected Behavior Implemented by #735
  • Add DurableConfig.Builder.withInvocationExecutorFactory(Supplier<? extends ExecutorService>). Each initialized invocation obtains a fresh, non-null, usable executor; the factory can be called concurrently on LMI. Reject simultaneous configuration of the factory and withExecutorService(...).
  • Route that invocation's root, steps, child contexts, and map/parallel coordinators through its selected executor, including plugin-enabled paths. Keep internal checkpoint/poll coordination on the SDK-managed executor. Preserve the shared, caller-owned mode when no factory is configured.
  • Enforce an identity lease so an executor already owned by an active invocation cannot be reused. Reject null/shutdown executors and safely dispose of a newly acquired executor if initialization fails, without querying or shutting down an executor already leased to another invocation.
  • Shut down an invocation-owned executor from the caller only after actual admitted work, owner/scope cleanup, admitted transport, and End have finished. Observe termination within the remaining cleanup allowance; attempt fallback cleanup when executor callbacks fail, restore interruption, and preserve safe lease ownership/release behavior.
  • Finalize failures both during manager initialization and after manager setup, including rejected root dispatch and expired admission. Preserve selected lifecycle failure and first-fatal precedence across serialization, delivery, outer MDC restoration, executor callbacks, termination, and state queries. Keep later failures as diagnostics without self-suppression, duplicate aliases, or suppression cycles; retain application ExecutionException identity and diagnostics from discarded wrappers.
  • Preserve the factory through toBuilder() and the local test runner, including replay/resume, while acquiring a new executor for each invocation. Document factory ownership, concurrency requirements, and the limits of fixed-pool isolation.
Acceptance Criteria
  • Concurrent invocations using fresh fixed(2) executors can each run a root and synchronous step without sharing execution capacity; all user-task roles use the invocation-selected executor.
  • Factory validation, mutually exclusive configuration, active identity reuse, configuration copying, and local replay/resume are covered.
  • Caller-owned shared executors are never shut down by the owned-executor path. Initialization/setup rejection cleans up only an executor acquired by the failing invocation.
  • Normal completion, caller interruption, expired admission, and rejected dispatch preserve actual owner/End-before-shutdown ordering and required cleanup attempts.
  • Shutdown, fallback shutdown, termination, state-query, delivery, serializer, and MDC failures retain the selected cause, fatal priority, interrupt state, and required diagnostics without alias cycles or lost wrapper diagnostics.
  • Confirmed termination and unsuccessful cleanup exercise lease release/retention controls without permitting simultaneous reuse of an active executor.
  • Java 17/25, plugin/no-plugin, configuration-copy/local-runner, and packaged-artifact controls cover the new mode and preserve the existing default/shared mode.
  • The LMI fixed2 fixture uses per-invocation fixed(2) pools, and documentation explicitly states that shared/nested fixed-pool starvation and non-cooperative cleanup bounds remain outside this issue.
Implementation and Validation

Implementation: #735, current head cd59f6542248bbdc4a98c85d12e5eee64b1ecb7e at scope extraction. Its diff is relative to the #733 branch, so the deadline implementation is not counted again here.

The PR description reports Java 17/25 reactor runs, 240 focused runtime controls, packaged SDK/OTel cases, and local LMI controls; see #735 for exact validated snapshots and results. Its fixed2 fixture now exercises invocation-local pools. The shared nested2 fixture remains diagnostic and is excluded from the 12 gating cloud cases. Deployed validation of the final tree remains pending.

Limits

This is an opt-in mitigation for contention between invocations. It does not change existing shared fixed-pool scheduling or separate blocking ancestors from descendants within one invocation's bounded pool; general progress and resource-capacity work remains in #839.

Actual owner/End completion remains required before executor shutdown. Non-cooperative tasks, plugin hooks, or custom clients can delay that point beyond the cleanup allowance, so this issue does not claim a hard caller-return, executor-termination, or LMI worker-reclamation guarantee. Those limits and deployed lifecycle acceptance remain in #726.

Langage dominant
Java
Étoiles
28
Forks
16
Merge moyen
2 j 3 h
PR mergées (30 j)
62

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de aws/aws-durable-execution-sdk-java

Toutes les issues de aws/aws-durable-execution-sdk-java

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.