You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Caleb Rackliffe (Jira)" <ji...@apache.org> on 2021/10/08 20:50:00 UTC

[jira] [Comment Edited] (CASSANDRA-17026) UnableToParseClientMessageFromBlockedSubnetTest.badMessageCausesProtocolExceptionFromExcludeList failing on extra log entries

    [ https://issues.apache.org/jira/browse/CASSANDRA-17026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17426368#comment-17426368 ] 

Caleb Rackliffe edited comment on CASSANDRA-17026 at 10/8/21, 8:49 PM:
-----------------------------------------------------------------------

To summarize, when protocol version decoding fails in the pre-V5 message handling code, we don't consume/skip the remaining {{Envelope}} bytes. So, we log on the initial decoding attempt, but then log again when the channel closure logic tries to decode again, which leads to all sorts of possible racy behavior in the test, which assumes a single log message per request.

PR: https://github.com/apache/cassandra/pull/1257
CircleCI: https://app.circleci.com/pipelines/github/maedhroz/cassandra?branch=CASSANDRA-17026


was (Author: maedhroz):
PR: https://github.com/apache/cassandra/pull/1257
CircleCI: https://app.circleci.com/pipelines/github/maedhroz/cassandra?branch=CASSANDRA-17026

> UnableToParseClientMessageFromBlockedSubnetTest.badMessageCausesProtocolExceptionFromExcludeList failing on extra log entries
> -----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-17026
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-17026
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Observability/Logging, Test/dtest/java
>            Reporter: Caleb Rackliffe
>            Assignee: Caleb Rackliffe
>            Priority: Normal
>             Fix For: 4.1
>
>
> This test, while parameterized and run more than once, expects a single log entry describing the reporting exclusion for the single query made with each parameter combination.
> However, we’re seeing this:
> {noformat}
> junit.framework.AssertionFailedError: 
> Expected size:<1>  but was:<2>  in:
> <["DEBUG [nioEventLoopGroup-5-2] {instance:id} 2021-10-07T09:49:42,974 Excluding client exception for /127.0.0.1:56628; address contained in client_error_reporting_exclusions",
>     "DEBUG [nioEventLoopGroup-5-3] {instance:id} 2021-10-07T09:49:42,984 Excluding client exception for /127.0.0.1:56634; address contained in client_error_reporting_exclusions"]>
> 	at org.apache.cassandra.distributed.test.UnableToParseClientMessageFromBlockedSubnetTest.badMessageCausesProtocolExceptionFromExcludeList(UnableToParseClientMessageFromBlockedSubnetTest.java:114)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
> Looking at the logs more deeply, the V3 and V4 protocol cases are actually logging twice, once on initially processing the message, and again on channel closure. There should be a way to eliminate the double logging...



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org