Details
-
Bug
-
Status: Open
-
Normal
-
Resolution: Fixed
-
Normal
-
Normal
Description
I've noticed some netty related errors in trunk in some of the dtest results. Just want to make sure that we don't have to change anything related to the exception handling in our pipeline and that this isn't a netty issue. Actually if this causes flakiness but is otherwise harmless, we should do something about it, even if it's just on the dtest side.
WARN [epollEventLoopGroup-2-9] 2017-06-28 17:23:49,699 Slf4JLogger.java:151 - An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception. io.netty.channel.unix.Errors$NativeIoException: syscall:read(...)() failed: Connection reset by peer at io.netty.channel.unix.FileDescriptor.readAddress(...)(Unknown Source) ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
And again in another test:
WARN [epollEventLoopGroup-2-8] 2017-06-29 02:27:31,300 Slf4JLogger.java:151 - An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception. io.netty.channel.unix.Errors$NativeIoException: syscall:read(...)() failed: Connection reset by peer at io.netty.channel.unix.FileDescriptor.readAddress(...)(Unknown Source) ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
Edit:
The io.netty.channel.unix.Errors$NativeIoException: syscall:read(...)() failed error also causes tests to fail for 3.0 and 3.11.
Attachments
Attachments
Issue Links
- is related to
-
CASSANDRA-17888 Uncaught exceptions in Netty pipeline CASSANDRA-13649
- Resolved