Closed StefanBratanov closed 10 months ago
Basically speaking this is actually an exceptional situation. The same as trying to write to a closed (RST
) stream.
When local party is disconnecting (or closing for write or FIN
) it doesn't necessarily expect the stream to close, it may e.g. expect some data from remote party.
If we want to be more lenient to that case then it probably makes sense to catch that explicit exception on client side (Teku) as it is now implemented in some places.
It also confuses me a bit that Teku tries to close the stream for writing when it was closed (presumably remotely):
at tech.pegasys.teku.networking.p2p.libp2p.rpc.LibP2PRpcStream.closeWriteStream(LibP2PRpcStream.java:62) ~[classes/:?]
at tech.pegasys.teku.networking.eth2.rpc.core.RpcResponseCallback.completeWithErrorResponse(RpcResponseCallback.java:73) ~[classes/:?]
at tech.pegasys.teku.networking.eth2.rpc.core.Eth2IncomingRequestHandler.readComplete(Eth2IncomingRequestHandler.java:93) ~[classes/:?]
at tech.pegasys.teku.networking.p2p.libp2p.rpc.RpcHandler$Controller.lambda$onRemoteWriteClosed$3(RpcHandler.java:251) ~[classes/:?]
at java.util.Optional.ifPresentOrElse(Optional.java:196) [?:?]
at tech.pegasys.teku.networking.p2p.libp2p.rpc.RpcHandler$Controller.runHandler(RpcHandler.java:265) [classes/:?]
at tech.pegasys.teku.networking.p2p.libp2p.rpc.RpcHandler$Controller.onRemoteWriteClosed(RpcHandler.java:251) [classes/:?]
at tech.pegasys.teku.networking.p2p.libp2p.rpc.RpcHandler$Controller.onChannelClosed(RpcHandler.java:257) [classes/:?]
at tech.pegasys.teku.networking.p2p.libp2p.rpc.RpcHandler$Controller.handlerRemoved(RpcHandler.java:238) [classes/:?]
Thanks for t
Basically speaking this is actually an exceptional situation. The same as trying to write to a closed (
RST
) stream. When local party is disconnecting (or closing for write orFIN
) it doesn't necessarily expect the stream to close, it may e.g. expect some data from remote party.If we want to be more lenient to that case then it probably makes sense to catch that explicit exception on client side (Teku) as it is now implemented in some places.
It also confuses me a bit that Teku tries to close the stream for writing when it was closed (presumably remotely):
at tech.pegasys.teku.networking.p2p.libp2p.rpc.LibP2PRpcStream.closeWriteStream(LibP2PRpcStream.java:62) ~[classes/:?] at tech.pegasys.teku.networking.eth2.rpc.core.RpcResponseCallback.completeWithErrorResponse(RpcResponseCallback.java:73) ~[classes/:?] at tech.pegasys.teku.networking.eth2.rpc.core.Eth2IncomingRequestHandler.readComplete(Eth2IncomingRequestHandler.java:93) ~[classes/:?] at tech.pegasys.teku.networking.p2p.libp2p.rpc.RpcHandler$Controller.lambda$onRemoteWriteClosed$3(RpcHandler.java:251) ~[classes/:?] at java.util.Optional.ifPresentOrElse(Optional.java:196) [?:?] at tech.pegasys.teku.networking.p2p.libp2p.rpc.RpcHandler$Controller.runHandler(RpcHandler.java:265) [classes/:?] at tech.pegasys.teku.networking.p2p.libp2p.rpc.RpcHandler$Controller.onRemoteWriteClosed(RpcHandler.java:251) [classes/:?] at tech.pegasys.teku.networking.p2p.libp2p.rpc.RpcHandler$Controller.onChannelClosed(RpcHandler.java:257) [classes/:?] at tech.pegasys.teku.networking.p2p.libp2p.rpc.RpcHandler$Controller.handlerRemoved(RpcHandler.java:238) [classes/:?]
Thank you. It makes sense. I will try to make sense of it and fix it in Teku.
When running Teku with
develop
and yamux enabled, getting following exception relatively often. Essentially stream seems to be already closed whenLibP2PRpcStream
closes it, so think we shouldn't throw in this case.