Repository navigation
[Bug] Make composite input stream handling safe when stream close races with an in-progress read #16458
Description
Pre-check
- I am sure that all the content I provide is in English.
Search before asking
- I had searched in the issues and found no similar issues.
Apache Dubbo Component
Java SDK (apache/dubbo)
Dubbo Version
Dubbo Java 3.3.7-SNAPSHOT, OpenJDK 25, WINDOWS
Steps to reproduce this issue
Fix composite input stream handling so that closing a stream while a concurrent read operation is actively consuming data does not cause unexpected stream closed exceptions or state corruption. When a client connection terminates abruptly during HTTP/2 streaming, the transport layer triggers a stream closure on the I/O event thread, which can execute simultaneously while an application worker thread is reading from the composite input stream for that same request. The composite stream handling must safely synchronize or manage concurrent closure during active reads so that in-flight read operations complete or terminate cleanly without raising unhandled concurrent access errors.
What you expected to happen
The composite stream handling must safely synchronize or manage concurrent closure during active reads so that in-flight read operations complete or terminate cleanly without raising unhandled concurrent access errors.
Anything else
No response
Do you have a (mini) reproduction demo?
- Yes, I have a minimal reproduction demo to help resolve this issue more effectively!
Are you willing to submit a pull request to fix on your own?
- Yes I am willing to submit a pull request on my own!
Code of Conduct
- I agree to follow this project's Code of Conduct
Activity
Lubaoshuai commentedon Sep 13, 2026
Hi, is anyone already working on this? Looking at CompositeInputStream, totalAvailable/readIndex are plain ints and the read loop releases the head stream once available() == 0, so a close() racing an in-flight read can observe torn state. I'd like to attempt a fix — my inclination is to make close() idempotent and synchronize the stream swap in the read loop, then define read-after-close as EOF. One question before I start: when close() lands mid-read, should a read() that already copied some bytes return the partial count, or is throwing preferred?
LI123456mo commentedon Sep 16, 2026
Hello @Lubaoshuai , you can work on it you have a good idea, i'll check