Skip to content

Propagate Connection Closure to Client#64

Open
crazyrokr wants to merge 3 commits intoJavaSaBr:developfrom
crazyrokr:propagate-connection-close
Open

Propagate Connection Closure to Client#64
crazyrokr wants to merge 3 commits intoJavaSaBr:developfrom
crazyrokr:propagate-connection-close

Conversation

@crazyrokr
Copy link
Copy Markdown
Contributor

@crazyrokr crazyrokr commented May 6, 2026

This PR introduces the propagation of connection closures from the server to the client. Previously, clients might not have been correctly notified when a connection was closed by the server, potentially leading to stale connection states or unhandled exceptions in reactive streams.

Changes

  • Added ConnectionClosedException to explicitly handle connection closure scenarios.
  • Updated AbstractConnection to notify active FluxSink subscribers with a ConnectionClosedException when a connection is closed.
  • Modified AbstractNetworkPacketReader and AbstractSslNetworkPacketReader to correctly detect and report connection closures.
  • Added a new unit test ConnectionCloseTest to verify that the client correctly receives the ConnectionClosedException when a server connection is closed.

Comment thread rlib-network/src/main/java/javasabr/rlib/network/impl/AbstractConnection.java Outdated
Comment thread rlib-network/src/main/java/javasabr/rlib/network/impl/AbstractConnection.java Outdated
Comment thread rlib-network/src/main/java/javasabr/rlib/network/impl/AbstractConnection.java Outdated
protected void handleReceivedData(int receivedBytes, ByteBuffer readingBuffer) {
if (receivedBytes == -1) {
doHandshake(sslNetworkBuffer(), -1);
connection.close();
Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's not always about closing connection by my testing

Copy link
Copy Markdown
Contributor Author

@crazyrokr crazyrokr May 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's correct to close the connection in AbstractSslNetworkPacketReader when receivedBytes == -1.

In non-blocking I/O (which this library appears to use), a return value of -1 from a SocketChannel.read() call signifies that the connection has been gracefully closed by the remote peer (end-of-stream). If the local connection is not closed in response to this, it may leave the channel in an inconsistent or zombie state, potentially leading to resource leaks or repeated failed reads.

A test was added for this case: 6b19a97

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.

2 participants