cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edward Capriolo (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
Date Mon, 03 Apr 2017 19:14:42 GMT

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

Edward Capriolo commented on CASSANDRA-13396:
---------------------------------------------

{quote}
Logging a warning for users isn't the same as throwing an exception. It's not like we're talking
about a system property here that requires explicit operator involvement to even run with
another logger, it's logging a single warning message that bugs may happen and we haven't
actively tested other configs. I don't think that's unreasonable, and it's not "get off my
lawn". This isn't an unreasonable compromise - we don't crash, but we give operators a chance
to know that they're running an untested config.
{quote}

The "get off my lawn" is related to this entire process. It had not even checked who added
the code originally. I did not quite understand why it got a -1 so fast. -1s are "rare" and
kill the proposal dead.

https://www.apache.org/foundation/voting.html
For code-modification votes, +1 votes are in favour of the proposal, but -1 votes are vetos
and kill the proposal dead until all vetoers withdraw their -1 votes.

The original reasons given were "This change will cause weird and hard to catch follow-up
issues (see the discussions and issues around that piece code), which cannot be caught by
neither unit nor dtests because it's an unsupported setup. We do not support embedding C*
in a container (i.e. a JVM not controlled "by us")"

Lets break this down:
1) "This change will cause weird and hard to catch follow-up issues"
Hard to quantify and the statement itself is a hypothesis. Can "WILL CAUSE" be proven? No.

2) which cannot be caught by neither unit nor dtests because it's an unsupported setup
Even though we are SURE issues that "WILL HAPPEN" they "CANNOT BE CAUGHT" . Amazing how that
logic works.

3) We do not support embedding C* in a container
Untrue. How does one run the CDC daemon? Not a written rule anyway.

If adding a single if statement to block of code and getting 3 completely ludicrous objections
from the person who happened to write said code is not "get off my lawn" then I don't know
what is.



> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
> ----------------------------------------------------------------
>
>                 Key: CASSANDRA-13396
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Edward Capriolo
>            Priority: Minor
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message