Skip to content

Java SDK: Serialize coordinator client send/receive for thread safety - #69080

Merged
jason810496 merged 2 commits into
apache:mainfrom
FrankYang0529:airflow-jdk-client-thread-safety
Jul 1, 2026
Merged

jason810496 merged 2 commits into
apache:mainfrom
FrankYang0529:airflow-jdk-client-thread-safety

Conversation

@FrankYang0529

Copy link
Copy Markdown
Member

Guard the whole send/receive pair in communicateImpl with a Mutex so concurrent task threads are serialized over the single channel, and verify the response id echoes the request id to reject a mis-paired response.


Was generative AI tooling used to co-author this PR?
  • Yes - Claude Code with Opus 4.8

  • Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
  • For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
  • When adding dependency, check compliance with the ASF 3rd Party License Policy.
  • For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

Comment thread java-sdk/sdk/src/main/kotlin/org/apache/airflow/sdk/execution/Comm.kt Outdated

@jason810496 jason810496 left a comment

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.

LGTM once addresses the comments TP pointed out. Thanks.

A Java task may call the SDK client from multiple threads. Every call goes through
one request/response channel to the supervisor. So it must be thread safe.

Signed-off-by: PoAn Yang <payang@apache.org>
Signed-off-by: PoAn Yang <payang@apache.org>
@FrankYang0529
FrankYang0529 force-pushed the airflow-jdk-client-thread-safety branch from 5efb31c to cd7020d Compare June 29, 2026 07:54
@jason810496
jason810496 merged commit 687134f into apache:main Jul 1, 2026
86 checks passed
@FrankYang0529
FrankYang0529 deleted the airflow-jdk-client-thread-safety branch July 1, 2026 10:41
FrankYang0529 added a commit to FrankYang0529/airflow that referenced this pull request Jul 3, 2026
Serializing each client's whole send → receive → deserialize round trip
behind one lock (apache#69080) allows only a single request in flight at a
time, so a task issuing concurrent calls over the shared comm socket
pays a full, serialized round trip per call.
Every frame already carries a request id, so a single background
dispatcher can read the socket and route each response by id, with the
lock guarding only the write.

Signed-off-by: PoAn Yang <payang@apache.org>
FrankYang0529 added a commit to FrankYang0529/airflow that referenced this pull request Jul 26, 2026
Serializing each client's whole send → receive → deserialize round trip
behind one lock (apache#69080) allows only a single request in flight at a
time, so a task issuing concurrent calls over the shared comm socket
pays a full, serialized round trip per call.
Every frame already carries a request id, so a single background
dispatcher can read the socket and route each response by id, with the
lock guarding only the write.

Signed-off-by: PoAn Yang <payang@apache.org>
FrankYang0529 added a commit to FrankYang0529/airflow that referenced this pull request Jul 26, 2026
Serializing each client's whole send → receive → deserialize round trip
behind one lock (apache#69080) allows only a single request in flight at a
time, so a task issuing concurrent calls over the shared comm socket
pays a full, serialized round trip per call.
Every frame already carries a request id, so a single background
dispatcher can read the socket and route each response by id, with the
lock guarding only the write.

Signed-off-by: PoAn Yang <payang@apache.org>
FrankYang0529 added a commit to FrankYang0529/airflow that referenced this pull request Jul 26, 2026
Serializing each client's whole send → receive → deserialize round trip
behind one lock (apache#69080) allows only a single request in flight at a
time, so a task issuing concurrent calls over the shared comm socket
pays a full, serialized round trip per call.
Every frame already carries a request id, so a single background
dispatcher can read the socket and route each response by id, with the
lock guarding only the write.

Signed-off-by: PoAn Yang <payang@apache.org>
jason810496 pushed a commit that referenced this pull request Jul 30, 2026
Serializing each client's whole send → receive → deserialize round trip
behind one lock (#69080) allows only a single request in flight at a
time, so a task issuing concurrent calls over the shared comm socket
pays a full, serialized round trip per call.
Every frame already carries a request id, so a single background
dispatcher can read the socket and route each response by id, with the
lock guarding only the write.

Signed-off-by: PoAn Yang <payang@apache.org>
dabla pushed a commit to dabla/airflow that referenced this pull request Aug 14, 2026
Serializing each client's whole send → receive → deserialize round trip
behind one lock (apache#69080) allows only a single request in flight at a
time, so a task issuing concurrent calls over the shared comm socket
pays a full, serialized round trip per call.
Every frame already carries a request id, so a single background
dispatcher can read the socket and route each response by id, with the
lock guarding only the write.

Signed-off-by: PoAn Yang <payang@apache.org>
imrichardwu pushed a commit to imrichardwu/airflow that referenced this pull request Sep 11, 2026
Serializing each client's whole send → receive → deserialize round trip
behind one lock (apache#69080) allows only a single request in flight at a
time, so a task issuing concurrent calls over the shared comm socket
pays a full, serialized round trip per call.
Every frame already carries a request id, so a single background
dispatcher can read the socket and route each response by id, with the
lock guarding only the write.

Signed-off-by: PoAn Yang <payang@apache.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants