You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In SwiftNIO it's generally a good idea that on errorCaught, the Channel should be closed to prevent leaking network connections that are in some error states. In swift-talk-backend this should be added to RouteHandler. But this advice applies to any NIO ChannelPipeline: Generally the last handler (I usually call it the 'application handler') should close on unknown error.
Why? Generally, ChannelHandlers fire errors in cases where they don't know how to recover themselves. If another, later ChannelHandler knows how to recover, that ChannelHandler would consume the error. In other words: If an error reaches the end of the pipeline, nobody knew how to handle that error and closing the Channel is a good default.
This has always been true in SwiftNIO but in NIO 2 this will become especially important because ByteToMessageDecoders (and the HTTP decoders) won't close the connections themselves anymore. Why is that? If the decoders themselves close the connection, then there's no way for the user to opt out.
The code to implement this is very straightforward:
publicfunc errorCaught(ctx:ChannelHandlerContext, error:Error){switch error {caselete as SomeErrorTypeIKnowHowToHandlewhere e.someCondition == expectedValue:
// handle error
case lete as SomeOtherErrorIKnowHowToHandle:
// handle that error
default:
// log error?
ctx.close(promise:nil)}}
The text was updated successfully, but these errors were encountered:
In SwiftNIO it's generally a good idea that on
errorCaught
, theChannel
should be closed to prevent leaking network connections that are in some error states. In swift-talk-backend this should be added toRouteHandler
. But this advice applies to any NIO ChannelPipeline: Generally the last handler (I usually call it the 'application handler') should close on unknown error.Why? Generally,
ChannelHandler
s fire errors in cases where they don't know how to recover themselves. If another, laterChannelHandler
knows how to recover, thatChannelHandler
would consume the error. In other words: If an error reaches the end of the pipeline, nobody knew how to handle that error and closing theChannel
is a good default.This has always been true in SwiftNIO but in NIO 2 this will become especially important because
ByteToMessageDecoder
s (and the HTTP decoders) won't close the connections themselves anymore. Why is that? If the decoders themselves close the connection, then there's no way for the user to opt out.The code to implement this is very straightforward:
The text was updated successfully, but these errors were encountered: