[jira] [Updated] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
[ https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19632: -- Status: Needs Committer (was: Patch Available) > wrap tracing logs in isTraceEnabled across the codebase > --- > > Key: CASSANDRA-19632 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19632 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > Our usage of logger.isTraceEnabled across the codebase is inconsistent. This > would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade] > suggested. > We should fix this at least in trunk and 5.0 (not critical though) and > probably come up with a checkstyle rule to prevent not calling isTraceEnabled > while logging with TRACE level. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
[
https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848940#comment-17848940
]
Stefan Miklosovic edited comment on CASSANDRA-19632 at 5/23/24 12:59 PM:
-
I went through all logger.trace in the production code and I modified only 59
files instead of 127 in the first PR.
[https://github.com/apache/cassandra/pull/3329]
The perception I got by going through all of that is that people were already
following the rule of "if it has more than 2 arguments then wrap it in
logger.isTraceEnabled" so I went by that logic as well everywhere where it was
not done like that.
There were also inconsistent usages of logger.trace() with 0 / 1 / 2 arguments.
Sometimes it was wrapped in isTraceEnabled, sometimes it was not, without any
apparent reason. I think that for simple cases it is not necessary to wrap it,
we have majority of cases like that in the code base (not wrapped).
I have also fixed the cases where string concatenation was used and similar.
Not all people also seem to understand that when it is logged like this:
{code:java}
logger.trace("abc {}", object);
{code}
then the actual object.toString() is evaluated _after_ we are absolutely sure
we go to indeed log. I do not think that this is necessary, even "object" is
some "heavyweight" when it comes to toString because it is not called
prematurely anyway.
{code:java}
if (logger.isTraceEnabled())
logger.trace("abc {}", object);
{code}
as per [https://www.slf4j.org/faq.html#string_contents]
{quote}The logging system will invoke complexObject.toString() method only
after it has ascertained that the log statement was enabled. Otherwise, the
cost of complexObject.toString() conversion will be advantageously avoided.
{quote}
was (Author: smiklosovic):
I went through all logger.trace in the production code and I modified only 59
files instead of 127 in the first one.
https://github.com/apache/cassandra/pull/3329
The perception I got by going through all of that is that people were already
following the rule of "it it has more than 2 arguments then wrap it in
logger.isTraceEnabled" so I went by that logic as well everywhere where it was
not done like that.
There were also inconsistent usages of logger.trace() with 0 / 1 / 2 arguments.
Sometimes it was wrapped in isTraceEnabled, sometimes it was not, without any
apparent reason. I think that for simple cases it is not necessary to wrap it,
we have majority of cases like that in the code base (not wrapped).
I have also fixed the cases where string concatenation was used and similar.
Not all people also seem to understand that when it is logged like this:
{code}
logger.trace("abc {}", object);
{code}
then the actual object.toString() is evaluated _after_ we are absolutely sure
we go to indeed log. I do not think that this is necessary, even "object" is
some "heavyweight" when it comes to toString because it is not called
prematurely anyway.
{code}
if (logger.isTraceEnabled())
logger.trace("abc {}", object);
{code}
as per https://www.slf4j.org/faq.html#string_contents
{quote}
The logging system will invoke complexObject.toString() method only after it
has ascertained that the log statement was enabled. Otherwise, the cost of
complexObject.toString() conversion will be advantageously avoided.
{quote}
> wrap tracing logs in isTraceEnabled across the codebase
> ---
>
> Key: CASSANDRA-19632
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19632
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Our usage of logger.isTraceEnabled across the codebase is inconsistent. This
> would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade]
> suggested.
> We should fix this at least in trunk and 5.0 (not critical though) and
> probably come up with a checkstyle rule to prevent not calling isTraceEnabled
> while logging with TRACE level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
[
https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848940#comment-17848940
]
Stefan Miklosovic edited comment on CASSANDRA-19632 at 5/23/24 12:57 PM:
-
I went through all logger.trace in the production code and I modified only 59
files instead of 127 in the first one.
https://github.com/apache/cassandra/pull/3329
The perception I got by going through all of that is that people were already
following the rule of "it it has more than 2 arguments then wrap it in
logger.isTraceEnabled" so I went by that logic as well everywhere where it was
not done like that.
There were also inconsistent usages of logger.trace() with 0 / 1 / 2 arguments.
Sometimes it was wrapped in isTraceEnabled, sometimes it was not, without any
apparent reason. I think that for simple cases it is not necessary to wrap it,
we have majority of cases like that in the code base (not wrapped).
I have also fixed the cases where string concatenation was used and similar.
Not all people also seem to understand that when it is logged like this:
{code}
logger.trace("abc {}", object);
{code}
then the actual object.toString() is evaluated _after_ we are absolutely sure
we go to indeed log. I do not think that this is necessary, even "object" is
some "heavyweight" when it comes to toString because it is not called
prematurely anyway.
{code}
if (logger.isTraceEnabled())
logger.trace("abc {}", object);
{code}
as per https://www.slf4j.org/faq.html#string_contents
{quote}
The logging system will invoke complexObject.toString() method only after it
has ascertained that the log statement was enabled. Otherwise, the cost of
complexObject.toString() conversion will be advantageously avoided.
{quote}
was (Author: smiklosovic):
I went through all logger.trace in the production code and I modified only 59
files instead of 127 in the first one.
https://github.com/apache/cassandra/pull/3329
The perception I got by going through all of that is that people were already
following the rule of "it it has more than 2 arguments then wrap it in
logger.isTraceEnabled" so I went by that logic as well everywhere where it was
not done like that.
There were also inconsistent usages of logger.trace() with 0 / 1 / 2 arguments.
Sometimes it was wrapped in isTraceEnabled, sometimes it was not, without any
apparent reason. I think that for simple cases it is not necessary to wrap it,
we have majority of cases like that in the code base (not wrapped).
I have also fixed the cases where string concatenation was used and similar.
Not all people also seem to understand that when it is logged like this:
{code}
logger.trace("abc {}", object);
{code}
then the actual object.toString() is evaluated _after_ we are absolutely sure
we go to indeed log. I do not think that this is necessary, even "object" is
some "heavyweight" when it comes to toString because it is not called
prematurely anyway.
{code}
if (logger.isTraceEnabled())
logger.trace("abc {}", object);
{code}
> wrap tracing logs in isTraceEnabled across the codebase
> ---
>
> Key: CASSANDRA-19632
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19632
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Our usage of logger.isTraceEnabled across the codebase is inconsistent. This
> would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade]
> suggested.
> We should fix this at least in trunk and 5.0 (not critical though) and
> probably come up with a checkstyle rule to prevent not calling isTraceEnabled
> while logging with TRACE level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
[
https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848940#comment-17848940
]
Stefan Miklosovic edited comment on CASSANDRA-19632 at 5/23/24 12:55 PM:
-
I went through all logger.trace in the production code and I modified only 59
files instead of 127 in the first one.
https://github.com/apache/cassandra/pull/3329
The perception I got by going through all of that is that people were already
following the rule of "it it has more than 2 arguments then wrap it in
logger.isTraceEnabled" so I went by that logic as well everywhere where it was
not done like that.
There were also inconsistent usages of logger.trace() with 0 / 1 / 2 arguments.
Sometimes it was wrapped in isTraceEnabled, sometimes it was not, without any
apparent reason. I think that for simple cases it is not necessary to wrap it,
we have majority of cases like that in the code base (not wrapped).
I have also fixed the cases where string concatenation was used and similar.
Not all people also dont seem to understand that when it is logger like this:
{code}
logger.trace("abc {}", object);
{code}
then the actual object.toString() is evaluated _after_ we are absolutely sure
we go to indeed log. I do not think that this is necessary, even "object" is
some "heavyweight" when it comes to toString because it is not called
prematurely anyway.
{code}
if (logger.isTraceEnabled())
logger.trace("abc {}", object);
{code}
was (Author: smiklosovic):
I went through all logger.trace in the production code and I modified only 59
files instead of 127 in the first one.
https://github.com/apache/cassandra/pull/3329
The perception I got by going through all of that is that people were already
following the rule of "it it has more than 2 arguments then wrap it in
logger.isTraceEnabled" so I went by that logic as well everywhere where it was
not done like that.
There were also inconsistent usages of logger.trace() with 0 / 1 / 2 arguments.
Sometimes it was wrapped in isTraceEnabled, sometimes it was not, without any
apparent reason. I think that for simple cases it is not necessary to wrap it,
we have majority of cases like that in the code base (not wrapped).
I have also fixed the cases where string concatenation was used and similar.
> wrap tracing logs in isTraceEnabled across the codebase
> ---
>
> Key: CASSANDRA-19632
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19632
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Our usage of logger.isTraceEnabled across the codebase is inconsistent. This
> would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade]
> suggested.
> We should fix this at least in trunk and 5.0 (not critical though) and
> probably come up with a checkstyle rule to prevent not calling isTraceEnabled
> while logging with TRACE level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
[
https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848940#comment-17848940
]
Stefan Miklosovic edited comment on CASSANDRA-19632 at 5/23/24 12:55 PM:
-
I went through all logger.trace in the production code and I modified only 59
files instead of 127 in the first one.
https://github.com/apache/cassandra/pull/3329
The perception I got by going through all of that is that people were already
following the rule of "it it has more than 2 arguments then wrap it in
logger.isTraceEnabled" so I went by that logic as well everywhere where it was
not done like that.
There were also inconsistent usages of logger.trace() with 0 / 1 / 2 arguments.
Sometimes it was wrapped in isTraceEnabled, sometimes it was not, without any
apparent reason. I think that for simple cases it is not necessary to wrap it,
we have majority of cases like that in the code base (not wrapped).
I have also fixed the cases where string concatenation was used and similar.
Not all people also seem to understand that when it is logged like this:
{code}
logger.trace("abc {}", object);
{code}
then the actual object.toString() is evaluated _after_ we are absolutely sure
we go to indeed log. I do not think that this is necessary, even "object" is
some "heavyweight" when it comes to toString because it is not called
prematurely anyway.
{code}
if (logger.isTraceEnabled())
logger.trace("abc {}", object);
{code}
was (Author: smiklosovic):
I went through all logger.trace in the production code and I modified only 59
files instead of 127 in the first one.
https://github.com/apache/cassandra/pull/3329
The perception I got by going through all of that is that people were already
following the rule of "it it has more than 2 arguments then wrap it in
logger.isTraceEnabled" so I went by that logic as well everywhere where it was
not done like that.
There were also inconsistent usages of logger.trace() with 0 / 1 / 2 arguments.
Sometimes it was wrapped in isTraceEnabled, sometimes it was not, without any
apparent reason. I think that for simple cases it is not necessary to wrap it,
we have majority of cases like that in the code base (not wrapped).
I have also fixed the cases where string concatenation was used and similar.
Not all people also seem to understand that when it is logger like this:
{code}
logger.trace("abc {}", object);
{code}
then the actual object.toString() is evaluated _after_ we are absolutely sure
we go to indeed log. I do not think that this is necessary, even "object" is
some "heavyweight" when it comes to toString because it is not called
prematurely anyway.
{code}
if (logger.isTraceEnabled())
logger.trace("abc {}", object);
{code}
> wrap tracing logs in isTraceEnabled across the codebase
> ---
>
> Key: CASSANDRA-19632
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19632
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Our usage of logger.isTraceEnabled across the codebase is inconsistent. This
> would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade]
> suggested.
> We should fix this at least in trunk and 5.0 (not critical though) and
> probably come up with a checkstyle rule to prevent not calling isTraceEnabled
> while logging with TRACE level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
[
https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848940#comment-17848940
]
Stefan Miklosovic edited comment on CASSANDRA-19632 at 5/23/24 12:55 PM:
-
I went through all logger.trace in the production code and I modified only 59
files instead of 127 in the first one.
https://github.com/apache/cassandra/pull/3329
The perception I got by going through all of that is that people were already
following the rule of "it it has more than 2 arguments then wrap it in
logger.isTraceEnabled" so I went by that logic as well everywhere where it was
not done like that.
There were also inconsistent usages of logger.trace() with 0 / 1 / 2 arguments.
Sometimes it was wrapped in isTraceEnabled, sometimes it was not, without any
apparent reason. I think that for simple cases it is not necessary to wrap it,
we have majority of cases like that in the code base (not wrapped).
I have also fixed the cases where string concatenation was used and similar.
Not all people also seem to understand that when it is logger like this:
{code}
logger.trace("abc {}", object);
{code}
then the actual object.toString() is evaluated _after_ we are absolutely sure
we go to indeed log. I do not think that this is necessary, even "object" is
some "heavyweight" when it comes to toString because it is not called
prematurely anyway.
{code}
if (logger.isTraceEnabled())
logger.trace("abc {}", object);
{code}
was (Author: smiklosovic):
I went through all logger.trace in the production code and I modified only 59
files instead of 127 in the first one.
https://github.com/apache/cassandra/pull/3329
The perception I got by going through all of that is that people were already
following the rule of "it it has more than 2 arguments then wrap it in
logger.isTraceEnabled" so I went by that logic as well everywhere where it was
not done like that.
There were also inconsistent usages of logger.trace() with 0 / 1 / 2 arguments.
Sometimes it was wrapped in isTraceEnabled, sometimes it was not, without any
apparent reason. I think that for simple cases it is not necessary to wrap it,
we have majority of cases like that in the code base (not wrapped).
I have also fixed the cases where string concatenation was used and similar.
Not all people also dont seem to understand that when it is logger like this:
{code}
logger.trace("abc {}", object);
{code}
then the actual object.toString() is evaluated _after_ we are absolutely sure
we go to indeed log. I do not think that this is necessary, even "object" is
some "heavyweight" when it comes to toString because it is not called
prematurely anyway.
{code}
if (logger.isTraceEnabled())
logger.trace("abc {}", object);
{code}
> wrap tracing logs in isTraceEnabled across the codebase
> ---
>
> Key: CASSANDRA-19632
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19632
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Our usage of logger.isTraceEnabled across the codebase is inconsistent. This
> would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade]
> suggested.
> We should fix this at least in trunk and 5.0 (not critical though) and
> probably come up with a checkstyle rule to prevent not calling isTraceEnabled
> while logging with TRACE level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
[ https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848940#comment-17848940 ] Stefan Miklosovic commented on CASSANDRA-19632: --- I went through all logger.trace in the production code and I modified only 59 files instead of 127 in the first one. https://github.com/apache/cassandra/pull/3329 The perception I got by going through all of that is that people were already following the rule of "it it has more than 2 arguments then wrap it in logger.isTraceEnabled" so I went by that logic as well everywhere where it was not done like that. There were also inconsistent usages of logger.trace() with 0 / 1 / 2 arguments. Sometimes it was wrapped in isTraceEnabled, sometimes it was not, without any apparent reason. I think that for simple cases it is not necessary to wrap it, we have majority of cases like that in the code base (not wrapped). I have also fixed the cases where string concatenation was used and similar. > wrap tracing logs in isTraceEnabled across the codebase > --- > > Key: CASSANDRA-19632 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19632 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 20m > Remaining Estimate: 0h > > Our usage of logger.isTraceEnabled across the codebase is inconsistent. This > would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade] > suggested. > We should fix this at least in trunk and 5.0 (not critical though) and > probably come up with a checkstyle rule to prevent not calling isTraceEnabled > while logging with TRACE level. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
[
https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848892#comment-17848892
]
Stefan Miklosovic edited comment on CASSANDRA-19632 at 5/23/24 10:48 AM:
-
I did some research on this and it is quite interesting read.
https://www.slf4j.org/faq.html#logging_performance
If we do this
{code}
logger.trace("abc" + obj + "def");
{code}
there is a performance penalty related to evaluating the argument.
When we do this:
{code}
logger.trace("abc {}", def);
{code}
this will evaluate {} only when we go to log on trace so it will check tracing
just once and it will evaluate {} at most once (if we indeed go to log).
Doing this
{code}
if (logger.isTracingEnabled()) logger.trace("abc" + obj + "def");
{code}
is the least performance-friendly, because it needs to evaluate if we go to log
on trace and if we do, then it will evaluate it for the second time in
logger.trace itself, plus it needs to construct the logging message before
doing so.
Doing this:
{code}
if (logger.isTracingEnabled()) logger.trace("abc {}", def);
{code}
will check if we go to trace at most twice and it will evaluate the placeholder
at most once.
I think that wrapping logger.trace with logger.isTracingEnabled() is necessary
only in case if
1) we do not use placeholders in the logging message, only string
concatenation, which would construct the logging message regardless of logging
or not, because it was not checked yet
2) if the number of placeholder arguments in logger.trace is bigger than 2.
For example, for 2)
{code}
logger.trace("abc {} def {}", obj1, obj2);
{code}
This will be OK. However this:
{code}
logger.trace("abc {} def {} ghi {}", obj1, obj2, obj3);
{code}
this will contain the hidden cost of constructing an object, Object[] ... with
these three parameters. Logging internals will create an object if the number
of placeholders is bigger than 2.
The cost of calling logger.isTracingEnabled is negligable, 1% of the actual
logging of the message but I think it is not necessary, as long as we make sure
that we are not using string concatenation upon message construction and as
long as we are not using more than 2 placeholders.
Also, it is important to check that it does not cost a lot to evaluate the
argument itself, as we hit that case in CASSANDRA-19429, for example
{code}
logger.trace("abc {}", thisIs.Hard.ToResolve())
{code}
Even we use a placeholder, if thisIs.Hard.ToResolve() takes a lot of resources,
that is not good and in that case it is preferable to wrap it in
isTracingEnabled(). There is no silver bullet, I think we need to just go case
by case by the rules I described and change it where it does not comply.
According to the docs, the alternative is also to use lambdas:
{code}
logger.trace("abc {}", () -> thisIs.Hard.ToResolve())
{code}
this will check if we go to log on trace level just once and it will evaluate
the placeholder if we indeed go to do that. I think this is the best solution.
I will try to go over the codebase to see where we are at currently.
EDIT: lambdas were added in SLF4J 2.0.0-alpha1
was (Author: smiklosovic):
I did some research on this and it is quite interesting read.
https://www.slf4j.org/faq.html#logging_performance
If we do this
{code}
logger.trace("abc" + obj + "def");
{code}
there is a performance penalty related to evaluating the argument.
When we do this:
{code}
logger.trace("abc {}", def);
{code}
this will evaluate {} only when we go to log on trace so it will check tracing
just once and it will evaluate {} at most once (if we indeed go to log).
Doing this
{code}
if (logger.isTracingEnabled()) logger.trace("abc" + obj + "def");
{code}
is the least performance-friendly, because it needs to evaluate if we go to log
on trace and if we do, then it will evaluate it for the second time in
logger.trace itself, plus it needs to construct the logging message before
doing so.
Doing this:
{code}
if (logger.isTracingEnabled()) logger.trace("abc {}", def);
{code}
will check if we go to trace at most twice and it will evaluate the placeholder
at most once.
I think that wrapping logger.trace with logger.isTracingEnabled() is necessary
only in case if
1) we do not use placeholders in the logging message, only string
concatenation, which would construct the logging message regardless of logging
or not, because it was not checked yet
2) if the number of placeholder arguments in logger.trace is bigger than 2.
For example, for 2)
{code}
logger.trace("abc {} def {}", obj1, obj2);
{code}
This will be OK. However this:
{code}
logger.trace("abc {} def {} ghi {}", obj1, obj2, obj3);
{code}
this will contain the hidden cost of constructing an object, Object[] ... with
these three parameters. Logging internals will create an object if the number
of placeholders is bigger than 2.
The cost
[jira] [Commented] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
[
https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848892#comment-17848892
]
Stefan Miklosovic commented on CASSANDRA-19632:
---
I did some research on this and it is quite interesting read.
https://www.slf4j.org/faq.html#logging_performance
If we do this
{code}
logger.trace("abc" + obj + "def");
{code}
there is a performance penalty related to evaluating the argument.
When we do this:
{code}
logger.trace("abc {}", def);
{code}
this will evaluate {} only when we go to log on trace so it will check tracing
just once and it will evaluate {} at most once (if we indeed go to log).
Doing this
{code}
if (logger.isTracingEnabled()) logger.trace("abc" + obj + "def");
{code}
is the least performance-friendly, because it needs to evaluate if we go to log
on trace and if we do, then it will evaluate it for the second time in
logger.trace itself, plus it needs to construct the logging message before
doing so.
Doing this:
{code}
if (logger.isTracingEnabled()) logger.trace("abc {}", def);
{code}
will check if we go to trace at most twice and it will evaluate the placeholder
at most once.
I think that wrapping logger.trace with logger.isTracingEnabled() is necessary
only in case if
1) we do not use placeholders in the logging message, only string
concatenation, which would construct the logging message regardless of logging
or not, because it was not checked yet
2) if the number of placeholder arguments in logger.trace is bigger than 2.
For example, for 2)
{code}
logger.trace("abc {} def {}", obj1, obj2);
{code}
This will be OK. However this:
{code}
logger.trace("abc {} def {} ghi {}", obj1, obj2, obj3);
{code}
this will contain the hidden cost of constructing an object, Object[] ... with
these three parameters. Logging internals will create an object if the number
of placeholders is bigger than 2.
The cost of calling logger.isTracingEnabled is negligable, 1% of the actual
logging of the message but I think it is not necessary, as long as we make sure
that we are not using string concatenation upon message construction and as
long as we are not using more than 2 placeholders.
Also, it is important to check that it does not cost a lot to evaluate the
argument itself, as we hit that case in CASSANDRA-19429, for example
{code}
logger.trace("abc {}", thisIs.Hard.ToResolve())
{code}
Even we use a placeholder, if thisIs.Hard.ToResolve() takes a lot of resources,
that is not good and in that case it is preferable to wrap it in
isTracingEnabled(). There is no silver bullet, I think we need to just go case
by case by the rules I described and change it where it does not comply.
According to the docs, the alternative is also to use lambdas:
{code}
logger.trace("abc {}", () -> thisIs.Hard.ToResolve())
{code}
this will check if we go to log on trace level just once and it will evaluate
the placeholder if we indeed go to do that. I think this is the best solution.
I will try to go over the codebase to see where we are at currently.
> wrap tracing logs in isTraceEnabled across the codebase
> ---
>
> Key: CASSANDRA-19632
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19632
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Our usage of logger.isTraceEnabled across the codebase is inconsistent. This
> would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade]
> suggested.
> We should fix this at least in trunk and 5.0 (not critical though) and
> probably come up with a checkstyle rule to prevent not calling isTraceEnabled
> while logging with TRACE level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848712#comment-17848712 ] Stefan Miklosovic commented on CASSANDRA-19556: --- OK, that sounds good. > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
[
https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848637#comment-17848637
]
Stefan Miklosovic commented on CASSANDRA-19632:
---
That will be probably the truth. I might check that. We can revert the cases
when it is logging like this:
{code:java}
if (logger.isTracingEnabled()) logger.trace("a message");
{code}
In these cases, I think it is pretty much an overkill. It is more about not
evaluating the message itself if there are some arguments.
> wrap tracing logs in isTraceEnabled across the codebase
> ---
>
> Key: CASSANDRA-19632
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19632
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Our usage of logger.isTraceEnabled across the codebase is inconsistent. This
> would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade]
> suggested.
> We should fix this at least in trunk and 5.0 (not critical though) and
> probably come up with a checkstyle rule to prevent not calling isTraceEnabled
> while logging with TRACE level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
[ https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19632: -- Test and Documentation Plan: ci Status: Patch Available (was: In Progress) I've created a PR. I have not added a checkstyle rule, it is actually quite tricky to get right and I do not think we can generalize it enough. It might be very specific to the code. > wrap tracing logs in isTraceEnabled across the codebase > --- > > Key: CASSANDRA-19632 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19632 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Our usage of logger.isTraceEnabled across the codebase is inconsistent. This > would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade] > suggested. > We should fix this at least in trunk and 5.0 (not critical though) and > probably come up with a checkstyle rule to prevent not calling isTraceEnabled > while logging with TRACE level. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19593) Transactional Guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-19593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848590#comment-17848590
]
Stefan Miklosovic commented on CASSANDRA-19593:
---
There is minimumReplicationFactor guardrail which looks into
DatabaseDescriptor.getDefaultKeyspaceRF() when validating the value:
{code:java}
public static void validateMinRFThreshold(int warn, int fail)
{
validateMinIntThreshold(warn, fail, "minimum_replication_factor");
if (fail > DatabaseDescriptor.getDefaultKeyspaceRF())
throw new
IllegalArgumentException(format("minimum_replication_factor_fail_threshold to
be set (%d) " +
"cannot be greater than
default_keyspace_rf (%d)",
fail,
DatabaseDescriptor.getDefaultKeyspaceRF()));
} {code}
this is similarly done for maximum_replication_factor.
Obviously, conf.default_keyspace_rf can be different per node, if
misconfigured, so transformation application would not be the same on all nodes
and it might fail on some and not fail on others.
This brings us to more general problem of transactional configuration which
should be done as well. It is questionable if it is desirable to do it as part
of this ticket or not, however, I would like to look into how we could do that
as well.
> Transactional Guardrails
>
>
> Key: CASSANDRA-19593
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19593
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails, Transactional Cluster Metadata
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I think it is time to start to think about this more seriously. TCM is
> getting into pretty nice shape and we might start to investigate how to do
> this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848560#comment-17848560 ] Stefan Miklosovic edited comment on CASSANDRA-19556 at 5/22/24 11:00 AM: - That being said, I am curious if the patch for trunk might go in as is - it is removing alter_table_enabled guardrail. If that is not desirable, then shadowing it is the next option. That means I would need to get alter_table_enabled back. Is everybody OK with this? Otherwise I am all ears how to do this - that was my whole point why I wanted to do it before 5.0.0 is out by removing the old one. Or we just do what Sam suggests, we just remove this feature altogether and replace it by a system property. That will work but it will not work while cluster is up and people need to prevent schema modifications operationally. was (Author: smiklosovic): That being said, I am curious if the patch for trunk might go in as is - it is removing alter_table_enabled guardrail. If that is not desirable, then shadowing it is the next option. That means I would need to get alter_table_enabled back. Is everybody OK with this? Otherwise I am all ears how to do this - that was my whole point why I wanted to do it before 5.0.0 is out by removing the old one. > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848553#comment-17848553 ] Stefan Miklosovic edited comment on CASSANDRA-19556 at 5/22/24 10:49 AM: - OK, I think we can just defer this effort to trunk / 5.1 then. Removing it from 5.0-rc. was (Author: smiklosovic): OK, I think we can just defer this effor to trunk / 5.1 then. Removing it from 5.0-rc. > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19556: -- Fix Version/s: (was: 5.0-rc) > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848553#comment-17848553 ] Stefan Miklosovic commented on CASSANDRA-19556: --- OK, I think we can just defer this effor to trunk / 5.1 then. Removing it from 5.0-rc. > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
[ https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19632: -- Change Category: Code Clarity Complexity: Normal Component/s: Legacy/Core Assignee: Stefan Miklosovic Status: Open (was: Triage Needed) > wrap tracing logs in isTraceEnabled across the codebase > --- > > Key: CASSANDRA-19632 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19632 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > > Our usage of logger.isTraceEnabled across the codebase is inconsistent. This > would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade] > suggested. > We should fix this at least in trunk and 5.0 (not critical though) and > probably come up with a checkstyle rule to prevent not calling isTraceEnabled > while logging with TRACE level. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
[ https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19632: -- Fix Version/s: (was: 5.0.x) > wrap tracing logs in isTraceEnabled across the codebase > --- > > Key: CASSANDRA-19632 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19632 > Project: Cassandra > Issue Type: Improvement >Reporter: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > > Our usage of logger.isTraceEnabled across the codebase is inconsistent. This > would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade] > suggested. > We should fix this at least in trunk and 5.0 (not critical though) and > probably come up with a checkstyle rule to prevent not calling isTraceEnabled > while logging with TRACE level. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19593) Transactional Guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-19593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848171#comment-17848171
]
Stefan Miklosovic edited comment on CASSANDRA-19593 at 5/21/24 11:45 AM:
-
Progress:
I finished all transformations (Flags, Values, Thresholds, Customs) (Custom is
a custom guardrail as per CEP-24). I have also tested ser/de of these
transformations, there are tests for vtables and diffing of transformations as
well.
I have also started to validate the input in vtables before it is committed to
TCM. That means that no invalid configuration (e.g. warn threshold bigger than
fail threshold) will be committed when CQL statement against such vtables is
executed. Validations are done per each logical guardrail category if
applicable.
It is worth to say that from the implementation perspective, Values (related to
values guardrail) are rather special when it comes to CQL.
If we want to have this table
{code:java}
VIRTUAL TABLE system_guardrails.values (
name text PRIMARY KEY,
disallowed frozen>,
ignored frozen>,
warned frozen>
) {code}
when we do this query:
{code:java}
update system_guardrails.values set warned = {'QUORUM'}, disallowed =
{'EACH_QUORUM'} WHERE name = 'read_consistency_levels'; {code}
the way how it works until now is that each value for respective column will
come to
AbstractMutableVirtualTable#applyColumnUpdate. But, think about that, if we
have two columns modified, as in the above example, that would translate to two
separate commits into TCM, just because mutable vtable iterates over such
columns.
I do not think this is desirable, there should be one commit per query,
basically. So the transformation might contain more than one column.
In order to do that, I had to override "apply" method in
AbstractMutableVirtualTable and I had to remove "final" modifier. This was
already discussed with [~blerer] that it might be possible to remove that in
order to accommodate this kind of situations.
Also, I am making sure that I am not committing something which has not
changed. E.g. when I execute above query twice, it will be actually committed
just once, because for the second time, when diffing it, there is no
difference, hence no commit is necessary. This was quite tricky to get right,
especially for values, because I wanted to model the situation when we are
removing the value by setting it to null, like this:
{code:java}
update system_guardrails.values set warned = null, disallowed = {} WHERE name =
'read_consistency_levels'; {code}
"null" and "empty" are two different operations in terms of mutable vtable. If
it is set to null, it is looked at as if we are going to delete but if it is an
empty set, it is a regular update. This was tricky to get right too but I think
I am there.
was (Author: smiklosovic):
Progress:
I finished all transformations (Flags, Values, Thresholds, Customs) (Custom is
a custom guardrail as per CEP-24). I have also tested ser/de of these
transformations, there are tests for vtables and diffing of transformations as
well.
I have also started to validate the input in vtables before it is committed to
TCM. That means that no invalid configuration (e.g. warn threshold bigger than
fail threshold) will be committed when CQL statement against such vtables is
executed. Validations are done per each logical guardrail category if
applicable.
> Transactional Guardrails
>
>
> Key: CASSANDRA-19593
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19593
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails, Transactional Cluster Metadata
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I think it is time to start to think about this more seriously. TCM is
> getting into pretty nice shape and we might start to investigate how to do
> this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19593) Transactional Guardrails
[ https://issues.apache.org/jira/browse/CASSANDRA-19593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848171#comment-17848171 ] Stefan Miklosovic commented on CASSANDRA-19593: --- Progress: I finished all transformations (Flags, Values, Thresholds, Customs) (Custom is a custom guardrail as per CEP-24). I have also tested ser/de of these transformations, there are tests for vtables and diffing of transformations as well. I have also started to validate the input in vtables before it is committed to TCM. That means that no invalid configuration (e.g. warn threshold bigger than fail threshold) will be committed when CQL statement against such vtables is executed. Validations are done per each logical guardrail category if applicable. > Transactional Guardrails > > > Key: CASSANDRA-19593 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19593 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails, Transactional Cluster Metadata >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > I think it is time to start to think about this more seriously. TCM is > getting into pretty nice shape and we might start to investigate how to do > this. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19450) Hygiene updates for warnings and pytests
[
https://issues.apache.org/jira/browse/CASSANDRA-19450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848042#comment-17848042
]
Stefan Miklosovic commented on CASSANDRA-19450:
---
[CASSANDRA-19450|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19450]
{noformat}
java17_pre-commit_tests
✓ j17_build4m 27s
✓ j17_cqlshlib_cython_tests7m 57s
✓ j17_cqlshlib_tests7m 7s
✓ j17_dtests 37m 34s
✓ j17_dtests_vnode35m 29s
✓ j17_unit_tests 14m 4s
✓ j17_utests_latest 14m 24s
✓ j17_utests_oa 15m 52s
✕ j17_cqlsh_dtests_py311 7m 11s
cqlsh_tests.test_cqlsh.TestCqlsh test_pycodestyle_compliance
✕ j17_cqlsh_dtests_py311_vnode 7m 15s
cqlsh_tests.test_cqlsh.TestCqlsh test_pycodestyle_compliance
✕ j17_cqlsh_dtests_py387m 10s
cqlsh_tests.test_cqlsh.TestCqlsh test_pycodestyle_compliance
✕ j17_cqlsh_dtests_py38_vnode 7m 26s
cqlsh_tests.test_cqlsh.TestCqlsh test_pycodestyle_compliance
✕ j17_dtests_latest 36m 34s
configuration_test.TestConfiguration test_change_durable_writes
✕ j17_jvm_dtests 21m 45s
✕ j17_jvm_dtests_latest_vnode 21m 35s
junit.framework.TestSuite
org.apache.cassandra.fuzz.harry.integration.model.InJVMTokenAwareExecutorTest
TIMEOUTED
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4315/workflows/8e5e7328-875d-4554-8535-b7c1437bf2ec]
[java17_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4315/workflows/c0eb2ffe-439c-462d-b633-7fd8034c3291]
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4315/workflows/16247a5a-16b0-43a7-8aea-a72853cdcd78]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4315/workflows/b4b06e17-bc75-4341-9416-91424ceda80c]
> Hygiene updates for warnings and pytests
>
>
> Key: CASSANDRA-19450
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19450
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Low
> Fix For: 5.x
>
>
>
> * Update 'Warning' message to write to stderr
> * -Replace TimeoutError Exception with builtin (since Python 3.3)-
> * -Remove re.pattern_type (removed since Python 3.7)-
> * Fix mutable arg [] in read_until()
> * Remove redirect of stderr to stdout in pytest fixture with tty=false;
> Deprecation warnings can otherwise fail unit tests when stdout & stderr
> output is combined.
> * Fix several pycodestyle issues
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19648) Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS
[ https://issues.apache.org/jira/browse/CASSANDRA-19648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19648: -- Fix Version/s: 5.1-alpha1 (was: 5.x) Source Control Link: https://github.com/apache/cassandra/commit/df78296dcbc67c1d6dd1e0412fcd71f0a8f8fa7c Resolution: Fixed Status: Resolved (was: Ready to Commit) > Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS > - > > Key: CASSANDRA-19648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19648 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Ling Mao >Assignee: Ling Mao >Priority: Low > Fix For: 5.1-alpha1 > > Time Spent: 10m > Remaining Estimate: 0h > > Flaky test: StartupChecksTest#testKernelBug1057843Check() cannot pass in my > MacOs(maybe Windows OS). Just skip this test when tested on Non-Linux OS -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847948#comment-17847948 ] Stefan Miklosovic commented on CASSANDRA-19556: --- Links were consolidated in Links section of this ticket. > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847930#comment-17847930 ] Stefan Miklosovic commented on CASSANDRA-19556: --- Let's ask then and get these binding -1s explicitly. > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19648) Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS
[ https://issues.apache.org/jira/browse/CASSANDRA-19648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19648: -- Status: Ready to Commit (was: Review In Progress) > Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS > - > > Key: CASSANDRA-19648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19648 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Ling Mao >Assignee: Ling Mao >Priority: Low > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Flaky test: StartupChecksTest#testKernelBug1057843Check() cannot pass in my > MacOs(maybe Windows OS). Just skip this test when tested on Non-Linux OS -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19648) Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS
[ https://issues.apache.org/jira/browse/CASSANDRA-19648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19648: -- Reviewers: Brandon Williams, Stefan Miklosovic Status: Review In Progress (was: Needs Committer) > Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS > - > > Key: CASSANDRA-19648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19648 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Ling Mao >Assignee: Ling Mao >Priority: Low > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Flaky test: StartupChecksTest#testKernelBug1057843Check() cannot pass in my > MacOs(maybe Windows OS). Just skip this test when tested on Non-Linux OS -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19648) Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS
[ https://issues.apache.org/jira/browse/CASSANDRA-19648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847913#comment-17847913 ] Stefan Miklosovic commented on CASSANDRA-19648: --- +1 > Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS > - > > Key: CASSANDRA-19648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19648 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Ling Mao >Assignee: Ling Mao >Priority: Low > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Flaky test: StartupChecksTest#testKernelBug1057843Check() cannot pass in my > MacOs(maybe Windows OS). Just skip this test when tested on Non-Linux OS -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19645) Mismatch of number of args of String.format() in three classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19645: -- Fix Version/s: 5.1-alpha1 (was: 5.x) Since Version: NA Source Control Link: https://github.com/apache/cassandra/commit/dc89df7da1d9577ed0130873c491f7f4ccf99bae Resolution: Fixed Status: Resolved (was: Ready to Commit) > Mismatch of number of args of String.format() in three classes > -- > > Key: CASSANDRA-19645 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19645 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Dmitrii Kriukov >Assignee: Dmitrii Kriukov >Priority: Normal > Fix For: 5.1-alpha1 > > Time Spent: 10m > Remaining Estimate: 0h > > Affected classes: > GossipHelper lines 196-197 > SchemaGenerators line 488 > StorageService line 1087 > I'm goind to provide a PR -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19645) Mismatch of number of args of String.format() in three classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847710#comment-17847710 ] Stefan Miklosovic commented on CASSANDRA-19645: --- +1 > Mismatch of number of args of String.format() in three classes > -- > > Key: CASSANDRA-19645 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19645 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Dmitrii Kriukov >Assignee: Dmitrii Kriukov >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Affected classes: > GossipHelper lines 196-197 > SchemaGenerators line 488 > StorageService line 1087 > I'm goind to provide a PR -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19645) Mismatch of number of args of String.format() in three classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19645: -- Status: Ready to Commit (was: Review In Progress) > Mismatch of number of args of String.format() in three classes > -- > > Key: CASSANDRA-19645 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19645 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Dmitrii Kriukov >Assignee: Dmitrii Kriukov >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Affected classes: > GossipHelper lines 196-197 > SchemaGenerators line 488 > StorageService line 1087 > I'm goind to provide a PR -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19645) Mismatch of number of args of String.format() in three classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847677#comment-17847677 ] Stefan Miklosovic commented on CASSANDRA-19645: --- maybe logging "sequence.kind()" is better? > Mismatch of number of args of String.format() in three classes > -- > > Key: CASSANDRA-19645 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19645 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Dmitrii Kriukov >Assignee: Dmitrii Kriukov >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Affected classes: > GossipHelper lines 196-197 > SchemaGenerators line 488 > StorageService line 1087 > I'm goind to provide a PR -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19645) Mismatch of number of args of String.format() in three classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847676#comment-17847676 ] Stefan Miklosovic edited comment on CASSANDRA-19645 at 5/19/24 12:54 PM: - Looks good but just saying that when "sequence" is MultiStepOperation, which is abstract class, then log message in GossiperHelper where "toString" is implicitly called on sequence will rely on overridden toString method in extended classes of MultiStepOperation. In other words, if somebody creates new MultiStepOperation and forgets to override toString in it, the default one will be used which is pretty much non-telling. was (Author: smiklosovic): Looks good but just saying that when "sequence" is MultiStepOperation, which is abstract class, then log message in GossiperHelper where "toString" is implicitly called on sequence will rely on overridden toString method in extended classes of MultiStepOperation. In other words, if somebody creates new MultiStepOperation and forgets to override toString in it, the the default one will be used which is pretty much non-telling. > Mismatch of number of args of String.format() in three classes > -- > > Key: CASSANDRA-19645 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19645 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Dmitrii Kriukov >Assignee: Dmitrii Kriukov >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Affected classes: > GossipHelper lines 196-197 > SchemaGenerators line 488 > StorageService line 1087 > I'm goind to provide a PR -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19645) Mismatch of number of args of String.format() in three classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847676#comment-17847676 ] Stefan Miklosovic edited comment on CASSANDRA-19645 at 5/19/24 12:54 PM: - Looks good but just saying that when "sequence" is MultiStepOperation, which is abstract class, then log message in GossiperHelper where "toString" is implicitly called on sequence will rely on overridden toString method in extended classes of MultiStepOperation. In other words, if somebody creates new MultiStepOperation and forgets to override toString in it, the the default one will be used which is pretty much non-telling. was (Author: smiklosovic): Looks good but just saying that when "sequence" is MultiStepOperation, which is abstract class, then log the message in GossiperHelper where "toString" is implicitly called on sequence will rely on overridden toString method in extended classes of MultiStepOperation. In other words, if somebody creates new MultiStepOperation and forgets to override toString in it, the the default one will be used which is pretty much non-telling. > Mismatch of number of args of String.format() in three classes > -- > > Key: CASSANDRA-19645 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19645 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Dmitrii Kriukov >Assignee: Dmitrii Kriukov >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Affected classes: > GossipHelper lines 196-197 > SchemaGenerators line 488 > StorageService line 1087 > I'm goind to provide a PR -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19645) Mismatch of number of args of String.format() in three classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847676#comment-17847676 ] Stefan Miklosovic commented on CASSANDRA-19645: --- Looks good but just saying that when "sequence" is MultiStepOperation, which is abstract class, then log the message in GossiperHelper where "toString" is implicitly called on sequence will rely on overridden toString method in extended classes of MultiStepOperation. In other words, if somebody creates new MultiStepOperation and forgets to override toString in it, the the default one will be used which is pretty much non-telling. > Mismatch of number of args of String.format() in three classes > -- > > Key: CASSANDRA-19645 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19645 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Dmitrii Kriukov >Assignee: Dmitrii Kriukov >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Affected classes: > GossipHelper lines 196-197 > SchemaGenerators line 488 > StorageService line 1087 > I'm goind to provide a PR -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19645) Mismatch of number of args of String.format() in three classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19645: -- Status: Review In Progress (was: Needs Committer) > Mismatch of number of args of String.format() in three classes > -- > > Key: CASSANDRA-19645 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19645 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Dmitrii Kriukov >Assignee: Dmitrii Kriukov >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Affected classes: > GossipHelper lines 196-197 > SchemaGenerators line 488 > StorageService line 1087 > I'm goind to provide a PR -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18712) Update Chronicle bytes
[ https://issues.apache.org/jira/browse/CASSANDRA-18712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18712: -- Status: Changes Suggested (was: Review In Progress) > Update Chronicle bytes > -- > > Key: CASSANDRA-18712 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18712 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Nayana Thorat >Assignee: Nayana Thorat >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > [https://github.com/OpenHFT/Chronicle-Bytes/pull/485] fixes test failures of > cassandra on s390x. > This patch is merged and available in chronicle-bytes-2.24ea7 and later > releases. > possible to update Chronicle bytes and related pkg versions in Cassandra > (https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml)? > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18712) Update Chronicle bytes
[
https://issues.apache.org/jira/browse/CASSANDRA-18712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847146#comment-17847146
]
Stefan Miklosovic commented on CASSANDRA-18712:
---
Oh well, so there are failures when upgrading to this version. It is all in the
respective logs.
I think it is not just about bumping the versions ... Naively bumping it
compiles but tests are failing.
The failure is something like this:
{noformat}
failed on teardown with "Unexpected error found in node logs (see stdout for
full details). Errors: [[node1] "WARN [RMI TCP Connection(2)-127.0.0.1]
2024-05-16 13:47:46,320 Slf4jExceptionHandler.java:50 - You've configured your
queue to use a deprecated RollCycle
(net.openhft.chronicle.queue.RollCycles.TEST_SECONDLY) please consider
switching to
net.openhft.chronicle.queue.rollcycles.TestRollCycles.TEST_SECONDLY, as the
RollCycle constant you've nominated will be removed in a future release!"]"
{noformat}
[CASSANDRA-18712|https://github.com/instaclustr/cassandra/tree/CASSANDRA-18712]
{noformat}
java17_pre-commit_tests
✓ j17_build4m 30s
✓ j17_cqlsh_dtests_py311 6m 57s
✓ j17_cqlsh_dtests_py311_vnode 7m 18s
✓ j17_cqlsh_dtests_py387m 17s
✓ j17_cqlsh_dtests_py38_vnode 7m 20s
✓ j17_cqlshlib_cython_tests8m 15s
✓ j17_cqlshlib_tests 6m 42s
✓ j17_jvm_dtests_latest_vnode 21m 0s
✓ j17_unit_tests 14m 12s
✓ j17_utests_oa13m 5s
✕ j17_dtests 36m 30s
auditlog_test.TestAuditlog test_archive_on_shutdown
auditlog_test.TestAuditlog test_archive_on_startup
auditlog_test.TestAuditlog test_archiving
auditlog_test.TestAuditlog test_archiving_fql
auditlog_test.TestAuditlog test_fql_nodetool_options
fqltool_test.TestFQLTool test_compare
fqltool_test.TestFQLTool test_compare_mismatch
fqltool_test.TestFQLTool test_jvmdtest
fqltool_test.TestFQLTool test_replay
fqltool_test.TestFQLTool test_unclean_enable
✕ j17_dtests_latest 36m 43s
auditlog_test.TestAuditlog test_archive_on_shutdown
auditlog_test.TestAuditlog test_archive_on_startup
auditlog_test.TestAuditlog test_archiving
auditlog_test.TestAuditlog test_archiving_fql
auditlog_test.TestAuditlog test_fql_nodetool_options
fqltool_test.TestFQLTool test_compare
fqltool_test.TestFQLTool test_compare_mismatch
fqltool_test.TestFQLTool test_jvmdtest
fqltool_test.TestFQLTool test_replay
configuration_test.TestConfiguration test_change_durable_writes
fqltool_test.TestFQLTool test_unclean_enable
✕ j17_dtests_vnode38m 20s
auditlog_test.TestAuditlog test_archive_on_shutdown
auditlog_test.TestAuditlog test_archive_on_startup
auditlog_test.TestAuditlog test_archiving
auditlog_test.TestAuditlog test_archiving_fql
auditlog_test.TestAuditlog test_fql_nodetool_options
fqltool_test.TestFQLTool test_compare
fqltool_test.TestFQLTool test_compare_mismatch
fqltool_test.TestFQLTool test_jvmdtest
fqltool_test.TestFQLTool test_replay
fqltool_test.TestFQLTool test_unclean_enable
✕ j17_jvm_dtests 22m 57s
✕ j17_utests_latest 14m 25s
org.apache.cassandra.net.ConnectionTest testTimeout
java17_separate_tests
java11_pre-commit_tests
✓ j11_build7m 33s
✓ j11_cqlsh_dtests_py311 8m 26s
✓ j11_cqlsh_dtests_py311_vnode 8m 8s
✓ j11_cqlsh_dtests_py388m 29s
✓ j11_cqlsh_dtests_py38_vnode 10m 33s
✓ j11_cqlshlib_cython_tests11m 8s
✓ j11_cqlshlib_tests 11m 39s
✓ j11_jvm_dtests 27m 21s
✓ j11_jvm_dtests_latest_vnode 21m 8s
✓ j11_unit_tests 17m 33s
✓ j11_utests_oa 18m 53s
✓ j11_utests_system_keyspace_directory18m 43s
✓ j17_cqlsh_dtests_py311 6m 51s
✓ j17_cqlsh_dtests_py311_vnode 7m 20s
✓ j17_cqlsh_dtests_py38 7m 6s
✓ j17_cqlsh_dtests_py38_vnode 7m 33s
✓ j17_cqlshlib_cython_tests7m 28s
✓ j17_cqlshlib_tests 8m 41s
✓ j17_unit_tests 14m 23s
✓ j17_utests_latest
[jira] [Commented] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847145#comment-17847145 ] Stefan Miklosovic commented on CASSANDRA-19556: --- I understand your concern about chasing the last rc blocker but purely in practical terms, as long as e.g. 19534 is not merged first we have time to merge this too. I am not sure what the next steps are. Do you want me to re-iterate the necessity of merging this on the ML in the respective mailing list thread? > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[
https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847034#comment-17847034
]
Stefan Miklosovic commented on CASSANDRA-19556:
---
{quote}I really think that the silver bullet does exist and that is just
removing alter_table_enabled while it is not late and introducing ddl_enabled
in 5.0 GA.
{quote}
I still think this is completely reasonable to do even now. There will be still
at least one rc1 anyway. What are the _objective_ reasons this can't be
incorporated now? There are way bigger patches like CASSANDRA-19534 which seem
to be completely OK to be introduced even now, this patch is magnitude less
complicated.
> Add guardrail to block DDL/DCL queries and replace alter_table_enabled
> guardrail
>
>
> Key: CASSANDRA-19556
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19556
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Yuqi Yan
>Assignee: Yuqi Yan
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Sometimes we want to block DDL/DCL queries to stop new schemas being created
> or roles created. (e.g. when doing live-upgrade)
> For DDL guardrail current implementation won't block the query if it's no-op
> (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The
> guardrail check is added in apply() right after all the existence check)
> I don't have preference on either block every DDL query or check whether if
> it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS..
> at startup, which is no-op but will be blocked by this guardrail and failed
> to start.
>
> 4.1 PR: [https://github.com/apache/cassandra/pull/3248]
> trunk PR: [https://github.com/apache/cassandra/pull/3275]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18712) Update Chronicle bytes
[ https://issues.apache.org/jira/browse/CASSANDRA-18712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846941#comment-17846941 ] Stefan Miklosovic commented on CASSANDRA-18712: --- What I would personally do is that I would wait with this ticket until 5.1 is imminent. The reason for doing so is that while we release 5.1, we will most likely want to update these dependencies again because they are being actively developed. I do not see any critical reason why should be this merged _right now_ - only if we want to enable people to test trunk on s390x as mentioned in the description that this is a blocker for them, but we do not officially support that architecture anyway ... > Update Chronicle bytes > -- > > Key: CASSANDRA-18712 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18712 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Nayana Thorat >Assignee: Nayana Thorat >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > [https://github.com/OpenHFT/Chronicle-Bytes/pull/485] fixes test failures of > cassandra on s390x. > This patch is merged and available in chronicle-bytes-2.24ea7 and later > releases. > possible to update Chronicle bytes and related pkg versions in Cassandra > (https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml)? > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18712) Update Chronicle bytes
[
https://issues.apache.org/jira/browse/CASSANDRA-18712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846919#comment-17846919
]
Stefan Miklosovic edited comment on CASSANDRA-18712 at 5/16/24 11:41 AM:
-
I verified that a tarball with this change contains
{code:java}
chronicle-bytes-2.25ea9.jar
chronicle-core-2.25ea13.jar
chronicle-queue-5.25ea13.jar
chronicle-threads-2.25ea6.jar
chronicle-wire-2.25ea12.jar{code}
while the old tarball contains
{code:java}
chronicle-bytes-2.23.33.jar
chronicle-core-2.23.36.jar
chronicle-queue-5.23.37.jar
chronicle-threads-2.23.25.jar
chronicle-wire-2.23.39.jar{code}
There are no changes in libs dir except these.
I checked that the versions match the versions in the bom.
When it comes to pom.xml (after ant mvn-install), it is same (checking with mvn
dependency:tree)
I am not sure what is their policy when it comes to release versioning.
[https://central.sonatype.com/artifact/net.openhft/chronicle-core/versions]
E.g. there is not any "not early access" of 2.24, they stopped with 2.24ea28
and next one was 2.25ea0.
[https://repo1.maven.org/maven2/net/openhft/chronicle-core/]
was (Author: smiklosovic):
I verified that a tarball with this change contains
{code:java}
chronicle-bytes-2.25ea9.jar
chronicle-core-2.25ea13.jar
chronicle-queue-5.25ea13.jar
chronicle-threads-2.25ea6.jar
chronicle-wire-2.25ea12.jar{code}
while the old tarball contains
{code:java}
chronicle-bytes-2.23.33.jar
chronicle-core-2.23.36.jar
chronicle-queue-5.23.37.jar
chronicle-threads-2.23.25.jar
chronicle-wire-2.23.39.jar{code}
There are no changes in libs dir except these.
When it comes to pom.xml (after ant mvn-install), it is same (checking with mvn
dependency:tree)
I am not sure what is their policy when it comes to release versioning.
[https://central.sonatype.com/artifact/net.openhft/chronicle-core/versions]
E.g. there is not any "not early access" of 2.24, they stopped with 2.24ea28
and next one was 2.25ea0.
[https://repo1.maven.org/maven2/net/openhft/chronicle-core/]
> Update Chronicle bytes
> --
>
> Key: CASSANDRA-18712
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18712
> Project: Cassandra
> Issue Type: Task
> Components: Dependencies
>Reporter: Nayana Thorat
>Assignee: Nayana Thorat
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> [https://github.com/OpenHFT/Chronicle-Bytes/pull/485] fixes test failures of
> cassandra on s390x.
> This patch is merged and available in chronicle-bytes-2.24ea7 and later
> releases.
> possible to update Chronicle bytes and related pkg versions in Cassandra
> (https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml)?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18712) Update Chronicle bytes
[
https://issues.apache.org/jira/browse/CASSANDRA-18712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846919#comment-17846919
]
Stefan Miklosovic edited comment on CASSANDRA-18712 at 5/16/24 11:40 AM:
-
I verified that a tarball with this change contains
{code:java}
chronicle-bytes-2.25ea9.jar
chronicle-core-2.25ea13.jar
chronicle-queue-5.25ea13.jar
chronicle-threads-2.25ea6.jar
chronicle-wire-2.25ea12.jar{code}
while the old tarball contains
{code:java}
chronicle-bytes-2.23.33.jar
chronicle-core-2.23.36.jar
chronicle-queue-5.23.37.jar
chronicle-threads-2.23.25.jar
chronicle-wire-2.23.39.jar{code}
There are no changes in libs dir except these.
When it comes to pom.xml (after ant mvn-install), it is same (checking with mvn
dependency:tree)
I am not sure what is their policy when it comes to release versioning.
[https://central.sonatype.com/artifact/net.openhft/chronicle-core/versions]
E.g. there is not any "not early access" of 2.24, they stopped with 2.24ea28
and next one was 2.25ea0.
[https://repo1.maven.org/maven2/net/openhft/chronicle-core/]
was (Author: smiklosovic):
I verified that a tarball with this change contains
{code:java}
chronicle-bytes-2.25ea9.jar
chronicle-core-2.25ea13.jar
chronicle-queue-5.25ea13.jar
chronicle-threads-2.25ea6.jar
chronicle-wire-2.25ea12.jar{code}
while the old tarball contains
{code:java}
chronicle-bytes-2.23.33.jar
chronicle-core-2.23.36.jar
chronicle-queue-5.23.37.jar
chronicle-threads-2.23.25.jar
chronicle-wire-2.23.39.jar{code}
There are no changes in libs dir except these.
When it comes to pom.xml (after ant mvn-install), it is same.
> Update Chronicle bytes
> --
>
> Key: CASSANDRA-18712
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18712
> Project: Cassandra
> Issue Type: Task
> Components: Dependencies
>Reporter: Nayana Thorat
>Assignee: Nayana Thorat
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> [https://github.com/OpenHFT/Chronicle-Bytes/pull/485] fixes test failures of
> cassandra on s390x.
> This patch is merged and available in chronicle-bytes-2.24ea7 and later
> releases.
> possible to update Chronicle bytes and related pkg versions in Cassandra
> (https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml)?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18712) Update Chronicle bytes
[
https://issues.apache.org/jira/browse/CASSANDRA-18712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846919#comment-17846919
]
Stefan Miklosovic commented on CASSANDRA-18712:
---
I verified that a tarball with this change contains
{code:java}
chronicle-bytes-2.25ea9.jar
chronicle-core-2.25ea13.jar
chronicle-queue-5.25ea13.jar
chronicle-threads-2.25ea6.jar
chronicle-wire-2.25ea12.jar{code}
while the old tarball contains
{code:java}
chronicle-bytes-2.23.33.jar
chronicle-core-2.23.36.jar
chronicle-queue-5.23.37.jar
chronicle-threads-2.23.25.jar
chronicle-wire-2.23.39.jar{code}
There are no changes in libs dir except these.
When it comes to pom.xml (after ant mvn-install), it is same.
> Update Chronicle bytes
> --
>
> Key: CASSANDRA-18712
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18712
> Project: Cassandra
> Issue Type: Task
> Components: Dependencies
>Reporter: Nayana Thorat
>Assignee: Nayana Thorat
>Priority: Normal
> Fix For: 5.x
>
>
> [https://github.com/OpenHFT/Chronicle-Bytes/pull/485] fixes test failures of
> cassandra on s390x.
> This patch is merged and available in chronicle-bytes-2.24ea7 and later
> releases.
> possible to update Chronicle bytes and related pkg versions in Cassandra
> (https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml)?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18712) Update Chronicle bytes
[ https://issues.apache.org/jira/browse/CASSANDRA-18712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846897#comment-17846897 ] Stefan Miklosovic commented on CASSANDRA-18712: --- thanks [~Nayana] , I ll take a look. > Update Chronicle bytes > -- > > Key: CASSANDRA-18712 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18712 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Nayana Thorat >Assignee: Nayana Thorat >Priority: Normal > Fix For: 5.x > > > [https://github.com/OpenHFT/Chronicle-Bytes/pull/485] fixes test failures of > cassandra on s390x. > This patch is merged and available in chronicle-bytes-2.24ea7 and later > releases. > possible to update Chronicle bytes and related pkg versions in Cassandra > (https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml)? > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18712) Update Chronicle bytes
[ https://issues.apache.org/jira/browse/CASSANDRA-18712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18712: -- Reviewers: Stefan Miklosovic Status: Review In Progress (was: Patch Available) > Update Chronicle bytes > -- > > Key: CASSANDRA-18712 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18712 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Nayana Thorat >Assignee: Nayana Thorat >Priority: Normal > Fix For: 5.x > > > [https://github.com/OpenHFT/Chronicle-Bytes/pull/485] fixes test failures of > cassandra on s390x. > This patch is merged and available in chronicle-bytes-2.24ea7 and later > releases. > possible to update Chronicle bytes and related pkg versions in Cassandra > (https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml)? > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18712) Update Chronicle bytes
[ https://issues.apache.org/jira/browse/CASSANDRA-18712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18712: -- Test and Documentation Plan: ci Status: Patch Available (was: In Progress) > Update Chronicle bytes > -- > > Key: CASSANDRA-18712 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18712 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Nayana Thorat >Assignee: Nayana Thorat >Priority: Normal > Fix For: 5.x > > > [https://github.com/OpenHFT/Chronicle-Bytes/pull/485] fixes test failures of > cassandra on s390x. > This patch is merged and available in chronicle-bytes-2.24ea7 and later > releases. > possible to update Chronicle bytes and related pkg versions in Cassandra > (https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml)? > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18712) Update Chronicle bytes
[ https://issues.apache.org/jira/browse/CASSANDRA-18712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic reassigned CASSANDRA-18712: - Assignee: Nayana Thorat > Update Chronicle bytes > -- > > Key: CASSANDRA-18712 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18712 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Nayana Thorat >Assignee: Nayana Thorat >Priority: Normal > Fix For: 5.x > > > [https://github.com/OpenHFT/Chronicle-Bytes/pull/485] fixes test failures of > cassandra on s390x. > This patch is merged and available in chronicle-bytes-2.24ea7 and later > releases. > possible to update Chronicle bytes and related pkg versions in Cassandra > (https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml)? > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19429) Remove lock contention generated by getCapacity function in SSTableReader
[
https://issues.apache.org/jira/browse/CASSANDRA-19429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846725#comment-17846725
]
Stefan Miklosovic commented on CASSANDRA-19429:
---
I think that because this is targetted primarily to 4.0 / 4.1 and all eyes are
on 5.0 for now, I do not see this has high priority at the moment, especially
as we are just releasing 4.1.5 / 4.0.13.
I would however say that you can expect this to be eventually merged, I just do
not know about when.
> Remove lock contention generated by getCapacity function in SSTableReader
> -
>
> Key: CASSANDRA-19429
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19429
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Dipietro Salvatore
>Assignee: Dipietro Salvatore
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
> Attachments: Screenshot 2024-02-26 at 10.27.10.png, Screenshot
> 2024-02-27 at 11.29.41.png, Screenshot 2024-03-19 at 15.22.50.png,
> asprof_cass4.1.3__lock_20240216052912lock.html,
> image-2024-03-08-15-51-30-439.png, image-2024-03-08-15-52-07-902.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Profiling Cassandra 4.1.3 on large AWS instances, a high number of lock
> acquires is measured in the `getCapacity` function from
> `org/apache/cassandra/cache/InstrumentingCache` (1.9M lock acquires per 60
> seconds). Based on our tests on r8g.24xlarge instances (using Ubuntu 22.04),
> this limits the CPU utilization of the system to under 50% when testing at
> full load and therefore limits the achieved throughput.
> Removing the lock contention from the SSTableReader.java file by replacing
> the call to `getCapacity` with `size` achieves up to 2.95x increase in
> throughput on r8g.24xlarge and 2x on r7i.24xlarge:
> |Instance type|Cass 4.1.3|Cass 4.1.3 patched|
> |r8g.24xlarge|168k ops|496k ops (2.95x)|
> |r7i.24xlarge|153k ops|304k ops (1.98x)|
>
> Instructions to reproduce:
> {code:java}
> ## Requirements for Ubuntu 22.04
> sudo apt install -y ant git openjdk-11-jdk
> ## Build and run
> CASSANDRA_USE_JDK11=true ant realclean && CASSANDRA_USE_JDK11=true ant jar &&
> CASSANDRA_USE_JDK11=true ant stress-build && rm -rf data && bin/cassandra -f
> -R
> # Run
> bin/cqlsh -e 'drop table if exists keyspace1.standard1;' && \
> bin/cqlsh -e 'drop keyspace if exists keyspace1;' && \
> bin/nodetool clearsnapshot --all && tools/bin/cassandra-stress write
> n=1000 cl=ONE -rate threads=384 -node 127.0.0.1 -log file=cload.log
> -graph file=cload.html && \
> bin/nodetool compact keyspace1 && sleep 30s && \
> tools/bin/cassandra-stress mixed ratio\(write=10,read=90\) duration=10m
> cl=ONE -rate threads=406 -node localhost -log file=result.log -graph
> file=graph.html
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19335) Default nodetool tablestats to Human-Readable Output
[ https://issues.apache.org/jira/browse/CASSANDRA-19335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846337#comment-17846337 ] Stefan Miklosovic commented on CASSANDRA-19335: --- the logic of the test is wrapped in "ifs", checking what version a node is of and then acting accordingly - doing it with or without new feature. > Default nodetool tablestats to Human-Readable Output > > > Key: CASSANDRA-19335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19335 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Leo Toff >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Attachments: c-19335-dtest-bootstraptest-fail.txt, > c-19335-dtest-ccm-fail.txt, c-19335-dtest-compactiontest-fail.txt > > Time Spent: 1h > Remaining Estimate: 0h > > *Current Behavior* > The current implementation of nodetool tablestats in Apache Cassandra outputs > statistics in a format that is not immediately human-readable. This output > primarily includes raw byte counts, which require additional calculation or > conversion to be easily understood by users. This can be inefficient and > time-consuming, especially for users who frequently monitor these statistics > for performance tuning or maintenance purposes. > *Proposed Change* > We propose that nodetool tablestats should, by default, provide its output in > a human-readable format. This change would involve converting byte counts > into more understandable units (KiB, MiB, GiB). The tool could still retain > the option to display raw data for those who need it, perhaps through a flag > such as --no-human-readable or --raw. > *Considerations* > The change should maintain backward compatibility, ensuring that scripts or > tools relying on the current output format can continue to function correctly. > We should provide adequate documentation and examples of both the new default > output and how to access the raw data format, if needed. > *Alignment* > Discussion in the dev mailing list: > [https://lists.apache.org/thread/mlp715kxho5b6f1ql9omlzmmnh4qfby9] > *Related work* > Previous work in the series: > # https://issues.apache.org/jira/browse/CASSANDRA-19015 > # https://issues.apache.org/jira/browse/CASSANDRA-19104 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19335) Default nodetool tablestats to Human-Readable Output
[ https://issues.apache.org/jira/browse/CASSANDRA-19335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846324#comment-17846324 ] Stefan Miklosovic commented on CASSANDRA-19335: --- maybe I am missing something but ... how does this work for e.g. 4.0 branch? By looking at (1), we are introducing -r flag for table stats for tests which have nodetool without this feature, no? (1) https://github.com/apache/cassandra-dtest/pull/261/files > Default nodetool tablestats to Human-Readable Output > > > Key: CASSANDRA-19335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19335 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Leo Toff >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Attachments: c-19335-dtest-bootstraptest-fail.txt, > c-19335-dtest-ccm-fail.txt, c-19335-dtest-compactiontest-fail.txt > > Time Spent: 1h > Remaining Estimate: 0h > > *Current Behavior* > The current implementation of nodetool tablestats in Apache Cassandra outputs > statistics in a format that is not immediately human-readable. This output > primarily includes raw byte counts, which require additional calculation or > conversion to be easily understood by users. This can be inefficient and > time-consuming, especially for users who frequently monitor these statistics > for performance tuning or maintenance purposes. > *Proposed Change* > We propose that nodetool tablestats should, by default, provide its output in > a human-readable format. This change would involve converting byte counts > into more understandable units (KiB, MiB, GiB). The tool could still retain > the option to display raw data for those who need it, perhaps through a flag > such as --no-human-readable or --raw. > *Considerations* > The change should maintain backward compatibility, ensuring that scripts or > tools relying on the current output format can continue to function correctly. > We should provide adequate documentation and examples of both the new default > output and how to access the raw data format, if needed. > *Alignment* > Discussion in the dev mailing list: > [https://lists.apache.org/thread/mlp715kxho5b6f1ql9omlzmmnh4qfby9] > *Related work* > Previous work in the series: > # https://issues.apache.org/jira/browse/CASSANDRA-19015 > # https://issues.apache.org/jira/browse/CASSANDRA-19104 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19335) Default nodetool tablestats to Human-Readable Output
[ https://issues.apache.org/jira/browse/CASSANDRA-19335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19335: -- Reviewers: Brandon Williams, Stefan Miklosovic (was: Brandon Williams) Status: Review In Progress (was: Needs Committer) > Default nodetool tablestats to Human-Readable Output > > > Key: CASSANDRA-19335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19335 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Leo Toff >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Attachments: c-19335-dtest-bootstraptest-fail.txt, > c-19335-dtest-ccm-fail.txt, c-19335-dtest-compactiontest-fail.txt > > Time Spent: 1h > Remaining Estimate: 0h > > *Current Behavior* > The current implementation of nodetool tablestats in Apache Cassandra outputs > statistics in a format that is not immediately human-readable. This output > primarily includes raw byte counts, which require additional calculation or > conversion to be easily understood by users. This can be inefficient and > time-consuming, especially for users who frequently monitor these statistics > for performance tuning or maintenance purposes. > *Proposed Change* > We propose that nodetool tablestats should, by default, provide its output in > a human-readable format. This change would involve converting byte counts > into more understandable units (KiB, MiB, GiB). The tool could still retain > the option to display raw data for those who need it, perhaps through a flag > such as --no-human-readable or --raw. > *Considerations* > The change should maintain backward compatibility, ensuring that scripts or > tools relying on the current output format can continue to function correctly. > We should provide adequate documentation and examples of both the new default > output and how to access the raw data format, if needed. > *Alignment* > Discussion in the dev mailing list: > [https://lists.apache.org/thread/mlp715kxho5b6f1ql9omlzmmnh4qfby9] > *Related work* > Previous work in the series: > # https://issues.apache.org/jira/browse/CASSANDRA-19015 > # https://issues.apache.org/jira/browse/CASSANDRA-19104 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19498) support legacy [plain_text_auth] section in credentials file removed unintentionally
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19498:
--
Fix Version/s: 4.1.6
5.0-beta2
5.1-alpha1
(was: 5.x)
(was: 4.1.x)
(was: 5.0.x)
Since Version: 4.1.0
Source Control Link:
https://github.com/apache/cassandra/commit/d1f2936ccbc54158831b01499554adf63ae2d6ec
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> support legacy [plain_text_auth] section in credentials file removed
> unintentionally
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.6, 5.0-beta2, 5.1-alpha1
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT by Stefan Miklosovic:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19498) support legacy [plain_text_auth] section in credentials file removed unintentionally
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19498:
--
Status: Ready to Commit (was: Review In Progress)
> support legacy [plain_text_auth] section in credentials file removed
> unintentionally
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT by Stefan Miklosovic:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19498) support legacy [plain_text_auth] section in credentials file removed unintentionally
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19498:
--
Reviewers: Brad Schoening, Stefan Miklosovic, Stefan Miklosovic (was: Brad
Schoening, Stefan Miklosovic)
Brad Schoening, Stefan Miklosovic, Stefan Miklosovic (was: Brad
Schoening, Stefan Miklosovic)
Status: Review In Progress (was: Patch Available)
> support legacy [plain_text_auth] section in credentials file removed
> unintentionally
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT by Stefan Miklosovic:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19498) support legacy [plain_text_auth] section in credentials file removed unintentionally
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19498:
--
Status: Patch Available (was: Ready to Commit)
> support legacy [plain_text_auth] section in credentials file removed
> unintentionally
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT by Stefan Miklosovic:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19498) support legacy [plain_text_auth] section in credentials file removed unintentionally
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19498:
--
Status: Ready to Commit (was: Review In Progress)
> support legacy [plain_text_auth] section in credentials file removed
> unintentionally
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT by Stefan Miklosovic:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19498) support legacy [plain_text_auth] section in credentials file removed unintentionally
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846094#comment-17846094
]
Stefan Miklosovic commented on CASSANDRA-19498:
---
Nothing seems to be related. I am sending it by tomorrow.
[CASSANDRA-19498-trunk|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19498-trunk]
{noformat}
java17_pre-commit_tests
✓ j17_build4m 14s
✓ j17_cqlsh_dtests_py311 7m 12s
✓ j17_cqlsh_dtests_py311_vnode 7m 17s
✓ j17_cqlsh_dtests_py38 7m 1s
✓ j17_cqlsh_dtests_py38_vnode 7m 38s
✓ j17_cqlshlib_cython_tests7m 30s
✓ j17_cqlshlib_tests 9m 13s
✓ j17_dtests_vnode36m 15s
✓ j17_unit_tests 13m 36s
✓ j17_utests_latest 14m 55s
✓ j17_utests_oa 13m 51s
✕ j17_dtests 37m 33s
pushed_notifications_test.TestPushedNotifications
test_move_single_node_localhost
✕ j17_dtests_latest 36m 11s
configuration_test.TestConfiguration test_change_durable_writes
topology_test.TestTopology test_resumable_decommission
✕ j17_jvm_dtests 23m 43s
org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
testEndpointVerificationEnabledIpNotInSAN
org.apache.cassandra.distributed.test.log.CoordinatorPathTest
readConsistencyTest
✕ j17_jvm_dtests_latest_vnode 19m 35s
org.apache.cassandra.fuzz.harry.integration.model.ConcurrentQuiescentCheckerIntegrationTest
testConcurrentReadWriteWorkload
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4306/workflows/af302198-2b4a-4283-a6f0-bd90710f05a8]
> support legacy [plain_text_auth] section in credentials file removed
> unintentionally
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT by Stefan Miklosovic:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail:
[jira] [Commented] (CASSANDRA-19498) support legacy [plain_text_auth] section in credentials file removed unintentionally
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846045#comment-17846045
]
Stefan Miklosovic commented on CASSANDRA-19498:
---
[CASSANDRA-19498-5.0|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19498-5.0]
{noformat}
java17_pre-commit_tests
✓ j17_build4m 11s
✓ j17_cqlsh_dtests_py311 6m 43s
✓ j17_cqlsh_dtests_py311_vnode 6m 11s
✓ j17_cqlsh_dtests_py38 6m 2s
✓ j17_cqlsh_dtests_py38_vnode 6m 31s
✓ j17_cqlshlib_cython_tests7m 21s
✓ j17_cqlshlib_tests 6m 43s
✓ j17_dtests 35m 20s
✓ j17_dtests_latest 33m 16s
✓ j17_dtests_vnode33m 50s
✓ j17_jvm_dtests 22m 25s
✓ j17_jvm_dtests_latest_vnode 17m 1s
✓ j17_unit_tests 15m 43s
✓ j17_utests_latest 14m 16s
✓ j17_utests_oa 14m 16s
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4305/workflows/f1f3c878-e0be-4b3c-9b53-315b3148e556]
> support legacy [plain_text_auth] section in credentials file removed
> unintentionally
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT by Stefan Miklosovic:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19498) support legacy [plain_text_auth] section in credentials file removed unintentionally
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845960#comment-17845960
]
Stefan Miklosovic commented on CASSANDRA-19498:
---
[CASSANDRA-19498-4.1|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19498-4.1]
{noformat}
java11_pre-commit_tests
✓ j11_build 2m 0s
✓ j11_cqlsh_dtests_py3 5m 50s
✓ j11_cqlsh_dtests_py311 5m 42s
✓ j11_cqlsh_dtests_py311_vnode 5m 58s
✓ j11_cqlsh_dtests_py385m 36s
✓ j11_cqlsh_dtests_py38_vnode 6m 1s
✓ j11_cqlsh_dtests_py3_vnode 6m 10s
✓ j11_cqlshlib_cython_tests 8m 4s
✓ j11_cqlshlib_tests 6m 28s
✓ j11_dtests 35m 12s
✓ j11_dtests_vnode37m 47s
✓ j11_jvm_dtests 19m 30s
✓ j11_jvm_dtests_vnode11m 50s
✕ j11_unit_tests 7m 30s
org.apache.cassandra.tools.TopPartitionsTest
testServiceTopPartitionsSingleTable
org.apache.cassandra.cql3.MemtableSizeTest testSize[skiplist]
{noformat}
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4300/workflows/47cb43ab-a92d-41e0-8ed7-6a45da454d23]
> support legacy [plain_text_auth] section in credentials file removed
> unintentionally
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT by Stefan Miklosovic:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845934#comment-17845934 ] Stefan Miklosovic edited comment on CASSANDRA-19556 at 5/13/24 1:57 PM: So deprecation of alter_table_enabled is probably out of window because it was never released in a GA so deprecating something on the very first introduction does not make sense to me either. It would be just better if we removed alter_table_enabled altogether in that case so we can just put ddl_enabled to 5.1. Plus we are not going to deprecate it in 5.0.x either. Individual guardrail per group, as explained on the mailing list, is IMHO overkill. All the explanation is there. Having two rules at the same time leads to kind of inconsistency / unexpected behavior. If we have ddl_enabled, it will, functionally, shadow alter_table_enabled. If the former is disabled but the latter is enabled, we can not alter tables which I find rather confusing for a user. I think there is no such case yet which would behave similarly. I really think that the silver bullet _does_ exist and that is just removing alter_table_enabled while it is not late and introducing ddl_enabled in 5.0 GA. was (Author: smiklosovic): So deprecation of alter_table_enabled is probably out of window because it was never released in a GA so deprecating something on the very first introduction does not make sense to me either. It would be just better if we removed alter_table_enabled altogether in that case so we can just put ddl_enabled to 5.1. Plus we are not going to deprecate it in 5.0.x either. Individual guardrail per group, as explained on the mailing list, is IMHO overkill. All the explanation is there. I really think that the silver bullet _does_ exist and that is just removing alter_table_enabled while it is not late and introducing ddl_enabled in 5.0 GA. > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845934#comment-17845934 ] Stefan Miklosovic edited comment on CASSANDRA-19556 at 5/13/24 1:55 PM: So deprecation of alter_table_enabled is probably out of window because it was never released in a GA so deprecating something on the very first introduction does not make sense to me either. It would be just better if we removed alter_table_enabled altogether in that case so we can just put ddl_enabled to 5.1. Plus we are not going to deprecate it in 5.0.x either. Individual guardrail per group, as explained on the mailing list, is IMHO overkill. All the explanation is there. I really think that the silver bullet _does_ exist and that is just removing alter_table_enabled while it is not late and introducing ddl_enabled in 5.0 GA. was (Author: smiklosovic): So deprecation of alter_table_enabled is probably out of window because it was never released in a GA so deprecating something on the very first introduction does not make sense to me either. It would be just better if we removed alter_table_enabled altogether in that case so we can just put ddl_enabled to 5.1. Individual guardrail per group, as explained on the mailing list, is IMHO overkill. All the explanation is there. I really think that the silver bullet _does_ exist and that is just removing alter_table_enabled while it is not late and introducing ddl_enabled in 5.0 GA. > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845934#comment-17845934 ] Stefan Miklosovic commented on CASSANDRA-19556: --- So deprecation of alter_table_enabled is probably out of window because it was never released in a GA so deprecating something on the very first introduction does not make sense to me either. It would be just better if we removed alter_table_enabled altogether in that case so we can just put ddl_enabled to 5.1. Individual guardrail per group, as explained on the mailing list, is IMHO overkill. All the explanation is there. I really think that the silver bullet _does_ exist and that is just removing alter_table_enabled while it is not late and introducing ddl_enabled in 5.0 GA. > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19498) support legacy [plain_text_auth] section in credentials file removed unintentionally
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19498:
--
Fix Version/s: 5.0.x
(was: 5.0-rc)
> support legacy [plain_text_auth] section in credentials file removed
> unintentionally
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT by Stefan Miklosovic:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19498) support legacy [plain_text_auth] section in credentials file removed unintentionally
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19498:
--
Fix Version/s: 5.0-rc
(was: 5.0.x)
> support legacy [plain_text_auth] section in credentials file removed
> unintentionally
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0-rc, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT by Stefan Miklosovic:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19498) support legacy [plain_text_auth] section in credentials file removed unintentionally
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19498:
--
Summary: support legacy [plain_text_auth] section in credentials file
removed unintentionally (was: support legacy [plain_text_auth] in credentials
file)
> support legacy [plain_text_auth] section in credentials file removed
> unintentionally
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT by Stefan Miklosovic:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19498) support legacy [plain_text_auth] in credentials file
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845890#comment-17845890
]
Stefan Miklosovic commented on CASSANDRA-19498:
---
I am starting the builds. I also tweaked the wording around docs a little bit
etc ...
> support legacy [plain_text_auth] in credentials file
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT by Stefan Miklosovic:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19498) support legacy [plain_text_auth] in credentials file
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19498:
--
Description:
The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
however, it is immediately ignored.
[https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
{code:java}
if not options.username:
credentials = configparser.ConfigParser()
if options.credentials is not None:
credentials.read(options.credentials) # use the username
from credentials file but fallback to cqlshrc if username is absent from the
command line parameters
options.username = username_from_cqlshrc if not options.password:
rawcredentials = configparser.RawConfigParser()
if options.credentials is not None:
rawcredentials.read(options.credentials) # handling password
in the same way as username, priority cli > credentials > cqlshrc
options.password = option_with_default(rawcredentials.get,
'plain_text_auth', 'password', password_from_cqlshrc)
options.password = password_from_cqlshrc{code}
These corrections have been made in accordance with
https://issues.apache.org/jira/browse/CASSANDRA-16983 and
https://issues.apache.org/jira/browse/CASSANDRA-16456.
The documentation does not indicate that AuthProviders can be used in the
cqlshrc and credentials files.
I propose to return the ability to use the legacy option of specifying the user
and password in the credentials file in the [plain_text_auth] section.
It is also required to describe the rules for using the credentials file in the
documentation.
I can make a corresponding pull request.
EDIT by Stefan Miklosovic:
specifying username and password in credentials file works, it is just that
[plain_text_auth] section does not work in credentials file anymore. This was
working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
tickets were firstly introduced in 4.1.0 (for the public). I do not think that
it was ever an intention to stop to support that when CASSANDRA-16456 was
merged and it was most probably just overlooked.
was:
The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
however, it is immediately ignored.
[https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
{code:java}
if not options.username:
credentials = configparser.ConfigParser()
if options.credentials is not None:
credentials.read(options.credentials) # use the username
from credentials file but fallback to cqlshrc if username is absent from the
command line parameters
options.username = username_from_cqlshrc if not options.password:
rawcredentials = configparser.RawConfigParser()
if options.credentials is not None:
rawcredentials.read(options.credentials) # handling password
in the same way as username, priority cli > credentials > cqlshrc
options.password = option_with_default(rawcredentials.get,
'plain_text_auth', 'password', password_from_cqlshrc)
options.password = password_from_cqlshrc{code}
These corrections have been made in accordance with
https://issues.apache.org/jira/browse/CASSANDRA-16983 and
https://issues.apache.org/jira/browse/CASSANDRA-16456.
The documentation does not indicate that AuthProviders can be used in the
cqlshrc and credentials files.
I propose to return the ability to use the legacy option of specifying the user
and password in the credentials file in the [plain_text_auth] section.
It is also required to describe the rules for using the credentials file in the
documentation.
I can make a corresponding pull request.
EDIT:
specifying username and password in credentials file works, it is just that
[plain_text_auth] section does not work in credentials file anymore. This was
working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
tickets were firstly introduced in 4.1.0 (for the public). I do not think that
it was ever an intention to stop to support that when CASSANDRA-16456 was
merged and it was most probably just overlooked.
> support legacy [plain_text_auth] in credentials file
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
[jira] [Updated] (CASSANDRA-19498) support legacy [plain_text_auth] in credentials file
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19498:
--
Reviewers: Brad Schoening, Stefan Miklosovic, Stefan Miklosovic (was: Brad
Schoening, Stefan Miklosovic)
Brad Schoening, Stefan Miklosovic, Stefan Miklosovic (was: Brad
Schoening, Stefan Miklosovic)
Status: Review In Progress (was: Patch Available)
> support legacy [plain_text_auth] in credentials file
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19498) support legacy [plain_text_auth] in credentials file
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19498:
--
Description:
The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
however, it is immediately ignored.
[https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
{code:java}
if not options.username:
credentials = configparser.ConfigParser()
if options.credentials is not None:
credentials.read(options.credentials) # use the username
from credentials file but fallback to cqlshrc if username is absent from the
command line parameters
options.username = username_from_cqlshrc if not options.password:
rawcredentials = configparser.RawConfigParser()
if options.credentials is not None:
rawcredentials.read(options.credentials) # handling password
in the same way as username, priority cli > credentials > cqlshrc
options.password = option_with_default(rawcredentials.get,
'plain_text_auth', 'password', password_from_cqlshrc)
options.password = password_from_cqlshrc{code}
These corrections have been made in accordance with
https://issues.apache.org/jira/browse/CASSANDRA-16983 and
https://issues.apache.org/jira/browse/CASSANDRA-16456.
The documentation does not indicate that AuthProviders can be used in the
cqlshrc and credentials files.
I propose to return the ability to use the legacy option of specifying the user
and password in the credentials file in the [plain_text_auth] section.
It is also required to describe the rules for using the credentials file in the
documentation.
I can make a corresponding pull request.
EDIT:
specifying username and password in credentials file works, it is just that
[plain_text_auth] section does not work in credentials file anymore. This was
working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
tickets were firstly introduced in 4.1.0 (for the public). I do not think that
it was ever an intention to stop to support that when CASSANDRA-16456 was
merged and it was most probably just overlooked.
was:
The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
however, it is immediately ignored.
https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070
{code:java}
if not options.username:
credentials = configparser.ConfigParser()
if options.credentials is not None:
credentials.read(options.credentials) # use the username
from credentials file but fallback to cqlshrc if username is absent from the
command line parameters
options.username = username_from_cqlshrc if not options.password:
rawcredentials = configparser.RawConfigParser()
if options.credentials is not None:
rawcredentials.read(options.credentials) # handling password
in the same way as username, priority cli > credentials > cqlshrc
options.password = option_with_default(rawcredentials.get,
'plain_text_auth', 'password', password_from_cqlshrc)
options.password = password_from_cqlshrc{code}
These corrections have been made in accordance with
https://issues.apache.org/jira/browse/CASSANDRA-16983 and
https://issues.apache.org/jira/browse/CASSANDRA-16456.
The documentation does not indicate that AuthProviders can be used in the
cqlshrc and credentials files.
I propose to return the ability to use the legacy option of specifying the user
and password in the credentials file in the [plain_text_auth] section.
It is also required to describe the rules for using the credentials file in the
documentation.
I can make a corresponding pull request.
> support legacy [plain_text_auth] in credentials file
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
>
[jira] [Assigned] (CASSANDRA-19498) support legacy [plain_text_auth] in credentials file
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic reassigned CASSANDRA-19498:
-
Assignee: Stefan Miklosovic
> support legacy [plain_text_auth] in credentials file
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19498) support legacy [plain_text_auth] in credentials file
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19498:
--
Summary: support legacy [plain_text_auth] in credentials file (was: Error
reading data from credential file)
> support legacy [plain_text_auth] in credentials file
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18322) Warn about unqualified prepared statement only if it is a select, update, delete, insert
[
https://issues.apache.org/jira/browse/CASSANDRA-18322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845839#comment-17845839
]
Stefan Miklosovic commented on CASSANDRA-18322:
---
Thanks for the approval on the PR, [~blerer] . I think we will get to this
post-5.0 again.
> Warn about unqualified prepared statement only if it is a select, update,
> delete, insert
>
>
> Key: CASSANDRA-18322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18322
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Mohammad Aburadeh
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Hi,
> We get the following warnings when we use prepared statements with "create
> keyspace ... " or "drop keyspace" statements.
> "
> {{USE }} with prepared statements is considered to be an
> anti-pattern due to ambiguity in non-qualified table names. Please consider
> removing instances of {{{}Session#setKeyspace(){}}},
> {{Session#execute("USE ")}} and {{cluster.newSession()}}
> from your code, and always use fully qualified table names (e.g.
> .). Keyspace used: null, statement keyspace: null, statement
> id: 8153d922390fdf9a9963bfeda85b2f3b at
> "
> Such statements are already full-qualified. So, why are we getting this
> warning?
> Regards
> Mohammad
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845735#comment-17845735 ] Stefan Miklosovic edited comment on CASSANDRA-19556 at 5/12/24 5:16 PM: if you all think otherwise then please go to ML and explain your position PLUS please provide the clear guidance how to introduce ddl_enabled rule after alter_table_enabled is in 5.0.0 GA. was (Author: smiklosovic): if you all think otherwise then please go to ML and explain your position PLUS please provide the clear guidance how to introduce ddl_enabled rule after this one is in 5.0.0 GA. > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845734#comment-17845734 ] Stefan Miklosovic edited comment on CASSANDRA-19556 at 5/12/24 5:12 PM: The decision about putting this in 5.0-rc/beta2 was made based on this answer on the ML (1) where Josh said that he would make an exception: _if you could get this patch in before we GA'd, I'd personally support making an exception for it._ Hence I went ahead. I still think that this makes sense to include in 5.0.0 GA. If we do not, then the situation we find ourselves in post GA is that we will have "alter_table_enabled" guardrail in cassandra.yaml and then ... what exactly is the path forward? If we do not do this right now, replacing alter_table_enabled with ddl_enabled, then 5.0.0 will be the only release which will include alter_table_enabled because if ddl_enabled is introduced then alter_table_enabled does not make sense to exist anymore. (Please go over the ML thread and my initial email where I go over all possibilities we have). I would rather not release anything with alter_table_enabled than to make it more problematic / questionable how we are actually going to get rid of it post GA because of backward compatibility etc. It just does not make sense to me to introduce something we know will have little value once it is out and we know we want to replace it. Are we OK to drop a guardrail rule just like that? What is the policy? (1) [https://lists.apache.org/thread/tz2mlzt2pnym2l1kvxgxxkmy65hznywl] was (Author: smiklosovic): The decision about putting this in 5.0-rc/beta2 was made based on this answer on the ML (1) where Josh said that he would make an exception: _if you could get this patch in before we GA'd, I'd personally support making an exception for it._ Hence I went ahead. I still think that this makes sense to include in 5.0.0 GA. If we do not, then the situation we find ourselves in post GA is that we will have "alter_table_enabled" guardrail in cassandra.yaml and then ... what exactly is the path forward? If we do not do this right now, replacing alter_table_enabled with ddl_enabled, then 5.0.0 will be the only release which will include alter_table_enabled because if ddl_enabled is introduced then alter_table_enabled does not make sense to exist anymore. (Please go over the ML thread and my initial email where I go over all possibilities we have). I would rather not release anything with alter_table_enabled than to make it more problematic / questionable how are we actually going to get rid of it post GA because of backward compatibility etc. It just does not make sense to me to introduce something we know will have little value once it is out and we know we want to replace it. Are we OK to drop a guardrail rule just like that? What is the policy? (1) [https://lists.apache.org/thread/tz2mlzt2pnym2l1kvxgxxkmy65hznywl] > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845734#comment-17845734 ] Stefan Miklosovic edited comment on CASSANDRA-19556 at 5/12/24 5:10 PM: The decision about putting this in 5.0-rc/beta2 was made based on this answer on the ML (1) where Josh said that he would make an exception: _if you could get this patch in before we GA'd, I'd personally support making an exception for it._ Hence I went ahead. I still think that this makes sense to include in 5.0.0 GA. If we do not, then the situation we find ourselves in post GA is that we will have "alter_table_enabled" guardrail in cassandra.yaml and then ... what exactly is the path forward? If we do not do this right now, replacing alter_table_enabled with ddl_enabled, then 5.0.0 will be the only release which will include alter_table_enabled because if ddl_enabled is introduced then alter_table_enabled does not make sense to exist anymore. (Please go over the ML thread and my initial email where I go over all possibilities we have). I would rather not release anything with alter_table_enabled than to make it more problematic / questionable how are we actually going to get rid of it post GA because of backward compatibility etc. It just does not make sense to me to introduce something we know will have little value once it is out and we know we want to replace it. Are we OK to drop a guardrail rule just like that? What is the policy? (1) [https://lists.apache.org/thread/tz2mlzt2pnym2l1kvxgxxkmy65hznywl] was (Author: smiklosovic): The decision about putting this in 5.0-rc/beta2 was made based on this answer on the ML (1) where Josh said that he would make an exception: _if you could get this patch in before we GA'd, I'd personally support making an exception for it._ Hence I went ahead. I still think that this makes sense to include in 5.0.0 GA. If we do not, then the situation we find ourselves in post GA is that we will have "alter_table_enabled" guardrail run in cassandra.yaml and then ... what exactly is the path forward? If we do not do this right now, replacing alter_table_enabled with ddl_enabled, then 5.0.0 will be the only release which will include alter_table_enabled because if ddl_enabled is introduced then alter_table_enabled does not make sense to exist anymore. (Please go over the ML thread and my initial email where I go over all possibilities we have). I would rather not release anything with alter_table_enabled than to make it more problematic / questionable how are we actually going to get rid of it post GA because of backward compatibility etc. It just does not make sense to me to introduce something we know will have little value once it is out and we know we want to replace it. Are we OK to drop a guardrail rule just like that? What is the policy? (1) [https://lists.apache.org/thread/tz2mlzt2pnym2l1kvxgxxkmy65hznywl] > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845735#comment-17845735 ] Stefan Miklosovic commented on CASSANDRA-19556: --- if you all think otherwise then please go to ML and explain your position PLUS please provide the clear guidance how to introduce ddl_enabled rule after this one is in 5.0.0 GA. > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845734#comment-17845734 ] Stefan Miklosovic commented on CASSANDRA-19556: --- The decision about putting this in 5.0-rc/beta2 was made based on this answer on the ML (1) where Josh said that he would make an exception: _if you could get this patch in before we GA'd, I'd personally support making an exception for it._ Hence I went ahead. I still think that this makes sense to include in 5.0.0 GA. If we do not, then the situation we find ourselves in post GA is that we will have "alter_table_enabled" guardrail run in cassandra.yaml and then ... what exactly is the path forward? If we do not do this right now, replacing alter_table_enabled with ddl_enabled, then 5.0.0 will be the only release which will include alter_table_enabled because if ddl_enabled is introduced then alter_table_enabled does not make sense to exist anymore. (Please go over the ML thread and my initial email where I go over all possibilities we have). I would rather not release anything with alter_table_enabled than to make it more problematic / questionable how are we actually going to get rid of it post GA because of backward compatibility etc. It just does not make sense to me to introduce something we know will have little value once it is out and we know we want to replace it. Are we OK to drop a guardrail rule just like that? What is the policy? (1) [https://lists.apache.org/thread/tz2mlzt2pnym2l1kvxgxxkmy65hznywl] > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
[ https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845733#comment-17845733 ] Stefan Miklosovic commented on CASSANDRA-19632: --- Well ... I created this ticket to be of type "improvement" and fix versions are 5.0.x and 5.x. I think that says it all. I also wrote: _We should fix this at least in trunk and 5.0 (not critical though)_ Yeah, 5.0 is just nice to have, not critical ... We also do not know how to quantify the improvement. Can we tell for sure what other (significant) performance improvements are out there? I think we were rather "lucky" to hit something like CASSANDRA-19429 but that does not mean that such improvements would be indeed found at other places too. > wrap tracing logs in isTraceEnabled across the codebase > --- > > Key: CASSANDRA-19632 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19632 > Project: Cassandra > Issue Type: Improvement >Reporter: Stefan Miklosovic >Priority: Normal > Fix For: 5.0.x, 5.x > > > Our usage of logger.isTraceEnabled across the codebase is inconsistent. This > would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade] > suggested. > We should fix this at least in trunk and 5.0 (not critical though) and > probably come up with a checkstyle rule to prevent not calling isTraceEnabled > while logging with TRACE level. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19556: -- Summary: Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail (was: Add Guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail) > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19556) Add Guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19556: -- Summary: Add Guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail (was: Guardrail to block DDL/DCL queries) > Add Guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
[ https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19632: -- Fix Version/s: 5.0.x 5.x > wrap tracing logs in isTraceEnabled across the codebase > --- > > Key: CASSANDRA-19632 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19632 > Project: Cassandra > Issue Type: Improvement >Reporter: Stefan Miklosovic >Priority: Normal > Fix For: 5.0.x, 5.x > > > Our usage of logger.isTraceEnabled across the codebase is inconsistent. This > would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade] > suggested. > We should fix this at least in trunk and 5.0 (not critical though) and > probably come up with a checkstyle rule to prevent not calling isTraceEnabled > while logging with TRACE level. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
Stefan Miklosovic created CASSANDRA-19632: - Summary: wrap tracing logs in isTraceEnabled across the codebase Key: CASSANDRA-19632 URL: https://issues.apache.org/jira/browse/CASSANDRA-19632 Project: Cassandra Issue Type: Improvement Reporter: Stefan Miklosovic Our usage of logger.isTraceEnabled across the codebase is inconsistent. This would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade] suggested. We should fix this at least in trunk and 5.0 (not critical though) and probably come up with a checkstyle rule to prevent not calling isTraceEnabled while logging with TRACE level. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19631) Consider autocompletion of in-built functions in CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-19631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19631: -- Description: Why do we not autocomplete native functions in CQLSH shell? I am pretty lost in what functions are there to choose from without consulting the documentation. (was: Why do we not autocomplete native functions in CQLSH shell? I am pretty lost in what functions are there to chose from without consulting the documentation.) > Consider autocompletion of in-built functions in CQLSH > -- > > Key: CASSANDRA-19631 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19631 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Stefan Miklosovic >Priority: Normal > > Why do we not autocomplete native functions in CQLSH shell? I am pretty lost > in what functions are there to choose from without consulting the > documentation. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19631) Consider autocompletion of in-built functions in CQLSH
Stefan Miklosovic created CASSANDRA-19631: - Summary: Consider autocompletion of in-built functions in CQLSH Key: CASSANDRA-19631 URL: https://issues.apache.org/jira/browse/CASSANDRA-19631 Project: Cassandra Issue Type: Improvement Components: CQL/Interpreter Reporter: Stefan Miklosovic Why do we not autocomplete native functions in CQLSH shell? I am pretty lost in what functions are there to chose from without consulting the documentation. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18322) Warn about unqualified prepared statement only if it is a select, update, delete, insert
[
https://issues.apache.org/jira/browse/CASSANDRA-18322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18322:
--
Fix Version/s: 5.0.x
(was: 3.0.x)
(was: 3.11.x)
(was: 4.0.x)
(was: 4.1.x)
> Warn about unqualified prepared statement only if it is a select, update,
> delete, insert
>
>
> Key: CASSANDRA-18322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18322
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Mohammad Aburadeh
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Hi,
> We get the following warnings when we use prepared statements with "create
> keyspace ... " or "drop keyspace" statements.
> "
> {{USE }} with prepared statements is considered to be an
> anti-pattern due to ambiguity in non-qualified table names. Please consider
> removing instances of {{{}Session#setKeyspace(){}}},
> {{Session#execute("USE ")}} and {{cluster.newSession()}}
> from your code, and always use fully qualified table names (e.g.
> .). Keyspace used: null, statement keyspace: null, statement
> id: 8153d922390fdf9a9963bfeda85b2f3b at
> "
> Such statements are already full-qualified. So, why are we getting this
> warning?
> Regards
> Mohammad
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18322) Warn about unqualified prepared statement only if it is a select, update, delete, insert
[
https://issues.apache.org/jira/browse/CASSANDRA-18322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845260#comment-17845260
]
Stefan Miklosovic edited comment on CASSANDRA-18322 at 5/10/24 9:32 AM:
well, thinking about it more, this is actually an improvement rather than a
bug, even less so critical. I moved it to improvement ticket type and lowered
the priority.
was (Author: smiklosovic):
well, thinking about it more, this is actually an improvement rather than a
bug, even less so critical.
> Warn about unqualified prepared statement only if it is a select, update,
> delete, insert
>
>
> Key: CASSANDRA-18322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18322
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Mohammad Aburadeh
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Hi,
> We get the following warnings when we use prepared statements with "create
> keyspace ... " or "drop keyspace" statements.
> "
> {{USE }} with prepared statements is considered to be an
> anti-pattern due to ambiguity in non-qualified table names. Please consider
> removing instances of {{{}Session#setKeyspace(){}}},
> {{Session#execute("USE ")}} and {{cluster.newSession()}}
> from your code, and always use fully qualified table names (e.g.
> .). Keyspace used: null, statement keyspace: null, statement
> id: 8153d922390fdf9a9963bfeda85b2f3b at
> "
> Such statements are already full-qualified. So, why are we getting this
> warning?
> Regards
> Mohammad
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18322) Warn about unqualified prepared statement only if it is a select, update, delete, insert
[
https://issues.apache.org/jira/browse/CASSANDRA-18322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845260#comment-17845260
]
Stefan Miklosovic edited comment on CASSANDRA-18322 at 5/10/24 9:31 AM:
well, thinking about it more, this is actually an improvement rather than a
bug, even less so critical.
was (Author: smiklosovic):
well, thinking about it more, this is actual an improvement rather than a bug,
even less so critical.
> Warn about unqualified prepared statement only if it is a select, update,
> delete, insert
>
>
> Key: CASSANDRA-18322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18322
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Mohammad Aburadeh
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Hi,
> We get the following warnings when we use prepared statements with "create
> keyspace ... " or "drop keyspace" statements.
> "
> {{USE }} with prepared statements is considered to be an
> anti-pattern due to ambiguity in non-qualified table names. Please consider
> removing instances of {{{}Session#setKeyspace(){}}},
> {{Session#execute("USE ")}} and {{cluster.newSession()}}
> from your code, and always use fully qualified table names (e.g.
> .). Keyspace used: null, statement keyspace: null, statement
> id: 8153d922390fdf9a9963bfeda85b2f3b at
> "
> Such statements are already full-qualified. So, why are we getting this
> warning?
> Regards
> Mohammad
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18322) Warn about unqualified prepared statement only if it is a select, update, delete, insert
[
https://issues.apache.org/jira/browse/CASSANDRA-18322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18322:
--
Workflow: Copy of Cassandra Default Workflow (was: Copy of Cassandra Bug
Workflow)
Issue Type: Improvement (was: Bug)
> Warn about unqualified prepared statement only if it is a select, update,
> delete, insert
>
>
> Key: CASSANDRA-18322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18322
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Mohammad Aburadeh
>Assignee: Stefan Miklosovic
>Priority: Urgent
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Hi,
> We get the following warnings when we use prepared statements with "create
> keyspace ... " or "drop keyspace" statements.
> "
> {{USE }} with prepared statements is considered to be an
> anti-pattern due to ambiguity in non-qualified table names. Please consider
> removing instances of {{{}Session#setKeyspace(){}}},
> {{Session#execute("USE ")}} and {{cluster.newSession()}}
> from your code, and always use fully qualified table names (e.g.
> .). Keyspace used: null, statement keyspace: null, statement
> id: 8153d922390fdf9a9963bfeda85b2f3b at
> "
> Such statements are already full-qualified. So, why are we getting this
> warning?
> Regards
> Mohammad
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18322) Warn about unqualified prepared statement only if it is a select, update, delete, insert
[
https://issues.apache.org/jira/browse/CASSANDRA-18322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18322:
--
Priority: Normal (was: Urgent)
> Warn about unqualified prepared statement only if it is a select, update,
> delete, insert
>
>
> Key: CASSANDRA-18322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18322
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Mohammad Aburadeh
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Hi,
> We get the following warnings when we use prepared statements with "create
> keyspace ... " or "drop keyspace" statements.
> "
> {{USE }} with prepared statements is considered to be an
> anti-pattern due to ambiguity in non-qualified table names. Please consider
> removing instances of {{{}Session#setKeyspace(){}}},
> {{Session#execute("USE ")}} and {{cluster.newSession()}}
> from your code, and always use fully qualified table names (e.g.
> .). Keyspace used: null, statement keyspace: null, statement
> id: 8153d922390fdf9a9963bfeda85b2f3b at
> "
> Such statements are already full-qualified. So, why are we getting this
> warning?
> Regards
> Mohammad
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18322) Warn about unqualified prepared statement only if it is a select, update, delete, insert
[
https://issues.apache.org/jira/browse/CASSANDRA-18322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845260#comment-17845260
]
Stefan Miklosovic commented on CASSANDRA-18322:
---
well, thinking about it more, this is actual an improvement rather than a bug,
even less so critical.
> Warn about unqualified prepared statement only if it is a select, update,
> delete, insert
>
>
> Key: CASSANDRA-18322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18322
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Mohammad Aburadeh
>Assignee: Stefan Miklosovic
>Priority: Urgent
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Hi,
> We get the following warnings when we use prepared statements with "create
> keyspace ... " or "drop keyspace" statements.
> "
> {{USE }} with prepared statements is considered to be an
> anti-pattern due to ambiguity in non-qualified table names. Please consider
> removing instances of {{{}Session#setKeyspace(){}}},
> {{Session#execute("USE ")}} and {{cluster.newSession()}}
> from your code, and always use fully qualified table names (e.g.
> .). Keyspace used: null, statement keyspace: null, statement
> id: 8153d922390fdf9a9963bfeda85b2f3b at
> "
> Such statements are already full-qualified. So, why are we getting this
> warning?
> Regards
> Mohammad
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18322) Warn about unqualified prepared statement only if it is a select, update, delete, insert
[
https://issues.apache.org/jira/browse/CASSANDRA-18322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845235#comment-17845235
]
Stefan Miklosovic edited comment on CASSANDRA-18322 at 5/10/24 7:58 AM:
[~blerer] any chance this might appear in 5.0 and trunk only? I just forgot
about this one and we just somehow dropped the ball.
https://github.com/apache/cassandra/pull/2668/files
was (Author: smiklosovic):
[~blerer] any chance this might appear in 5.0+ only? I just forgot about this
one and we just somehow dropped the ball.
https://github.com/apache/cassandra/pull/2668/files
> Warn about unqualified prepared statement only if it is a select, update,
> delete, insert
>
>
> Key: CASSANDRA-18322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18322
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Mohammad Aburadeh
>Assignee: Stefan Miklosovic
>Priority: Urgent
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Hi,
> We get the following warnings when we use prepared statements with "create
> keyspace ... " or "drop keyspace" statements.
> "
> {{USE }} with prepared statements is considered to be an
> anti-pattern due to ambiguity in non-qualified table names. Please consider
> removing instances of {{{}Session#setKeyspace(){}}},
> {{Session#execute("USE ")}} and {{cluster.newSession()}}
> from your code, and always use fully qualified table names (e.g.
> .). Keyspace used: null, statement keyspace: null, statement
> id: 8153d922390fdf9a9963bfeda85b2f3b at
> "
> Such statements are already full-qualified. So, why are we getting this
> warning?
> Regards
> Mohammad
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18322) Warn about unqualified prepared statement only if it is a select, update, delete, insert
[
https://issues.apache.org/jira/browse/CASSANDRA-18322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845235#comment-17845235
]
Stefan Miklosovic edited comment on CASSANDRA-18322 at 5/10/24 7:57 AM:
[~blerer] any chance this might appear in 5.0+ only? I just forgot about this
one and we just somehow dropped the ball.
https://github.com/apache/cassandra/pull/2668/files
was (Author: smiklosovic):
[~blerer] any chance this might appear in 5.0+ only? I just forgot about this
one and we just somehow dropped the ball.
> Warn about unqualified prepared statement only if it is a select, update,
> delete, insert
>
>
> Key: CASSANDRA-18322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18322
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Mohammad Aburadeh
>Assignee: Stefan Miklosovic
>Priority: Urgent
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Hi,
> We get the following warnings when we use prepared statements with "create
> keyspace ... " or "drop keyspace" statements.
> "
> {{USE }} with prepared statements is considered to be an
> anti-pattern due to ambiguity in non-qualified table names. Please consider
> removing instances of {{{}Session#setKeyspace(){}}},
> {{Session#execute("USE ")}} and {{cluster.newSession()}}
> from your code, and always use fully qualified table names (e.g.
> .). Keyspace used: null, statement keyspace: null, statement
> id: 8153d922390fdf9a9963bfeda85b2f3b at
> "
> Such statements are already full-qualified. So, why are we getting this
> warning?
> Regards
> Mohammad
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18322) Warn about unqualified prepared statement only if it is a select, update, delete, insert
[
https://issues.apache.org/jira/browse/CASSANDRA-18322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845235#comment-17845235
]
Stefan Miklosovic commented on CASSANDRA-18322:
---
[~blerer] any chance this might appear in 5.0+ only? I just forgot about this
one and we just somehow dropped the ball.
> Warn about unqualified prepared statement only if it is a select, update,
> delete, insert
>
>
> Key: CASSANDRA-18322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18322
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Mohammad Aburadeh
>Assignee: Stefan Miklosovic
>Priority: Urgent
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Hi,
> We get the following warnings when we use prepared statements with "create
> keyspace ... " or "drop keyspace" statements.
> "
> {{USE }} with prepared statements is considered to be an
> anti-pattern due to ambiguity in non-qualified table names. Please consider
> removing instances of {{{}Session#setKeyspace(){}}},
> {{Session#execute("USE ")}} and {{cluster.newSession()}}
> from your code, and always use fully qualified table names (e.g.
> .). Keyspace used: null, statement keyspace: null, statement
> id: 8153d922390fdf9a9963bfeda85b2f3b at
> "
> Such statements are already full-qualified. So, why are we getting this
> warning?
> Regards
> Mohammad
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18108) Data loss after a system restart of 3.11.17/4.1.4
[
https://issues.apache.org/jira/browse/CASSANDRA-18108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845231#comment-17845231
]
Stefan Miklosovic commented on CASSANDRA-18108:
---
Something very similar is happening in CASSANDRA-18956
> Data loss after a system restart of 3.11.17/4.1.4
> -
>
> Key: CASSANDRA-18108
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18108
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Ke Han
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>
> When we upgrade Cassandra from 3.11.17 to 4.0.12, we found a data loss during
> the upgrade process. This bug can also be triggered if simply performing a
> system restart for 3.11.17, 4.0.12 or 4.1.4.
> h1. Steps to reproduce
> Start a 3.11.15 or 4.1.4 Cassandra node using default configurations. Execute
> the following cqlsh commands.
> {code:java}
> CREATE KEYSPACE ks WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> CREATE TABLE IF NOT EXISTS ks.tb (c1 INT,c3 INT,c2 TEXT, PRIMARY KEY (c1 ))
> WITH speculative_retry = 'ALWAYS';
> INSERT INTO ks.tb (c1, c2) VALUES (2,'val');
> ALTER TABLE ks.tb DROP c2 ;
> ALTER TABLE ks.tb RENAME c1 TO c2; {code}
> Then execute a SELECT command, we get the correct data
> {code:java}
> cqlsh> SELECT * FROM ks.tb;
> c2 | c3
> +--
> 2 | null
> (1 rows){code}
> Flush and stop the Cassandra daemon.
> {code:java}
> bin/nodetool flush
> bin/nodetool stopdaemon{code}
> Then restart the node.
> {code:java}
> bin/cassandra{code}
> Start cqlsh, and execute the same SELECT command. The data in ks.tb is lost.
> {code:java}
> cqlsh> SELECT * FROM ks.tb;
> c2 | c3
> +
> (0 rows){code}
> During the node restart, we found an error log about initializing the table,
> but it didn't prevent the system from starting up.
> {code:java}
> INFO [main] 2022-12-09 21:37:54,234 ColumnFamilyStore.java:432 -
> Initializing ks.tb
> ERROR [SSTableBatchOpen:1] 2022-12-09 21:37:54,237 CassandraDaemon.java:244 -
> Exception in thread Thread[SSTableBatchOpen:1,5,main]
> java.lang.AssertionError: null
> at
> org.apache.cassandra.db.PartitionColumns$Builder.add(PartitionColumns.java:161)
> at
> org.apache.cassandra.db.SerializationHeader$Component.toHeader(SerializationHeader.java:340)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:522)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:385)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader$3.run(SSTableReader.java:570)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:84)
> at java.lang.Thread.run(Thread.java:750) {code}
> This bug can also be triggered if we perform an upgrade (with drain) from
> 3.11.17 to 4.0.12 or 4.1.4 and execute the SELECT command in the new version.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19604) Add support for BETWEEN operator
[
https://issues.apache.org/jira/browse/CASSANDRA-19604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845226#comment-17845226
]
Stefan Miklosovic commented on CASSANDRA-19604:
---
what's the fix version?
> Add support for BETWEEN operator
>
>
> Key: CASSANDRA-19604
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19604
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
>
> CQL support the {{>=}} and {{<=}} but does not support yet the {{BETWEEN}}
> operator. After CASSANDRA-19341 adding new operators should be much simpler
> and safer than it use to be.
> For the scope of this ticket {{BETWEEN}} support should be added for
> {{WHERE}} clauses of {{SELECT}} and {{DELETE}} queries (for single column and
> multi-column restrictions). NOT BETWEEN should be added and should be
> supported everywhere BETWEEN is.
> +Additional information for newcomers:+
> Parts that will need to be modified:
> * {{Lexer.g}} and {{Parser.g}} to add support for the new keyword and syntax
> * The {{Operator.class}} to add the new {{BETWEEN}} operator
> * Unit tests in {{SelectSingleColumnRelationTest}} and
> {{SelectMultiColumnRelationTest}} classes for the different types of columns
> (partition key, clustering, static and regular).
> * CQLSH auto completion in {{cql3handling.py}} and test for it in
> {{test_cqlsh_completion.py}}
> * Update the documentation
> Of course this is just an overview and some other parts might have to be
> changed as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19498) Error reading data from credential file
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845224#comment-17845224
]
Stefan Miklosovic commented on CASSANDRA-19498:
---
[~bschoeni] any progress?
> Error reading data from credential file
> ---
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19556) Guardrail to block DDL/DCL queries
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844930#comment-17844930 ] Stefan Miklosovic commented on CASSANDRA-19556: --- [~jmckenzie] it's yours! > Guardrail to block DDL/DCL queries > -- > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19556) Guardrail to block DDL/DCL queries
[
https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844929#comment-17844929
]
Stefan Miklosovic commented on CASSANDRA-19556:
---
[CASSANDRA-19556-5.0|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19556-5.0]
{noformat}
java11_pre-commit_tests
✓ j11_build7m 58s
✓ j11_cqlsh_dtests_py311 9m 57s
✓ j11_cqlsh_dtests_py311_vnode 9m 36s
✓ j11_cqlsh_dtests_py388m 52s
✓ j11_cqlsh_dtests_py38_vnode 9m 52s
✓ j11_cqlshlib_cython_tests 11m 25s
✓ j11_cqlshlib_tests 9m 39s
✓ j11_dtests 33m 33s
✓ j11_dtests_latest 36m 25s
✓ j11_dtests_vnode35m 29s
✓ j11_jvm_dtests 22m 39s
✓ j11_jvm_dtests_latest_vnode 18m 37s
✓ j11_simulator_dtests10m 28s
✓ j11_unit_tests 15m 33s
✓ j11_unit_tests_repeat 17m 36s
✓ j11_utests_latest 17m 40s
✓ j11_utests_latest_repeat18m 10s
✓ j11_utests_oa 15m 54s
✓ j11_utests_oa_repeat17m 12s
✓ j11_utests_system_keyspace_directory_repeat 15m 18s
✓ j17_cqlsh_dtests_py311 6m 20s
✓ j17_cqlsh_dtests_py311_vnode 6m 24s
✓ j17_cqlsh_dtests_py386m 15s
✓ j17_cqlsh_dtests_py38_vnode 6m 20s
✓ j17_cqlshlib_cython_tests7m 31s
✓ j17_cqlshlib_tests 6m 39s
✓ j17_dtests 32m 52s
✓ j17_dtests_latest33m 8s
✓ j17_dtests_vnode33m 13s
✓ j17_jvm_dtests 21m 57s
✓ j17_jvm_dtests_latest_vnode 17m 5s
✓ j17_unit_tests 14m 28s
✓ j17_unit_tests_repeat 13m 36s
✓ j17_utests_latest17m 3s
✓ j17_utests_latest_repeat13m 55s
✓ j17_utests_oa 19m 44s
✓ j17_utests_oa_repeat13m 18s
✕ j11_utests_system_keyspace_directory15m 11s
org.apache.cassandra.cql3.validation.operations.SelectTest
testCreatingUDFWithSameNameAsBuiltin_PrefersCompatibleArgs
java11_separate_tests
{noformat}
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4298/workflows/efcf5f01-6b32-4ca8-af12-a47f21564e26]
testCreatingUDFWithSameNameAsBuiltin_PrefersCompatibleArgs is just a flake
> Guardrail to block DDL/DCL queries
> --
>
> Key: CASSANDRA-19556
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19556
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Yuqi Yan
>Assignee: Yuqi Yan
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Sometimes we want to block DDL/DCL queries to stop new schemas being created
> or roles created. (e.g. when doing live-upgrade)
> For DDL guardrail current implementation won't block the query if it's no-op
> (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The
> guardrail check is added in apply() right after all the existence check)
> I don't have preference on either block every DDL query or check whether if
> it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS..
> at startup, which is no-op but will be blocked by this guardrail and failed
> to start.
>
> 4.1 PR: [https://github.com/apache/cassandra/pull/3248]
> trunk PR: [https://github.com/apache/cassandra/pull/3275]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19556) Guardrail to block DDL/DCL queries
[
https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844886#comment-17844886
]
Stefan Miklosovic commented on CASSANDRA-19556:
---
Clean java 17 pre-commit on 5.0!
[CASSANDRA-19556-5.0|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19556-5.0]
{noformat}
java17_pre-commit_tests
✓ j17_build3m 55s
✓ j17_cqlsh_dtests_py311 5m 55s
✓ j17_cqlsh_dtests_py311_vnode 6m 31s
✓ j17_cqlsh_dtests_py38 6m 8s
✓ j17_cqlsh_dtests_py38_vnode 6m 33s
✓ j17_cqlshlib_cython_tests9m 51s
✓ j17_cqlshlib_tests 8m 55s
✓ j17_dtests 34m 9s
✓ j17_dtests_latest 33m 21s
✓ j17_dtests_vnode33m 44s
✓ j17_jvm_dtests 22m 21s
✓ j17_jvm_dtests_latest_vnode 16m 56s
✓ j17_unit_tests 15m 5s
✓ j17_unit_tests_repeat14m 6s
✓ j17_utests_latest 13m 52s
✓ j17_utests_latest_repeat15m 14s
✓ j17_utests_oa 13m 52s
✓ j17_utests_oa_repeat13m 30s
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4298/workflows/edba89d8-4d28-4fa9-9e79-1fe9a03275f4]
> Guardrail to block DDL/DCL queries
> --
>
> Key: CASSANDRA-19556
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19556
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Yuqi Yan
>Assignee: Yuqi Yan
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Sometimes we want to block DDL/DCL queries to stop new schemas being created
> or roles created. (e.g. when doing live-upgrade)
> For DDL guardrail current implementation won't block the query if it's no-op
> (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The
> guardrail check is added in apply() right after all the existence check)
> I don't have preference on either block every DDL query or check whether if
> it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS..
> at startup, which is no-op but will be blocked by this guardrail and failed
> to start.
>
> 4.1 PR: [https://github.com/apache/cassandra/pull/3248]
> trunk PR: [https://github.com/apache/cassandra/pull/3275]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
