(mina-sshd) branch master updated: [SSHD-1343] Correct javadoc in ChannelDataReceiver

[twolf]

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;