This is an automated email from the ASF dual-hosted git repository.
twolf pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/mina-sshd.git
The following commit(s) were added to refs/heads/master by this push:
new 88a8dd21b [SSHD-1343] Correct javadoc in ChannelDataReceiver
88a8dd21b is described below
commit 88a8dd21b0a11765947ebe320b7e229a49be9c3a
Author: Thomas Wolf <tw...@apache.org>
AuthorDate: Fri Mar 28 20:15:26 2025 +0100
[SSHD-1343] Correct javadoc in ChannelDataReceiver
---
CHANGES.md | 3 +++
.../org/apache/sshd/server/channel/ChannelDataReceiver.java | 11 ++++++-----
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/CHANGES.md b/CHANGES.md
index 4da3dc02a..9377f97e4 100644
--- a/CHANGES.md
+++ b/CHANGES.md
@@ -37,6 +37,9 @@
* [GH-700](https://github.com/apache/mina-sshd/issues/700) Fix race in
`AbstractCloseable.doCloseImmediately()`
* [GH-709](https://github.com/apache/mina-sshd/issues/709) `AbstractChannel`:
Handle keep-alive channel messages sent by an old OpenSSH server
+
+* [SSHD-1343](https://issues.apache.org/jira/projects/SSHD/issues/SSHD-1343)
Correct documentation in `ChannelDataReceiver`
+
## New Features
* [GH-705](https://github.com/apache/mina-sshd/issues/705) New method
`TcpipServerChannel.getPort()` returning the `ChannelToPortHandler`
diff --git
a/sshd-core/src/main/java/org/apache/sshd/server/channel/ChannelDataReceiver.java
b/sshd-core/src/main/java/org/apache/sshd/server/channel/ChannelDataReceiver.java
index da0d1ab92..c5f70b4fc 100644
---
a/sshd-core/src/main/java/org/apache/sshd/server/channel/ChannelDataReceiver.java
+++
b/sshd-core/src/main/java/org/apache/sshd/server/channel/ChannelDataReceiver.java
@@ -69,8 +69,8 @@ public interface ChannelDataReceiver extends Closeable {
* <p>
* On the other hand, if the callee is queueing up the received bytes
somewhere to be consumed later (for example by
* another thread), then this method should return 0, for the bytes aren't
really consumed yet. And when at some
- * later point the bytes are actually used, then you'll invoke {@code
channel.getLocalWindow().consumeAndCheck(len)}
- * to let the channel know that bytes are consumed.
+ * later point the bytes are actually used, then you'll invoke {@code
channel.getLocalWindow().release(len)} to let
+ * the channel know that bytes are consumed.
* </p>
*
* <p>
@@ -81,8 +81,9 @@ public interface ChannelDataReceiver extends Closeable {
*
* <p>
* In either case, the callee must account for every bytes it receives in
this method. Returning 0 and failing to
- * call back {@code channel.getLocalWindow().consumeAndCheck(len)} later
will dry up the window size, and eventually
- * the client will stop sending you any data.
+ * call back {@code channel.getLocalWindow().release(len)} later will dry
up the window size, and eventually the
+ * client will stop sending any data. (And if it does despite the window
size being zero, the channel will be
+ * forcibly closed.)
* </p>
*
* <p>
@@ -95,7 +96,7 @@ public interface ChannelDataReceiver extends Closeable {
* @param start buf[start] is the first byte that received from the
client.
* @param len the length of the bytes received. Can be zero.
* @return The number of bytes consumed, for the purpose of
the flow control. For a simple use case, you
- * return the value given by the 'len' parameter. See
the method javadoc for more details.
+ * return the value given by the 'len' parameter. See
above for more details.
* @throws IOException if failed to consume the data
*/
int data(ChannelSession channel, byte[] buf, int start, int len) throws
IOException;
