-
Type:
Bug
-
Resolution: Fixed
-
Priority:
P4
-
Affects Version/s: 26
-
Component/s: core-libs
-
master
When a connection receives a CONNECTION_CLOSE frame, it is supposed to enter the draining state and ignore all incoming packets for at least the next 3 PTO periods.
The implementation is done in the DrainingConnection class, which is supposed to replace the original connection when a closing datagram is received. However, the connection is first removed from the endpoint, and then the draining connection is never registered.
Early removal of the connection may result in sending unnecessary stateless reset packets.
The connection is removed here:
at java.net.http/jdk.internal.net.http.quic.QuicEndpoint.removeConnection(QuicEndpoint.java:1538)
at java.net.http/jdk.internal.net.http.quic.QuicEndpoint.pushClosedDatagram(QuicEndpoint.java:1524)
at java.net.http/jdk.internal.net.http.quic.QuicConnectionImpl.pushEncryptedDatagram(QuicConnectionImpl.java:2815)
at java.net.http/jdk.internal.net.http.quic.QuicConnectionImpl.pushDatagram(QuicConnectionImpl.java:1009)
at java.net.http/jdk.internal.net.http.quic.ConnectionTerminatorImpl.pushConnectionCloseFrame(ConnectionTerminatorImpl.java:443)
at java.net.http/jdk.internal.net.http.quic.ConnectionTerminatorImpl.drain(ConnectionTerminatorImpl.java:333)
and the attempt to replace the connection with a draining one is done here:
at java.net.http/jdk.internal.net.http.quic.QuicEndpoint.draining(QuicEndpoint.java:1603)
at java.net.http/jdk.internal.net.http.quic.ConnectionTerminatorImpl.drain(ConnectionTerminatorImpl.java:350)
The implementation is done in the DrainingConnection class, which is supposed to replace the original connection when a closing datagram is received. However, the connection is first removed from the endpoint, and then the draining connection is never registered.
Early removal of the connection may result in sending unnecessary stateless reset packets.
The connection is removed here:
at java.net.http/jdk.internal.net.http.quic.QuicEndpoint.removeConnection(QuicEndpoint.java:1538)
at java.net.http/jdk.internal.net.http.quic.QuicEndpoint.pushClosedDatagram(QuicEndpoint.java:1524)
at java.net.http/jdk.internal.net.http.quic.QuicConnectionImpl.pushEncryptedDatagram(QuicConnectionImpl.java:2815)
at java.net.http/jdk.internal.net.http.quic.QuicConnectionImpl.pushDatagram(QuicConnectionImpl.java:1009)
at java.net.http/jdk.internal.net.http.quic.ConnectionTerminatorImpl.pushConnectionCloseFrame(ConnectionTerminatorImpl.java:443)
at java.net.http/jdk.internal.net.http.quic.ConnectionTerminatorImpl.drain(ConnectionTerminatorImpl.java:333)
and the attempt to replace the connection with a draining one is done here:
at java.net.http/jdk.internal.net.http.quic.QuicEndpoint.draining(QuicEndpoint.java:1603)
at java.net.http/jdk.internal.net.http.quic.ConnectionTerminatorImpl.drain(ConnectionTerminatorImpl.java:350)
- links to
-
Commit(master)
openjdk/jdk/7a7e7c9a
-
Review(master)
openjdk/jdk/28874