Automatic pongs should not be sent when connection is closed

[pshevche]

Jetty version(s)
9.4.48.v20220622

Java version/vendor
Eclipse Adoptium OpenJDK Runtime Environment 11.0.15+10

OS type/version
Linux 5.4.0-122-generic (amd64)

Description
We observe that Jetty websocket client automatically replies to pings with pongs, even though the channel has already been closed in the meantime. In this scenario, we expect that no pong should be sent.

java.nio.channels.ClosedChannelException	
    at org.eclipse.jetty.websocket.common.io.FrameFlusher.enqueue (SourceFile:109)	
    at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.outgoingFrame (SourceFile:579)	
    at org.eclipse.jetty.websocket.client.io.WebSocketClientConnection.outgoingFrame (SourceFile:58)	
    at org.eclipse.jetty.websocket.common.extensions.ExtensionStack$Flusher.process (SourceFile:403)	
    at org.eclipse.jetty.util.IteratingCallback.processing (SourceFile:241)	
    at org.eclipse.jetty.util.IteratingCallback.iterate (SourceFile:223)	
    at org.eclipse.jetty.websocket.common.extensions.ExtensionStack.outgoingFrame (SourceFile:280)	
    at org.eclipse.jetty.websocket.common.WebSocketSession.outgoingFrame (SourceFile:360)	
    at org.eclipse.jetty.websocket.common.WebSocketRemoteEndpoint.uncheckedSendFrame (SourceFile:322)	
    at org.eclipse.jetty.websocket.common.WebSocketRemoteEndpoint.sendAsyncFrame (SourceFile:243)	
    at org.eclipse.jetty.websocket.common.WebSocketRemoteEndpoint.sendPong (SourceFile:386)	
    at org.eclipse.jetty.websocket.common.events.AbstractEventDriver.incomingFrame (SourceFile:133)	
    at org.eclipse.jetty.websocket.common.WebSocketSession.incomingFrame (SourceFile:326)	
    at org.eclipse.jetty.websocket.common.extensions.ExtensionStack.incomingFrame (SourceFile:202)	
    at org.eclipse.jetty.websocket.common.Parser.notifyFrame (SourceFile:225)	
    at org.eclipse.jetty.websocket.common.Parser.parseSingleFrame (SourceFile:259)	
    at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.onFillable (SourceFile:459)	
    at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.onFillable (SourceFile:440)	
    at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded (SourceFile:311)	
    at org.eclipse.jetty.io.FillInterest.fillable (SourceFile:105)	
    at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable (SourceFile:555)	
    at org.eclipse.jetty.io.ssl.SslConnection.onFillable (SourceFile:410)	
    at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded (SourceFile:164)	
    at org.eclipse.jetty.io.FillInterest.fillable (SourceFile:105)	
    at org.eclipse.jetty.io.ChannelEndPoint$1.run (SourceFile:104)	
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask (SourceFile:338)	
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce (SourceFile:315)	
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce (SourceFile:173)	
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run (SourceFile:131)	
    at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run (SourceFile:409)	
    at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob (SourceFile:883)	
    at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run (SourceFile:1034)	
    at java.lang.Thread.run (Thread.java:829)

[lachlan-roberts]

Jetty 9.4 has reached the end of community support (see #7958).

If you upgrade to Jetty 10 do you still encounter this error? Jetty 10 has major changes to the websocket implementation, so you may not experience the same issue after upgrading.

[pshevche]

Jetty 9.4 has reached the end of community support (see #7958).

If you upgrade to Jetty 10 do you still encounter this error? Jetty 10 has major changes to the websocket implementation, so you may not experience the same issue after upgrading.

Thank you for a quick response. Unfortunately, we are not able to upgrade to Jetty 10 yet, as we have to stay backwards compatible with Java 8 for the time being. It seems like you've already checked that the issue is present in Jetty 10 and #8356 should resolve it. Do you need any more input from my side?

[lachlan-roberts]

@pshevche the problem does not currently exist in Jetty 10 as the failure is ignored with a NOOP callback, the PR #8356 is really just a cleanup to make things a bit nicer with the implementation.