[jira] [Updated] (CASSANDRA-17570) Update the CQL version for the 4.1 release
[
https://issues.apache.org/jira/browse/CASSANDRA-17570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-17570:
Status: Review In Progress (was: Patch Available)
> Update the CQL version for the 4.1 release
> --
>
> Key: CASSANDRA-17570
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17570
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Berenguer Blasi
>Priority: Urgent
> Fix For: 4.1-rc
>
>
> We made several changes to CQL during that version. We need to document those
> changes in the {{CQL.textile}} file and update the version.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17570) Update the CQL version for the 4.1 release
[
https://issues.apache.org/jira/browse/CASSANDRA-17570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-17570:
Status: Ready to Commit (was: Review In Progress)
> Update the CQL version for the 4.1 release
> --
>
> Key: CASSANDRA-17570
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17570
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Berenguer Blasi
>Priority: Urgent
> Fix For: 4.1-rc
>
>
> We made several changes to CQL during that version. We need to document those
> changes in the {{CQL.textile}} file and update the version.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16052) CEP-7 Storage Attached Indexes
[
https://issues.apache.org/jira/browse/CASSANDRA-16052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17564025#comment-17564025
]
Caleb Rackliffe commented on CASSANDRA-16052:
-
[~mikea] I've just rebased the [feature
branch|https://github.com/apache/cassandra/pull/1466] on trunk. The only real
source of conflicts (predictably) was the recent Memtable API work. I opted to
just leave out for now the bit that tracked the {{tracker}} in the old concrete
{{Memtable}}. Nothing here uses it yet anyway.
Otherwise, the only interesting thing was
https://github.com/apache/cassandra/pull/1466/files#diff-5cddfa459aa739fe34f47d3a810b0f88168b84a7510d6428abc9b60c6a649a32R820
Tests are running
[here|https://app.circleci.com/pipelines/github/maedhroz/cassandra?branch=CASSANDRA-16052].
In any case, the feature branch now should contain all the dependencies for SAI
proper.
> CEP-7 Storage Attached Indexes
> --
>
> Key: CASSANDRA-16052
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16052
> Project: Cassandra
> Issue Type: Epic
> Components: Feature/2i Index
>Reporter: Zhao Yang
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> [CEP|https://docs.google.com/document/d/1V830eAMmQAspjJdjviVZIaSolVGvZ1hVsqOLWyV0DS4/edit#heading=h.67ap6rr1mxr]
> - A new index implementation, called Storage
> Attached Index(SAI), based on the advancement made by SASI.
> * disk usage by sharing of common data between multiple column indexes on
> the same table and better compression of on-disk structures.
> * numeric range query performance with modified KDTree and collection type
> support.
> * compaction performance and stability for larger data set.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRASC-39) Allow for configuring Cassandra input validation parameters
Francisco Guerrero created CASSANDRASC-39:
-
Summary: Allow for configuring Cassandra input validation
parameters
Key: CASSANDRASC-39
URL: https://issues.apache.org/jira/browse/CASSANDRASC-39
Project: Sidecar for Apache Cassandra
Issue Type: New Feature
Reporter: Francisco Guerrero
Assignee: Francisco Guerrero
Currently, Cassandra input is validated using the
{{org.apache.cassandra.sidecar.common.utils.ValidationUtils}} class. This class
is a static class with hard-coded values for validation. It does not allow for
configuring different versions of Cassandra, or customizing the set of
forbidden keyspaces, the allowed characters for a keyspace / table, or the
allowed characters for a component.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-39) Allow for configuring Cassandra input validation parameters
[
https://issues.apache.org/jira/browse/CASSANDRASC-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francisco Guerrero updated CASSANDRASC-39:
--
Change Category: Operability
Complexity: Normal
Component/s: Configuration
Status: Open (was: Triage Needed)
> Allow for configuring Cassandra input validation parameters
> ---
>
> Key: CASSANDRASC-39
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-39
> Project: Sidecar for Apache Cassandra
> Issue Type: New Feature
> Components: Configuration
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
>
> Currently, Cassandra input is validated using the
> {{org.apache.cassandra.sidecar.common.utils.ValidationUtils}} class. This
> class is a static class with hard-coded values for validation. It does not
> allow for configuring different versions of Cassandra, or customizing the set
> of forbidden keyspaces, the allowed characters for a keyspace / table, or the
> allowed characters for a component.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17725) Add a flag for throughput in MiB/s for nodetool setstreamthroughput, getstreamthroughput, setinterdcstreamthroughput and getinterdcstreamthroughput
[
https://issues.apache.org/jira/browse/CASSANDRA-17725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563982#comment-17563982
]
Caleb Rackliffe edited comment on CASSANDRA-17725 at 7/7/22 9:25 PM:
-
{quote}The only thing I am wondering here is how to handle that nodetool and
the StorageService JMX methods are rounding to int and 0 very small values in
megabits to MiB/s (the getters in MiB, when we provide too small megabits) I
added in nodetool a check that will say instead of unlimited - 1 MiB/s. I plan
to document that when you use one or the other unit you should use the
respective setter/getter as otherwise you might see that side effect. Seeing 0
in MiB - someone might decide that they are unthrottling when in reality they
have super low value in megabits internally. What do others think about this?
{quote}
Why don't we just simplify things and leave MiB/s values as doubles everywhere?
If we do that for JMX and {{{}nodetool{}}}, can't we just sidestep the rounding
ambiguity almost entirely? (I mean, we still need to decide on how many
decimals we'll report, but we can probably do 2 or 3 and call it a day.) I
don't see any reason to force a rounded/integer output when it would only
materialize in conjunction with our new flag.
Other minor notes from my pass at review:
- In the {{MEGABITS_TO_MEBIBYTES_PER_SECOND_DATA_RATE}} JavaDoc, "megatibs" ->
"megabits"?
- There's enough in common that it might be nice to combine
{{SetGetInterDCStreamThroughputMiBTest}} and
{{SetGetInterDCStreamThroughputTest}} into a single
{{{}InterDCStreamThroughputConfigTest{}}}. (Same goes for the non-inter-DC
versions.)
- In {{{}StorageService{}}}, we have {{{}int oldValue = (int)
DatabaseDescriptor.getStreamThroughputOutboundMebibytesPerSec();{}}}. Why not
just get the existing value as a double and log it that way? (Happens in
{{setStreamThroughputMebibytesPerSec}} and
{{{}setInterDCStreamThroughputMebibytesPerSec{}}}.)
- Given we're going to a new major version, did we really have to change
{{MiB}} back to {{MB}} in [this
commit|https://github.com/ekaterinadimitrova2/cassandra/commit/92e0c3948fc65b29fbe289814f84aaf603188152]?
Even if someone was parsing tool output, they still would only break if they
explicitly validated "MB" rather than just making sure to take the numeric
value, right?
- Two things on {{"i", "stream_throughput_mib"}}. First, is the normal pattern
to use hyphens instead of underscores for the long form? Second, given this is
a modifier on the default argument, why not just use something like {{"m",
"mib"}}?
was (Author: maedhroz):
{quote}The only thing I am wondering here is how to handle that nodetool and
the StorageService JMX methods are rounding to int and 0 very small values in
megabits to MiB/s (the getters in MiB, when we provide too small megabits) I
added in nodetool a check that will say instead of unlimited - 1 MiB/s. I plan
to document that when you use one or the other unit you should use the
respective setter/getter as otherwise you might see that side effect. Seeing 0
in MiB - someone might decide that they are unthrottling when in reality they
have super low value in megabits internally. What do others think about this?
{quote}
Why don't we just simplify things and leave MiB/s values as doubles everywhere?
If we do that for JMX and {{{}nodetool{}}}, can't we just sidestep the rounding
ambiguity almost entirely? (I mean, we still need to decide on how many
decimals we'll report, but we can probably do 2 or 3 and call it a day.) I
don't see any reason to force a rounded/integer output when it would only
materialize in conjunction with our new flag.
Other minor notes from my pass at review:
- In the {{MEGABITS_TO_MEBIBYTES_PER_SECOND_DATA_RATE}} JavaDoc, "megatibs" ->
"megabits"?
- There's enough in common that it might be nice to combine
{{SetGetInterDCStreamThroughputMiBTest}} and
{{SetGetInterDCStreamThroughputTest}} into a single
{{{}InterDCStreamThroughputConfigTest{}}}. (Same goes for the non-inter-DC
versions.)
- In {{{}StorageService{}}}, we have {{{}int oldValue = (int)
DatabaseDescriptor.getStreamThroughputOutboundMebibytesPerSec();{}}}. Why not
just get the existing value as a double and log it that way? (Happens in
{{setStreamThroughputMebibytesPerSec}} and
{{{}setInterDCStreamThroughputMebibytesPerSec{}}}.)
- Given we're going to a new major version, did we really have to change
{{MiB}} back to {{MB}} in [this
commit|https://github.com/ekaterinadimitrova2/cassandra/commit/92e0c3948fc65b29fbe289814f84aaf603188152]?
Even if someone was parsing tool output, they still would only break if they
explicitly validated "MB" rather than just making sure to take the numeric
value, right?
- Two things on {{{}"{-}i", "{-}{-}stream_throughput_mib"{-}{}}}. First, is
the normal pattern to use hyphens instead of underscores
[jira] [Comment Edited] (CASSANDRA-17725) Add a flag for throughput in MiB/s for nodetool setstreamthroughput, getstreamthroughput, setinterdcstreamthroughput and getinterdcstreamthroughput
[
https://issues.apache.org/jira/browse/CASSANDRA-17725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563982#comment-17563982
]
Caleb Rackliffe edited comment on CASSANDRA-17725 at 7/7/22 9:24 PM:
-
{quote}The only thing I am wondering here is how to handle that nodetool and
the StorageService JMX methods are rounding to int and 0 very small values in
megabits to MiB/s (the getters in MiB, when we provide too small megabits) I
added in nodetool a check that will say instead of unlimited - 1 MiB/s. I plan
to document that when you use one or the other unit you should use the
respective setter/getter as otherwise you might see that side effect. Seeing 0
in MiB - someone might decide that they are unthrottling when in reality they
have super low value in megabits internally. What do others think about this?
{quote}
Why don't we just simplify things and leave MiB/s values as doubles everywhere?
If we do that for JMX and {{{}nodetool{}}}, can't we just sidestep the rounding
ambiguity almost entirely? (I mean, we still need to decide on how many
decimals we'll report, but we can probably do 2 or 3 and call it a day.) I
don't see any reason to force a rounded/integer output when it would only
materialize in conjunction with our new flag.
Other minor notes from my pass at review:
- In the {{MEGABITS_TO_MEBIBYTES_PER_SECOND_DATA_RATE}} JavaDoc, "megatibs" ->
"megabits"?
- There's enough in common that it might be nice to combine
{{SetGetInterDCStreamThroughputMiBTest}} and
{{SetGetInterDCStreamThroughputTest}} into a single
{{{}InterDCStreamThroughputConfigTest{}}}. (Same goes for the non-inter-DC
versions.)
- In {{{}StorageService{}}}, we have {{{}int oldValue = (int)
DatabaseDescriptor.getStreamThroughputOutboundMebibytesPerSec();{}}}. Why not
just get the existing value as a double and log it that way? (Happens in
{{setStreamThroughputMebibytesPerSec}} and
{{{}setInterDCStreamThroughputMebibytesPerSec{}}}.)
- Given we're going to a new major version, did we really have to change
{{MiB}} back to {{MB}} in [this
commit|https://github.com/ekaterinadimitrova2/cassandra/commit/92e0c3948fc65b29fbe289814f84aaf603188152]?
Even if someone was parsing tool output, they still would only break if they
explicitly validated "MB" rather than just making sure to take the numeric
value, right?
- Two things on {{{}"-i", "--stream_throughput_mib"{}}}. First, is the normal
pattern to use hyphens instead of underscores for the long form? Second, given
this is a modifier on the default argument, why not just use something like
{{{}"-m", "--mib"{}}}?
was (Author: maedhroz):
bq. The only thing I am wondering here is how to handle that nodetool and the
StorageService JMX methods are rounding to int and 0 very small values in
megabits to MiB/s (the getters in MiB, when we provide too small megabits) I
added in nodetool a check that will say instead of unlimited - 1 MiB/s. I plan
to document that when you use one or the other unit you should use the
respective setter/getter as otherwise you might see that side effect. Seeing 0
in MiB - someone might decide that they are unthrottling when in reality they
have super low value in megabits internally. What do others think about this?
Why don't we just simplify things and leave MiB/s values as doubles everywhere?
If we do that for JMX and {{nodetool}}, can't we just sidestep the rounding
ambiguity almost entirely? (I mean, we still need to decide on how many
decimals we'll report, but we can probably do 2 or 3 and call it a day.) I
don't see any reason to force a rounded/integer output when it would only
materialize in conjunction with our new flag.
Other minor notes from my pass at review:
- In the {{MEGABITS_TO_MEBIBYTES_PER_SECOND_DATA_RATE}} JavaDoc, "megatibs" ->
"megabits"?
- There's enough in common that it might be nice to combine
{{SetGetInterDCStreamThroughputMiBTest}} and
{{SetGetInterDCStreamThroughputTest}} into a single
{{InterDCStreamThroughputConfigTest}}. (Same goes for the non-inter-DC
versions.)
- In {{StorageService}}, we have {{int oldValue = (int)
DatabaseDescriptor.getStreamThroughputOutboundMebibytesPerSec();}}. Why not
just get the existing value as a double and log it that way? (Happens in
{{setStreamThroughputMebibytesPerSec}} and
{{setInterDCStreamThroughputMebibytesPerSec}}.)
- Given we're going to a new major version, did we really have to change
{{MiB}} back to {{MB}} in [this
commit|https://github.com/ekaterinadimitrova2/cassandra/commit/92e0c3948fc65b29fbe289814f84aaf603188152]?
Even if someone was parsing tool output, they still would only break if they
explicitly validated "MB" rather than just making sure to take the numeric
value, right?
- Two things on {{"-i", "--stream_throughput_mib"}}. First, is the normal
pattern to use hyphens instead of underscores for the long form? Second, given
[jira] [Comment Edited] (CASSANDRA-17725) Add a flag for throughput in MiB/s for nodetool setstreamthroughput, getstreamthroughput, setinterdcstreamthroughput and getinterdcstreamthroughput
[
https://issues.apache.org/jira/browse/CASSANDRA-17725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563982#comment-17563982
]
Caleb Rackliffe edited comment on CASSANDRA-17725 at 7/7/22 9:24 PM:
-
{quote}The only thing I am wondering here is how to handle that nodetool and
the StorageService JMX methods are rounding to int and 0 very small values in
megabits to MiB/s (the getters in MiB, when we provide too small megabits) I
added in nodetool a check that will say instead of unlimited - 1 MiB/s. I plan
to document that when you use one or the other unit you should use the
respective setter/getter as otherwise you might see that side effect. Seeing 0
in MiB - someone might decide that they are unthrottling when in reality they
have super low value in megabits internally. What do others think about this?
{quote}
Why don't we just simplify things and leave MiB/s values as doubles everywhere?
If we do that for JMX and {{{}nodetool{}}}, can't we just sidestep the rounding
ambiguity almost entirely? (I mean, we still need to decide on how many
decimals we'll report, but we can probably do 2 or 3 and call it a day.) I
don't see any reason to force a rounded/integer output when it would only
materialize in conjunction with our new flag.
Other minor notes from my pass at review:
- In the {{MEGABITS_TO_MEBIBYTES_PER_SECOND_DATA_RATE}} JavaDoc, "megatibs" ->
"megabits"?
- There's enough in common that it might be nice to combine
{{SetGetInterDCStreamThroughputMiBTest}} and
{{SetGetInterDCStreamThroughputTest}} into a single
{{{}InterDCStreamThroughputConfigTest{}}}. (Same goes for the non-inter-DC
versions.)
- In {{{}StorageService{}}}, we have {{{}int oldValue = (int)
DatabaseDescriptor.getStreamThroughputOutboundMebibytesPerSec();{}}}. Why not
just get the existing value as a double and log it that way? (Happens in
{{setStreamThroughputMebibytesPerSec}} and
{{{}setInterDCStreamThroughputMebibytesPerSec{}}}.)
- Given we're going to a new major version, did we really have to change
{{MiB}} back to {{MB}} in [this
commit|https://github.com/ekaterinadimitrova2/cassandra/commit/92e0c3948fc65b29fbe289814f84aaf603188152]?
Even if someone was parsing tool output, they still would only break if they
explicitly validated "MB" rather than just making sure to take the numeric
value, right?
- Two things on {{{}"{-}i", "{-}{-}stream_throughput_mib"{-}{}}}. First, is
the normal pattern to use hyphens instead of underscores for the long form?
Second, given this is a modifier on the default argument, why not just use
something like {{{}"-m", "--mib"{}}}?
was (Author: maedhroz):
{quote}The only thing I am wondering here is how to handle that nodetool and
the StorageService JMX methods are rounding to int and 0 very small values in
megabits to MiB/s (the getters in MiB, when we provide too small megabits) I
added in nodetool a check that will say instead of unlimited - 1 MiB/s. I plan
to document that when you use one or the other unit you should use the
respective setter/getter as otherwise you might see that side effect. Seeing 0
in MiB - someone might decide that they are unthrottling when in reality they
have super low value in megabits internally. What do others think about this?
{quote}
Why don't we just simplify things and leave MiB/s values as doubles everywhere?
If we do that for JMX and {{{}nodetool{}}}, can't we just sidestep the rounding
ambiguity almost entirely? (I mean, we still need to decide on how many
decimals we'll report, but we can probably do 2 or 3 and call it a day.) I
don't see any reason to force a rounded/integer output when it would only
materialize in conjunction with our new flag.
Other minor notes from my pass at review:
- In the {{MEGABITS_TO_MEBIBYTES_PER_SECOND_DATA_RATE}} JavaDoc, "megatibs" ->
"megabits"?
- There's enough in common that it might be nice to combine
{{SetGetInterDCStreamThroughputMiBTest}} and
{{SetGetInterDCStreamThroughputTest}} into a single
{{{}InterDCStreamThroughputConfigTest{}}}. (Same goes for the non-inter-DC
versions.)
- In {{{}StorageService{}}}, we have {{{}int oldValue = (int)
DatabaseDescriptor.getStreamThroughputOutboundMebibytesPerSec();{}}}. Why not
just get the existing value as a double and log it that way? (Happens in
{{setStreamThroughputMebibytesPerSec}} and
{{{}setInterDCStreamThroughputMebibytesPerSec{}}}.)
- Given we're going to a new major version, did we really have to change
{{MiB}} back to {{MB}} in [this
commit|https://github.com/ekaterinadimitrova2/cassandra/commit/92e0c3948fc65b29fbe289814f84aaf603188152]?
Even if someone was parsing tool output, they still would only break if they
explicitly validated "MB" rather than just making sure to take the numeric
value, right?
- Two things on {{{}"-i", "--stream_throughput_mib"{}}}. First, is the normal
pattern to use hyphens instead
[jira] [Commented] (CASSANDRA-17725) Add a flag for throughput in MiB/s for nodetool setstreamthroughput, getstreamthroughput, setinterdcstreamthroughput and getinterdcstreamthroughput
[
https://issues.apache.org/jira/browse/CASSANDRA-17725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563982#comment-17563982
]
Caleb Rackliffe commented on CASSANDRA-17725:
-
bq. The only thing I am wondering here is how to handle that nodetool and the
StorageService JMX methods are rounding to int and 0 very small values in
megabits to MiB/s (the getters in MiB, when we provide too small megabits) I
added in nodetool a check that will say instead of unlimited - 1 MiB/s. I plan
to document that when you use one or the other unit you should use the
respective setter/getter as otherwise you might see that side effect. Seeing 0
in MiB - someone might decide that they are unthrottling when in reality they
have super low value in megabits internally. What do others think about this?
Why don't we just simplify things and leave MiB/s values as doubles everywhere?
If we do that for JMX and {{nodetool}}, can't we just sidestep the rounding
ambiguity almost entirely? (I mean, we still need to decide on how many
decimals we'll report, but we can probably do 2 or 3 and call it a day.) I
don't see any reason to force a rounded/integer output when it would only
materialize in conjunction with our new flag.
Other minor notes from my pass at review:
- In the {{MEGABITS_TO_MEBIBYTES_PER_SECOND_DATA_RATE}} JavaDoc, "megatibs" ->
"megabits"?
- There's enough in common that it might be nice to combine
{{SetGetInterDCStreamThroughputMiBTest}} and
{{SetGetInterDCStreamThroughputTest}} into a single
{{InterDCStreamThroughputConfigTest}}. (Same goes for the non-inter-DC
versions.)
- In {{StorageService}}, we have {{int oldValue = (int)
DatabaseDescriptor.getStreamThroughputOutboundMebibytesPerSec();}}. Why not
just get the existing value as a double and log it that way? (Happens in
{{setStreamThroughputMebibytesPerSec}} and
{{setInterDCStreamThroughputMebibytesPerSec}}.)
- Given we're going to a new major version, did we really have to change
{{MiB}} back to {{MB}} in [this
commit|https://github.com/ekaterinadimitrova2/cassandra/commit/92e0c3948fc65b29fbe289814f84aaf603188152]?
Even if someone was parsing tool output, they still would only break if they
explicitly validated "MB" rather than just making sure to take the numeric
value, right?
- Two things on {{"-i", "--stream_throughput_mib"}}. First, is the normal
pattern to use hyphens instead of underscores for the long form? Second, given
this is a modifier on the default argument, why not just use something like
{{"-m", "--mib"}}?
> Add a flag for throughput in MiB/s for nodetool setstreamthroughput,
> getstreamthroughput, setinterdcstreamthroughput and
> getinterdcstreamthroughput
>
>
> Key: CASSANDRA-17725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17725
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> As we agreed not to add new JMX methods for the new config on the mailing
> list, we need at least new flags for setstreamthroughput and
> interdcstreamthroughput for the two 4.0 parameters to be set/get also in MiB,
> not only in megabits.
> Thus we will have the option either to use the old version for those 2, or to
> be able to set/get in MiB all 4 streaming parameters. As of 4.1 supported
> units for DataRateSpec are MiB/s, B/s, KiB/s, megabit is only for legacy from
> 4.0 - backward compatibility.
> To be sure we satisfy the requirements around the latest discussions about
> backward compatibility in tools, I will use this ticket also to make a final
> pass on the unit changes done, to ensure the probe output is not affected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (dbcdf00a -> 063a5f03)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard dbcdf00a generate docs for 22eba1cc new 063a5f03 generate docs for 22eba1cc This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (dbcdf00a) \ N -- N -- N refs/heads/asf-staging (063a5f03) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4740078 -> 4740078 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (5f2f5b7a -> dbcdf00a)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 5f2f5b7a generate docs for 22eba1cc new dbcdf00a generate docs for 22eba1cc This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (5f2f5b7a) \ N -- N -- N refs/heads/asf-staging (dbcdf00a) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4740078 -> 4740078 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (ad00a0a8 -> 5f2f5b7a)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git omit ad00a0a8 generate docs for 22eba1cc new 5f2f5b7a generate docs for 22eba1cc This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (ad00a0a8) \ N -- N -- N refs/heads/asf-staging (5f2f5b7a) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4740078 -> 4740078 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17725) Add a flag for throughput in MiB/s for nodetool setstreamthroughput, getstreamthroughput, setinterdcstreamthroughput and getinterdcstreamthroughput
[
https://issues.apache.org/jira/browse/CASSANDRA-17725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563903#comment-17563903
]
Caleb Rackliffe commented on CASSANDRA-17725:
-
If the original logic had been...
{noformat}
while (nanoTime() <= loadByNanos && in.available() > 0)
{noformat}
...perhaps you could have imagined a case for zero where the clock didn't
advance, and you would have been able to load the first table in the while
body, but that seems pretty esoteric.
> Add a flag for throughput in MiB/s for nodetool setstreamthroughput,
> getstreamthroughput, setinterdcstreamthroughput and
> getinterdcstreamthroughput
>
>
> Key: CASSANDRA-17725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17725
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> As we agreed not to add new JMX methods for the new config on the mailing
> list, we need at least new flags for setstreamthroughput and
> interdcstreamthroughput for the two 4.0 parameters to be set/get also in MiB,
> not only in megabits.
> Thus we will have the option either to use the old version for those 2, or to
> be able to set/get in MiB all 4 streaming parameters. As of 4.1 supported
> units for DataRateSpec are MiB/s, B/s, KiB/s, megabit is only for legacy from
> 4.0 - backward compatibility.
> To be sure we satisfy the requirements around the latest discussions about
> backward compatibility in tools, I will use this ticket also to make a final
> pass on the unit changes done, to ensure the probe output is not affected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17725) Add a flag for throughput in MiB/s for nodetool setstreamthroughput, getstreamthroughput, setinterdcstreamthroughput and getinterdcstreamthroughput
[
https://issues.apache.org/jira/browse/CASSANDRA-17725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563902#comment-17563902
]
Caleb Rackliffe commented on CASSANDRA-17725:
-
bq. maybe we can use the NEGATIVE_SECONDS_DURATION converter from the
Converters class we added for validation_preview_purge_head_start which will
convert a negative number to 0 in 4.1 and tell people from now on will use 0 to
disable but at the same time if they upgrade with negative and the old value
format and property name, they will be able to set negative number which will
be migrated internally to 0. I am really not completely sure, what do others
think?
The sequence in the code is...
{noformat}
long start = nanoTime();
...
long loadByNanos = start +
TimeUnit.SECONDS.toNanos(DatabaseDescriptor.getCacheLoadTimeout());
while (nanoTime() < loadByNanos && in.available() > 0)
{
// do saved cache loading stuff
{noformat}
So unless the high-resolution clock goes backwards, -1 and 0 should have the
same effect. (i.e. {{start == loadByNanos}} and getting {{nanoTime()}} again
should be >= {{start}}) The condition of the {{while}} loop, if interpreted
strictly as "don't try any more saved cache loading if we've hit the load-by
time", is fine, and I think the only concern we have is making sure an
inherited -1 from an old config doesn't make things explode. (There was never
any explicit checking for -1 in the original patch that I can see.)
> Add a flag for throughput in MiB/s for nodetool setstreamthroughput,
> getstreamthroughput, setinterdcstreamthroughput and
> getinterdcstreamthroughput
>
>
> Key: CASSANDRA-17725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17725
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> As we agreed not to add new JMX methods for the new config on the mailing
> list, we need at least new flags for setstreamthroughput and
> interdcstreamthroughput for the two 4.0 parameters to be set/get also in MiB,
> not only in megabits.
> Thus we will have the option either to use the old version for those 2, or to
> be able to set/get in MiB all 4 streaming parameters. As of 4.1 supported
> units for DataRateSpec are MiB/s, B/s, KiB/s, megabit is only for legacy from
> 4.0 - backward compatibility.
> To be sure we satisfy the requirements around the latest discussions about
> backward compatibility in tools, I will use this ticket also to make a final
> pass on the unit changes done, to ensure the probe output is not affected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17725) Add a flag for throughput in MiB/s for nodetool setstreamthroughput, getstreamthroughput, setinterdcstreamthroughput and getinterdcstreamthroughput
[ https://issues.apache.org/jira/browse/CASSANDRA-17725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-17725: Reviewers: Caleb Rackliffe, Caleb Rackliffe Caleb Rackliffe, Caleb Rackliffe (was: Caleb Rackliffe) Status: Review In Progress (was: Patch Available) > Add a flag for throughput in MiB/s for nodetool setstreamthroughput, > getstreamthroughput, setinterdcstreamthroughput and > getinterdcstreamthroughput > > > Key: CASSANDRA-17725 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17725 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.1-beta, 4.x > > > As we agreed not to add new JMX methods for the new config on the mailing > list, we need at least new flags for setstreamthroughput and > interdcstreamthroughput for the two 4.0 parameters to be set/get also in MiB, > not only in megabits. > Thus we will have the option either to use the old version for those 2, or to > be able to set/get in MiB all 4 streaming parameters. As of 4.1 supported > units for DataRateSpec are MiB/s, B/s, KiB/s, megabit is only for legacy from > 4.0 - backward compatibility. > To be sure we satisfy the requirements around the latest discussions about > backward compatibility in tools, I will use this ticket also to make a final > pass on the unit changes done, to ensure the probe output is not affected. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17729) Raise test timeouts
[ https://issues.apache.org/jira/browse/CASSANDRA-17729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563838#comment-17563838 ] Josh McKenzie commented on CASSANDRA-17729: --- bq. at the moment jenkins is our official CI so any bugs there need ironing In my mind there's a distinction between a "test bug" and a "product bug". I don't deny we have many of the former, but we may not agree on the relative value of spending time fixing things that only show up in highly contended, lowly provisioned test runtime environments. Let's continue this discussion on the dev ML thread? > Raise test timeouts > --- > > Key: CASSANDRA-17729 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17729 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.1-beta > > > We have seen for some time now junits timeout frequently on jenkins. This is > probably down to it being a very loaded env. On circle we don't observe that > behavior probably bc it's not so loaded. > The question is whether it is time to raise timeouts as they might be hiding > legit failures. As en experiment I raised timeouts in a branch and ran > jenkins against it. What I see is that the last 4.1 run had 14 failures out > of which 12 were timeouts. Increasing timeouts reveals what looks to be 9 > legit failures where 2 are timeouts that probably need to be investigated. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17741) WEBSITE - July 2022 blog "Apache Cassandra 4.1: Configuration Standardization"
[
https://issues.apache.org/jira/browse/CASSANDRA-17741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563794#comment-17563794
]
Erick Ramirez commented on CASSANDRA-17741:
---
I’ve completed final verification in staging and [published to
production|https://github.com/apache/cassandra-website#merging-asf-staging-to-asf-site]:
{noformat}
$ git branch
* trunk
$ git fetch origin
$ git checkout asf-site
Branch ‘asf-site’ set up to track remote branch ‘asf-site’ from ‘origin’.
Switched to a new branch ‘asf-site’
$ git branch
* asf-site
trunk
$ git reset --hard origin/asf-staging
HEAD is now at ad00a0a8 generate docs for 22eba1cc
$ git push -f origin asf-site
Username for ‘https://github.com’: erickramirezau
Password for ‘https://erickramire...@github.com’:
Total 0 (delta 0), reused 0 (delta 0)
To https://github.com/apache/cassandra-website.git
+ c672d00a...ad00a0a8 asf-site -> asf-site (forced update)
{noformat}
The blog post is now live on the site –
https://cassandra.apache.org/_/blog/Apache-Cassandra-4.1-Configuration-Standardization.html
> WEBSITE - July 2022 blog "Apache Cassandra 4.1: Configuration Standardization"
> --
>
> Key: CASSANDRA-17741
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17741
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Diogenese Topper
>Assignee: Erick Ramirez
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.1.x
>
> Attachments: CASSANDRA-17741v2.patch, PR151-01-summary_truncated.png,
> PR151-02-incorrect_list_format.png, c17741-01-blog-index.png,
> c17741-02-blog-post.png
>
>
> This ticket is to capture the work associated with publishing the June 2022
> blog "Apache Cassandra 4.1: Configuration Standardization"
> If this blog cannot be published by the *July 7, 2022 publish date*, please
> contact me, suggest changes, or correct the date when possible in the pull
> request for the appropriate time that the blog will go live (on both the
> blog.adoc and the blog post's file).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-site updated (c672d00a -> ad00a0a8)
This is an automated email from the ASF dual-hosted git repository.
erickramirezau pushed a change to branch asf-site
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git
discard c672d00a generate docs for 07cc189e
add 22eba1cc BLOG - Configuration Standardization in 4.1
add ad00a0a8 generate docs for 22eba1cc
This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version. This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:
* -- * -- B -- O -- O -- O (c672d00a)
\
N -- N -- N refs/heads/asf-site (ad00a0a8)
You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.
Any revisions marked "omit" are not gone; other references still
refer to them. Any revisions marked "discard" are gone forever.
No new revisions were added by this update.
Summary of changes:
...ion-standardization-unsplash-cookie-the-pom.jpg | Bin 0 -> 71230 bytes
content/_/blog.html| 24 +
...ssandra-4.1-Configuration-Standardization.html} | 113 +
content/search-index.js| 2 +-
...ion-standardization-unsplash-cookie-the-pom.jpg | Bin 0 -> 71230 bytes
site-content/source/modules/ROOT/pages/blog.adoc | 25 +
...assandra-4.1-Configuration-Standardization.adoc | 60 +++
site-ui/build/ui-bundle.zip| Bin 4740078 -> 4740078
bytes
8 files changed, 160 insertions(+), 64 deletions(-)
create mode 100644
content/_/_images/blog/apache-cassandra-4.1-configuration-standardization-unsplash-cookie-the-pom.jpg
copy
content/_/blog/{Apache-Cassandra-4.1-Features-Client-side-Password-Hashing.html
=> Apache-Cassandra-4.1-Configuration-Standardization.html} (67%)
create mode 100644
site-content/source/modules/ROOT/images/blog/apache-cassandra-4.1-configuration-standardization-unsplash-cookie-the-pom.jpg
create mode 100644
site-content/source/modules/ROOT/pages/blog/Apache-Cassandra-4.1-Configuration-Standardization.adoc
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17741) WEBSITE - July 2022 blog "Apache Cassandra 4.1: Configuration Standardization"
[ https://issues.apache.org/jira/browse/CASSANDRA-17741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563791#comment-17563791 ] Erick Ramirez commented on CASSANDRA-17741: --- The blog post is now in staging – https://cassandra.staged.apache.org/_/blog/Apache-Cassandra-4.1-Configuration-Standardization.html > WEBSITE - July 2022 blog "Apache Cassandra 4.1: Configuration Standardization" > -- > > Key: CASSANDRA-17741 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17741 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.1.x > > Attachments: CASSANDRA-17741v2.patch, PR151-01-summary_truncated.png, > PR151-02-incorrect_list_format.png, c17741-01-blog-index.png, > c17741-02-blog-post.png > > > This ticket is to capture the work associated with publishing the June 2022 > blog "Apache Cassandra 4.1: Configuration Standardization" > If this blog cannot be published by the *July 7, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (f6a0710c -> ad00a0a8)
This is an automated email from the ASF dual-hosted git repository.
git-site-role pushed a change to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git
discard f6a0710c generate docs for 07cc189e
add 22eba1cc BLOG - Configuration Standardization in 4.1
new ad00a0a8 generate docs for 22eba1cc
This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version. This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:
* -- * -- B -- O -- O -- O (f6a0710c)
\
N -- N -- N refs/heads/asf-staging (ad00a0a8)
You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.
Any revisions marked "omit" are not gone; other references still
refer to them. Any revisions marked "discard" are gone forever.
The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
...ion-standardization-unsplash-cookie-the-pom.jpg | Bin 0 -> 71230 bytes
content/_/blog.html| 24 +
...ssandra-4.1-Configuration-Standardization.html} | 113 +
content/search-index.js| 2 +-
...ion-standardization-unsplash-cookie-the-pom.jpg | Bin 0 -> 71230 bytes
site-content/source/modules/ROOT/pages/blog.adoc | 25 +
...assandra-4.1-Configuration-Standardization.adoc | 60 +++
site-ui/build/ui-bundle.zip| Bin 4740078 -> 4740078
bytes
8 files changed, 160 insertions(+), 64 deletions(-)
create mode 100644
content/_/_images/blog/apache-cassandra-4.1-configuration-standardization-unsplash-cookie-the-pom.jpg
copy
content/_/blog/{Apache-Cassandra-4.1-Features-Client-side-Password-Hashing.html
=> Apache-Cassandra-4.1-Configuration-Standardization.html} (67%)
create mode 100644
site-content/source/modules/ROOT/images/blog/apache-cassandra-4.1-configuration-standardization-unsplash-cookie-the-pom.jpg
create mode 100644
site-content/source/modules/ROOT/pages/blog/Apache-Cassandra-4.1-Configuration-Standardization.adoc
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17741) WEBSITE - July 2022 blog "Apache Cassandra 4.1: Configuration Standardization"
[
https://issues.apache.org/jira/browse/CASSANDRA-17741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563783#comment-17563783
]
Erick Ramirez commented on CASSANDRA-17741:
---
The website content is getting built in staging:
||Branch||PR||Commit||Build||
|{{trunk}}|[#151|https://github.com/apache/cassandra-website/pull/151]|[22eba1c
|https://github.com/apache/cassandra-website/commit/22eba1ccbcc1c874cb0cd868b5745797fc578a4d]|[#391|https://ci-cassandra.apache.org/job/cassandra-website/391/]|
> WEBSITE - July 2022 blog "Apache Cassandra 4.1: Configuration Standardization"
> --
>
> Key: CASSANDRA-17741
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17741
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Diogenese Topper
>Assignee: Erick Ramirez
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.1.x
>
> Attachments: CASSANDRA-17741v2.patch, PR151-01-summary_truncated.png,
> PR151-02-incorrect_list_format.png, c17741-01-blog-index.png,
> c17741-02-blog-post.png
>
>
> This ticket is to capture the work associated with publishing the June 2022
> blog "Apache Cassandra 4.1: Configuration Standardization"
> If this blog cannot be published by the *July 7, 2022 publish date*, please
> contact me, suggest changes, or correct the date when possible in the pull
> request for the appropriate time that the blog will go live (on both the
> blog.adoc and the blog post's file).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17741) WEBSITE - July 2022 blog "Apache Cassandra 4.1: Configuration Standardization"
[
https://issues.apache.org/jira/browse/CASSANDRA-17741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-17741:
--
Source Control Link:
https://github.com/apache/cassandra-website/commit/22eba1ccbcc1c874cb0cd868b5745797fc578a4d
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed:
||Branch||PR||Commit||
|{{trunk}}|[#151|https://github.com/apache/cassandra-website/pull/151]|[22eba1c
|https://github.com/apache/cassandra-website/commit/22eba1ccbcc1c874cb0cd868b5745797fc578a4d]|
> WEBSITE - July 2022 blog "Apache Cassandra 4.1: Configuration Standardization"
> --
>
> Key: CASSANDRA-17741
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17741
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Diogenese Topper
>Assignee: Erick Ramirez
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.1.x
>
> Attachments: CASSANDRA-17741v2.patch, PR151-01-summary_truncated.png,
> PR151-02-incorrect_list_format.png, c17741-01-blog-index.png,
> c17741-02-blog-post.png
>
>
> This ticket is to capture the work associated with publishing the June 2022
> blog "Apache Cassandra 4.1: Configuration Standardization"
> If this blog cannot be published by the *July 7, 2022 publish date*, please
> contact me, suggest changes, or correct the date when possible in the pull
> request for the appropriate time that the blog will go live (on both the
> blog.adoc and the blog post's file).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17741) WEBSITE - July 2022 blog "Apache Cassandra 4.1: Configuration Standardization"
[ https://issues.apache.org/jira/browse/CASSANDRA-17741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17741: -- Status: Ready to Commit (was: Changes Suggested) I've made the necessary adjustments/fixes. See [^CASSANDRA-17741v2.patch] for the full details. !c17741-01-blog-index.png|width=300! !c17741-02-blog-post.png|width=300! > WEBSITE - July 2022 blog "Apache Cassandra 4.1: Configuration Standardization" > -- > > Key: CASSANDRA-17741 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17741 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.1.x > > Attachments: CASSANDRA-17741v2.patch, PR151-01-summary_truncated.png, > PR151-02-incorrect_list_format.png, c17741-01-blog-index.png, > c17741-02-blog-post.png > > > This ticket is to capture the work associated with publishing the June 2022 > blog "Apache Cassandra 4.1: Configuration Standardization" > If this blog cannot be published by the *July 7, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch trunk updated: BLOG - Configuration Standardization in 4.1
This is an automated email from the ASF dual-hosted git repository. erickramirezau pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-website.git The following commit(s) were added to refs/heads/trunk by this push: new 22eba1cc BLOG - Configuration Standardization in 4.1 22eba1cc is described below commit 22eba1ccbcc1c874cb0cd868b5745797fc578a4d Author: Diogenese Topper AuthorDate: Wed Jul 6 12:29:49 2022 -0700 BLOG - Configuration Standardization in 4.1 patch by Ekaterina Dimitrova, Chris Thornett, Diogenese Topper; reviewed by Erick Ramirez for CASSANDRA-17741 Co-authored by: Ekaterina Dimitrova Co-authored by: Chris Thornett Co-authored by: Diogenese Topper --- ...ion-standardization-unsplash-cookie-the-pom.jpg | Bin 0 -> 71230 bytes site-content/source/modules/ROOT/pages/blog.adoc | 25 + ...assandra-4.1-Configuration-Standardization.adoc | 60 + 3 files changed, 85 insertions(+) diff --git a/site-content/source/modules/ROOT/images/blog/apache-cassandra-4.1-configuration-standardization-unsplash-cookie-the-pom.jpg b/site-content/source/modules/ROOT/images/blog/apache-cassandra-4.1-configuration-standardization-unsplash-cookie-the-pom.jpg new file mode 100644 index ..08b845a4 Binary files /dev/null and b/site-content/source/modules/ROOT/images/blog/apache-cassandra-4.1-configuration-standardization-unsplash-cookie-the-pom.jpg differ diff --git a/site-content/source/modules/ROOT/pages/blog.adoc b/site-content/source/modules/ROOT/pages/blog.adoc index a6cafd19..3e82a86d 100644 --- a/site-content/source/modules/ROOT/pages/blog.adoc +++ b/site-content/source/modules/ROOT/pages/blog.adoc @@ -8,6 +8,31 @@ NOTES FOR CONTENT CREATORS - Replace post tile, date, description and link to you post. +//start card +[openblock,card shadow relative test] + +[openblock,card-header] +-- +[discrete] +=== Apache Cassandra 4.1: Configuration Standardization +[discrete] + July 7, 2022 +-- +[openblock,card-content] +-- +Introducting the New configuration framework for standardized property names and units, and provide more flexibility to end users. + +[openblock,card-btn card-btn--blog] + + +[.btn.btn--alt] +xref:blog/Apache-Cassandra-4.1-Configuration-Standardization.adoc[Read More] + + +-- + +//end card + //start card [openblock,card shadow relative test] diff --git a/site-content/source/modules/ROOT/pages/blog/Apache-Cassandra-4.1-Configuration-Standardization.adoc b/site-content/source/modules/ROOT/pages/blog/Apache-Cassandra-4.1-Configuration-Standardization.adoc new file mode 100644 index ..c061527a --- /dev/null +++ b/site-content/source/modules/ROOT/pages/blog/Apache-Cassandra-4.1-Configuration-Standardization.adoc @@ -0,0 +1,60 @@ += Apache Cassandra 4.1: Configuration Standardization +:page-layout: single-post +:page-role: blog-post +:page-post-date: 7 July, 2022 +:page-post-author: Ekaterina Dimitrova +:description: Configuration standardization in Apache Cassandra 4.1 +:keywords: configuration, apache cassandra, 4.1 + +:!figure-caption: + +.Image credit: https://unsplash.com/@cookiethepom[Cookie the Pom on Unsplash^] +image::blog/apache-cassandra-4.1-configuration-standardization-unsplash-cookie-the-pom.jpg[Configuration Standardization] + +Apache Cassandra comes with a long list of configuration parameters in cassandra.yaml. A big part of them represent parameters of type duration, data storage, or data rate. Up until 4.1 all of them were set with different units (every parameter name had its unit identified by a suffix to its name). On the other hand our naming conventions were not always clear. For example, “abort” and “fail” were used interchangeably and there was no predefined order as we have now - `noun_verb` (`enabl [...] + +This had the potential to create a lot of confusion for end users and Cassandra developers. To strengthen our configuration and also to provide more flexibility to the end users, we created a new configuration framework with the following goals: + +. Standardize names and units while keeping backward compatibility with the old names, units and values format. +. Create flexibility for end users to provide units of their choice from a predefined list of units for parameters of type data storage, data rate, and duration. For example, this old property: ++ + +permissions_update_interval_ms: 0 + ++ +can now be written in any of these ways: ++ + +permissions_update_interval: 0ms +permissions_update_interval: 0s +permissions_update_interval: 0d +permissions_update_interval: 0us +permissions_update_interval: 0µs + + +. Provide an easier and uniform way to add new parameters for Cassandra developers with the goal of reducing the chances of introducing bugs when adding new parameters. +. The approach for backward compatibility can be reused for more
[jira] [Updated] (CASSANDRA-17741) WEBSITE - July 2022 blog "Apache Cassandra 4.1: Configuration Standardization"
[ https://issues.apache.org/jira/browse/CASSANDRA-17741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17741: -- Attachment: c17741-02-blog-post.png c17741-01-blog-index.png > WEBSITE - July 2022 blog "Apache Cassandra 4.1: Configuration Standardization" > -- > > Key: CASSANDRA-17741 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17741 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.1.x > > Attachments: CASSANDRA-17741v2.patch, PR151-01-summary_truncated.png, > PR151-02-incorrect_list_format.png, c17741-01-blog-index.png, > c17741-02-blog-post.png > > > This ticket is to capture the work associated with publishing the June 2022 > blog "Apache Cassandra 4.1: Configuration Standardization" > If this blog cannot be published by the *July 7, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17741) WEBSITE - July 2022 blog "Apache Cassandra 4.1: Configuration Standardization"
[ https://issues.apache.org/jira/browse/CASSANDRA-17741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17741: -- Attachment: CASSANDRA-17741v2.patch > WEBSITE - July 2022 blog "Apache Cassandra 4.1: Configuration Standardization" > -- > > Key: CASSANDRA-17741 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17741 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.1.x > > Attachments: CASSANDRA-17741v2.patch, PR151-01-summary_truncated.png, > PR151-02-incorrect_list_format.png > > > This ticket is to capture the work associated with publishing the June 2022 > blog "Apache Cassandra 4.1: Configuration Standardization" > If this blog cannot be published by the *July 7, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15511) Utilising BTree Improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-15511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15511:
---
Fix Version/s: 4.0.5
4.1-alpha
(was: 4.x)
(was: 4.0.x)
(was: 4.1.x)
Source Control Link:
https://github.com/apache/cassandra/commit/c378874a9fa123891d1d75177d99dba5c4d18f9b
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed into cassandra-4.0 at c378874a9fa123891d1d75177d99dba5c4d18f9b and
merged into cassandra-4.1 and trunk
> Utilising BTree Improvements
>
>
> Key: CASSANDRA-15511
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15511
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.0.5, 4.1-alpha
>
> Attachments: atomicbtreepartition.ods, atomicbtreepartition.xlsx.zip,
> perfsh.tar.gz
>
>
> This patch utilises CASSANDRA-15510 to improve throughput and reduce garbage
> produced by a number of common operations, by employing
> {{transformAndFilter}}, {{transform}} and {{FastBuilder}}
> * {{Row}}, {{Cell}} and {{ComplexColumnData}} cloning are implemented with
> {{BTree.transform}}, so no special builders are necessary;
> ** {{Rows.copy}} removed
> * {{Rows.merge}} implemented using {{BTree.update}} and a {{ColumnData}}
> reconciler
> ** Zero-allocations if result of merge is same as {{existing}}
> ** Fewer comparisons
> * {{ColumnData}} reconciler implemented in same manner
> ** {{Cells.reconcileComplex}} is retired
> ** {{ComplexColumnData}} reconciliation now
> *** Garbage-free if the merge has no effect
> *** Always fewer allocations
> *** Fewer comparisons
> * {{FastBuilder}} employed widely:
> ** {{ClusteringIndexNamesFilter}} deserialization
> ** {{Columns}} deserialization
> ** {{PartitionUpdate}} deserialization
> ** {{AbstractBTreePartition}} construction
> ** Misc others
> The upshot of this work when combined with the proposed patch for
> CASSANDRA-15367 has a dramatic impact on operations over collection types -
> under contention, as much as 100x improved throughput, and hundreds of
> megabytes of reduced allocations. For all operations, allocations under
> contention and no contention are significantly reduced and throughput
> improved.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17741) WEBSITE - July 2022 blog "Apache Cassandra 4.1: Configuration Standardization"
[
https://issues.apache.org/jira/browse/CASSANDRA-17741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563761#comment-17563761
]
Erick Ramirez edited comment on CASSANDRA-17741 at 7/7/22 12:35 PM:
I've noted the following:
* The cards on the blog index page can only have a maximum of 175 characters
(about 20-22 words). The summary is too long so it got truncated:
!PR151-01-summary_truncated.png|width=100!
* The list in the second paragraph is incorrectly formatted so they don't
render as bullet points:
!PR151-02-incorrect_list_format.png|width=300!
* The {{/doc}} pages are hard-linked instead of using the Asciidoc
{{link:/doc}} macro. For example:
{quote}For a full list of affected parameters, mapping of old to new names and
supported units and how things work in general, please, refer to the
https://cassandra.apache.org/doc/trunk/cassandra/new/configuration.html[documentation^].{quote}
was (Author: JIRAUSER285101):
I've noted the following:
* The cards on the blog index page can only have a maximum of 175 characters
(about 20-22 words). The summary is too long so it got truncated:
!PR151-01-summary_truncated.png|width=300!
* The list in the second paragraph is incorrectly formatted so they don't
render as bullet points:
!PR151-02-incorrect_list_format.png|width=300!
* The {{/doc}} pages are hard-linked instead of using the Asciidoc
{{link:/doc}} macro. For example:
{quote}For a full list of affected parameters, mapping of old to new names and
supported units and how things work in general, please, refer to the
https://cassandra.apache.org/doc/trunk/cassandra/new/configuration.html[documentation^].{quote}
> WEBSITE - July 2022 blog "Apache Cassandra 4.1: Configuration Standardization"
> --
>
> Key: CASSANDRA-17741
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17741
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Diogenese Topper
>Assignee: Erick Ramirez
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.1.x
>
> Attachments: PR151-01-summary_truncated.png,
> PR151-02-incorrect_list_format.png
>
>
> This ticket is to capture the work associated with publishing the June 2022
> blog "Apache Cassandra 4.1: Configuration Standardization"
> If this blog cannot be published by the *July 7, 2022 publish date*, please
> contact me, suggest changes, or correct the date when possible in the pull
> request for the appropriate time that the blog will go live (on both the
> blog.adoc and the blog post's file).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17741) WEBSITE - July 2022 blog "Apache Cassandra 4.1: Configuration Standardization"
[
https://issues.apache.org/jira/browse/CASSANDRA-17741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-17741:
--
Status: Changes Suggested (was: Review In Progress)
I've noted the following:
* The cards on the blog index page can only have a maximum of 175 characters
(about 20-22 words). The summary is too long so it got truncated:
!PR151-01-summary_truncated.png|width=300!
* The list in the second paragraph is incorrectly formatted so they don't
render as bullet points:
!PR151-02-incorrect_list_format.png|width=300!
* The {{/doc}} pages are hard-linked instead of using the Asciidoc
{{link:/doc}} macro. For example:
{quote}For a full list of affected parameters, mapping of old to new names and
supported units and how things work in general, please, refer to the
https://cassandra.apache.org/doc/trunk/cassandra/new/configuration.html[documentation^].{quote}
> WEBSITE - July 2022 blog "Apache Cassandra 4.1: Configuration Standardization"
> --
>
> Key: CASSANDRA-17741
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17741
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Diogenese Topper
>Assignee: Erick Ramirez
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.1.x
>
> Attachments: PR151-01-summary_truncated.png,
> PR151-02-incorrect_list_format.png
>
>
> This ticket is to capture the work associated with publishing the June 2022
> blog "Apache Cassandra 4.1: Configuration Standardization"
> If this blog cannot be published by the *July 7, 2022 publish date*, please
> contact me, suggest changes, or correct the date when possible in the pull
> request for the appropriate time that the blog will go live (on both the
> blog.adoc and the blog post's file).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch cassandra-4.1 into trunk
This is an automated email from the ASF dual-hosted git repository. blerer pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit b29ad8823a20d910a0b9b984b06421f390cc0a17 Merge: ab0a9b5f5c 50e7a3f5df Author: Benjamin Lerer AuthorDate: Thu Jul 7 14:11:03 2022 +0200 Merge branch cassandra-4.1 into trunk CHANGES.txt| 1 + .../apache/cassandra/cql3/ColumnIdentifier.java| 6 +- .../apache/cassandra/db/ArrayClusteringBound.java | 7 +- .../apache/cassandra/db/BufferClusteringBound.java | 6 +- .../cassandra/db/BufferClusteringBoundary.java | 6 +- src/java/org/apache/cassandra/db/Clustering.java | 6 +- .../org/apache/cassandra/db/ClusteringBound.java | 4 +- .../cassandra/db/ClusteringBoundOrBoundary.java| 6 +- src/java/org/apache/cassandra/db/Columns.java | 127 +++-- src/java/org/apache/cassandra/db/DeletionInfo.java | 5 +- .../org/apache/cassandra/db/EmptyIterators.java| 2 +- .../apache/cassandra/db/MutableDeletionInfo.java | 7 +- .../apache/cassandra/db/RangeTombstoneList.java| 12 +- .../cassandra/db/RegularAndStaticColumns.java | 18 +- .../apache/cassandra/db/compaction/Scrubber.java | 32 +- .../db/filter/ClusteringIndexNamesFilter.java | 13 +- .../db/memtable/ShardedSkipListMemtable.java | 6 +- .../cassandra/db/memtable/SkipListMemtable.java| 9 +- .../db/partitions/AbstractBTreePartition.java | 52 +- .../db/partitions/AtomicBTreePartition.java| 101 ++-- .../cassandra/db/partitions/FilteredPartition.java | 2 +- .../cassandra/db/partitions/PartitionUpdate.java | 29 +- .../org/apache/cassandra/db/rows/AbstractCell.java | 8 +- .../org/apache/cassandra/db/rows/ArrayCell.java| 7 +- .../org/apache/cassandra/db/rows/BTreeRow.java | 107 +++- .../org/apache/cassandra/db/rows/BufferCell.java | 10 + src/java/org/apache/cassandra/db/rows/Cell.java| 11 +- .../org/apache/cassandra/db/rows/CellPath.java | 12 +- src/java/org/apache/cassandra/db/rows/Cells.java | 112 .../org/apache/cassandra/db/rows/ColumnData.java | 172 ++ .../cassandra/db/rows/ComplexColumnData.java | 42 +- .../db/rows/RangeTombstoneBoundMarker.java | 7 +- .../db/rows/RangeTombstoneBoundaryMarker.java | 9 +- .../cassandra/db/rows/RangeTombstoneMarker.java| 4 +- src/java/org/apache/cassandra/db/rows/Row.java | 24 +- src/java/org/apache/cassandra/db/rows/Rows.java| 120 +--- .../db/rows/WrappingUnfilteredRowIterator.java | 2 +- .../org/apache/cassandra/db/view/TableViews.java | 24 +- .../org/apache/cassandra/dht/LocalPartitioner.java | 4 +- .../index/internal/CassandraIndexSearcher.java | 6 +- .../org/apache/cassandra/io/sstable/SSTable.java | 4 +- .../org/apache/cassandra/utils/btree/BTree.java| 85 +-- .../cassandra/utils/btree/UpdateFunction.java | 23 +- ...bstractAllocator.java => ByteBufferCloner.java} | 84 ++- .../org/apache/cassandra/utils/memory/Cloner.java | 54 ++ .../cassandra/utils/memory/ContextAllocator.java | 59 -- .../cassandra/utils/memory/EnsureOnHeap.java | 8 +- .../cassandra/utils/memory/HeapAllocator.java | 41 -- .../apache/cassandra/utils/memory/HeapCloner.java | 37 ++ .../apache/cassandra/utils/memory/HeapPool.java| 19 +- .../cassandra/utils/memory/MemtableAllocator.java | 7 +- .../utils/memory/MemtableBufferAllocator.java | 23 +- .../cassandra/utils/memory/NativeAllocator.java| 31 +- .../cassandra/utils/memory/SlabAllocator.java | 4 +- .../org/apache/cassandra/utils/LongBTreeTest.java | 8 +- .../btree/AtomicBTreePartitionUpdateBench.java | 615 + .../test/microbench/btree/Megamorphism.java| 14 +- .../cql3/validation/operations/DeleteTest.java | 1 + test/unit/org/apache/cassandra/db/CellTest.java| 46 +- .../org/apache/cassandra/db/NativeCellTest.java| 12 +- .../org/apache/cassandra/db/rows/RowBuilder.java | 91 --- .../apache/cassandra/db/rows/RowsMergingTest.java | 286 ++ .../org/apache/cassandra/db/rows/RowsTest.java | 90 +-- .../apache/cassandra/utils/btree/BTreeTest.java| 13 +- 64 files changed, 1904 insertions(+), 889 deletions(-) diff --cc src/java/org/apache/cassandra/dht/LocalPartitioner.java index df976701aa,09cd2b7d4a..127c5b7ded --- a/src/java/org/apache/cassandra/dht/LocalPartitioner.java +++ b/src/java/org/apache/cassandra/dht/LocalPartitioner.java @@@ -26,12 -26,9 +26,12 @@@ import java.util.Random import org.apache.cassandra.db.DecoratedKey; import org.apache.cassandra.db.CachedHashDecoratedKey; import org.apache.cassandra.db.marshal.AbstractType; +import org.apache.cassandra.db.marshal.ByteBufferAccessor; import org.apache.cassandra.utils.ByteBufferUtil; +import org.apache.cassandra.utils.bytecomparable.ByteComparable; +import
[cassandra] branch trunk updated (ab0a9b5f5c -> b29ad8823a)
This is an automated email from the ASF dual-hosted git repository.
blerer pushed a change to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
from ab0a9b5f5c Merge branch 'cassandra-4.1' into trunk
add c378874a9f Utilise BTree improvements to reduce garbage and improve
throughput
add 50e7a3f5df Merge branch cassandra-4.0 into cassandra-4.1
new b29ad8823a Merge branch cassandra-4.1 into trunk
The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
CHANGES.txt| 1 +
.../apache/cassandra/cql3/ColumnIdentifier.java| 6 +-
.../apache/cassandra/db/ArrayClusteringBound.java | 7 +-
.../apache/cassandra/db/BufferClusteringBound.java | 6 +-
.../cassandra/db/BufferClusteringBoundary.java | 6 +-
src/java/org/apache/cassandra/db/Clustering.java | 6 +-
.../org/apache/cassandra/db/ClusteringBound.java | 4 +-
.../cassandra/db/ClusteringBoundOrBoundary.java| 6 +-
src/java/org/apache/cassandra/db/Columns.java | 127 +++--
src/java/org/apache/cassandra/db/DeletionInfo.java | 5 +-
.../org/apache/cassandra/db/EmptyIterators.java| 2 +-
.../apache/cassandra/db/MutableDeletionInfo.java | 7 +-
.../apache/cassandra/db/RangeTombstoneList.java| 12 +-
.../cassandra/db/RegularAndStaticColumns.java | 18 +-
.../apache/cassandra/db/compaction/Scrubber.java | 32 +-
.../db/filter/ClusteringIndexNamesFilter.java | 13 +-
.../db/memtable/ShardedSkipListMemtable.java | 6 +-
.../cassandra/db/memtable/SkipListMemtable.java| 9 +-
.../db/partitions/AbstractBTreePartition.java | 52 +-
.../db/partitions/AtomicBTreePartition.java| 101 ++--
.../cassandra/db/partitions/FilteredPartition.java | 2 +-
.../cassandra/db/partitions/PartitionUpdate.java | 29 +-
.../org/apache/cassandra/db/rows/AbstractCell.java | 8 +-
.../org/apache/cassandra/db/rows/ArrayCell.java| 7 +-
.../org/apache/cassandra/db/rows/BTreeRow.java | 107 +++-
.../org/apache/cassandra/db/rows/BufferCell.java | 10 +
src/java/org/apache/cassandra/db/rows/Cell.java| 11 +-
.../org/apache/cassandra/db/rows/CellPath.java | 12 +-
src/java/org/apache/cassandra/db/rows/Cells.java | 112
.../org/apache/cassandra/db/rows/ColumnData.java | 172 ++
.../cassandra/db/rows/ComplexColumnData.java | 42 +-
.../db/rows/RangeTombstoneBoundMarker.java | 7 +-
.../db/rows/RangeTombstoneBoundaryMarker.java | 9 +-
.../cassandra/db/rows/RangeTombstoneMarker.java| 4 +-
src/java/org/apache/cassandra/db/rows/Row.java | 24 +-
src/java/org/apache/cassandra/db/rows/Rows.java| 120 +---
.../db/rows/WrappingUnfilteredRowIterator.java | 2 +-
.../org/apache/cassandra/db/view/TableViews.java | 24 +-
.../org/apache/cassandra/dht/LocalPartitioner.java | 4 +-
.../index/internal/CassandraIndexSearcher.java | 6 +-
.../org/apache/cassandra/io/sstable/SSTable.java | 4 +-
.../org/apache/cassandra/utils/btree/BTree.java| 85 +--
.../cassandra/utils/btree/UpdateFunction.java | 23 +-
...bstractAllocator.java => ByteBufferCloner.java} | 84 ++-
.../utils/memory/{SlabPool.java => Cloner.java}| 43 +-
.../cassandra/utils/memory/ContextAllocator.java | 59 --
.../cassandra/utils/memory/EnsureOnHeap.java | 8 +-
.../cassandra/utils/memory/HeapAllocator.java | 41 --
.../memory/{NativePool.java => HeapCloner.java}| 22 +-
.../apache/cassandra/utils/memory/HeapPool.java| 19 +-
.../cassandra/utils/memory/MemtableAllocator.java | 7 +-
.../utils/memory/MemtableBufferAllocator.java | 23 +-
.../cassandra/utils/memory/NativeAllocator.java| 31 +-
.../cassandra/utils/memory/SlabAllocator.java | 4 +-
.../org/apache/cassandra/utils/LongBTreeTest.java | 8 +-
.../btree/AtomicBTreePartitionUpdateBench.java | 615 +
.../test/microbench/btree/Megamorphism.java| 14 +-
.../cql3/validation/operations/DeleteTest.java | 1 +
test/unit/org/apache/cassandra/db/CellTest.java| 46 +-
.../org/apache/cassandra/db/NativeCellTest.java| 12 +-
.../org/apache/cassandra/db/rows/RowBuilder.java | 91 ---
.../apache/cassandra/db/rows/RowsMergingTest.java | 286 ++
.../org/apache/cassandra/db/rows/RowsTest.java | 90 +--
.../apache/cassandra/utils/btree/BTreeTest.java| 13 +-
64 files changed, 1857 insertions(+), 910 deletions(-)
rename src/java/org/apache/cassandra/utils/memory/{AbstractAllocator.java =>
ByteBufferCloner.java} (50%)
copy src/java/org/apache/cassandra/utils/memory/{SlabPool.java => Cloner.java}
(54%)
delete mode 100644
src/java/org/apache/cassandra/utils/memory/ContextAllocator.java
delete mode
[cassandra] branch cassandra-4.1 updated (a250126f0f -> 50e7a3f5df)
This is an automated email from the ASF dual-hosted git repository.
blerer pushed a change to branch cassandra-4.1
in repository https://gitbox.apache.org/repos/asf/cassandra.git
from a250126f0f Remove commons-lang dependency during build runtime
add c378874a9f Utilise BTree improvements to reduce garbage and improve
throughput
add 50e7a3f5df Merge branch cassandra-4.0 into cassandra-4.1
No new revisions were added by this update.
Summary of changes:
CHANGES.txt| 1 +
.../apache/cassandra/cql3/ColumnIdentifier.java| 6 +-
.../apache/cassandra/db/ArrayClusteringBound.java | 7 +-
.../apache/cassandra/db/BufferClusteringBound.java | 6 +-
.../cassandra/db/BufferClusteringBoundary.java | 6 +-
src/java/org/apache/cassandra/db/Clustering.java | 6 +-
.../org/apache/cassandra/db/ClusteringBound.java | 4 +-
.../cassandra/db/ClusteringBoundOrBoundary.java| 6 +-
src/java/org/apache/cassandra/db/Columns.java | 127 +++--
src/java/org/apache/cassandra/db/DeletionInfo.java | 5 +-
.../org/apache/cassandra/db/EmptyIterators.java| 2 +-
.../apache/cassandra/db/MutableDeletionInfo.java | 7 +-
.../apache/cassandra/db/RangeTombstoneList.java| 12 +-
.../cassandra/db/RegularAndStaticColumns.java | 18 +-
.../apache/cassandra/db/compaction/Scrubber.java | 32 +-
.../db/filter/ClusteringIndexNamesFilter.java | 13 +-
.../db/memtable/ShardedSkipListMemtable.java | 6 +-
.../cassandra/db/memtable/SkipListMemtable.java| 9 +-
.../db/partitions/AbstractBTreePartition.java | 52 +-
.../db/partitions/AtomicBTreePartition.java| 101 ++--
.../cassandra/db/partitions/FilteredPartition.java | 2 +-
.../cassandra/db/partitions/PartitionUpdate.java | 29 +-
.../org/apache/cassandra/db/rows/AbstractCell.java | 8 +-
.../org/apache/cassandra/db/rows/ArrayCell.java| 7 +-
.../org/apache/cassandra/db/rows/BTreeRow.java | 107 +++-
.../org/apache/cassandra/db/rows/BufferCell.java | 10 +
src/java/org/apache/cassandra/db/rows/Cell.java| 11 +-
.../org/apache/cassandra/db/rows/CellPath.java | 12 +-
src/java/org/apache/cassandra/db/rows/Cells.java | 112
.../org/apache/cassandra/db/rows/ColumnData.java | 172 ++
.../cassandra/db/rows/ComplexColumnData.java | 42 +-
.../db/rows/RangeTombstoneBoundMarker.java | 7 +-
.../db/rows/RangeTombstoneBoundaryMarker.java | 9 +-
.../cassandra/db/rows/RangeTombstoneMarker.java| 4 +-
src/java/org/apache/cassandra/db/rows/Row.java | 24 +-
src/java/org/apache/cassandra/db/rows/Rows.java| 120 +---
.../db/rows/WrappingUnfilteredRowIterator.java | 2 +-
.../org/apache/cassandra/db/view/TableViews.java | 24 +-
.../org/apache/cassandra/dht/LocalPartitioner.java | 4 +-
.../index/internal/CassandraIndexSearcher.java | 6 +-
.../org/apache/cassandra/io/sstable/SSTable.java | 4 +-
.../org/apache/cassandra/utils/btree/BTree.java| 85 +--
.../cassandra/utils/btree/UpdateFunction.java | 23 +-
...bstractAllocator.java => ByteBufferCloner.java} | 84 ++-
.../utils/memory/{SlabPool.java => Cloner.java}| 43 +-
.../cassandra/utils/memory/ContextAllocator.java | 59 --
.../cassandra/utils/memory/EnsureOnHeap.java | 8 +-
.../cassandra/utils/memory/HeapAllocator.java | 41 --
.../memory/{NativePool.java => HeapCloner.java}| 22 +-
.../apache/cassandra/utils/memory/HeapPool.java| 19 +-
.../cassandra/utils/memory/MemtableAllocator.java | 7 +-
.../utils/memory/MemtableBufferAllocator.java | 23 +-
.../cassandra/utils/memory/NativeAllocator.java| 31 +-
.../cassandra/utils/memory/SlabAllocator.java | 4 +-
.../org/apache/cassandra/utils/LongBTreeTest.java | 8 +-
.../btree/AtomicBTreePartitionUpdateBench.java | 615 +
.../test/microbench/btree/Megamorphism.java| 14 +-
.../cql3/validation/operations/DeleteTest.java | 1 +
test/unit/org/apache/cassandra/db/CellTest.java| 46 +-
.../org/apache/cassandra/db/NativeCellTest.java| 12 +-
.../org/apache/cassandra/db/rows/RowBuilder.java | 91 ---
.../apache/cassandra/db/rows/RowsMergingTest.java | 286 ++
.../org/apache/cassandra/db/rows/RowsTest.java | 90 +--
.../apache/cassandra/utils/btree/BTreeTest.java| 13 +-
64 files changed, 1857 insertions(+), 910 deletions(-)
rename src/java/org/apache/cassandra/utils/memory/{AbstractAllocator.java =>
ByteBufferCloner.java} (50%)
copy src/java/org/apache/cassandra/utils/memory/{SlabPool.java => Cloner.java}
(54%)
delete mode 100644
src/java/org/apache/cassandra/utils/memory/ContextAllocator.java
delete mode 100644
src/java/org/apache/cassandra/utils/memory/HeapAllocator.java
copy src/java/org/apache/cassandra/utils/memory/{NativePool.java =>
HeapCloner.java} (70%)
create mode 100644
[cassandra] branch cassandra-4.0 updated (924cd8f52c -> c378874a9f)
This is an automated email from the ASF dual-hosted git repository.
blerer pushed a change to branch cassandra-4.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
from 924cd8f52c Make sure delayed timeout task in StreamTransferTask cannot
prevent clean shutdown
add c378874a9f Utilise BTree improvements to reduce garbage and improve
throughput
No new revisions were added by this update.
Summary of changes:
CHANGES.txt| 1 +
.../apache/cassandra/cql3/ColumnIdentifier.java| 6 +-
.../apache/cassandra/db/ArrayClusteringBound.java | 7 +-
.../apache/cassandra/db/BufferClusteringBound.java | 7 +-
.../cassandra/db/BufferClusteringBoundary.java | 7 +-
src/java/org/apache/cassandra/db/Clustering.java | 6 +-
.../org/apache/cassandra/db/ClusteringBound.java | 4 +-
.../cassandra/db/ClusteringBoundOrBoundary.java| 6 +-
src/java/org/apache/cassandra/db/Columns.java | 127 +++--
src/java/org/apache/cassandra/db/DeletionInfo.java | 5 +-
.../org/apache/cassandra/db/EmptyIterators.java| 2 +-
src/java/org/apache/cassandra/db/Memtable.java | 9 +-
.../apache/cassandra/db/MutableDeletionInfo.java | 7 +-
.../apache/cassandra/db/RangeTombstoneList.java| 12 +-
.../cassandra/db/RegularAndStaticColumns.java | 18 +-
.../apache/cassandra/db/compaction/Scrubber.java | 32 +-
.../db/filter/ClusteringIndexNamesFilter.java | 13 +-
.../db/partitions/AbstractBTreePartition.java | 52 +-
.../db/partitions/AtomicBTreePartition.java| 102 ++--
.../cassandra/db/partitions/FilteredPartition.java | 2 +-
.../cassandra/db/partitions/PartitionUpdate.java | 29 +-
.../org/apache/cassandra/db/rows/AbstractCell.java | 7 +-
.../org/apache/cassandra/db/rows/ArrayCell.java| 7 +-
.../org/apache/cassandra/db/rows/BTreeRow.java | 107 +++-
.../org/apache/cassandra/db/rows/BufferCell.java | 7 +-
src/java/org/apache/cassandra/db/rows/Cell.java| 11 +-
.../org/apache/cassandra/db/rows/CellPath.java | 12 +-
src/java/org/apache/cassandra/db/rows/Cells.java | 112
.../org/apache/cassandra/db/rows/ColumnData.java | 172 ++
.../cassandra/db/rows/ComplexColumnData.java | 42 +-
.../db/rows/RangeTombstoneBoundMarker.java | 7 +-
.../db/rows/RangeTombstoneBoundaryMarker.java | 7 +-
.../cassandra/db/rows/RangeTombstoneMarker.java| 4 +-
src/java/org/apache/cassandra/db/rows/Row.java | 24 +-
src/java/org/apache/cassandra/db/rows/Rows.java| 116 +---
.../db/rows/WrappingUnfilteredRowIterator.java | 2 +-
.../org/apache/cassandra/db/view/TableViews.java | 24 +-
.../org/apache/cassandra/dht/LocalPartitioner.java | 4 +-
.../index/internal/CassandraIndexSearcher.java | 6 +-
.../org/apache/cassandra/io/sstable/SSTable.java | 4 +-
.../org/apache/cassandra/utils/btree/BTree.java| 85 +--
.../cassandra/utils/btree/UpdateFunction.java | 23 +-
...bstractAllocator.java => ByteBufferCloner.java} | 84 ++-
.../utils/memory/{SlabPool.java => Cloner.java}| 43 +-
.../cassandra/utils/memory/ContextAllocator.java | 59 --
.../cassandra/utils/memory/EnsureOnHeap.java | 8 +-
.../cassandra/utils/memory/HeapAllocator.java | 41 --
.../memory/{NativePool.java => HeapCloner.java}| 22 +-
.../apache/cassandra/utils/memory/HeapPool.java| 14 +-
.../cassandra/utils/memory/MemtableAllocator.java | 6 +-
.../utils/memory/MemtableBufferAllocator.java | 23 +-
.../cassandra/utils/memory/NativeAllocator.java| 31 +-
.../cassandra/utils/memory/SlabAllocator.java | 4 +-
.../org/apache/cassandra/utils/LongBTreeTest.java | 8 +-
.../btree/AtomicBTreePartitionUpdateBench.java | 614 +
.../test/microbench/btree/Megamorphism.java| 14 +-
.../cql3/validation/operations/DeleteTest.java | 1 +
test/unit/org/apache/cassandra/db/CellTest.java| 46 +-
.../org/apache/cassandra/db/NativeCellTest.java| 12 +-
.../org/apache/cassandra/db/rows/RowBuilder.java | 91 ---
.../apache/cassandra/db/rows/RowsMergingTest.java | 286 ++
.../org/apache/cassandra/db/rows/RowsTest.java | 90 +--
.../utils/btree/BTreeSearchIteratorTest.java | 2 -
.../apache/cassandra/utils/btree/BTreeTest.java| 13 +-
64 files changed, 1836 insertions(+), 913 deletions(-)
rename src/java/org/apache/cassandra/utils/memory/{AbstractAllocator.java =>
ByteBufferCloner.java} (50%)
copy src/java/org/apache/cassandra/utils/memory/{SlabPool.java => Cloner.java}
(54%)
delete mode 100644
src/java/org/apache/cassandra/utils/memory/ContextAllocator.java
delete mode 100644
src/java/org/apache/cassandra/utils/memory/HeapAllocator.java
copy src/java/org/apache/cassandra/utils/memory/{NativePool.java =>
HeapCloner.java} (71%)
create mode 100644
[jira] [Updated] (CASSANDRA-15511) Utilising BTree Improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-15511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15511:
---
Status: Ready to Commit (was: Review In Progress)
> Utilising BTree Improvements
>
>
> Key: CASSANDRA-15511
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15511
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Attachments: atomicbtreepartition.ods, atomicbtreepartition.xlsx.zip,
> perfsh.tar.gz
>
>
> This patch utilises CASSANDRA-15510 to improve throughput and reduce garbage
> produced by a number of common operations, by employing
> {{transformAndFilter}}, {{transform}} and {{FastBuilder}}
> * {{Row}}, {{Cell}} and {{ComplexColumnData}} cloning are implemented with
> {{BTree.transform}}, so no special builders are necessary;
> ** {{Rows.copy}} removed
> * {{Rows.merge}} implemented using {{BTree.update}} and a {{ColumnData}}
> reconciler
> ** Zero-allocations if result of merge is same as {{existing}}
> ** Fewer comparisons
> * {{ColumnData}} reconciler implemented in same manner
> ** {{Cells.reconcileComplex}} is retired
> ** {{ComplexColumnData}} reconciliation now
> *** Garbage-free if the merge has no effect
> *** Always fewer allocations
> *** Fewer comparisons
> * {{FastBuilder}} employed widely:
> ** {{ClusteringIndexNamesFilter}} deserialization
> ** {{Columns}} deserialization
> ** {{PartitionUpdate}} deserialization
> ** {{AbstractBTreePartition}} construction
> ** Misc others
> The upshot of this work when combined with the proposed patch for
> CASSANDRA-15367 has a dramatic impact on operations over collection types -
> under contention, as much as 100x improved throughput, and hundreds of
> megabytes of reduced allocations. For all operations, allocations under
> contention and no contention are significantly reduced and throughput
> improved.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15511) Utilising BTree Improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-15511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563738#comment-17563738
]
Benjamin Lerer commented on CASSANDRA-15511:
Tests results look good outside of some known failures.
> Utilising BTree Improvements
>
>
> Key: CASSANDRA-15511
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15511
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Attachments: atomicbtreepartition.ods, atomicbtreepartition.xlsx.zip,
> perfsh.tar.gz
>
>
> This patch utilises CASSANDRA-15510 to improve throughput and reduce garbage
> produced by a number of common operations, by employing
> {{transformAndFilter}}, {{transform}} and {{FastBuilder}}
> * {{Row}}, {{Cell}} and {{ComplexColumnData}} cloning are implemented with
> {{BTree.transform}}, so no special builders are necessary;
> ** {{Rows.copy}} removed
> * {{Rows.merge}} implemented using {{BTree.update}} and a {{ColumnData}}
> reconciler
> ** Zero-allocations if result of merge is same as {{existing}}
> ** Fewer comparisons
> * {{ColumnData}} reconciler implemented in same manner
> ** {{Cells.reconcileComplex}} is retired
> ** {{ComplexColumnData}} reconciliation now
> *** Garbage-free if the merge has no effect
> *** Always fewer allocations
> *** Fewer comparisons
> * {{FastBuilder}} employed widely:
> ** {{ClusteringIndexNamesFilter}} deserialization
> ** {{Columns}} deserialization
> ** {{PartitionUpdate}} deserialization
> ** {{AbstractBTreePartition}} construction
> ** Misc others
> The upshot of this work when combined with the proposed patch for
> CASSANDRA-15367 has a dramatic impact on operations over collection types -
> under contention, as much as 100x improved throughput, and hundreds of
> megabytes of reduced allocations. For all operations, allocations under
> contention and no contention are significantly reduced and throughput
> improved.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17741) WEBSITE - July 2022 blog "Apache Cassandra 4.1: Configuration Standardization"
[ https://issues.apache.org/jira/browse/CASSANDRA-17741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17741: -- Attachment: PR151-02-incorrect_list_format.png > WEBSITE - July 2022 blog "Apache Cassandra 4.1: Configuration Standardization" > -- > > Key: CASSANDRA-17741 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17741 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.1.x > > Attachments: PR151-01-summary_truncated.png, > PR151-02-incorrect_list_format.png > > > This ticket is to capture the work associated with publishing the June 2022 > blog "Apache Cassandra 4.1: Configuration Standardization" > If this blog cannot be published by the *July 7, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17741) WEBSITE - July 2022 blog "Apache Cassandra 4.1: Configuration Standardization"
[ https://issues.apache.org/jira/browse/CASSANDRA-17741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17741: -- Attachment: PR151-01-summary_truncated.png > WEBSITE - July 2022 blog "Apache Cassandra 4.1: Configuration Standardization" > -- > > Key: CASSANDRA-17741 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17741 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.1.x > > Attachments: PR151-01-summary_truncated.png > > > This ticket is to capture the work associated with publishing the June 2022 > blog "Apache Cassandra 4.1: Configuration Standardization" > If this blog cannot be published by the *July 7, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17653) Fix flaky test - org.apache.cassandra.cql3.validation.operations.InsertUpdateIfConditionTest.testConditionalUpdate[0: clusterMinVersion=3.0]
[
https://issues.apache.org/jira/browse/CASSANDRA-17653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563661#comment-17563661
]
Benjamin Lerer commented on CASSANDRA-17653:
+1
> Fix flaky test -
> org.apache.cassandra.cql3.validation.operations.InsertUpdateIfConditionTest.testConditionalUpdate[0:
> clusterMinVersion=3.0]
>
>
> Key: CASSANDRA-17653
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17653
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Brandon Williams
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x
>
>
> {code}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.cql3.validation.operations.InsertUpdateIfConditionTest.lambda$data$0(InsertUpdateIfConditionTest.java:64)
> at
> org.apache.cassandra.cql3.validation.operations.InsertUpdateIfConditionTest.beforeSetup(InsertUpdateIfConditionTest.java:90)
> at
> org.apache.cassandra.cql3.validation.operations.InsertUpdateIfConditionTest.before(InsertUpdateIfConditionTest.java:84)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
> https://ci-cassandra.apache.org/job/Cassandra-4.1/34/testReport/org.apache.cassandra.cql3.validation.operations/InsertUpdateIfConditionTest/testConditionalUpdate_0__clusterMinVersion_3_0__3/
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17741) WEBSITE - July 2022 blog "Apache Cassandra 4.1: Configuration Standardization"
[ https://issues.apache.org/jira/browse/CASSANDRA-17741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez reassigned CASSANDRA-17741: - Assignee: Erick Ramirez > WEBSITE - July 2022 blog "Apache Cassandra 4.1: Configuration Standardization" > -- > > Key: CASSANDRA-17741 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17741 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.1.x > > > This ticket is to capture the work associated with publishing the June 2022 > blog "Apache Cassandra 4.1: Configuration Standardization" > If this blog cannot be published by the *July 7, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17741) WEBSITE - July 2022 blog "Apache Cassandra 4.1: Configuration Standardization"
[ https://issues.apache.org/jira/browse/CASSANDRA-17741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17741: -- Authors: Chris Thornett, Diogenese Topper, Ekaterina Dimitrova (was: Erick Ramirez) > WEBSITE - July 2022 blog "Apache Cassandra 4.1: Configuration Standardization" > -- > > Key: CASSANDRA-17741 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17741 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.1.x > > > This ticket is to capture the work associated with publishing the June 2022 > blog "Apache Cassandra 4.1: Configuration Standardization" > If this blog cannot be published by the *July 7, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17741) WEBSITE - July 2022 blog "Apache Cassandra 4.1: Configuration Standardization"
[ https://issues.apache.org/jira/browse/CASSANDRA-17741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17741: -- Reviewers: Erick Ramirez Status: Review In Progress (was: Patch Available) > WEBSITE - July 2022 blog "Apache Cassandra 4.1: Configuration Standardization" > -- > > Key: CASSANDRA-17741 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17741 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.1.x > > > This ticket is to capture the work associated with publishing the June 2022 > blog "Apache Cassandra 4.1: Configuration Standardization" > If this blog cannot be published by the *July 7, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17232) org.apache.cassandra.db.commitlog.GroupCommitLogTest tests failing on trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-17232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563628#comment-17563628
]
Berenguer Blasi edited comment on CASSANDRA-17232 at 7/7/22 8:11 AM:
-
[~adelapena] found it. We were swallowing interrupts and not properly cleaning
up on them. CI attached in the PR green as a 4 leaved clover as you say lol :-)
was (Author: bereng):
[~adelapena] found it. We were swallowing interrupts and not properly cleaning
up on them. CI attached in the PR green as a 4 leave clover as you say lol :-)
> org.apache.cassandra.db.commitlog.GroupCommitLogTest tests failing on trunk
> ---
>
> Key: CASSANDRA-17232
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17232
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x, 4.x
>
>
> I saw
> [here|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1344/testReport/junit/org.apache.cassandra.db.commitlog/GroupCommitLogTest/replayWithDiscard_3_/]
> and
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/881/testReport/junit/org.apache.cassandra.db.commitlog/GroupCommitLogTest/replayWithDiscard_3__compression_3/]
> the same assertion failure:
>
> {code:java}
> org.apache.cassandra.db.commitlog.GroupCommitLogTest.replayWithDiscard[3]
> Error Message
> expected:<204> but was:<0>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<204> but was:<0> at
> org.apache.cassandra.db.commitlog.CommitLogTest.replayWithDiscard(CommitLogTest.java:883)
> {code}
>
> Then I find that there are many other tests from GroupCommitLogTest failing
> with No such file found.
> Example:
> https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1344/
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17232) org.apache.cassandra.db.commitlog.GroupCommitLogTest tests failing on trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-17232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563628#comment-17563628
]
Berenguer Blasi commented on CASSANDRA-17232:
-
[~adelapena] found it. We were swallowing interrupts and not properly cleaning
up on them. CI attached in the PR green as a 4 leave clover as you say lol :-)
> org.apache.cassandra.db.commitlog.GroupCommitLogTest tests failing on trunk
> ---
>
> Key: CASSANDRA-17232
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17232
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x, 4.x
>
>
> I saw
> [here|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1344/testReport/junit/org.apache.cassandra.db.commitlog/GroupCommitLogTest/replayWithDiscard_3_/]
> and
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/881/testReport/junit/org.apache.cassandra.db.commitlog/GroupCommitLogTest/replayWithDiscard_3__compression_3/]
> the same assertion failure:
>
> {code:java}
> org.apache.cassandra.db.commitlog.GroupCommitLogTest.replayWithDiscard[3]
> Error Message
> expected:<204> but was:<0>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<204> but was:<0> at
> org.apache.cassandra.db.commitlog.CommitLogTest.replayWithDiscard(CommitLogTest.java:883)
> {code}
>
> Then I find that there are many other tests from GroupCommitLogTest failing
> with No such file found.
> Example:
> https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1344/
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17734) Validate that JMX and the Settings Virtual Table are aligned
[ https://issues.apache.org/jira/browse/CASSANDRA-17734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer reassigned CASSANDRA-17734: -- Assignee: (was: Benjamin Lerer) > Validate that JMX and the Settings Virtual Table are aligned > > > Key: CASSANDRA-17734 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17734 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0.x, 4.1.x, 4.x > > > I discovered JMX methods that are not updating the Config parameters but > directly the usage. (see index_summary_resize_interval) This is a bug in 4.0+ > as users will see wrong values in the Settings virtual table which rely on > the Config parameters (if some value was changed after startup). It will be > explicitly important to ensure there is no disconnect between those when we > add update option for the Virtual Table. > This ticket is meant to serve as an umbrella for subtasks to check the > properties getters methods and for tickets to fix any discovered > bugs. > > CC [~b.le...@gmail.com] and [~dcapwell] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17736) Settings Virtual Table should display the values assigned to a property in the DatabaseDescriptor on startup and not null (as per the yaml)
[ https://issues.apache.org/jira/browse/CASSANDRA-17736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer reassigned CASSANDRA-17736: -- Assignee: Benjamin Lerer > Settings Virtual Table should display the values assigned to a property in > the DatabaseDescriptor on startup and not null (as per the yaml) > --- > > Key: CASSANDRA-17736 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17736 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Benjamin Lerer >Priority: Normal > Fix For: 4.0.x, 4.1-beta, 4.1.x > > > There are a few properties that after startup do not show their assigned > values as per the DatabaseDescriptor assignment but the cassandra.yaml value. > They will not be also updated in the virtual table down the road in case they > are updated through JMX, nodetool etc. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17734) Validate that JMX and the Settings Virtual Table are aligned
[ https://issues.apache.org/jira/browse/CASSANDRA-17734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer reassigned CASSANDRA-17734: -- Assignee: Benjamin Lerer > Validate that JMX and the Settings Virtual Table are aligned > > > Key: CASSANDRA-17734 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17734 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Benjamin Lerer >Priority: Normal > Fix For: 4.0.x, 4.1.x, 4.x > > > I discovered JMX methods that are not updating the Config parameters but > directly the usage. (see index_summary_resize_interval) This is a bug in 4.0+ > as users will see wrong values in the Settings virtual table which rely on > the Config parameters (if some value was changed after startup). It will be > explicitly important to ensure there is no disconnect between those when we > add update option for the Virtual Table. > This ticket is meant to serve as an umbrella for subtasks to check the > properties getters methods and for tickets to fix any discovered > bugs. > > CC [~b.le...@gmail.com] and [~dcapwell] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (18612450 -> f6a0710c)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 18612450 generate docs for 07cc189e new f6a0710c generate docs for 07cc189e This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (18612450) \ N -- N -- N refs/heads/asf-staging (f6a0710c) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4740078 -> 4740078 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
