ffang commented on code in PR #3674:
URL: https://github.com/apache/cxf/pull/3674#discussion_r4461548339
##########
rt/transports/http-hc5/src/main/java/org/apache/cxf/transport/http/asyncclient/hc5/SharedInputBuffer.java:
##########
@@ -97,6 +97,9 @@ public int consumeContent(final ByteBuffer buffer, boolean
last) throws IOExcept
}
if (!buffer().hasRemaining() && !this.endOfStream) {
+ // Wake up a reader waiting for data first: only the reader
signals suspendInput,
+ // once it has drained the buffer
+ this.condition.signalAll();
Review Comment:
Thanks @reta! I checked the hc4 `SharedInputBuffer`, and I don't think it
needs the change: it doesn't block the I/O dispatcher thread, so it can't
deadlock this way. When the buffer is full, `consumeContent()` only calls
`ioctrl.suspendInput()`, which doesn't block, and it already signals the reader
once, unconditionally, right after that:
```java
if (!this.buffer.hasRemaining() && this.ioctrl != null && !this.endOfStream)
{
this.ioctrl.suspendInput();
}
this.condition.signalAll();
```
The reader then resumes input with `ioctrl.requestInput()` in
`waitForData()`, instead of the dispatcher waiting for it. So it's already in
the same shape as the hc5 one now: a single signal, and no wait. I also ran the
same scenario as the new `SharedInputBufferTest` against it (4 KiB block, 1 KiB
buffer, reader waiting with a 256-byte array), and it completes.
Freeman
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
