[jira] [Comment Edited] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[
https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16412169#comment-16412169
]
Jason Brown edited comment on CASSANDRA-13396 at 3/23/18 10:05 PM:
---
Looks like you are using {{StaticLoggerBinder}} to figure out which logging
implementation to use. That seems
[deprecated|https://www.slf4j.org/faq.html#changesInVersion18] as of slf4j v1.8
(soon to be released), in lieu of some JIgsaw modularization. I have absolutely
zero desire to investigate that modularization, wrt to cassandra as a whole.
What are the alternatives here? Remaining on the current version of slf4j is
certainly an option
ftr, 3.11 uses slf4j 1.7.7
was (Author: jasobrown):
Looks like you are using {{StaticLoggerBinder}} to figure out which logging
implementation to use. That seems
[deprecated|https://www.slf4j.org/faq.html#changesInVersion18] as of slf4j v1.8
(soon to be released), in lieu of some JIgsaw modularization. I have absolutely
zero desire to investigate that modularization. What are the alternatives here?
> 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
>Assignee: Eugene Fedotov
>Priority: Minor
> Attachments: CASSANDRA-13396_ehubert_1.patch
>
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16364865#comment-16364865 ] Eric Hubert edited comment on CASSANDRA-13396 at 2/16/18 2:42 PM: -- [~jasobrown], fair enough. From what I read/understood the majority of users (if not all, definitely including us) facing this issue, wanted to use Cassandra as an embedded server (mostly for integration testing purposes) utilizing class org.apache.cassandra.service.CassandraDaemon - so no production deployment of a standalone server or cluster. While running in the same JVM alongside an application using slf4j with any slf4j supported backend != logback after upgrading to Cassandra 3.10 or later you are in trouble and no longer able to start the Cassandra server, although logging/logging performance are none of your (primary) goals/concerns. I doubt there are many users who want to configure a standalone single or multi-node Cassandra installation using a different logging backend to use this in production and have your support, but many users want to write automated integration/scenario tests of their own application interacting with Cassandra using an embedded Cassandra server in addition to plain unit tests using mocks without being forced to switch the logging backend chosen for their application for similar reasons you have. Therefore I see no conflict at all. An implementation could even somehow enforce the differentiation between embedded and standalone usage similar to "runManaged" in CassandraDeamon to only allow/support other logging backends (skip special logging backend specific configuration) when CassandraDeamon is used/configured differently than done from main() used by a standalone server installation, if this is really a concern you want to see addressed. Even in this case one should exchange nasty runtime exceptions or even JVM errors (ClassCastException or NoClassDefFoundError) with a dedicated error message: "When using a Cassandra standalone installation the only supported logging backend is logback." For ClassCastException add something like "slf4j is currently bound to a different logging framework. Please ensure your classpath only contains logback implementations!" For NoClassDefFoundError add something like "No logback implementation was found. Please ensure your classpath contains the bundled logback implementation!" You can decide to abort the startup or have the same behavior as for the embedded case, but only providing a detailed error logging regarding the unsupported setup. For embedded use cases one could advice programmers to activate the CassandraDaemon differently (e.g. some parameter) and here I would propose to simply not execute all logback specific configuration logic - e.g. try loading specific logback classes via reflection, so in this mode logback could be easily replaced by any slf4j logging backend which the application currently uses without further adjustments. JUnit test cases might be a bit tricky, because I think they involve different classpath setups of the used test runner to simulate/trigger those type of issues. was (Author: ehubert): [~jasobrown], fair enough. From what I read/understood the majority of users (if not all, definitely including us) facing this issue, wanted to use Cassandra as an embedded server (mostly for integration testing purposes) utilizing class org.apache.cassandra.service.CassandraDaemon - so no production deployment of a standalone server or cluster. While running alongside an application using slf4j with any slf4j supported backend != logback your are in trouble and no longer able to start the cassandra server, although logging/logging performance are none of your (primary) goals/concerns. I doubt there are many users who want to configure a standalone single or multi-node Cassandra installation using a different logging backend to use this in production and have your support, but many users want to write automated integration/scenario tests of their own application interacting with Cassandra using an embedded Cassandra server in addition to plain unit tests using mocks without being forced to switch the logging backend chosen for their application for similar reasons you have. Therefore I see no conflict at all. An implementation could even somehow enforce the differentation between embedded and standalone similar to "runManaged" to only allow/support other logging backends (skip special logging backend specific configuration) if CassandraDeamon is used/configured differently than from main() as done by a standalone server installation, this this is really a concern you want to see addressed. > Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager > > > Key: CASSANDRA-13396
[jira] [Comment Edited] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16364505#comment-16364505 ] Jason Brown edited comment on CASSANDRA-13396 at 2/14/18 5:53 PM: -- OK, looks like this has drifted for long enough. I'm gonna look at the patches and review for commit. UPDATE: I'll wait until CASSANDRA-14183 is committed before attacking this (as it touches logging, as well) was (Author: jasobrown): OK, looks like this has drifted for long enough. I'm gonna look at the patches and review for commit. > 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 >Assignee: Eugene Fedotov >Priority: Minor > > https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16069393#comment-16069393 ] Gus Heck edited comment on CASSANDRA-13396 at 6/30/17 3:01 AM: --- After some IRC discussion, I've been encouraged to submit a patch. Here's an implementation of my #3 suggestion above: https://github.com/nsoft/cassandra/commit/382a44c238b6d4bd7e3d8cc7bbd6710b0a7c5274 Though Github's diff has done a fabulous job of obfuscating it, the patch is very simple all I did was add a constant, and two conditions that read the system property represented by the constant and prevent this security manager and its policies from getting installed via the install() method if the system property has been set. Circle CI here: https://circleci.com/gh/nsoft/cassandra/2 (still running as of this comment, but I expect it to pass) Ran tests locally and Installed a version with this patch in JesterJ and everything seems happy there. was (Author: gus_heck): After some IRC discussion, I've been encouraged to submit a patch. Here's an implementation of my #3 suggestion above: https://github.com/nsoft/cassandra/commit/382a44c238b6d4bd7e3d8cc7bbd6710b0a7c5274 Though Github's diff has done a fabulous job of obfuscating it, the patch is very simple all I did was add a constant, and two conditions that read the system property represented by the constant and prevent this security manager and its policies from getting installed via the install() method if the system property has been set. Circle CI here: https://circleci.com/gh/nsoft/cassandra/2 (still running as of this comment, but I expect it to pass) Installed a version with this patch in JesterJ and everything seems happy there. > 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 >Assignee: Eugene Fedotov >Priority: Minor > > https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15997073#comment-15997073 ] Eugene Fedotov edited comment on CASSANDRA-13396 at 5/4/17 5:04 PM: I made the [suggested changes by Jeff|https://issues.apache.org/jira/browse/CASSANDRA-13396?focusedCommentId=15996968=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15996968]. was (Author: eugenefedoto): I made the suggested changes. > 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 >Assignee: Eugene Fedotov >Priority: Minor > > https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[
https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15996968#comment-15996968
]
Jeff Jirsa edited comment on CASSANDRA-13396 at 5/4/17 3:58 PM:
[~eugenefedoto] - two quick notes
1) In all three versions of your patch, we can't
[throw|https://github.com/eugenefedoto/cassandra/commit/5957dd84aaa239d62f40aa4bf5f3159bf7a300d7#diff-30a3dbf7d783cf329b5fb28a8b14332eR110]
in {{ThreadAwareSecurityManager.java}} or we'll end up with the same problem
we had before.
2) In your
[StartupCheck|https://github.com/eugenefedoto/cassandra/commit/5957dd84aaa239d62f40aa4bf5f3159bf7a300d7#diff-a5df240149285ae528cdd3c41aa59360R419]
, the second log line (on L419) isn't necessary.
[~snazy] - Eugene is a new contributor, I've talked him through how to
contribute offline via email, and probably shaped his approach (notably, the
{{instanceof}} check from Ed's patch isn't sufficient, because if logback has
been removed from the classpath, we'll throw a {{NoClassDefFoundError}}
instead). Given that, do you want to review?
was (Author: jjirsa):
[~eugenefedoto] - two quick notes
1) In all three versions of your patch, we can't
[throw|https://github.com/eugenefedoto/cassandra/commit/5957dd84aaa239d62f40aa4bf5f3159bf7a300d7#diff-30a3dbf7d783cf329b5fb28a8b14332eR110]
in {{ThreadAwareSecurityManager.java}} or we'll end up with the same problem
we had before.
2) In your
[StartupCheck|https://github.com/eugenefedoto/cassandra/commit/5957dd84aaa239d62f40aa4bf5f3159bf7a300d7#diff-a5df240149285ae528cdd3c41aa59360R419]
, the second log line (on L419) isn't necessary.
[~snazy] - Eugene is a new contributor, I've talked him through how to
contribute offline via email, and probably shaped his approach. Given that, do
you want to review?
> 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
>Assignee: Eugene Fedotov
>Priority: Minor
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[
https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15954044#comment-15954044
]
Edward Capriolo edited comment on CASSANDRA-13396 at 4/3/17 7:31 PM:
-
{quote}
The project has always allowed ninja fixing minor (especially non-code) things.
Comments here are a net positive. There's no reason to fight about adding
comments after the fact.
{quote}
No. It is important. The -1 er is using his technical insight as a
justification for his -1. The incomplete comment shows how much time he really
spent working on the given code. No tests, no argument checking, and a half
done comment.
was (Author: appodictic):
{quote}
The project has always allowed ninja fixing minor (especially non-code) things.
Comments here are a net positive. There's no reason to fight about adding
comments after the fact.
{quote}
No. It is important. The -1 er is using his technical insight as a
justification for his -1. The incomplete comment shows how much time he really
spent working on the given code.
> 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)
[jira] [Comment Edited] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953973#comment-15953973 ] Edward Capriolo edited comment on CASSANDRA-13396 at 4/3/17 6:40 PM: - A true cassandra special. A patch with a dubious ClassCastException and a half finished comment passed a review, and now the next person who touches the code needs to "sufficiently test" to earn the "officially supported" designation only granted to committers that make untrue statements like "We do not support embedding C* in a container " and ninja fix stuff. was (Author: appodictic): A true cassandra special. A patch with a dubious ClassCastException and a half finished comment passed a review, and now the next person who touches the code needs to "sufficiently test" to earn the "officially supported" designation only granted to committers that make statements like "We do not support embedding C* in a container " and ninja fix stuff. > 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)
[jira] [Comment Edited] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953853#comment-15953853 ] Edward Capriolo edited comment on CASSANDRA-13396 at 4/3/17 5:19 PM: - 1) ninja fix How does meritocracy work when we spend globs of time striking down patches, while simultaneously 'ninja fixing' stuff? Go make a patch and get it reviewed like everyone else. 2) Agreed. 3) What a backwards argument. The "critical past bugs" sited in CASSANDRA-12535 where caused by the person attempting to drop the -1 on this patch. This directly translates to "No one can edit the buggy code I introduced because THEY might make bugs." Consider throwing a GetOffMyLawn exception https://github.com/apache/cassandra/commit/8f15eb1b717548816a9ee8314269d4d1e2ee7084 was (Author: appodictic): 1) ninja fix How does meritocracy work when we spend globs of time striking down patches, while simultaneously 'ninja fixing' stuff? Go make a patch and get it reviewed like everyone else. 2) Agreed. 3) What a backwards argument. The "critical past bugs" sited in CASSANDRA-12535 where caused by the person attempting to drop the -1 on this patch. This directly translates to "No one can edit the buggy code I introduced because THEY might make bugs." https://github.com/apache/cassandra/commit/8f15eb1b717548816a9ee8314269d4d1e2ee7084 > 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)
[jira] [Comment Edited] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[
https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953520#comment-15953520
]
Edward Capriolo edited comment on CASSANDRA-13396 at 4/3/17 2:48 PM:
-
{quote}
We can as well state something like "Using any logging library not shipped with
Cassandra is NOT supported. Use at your own risk.". If that is the consensus of
this discussion.
{quote}
-1 The point of this Jira is not to create some new policy to avoid committing
things. Fake blockers like 'this might cause a bug in the future' are not a
valid technical reason to reject something. If that is the case shutdown all
development on everything. I appreciate the attempt to compromise, but this is
not the right direction. "Not supported" puts this in a trigger like situation.
It will create a policy that will stop active research. Anyone will be free to
reject further development using the "not supported" argument regardless of how
baseless it is.
was (Author: appodictic):
{quote}
We can as well state something like "Using any logging library not shipped with
Cassandra is NOT supported. Use at your own risk.". If that is the consensus of
this discussion.
{quote}
-1 The point of this Jira is not to create some new policy to avoid committing
things. Fake blockers like 'this might cause a bug in the future' are not a
valid technical reason to reject something. If that is the case shutdown all
development on everything. I appreciate the attempt to compromise, but this is
not the right direction. "Not supported" puts this in a trigger like situation.
It will create a policy that stop active research. Anyone will be free to
reject further development using the "not supported" argument regardless of how
baseless it 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)
[jira] [Comment Edited] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[
https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953520#comment-15953520
]
Edward Capriolo edited comment on CASSANDRA-13396 at 4/3/17 2:47 PM:
-
{quote}
We can as well state something like "Using any logging library not shipped with
Cassandra is NOT supported. Use at your own risk.". If that is the consensus of
this discussion.
{quote}
-1 The point of this Jira is not to create some new policy to avoid committing
things. Fake blockers like 'this might cause a bug in the future' are not a
valid technical reason to reject something. If that is the case shutdown all
development on everything. I appreciate the attempt to compromise, but this is
not the right direction. "Not supported" puts this in a trigger like situation.
It will create a policy that stop active research. Anyone will be free to
reject further development using the "not supported" argument regardless of how
baseless it is.
was (Author: appodictic):
{quote}
We can as well state something like "Using any logging library not shipped with
Cassandra is NOT supported. Use at your own risk.". If that is the consensus of
this discussion.
{quote}
-1 The point of this Jira is not to create some new policy to avoid committing
things. Fake blockers like 'this might cause a bug in the future' are not a
valid technical reason to reject something. If that is the case shutdown all
development on everything. I appreciate the attempt to compromise, but this is
not the right direction. "Not supported" puts this in a trigger like situation,
it will create a policy that stop active research. Anyone will be free to
reject further development using the "not supported" argument regardless of how
baseless it 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)
[jira] [Comment Edited] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[
https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953520#comment-15953520
]
Edward Capriolo edited comment on CASSANDRA-13396 at 4/3/17 2:46 PM:
-
{quote}
We can as well state something like "Using any logging library not shipped with
Cassandra is NOT supported. Use at your own risk.". If that is the consensus of
this discussion.
{quote}
-1 The point of this Jira is not to create some new policy to avoid committing
things. Fake blockers like 'this might cause a bug in the future' are not a
valid technical reason to reject something. If that is the case shutdown all
development on everything. I appreciate the attempt to compromise, but this is
not the right direction. "Not supported" puts this in a trigger like situation,
it will create a policy that stop active research. Anyone will be free to
reject further development using the "not supported" argument regardless of how
baseless it is.
was (Author: appodictic):
{quote}
We can as well state something like "Using any logging library not shipped with
Cassandra is NOT supported. Use at your own risk.". If that is the consensus of
this discussion.
{quote}
-1 The point of this Jira is not to create some new policy to avoid committing
things. Fake blockers like 'this might cause a bug in the future' are not a
valid technical reason to reject something. If that is the case shutdown all
development on everything
> 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)
[jira] [Comment Edited] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[
https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953520#comment-15953520
]
Edward Capriolo edited comment on CASSANDRA-13396 at 4/3/17 2:11 PM:
-
{quote}
We can as well state something like "Using any logging library not shipped with
Cassandra is NOT supported. Use at your own risk.". If that is the consensus of
this discussion.
{quote}
-1 The point of this Jira is not to create some new policy to avoid committing
things. Fake blockers like 'this might cause a bug in the future' are not a
valid technical reason to reject something. If that is the case shutdown all
development on everything
was (Author: appodictic):
{quote}
We can as well state something like "Using any logging library not shipped with
Cassandra is NOT supported. Use at your own risk.". If that is the consensus of
this discussion.
{quote}
-1 The point of this Jira is not to create some new policy to avoid committing
things. Fake blockers like 'this might cause a bug in the future' are not a
valid technical reason not to do anything. If that is the case shutdown all
development on everything
> 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)
[jira] [Comment Edited] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[
https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953520#comment-15953520
]
Edward Capriolo edited comment on CASSANDRA-13396 at 4/3/17 2:01 PM:
-
{quote}
We can as well state something like "Using any logging library not shipped with
Cassandra is NOT supported. Use at your own risk.". If that is the consensus of
this discussion.
{quote}
-1 The point of this Jira is not to create some new policy to avoid committing
things. Fake blockers like 'this might cause a bug in the future' are not a
valid technical reason not to do anything. If that is the case shutdown all
development on everything
was (Author: appodictic):
{quote}
We can as well state something like "Using any logging library not shipped with
Cassandra is NOT supported. Use at your own risk.". If that is the consensus of
this discussion.
{quote}
-1 The point of this Jira is not to create some new policy to avoid committing
things you do not want to commit.
> 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)
[jira] [Comment Edited] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953111#comment-15953111 ] Benjamin Lerer edited comment on CASSANDRA-13396 at 4/3/17 8:10 AM: The problem that I see with this ticket is the following: "Once we agree to allow people to use the loggers that they wish we somehow become responsible for the bugs that can show up". As [~snazy] point it up, some of those issues might be non trivial to figure out. Simply because when someone will open a bug he might not mention that he changed the logging library and we might end up wasting a lot of time to reproduce the problem. Due to that, I tend to be in favor of Robert suggestion of not supporting it (years spend debugging crappy issues have made me somehow paranoiac). Now, I think it also make sense to allow people to use another logging library as long as they know that we do not fully support it. My proposal woud be to log a warning at startup saying that the logging library that they use is not supported. was (Author: blerer): The problem that I see with this ticket is the following: "Once we agree to allow people to use the loggers that they wish we somehow become responsible for the bugs that can show up". As [~snazy] point it up, some of those issues might be non trivial to figure out. Simply because when someone will open a bug he might not mention that he changed the logging library and we might end up wasting a lot of time to reproduce the problem. Due to that I tend to be in favor of Robert approach (years spend debugging crappy issues have made me somehow paranoiac). Now, I think it also make sense to allow people to use another logging library as long as they know that we do not fully support it. My proposal woud be to log a warning at startup saying that the logging library that they use is not supported. > 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)
[jira] [Comment Edited] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[
https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15951215#comment-15951215
]
Edward Capriolo edited comment on CASSANDRA-13396 at 3/31/17 4:27 PM:
--
{quote}
people would complain that C* is slow but don't realize it's in this case
because of that change.
{quote}
First, its an obvious bug. The entire point of plug-gable logging
implementations is so that you can replace them.
Second, the only person being actually affected would be Anton, because
effective no one else is changing logging implementations so no one else is
hitting that block.
For Anton (and anyone else) they would have to manually change the files in the
lib folder and the configuration. So nothing is 'hidden' to him. He/They make a
change and they can report if there actually is a performance issue.
Because they can "scratch their itch" of running Cassandra in a container they
might find new problems or they might make new opportunities. For example, they
may find that some other implementation is actually better or faster.
If anyone was actually trying to convince me that this bug is intentional,
(which is almost laughable). The proper practice would be:
{code}
if (!logger instanceof XYZ){
throw new IllegalArgumentException("we only support XYZ for reasons ABC");
}
{code}
But instead we are attempting to pretend the opposite, that the bug is
intentional and the correct thing to do is throw a ClassCastException. Which is
a joke.
was (Author: appodictic):
{quote}
people would complain that C* is slow but don't realize it's in this case
because of that change.
{quote}
First, its an obvious bug. The entire point of plug-gable logging
implementations is so that you can replace them.
Second, the only person being actually affected would be Anton, because
effective no one else is changing logging implementations so no one else is
hitting that block.
For Anton (and anyone else) they would have to manually change the files in the
lib folder and the configuration. So nothing is 'hidden' to him. He/They make a
chance and they can report if there actually is a performance issue.
Because they can "scratch their itch" of running Cassandra in a container they
might find new problems or they might make new opportunities. For example, they
may find that some other implementation is actually better or faster.
If anyone was actually trying to convince me that this bug is intentional,
(which is almost laughable). The proper practice would be:
{code}
if (!logger instanceof XYZ){
throw new IllegalArgumentException("we only support XYZ for reasons ABC");
}
{code}
But instead we are attempting to pretend the opposite, that the bug is
intentional and the correct thing to do is throw a ClassCastException. Which is
a joke.
> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
>
>
> Key: CASSANDRA-13396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
> Project: Cassandra
> Issue Type: Wish
>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)
[jira] [Comment Edited] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[
https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15951215#comment-15951215
]
Edward Capriolo edited comment on CASSANDRA-13396 at 3/31/17 4:26 PM:
--
{quote}
people would complain that C* is slow but don't realize it's in this case
because of that change.
{quote}
First, its an obvious bug. The entire point of plug-gable logging
implementations is so that you can replace them.
Second, the only person being actually affected would be Anton, because
effective no one else is changing logging implementations so no one else is
hitting that block.
For Anton (and anyone else) they would have to manually change the files in the
lib folder and the configuration. So nothing is 'hidden' to him. He/They make a
chance and they can report if there actually is a performance issue.
Because they can "scratch their itch" of running Cassandra in a container they
might find new problems or they might make new opportunities. For example, they
may find that some other implementation is actually better or faster.
If anyone was actually trying to convince me that this bug is intentional,
(which is almost laughable). The proper practice would be:
{code}
if (!logger instanceof XYZ){
throw new IllegalArgumentException("we only support XYZ for reasons ABC");
}
{code}
But instead we are attempting to pretend the opposite, that the bug is
intentional and the correct thing to do is throw a ClassCastException. Which is
a joke.
was (Author: appodictic):
{quote}
people would complain that C* is slow but don't realize it's in this case
because of that change.
{quote}
First, its an obvious bug. The entire point of plug-gable logging
implementations is so that you can replace them.
Second, the only person being actually affected would be Anton, because
effective no one else is changing logging implementations so no one else is
hitting that block.
For Anton (and anyone else) they would have to manually change the files in the
lib folder and the configuration. So nothing is 'hidden' to him. He/They make a
chance and they can report if there actually is a performance issue.
Because they can "scratch their itch" of running Cassandra in a container they
might find new problems or they might make new opportunities. For example, they
may find that some other implementation is actually better or faster.
If anyone was actually trying to convince be that this bug is intentional,
(which is almost laughable). The proper practice would
{code}
if (!logger instanceof XYZ){
throw new IllegalArgumentException("we only support XYZ for reasons ABC");
}
{code}
But instead we are attempting to pretend the opposite that the bug is
intentional and the correct thing to do is throw a ClassCastException.
> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
>
>
> Key: CASSANDRA-13396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
> Project: Cassandra
> Issue Type: Wish
>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)
[jira] [Comment Edited] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15951110#comment-15951110 ] Edward Capriolo edited comment on CASSANDRA-13396 at 3/31/17 3:23 PM: -- So strange: No such statement about supporting containers seems to exist. [edward@jackintosh cassandra]$ find . -type f | xargs grep containers ./src/java/org/apache/cassandra/db/ColumnFamilyStore.java: * thread safety. All we do is wipe the sstable containers clean, while leaving the actual ./src/java/org/apache/cassandra/index/sasi/disk/OnDiskIndexBuilder.java: private final List containers = new ArrayList<>(); ./src/java/org/apache/cassandra/index/sasi/disk/OnDiskIndexBuilder.java: containers.add(keys); ./src/java/org/apache/cassandra/index/sasi/disk/OnDiskIndexBuilder.java: if (containers.size() > 0) ./src/java/org/apache/cassandra/index/sasi/disk/OnDiskIndexBuilder.java: for (TokenTreeBuilder tokens : containers) ./src/java/org/apache/cassandra/index/sasi/disk/OnDiskIndexBuilder.java: containers.clear(); ./conf/jvm.options:# This helps prevent soft faults in containers and makes Binary file ./build/classes/main/org/apache/cassandra/index/sasi/disk/OnDiskIndexBuilder$MutableDataBlock.class matches [edward@jackintosh cassandra]$ find . -type f | xargs grep Containers Its almost as if people just make up things, and then when you corner them on their position being false they just pivot and make up a new reason not to like the idea. was (Author: appodictic): So strange: No such statement about supporting containers seems to exist. [edward@jackintosh cassandra]$ find . -type f | xargs grep containers ./src/java/org/apache/cassandra/db/ColumnFamilyStore.java: * thread safety. All we do is wipe the sstable containers clean, while leaving the actual ./src/java/org/apache/cassandra/index/sasi/disk/OnDiskIndexBuilder.java: private final List containers = new ArrayList<>(); ./src/java/org/apache/cassandra/index/sasi/disk/OnDiskIndexBuilder.java: containers.add(keys); ./src/java/org/apache/cassandra/index/sasi/disk/OnDiskIndexBuilder.java: if (containers.size() > 0) ./src/java/org/apache/cassandra/index/sasi/disk/OnDiskIndexBuilder.java: for (TokenTreeBuilder tokens : containers) ./src/java/org/apache/cassandra/index/sasi/disk/OnDiskIndexBuilder.java: containers.clear(); ./conf/jvm.options:# This helps prevent soft faults in containers and makes Binary file ./build/classes/main/org/apache/cassandra/index/sasi/disk/OnDiskIndexBuilder$MutableDataBlock.class matches [edward@jackintosh cassandra]$ find . -type f | xargs grep Containers > Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager > > > Key: CASSANDRA-13396 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13396 > Project: Cassandra > Issue Type: Wish >Reporter: Edward Capriolo >Assignee: 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)
[jira] [Comment Edited] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15951053#comment-15951053 ] Anton Passiouk edited comment on CASSANDRA-13396 at 3/31/17 2:56 PM: - @[~snazy]: OK but what if the cassandra daemon is not embedded anywhere but is simply running with a classpath containing several slf4j bindings? It will still crash, right? @[~appodictic]: please don't over-react (and don't hijack my question), it's an open discussion ;-) was (Author: apassiou): @[~snazy]: OK but what if the cassandra daemon is not embedded anywhere but is simply running with a classpath containing several slf4j bindings? It will still crash, right? @[~appodictic]: please don't over-react, it's an open discussion ;-) > Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager > > > Key: CASSANDRA-13396 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13396 > Project: Cassandra > Issue Type: Wish >Reporter: Edward Capriolo >Assignee: 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)
[jira] [Comment Edited] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15951053#comment-15951053 ] Anton Passiouk edited comment on CASSANDRA-13396 at 3/31/17 2:55 PM: - @[~snazy]: OK but what if the cassandra daemon is not embedded anywhere but is simply running with a classpath containing several slf4j bindings? It will still crash, right? @[~appodictic]: please don't over-react, it's an open discussion ;-) was (Author: apassiou): OK but what if the cassandra daemon is not embedded anywhere but is simply running with a classpath containing several slf4j bindings? It will still crash, right? > Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager > > > Key: CASSANDRA-13396 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13396 > Project: Cassandra > Issue Type: Wish >Reporter: Edward Capriolo >Assignee: 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)
[jira] [Comment Edited] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15951052#comment-15951052 ] Edward Capriolo edited comment on CASSANDRA-13396 at 3/31/17 2:51 PM: -- How come everyone in Cassandra's first reaction is to -1 everything? The entire model of apache is "I have an itch to scratch". This person WANTS to run Cassandra in a container it is an "itch". The immediate opposition position should not be "BUT DON'T SCRATCH THAT ITCH", because I say so. was (Author: appodictic): How come everyone in Cassandra's first reaction is to -1 everything? The entire model of apache is "I have an itch to scratch". This person WANTS to run Cassandra in a container it is an "itch". The position should not just instantly be "BUT DON'T SCRATCH THAT ITCH". > Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager > > > Key: CASSANDRA-13396 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13396 > Project: Cassandra > Issue Type: Wish >Reporter: Edward Capriolo >Assignee: 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)
