[jira] [Commented] (CASSANDRA-17116) When zero-copy-streaming sees a channel close this triggers the disk failure policy
[
https://issues.apache.org/jira/browse/CASSANDRA-17116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454294#comment-17454294
]
Francisco Guerrero commented on CASSANDRA-17116:
I took a look at this as well, and it seems that the follower keeps track of
the number of {{RECEIVED}} messages it expects and the number of received
messages it has seen. Only when the follower has seen all the {{RECEIVED}}
messages it expects to see, will the follower initiate the {{COMPLETE}}
message, and close the connections.
It looks like the initiator is sending back the received message before
actually receiving the stream. The code sits in
{{org.apache.cassandra.streaming.StreamSesssion.receive(IncomingStreamMessage)}}.
We can see that the control message is being sent and then the receiver
receives the stream.
A potential solution to the race is delaying the sending of the {{RECEIVED}}
message right after the stream has been consumed (maybe in the finally block of
the {{receive}} method).
Unfortunately, I have not found a good way to reproduce the issue, so I don't
know if that will be sufficient to resolve the race issue. Maybe if [~dcapwell]
can try it, or give me some guidance on how to repro the issue, I can take a
look into it further.
> When zero-copy-streaming sees a channel close this triggers the disk failure
> policy
> ---
>
> Key: CASSANDRA-17116
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17116
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.x
>
>
> Found in CASSANDRA-17085.
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1069/workflows/26b7b83a-686f-4516-a56a-0709d428d4f2/jobs/7264
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1069/workflows/26b7b83a-686f-4516-a56a-0709d428d4f2/jobs/7256
> {code}
> ERROR [Stream-Deserializer-/127.0.0.1:7000-f2eb1a15] 2021-11-02 21:35:40,983
> DefaultFSErrorHandler.java:104 - Exiting forcefully due to file system
> exception on startup, disk failure policy "stop"
> org.apache.cassandra.io.FSWriteError: java.nio.channels.ClosedChannelException
> at
> org.apache.cassandra.io.sstable.format.big.BigTableZeroCopyWriter.write(BigTableZeroCopyWriter.java:227)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableZeroCopyWriter.writeComponent(BigTableZeroCopyWriter.java:206)
> at
> org.apache.cassandra.db.streaming.CassandraEntireSSTableStreamReader.read(CassandraEntireSSTableStreamReader.java:125)
> at
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:84)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:51)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:37)
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:50)
> at
> org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:62)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.nio.channels.ClosedChannelException: null
> at
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:136)
> at
> org.apache.cassandra.net.AsyncStreamingInputPlus.consume(AsyncStreamingInputPlus.java:155)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableZeroCopyWriter.write(BigTableZeroCopyWriter.java:217)
> ... 9 common frames omitted
> {code}
> When bootstrap fails and streaming is closed, this triggers the disk failure
> policy which causes the JVM to halt by default (if this happens outside of
> bootstrap, then we stop transports and keep the JVM up).
> org.apache.cassandra.streaming.StreamDeserializingTask attempts to handle
> this by ignoring this exception, but the call to
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize
> Does try/catch and inspects exception; triggering this condition.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454221#comment-17454221
]
Caleb Rackliffe edited comment on CASSANDRA-15234 at 12/6/21, 11:35 PM:
Note: I think the {{TestClientRequestMetrics}}
[failure|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1239/workflows/d0f8f584-ede1-42f1-96ad-9fbc2d981a56/jobs/7427]
is related to CASSANDRA-17155. With everything rebased, it should wash out. CC
[~yifanc]
was (Author: maedhroz):
Note: I think the {{TestClientRequestMetrics}}
[failure|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1239/workflows/d0f8f584-ede1-42f1-96ad-9fbc2d981a56/jobs/7427]
is related to CASSANDRA-17155. With everything rebased, it should wash out.
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16630) Migrate to JUnit5
[
https://issues.apache.org/jira/browse/CASSANDRA-16630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454281#comment-17454281
]
Brandon Williams commented on CASSANDRA-16630:
--
Ah yes, back when it used Whirr, so long ago that the project has retired. I
agree it's probably to prevent shared state issues (which we still battle some
today) but we can try removing it. Ultimately it would be nice to have those
tests written such that it's not necessary.
> Migrate to JUnit5
> -
>
> Key: CASSANDRA-16630
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16630
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Low
> Time Spent: 20m
> Remaining Estimate: 0h
>
> h3. Overview
> Currently C* uses JUnit4 (version 4.12) which is obsolete. There is a newer
> version 4.13.2 which we could update to. However, JUnit4 is generally
> considered to be outdated and it is reasonable to migrate to JUnit5.
> Despite of having a syntax sugar in JUnit5 (assertThrow, lamda's support,
> ect), there are no blockers that push us to move from JUnit4. The main
> motivation for this initiative is rule of thumb to use up-to-date versions of
> the dependencies.
> Obviously this change is not backward compatible with the open PRs and
> previous C* versions. Therefore, it will require an additional effort for
> backporting the changes and updating PRs that have tests. However, I believe
> it should not be a blocker for this initiative.
> h3. Scope (preliminary list)
> # change JUnit4 to JUnit5 dependencies and make necessary changes in ant
> tasks (https://ant.apache.org/manual/Tasks/junitlauncher.html)
> # update syntax in all tests (imports, Before/After annotations, etc)
> # update parameterized tests
> # create a new version of {{OrderedJUnit4ClassRunner}} and update
> corresponding tests
> # update tests that use {{BMUnitRunner}} (as per
> https://developer.jboss.org/docs/DOC-52953 it supports JUnit5)
> # update tests with {{@Rule}}
> # update tests with expected exceptions
> # update {{JStackJUnitTask}}
> # update formatters
> # create a separate ticket to migrate to {{ant-junitlauncher-1.10.11}} (once
> it is released) and simplify {{JStackJUnitTask}} after
> https://github.com/apache/ant/pull/147
> h3. Order of operations
> In order to make the transition more smooth we want to use a phased approach:
> # migrate to JUnit5 with [Vintage
> Engine|https://junit.org/junit5/docs/current/user-guide/#dependency-metadata-junit-vintage],
> so all JUnit4 tests work as is
> # update tests in a few bunches (to not have a huge single PR with numerous
> conflicts)
> # disable (remove dependency) Vintage Engine, so only JUnit5 tests work
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16630) Migrate to JUnit5
[
https://issues.apache.org/jira/browse/CASSANDRA-16630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454255#comment-17454255
]
Ekaterina Dimitrova commented on CASSANDRA-16630:
-
Should we update still JUnit 4 to last version? if we keep on using it in time
with old tests, I have to check the differences between the current version and
the last one.
{quote}As per my understanding these changes in the output format should affect
nothing, but your expertise here would be very helpful.
{quote}
I am also not aware of any issues with that, let's see if [~mck] has something
in mind.
{quote}The newer _ant-junitlauncher_ version does not have necessary filtering
capabilities. I gave a try in writing this logic manually, but it seems to be
clunky and not very accurate. I can invest more time, but I'm not sure that
full traces is a problem since we do not expect many failed tests, so it won't
pollute our logs.
{quote}
We all hope for not many failures :D
{quote}Please, review the above output diffs for the XML formatter and let me
know if you believe any of the changes may affect current pipeline (I'd be very
grateful if you could comment on every point). Even though I'm able to fix all
diffs (some would be hard but doable) and keep exactly the same format as for
JUnit 4, I do want to minimize customizations and stick to the default JUnit 5
format where possible.
{quote}
Sounds reasonable but I want to spend a bit more time on those formatters
before making any conclusions.
{quote}In the meantime I double checked the source of _cql-test_ and
_cql-test-some_ targets. They were introduced as a part of CASSANDRA-7248.
Looks like that was done just for convenience and it probably made sense then.
Now these target do not seem to be useful, so I'm going to remove them.
{quote}
Sounds reasonable to me.
{quote} Is there any particular reason why some tests require "perTest" mode? I
believe it just helps to prevent any issues with shared state (configs,
statics, system properties, etc).
{quote}
I think the same but I see perTest was introduced 10 years ago in
CASSANDRA-1859,
[~brandon.williams] was a reviewer, he has sharp memory, maybe he remembers
something different? :)
> Migrate to JUnit5
> -
>
> Key: CASSANDRA-16630
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16630
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Low
> Time Spent: 20m
> Remaining Estimate: 0h
>
> h3. Overview
> Currently C* uses JUnit4 (version 4.12) which is obsolete. There is a newer
> version 4.13.2 which we could update to. However, JUnit4 is generally
> considered to be outdated and it is reasonable to migrate to JUnit5.
> Despite of having a syntax sugar in JUnit5 (assertThrow, lamda's support,
> ect), there are no blockers that push us to move from JUnit4. The main
> motivation for this initiative is rule of thumb to use up-to-date versions of
> the dependencies.
> Obviously this change is not backward compatible with the open PRs and
> previous C* versions. Therefore, it will require an additional effort for
> backporting the changes and updating PRs that have tests. However, I believe
> it should not be a blocker for this initiative.
> h3. Scope (preliminary list)
> # change JUnit4 to JUnit5 dependencies and make necessary changes in ant
> tasks (https://ant.apache.org/manual/Tasks/junitlauncher.html)
> # update syntax in all tests (imports, Before/After annotations, etc)
> # update parameterized tests
> # create a new version of {{OrderedJUnit4ClassRunner}} and update
> corresponding tests
> # update tests that use {{BMUnitRunner}} (as per
> https://developer.jboss.org/docs/DOC-52953 it supports JUnit5)
> # update tests with {{@Rule}}
> # update tests with expected exceptions
> # update {{JStackJUnitTask}}
> # update formatters
> # create a separate ticket to migrate to {{ant-junitlauncher-1.10.11}} (once
> it is released) and simplify {{JStackJUnitTask}} after
> https://github.com/apache/ant/pull/147
> h3. Order of operations
> In order to make the transition more smooth we want to use a phased approach:
> # migrate to JUnit5 with [Vintage
> Engine|https://junit.org/junit5/docs/current/user-guide/#dependency-metadata-junit-vintage],
> so all JUnit4 tests work as is
> # update tests in a few bunches (to not have a huge single PR with numerous
> conflicts)
> # disable (remove dependency) Vintage Engine, so only JUnit5 tests work
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16436) Add startup check for large read_ahead_kb setting
[
https://issues.apache.org/jira/browse/CASSANDRA-16436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454230#comment-17454230
]
Paulo Motta commented on CASSANDRA-16436:
-
Thanks for your patch [~subkanthi]. Added review on PR.
> Add startup check for large read_ahead_kb setting
> -
>
> Key: CASSANDRA-16436
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16436
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Startup and Shutdown
>Reporter: Paulo Motta
>Assignee: Kanthi Subramanian
>Priority: Normal
> Labels: AdventCalendar2021, lhf
>
> A well known production tuning recommendation is to dial back the
> {{read_ahead_kb}} Linux setting from the default of 4096 in most
> distributions as this can cause high IO usage and cache churn on
> read-intensive workloads.
> We should add a startup warning to detect when a high {{read_ahead_kb}} is
> used and recommend the user to dial back to a reasonable value, which varies
> according to the workload but a general guideline is to tune this to 8kb.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16436) Add startup check for large read_ahead_kb setting
[
https://issues.apache.org/jira/browse/CASSANDRA-16436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-16436:
Status: Open (was: Patch Available)
> Add startup check for large read_ahead_kb setting
> -
>
> Key: CASSANDRA-16436
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16436
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Startup and Shutdown
>Reporter: Paulo Motta
>Assignee: Kanthi Subramanian
>Priority: Normal
> Labels: AdventCalendar2021, lhf
>
> A well known production tuning recommendation is to dial back the
> {{read_ahead_kb}} Linux setting from the default of 4096 in most
> distributions as this can cause high IO usage and cache churn on
> read-intensive workloads.
> We should add a startup warning to detect when a high {{read_ahead_kb}} is
> used and recommend the user to dial back to a reasonable value, which varies
> according to the workload but a general guideline is to tune this to 8kb.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16436) Add startup check for large read_ahead_kb setting
[
https://issues.apache.org/jira/browse/CASSANDRA-16436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-16436:
Reviewers: Paulo Motta
> Add startup check for large read_ahead_kb setting
> -
>
> Key: CASSANDRA-16436
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16436
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Startup and Shutdown
>Reporter: Paulo Motta
>Assignee: Kanthi Subramanian
>Priority: Normal
> Labels: AdventCalendar2021, lhf
>
> A well known production tuning recommendation is to dial back the
> {{read_ahead_kb}} Linux setting from the default of 4096 in most
> distributions as this can cause high IO usage and cache churn on
> read-intensive workloads.
> We should add a startup warning to detect when a high {{read_ahead_kb}} is
> used and recommend the user to dial back to a reasonable value, which varies
> according to the workload but a general guideline is to tune this to 8kb.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454221#comment-17454221
]
Caleb Rackliffe commented on CASSANDRA-15234:
-
Note: I think the {{TestClientRequestMetrics}}
[failure|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1239/workflows/d0f8f584-ede1-42f1-96ad-9fbc2d981a56/jobs/7427]
is related to CASSANDRA-17155. With everything rebased, it should wash out.
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17136) FQL: Enabling via nodetool can trigger disk_failure_mode
[
https://issues.apache.org/jira/browse/CASSANDRA-17136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454201#comment-17454201
]
Brandon Williams edited comment on CASSANDRA-17136 at 12/6/21, 7:24 PM:
We can't reproduce exactly the same error without being able to become another
unix user, but I added a dtest
[here:https://github.com/driftx/cassandra-dtest/tree/CASSANDRA-17136] that
reproduces the NPE by reducing permissions.
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1309/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1309/pipeline]
was (Author: brandon.williams):
We can't reproduce exactly the same error without being able to become another
unix user, but I added a dtest
[here:https://github.com/driftx/cassandra-dtest/tree/CASSANDRA-17136] that
reproduces the NPE by reducing permissions.
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1308/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1308/pipeline]
> FQL: Enabling via nodetool can trigger disk_failure_mode
>
>
> Key: CASSANDRA-17136
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17136
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/fql
>Reporter: Brendan Cicchi
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x
>
>
> When enabling fullquerylog via nodetool, if there is a non empty directory
> present under the location specified via --path which would trigger an
> java.nio.file.AccessDeniedException during cleaning, the node will trigger
> the disk_failure_policy which by default is stop. This is a fairly easy way
> to offline a cluster if someone executes this in parallel. I don't that think
> the behavior is desirable for enabling via nodetool.
>
> Repro (1 node cluster already up):
> {code:bash}
> mkdir /some/path/dir
> touch /some/path/dir/file
> chown -R user: /some/path/dir # Non Cassandra process user
> chmod 700 /some/path/dir
> nodetool enablefullquerylog --path /some/path
> {code}
> Nodetool will give back this error:
> {code:java}
> error: /some/path/dir/file
> -- StackTrace --
> java.nio.file.AccessDeniedException: /some/path/dir/file
> at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> at
> sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:244)
> at
> sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
> at java.nio.file.Files.delete(Files.java:1126)
> at
> org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:250)
> at
> org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:237)
> at
> org.apache.cassandra.utils.binlog.BinLog.deleteRecursively(BinLog.java:492)
> at
> org.apache.cassandra.utils.binlog.BinLog.cleanDirectory(BinLog.java:477)
> at
> org.apache.cassandra.utils.binlog.BinLog$Builder.build(BinLog.java:436)
> at
> org.apache.cassandra.fql.FullQueryLogger.enable(FullQueryLogger.java:106)
> at
> org.apache.cassandra.service.StorageService.enableFullQueryLogger(StorageService.java:5915)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:276)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at
>
[jira] [Commented] (CASSANDRA-17042) Avoid sstable corruption when upgrading from 4.0-rc1 to 4.0.0
[
https://issues.apache.org/jira/browse/CASSANDRA-17042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454203#comment-17454203
]
Caleb Rackliffe commented on CASSANDRA-17042:
-
+1
Other than the TODO in {{RepairStreamingUpgradeTest}}, which you've already
mentioned above, there's a reference to {{4.0.0.35}} I suppose we should clean
up in {{EntireSSTableStreamConcurrentComponentMutationTest}}.
> Avoid sstable corruption when upgrading from 4.0-rc1 to 4.0.0
> -
>
> Key: CASSANDRA-17042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17042
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming, Local/SSTable
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> 4.0-rc2 introduced a new sstable version ({{-nb-}}), adding a field in
> {{StatsMetadata}}. When zero copy streaming a file from 4.0-rc2+ to 4.0-rc1,
> the rc1 node will write it as an {{-nb-}} file, mutate the metadata to clear
> repairedAt/level information from StatsMetadata and rewrite the file, keeping
> the same file name. Problem is that since rc1 doesn't know about the new
> field in StatsMetadata, it will write the file without the new StatsMetadata
> field, but with an {{-nb-}} filename. Then, when upgrading this node to rc2+
> we will try to read it as a {{-nb-}} file, but will get {{EOFException}}
> since it doesn't contain the new field.
> We should make sure that we never do zero-copy streaming to nodes that don't
> know about the file version.
> The corrupt sstables can be fixed by simply renaming all components of it to
> {{-na-}} from {{-nb-}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17136) FQL: Enabling via nodetool can trigger disk_failure_mode
[
https://issues.apache.org/jira/browse/CASSANDRA-17136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454201#comment-17454201
]
Brandon Williams commented on CASSANDRA-17136:
--
We can't reproduce exactly the same error without being able to become another
unix user, but I added a dtest
[here:https://github.com/driftx/cassandra-dtest/tree/CASSANDRA-17136] that
reproduces the NPE by reducing permissions.
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1308/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1308/pipeline]
> FQL: Enabling via nodetool can trigger disk_failure_mode
>
>
> Key: CASSANDRA-17136
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17136
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/fql
>Reporter: Brendan Cicchi
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x
>
>
> When enabling fullquerylog via nodetool, if there is a non empty directory
> present under the location specified via --path which would trigger an
> java.nio.file.AccessDeniedException during cleaning, the node will trigger
> the disk_failure_policy which by default is stop. This is a fairly easy way
> to offline a cluster if someone executes this in parallel. I don't that think
> the behavior is desirable for enabling via nodetool.
>
> Repro (1 node cluster already up):
> {code:bash}
> mkdir /some/path/dir
> touch /some/path/dir/file
> chown -R user: /some/path/dir # Non Cassandra process user
> chmod 700 /some/path/dir
> nodetool enablefullquerylog --path /some/path
> {code}
> Nodetool will give back this error:
> {code:java}
> error: /some/path/dir/file
> -- StackTrace --
> java.nio.file.AccessDeniedException: /some/path/dir/file
> at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> at
> sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:244)
> at
> sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
> at java.nio.file.Files.delete(Files.java:1126)
> at
> org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:250)
> at
> org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:237)
> at
> org.apache.cassandra.utils.binlog.BinLog.deleteRecursively(BinLog.java:492)
> at
> org.apache.cassandra.utils.binlog.BinLog.cleanDirectory(BinLog.java:477)
> at
> org.apache.cassandra.utils.binlog.BinLog$Builder.build(BinLog.java:436)
> at
> org.apache.cassandra.fql.FullQueryLogger.enable(FullQueryLogger.java:106)
> at
> org.apache.cassandra.service.StorageService.enableFullQueryLogger(StorageService.java:5915)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:276)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1468)
> at
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
> at
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1309)
> at
>
[jira] [Comment Edited] (CASSANDRA-17042) Avoid sstable corruption when upgrading from 4.0-rc1 to 4.0.0
[
https://issues.apache.org/jira/browse/CASSANDRA-17042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454188#comment-17454188
]
Caleb Rackliffe edited comment on CASSANDRA-17042 at 12/6/21, 6:57 PM:
---
Note: A rebase to {{cassandra-4.0}} should pick up CASSANDRA-17119, which fixes
a failure in the run above.
was (Author: maedhroz):
Note: A rebase would pick up CASSANDRA-17119, which is failing in the run above.
> Avoid sstable corruption when upgrading from 4.0-rc1 to 4.0.0
> -
>
> Key: CASSANDRA-17042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17042
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming, Local/SSTable
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> 4.0-rc2 introduced a new sstable version ({{-nb-}}), adding a field in
> {{StatsMetadata}}. When zero copy streaming a file from 4.0-rc2+ to 4.0-rc1,
> the rc1 node will write it as an {{-nb-}} file, mutate the metadata to clear
> repairedAt/level information from StatsMetadata and rewrite the file, keeping
> the same file name. Problem is that since rc1 doesn't know about the new
> field in StatsMetadata, it will write the file without the new StatsMetadata
> field, but with an {{-nb-}} filename. Then, when upgrading this node to rc2+
> we will try to read it as a {{-nb-}} file, but will get {{EOFException}}
> since it doesn't contain the new field.
> We should make sure that we never do zero-copy streaming to nodes that don't
> know about the file version.
> The corrupt sstables can be fixed by simply renaming all components of it to
> {{-na-}} from {{-nb-}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17042) Avoid sstable corruption when upgrading from 4.0-rc1 to 4.0.0
[
https://issues.apache.org/jira/browse/CASSANDRA-17042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454188#comment-17454188
]
Caleb Rackliffe commented on CASSANDRA-17042:
-
Note: A rebase would pick up CASSANDRA-17119, which is failing in the run above.
> Avoid sstable corruption when upgrading from 4.0-rc1 to 4.0.0
> -
>
> Key: CASSANDRA-17042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17042
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming, Local/SSTable
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> 4.0-rc2 introduced a new sstable version ({{-nb-}}), adding a field in
> {{StatsMetadata}}. When zero copy streaming a file from 4.0-rc2+ to 4.0-rc1,
> the rc1 node will write it as an {{-nb-}} file, mutate the metadata to clear
> repairedAt/level information from StatsMetadata and rewrite the file, keeping
> the same file name. Problem is that since rc1 doesn't know about the new
> field in StatsMetadata, it will write the file without the new StatsMetadata
> field, but with an {{-nb-}} filename. Then, when upgrading this node to rc2+
> we will try to read it as a {{-nb-}} file, but will get {{EOFException}}
> since it doesn't contain the new field.
> We should make sure that we never do zero-copy streaming to nodes that don't
> know about the file version.
> The corrupt sstables can be fixed by simply renaming all components of it to
> {{-na-}} from {{-nb-}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17195) Migrate thresholds for number of keyspaces and tables to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña reassigned CASSANDRA-17195:
-
Assignee: Andres de la Peña
> Migrate thresholds for number of keyspaces and tables to guardrails
> ---
>
> Key: CASSANDRA-17195
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17195
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> Migrate the existing thresholds for the number of keyspaces and tables:
> {code}
> # table_count_warn_threshold: 150
> # keyspace_count_warn_threshold: 40
> {code}
> to a new guardrail under the guardrails section, for example:
> {code}
> guardrails:
> keyspaces:
> warn_threshold: 40
> abort_threshold: -1
> tables:
> warn_threshold: 150
> abort_threshold: -1
> {code}
> Please note that CASSANDRA-17147 has already added a guardrail for the number
> of tables, but the previous not-guardrail threshold for warning about the
> number of tables still exists.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17197) Diagnostic events for guardrails
Andres de la Peña created CASSANDRA-17197: - Summary: Diagnostic events for guardrails Key: CASSANDRA-17197 URL: https://issues.apache.org/jira/browse/CASSANDRA-17197 Project: Cassandra Issue Type: New Feature Components: Feature/Guardrails Reporter: Andres de la Peña Add diagnostic events for guardrails, so we can monitor when each type of guardrail is triggered. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17196) Migrate thresholds for GC pauses to guardrails
Andres de la Peña created CASSANDRA-17196:
-
Summary: Migrate thresholds for GC pauses to guardrails
Key: CASSANDRA-17196
URL: https://issues.apache.org/jira/browse/CASSANDRA-17196
Project: Cassandra
Issue Type: New Feature
Components: Feature/Guardrails
Reporter: Andres de la Peña
Migrate the existing thresholds for GC pauses:
{code}
# gc_log_threshold_in_ms: 200
# gc_warn_threshold_in_ms: 1000
{code}
to a new guardrail under the guardrails section, for example:
{code}
guardrails:
...
gc_pauses:
log_threshold_in_ms: 200
warn_threshold_in_ms: 200
{code}
Note that currently {{Threshold}} guardrails only have warn/abort threshold
values, so we should consider adding a new {{log}} threshold value if we want
to preserve the log-only functionality for this particular case.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17195) Migrate thresholds for number of keyspaces and tables to guardrails
Andres de la Peña created CASSANDRA-17195:
-
Summary: Migrate thresholds for number of keyspaces and tables to
guardrails
Key: CASSANDRA-17195
URL: https://issues.apache.org/jira/browse/CASSANDRA-17195
Project: Cassandra
Issue Type: New Feature
Components: Feature/Guardrails
Reporter: Andres de la Peña
Migrate the existing thresholds for the number of keyspaces and tables:
{code}
# table_count_warn_threshold: 150
# keyspace_count_warn_threshold: 40
{code}
to a new guardrail under the guardrails section, for example:
{code}
guardrails:
keyspaces:
warn_threshold: 40
abort_threshold: -1
tables:
warn_threshold: 150
abort_threshold: -1
{code}
Please note that CASSANDRA-17147 has already added a guardrail for the number
of tables, but the previous not-guardrail threshold for warning about the
number of tables still exists.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17042) Avoid sstable corruption when upgrading from 4.0-rc1 to 4.0.0
[
https://issues.apache.org/jira/browse/CASSANDRA-17042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17042:
Reviewers: Caleb Rackliffe, Caleb Rackliffe
Caleb Rackliffe, Caleb Rackliffe (was: Caleb Rackliffe)
Status: Review In Progress (was: Patch Available)
> Avoid sstable corruption when upgrading from 4.0-rc1 to 4.0.0
> -
>
> Key: CASSANDRA-17042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17042
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming, Local/SSTable
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> 4.0-rc2 introduced a new sstable version ({{-nb-}}), adding a field in
> {{StatsMetadata}}. When zero copy streaming a file from 4.0-rc2+ to 4.0-rc1,
> the rc1 node will write it as an {{-nb-}} file, mutate the metadata to clear
> repairedAt/level information from StatsMetadata and rewrite the file, keeping
> the same file name. Problem is that since rc1 doesn't know about the new
> field in StatsMetadata, it will write the file without the new StatsMetadata
> field, but with an {{-nb-}} filename. Then, when upgrading this node to rc2+
> we will try to read it as a {{-nb-}} file, but will get {{EOFException}}
> since it doesn't contain the new field.
> We should make sure that we never do zero-copy streaming to nodes that don't
> know about the file version.
> The corrupt sstables can be fixed by simply renaming all components of it to
> {{-na-}} from {{-nb-}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17194) Migrate thresholds for compaction to guardrails
Andres de la Peña created CASSANDRA-17194:
-
Summary: Migrate thresholds for compaction to guardrails
Key: CASSANDRA-17194
URL: https://issues.apache.org/jira/browse/CASSANDRA-17194
Project: Cassandra
Issue Type: New Feature
Components: Feature/Guardrails
Reporter: Andres de la Peña
Migrate the existing thresholds for replica filtering protection:
{code:java}
compaction_large_partition_warning_threshold_mb: 100
compaction_tombstone_warning_threshold: 10
{code}
To a new guardrail under the {{guardrails}} section, for example:
{code:java}
guardrails:
...
compacted_partition_size_warn_threshold_mb: 100
compacted_partition_tombstone_warn_threshold: 10
{code}
Or maybe:
{code:java}
guardrails:
...
compacted_partition_size:
warn_threshold_mb: 100
compacted_partition_tombstones:
warn_threshold: 10
{code}
Note that since these guardrails would be attached to a background process
there wouldn't be abort/fail thresholds because we don't want to stop
compaction.
At the moment these thresholds are enabled by default, while guardrails are
globally disabled by default, so we should consider whether we want to globally
enable guardrails, or change these thresholds to disabled by default, or don't
migrate the thresholds.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17193) Migrate thresholds for logged/unlogged batches to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17193:
--
Summary: Migrate thresholds for logged/unlogged batches to guardrails
(was: Migrate threshold for logged/unlogged batches to guardrails)
> Migrate thresholds for logged/unlogged batches to guardrails
>
>
> Key: CASSANDRA-17193
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17193
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
>
> Migrate the existing thresholds for logged/unlogged batches:
> {code}
> batch_size_warn_threshold_in_kb: 5
> batch_size_fail_threshold_in_kb: 50
> unlogged_batch_across_partitions_warn_threshold: 10
> {code}
> To a pair of new guardrails under the guardrails section, for example:
> {code}
> guardrails:
> ...
> batch_size:
> warn_threshold_in_kb: 5
> abort_threshold_in_kb: 50
> unlogged_batch_across_partitions:
> warn_threshold: 10
> {code}
> At the moment these thresholds are enabled by default, while guardrails are
> globally disabled by default, so we should consider whether we want to
> globally enable guardrails, or change these thresholds to disabled by
> default, or don't migrate the thresholds.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17193) Migrate threshold for logged/unlogged batches to guardrails
Andres de la Peña created CASSANDRA-17193:
-
Summary: Migrate threshold for logged/unlogged batches to
guardrails
Key: CASSANDRA-17193
URL: https://issues.apache.org/jira/browse/CASSANDRA-17193
Project: Cassandra
Issue Type: New Feature
Components: Feature/Guardrails
Reporter: Andres de la Peña
Migrate the existing thresholds for logged/unlogged batches:
{code}
batch_size_warn_threshold_in_kb: 5
batch_size_fail_threshold_in_kb: 50
unlogged_batch_across_partitions_warn_threshold: 10
{code}
To a pair of new guardrails under the guardrails section, for example:
{code}
guardrails:
...
batch_size:
warn_threshold_in_kb: 5
abort_threshold_in_kb: 50
unlogged_batch_across_partitions:
warn_threshold: 10
{code}
At the moment these thresholds are enabled by default, while guardrails are
globally disabled by default, so we should consider whether we want to globally
enable guardrails, or change these thresholds to disabled by default, or don't
migrate the thresholds.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17191) Migrate thresholds for scanned tombstones to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17191:
--
Description:
Migrate the two existing thresholds for scanned tombstones:
{code:java}
tombstone_warn_threshold: 1000
tombstone_failure_threshold: 10
{code}
to a new guardrail under the {{guardrails}} section, for example:
{code:java}
guardrails:
...
# Guardrail to warn or abort when reading more tombstones than threshold.
scanned_tombstones:
warn_threshold: 1000
abort_threshold: 10 {code}
At the moment these thresholds are enabled by default, while guardrails are
globally disabled by default, so we should consider whether we want to globally
enable guardrails, or change these thresholds to disabled by default, or don't
migrate the thresholds.
was:
Migrate the two thresholds for scanned tombstones
({{{}tombstone_warn_threshold{}}} and {{{}tombstone_failure_threshold{}}}) to a
new guardrail, for example:
{code:java}
guardrails:
...
# Guardrail to warn or abort when reading more tombstones than threshold.
# The two thresholds default to -1 to disable.
scanned_tombstones:
warn_threshold: -1
abort_threshold: -1
{code}
> Migrate thresholds for scanned tombstones to guardrails
> ---
>
> Key: CASSANDRA-17191
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17191
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
>
> Migrate the two existing thresholds for scanned tombstones:
> {code:java}
> tombstone_warn_threshold: 1000
> tombstone_failure_threshold: 10
> {code}
> to a new guardrail under the {{guardrails}} section, for example:
> {code:java}
> guardrails:
> ...
> # Guardrail to warn or abort when reading more tombstones than threshold.
> scanned_tombstones:
> warn_threshold: 1000
> abort_threshold: 10 {code}
> At the moment these thresholds are enabled by default, while guardrails are
> globally disabled by default, so we should consider whether we want to
> globally enable guardrails, or change these thresholds to disabled by
> default, or don't migrate the thresholds.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17192) Migrate the thresholds for RFP cached rows to guardrails
Andres de la Peña created CASSANDRA-17192:
-
Summary: Migrate the thresholds for RFP cached rows to guardrails
Key: CASSANDRA-17192
URL: https://issues.apache.org/jira/browse/CASSANDRA-17192
Project: Cassandra
Issue Type: New Feature
Components: Feature/Guardrails
Reporter: Andres de la Peña
Migrate the existing thresholds for replica filtering protection:
{code}
replica_filtering_protection:
cached_rows_warn_threshold: 2000
cached_rows_fail_threshold: 32000
{code}
To a new guardrail under the {{guardrails}} section, for example:
{code}
guardrails:
...
replica_filtering_protection_cached_rows:
warn_threshold: 2000
abort_threshold: 32000
{code}
At the moment these thresholds are enabled by default, while guardrails are
globally disabled by default, so we should consider whether we want to globally
enable guardrails, or change these thresholds to disabled by default, or don't
migrate the thresholds.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17191) Migrate thresholds for scanned tombstones to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17191:
--
Description:
Migrate the two thresholds for scanned tombstones
({{{}tombstone_warn_threshold{}}} and {{{}tombstone_failure_threshold{}}}) to a
new guardrail, for example:
{code:java}
guardrails:
...
# Guardrail to warn or abort when reading more tombstones than threshold.
# The two thresholds default to -1 to disable.
scanned_tombstones:
warn_threshold: -1
abort_threshold: -1
{code}
was:
Add guardrail for limiting the number of read tombstones during a query, for
example:
{code}
# Guardrail to warn or abort when reading more tombstones than threshold.
# The two thresholds default to -1 to disable.
scanned_tombstones:
warn_threshold: -1
abort_threshold: -1
{code}
Summary: Migrate thresholds for scanned tombstones to guardrails (was:
Guardrail for scanned tombstones)
> Migrate thresholds for scanned tombstones to guardrails
> ---
>
> Key: CASSANDRA-17191
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17191
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
>
> Migrate the two thresholds for scanned tombstones
> ({{{}tombstone_warn_threshold{}}} and {{{}tombstone_failure_threshold{}}}) to
> a new guardrail, for example:
> {code:java}
> guardrails:
> ...
> # Guardrail to warn or abort when reading more tombstones than threshold.
> # The two thresholds default to -1 to disable.
> scanned_tombstones:
> warn_threshold: -1
> abort_threshold: -1
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14898) Key cache loading is very slow when there are many SSTables
[
https://issues.apache.org/jira/browse/CASSANDRA-14898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454128#comment-17454128
]
Joey Lynch edited comment on CASSANDRA-14898 at 12/6/21, 4:48 PM:
--
Also lg2m, let's iron out the configuration name since that's a public
interface but I think the rest of the feedback is straightforward.
in-jvm dtest flakes seem unrelated to me
was (Author: jolynch):
Also lg2m, let's iron out the configuration name since that's a public
interface but I think the rest of the feedback is straightforward.
Test flakes seem unrelated to me
> Key cache loading is very slow when there are many SSTables
> ---
>
> Key: CASSANDRA-14898
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14898
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
> Environment: AWS i3.2xlarge, 4 physical cores (8 threads), 60GB of
> RAM, loading about 8MB of KeyCache with 10k keys in it.
>Reporter: Joey Lynch
>Assignee: Venkata Harikrishna Nukala
>Priority: Low
> Labels: Performance, low-hanging-fruit
> Attachments: key_cache_load_slow.svg
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> While dealing with a production issue today where some 3.0.17 nodes had close
> to ~8k sstables on disk due to excessive write pressure, we had a few nodes
> crash due to OOM and then they took close to 17 minutes to load the key cache
> and recover. This excessive key cache load significantly increased the
> duration of the outage (to mitigate we just removed the saved key cache
> files). For example here is one example taking 17 minutes to load 10k keys,
> or about 10 keys per second (which is ... very slow):
> {noformat}
> INFO [pool-3-thread-1] 2018-11-15 21:50:21,885 AutoSavingCache.java:190 -
> reading saved cache /mnt/data/cassandra/saved_caches/KeyCache-d.db
> INFO [pool-3-thread-1] 2018-11-15 22:07:16,490 AutoSavingCache.java:166 -
> Completed loading (1014606 ms; 10103 keys) KeyCache cache
> {noformat}
> I've witnessed similar behavior in the past with large LCS clusters, and
> indeed it appears that any time the number of sstables is large, KeyCache
> loading takes a _really_ long time. Today I got a flame graph and I believe
> that I found the issue and I think it's reasonably easy to fix. From what I
> can tell the {{KeyCacheSerializer::deserialize}} [method
> |https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/service/CacheService.java#L445]
> which is called for every key is linear in the number of sstables due to the
> [call|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/service/CacheService.java#L459]
> to {{ColumnFamilyStore::getSSTables}} which ends up calling {{View::select}}
> [here|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/db/lifecycle/View.java#L139].
> The {{View::select}} call is linear in the number of sstables and causes a
> _lot_ of {{HashSet}}
> [resizing|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/db/lifecycle/View.java#L139]
> when the number of sstables is much greater than 16 (the default size of the
> backing {{HashMap}}).
> As we see in the attached flamegraph we spend 50% of our CPU time in these
> {{getSSTable}} calls, of which 36% is spent adding sstables to the HashSet in
> {{View::select}} and 17% is spent just iterating the sstables in the first
> place. A full 16% of CPU time is spent _just resizing the HashMap_. Then
> another 4% is spend calling {{CacheService::findDesc}} which does [a linear
> search|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/service/CacheService.java#L475]
> for the sstable generation.
> I believe that this affects at least Cassandra 3.0.17 and trunk, and could be
> pretty easily fixed by either caching the getSSTables call or at the very
> least pre-sizing the {{HashSet}} in {{View::select}} to be the size of the
> sstables map.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14898) Key cache loading is very slow when there are many SSTables
[
https://issues.apache.org/jira/browse/CASSANDRA-14898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454128#comment-17454128
]
Joey Lynch edited comment on CASSANDRA-14898 at 12/6/21, 4:47 PM:
--
Also lg2m, let's iron out the configuration name since that's a public
interface but I think the rest of the feedback is straightforward.
Test flakes seem unrelated to me
was (Author: jolynch):
Also lg2m, let's iron out the configuration name since that's a public
interface but I think the rest of the feedback is straightforward.
> Key cache loading is very slow when there are many SSTables
> ---
>
> Key: CASSANDRA-14898
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14898
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
> Environment: AWS i3.2xlarge, 4 physical cores (8 threads), 60GB of
> RAM, loading about 8MB of KeyCache with 10k keys in it.
>Reporter: Joey Lynch
>Assignee: Venkata Harikrishna Nukala
>Priority: Low
> Labels: Performance, low-hanging-fruit
> Attachments: key_cache_load_slow.svg
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> While dealing with a production issue today where some 3.0.17 nodes had close
> to ~8k sstables on disk due to excessive write pressure, we had a few nodes
> crash due to OOM and then they took close to 17 minutes to load the key cache
> and recover. This excessive key cache load significantly increased the
> duration of the outage (to mitigate we just removed the saved key cache
> files). For example here is one example taking 17 minutes to load 10k keys,
> or about 10 keys per second (which is ... very slow):
> {noformat}
> INFO [pool-3-thread-1] 2018-11-15 21:50:21,885 AutoSavingCache.java:190 -
> reading saved cache /mnt/data/cassandra/saved_caches/KeyCache-d.db
> INFO [pool-3-thread-1] 2018-11-15 22:07:16,490 AutoSavingCache.java:166 -
> Completed loading (1014606 ms; 10103 keys) KeyCache cache
> {noformat}
> I've witnessed similar behavior in the past with large LCS clusters, and
> indeed it appears that any time the number of sstables is large, KeyCache
> loading takes a _really_ long time. Today I got a flame graph and I believe
> that I found the issue and I think it's reasonably easy to fix. From what I
> can tell the {{KeyCacheSerializer::deserialize}} [method
> |https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/service/CacheService.java#L445]
> which is called for every key is linear in the number of sstables due to the
> [call|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/service/CacheService.java#L459]
> to {{ColumnFamilyStore::getSSTables}} which ends up calling {{View::select}}
> [here|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/db/lifecycle/View.java#L139].
> The {{View::select}} call is linear in the number of sstables and causes a
> _lot_ of {{HashSet}}
> [resizing|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/db/lifecycle/View.java#L139]
> when the number of sstables is much greater than 16 (the default size of the
> backing {{HashMap}}).
> As we see in the attached flamegraph we spend 50% of our CPU time in these
> {{getSSTable}} calls, of which 36% is spent adding sstables to the HashSet in
> {{View::select}} and 17% is spent just iterating the sstables in the first
> place. A full 16% of CPU time is spent _just resizing the HashMap_. Then
> another 4% is spend calling {{CacheService::findDesc}} which does [a linear
> search|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/service/CacheService.java#L475]
> for the sstable generation.
> I believe that this affects at least Cassandra 3.0.17 and trunk, and could be
> pretty easily fixed by either caching the getSSTables call or at the very
> least pre-sizing the {{HashSet}} in {{View::select}} to be the size of the
> sstables map.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14898) Key cache loading is very slow when there are many SSTables
[
https://issues.apache.org/jira/browse/CASSANDRA-14898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454128#comment-17454128
]
Joey Lynch commented on CASSANDRA-14898:
Also lg2m, let's iron out the configuration name since that's a public
interface but I think the rest of the feedback is straightforward.
> Key cache loading is very slow when there are many SSTables
> ---
>
> Key: CASSANDRA-14898
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14898
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
> Environment: AWS i3.2xlarge, 4 physical cores (8 threads), 60GB of
> RAM, loading about 8MB of KeyCache with 10k keys in it.
>Reporter: Joey Lynch
>Assignee: Venkata Harikrishna Nukala
>Priority: Low
> Labels: Performance, low-hanging-fruit
> Attachments: key_cache_load_slow.svg
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> While dealing with a production issue today where some 3.0.17 nodes had close
> to ~8k sstables on disk due to excessive write pressure, we had a few nodes
> crash due to OOM and then they took close to 17 minutes to load the key cache
> and recover. This excessive key cache load significantly increased the
> duration of the outage (to mitigate we just removed the saved key cache
> files). For example here is one example taking 17 minutes to load 10k keys,
> or about 10 keys per second (which is ... very slow):
> {noformat}
> INFO [pool-3-thread-1] 2018-11-15 21:50:21,885 AutoSavingCache.java:190 -
> reading saved cache /mnt/data/cassandra/saved_caches/KeyCache-d.db
> INFO [pool-3-thread-1] 2018-11-15 22:07:16,490 AutoSavingCache.java:166 -
> Completed loading (1014606 ms; 10103 keys) KeyCache cache
> {noformat}
> I've witnessed similar behavior in the past with large LCS clusters, and
> indeed it appears that any time the number of sstables is large, KeyCache
> loading takes a _really_ long time. Today I got a flame graph and I believe
> that I found the issue and I think it's reasonably easy to fix. From what I
> can tell the {{KeyCacheSerializer::deserialize}} [method
> |https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/service/CacheService.java#L445]
> which is called for every key is linear in the number of sstables due to the
> [call|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/service/CacheService.java#L459]
> to {{ColumnFamilyStore::getSSTables}} which ends up calling {{View::select}}
> [here|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/db/lifecycle/View.java#L139].
> The {{View::select}} call is linear in the number of sstables and causes a
> _lot_ of {{HashSet}}
> [resizing|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/db/lifecycle/View.java#L139]
> when the number of sstables is much greater than 16 (the default size of the
> backing {{HashMap}}).
> As we see in the attached flamegraph we spend 50% of our CPU time in these
> {{getSSTable}} calls, of which 36% is spent adding sstables to the HashSet in
> {{View::select}} and 17% is spent just iterating the sstables in the first
> place. A full 16% of CPU time is spent _just resizing the HashMap_. Then
> another 4% is spend calling {{CacheService::findDesc}} which does [a linear
> search|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/service/CacheService.java#L475]
> for the sstable generation.
> I believe that this affects at least Cassandra 3.0.17 and trunk, and could be
> pretty easily fixed by either caching the getSSTables call or at the very
> least pre-sizing the {{HashSet}} in {{View::select}} to be the size of the
> sstables map.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17172) incremental repairs get stuck often
[
https://issues.apache.org/jira/browse/CASSANDRA-17172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454120#comment-17454120
]
Brandon Williams commented on CASSANDRA-17172:
--
[~dcapwell] I know you've been working on IR recently, have you seen anything
that may cause this?
> incremental repairs get stuck often
> ---
>
> Key: CASSANDRA-17172
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17172
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: James Brown
>Priority: Normal
> Fix For: 4.0.x
>
>
> We're on 4.0.1 and switched to incremental repairs shortly after upgrading to
> 4.0.x. They work fine about 95% of the time, but once in a while a session
> will get stuck and will have to be cancelled (with `nodetool repair_admin
> cancel -s `). Typically the session will be in REPAIRING but nothing
> will actually be happening.
> Output of nodetool repair_admin:
> {code}
> $ nodetool repair_admin
> id | state | last activity |
> coordinator | participants
>
>
>
>
>
>| participants_wp
> 3a059b10-4ef6-11ec-925f-8f7bcf0ba035 | REPAIRING | 6771 (s) |
> /[fd00:ea51:d057:200:1:0:0:8e]:25472 |
> fd00:ea51:d057:200:1:0:0:8e,fd00:ea51:d057:200:1:0:0:8f,fd00:ea51:d057:200:1:0:0:92,fd00:ea51:d057:100:1:0:0:571,fd00:ea51:d057:100:1:0:0:570,fd00:ea51:d057:200:1:0:0:93,fd00:ea51:d057:100:1:0:0:573,fd00:ea51:d057:200:1:0:0:90,fd00:ea51:d057:200:1:0:0:91,fd00:ea51:d057:100:1:0:0:572,fd00:ea51:d057:100:1:0:0:575,fd00:ea51:d057:100:1:0:0:574,fd00:ea51:d057:200:1:0:0:94,fd00:ea51:d057:100:1:0:0:577,fd00:ea51:d057:200:1:0:0:95,fd00:ea51:d057:100:1:0:0:576
> |
> [fd00:ea51:d057:200:1:0:0:8e]:25472,[fd00:ea51:d057:200:1:0:0:8f]:25472,[fd00:ea51:d057:200:1:0:0:92]:25472,[fd00:ea51:d057:100:1:0:0:571]:25472,[fd00:ea51:d057:100:1:0:0:570]:25472,[fd00:ea51:d057:200:1:0:0:93]:25472,[fd00:ea51:d057:100:1:0:0:573]:25472,[fd00:ea51:d057:200:1:0:0:90]:25472,[fd00:ea51:d057:200:1:0:0:91]:25472,[fd00:ea51:d057:100:1:0:0:572]:25472,[fd00:ea51:d057:100:1:0:0:575]:25472,[fd00:ea51:d057:100:1:0:0:574]:25472,[fd00:ea51:d057:200:1:0:0:94]:25472,[fd00:ea51:d057:100:1:0:0:577]:25472,[fd00:ea51:d057:200:1:0:0:95]:25472,[fd00:ea51:d057:100:1:0:0:576]:25472
> {code}
> Running `jstack` on the coordinator shows two repair threads, both idle:
> {code}
> "Repair#167:1" #602177 daemon prio=5 os_prio=0 cpu=9.60ms elapsed=57359.81s
> tid=0x7fa6d1741800 nid=0x18e6c waiting on condition [0x7fc529f9a000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at jdk.internal.misc.Unsafe.park(java.base@11.0.11/Native Method)
> - parking to wait for <0x00045ba93a18> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(java.base@11.0.11/LockSupport.java:234)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base@11.0.11/AbstractQueuedSynchronizer.java:2123)
> at
> java.util.concurrent.LinkedBlockingQueue.poll(java.base@11.0.11/LinkedBlockingQueue.java:458)
> at
> java.util.concurrent.ThreadPoolExecutor.getTask(java.base@11.0.11/ThreadPoolExecutor.java:1053)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.11/ThreadPoolExecutor.java:1114)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.11/ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(java.base@11.0.11/Thread.java:829)
> "Repair#170:1" #654814 daemon prio=5 os_prio=0 cpu=9.62ms elapsed=7369.98s
> tid=0x7fa6aec09000 nid=0x1a96f waiting on condition [0x7fc535aae000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at jdk.internal.misc.Unsafe.park(java.base@11.0.11/Native Method)
> - parking to wait for <0x0004c45bf7d8> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(java.base@11.0.11/LockSupport.java:234)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base@11.0.11/AbstractQueuedSynchronizer.java:2123)
> at
> java.util.concurrent.LinkedBlockingQueue.poll(java.base@11.0.11/LinkedBlockingQueue.java:458)
> at
>
[jira] [Updated] (CASSANDRA-17172) incremental repairs get stuck often
[
https://issues.apache.org/jira/browse/CASSANDRA-17172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17172:
-
Bug Category: Parent values: Correctness(12982)
Complexity: Normal
Discovered By: User Report
Fix Version/s: 4.0.x
Severity: Normal
Status: Open (was: Triage Needed)
> incremental repairs get stuck often
> ---
>
> Key: CASSANDRA-17172
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17172
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: James Brown
>Priority: Normal
> Fix For: 4.0.x
>
>
> We're on 4.0.1 and switched to incremental repairs shortly after upgrading to
> 4.0.x. They work fine about 95% of the time, but once in a while a session
> will get stuck and will have to be cancelled (with `nodetool repair_admin
> cancel -s `). Typically the session will be in REPAIRING but nothing
> will actually be happening.
> Output of nodetool repair_admin:
> {code}
> $ nodetool repair_admin
> id | state | last activity |
> coordinator | participants
>
>
>
>
>
>| participants_wp
> 3a059b10-4ef6-11ec-925f-8f7bcf0ba035 | REPAIRING | 6771 (s) |
> /[fd00:ea51:d057:200:1:0:0:8e]:25472 |
> fd00:ea51:d057:200:1:0:0:8e,fd00:ea51:d057:200:1:0:0:8f,fd00:ea51:d057:200:1:0:0:92,fd00:ea51:d057:100:1:0:0:571,fd00:ea51:d057:100:1:0:0:570,fd00:ea51:d057:200:1:0:0:93,fd00:ea51:d057:100:1:0:0:573,fd00:ea51:d057:200:1:0:0:90,fd00:ea51:d057:200:1:0:0:91,fd00:ea51:d057:100:1:0:0:572,fd00:ea51:d057:100:1:0:0:575,fd00:ea51:d057:100:1:0:0:574,fd00:ea51:d057:200:1:0:0:94,fd00:ea51:d057:100:1:0:0:577,fd00:ea51:d057:200:1:0:0:95,fd00:ea51:d057:100:1:0:0:576
> |
> [fd00:ea51:d057:200:1:0:0:8e]:25472,[fd00:ea51:d057:200:1:0:0:8f]:25472,[fd00:ea51:d057:200:1:0:0:92]:25472,[fd00:ea51:d057:100:1:0:0:571]:25472,[fd00:ea51:d057:100:1:0:0:570]:25472,[fd00:ea51:d057:200:1:0:0:93]:25472,[fd00:ea51:d057:100:1:0:0:573]:25472,[fd00:ea51:d057:200:1:0:0:90]:25472,[fd00:ea51:d057:200:1:0:0:91]:25472,[fd00:ea51:d057:100:1:0:0:572]:25472,[fd00:ea51:d057:100:1:0:0:575]:25472,[fd00:ea51:d057:100:1:0:0:574]:25472,[fd00:ea51:d057:200:1:0:0:94]:25472,[fd00:ea51:d057:100:1:0:0:577]:25472,[fd00:ea51:d057:200:1:0:0:95]:25472,[fd00:ea51:d057:100:1:0:0:576]:25472
> {code}
> Running `jstack` on the coordinator shows two repair threads, both idle:
> {code}
> "Repair#167:1" #602177 daemon prio=5 os_prio=0 cpu=9.60ms elapsed=57359.81s
> tid=0x7fa6d1741800 nid=0x18e6c waiting on condition [0x7fc529f9a000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at jdk.internal.misc.Unsafe.park(java.base@11.0.11/Native Method)
> - parking to wait for <0x00045ba93a18> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(java.base@11.0.11/LockSupport.java:234)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base@11.0.11/AbstractQueuedSynchronizer.java:2123)
> at
> java.util.concurrent.LinkedBlockingQueue.poll(java.base@11.0.11/LinkedBlockingQueue.java:458)
> at
> java.util.concurrent.ThreadPoolExecutor.getTask(java.base@11.0.11/ThreadPoolExecutor.java:1053)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.11/ThreadPoolExecutor.java:1114)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.11/ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(java.base@11.0.11/Thread.java:829)
> "Repair#170:1" #654814 daemon prio=5 os_prio=0 cpu=9.62ms elapsed=7369.98s
> tid=0x7fa6aec09000 nid=0x1a96f waiting on condition [0x7fc535aae000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at jdk.internal.misc.Unsafe.park(java.base@11.0.11/Native Method)
> - parking to wait for <0x0004c45bf7d8> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(java.base@11.0.11/LockSupport.java:234)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base@11.0.11/AbstractQueuedSynchronizer.java:2123)
> at
>
[jira] [Updated] (CASSANDRA-14898) Key cache loading is very slow when there are many SSTables
[
https://issues.apache.org/jira/browse/CASSANDRA-14898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joey Lynch updated CASSANDRA-14898:
---
Reviewers: Joey Lynch, Marcus Eriksson (was: Marcus Eriksson)
> Key cache loading is very slow when there are many SSTables
> ---
>
> Key: CASSANDRA-14898
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14898
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
> Environment: AWS i3.2xlarge, 4 physical cores (8 threads), 60GB of
> RAM, loading about 8MB of KeyCache with 10k keys in it.
>Reporter: Joey Lynch
>Assignee: Venkata Harikrishna Nukala
>Priority: Low
> Labels: Performance, low-hanging-fruit
> Attachments: key_cache_load_slow.svg
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> While dealing with a production issue today where some 3.0.17 nodes had close
> to ~8k sstables on disk due to excessive write pressure, we had a few nodes
> crash due to OOM and then they took close to 17 minutes to load the key cache
> and recover. This excessive key cache load significantly increased the
> duration of the outage (to mitigate we just removed the saved key cache
> files). For example here is one example taking 17 minutes to load 10k keys,
> or about 10 keys per second (which is ... very slow):
> {noformat}
> INFO [pool-3-thread-1] 2018-11-15 21:50:21,885 AutoSavingCache.java:190 -
> reading saved cache /mnt/data/cassandra/saved_caches/KeyCache-d.db
> INFO [pool-3-thread-1] 2018-11-15 22:07:16,490 AutoSavingCache.java:166 -
> Completed loading (1014606 ms; 10103 keys) KeyCache cache
> {noformat}
> I've witnessed similar behavior in the past with large LCS clusters, and
> indeed it appears that any time the number of sstables is large, KeyCache
> loading takes a _really_ long time. Today I got a flame graph and I believe
> that I found the issue and I think it's reasonably easy to fix. From what I
> can tell the {{KeyCacheSerializer::deserialize}} [method
> |https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/service/CacheService.java#L445]
> which is called for every key is linear in the number of sstables due to the
> [call|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/service/CacheService.java#L459]
> to {{ColumnFamilyStore::getSSTables}} which ends up calling {{View::select}}
> [here|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/db/lifecycle/View.java#L139].
> The {{View::select}} call is linear in the number of sstables and causes a
> _lot_ of {{HashSet}}
> [resizing|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/db/lifecycle/View.java#L139]
> when the number of sstables is much greater than 16 (the default size of the
> backing {{HashMap}}).
> As we see in the attached flamegraph we spend 50% of our CPU time in these
> {{getSSTable}} calls, of which 36% is spent adding sstables to the HashSet in
> {{View::select}} and 17% is spent just iterating the sstables in the first
> place. A full 16% of CPU time is spent _just resizing the HashMap_. Then
> another 4% is spend calling {{CacheService::findDesc}} which does [a linear
> search|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/service/CacheService.java#L475]
> for the sstable generation.
> I believe that this affects at least Cassandra 3.0.17 and trunk, and could be
> pretty easily fixed by either caching the getSSTables call or at the very
> least pre-sizing the {{HashSet}} in {{View::select}} to be the size of the
> sstables map.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17191) Guardrail for scanned tombstones
Andres de la Peña created CASSANDRA-17191:
-
Summary: Guardrail for scanned tombstones
Key: CASSANDRA-17191
URL: https://issues.apache.org/jira/browse/CASSANDRA-17191
Project: Cassandra
Issue Type: New Feature
Components: Feature/Guardrails
Reporter: Andres de la Peña
Add guardrail for limiting the number of read tombstones during a query, for
example:
{code}
# Guardrail to warn or abort when reading more tombstones than threshold.
# The two thresholds default to -1 to disable.
scanned_tombstones:
warn_threshold: -1
abort_threshold: -1
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14898) Key cache loading is very slow when there are many SSTables
[
https://issues.apache.org/jira/browse/CASSANDRA-14898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454080#comment-17454080
]
Venkata Harikrishna Nukala commented on CASSANDRA-14898:
Thanks for the review [~marcuse] ! Taking a look.
> Key cache loading is very slow when there are many SSTables
> ---
>
> Key: CASSANDRA-14898
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14898
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
> Environment: AWS i3.2xlarge, 4 physical cores (8 threads), 60GB of
> RAM, loading about 8MB of KeyCache with 10k keys in it.
>Reporter: Joey Lynch
>Assignee: Venkata Harikrishna Nukala
>Priority: Low
> Labels: Performance, low-hanging-fruit
> Attachments: key_cache_load_slow.svg
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> While dealing with a production issue today where some 3.0.17 nodes had close
> to ~8k sstables on disk due to excessive write pressure, we had a few nodes
> crash due to OOM and then they took close to 17 minutes to load the key cache
> and recover. This excessive key cache load significantly increased the
> duration of the outage (to mitigate we just removed the saved key cache
> files). For example here is one example taking 17 minutes to load 10k keys,
> or about 10 keys per second (which is ... very slow):
> {noformat}
> INFO [pool-3-thread-1] 2018-11-15 21:50:21,885 AutoSavingCache.java:190 -
> reading saved cache /mnt/data/cassandra/saved_caches/KeyCache-d.db
> INFO [pool-3-thread-1] 2018-11-15 22:07:16,490 AutoSavingCache.java:166 -
> Completed loading (1014606 ms; 10103 keys) KeyCache cache
> {noformat}
> I've witnessed similar behavior in the past with large LCS clusters, and
> indeed it appears that any time the number of sstables is large, KeyCache
> loading takes a _really_ long time. Today I got a flame graph and I believe
> that I found the issue and I think it's reasonably easy to fix. From what I
> can tell the {{KeyCacheSerializer::deserialize}} [method
> |https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/service/CacheService.java#L445]
> which is called for every key is linear in the number of sstables due to the
> [call|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/service/CacheService.java#L459]
> to {{ColumnFamilyStore::getSSTables}} which ends up calling {{View::select}}
> [here|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/db/lifecycle/View.java#L139].
> The {{View::select}} call is linear in the number of sstables and causes a
> _lot_ of {{HashSet}}
> [resizing|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/db/lifecycle/View.java#L139]
> when the number of sstables is much greater than 16 (the default size of the
> backing {{HashMap}}).
> As we see in the attached flamegraph we spend 50% of our CPU time in these
> {{getSSTable}} calls, of which 36% is spent adding sstables to the HashSet in
> {{View::select}} and 17% is spent just iterating the sstables in the first
> place. A full 16% of CPU time is spent _just resizing the HashMap_. Then
> another 4% is spend calling {{CacheService::findDesc}} which does [a linear
> search|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/service/CacheService.java#L475]
> for the sstable generation.
> I believe that this affects at least Cassandra 3.0.17 and trunk, and could be
> pretty easily fixed by either caching the getSSTables call or at the very
> least pre-sizing the {{HashSet}} in {{View::select}} to be the size of the
> sstables map.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15510) BTree: Improve Building, Inserting and Transforming
[
https://issues.apache.org/jira/browse/CASSANDRA-15510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15510:
---
Status: Review In Progress (was: Patch Available)
> BTree: Improve Building, Inserting and Transforming
> ---
>
> Key: CASSANDRA-15510
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15510
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> This work was originally undertaken as a follow-up to CASSANDRA-15367 to
> ensure performance is strictly improved, but it may no longer be needed for
> that purpose. It’s still hugely impactful, however. It remains to be
> decided where this should land.
> The current {{BTree}} implementation is suboptimal in a number of ways, with
> very little focus having been given to its performance besides its
> memory-occupancy. This patch aims to address that, specifically improving
> the performance and allocations involved in: building, transforming and
> inserting into a tree.
> To facilitate this work, the {{BTree}} definition is modified slightly, so
> that we can perform some simple arithmetic on tree sizes. Specifically,
> trees of depth n are defined to have a maximum capacity of {{branchFactor^n -
> 1}}, which translates into capping the number of leaf children at
> {{branchFactor-1}}, as opposed to {{branchFactor}}. Since {{branchFactor}}
> is a power of 2, this permits fast tree size arithmetic, enabling some of
> these changes.
> h2. Building
> The static build method has been modified to utilise dedicated
> {{buildPerfect}} methods that build either perfectly dense or perfectly
> sparse sub-trees. These perfect trees all share their {{sizeMap}} with each
> other, and can be built more efficiently than trees of arbitrary size. The
> specifics are described in detail in the comments, but this building block
> can be used to construct trees of any size, using at most one child at each
> level that is not either perfectly sparse or perfectly dense. Bulk methods
> are used where possible.
> For large trees this can produce up to 30x throughput improvement and 30%
> allocation reduction vs 3.0 (TBC, and to be tested vs 4.0).
> {{FastBuilder}} is introduced for building a tree in-order (or in reverse)
> without duplicate elements to resolve, without necessarily knowing the size
> upfront. This meets the needs of most use cases. Data is built directly
> into nodes, with up to one already-constructed node, and one partially
> constructed node, on each level, being mutated to share their contents in the
> event of insufficient data to populate the tree. These builders are
> thread-locally shared. These leads to minimal copying, the same sharing of
> {{sizeMap}} as above, zero wasted allocations, and results in minimal
> difference in performance between utilising the less-ergonomic static build
> and builder approach.
> For large trees this leads to ~4.5x throughput improvement, and 70% reduction
> in allocations vs a normal Builder. For small trees performance is
> comparable, but allocations similarly reduced.
> h2. Inserting
> It turns out that we only ever insert another tree into a tree, so we exploit
> this to implement an efficient union of two trees, operating on them directly
> via stacks in the transformer, instead of via a collection interface. A
> builder-like object is introduced that shares functionality with
> {{FastBuilder}}, and permits us to build the result of the union directly
> into the final nodes, reusing as much of the original trees as possible.
> Bulk methods are used where possible.
> The result is not _uniformly_ faster, but is _significantly_ faster on
> average: median _improvement_ of 1.4x (that is, 2.4x total throughput), mean
> improvement of 10x. Worst reduction is 30%, and it may be that we can
> isolate and alleviate that. Allocations are also reduced significantly, with
> a median of 30% and mean of 42% for the tested workloads. As the trees get
> larger the improvement drops, but remains uniformly lower.
> h2. Transforming
> Transformations garbage overhead is minimal, i.e. the main allocations are
> those necessary to represent the new tree. It is significantly faster and
> particularly more efficient when removing elements, utilising the shared
> functionality of the builder and transformer objects to define an efficient
> builder that reuses as much of the original tree as possible.
> We also introduce dedicated {{transform}} methods (that forbid returning
> {{null}}), and {{BiFunction}} transformations to permit efficient follow-ups.
--
This message
[jira] [Commented] (CASSANDRA-17184) Add += and -= syntax to ALTER TABLE WITH
[
https://issues.apache.org/jira/browse/CASSANDRA-17184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454034#comment-17454034
]
Benjamin Lerer commented on CASSANDRA-17184:
[~aleks_v] I assigned the ticket to you :-)
> Add += and -= syntax to ALTER TABLE WITH
>
>
> Key: CASSANDRA-17184
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17184
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Aleksandr Volochnev
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
>
> We have 2 types of table properties in CQL: simple ones (comment,
> gc_grace_seconds, ...), which are basically of type text (even if, we
> historically allow constants of any type) and complex ones (compaction,
> caching...), which are basically map.
> The only syntax that {{ALTER TABLE WITH}} supports is of setting a property,
> and so for the later kind, we basically always have to provide the new full
> map for the option. To take an example, say you have a table with compaction
> and want to enable compaction logging you will have to provide the all map.
> In order to avoid that problem we can add support for the {{+=}} (and {{-=}}
> ideally) syntax that already exists for maps otherwise, and support:
> {code}
> ALTER TABLE t WITH compaction+= { 'log_all' : 'true' }
> {code}
> +Additional info for newcomers:+
> In order to implement this change you will need to change the Parser.g ANTLR
> file located in the src/antlr directory and the java classes corresponding to
> the different alter statements located in the
> {{org.apache.cassandra.cql3.statements.schema}} package.
> The unit test for the CQL logic are located under
> {{org.apache.cassandra.cql3.validation}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17184) Add += and -= syntax to ALTER TABLE WITH
[
https://issues.apache.org/jira/browse/CASSANDRA-17184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-17184:
--
Assignee: Aleksandr Volochnev (was: Aleksandar Vidakovic)
> Add += and -= syntax to ALTER TABLE WITH
>
>
> Key: CASSANDRA-17184
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17184
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Aleksandr Volochnev
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
>
> We have 2 types of table properties in CQL: simple ones (comment,
> gc_grace_seconds, ...), which are basically of type text (even if, we
> historically allow constants of any type) and complex ones (compaction,
> caching...), which are basically map.
> The only syntax that {{ALTER TABLE WITH}} supports is of setting a property,
> and so for the later kind, we basically always have to provide the new full
> map for the option. To take an example, say you have a table with compaction
> and want to enable compaction logging you will have to provide the all map.
> In order to avoid that problem we can add support for the {{+=}} (and {{-=}}
> ideally) syntax that already exists for maps otherwise, and support:
> {code}
> ALTER TABLE t WITH compaction+= { 'log_all' : 'true' }
> {code}
> +Additional info for newcomers:+
> In order to implement this change you will need to change the Parser.g ANTLR
> file located in the src/antlr directory and the java classes corresponding to
> the different alter statements located in the
> {{org.apache.cassandra.cql3.statements.schema}} package.
> The unit test for the CQL logic are located under
> {{org.apache.cassandra.cql3.validation}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17184) Add += and -= syntax to ALTER TABLE WITH
[
https://issues.apache.org/jira/browse/CASSANDRA-17184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-17184:
--
Assignee: Aleksandar Vidakovic
> Add += and -= syntax to ALTER TABLE WITH
>
>
> Key: CASSANDRA-17184
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17184
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Aleksandar Vidakovic
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
>
> We have 2 types of table properties in CQL: simple ones (comment,
> gc_grace_seconds, ...), which are basically of type text (even if, we
> historically allow constants of any type) and complex ones (compaction,
> caching...), which are basically map.
> The only syntax that {{ALTER TABLE WITH}} supports is of setting a property,
> and so for the later kind, we basically always have to provide the new full
> map for the option. To take an example, say you have a table with compaction
> and want to enable compaction logging you will have to provide the all map.
> In order to avoid that problem we can add support for the {{+=}} (and {{-=}}
> ideally) syntax that already exists for maps otherwise, and support:
> {code}
> ALTER TABLE t WITH compaction+= { 'log_all' : 'true' }
> {code}
> +Additional info for newcomers:+
> In order to implement this change you will need to change the Parser.g ANTLR
> file located in the src/antlr directory and the java classes corresponding to
> the different alter statements located in the
> {{org.apache.cassandra.cql3.statements.schema}} package.
> The unit test for the CQL logic are located under
> {{org.apache.cassandra.cql3.validation}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17190) Add support for String contatenation through the "+" operator
[
https://issues.apache.org/jira/browse/CASSANDRA-17190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17190:
---
Labels: AdventCalendar2021 lhf (was: )
> Add support for String contatenation through the "+" operator
> -
>
> Key: CASSANDRA-17190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17190
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
>
> Since 4.0, Cassandra support operations on numeric types and on some temporal
> types.
> We should add support for string concatenations through the {{+}} operator.
> +Additional information for newcomers:+
> Cassandra has 2 string types: {{Text}} ({{UTF8Type}}) and ascii
> ({{AsciiType}}) both are sub-classes of ({{StringType}}). In order to add
> support for string concatenation you will need to add a new method to
> {{StringType}} and modify {{OperationFcts}} to add the new functions (one for
> each combination of types: ascii/ascii, ascii/text, text/ascii and text/text).
> The unit test should be added to {{OperationFctsTest}}.
> To allow for concatenating constants (eg: SELECT v1 + ' ' + v2 FROM ...) you
> will need to add a {{getPreferedTypeFor}} method to
> {{org.apache.cassandra.Constants.Type.STRING}} that determine the constant
> type based on its content (ascii or not).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17190) Add support for String contatenation through the "+" operator
[
https://issues.apache.org/jira/browse/CASSANDRA-17190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17190:
---
Change Category: Semantic
Complexity: Low Hanging Fruit
Fix Version/s: 4.x
Status: Open (was: Triage Needed)
> Add support for String contatenation through the "+" operator
> -
>
> Key: CASSANDRA-17190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17190
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Priority: Normal
> Fix For: 4.x
>
>
> Since 4.0, Cassandra support operations on numeric types and on some temporal
> types.
> We should add support for string concatenations through the {{+}} operator.
> +Additional information for newcomers:+
> Cassandra has 2 string types: {{Text}} ({{UTF8Type}}) and ascii
> ({{AsciiType}}) both are sub-classes of ({{StringType}}). In order to add
> support for string concatenation you will need to add a new method to
> {{StringType}} and modify {{OperationFcts}} to add the new functions (one for
> each combination of types: ascii/ascii, ascii/text, text/ascii and text/text).
> The unit test should be added to {{OperationFctsTest}}.
> To allow for concatenating constants (eg: SELECT v1 + ' ' + v2 FROM ...) you
> will need to add a {{getPreferedTypeFor}} method to
> {{org.apache.cassandra.Constants.Type.STRING}} that determine the constant
> type based on its content (ascii or not).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17190) Add support for String contatenation through the "+" operator
Benjamin Lerer created CASSANDRA-17190:
--
Summary: Add support for String contatenation through the "+"
operator
Key: CASSANDRA-17190
URL: https://issues.apache.org/jira/browse/CASSANDRA-17190
Project: Cassandra
Issue Type: Improvement
Components: CQL/Interpreter
Reporter: Benjamin Lerer
Since 4.0, Cassandra support operations on numeric types and on some temporal
types.
We should add support for string concatenations through the {{+}} operator.
+Additional information for newcomers:+
Cassandra has 2 string types: {{Text}} ({{UTF8Type}}) and ascii
({{AsciiType}}) both are sub-classes of ({{StringType}}). In order to add
support for string concatenation you will need to add a new method to
{{StringType}} and modify {{OperationFcts}} to add the new functions (one for
each combination of types: ascii/ascii, ascii/text, text/ascii and text/text).
The unit test should be added to {{OperationFctsTest}}.
To allow for concatenating constants (eg: SELECT v1 + ' ' + v2 FROM ...) you
will need to add a {{getPreferedTypeFor}} method to
{{org.apache.cassandra.Constants.Type.STRING}} that determine the constant type
based on its content (ascii or not).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17184) Add += and -= syntax to ALTER TABLE WITH
[
https://issues.apache.org/jira/browse/CASSANDRA-17184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454022#comment-17454022
]
Aleksandr Volochnev edited comment on CASSANDRA-17184 at 12/6/21, 1:54 PM:
---
Hi [~blerer], this task looks like a good starting point for me. I'll start
working on it tonight if there is no one assigned already. Should I assign the
issue to myself?
Thank you for the detailed description, it helps a lot.
was (Author: JIRAUSER281282):
Hi [~blerer], this task looks like a good starting point for me. I'll start
working on it tonight if there is no one assigned already.
Thank you for the detailed description, it helps a lot.
> Add += and -= syntax to ALTER TABLE WITH
>
>
> Key: CASSANDRA-17184
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17184
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
>
> We have 2 types of table properties in CQL: simple ones (comment,
> gc_grace_seconds, ...), which are basically of type text (even if, we
> historically allow constants of any type) and complex ones (compaction,
> caching...), which are basically map.
> The only syntax that {{ALTER TABLE WITH}} supports is of setting a property,
> and so for the later kind, we basically always have to provide the new full
> map for the option. To take an example, say you have a table with compaction
> and want to enable compaction logging you will have to provide the all map.
> In order to avoid that problem we can add support for the {{+=}} (and {{-=}}
> ideally) syntax that already exists for maps otherwise, and support:
> {code}
> ALTER TABLE t WITH compaction+= { 'log_all' : 'true' }
> {code}
> +Additional info for newcomers:+
> In order to implement this change you will need to change the Parser.g ANTLR
> file located in the src/antlr directory and the java classes corresponding to
> the different alter statements located in the
> {{org.apache.cassandra.cql3.statements.schema}} package.
> The unit test for the CQL logic are located under
> {{org.apache.cassandra.cql3.validation}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17184) Add += and -= syntax to ALTER TABLE WITH
[
https://issues.apache.org/jira/browse/CASSANDRA-17184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454022#comment-17454022
]
Aleksandr Volochnev commented on CASSANDRA-17184:
-
Hi [~blerer], this task looks like a good starting point for me. I'll start
working on it tonight if there is no one assigned already.
Thank you for the detailed description, it helps a lot.
> Add += and -= syntax to ALTER TABLE WITH
>
>
> Key: CASSANDRA-17184
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17184
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
>
> We have 2 types of table properties in CQL: simple ones (comment,
> gc_grace_seconds, ...), which are basically of type text (even if, we
> historically allow constants of any type) and complex ones (compaction,
> caching...), which are basically map.
> The only syntax that {{ALTER TABLE WITH}} supports is of setting a property,
> and so for the later kind, we basically always have to provide the new full
> map for the option. To take an example, say you have a table with compaction
> and want to enable compaction logging you will have to provide the all map.
> In order to avoid that problem we can add support for the {{+=}} (and {{-=}}
> ideally) syntax that already exists for maps otherwise, and support:
> {code}
> ALTER TABLE t WITH compaction+= { 'log_all' : 'true' }
> {code}
> +Additional info for newcomers:+
> In order to implement this change you will need to change the Parser.g ANTLR
> file located in the src/antlr directory and the java classes corresponding to
> the different alter statements located in the
> {{org.apache.cassandra.cql3.statements.schema}} package.
> The unit test for the CQL logic are located under
> {{org.apache.cassandra.cql3.validation}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14898) Key cache loading is very slow when there are many SSTables
[
https://issues.apache.org/jira/browse/CASSANDRA-14898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454018#comment-17454018
]
Marcus Eriksson commented on CASSANDRA-14898:
-
this lgtm, just a few minor comments on the 3.0 PR above (but the comments
apply on all branches)
> Key cache loading is very slow when there are many SSTables
> ---
>
> Key: CASSANDRA-14898
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14898
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
> Environment: AWS i3.2xlarge, 4 physical cores (8 threads), 60GB of
> RAM, loading about 8MB of KeyCache with 10k keys in it.
>Reporter: Joey Lynch
>Assignee: Venkata Harikrishna Nukala
>Priority: Low
> Labels: Performance, low-hanging-fruit
> Attachments: key_cache_load_slow.svg
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> While dealing with a production issue today where some 3.0.17 nodes had close
> to ~8k sstables on disk due to excessive write pressure, we had a few nodes
> crash due to OOM and then they took close to 17 minutes to load the key cache
> and recover. This excessive key cache load significantly increased the
> duration of the outage (to mitigate we just removed the saved key cache
> files). For example here is one example taking 17 minutes to load 10k keys,
> or about 10 keys per second (which is ... very slow):
> {noformat}
> INFO [pool-3-thread-1] 2018-11-15 21:50:21,885 AutoSavingCache.java:190 -
> reading saved cache /mnt/data/cassandra/saved_caches/KeyCache-d.db
> INFO [pool-3-thread-1] 2018-11-15 22:07:16,490 AutoSavingCache.java:166 -
> Completed loading (1014606 ms; 10103 keys) KeyCache cache
> {noformat}
> I've witnessed similar behavior in the past with large LCS clusters, and
> indeed it appears that any time the number of sstables is large, KeyCache
> loading takes a _really_ long time. Today I got a flame graph and I believe
> that I found the issue and I think it's reasonably easy to fix. From what I
> can tell the {{KeyCacheSerializer::deserialize}} [method
> |https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/service/CacheService.java#L445]
> which is called for every key is linear in the number of sstables due to the
> [call|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/service/CacheService.java#L459]
> to {{ColumnFamilyStore::getSSTables}} which ends up calling {{View::select}}
> [here|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/db/lifecycle/View.java#L139].
> The {{View::select}} call is linear in the number of sstables and causes a
> _lot_ of {{HashSet}}
> [resizing|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/db/lifecycle/View.java#L139]
> when the number of sstables is much greater than 16 (the default size of the
> backing {{HashMap}}).
> As we see in the attached flamegraph we spend 50% of our CPU time in these
> {{getSSTable}} calls, of which 36% is spent adding sstables to the HashSet in
> {{View::select}} and 17% is spent just iterating the sstables in the first
> place. A full 16% of CPU time is spent _just resizing the HashMap_. Then
> another 4% is spend calling {{CacheService::findDesc}} which does [a linear
> search|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/service/CacheService.java#L475]
> for the sstable generation.
> I believe that this affects at least Cassandra 3.0.17 and trunk, and could be
> pretty easily fixed by either caching the getSSTables call or at the very
> least pre-sizing the {{HashSet}} in {{View::select}} to be the size of the
> sstables map.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14898) Key cache loading is very slow when there are many SSTables
[
https://issues.apache.org/jira/browse/CASSANDRA-14898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-14898:
Reviewers: Marcus Eriksson
> Key cache loading is very slow when there are many SSTables
> ---
>
> Key: CASSANDRA-14898
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14898
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
> Environment: AWS i3.2xlarge, 4 physical cores (8 threads), 60GB of
> RAM, loading about 8MB of KeyCache with 10k keys in it.
>Reporter: Joey Lynch
>Assignee: Venkata Harikrishna Nukala
>Priority: Low
> Labels: Performance, low-hanging-fruit
> Attachments: key_cache_load_slow.svg
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> While dealing with a production issue today where some 3.0.17 nodes had close
> to ~8k sstables on disk due to excessive write pressure, we had a few nodes
> crash due to OOM and then they took close to 17 minutes to load the key cache
> and recover. This excessive key cache load significantly increased the
> duration of the outage (to mitigate we just removed the saved key cache
> files). For example here is one example taking 17 minutes to load 10k keys,
> or about 10 keys per second (which is ... very slow):
> {noformat}
> INFO [pool-3-thread-1] 2018-11-15 21:50:21,885 AutoSavingCache.java:190 -
> reading saved cache /mnt/data/cassandra/saved_caches/KeyCache-d.db
> INFO [pool-3-thread-1] 2018-11-15 22:07:16,490 AutoSavingCache.java:166 -
> Completed loading (1014606 ms; 10103 keys) KeyCache cache
> {noformat}
> I've witnessed similar behavior in the past with large LCS clusters, and
> indeed it appears that any time the number of sstables is large, KeyCache
> loading takes a _really_ long time. Today I got a flame graph and I believe
> that I found the issue and I think it's reasonably easy to fix. From what I
> can tell the {{KeyCacheSerializer::deserialize}} [method
> |https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/service/CacheService.java#L445]
> which is called for every key is linear in the number of sstables due to the
> [call|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/service/CacheService.java#L459]
> to {{ColumnFamilyStore::getSSTables}} which ends up calling {{View::select}}
> [here|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/db/lifecycle/View.java#L139].
> The {{View::select}} call is linear in the number of sstables and causes a
> _lot_ of {{HashSet}}
> [resizing|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/db/lifecycle/View.java#L139]
> when the number of sstables is much greater than 16 (the default size of the
> backing {{HashMap}}).
> As we see in the attached flamegraph we spend 50% of our CPU time in these
> {{getSSTable}} calls, of which 36% is spent adding sstables to the HashSet in
> {{View::select}} and 17% is spent just iterating the sstables in the first
> place. A full 16% of CPU time is spent _just resizing the HashMap_. Then
> another 4% is spend calling {{CacheService::findDesc}} which does [a linear
> search|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/service/CacheService.java#L475]
> for the sstable generation.
> I believe that this affects at least Cassandra 3.0.17 and trunk, and could be
> pretty easily fixed by either caching the getSSTables call or at the very
> least pre-sizing the {{HashSet}} in {{View::select}} to be the size of the
> sstables map.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña reassigned CASSANDRA-17188:
-
Assignee: Andres de la Peña
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17189) Guardrail for page size
Andres de la Peña created CASSANDRA-17189:
-
Summary: Guardrail for page size
Key: CASSANDRA-17189
URL: https://issues.apache.org/jira/browse/CASSANDRA-17189
Project: Cassandra
Issue Type: New Feature
Components: Feature/Guardrails
Reporter: Andres de la Peña
Add guardrail limiting the query page size, for example:
{code}
# Guardrail to warn about or reject page sizes greater than threshold.
# The two thresholds default to -1 to disable.
page_size:
warn_threshold: -1
abort_threshold: -1
{code}
Initially this can be based on the specified number of rows used as page size,
although it would be ideal to also limit the actual size in bytes of the
returned pages.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17188) Guardrails for consistency levels
Andres de la Peña created CASSANDRA-17188:
-
Summary: Guardrails for consistency levels
Key: CASSANDRA-17188
URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
Project: Cassandra
Issue Type: New Feature
Components: Feature/Guardrails
Reporter: Andres de la Peña
Add guardrails for read/write consistency levels, for example:
{code:java}
# Guardrail to warn about or reject read consistency levels.
# By default all consistency levels are allowed.
read_consistency_levels:
warned: []
disallowed: []
# Guardrail to warn about or reject write consistency levels.
# By default all consistency levels are allowed.
write_consistency_levels:
warned: []
disallowed: []
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17187) Guardrail for SELECT IN terms and their cartesian product
Andres de la Peña created CASSANDRA-17187:
-
Summary: Guardrail for SELECT IN terms and their cartesian product
Key: CASSANDRA-17187
URL: https://issues.apache.org/jira/browse/CASSANDRA-17187
Project: Cassandra
Issue Type: New Feature
Components: Feature/Guardrails
Reporter: Andres de la Peña
Add a guardrail to limit the number restrictions generated by the cartesian
product of the {{IN}} restrictions of a {{SELECT}} query, for example:
{code}
# Guardrail to warn or abort when IN query creates a cartesian product with a
# size exceeding threshold, eg. "a in (1,2,...10) and b in (1,2...10)" results
in
# cartesian product of 100.
# The two thresholds default to -1 to disable.
in_select_cartesian_product:
warn_threshold: -1
abort_threshold: -1
{code}
As an example of why this guardrails is proposed, these queries bring a C*
instance to its knees even before the query starts executing:
{code}
@Test
public void testPartitionKeyTerms() throws Throwable
{
createTable("CREATE TABLE %s (pk1 int, pk2 int, pk3 int, pk4 int, pk5 int,
pk6 int, pk7 int, pk8 int, pk9 int, " +
"PRIMARY KEY((pk1, pk2, pk3, pk4, pk5, pk6, pk7, pk8, pk9)))");
execute("SELECT * FROM %s WHERE pk1 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
"AND pk2 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
"AND pk3 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
"AND pk4 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
"AND pk5 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
"AND pk6 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
"AND pk7 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
"AND pk8 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
"AND pk9 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);");
}
@Test
public void testClusteringKeyTerms() throws Throwable
{
createTable("CREATE TABLE %s (pk int ,ck1 int, ck2 int, ck3 int, ck4 int,
ck5 int, ck6 int, ck7 int, ck8 int, ck9 int, " +
"PRIMARY KEY(pk, ck1, ck2, ck3, ck4, ck5, ck6, ck7, ck8, ck9))");
execute("SELECT * FROM %s WHERE pk = 1 " +
"AND ck1 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
"AND ck2 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
"AND ck3 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
"AND ck4 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
"AND ck5 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
"AND ck6 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
"AND ck7 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
"AND ck8 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
"AND ck9 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);");
}
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17186) Guardrail for number of partition keys on IN queries
Andres de la Peña created CASSANDRA-17186:
-
Summary: Guardrail for number of partition keys on IN queries
Key: CASSANDRA-17186
URL: https://issues.apache.org/jira/browse/CASSANDRA-17186
Project: Cassandra
Issue Type: New Feature
Components: Feature/Guardrails
Reporter: Andres de la Peña
Add a guardrail for limiting the number of partitions restricted with an {{IN}}
clause in a {{SELECT}} query, for example:
{code:java}
# Guardrail to warn or abort when querying with an IN restriction selecting
# more partition keys than threshold.
# The two thresholds default to -1 to disable.
partition_keys_in_select:
warn_threshold: -1
abort_threshold: -1
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17181) SchemaCQLHelperTest methods can be simplified
[
https://issues.apache.org/jira/browse/CASSANDRA-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17181:
---
Description:
{{SchemaCQLHelperTest}} is used during a snapshot to generate the
{{schema.cql}} file. The methods accept the following paramaters:
{{includeDroppedColumns}}, {{internals}} and {{ifNotExists}}.
Those parameters are in practice always set to true by the calling code and
therefore can be removed.
was:
When a schema.cql is created during a snapshot, {{CREATE TYPE}} statements are
not created with {{IF NOT EXISTS}} as the {{CREATE TABLE}} statements. This can
cause some issues when using those statements during restore.
Additional Information for newcomers:
In 3.0 and 3.11 the code use to generate the {{schema.cql}} file is in
{{TableCQLHelper}} and the unit tests in {{TableCQLHelperTest}}.
In 4.0 the bug does not exist anymore but the test {{SchemaCQLHelperTest}} does
not test the correct behavior and the code could be simplified
> SchemaCQLHelperTest methods can be simplified
> -
>
> Key: CASSANDRA-17181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17181
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Benjamin Lerer
>Assignee: Bartlomiej
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.1
>
>
> {{SchemaCQLHelperTest}} is used during a snapshot to generate the
> {{schema.cql}} file. The methods accept the following paramaters:
> {{includeDroppedColumns}}, {{internals}} and {{ifNotExists}}.
> Those parameters are in practice always set to true by the calling code and
> therefore can be removed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17181) SchemaCQLHelperTest methods can be simplified
[
https://issues.apache.org/jira/browse/CASSANDRA-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-17181:
--
Assignee: Bartlomiej
> SchemaCQLHelperTest methods can be simplified
> -
>
> Key: CASSANDRA-17181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17181
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Benjamin Lerer
>Assignee: Bartlomiej
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.1
>
>
> When a schema.cql is created during a snapshot, {{CREATE TYPE}} statements
> are not created with {{IF NOT EXISTS}} as the {{CREATE TABLE}} statements.
> This can cause some issues when using those statements during restore.
> Additional Information for newcomers:
> In 3.0 and 3.11 the code use to generate the {{schema.cql}} file is in
> {{TableCQLHelper}} and the unit tests in {{TableCQLHelperTest}}.
> In 4.0 the bug does not exist anymore but the test {{SchemaCQLHelperTest}}
> does not test the correct behavior and the code could be simplified
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17181) SchemaCQLHelperTest methods can be simplified
[
https://issues.apache.org/jira/browse/CASSANDRA-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17181:
---
Fix Version/s: 4.1
(was: 3.0.x)
(was: 3.11.x)
(was: 4.0.x)
> SchemaCQLHelperTest methods can be simplified
> -
>
> Key: CASSANDRA-17181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17181
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Benjamin Lerer
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.1
>
>
> When a schema.cql is created during a snapshot, {{CREATE TYPE}} statements
> are not created with {{IF NOT EXISTS}} as the {{CREATE TABLE}} statements.
> This can cause some issues when using those statements during restore.
> Additional Information for newcomers:
> In 3.0 and 3.11 the code use to generate the {{schema.cql}} file is in
> {{TableCQLHelper}} and the unit tests in {{TableCQLHelperTest}}.
> In 4.0 the bug does not exist anymore but the test {{SchemaCQLHelperTest}}
> does not test the correct behavior and the code could be simplified
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17181) SchemaCQLHelperTest methods can be simplified
[
https://issues.apache.org/jira/browse/CASSANDRA-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17181:
---
Summary: SchemaCQLHelperTest methods can be simplified (was: schema.cql
should have IF NOT EXISTS for CREATE TYPE)
> SchemaCQLHelperTest methods can be simplified
> -
>
> Key: CASSANDRA-17181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17181
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Benjamin Lerer
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> When a schema.cql is created during a snapshot, {{CREATE TYPE}} statements
> are not created with {{IF NOT EXISTS}} as the {{CREATE TABLE}} statements.
> This can cause some issues when using those statements during restore.
> Additional Information for newcomers:
> In 3.0 and 3.11 the code use to generate the {{schema.cql}} file is in
> {{TableCQLHelper}} and the unit tests in {{TableCQLHelperTest}}.
> In 4.0 the bug does not exist anymore but the test {{SchemaCQLHelperTest}}
> does not test the correct behavior and the code could be simplified
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17151) Guardrail for column size
[
https://issues.apache.org/jira/browse/CASSANDRA-17151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña reassigned CASSANDRA-17151:
-
Assignee: Andres de la Peña
> Guardrail for column size
> -
>
> Key: CASSANDRA-17151
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17151
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> Add a guardrail for limiting the max size of column values, for example:
> {code}
> # Failure threshold to prevent writing large column values.
> # Defaults to -1 to disable.
> column_value_size_failure_threshold_in_kb: -1
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17181) schema.cql should have IF NOT EXISTS for CREATE TYPE
[
https://issues.apache.org/jira/browse/CASSANDRA-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17453949#comment-17453949
]
Bartlomiej commented on CASSANDRA-17181:
{code:java}
If you are interested in cleaning that I can update the ticket to reflect the
new goal {code}
yeas pls - I will clean this :)
> schema.cql should have IF NOT EXISTS for CREATE TYPE
>
>
> Key: CASSANDRA-17181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17181
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Benjamin Lerer
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> When a schema.cql is created during a snapshot, {{CREATE TYPE}} statements
> are not created with {{IF NOT EXISTS}} as the {{CREATE TABLE}} statements.
> This can cause some issues when using those statements during restore.
> Additional Information for newcomers:
> In 3.0 and 3.11 the code use to generate the {{schema.cql}} file is in
> {{TableCQLHelper}} and the unit tests in {{TableCQLHelperTest}}.
> In 4.0 the bug does not exist anymore but the test {{SchemaCQLHelperTest}}
> does not test the correct behavior and the code could be simplified
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15215) VIntCoding should read and write more efficiently
[ https://issues.apache.org/jira/browse/CASSANDRA-15215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17453947#comment-17453947 ] Benedict Elliott Smith commented on CASSANDRA-15215: I've re-run [CI|https://app.circleci.com/pipelines/github/belliottsmith/cassandra?branch=15215-trunk] and it looks mostly clean but there are some remaining issues. I'm on holiday at the moment, and will get back to review and final sign off next week. > VIntCoding should read and write more efficiently > - > > Key: CASSANDRA-15215 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15215 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction, Local/SSTable >Reporter: Benedict Elliott Smith >Assignee: Aleksandr Sorokoumov >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.x > > Attachments: testWriteRandomLongDOP_final.png, > writeUnsignedVInt_megamorphic_BB.png, writeUnsignedVInt_megamorphic_DOP.png > > Time Spent: 40m > Remaining Estimate: 0h > > Most vints occupy significantly fewer than 8 bytes, and most buffers have >= > 8 bytes spare, in which case we can construct the relevant bytes in a > register and memcpy them to the correct position. Since we read and write a > lot of vints, this waste is probably measurable, particularly during > compaction and flush, and can probably be considered a performance bug. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17181) schema.cql should have IF NOT EXISTS for CREATE TYPE
[
https://issues.apache.org/jira/browse/CASSANDRA-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17453946#comment-17453946
]
Benjamin Lerer commented on CASSANDRA-17181:
[~bkowalczyyk] You are right. I was looking at a snapshot of the code from when
CASSANDRA-14825 was committed (shame on me). To make the matter worst, I was
reviewer of the fix CASSANDRA-13935 :-(. All my apologizes for that.
So the problem is fixed but looking at the 4.0 code it seems that the
{{SchemaCQLHelper}} methods are having a set of boolean parameters that are
never used (as I would have expected) as they are always called with {{true}}.
The only call that do not use true seems to be a useless one.
If you are interested in cleaning that I can update the ticket to reflect the
new goal (or create a new one). Otherwise I am sure that can I find you
something else to play with :-)
> schema.cql should have IF NOT EXISTS for CREATE TYPE
>
>
> Key: CASSANDRA-17181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17181
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Benjamin Lerer
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> When a schema.cql is created during a snapshot, {{CREATE TYPE}} statements
> are not created with {{IF NOT EXISTS}} as the {{CREATE TABLE}} statements.
> This can cause some issues when using those statements during restore.
> Additional Information for newcomers:
> In 3.0 and 3.11 the code use to generate the {{schema.cql}} file is in
> {{TableCQLHelper}} and the unit tests in {{TableCQLHelperTest}}.
> In 4.0 the bug does not exist anymore but the test {{SchemaCQLHelperTest}}
> does not test the correct behavior and the code could be simplified
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17181) schema.cql should have IF NOT EXISTS for CREATE TYPE
[
https://issues.apache.org/jira/browse/CASSANDRA-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-17181:
--
Assignee: (was: Benjamin Lerer)
> schema.cql should have IF NOT EXISTS for CREATE TYPE
>
>
> Key: CASSANDRA-17181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17181
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Benjamin Lerer
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> When a schema.cql is created during a snapshot, {{CREATE TYPE}} statements
> are not created with {{IF NOT EXISTS}} as the {{CREATE TABLE}} statements.
> This can cause some issues when using those statements during restore.
> Additional Information for newcomers:
> In 3.0 and 3.11 the code use to generate the {{schema.cql}} file is in
> {{TableCQLHelper}} and the unit tests in {{TableCQLHelperTest}}.
> In 4.0 the bug does not exist anymore but the test {{SchemaCQLHelperTest}}
> does not test the correct behavior and the code could be simplified
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17181) schema.cql should have IF NOT EXISTS for CREATE TYPE
[
https://issues.apache.org/jira/browse/CASSANDRA-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-17181:
--
Assignee: Benjamin Lerer
> schema.cql should have IF NOT EXISTS for CREATE TYPE
>
>
> Key: CASSANDRA-17181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17181
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> When a schema.cql is created during a snapshot, {{CREATE TYPE}} statements
> are not created with {{IF NOT EXISTS}} as the {{CREATE TABLE}} statements.
> This can cause some issues when using those statements during restore.
> Additional Information for newcomers:
> In 3.0 and 3.11 the code use to generate the {{schema.cql}} file is in
> {{TableCQLHelper}} and the unit tests in {{TableCQLHelperTest}}.
> In 4.0 the bug does not exist anymore but the test {{SchemaCQLHelperTest}}
> does not test the correct behavior and the code could be simplified
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17181) schema.cql should have IF NOT EXISTS for CREATE TYPE
[
https://issues.apache.org/jira/browse/CASSANDRA-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-17181:
--
Assignee: (was: Bartlomiej)
> schema.cql should have IF NOT EXISTS for CREATE TYPE
>
>
> Key: CASSANDRA-17181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17181
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Benjamin Lerer
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> When a schema.cql is created during a snapshot, {{CREATE TYPE}} statements
> are not created with {{IF NOT EXISTS}} as the {{CREATE TABLE}} statements.
> This can cause some issues when using those statements during restore.
> Additional Information for newcomers:
> In 3.0 and 3.11 the code use to generate the {{schema.cql}} file is in
> {{TableCQLHelper}} and the unit tests in {{TableCQLHelperTest}}.
> In 4.0 the bug does not exist anymore but the test {{SchemaCQLHelperTest}}
> does not test the correct behavior and the code could be simplified
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17181) schema.cql should have IF NOT EXISTS for CREATE TYPE
[
https://issues.apache.org/jira/browse/CASSANDRA-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-17181:
--
Assignee: Bartlomiej
> schema.cql should have IF NOT EXISTS for CREATE TYPE
>
>
> Key: CASSANDRA-17181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17181
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Benjamin Lerer
>Assignee: Bartlomiej
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> When a schema.cql is created during a snapshot, {{CREATE TYPE}} statements
> are not created with {{IF NOT EXISTS}} as the {{CREATE TABLE}} statements.
> This can cause some issues when using those statements during restore.
> Additional Information for newcomers:
> In 3.0 and 3.11 the code use to generate the {{schema.cql}} file is in
> {{TableCQLHelper}} and the unit tests in {{TableCQLHelperTest}}.
> In 4.0 the bug does not exist anymore but the test {{SchemaCQLHelperTest}}
> does not test the correct behavior and the code could be simplified
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17044) Refactor schema management to allow for schema source pluggability
[ https://issues.apache.org/jira/browse/CASSANDRA-17044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17453898#comment-17453898 ] Jacek Lewandowski commented on CASSANDRA-17044: --- i've rebased it, I'll provide test links once they are worth showing ;-) > Refactor schema management to allow for schema source pluggability > -- > > Key: CASSANDRA-17044 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17044 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Schema >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 4.1 > > > The idea is decompose `Schema` into separate entities responsible for > different things. In particular extract what is related to schema storage and > synchronization into a separate class so that it is possible to create an > extension point there and store schema in a different way than > `system_schema` keyspace, for example in etcd. > This would also simplify the logic and reduce the number of special cases, > make all the things more testable and the logic of internal classes > encapsulated. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
