[jira] [Comment Edited] (CASSANDRA-15877) Followup on CASSANDRA-15600
[ https://issues.apache.org/jira/browse/CASSANDRA-15877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142576#comment-17142576 ] Ekaterina Dimitrova edited comment on CASSANDRA-15877 at 6/23/20, 3:02 AM: --- [~adelapena]'s comments are addressed in a new separate [commit|https://github.com/ekaterinadimitrova2/cassandra/pull/44/commits/a4dac9d33b86325f07ea722d592824d12d2e40ba]. I didn't run a new CI as they are formatting changes. Separate tickets for the failing tests, not related to this patch were opened: *JAVA 11:* _test_resumable_rebuild - rebuild_test.TestRebuild_ - CASSANDRA-15892 _test_short_read - consistency_test.TestConsistency_ - CASSANDRA-15893 *JAVA 8:* _test_multiple_repair - repair_tests.incremental_repair_test.TestIncRepair_ - CASSANDRA-15894 was (Author: e.dimitrova): [~adelapena] comments are addressed in a new separate [commit| https://github.com/ekaterinadimitrova2/cassandra/pull/44/commits/a4dac9d33b86325f07ea722d592824d12d2e40ba]. I didn't run a new CI as they are formatting changes. Separate tickets for the failing tests, not related to this patch were opened: JAVA 11: test_resumable_rebuild - rebuild_test.TestRebuild - CASSANDRA-15892 test_short_read - consistency_test.TestConsistency - CASSANDRA-15893 JAVA 8: test_multiple_repair - repair_tests.incremental_repair_test.TestIncRepair - CASSANDRA-15894 > Followup on CASSANDRA-15600 > --- > > Key: CASSANDRA-15877 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15877 > Project: Cassandra > Issue Type: Bug > Components: Feature/Virtual Nodes >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0, 4.0-alpha > > Attachments: Screen Shot 2020-06-12 at 3.21.18 PM.png > > > As part of CASSANDRA-15600 generateSplits method replaced the > generateRandomTokens for NoReplicationAwareTokenAllocator. generateSplits > should be used also in ReplicationAwareTokenAllocator. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15877) Followup on CASSANDRA-15600
[ https://issues.apache.org/jira/browse/CASSANDRA-15877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-15877: Status: Ready to Commit (was: Changes Suggested) > Followup on CASSANDRA-15600 > --- > > Key: CASSANDRA-15877 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15877 > Project: Cassandra > Issue Type: Bug > Components: Feature/Virtual Nodes >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0, 4.0-alpha > > Attachments: Screen Shot 2020-06-12 at 3.21.18 PM.png > > > As part of CASSANDRA-15600 generateSplits method replaced the > generateRandomTokens for NoReplicationAwareTokenAllocator. generateSplits > should be used also in ReplicationAwareTokenAllocator. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15877) Followup on CASSANDRA-15600
[ https://issues.apache.org/jira/browse/CASSANDRA-15877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142576#comment-17142576 ] Ekaterina Dimitrova commented on CASSANDRA-15877: - [~adelapena] comments are addressed in a new separate [commit| https://github.com/ekaterinadimitrova2/cassandra/pull/44/commits/a4dac9d33b86325f07ea722d592824d12d2e40ba]. I didn't run a new CI as they are formatting changes. Separate tickets for the failing tests, not related to this patch were opened: JAVA 11: test_resumable_rebuild - rebuild_test.TestRebuild - CASSANDRA-15892 test_short_read - consistency_test.TestConsistency - CASSANDRA-15893 JAVA 8: test_multiple_repair - repair_tests.incremental_repair_test.TestIncRepair - CASSANDRA-15894 > Followup on CASSANDRA-15600 > --- > > Key: CASSANDRA-15877 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15877 > Project: Cassandra > Issue Type: Bug > Components: Feature/Virtual Nodes >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0, 4.0-alpha > > Attachments: Screen Shot 2020-06-12 at 3.21.18 PM.png > > > As part of CASSANDRA-15600 generateSplits method replaced the > generateRandomTokens for NoReplicationAwareTokenAllocator. generateSplits > should be used also in ReplicationAwareTokenAllocator. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15894) JAVA 8: test_multiple_repair - repair_tests.incremental_repair_test.TestIncRepair
Ekaterina Dimitrova created CASSANDRA-15894: --- Summary: JAVA 8: test_multiple_repair - repair_tests.incremental_repair_test.TestIncRepair Key: CASSANDRA-15894 URL: https://issues.apache.org/jira/browse/CASSANDRA-15894 Project: Cassandra Issue Type: Bug Reporter: Ekaterina Dimitrova JAVA 8: test_multiple_repair - repair_tests.incremental_repair_test.TestIncRepair Fails locally and in CircleCI: https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/222/workflows/46515d14-9be4-4edb-8db4-5930312d2bfb/jobs/1329 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15893) JAVA 11: test_short_read - consistency_test.TestConsistency
Ekaterina Dimitrova created CASSANDRA-15893: --- Summary: JAVA 11: test_short_read - consistency_test.TestConsistency Key: CASSANDRA-15893 URL: https://issues.apache.org/jira/browse/CASSANDRA-15893 Project: Cassandra Issue Type: Bug Reporter: Ekaterina Dimitrova JAVA 11: test_short_read - consistency_test.TestConsistency Failing locally and in CircleCI: https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/222/workflows/11202c7e-6c94-4d4e-bbbf-9e2fa9791ad0/jobs/1337 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15892) JAVA 11: test_resumable_rebuild - rebuild_test.TestRebuild
[ https://issues.apache.org/jira/browse/CASSANDRA-15892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-15892: Description: JAVA 11: test_resumable_rebuild - rebuild_test.TestRebuild Fails locally and in [CircleCI | [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/222/workflows/11202c7e-6c94-4d4e-bbbf-9e2fa9791ad0/jobs/1338]] was: JAVA 11: test_resumable_rebuild - rebuild_test.TestRebuild Fails locally and in [CircleCI | https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/222/workflows/11202c7e-6c94-4d4e-bbbf-9e2fa9791ad0/jobs/1338] > JAVA 11: test_resumable_rebuild - rebuild_test.TestRebuild > -- > > Key: CASSANDRA-15892 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15892 > Project: Cassandra > Issue Type: Bug >Reporter: Ekaterina Dimitrova >Priority: Normal > > JAVA 11: > test_resumable_rebuild - rebuild_test.TestRebuild > Fails locally and in > [CircleCI | > [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/222/workflows/11202c7e-6c94-4d4e-bbbf-9e2fa9791ad0/jobs/1338]] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15892) JAVA 11: test_resumable_rebuild - rebuild_test.TestRebuild
Ekaterina Dimitrova created CASSANDRA-15892: --- Summary: JAVA 11: test_resumable_rebuild - rebuild_test.TestRebuild Key: CASSANDRA-15892 URL: https://issues.apache.org/jira/browse/CASSANDRA-15892 Project: Cassandra Issue Type: Bug Reporter: Ekaterina Dimitrova JAVA 11: test_resumable_rebuild - rebuild_test.TestRebuild Fails locally and in [CircleCI | https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/222/workflows/11202c7e-6c94-4d4e-bbbf-9e2fa9791ad0/jobs/1338] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15788) Add tests to cover CacheMetrics
[
https://issues.apache.org/jira/browse/CASSANDRA-15788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142502#comment-17142502
]
David Capwell commented on CASSANDRA-15788:
---
sorry I have been slow, too much chaos on my end for a while now; not sure ill
be able to review for a while still =(
> Add tests to cover CacheMetrics
> ---
>
> Key: CASSANDRA-15788
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15788
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Normal
>
> {{CacheMetrics}} and {{ChunkCacheMetrics}} do not have unit tests covering
> them. {{CachingBench}} seems to provide some coverage but those tests (which
> don't appear to run as part of the standard run of unit tests) are failing
> and do not assert against all defined metrics, nor do they seem to assert
> code in {{InstrumentingCache}} which also incremented metrics.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15854) Truncation should fail any ongoing preview repairs
[ https://issues.apache.org/jira/browse/CASSANDRA-15854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142499#comment-17142499 ] Caleb Rackliffe commented on CASSANDRA-15854: - [~marcuse] I've left the comments from my first pass of review [inline|https://github.com/krummas/cassandra/commit/0da4b6ca0180efae9cbf22bf5eee77d2aa3b936e]. > Truncation should fail any ongoing preview repairs > -- > > Key: CASSANDRA-15854 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15854 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-beta > > > Truncation may race with preview repairs, validating different data on > different nodes, we should abort any ongoing preview repairs if we get a > truncation request -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15882) sstablemetadata should show tombstone timestamp not just the local drop time
[
https://issues.apache.org/jira/browse/CASSANDRA-15882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142458#comment-17142458
]
Thanh edited comment on CASSANDRA-15882 at 6/22/20, 10:35 PM:
--
[~ifesdjeen]
sorry, pls disregard this request, it's invalid. I've confirmed that the
tombstone is expired at local_delete_time + gc_grace_seconds
was (Author: thatran):
sorry, pls disregard this request, it's invalid. I've confirmed that the
tombstone is expired at local_delete_time + gc_grace_seconds
> sstablemetadata should show tombstone timestamp not just the local drop time
>
>
> Key: CASSANDRA-15882
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15882
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Thanh
>Priority: Normal
>
> issue/request:
> sstablemetadata should show tombstone timestamp not just the local drop time
>
> I'm not sure what all versions this exists in but the sstablemetadata
> tombstone "drop time" only just shows the local delete time of the
> tombstones. What's more important (what the tombstone expiration time
> depends on) is the tombstone writetime (tombstone timestamp). It's possible
> to, and a surprising number of users have done this, write a tombstone with a
> timetamp in the future (by doing "DELETE...USING TIMESTAMP
> "). When this happens, the tombstone hangs around in
> sstables for a lot longer than users expect because
> {code:java}
> tombstone_expiration_time = gc_grace_seconds + tombstone_timestamp{code}
> NOT
> {code:java}
> tombstone_expiration_time = gc_grace_seconds +
> tombstone_local_delete_time{code}
> and the sstablemetadata output doesn't help here because it only shows the
> local delete time, not the actual tombstone timestamp that's used to
> calculate tombstone expiration time.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15882) sstablemetadata should show tombstone timestamp not just the local drop time
[
https://issues.apache.org/jira/browse/CASSANDRA-15882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142458#comment-17142458
]
Thanh commented on CASSANDRA-15882:
---
sorry, pls disregard this request, it's invalid. I've confirmed that the
tombstone is expired at local_delete_time + gc_grace_seconds
> sstablemetadata should show tombstone timestamp not just the local drop time
>
>
> Key: CASSANDRA-15882
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15882
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Thanh
>Priority: Normal
>
> issue/request:
> sstablemetadata should show tombstone timestamp not just the local drop time
>
> I'm not sure what all versions this exists in but the sstablemetadata
> tombstone "drop time" only just shows the local delete time of the
> tombstones. What's more important (what the tombstone expiration time
> depends on) is the tombstone writetime (tombstone timestamp). It's possible
> to, and a surprising number of users have done this, write a tombstone with a
> timetamp in the future (by doing "DELETE...USING TIMESTAMP
> "). When this happens, the tombstone hangs around in
> sstables for a lot longer than users expect because
> {code:java}
> tombstone_expiration_time = gc_grace_seconds + tombstone_timestamp{code}
> NOT
> {code:java}
> tombstone_expiration_time = gc_grace_seconds +
> tombstone_local_delete_time{code}
> and the sstablemetadata output doesn't help here because it only shows the
> local delete time, not the actual tombstone timestamp that's used to
> calculate tombstone expiration time.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15882) sstablemetadata should show tombstone timestamp not just the local drop time
[
https://issues.apache.org/jira/browse/CASSANDRA-15882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thanh updated CASSANDRA-15882:
--
Resolution: Invalid
Status: Resolved (was: Triage Needed)
> sstablemetadata should show tombstone timestamp not just the local drop time
>
>
> Key: CASSANDRA-15882
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15882
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Thanh
>Priority: Normal
>
> issue/request:
> sstablemetadata should show tombstone timestamp not just the local drop time
>
> I'm not sure what all versions this exists in but the sstablemetadata
> tombstone "drop time" only just shows the local delete time of the
> tombstones. What's more important (what the tombstone expiration time
> depends on) is the tombstone writetime (tombstone timestamp). It's possible
> to, and a surprising number of users have done this, write a tombstone with a
> timetamp in the future (by doing "DELETE...USING TIMESTAMP
> "). When this happens, the tombstone hangs around in
> sstables for a lot longer than users expect because
> {code:java}
> tombstone_expiration_time = gc_grace_seconds + tombstone_timestamp{code}
> NOT
> {code:java}
> tombstone_expiration_time = gc_grace_seconds +
> tombstone_local_delete_time{code}
> and the sstablemetadata output doesn't help here because it only shows the
> local delete time, not the actual tombstone timestamp that's used to
> calculate tombstone expiration time.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15854) Truncation should fail any ongoing preview repairs
[
https://issues.apache.org/jira/browse/CASSANDRA-15854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142455#comment-17142455
]
Caleb Rackliffe commented on CASSANDRA-15854:
-
This isn't related directly to the patch, but there are a couple places
({{CassandraValidationIterator}} and {{RepairMessageVerbHandler}}) where we
believe {{ActiveRepairService#getParentRepairSession()}} can return {{null}}.
It seems pretty clear, though, that we'll always throw a {{RuntimeException}}
before we allow that to happen.
> Truncation should fail any ongoing preview repairs
> --
>
> Key: CASSANDRA-15854
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15854
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Truncation may race with preview repairs, validating different data on
> different nodes, we should abort any ongoing preview repairs if we get a
> truncation request
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15854) Truncation should fail any ongoing preview repairs
[
https://issues.apache.org/jira/browse/CASSANDRA-15854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142442#comment-17142442
]
Caleb Rackliffe commented on CASSANDRA-15854:
-
The dtest failure in {{TestRepair}} looks like CASSANDRA-15861, but
{{test_cleanup}} in {{bootstrap_test.TestBootstrap}} doesn't look like it's
been reported yet.
> Truncation should fail any ongoing preview repairs
> --
>
> Key: CASSANDRA-15854
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15854
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Truncation may race with preview repairs, validating different data on
> different nodes, we should abort any ongoing preview repairs if we get a
> truncation request
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15854) Truncation should fail any ongoing preview repairs
[
https://issues.apache.org/jira/browse/CASSANDRA-15854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142440#comment-17142440
]
Caleb Rackliffe commented on CASSANDRA-15854:
-
I'm not able to reproduce the failure in {{StreamingInboundHandlerTest}} in a
few local runs, but it also doesn't seem to have a flaky test Jira. Will have
to investigate further...
> Truncation should fail any ongoing preview repairs
> --
>
> Key: CASSANDRA-15854
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15854
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Truncation may race with preview repairs, validating different data on
> different nodes, we should abort any ongoing preview repairs if we get a
> truncation request
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15889) Debian package fails to download on Arm-based hosts
[
https://issues.apache.org/jira/browse/CASSANDRA-15889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Davis updated CASSANDRA-15889:
---
Description:
Following the first three steps of the [Debian install
process|https://cassandra.apache.org/download/], after an apt-get update you'll
see this line:
{code:bash}
$ sudo apt-get update
...
N: Skipping acquire of configured file 'main/binary-arm64/Packages' as
repository 'https://downloads.apache.org/cassandra/debian 311x InRelease'
doesn't support architecture 'arm64'
{code}
Checking the [Debian
repo|https://dl.bintray.com/apache/cassandra/dists/311x/main/] confirms there
is no aarch64 variant available.
Should you then attempt to install Cassandra:
{code:bash}
$ sudo apt-get install cassandra
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package cassandra is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'cassandra' has no installation candidate
{code}
The Redhat RPM contains a "noarch" arch type, so it will download on any host.
(Cassandra does not use separate binaries/releases for different architectures,
so this seems to be the correct approach, but adding an aarch64 variant would
also suffice.)
Note that there is a workaround available: if you specify "amd64" as the arch
for the source, it downloads and runs on Arm without issue:
{code:bash}
deb [arch=amd64] https://downloads.apache.org/cassandra/debian 311x main
{code}
was:
Following the first three steps of the [Debian install
process|https://cassandra.apache.org/download/], after an apt-get update you'll
see this line:
{code:bash}
$ sudo apt-get update
...
N: Skipping acquire of configured file 'main/binary-arm64/Packages' as
repository 'https://downloads.apache.org/cassandra/debian 311x InRelease'
doesn't support architecture 'arm64'
{code}
Checking the [Debian
repo|https://dl.bintray.com/apache/cassandra/dists/311x/main/] confirms there
is no aarch64 variant available.
Should you then attempt to install Cassandra:
{code:bash}
$ sudo apt-get install cassandra
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package cassandra is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'cassandra' has no installation candidate
{code}
The Redhat RPM contains a "noarch" arch type, so it will download on any host.
(Cassandra does not use separate binaries/releases for different architectures,
so this seems to be the correct approach, but adding an aarch64 variant would
also suffice.)
Note that there is a workaround available: if you specify "amd64" as the arch
in the deb command, it downloads and runs on aarch64 without issue:
{code:bash}
deb [arch=amd64] https://downloads.apache.org/cassandra/debian 311x main
{code}
> Debian package fails to download on Arm-based hosts
> ---
>
> Key: CASSANDRA-15889
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15889
> Project: Cassandra
> Issue Type: Bug
>Reporter: Matt Davis
>Priority: Normal
>
> Following the first three steps of the [Debian install
> process|https://cassandra.apache.org/download/], after an apt-get update
> you'll see this line:
> {code:bash}
> $ sudo apt-get update
> ...
> N: Skipping acquire of configured file 'main/binary-arm64/Packages' as
> repository 'https://downloads.apache.org/cassandra/debian 311x InRelease'
> doesn't support architecture 'arm64'
> {code}
> Checking the [Debian
> repo|https://dl.bintray.com/apache/cassandra/dists/311x/main/] confirms there
> is no aarch64 variant available.
> Should you then attempt to install Cassandra:
> {code:bash}
> $ sudo apt-get install cassandra
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Package cassandra is not available, but is referred to by another package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
> E: Package 'cassandra' has no installation candidate
> {code}
> The Redhat RPM contains a "noarch" arch type, so it will download on any
> host. (Cassandra does not use separate binaries/releases for different
> architectures, so this seems to be the correct approach, but adding an
> aarch64 variant would also suffice.)
> Note that there is a workaround available: if you specify "amd64" as the arch
> for the source, it downloads and runs on Arm without issue:
> {code:bash}
> deb [arch=amd64] https://downloads.apache.org/cassandra/debian 311x main
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
--
[jira] [Updated] (CASSANDRA-15889) Debian package fails to download on Arm-based hosts
[
https://issues.apache.org/jira/browse/CASSANDRA-15889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Davis updated CASSANDRA-15889:
---
Description:
Following the first three steps of the [Debian install
process|https://cassandra.apache.org/download/], after an apt-get update you'll
see this line:
{code:bash}
$ sudo apt-get update
...
N: Skipping acquire of configured file 'main/binary-arm64/Packages' as
repository 'https://downloads.apache.org/cassandra/debian 311x InRelease'
doesn't support architecture 'arm64'
{code}
Checking the [Debian
repo|https://dl.bintray.com/apache/cassandra/dists/311x/main/] confirms there
is no aarch64 variant available.
Should you then attempt to install Cassandra:
{code:bash}
$ sudo apt-get install cassandra
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package cassandra is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'cassandra' has no installation candidate
{code}
The Redhat RPM contains a "noarch" arch type, so it will download on any host.
(Cassandra does not use separate binaries/releases for different architectures,
so this seems to be the correct approach, but adding an aarch64 variant would
also suffice.)
Note that there is a workaround available: if you specify "amd64" as the arch
in the deb command, it downloads and runs on aarch64 without issue:
{code:bash}
deb [arch=amd64] https://downloads.apache.org/cassandra/debian 311x main
{code}
was:
Following the first three steps of the [Debian install
process|https://cassandra.apache.org/download/], after an apt-get update you'll
see this line:
{code:bash}
$ sudo apt-get update
...
N: Skipping acquire of configured file 'main/binary-arm64/Packages' as
repository 'https://downloads.apache.org/cassandra/debian 311x InRelease'
doesn't support architecture 'arm64'
{code}
Checking the [Debian
repo|https://dl.bintray.com/apache/cassandra/dists/311x/main/] confirms there
is no aarch64 variant available.
Should you then attempt to install Cassandra:
{code:bash}
$ sudo apt-get install cassandra
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package cassandra is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'cassandra' has no installation candidate
{code}
Note that the Redhat RPM contains a "noarch" arch type, so it downloads
properly on any host. (Given that Cassandra does not use separate
binaries/releases for different architectures, this seems to be the correct
approach for Debian. That said, adding an aarch64 variant would also suffice.)
Also, there is a workaround available: if you specify "amd64" as the arch in
the deb command, it downloads and runs on aarch64 without issue:
{code:bash}
deb [arch=amd64] https://downloads.apache.org/cassandra/debian 311x main
{code}
> Debian package fails to download on Arm-based hosts
> ---
>
> Key: CASSANDRA-15889
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15889
> Project: Cassandra
> Issue Type: Bug
>Reporter: Matt Davis
>Priority: Normal
>
> Following the first three steps of the [Debian install
> process|https://cassandra.apache.org/download/], after an apt-get update
> you'll see this line:
> {code:bash}
> $ sudo apt-get update
> ...
> N: Skipping acquire of configured file 'main/binary-arm64/Packages' as
> repository 'https://downloads.apache.org/cassandra/debian 311x InRelease'
> doesn't support architecture 'arm64'
> {code}
> Checking the [Debian
> repo|https://dl.bintray.com/apache/cassandra/dists/311x/main/] confirms there
> is no aarch64 variant available.
> Should you then attempt to install Cassandra:
> {code:bash}
> $ sudo apt-get install cassandra
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Package cassandra is not available, but is referred to by another package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
> E: Package 'cassandra' has no installation candidate
> {code}
> The Redhat RPM contains a "noarch" arch type, so it will download on any
> host. (Cassandra does not use separate binaries/releases for different
> architectures, so this seems to be the correct approach, but adding an
> aarch64 variant would also suffice.)
> Note that there is a workaround available: if you specify "amd64" as the arch
> in the deb command, it downloads and runs on aarch64 without issue:
> {code:bash}
> deb [arch=amd64] https://downloads.apache.org/cassandra/debian 311x main
> {code}
--
This messa
[jira] [Commented] (CASSANDRA-15861) Mutating sstable component may race with entire-sstable-streaming(ZCS) causing checksum validation failure
[
https://issues.apache.org/jira/browse/CASSANDRA-15861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142390#comment-17142390
]
David Capwell commented on CASSANDRA-15861:
---
bq. writeFileToChannelZeroCopy is async, but if I remember correctly about unix
file system: once a file is opened, reader won't be affected by file deletion
or rewrite. So when the synchronized block completes, all component
file-channels are already opened and in-sync with ComponentManifest, even if
they are not flushed from netty outbound buffer to kernel.
Yep, checked and see that each region in netty holds reference to the channel
so you are right, will not be impacted by delete.
bq. The only thing I don't like is redistributing index summary every hour will
explode sstable generation..
That could have negatives for third party tools like backups since they would
look like new sstables; versioning the Statistics.db file would be nice but
adds its own complexity as well.
Looking closer at
org.apache.cassandra.db.streaming.CassandraOutgoingFile#write, why not take
advantage of the fact a FD will be immune to the swap and just create the FD at
the start of the method? This would give you the ability to write the header
and the body without worrying about locking.
> Mutating sstable component may race with entire-sstable-streaming(ZCS)
> causing checksum validation failure
> --
>
> Key: CASSANDRA-15861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15861
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Consistency/Streaming,
> Local/Compaction
>Reporter: ZhaoYang
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Flaky dtest: [test_dead_sync_initiator -
> repair_tests.repair_test.TestRepair|https://ci-cassandra.apache.org/view/all/job/Cassandra-devbranch-dtest/143/testReport/junit/dtest.repair_tests.repair_test/TestRepair/test_dead_sync_initiator/]
> {code:java|title=stacktrace}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [ERROR [Stream-Deserializer-127.0.0.1:7000-570871f3] 2020-06-03 04:05:19,081
> CassandraEntireSSTableStreamReader.java:145 - [Stream
> 6f1c3360-a54f-11ea-a808-2f23710fdc90] Error while reading sstable from stream
> for table = keyspace1.standard1
> org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted:
> /home/cassandra/cassandra/cassandra-dtest/tmp/dtest-te4ty0r9/test/node3/data0/keyspace1/standard1-5f5ab140a54f11eaa8082f23710fdc90/na-2-big-Statistics.db
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.maybeValidateChecksum(MetadataSerializer.java:219)
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:198)
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:129)
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.mutate(MetadataSerializer.java:226)
> at
> org.apache.cassandra.db.streaming.CassandraEntireSSTableStreamReader.read(CassandraEntireSSTableStreamReader.java:140)
> at
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:78)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:49)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:36)
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:49)
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:181)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.IOException: Checksums do not match for
> /home/cassandra/cassandra/cassandra-dtest/tmp/dtest-te4ty0r9/test/node3/data0/keyspace1/standard1-5f5ab140a54f11eaa8082f23710fdc90/na-2-big-Statistics.db
> {code}
>
> In the above test, it executes "nodetool repair" on node1 and kills node2
> during repair. At the end, node3 reports checksum validation failure on
> sstable transferred from node1.
> {code:java|title=what happened}
> 1. When repair started on node1, it performs anti-compaction which modifies
> sstable's repairAt to 0 and pending repair id to session-id.
> 2. Then node1 creates {{ComponentManifest}} which contains file lengths to be
> transferred to node3.
> 3. Before node1 actually sends the files to node3, node2 is killed and node1
> starts to broadcast repair-failure-message to all participants in
[jira] [Updated] (CASSANDRA-15890) Add token to tombstone warning and error log message
[
https://issues.apache.org/jira/browse/CASSANDRA-15890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15890:
-
Reviewers: Brandon Williams, Brandon Williams (was: Brandon Williams)
Brandon Williams, Brandon Williams
Status: Review In Progress (was: Patch Available)
> Add token to tombstone warning and error log message
>
>
> Key: CASSANDRA-15890
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15890
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Logging
>Reporter: Venkata Harikrishna Nukala
>Assignee: Venkata Harikrishna Nukala
>Priority: Normal
> Fix For: 3.0.21, 3.11.7, 4.0
>
>
> If Cassandra scans too many tombstones while reading a partition, then it
> prints log messages with query based on warning/failure thresholds. The token
> is not printed in the log message. If tombstones are hurting the
> instance/replica set, then running force compaction for the partition
> ("nodetool compact" using start and end tokens i.e. token -/+ some delta) is
> one of the actions taken to recover. In order to find out the token, someone
> has to manually connect to cluster and run SELECT TOKEN query. Printing token
> with the log message helps to avoid manual effort and execute force
> compaction quickly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15890) Add token to tombstone warning and error log message
[
https://issues.apache.org/jira/browse/CASSANDRA-15890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142376#comment-17142376
]
Brandon Williams commented on CASSANDRA-15890:
--
Your git links don't seem to work for me. I dug them up, though. Actual:
3.0:
https://github.com/nvharikrishna/cassandra/commit/7962817a14cd48946d2864431b6bfa8088b34ea4
3.11:
https://github.com/nvharikrishna/cassandra/commit/b106b89500da555bf0264e6dcfd8ba5256a94fb4
trunk:
https://github.com/nvharikrishna/cassandra/commit/ca8a8b51110abffc157f30a9da75f9cee6f7c906
I started Jenkins CI on these:
3.0: https://ci-cassandra.apache.org/job/Cassandra-devbranch/164/
3.11: https://ci-cassandra.apache.org/job/Cassandra-devbranch/165/
trunk: https://ci-cassandra.apache.org/job/Cassandra-devbranch/166/
I expect everything to be fine, and I'll commit after they complete.
> Add token to tombstone warning and error log message
>
>
> Key: CASSANDRA-15890
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15890
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Logging
>Reporter: Venkata Harikrishna Nukala
>Assignee: Venkata Harikrishna Nukala
>Priority: Normal
> Fix For: 3.0.21, 3.11.7, 4.0
>
>
> If Cassandra scans too many tombstones while reading a partition, then it
> prints log messages with query based on warning/failure thresholds. The token
> is not printed in the log message. If tombstones are hurting the
> instance/replica set, then running force compaction for the partition
> ("nodetool compact" using start and end tokens i.e. token -/+ some delta) is
> one of the actions taken to recover. In order to find out the token, someone
> has to manually connect to cluster and run SELECT TOKEN query. Printing token
> with the log message helps to avoid manual effort and execute force
> compaction quickly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15890) Add token to tombstone warning and error log message
[
https://issues.apache.org/jira/browse/CASSANDRA-15890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15890:
-
Test and Documentation Plan: CI
Status: Patch Available (was: Open)
> Add token to tombstone warning and error log message
>
>
> Key: CASSANDRA-15890
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15890
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Logging
>Reporter: Venkata Harikrishna Nukala
>Assignee: Venkata Harikrishna Nukala
>Priority: Normal
> Fix For: 3.0.21, 3.11.7, 4.0
>
>
> If Cassandra scans too many tombstones while reading a partition, then it
> prints log messages with query based on warning/failure thresholds. The token
> is not printed in the log message. If tombstones are hurting the
> instance/replica set, then running force compaction for the partition
> ("nodetool compact" using start and end tokens i.e. token -/+ some delta) is
> one of the actions taken to recover. In order to find out the token, someone
> has to manually connect to cluster and run SELECT TOKEN query. Printing token
> with the log message helps to avoid manual effort and execute force
> compaction quickly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15891) provide a configuration option such as endpoint_verification_method
[
https://issues.apache.org/jira/browse/CASSANDRA-15891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thanh updated CASSANDRA-15891:
--
Summary: provide a configuration option such as
endpoint_verification_method (was: allow cassandra admin to decide what
endpoint to use for endpoint verification)
> provide a configuration option such as endpoint_verification_method
> ---
>
> Key: CASSANDRA-15891
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15891
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Thanh
>Priority: Normal
>
> With cassandra-9220, it's possible to configure endpoint/hostname
> verification when enabling internode encryption. However, you don't have any
> control over what endpoint is used for the endpoint verification; instead,
> cassandra will automatically try to use node IP (not node hostname) for
> endpoint verification, so if your node certificates don't include the IP in
> the ssl certificate's SAN list, then you'll get an error like:
> {code:java}
> ERROR [MessagingService-Outgoing-/10.10.88.194-Gossip] 2018-11-13
> 10:20:26,903 OutboundTcpConnection.java:606 - SSL handshake error for
> outbound connection to 50cc97c1[SSL_NULL_WITH_NULL_NULL:
> Socket[addr=/,port=7001,localport=47684]]
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address found
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) {code}
> From what I've seen, most orgs will not have node IPs in their certs.
> So, it will be best if cassandra would provide another configuration option
> such as *{{endpoint_verification_method}}* which you could set to "ip" or
> "fqdn" or something else (eg "hostname_alias" if for whatever reason the org
> doesn't want to use fqdn for endpoint verification).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15891) allow cassandra admin to decide what endpoint to use for endpoint verification
Thanh created CASSANDRA-15891:
-
Summary: allow cassandra admin to decide what endpoint to use for
endpoint verification
Key: CASSANDRA-15891
URL: https://issues.apache.org/jira/browse/CASSANDRA-15891
Project: Cassandra
Issue Type: Improvement
Reporter: Thanh
With cassandra-9220, it's possible to configure endpoint/hostname verification
when enabling internode encryption. However, you don't have any control over
what endpoint is used for the endpoint verification; instead, cassandra will
automatically try to use node IP (not node hostname) for endpoint verification,
so if your node certificates don't include the IP in the ssl certificate's SAN
list, then you'll get an error like:
{code:java}
ERROR [MessagingService-Outgoing-/10.10.88.194-Gossip] 2018-11-13 10:20:26,903
OutboundTcpConnection.java:606 - SSL handshake error for outbound connection to
50cc97c1[SSL_NULL_WITH_NULL_NULL:
Socket[addr=/,port=7001,localport=47684]]
javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
No subject alternative names matching IP address found
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) {code}
>From what I've seen, most orgs will not have node IPs in their certs.
So, it will be best if cassandra would provide another configuration option
such as *{{endpoint_verification_method}}* which you could set to "ip" or
"fqdn" or something else (eg "hostname_alias" if for whatever reason the org
doesn't want to use fqdn for endpoint verification).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15890) Add token to tombstone warning and error log message
[
https://issues.apache.org/jira/browse/CASSANDRA-15890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142349#comment-17142349
]
Venkata Harikrishna Nukala commented on CASSANDRA-15890:
Here are the patches:
*Trunk*
Git:
[https://github.com/apache/cassandra/compare/trunk...nvharikrishna:15890-trunk?expand=1]
CI:
[https://app.circleci.com/pipelines/github/nvharikrishna/cassandra?branch=15890-trunk]
*3.11*
Git:
[https://github.com/apache/cassandra/compare/cassandra-3.11...nvharikrishna:15890-cassandra-3.11?expand=1]
CI:
[https://app.circleci.com/pipelines/github/nvharikrishna/cassandra?branch=15890-cassandra-3.11]
*3.0*
Git:
[https://github.com/apache/cassandra/compare/cassandra-3.0...nvharikrishna:15890-cassandra-3.0?expand=1]
CI:
[https://app.circleci.com/pipelines/github/nvharikrishna/cassandra?branch=15890-cassandra-3.0]
CI is still running for these branches. I think it is going to take some more
time. I will update once CI passes.
> Add token to tombstone warning and error log message
>
>
> Key: CASSANDRA-15890
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15890
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Logging
>Reporter: Venkata Harikrishna Nukala
>Assignee: Venkata Harikrishna Nukala
>Priority: Normal
> Fix For: 3.0.21, 3.11.7, 4.0
>
>
> If Cassandra scans too many tombstones while reading a partition, then it
> prints log messages with query based on warning/failure thresholds. The token
> is not printed in the log message. If tombstones are hurting the
> instance/replica set, then running force compaction for the partition
> ("nodetool compact" using start and end tokens i.e. token -/+ some delta) is
> one of the actions taken to recover. In order to find out the token, someone
> has to manually connect to cluster and run SELECT TOKEN query. Printing token
> with the log message helps to avoid manual effort and execute force
> compaction quickly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15890) Add token to tombstone warning and error log message
[
https://issues.apache.org/jira/browse/CASSANDRA-15890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142319#comment-17142319
]
Venkata Harikrishna Nukala commented on CASSANDRA-15890:
Yes, I am preparing patch. I will update the patch soon.
> Add token to tombstone warning and error log message
>
>
> Key: CASSANDRA-15890
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15890
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Logging
>Reporter: Venkata Harikrishna Nukala
>Assignee: Venkata Harikrishna Nukala
>Priority: Normal
> Fix For: 3.0.21, 3.11.7, 4.0
>
>
> If Cassandra scans too many tombstones while reading a partition, then it
> prints log messages with query based on warning/failure thresholds. The token
> is not printed in the log message. If tombstones are hurting the
> instance/replica set, then running force compaction for the partition
> ("nodetool compact" using start and end tokens i.e. token -/+ some delta) is
> one of the actions taken to recover. In order to find out the token, someone
> has to manually connect to cluster and run SELECT TOKEN query. Printing token
> with the log message helps to avoid manual effort and execute force
> compaction quickly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15890) Add token to tombstone warning and error log message
[
https://issues.apache.org/jira/browse/CASSANDRA-15890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15890:
-
Fix Version/s: 4.0
3.11.7
3.0.21
> Add token to tombstone warning and error log message
>
>
> Key: CASSANDRA-15890
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15890
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Logging
>Reporter: Venkata Harikrishna Nukala
>Assignee: Venkata Harikrishna Nukala
>Priority: Normal
> Fix For: 3.0.21, 3.11.7, 4.0
>
>
> If Cassandra scans too many tombstones while reading a partition, then it
> prints log messages with query based on warning/failure thresholds. The token
> is not printed in the log message. If tombstones are hurting the
> instance/replica set, then running force compaction for the partition
> ("nodetool compact" using start and end tokens i.e. token -/+ some delta) is
> one of the actions taken to recover. In order to find out the token, someone
> has to manually connect to cluster and run SELECT TOKEN query. Printing token
> with the log message helps to avoid manual effort and execute force
> compaction quickly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15890) Add token to tombstone warning and error log message
[
https://issues.apache.org/jira/browse/CASSANDRA-15890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15890:
-
Change Category: Operability
Complexity: Low Hanging Fruit
Status: Open (was: Triage Needed)
> Add token to tombstone warning and error log message
>
>
> Key: CASSANDRA-15890
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15890
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Logging
>Reporter: Venkata Harikrishna Nukala
>Assignee: Venkata Harikrishna Nukala
>Priority: Normal
>
> If Cassandra scans too many tombstones while reading a partition, then it
> prints log messages with query based on warning/failure thresholds. The token
> is not printed in the log message. If tombstones are hurting the
> instance/replica set, then running force compaction for the partition
> ("nodetool compact" using start and end tokens i.e. token -/+ some delta) is
> one of the actions taken to recover. In order to find out the token, someone
> has to manually connect to cluster and run SELECT TOKEN query. Printing token
> with the log message helps to avoid manual effort and execute force
> compaction quickly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15890) Add token to tombstone warning and error log message
[
https://issues.apache.org/jira/browse/CASSANDRA-15890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142315#comment-17142315
]
Brandon Williams commented on CASSANDRA-15890:
--
I'm +1 on doing this, would you like to submit a patch?
> Add token to tombstone warning and error log message
>
>
> Key: CASSANDRA-15890
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15890
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Logging
>Reporter: Venkata Harikrishna Nukala
>Assignee: Venkata Harikrishna Nukala
>Priority: Normal
>
> If Cassandra scans too many tombstones while reading a partition, then it
> prints log messages with query based on warning/failure thresholds. The token
> is not printed in the log message. If tombstones are hurting the
> instance/replica set, then running force compaction for the partition
> ("nodetool compact" using start and end tokens i.e. token -/+ some delta) is
> one of the actions taken to recover. In order to find out the token, someone
> has to manually connect to cluster and run SELECT TOKEN query. Printing token
> with the log message helps to avoid manual effort and execute force
> compaction quickly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15851) Add bytebuddy support for in-jvm dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-15851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142302#comment-17142302 ] David Capwell commented on CASSANDRA-15851: --- Sounds good [~ifesdjeen]. > Add bytebuddy support for in-jvm dtests > --- > > Key: CASSANDRA-15851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15851 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Labels: pull-request-available > > Old python dtests support byteman, but that is quite horrible to work with, > [bytebuddy|https://bytebuddy.net/#/] is much better, so we should add support > for that in the in-jvm dtests. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15854) Truncation should fail any ongoing preview repairs
[ https://issues.apache.org/jira/browse/CASSANDRA-15854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-15854: Reviewers: Caleb Rackliffe, Caleb Rackliffe (was: Caleb Rackliffe) Caleb Rackliffe, Caleb Rackliffe Status: Review In Progress (was: Patch Available) > Truncation should fail any ongoing preview repairs > -- > > Key: CASSANDRA-15854 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15854 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-beta > > > Truncation may race with preview repairs, validating different data on > different nodes, we should abort any ongoing preview repairs if we get a > truncation request -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15890) Add token to tombstone warning and error log message
Venkata Harikrishna Nukala created CASSANDRA-15890:
--
Summary: Add token to tombstone warning and error log message
Key: CASSANDRA-15890
URL: https://issues.apache.org/jira/browse/CASSANDRA-15890
Project: Cassandra
Issue Type: Improvement
Components: Observability/Logging
Reporter: Venkata Harikrishna Nukala
Assignee: Venkata Harikrishna Nukala
If Cassandra scans too many tombstones while reading a partition, then it
prints log messages with query based on warning/failure thresholds. The token
is not printed in the log message. If tombstones are hurting the
instance/replica set, then running force compaction for the partition
("nodetool compact" using start and end tokens i.e. token -/+ some delta) is
one of the actions taken to recover. In order to find out the token, someone
has to manually connect to cluster and run SELECT TOKEN query. Printing token
with the log message helps to avoid manual effort and execute force compaction
quickly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15889) Debian package fails to download on Arm-based hosts
[
https://issues.apache.org/jira/browse/CASSANDRA-15889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Davis updated CASSANDRA-15889:
---
Platform: ARM (was: All)
> Debian package fails to download on Arm-based hosts
> ---
>
> Key: CASSANDRA-15889
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15889
> Project: Cassandra
> Issue Type: Bug
>Reporter: Matt Davis
>Priority: Normal
>
> Following the first three steps of the [Debian install
> process|https://cassandra.apache.org/download/], after an apt-get update
> you'll see this line:
> {code:bash}
> $ sudo apt-get update
> ...
> N: Skipping acquire of configured file 'main/binary-arm64/Packages' as
> repository 'https://downloads.apache.org/cassandra/debian 311x InRelease'
> doesn't support architecture 'arm64'
> {code}
> Checking the [Debian
> repo|https://dl.bintray.com/apache/cassandra/dists/311x/main/] confirms there
> is no aarch64 variant available.
> Should you then attempt to install Cassandra:
> {code:bash}
> $ sudo apt-get install cassandra
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Package cassandra is not available, but is referred to by another package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
> E: Package 'cassandra' has no installation candidate
> {code}
> Note that the Redhat RPM contains a "noarch" arch type, so it downloads
> properly on any host. (Given that Cassandra does not use separate
> binaries/releases for different architectures, this seems to be the correct
> approach for Debian. That said, adding an aarch64 variant would also suffice.)
> Also, there is a workaround available: if you specify "amd64" as the arch in
> the deb command, it downloads and runs on aarch64 without issue:
> {code:bash}
> deb [arch=amd64] https://downloads.apache.org/cassandra/debian 311x main
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15889) Debian package fails to download on Arm-based hosts
[
https://issues.apache.org/jira/browse/CASSANDRA-15889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Davis updated CASSANDRA-15889:
---
Fix Version/s: (was: 3.11.x)
(was: 4.0)
> Debian package fails to download on Arm-based hosts
> ---
>
> Key: CASSANDRA-15889
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15889
> Project: Cassandra
> Issue Type: Bug
>Reporter: Matt Davis
>Priority: Normal
>
> Following the first three steps of the [Debian install
> process|https://cassandra.apache.org/download/], after an apt-get update
> you'll see this line:
> {code:bash}
> $ sudo apt-get update
> ...
> N: Skipping acquire of configured file 'main/binary-arm64/Packages' as
> repository 'https://downloads.apache.org/cassandra/debian 311x InRelease'
> doesn't support architecture 'arm64'
> {code}
> Checking the [Debian
> repo|https://dl.bintray.com/apache/cassandra/dists/311x/main/] confirms there
> is no aarch64 variant available.
> Should you then attempt to install Cassandra:
> {code:bash}
> $ sudo apt-get install cassandra
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Package cassandra is not available, but is referred to by another package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
> E: Package 'cassandra' has no installation candidate
> {code}
> Note that the Redhat RPM contains a "noarch" arch type, so it downloads
> properly on any host. (Given that Cassandra does not use separate
> binaries/releases for different architectures, this seems to be the correct
> approach for Debian. That said, adding an aarch64 variant would also suffice.)
> Also, there is a workaround available: if you specify "amd64" as the arch in
> the deb command, it downloads and runs on aarch64 without issue:
> {code:bash}
> deb [arch=amd64] https://downloads.apache.org/cassandra/debian 311x main
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15889) Debian package fails to download on Arm-based hosts
[
https://issues.apache.org/jira/browse/CASSANDRA-15889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Davis updated CASSANDRA-15889:
---
Description:
Following the first three steps of the [Debian install
process|https://cassandra.apache.org/download/], after an apt-get update you'll
see this line:
{code:bash}
$ sudo apt-get update
...
N: Skipping acquire of configured file 'main/binary-arm64/Packages' as
repository 'https://downloads.apache.org/cassandra/debian 311x InRelease'
doesn't support architecture 'arm64'
{code}
Checking the [Debian
repo|https://dl.bintray.com/apache/cassandra/dists/311x/main/] confirms there
is no aarch64 variant available.
Should you then attempt to install Cassandra:
{code:bash}
$ sudo apt-get install cassandra
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package cassandra is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'cassandra' has no installation candidate
{code}
Note that the Redhat RPM contains a "noarch" arch type, so it downloads
properly on any host. (Given that Cassandra does not use separate
binaries/releases for different architectures, this seems to be the correct
approach for Debian. That said, adding an aarch64 variant would also suffice.)
Also, there is a workaround available: if you specify "amd64" as the arch in
the deb command, it downloads and runs on aarch64 without issue:
{code:bash}
deb [arch=amd64] https://downloads.apache.org/cassandra/debian 311x main
{code}
was:
Following the first three steps of the [Debian install
process|https://cassandra.apache.org/download/], after an apt-get update you'll
see this line:
{code:bash}
N: Skipping acquire of configured file 'main/binary-arm64/Packages' as
repository 'https://downloads.apache.org/cassandra/debian 311x InRelease'
doesn't support architecture 'arm64'
{code}
Checking the [Debian
repo|https://dl.bintray.com/apache/cassandra/dists/311x/main/] confirms there
is no aarch64 variant available.
Should you then attempt to install Cassandra:
{code:bash}
sudo apt-get install cassandra
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package cassandra is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'cassandra' has no installation candidate
{code}
Note that the Redhat RPM contains a "noarch" arch type, so it downloads
properly on any host. (Given that Cassandra does not use separate
binaries/releases for different architectures, this seems to be the correct
approach for Debian. That said, adding an aarch64 variant would also suffice.)
Also, there is a workaround available: if you specify "amd64" as the arch in
the deb command, it downloads and runs on aarch64 without issue:
{code:bash}
deb [arch=amd64] https://downloads.apache.org/cassandra/debian 311x main
{code}
> Debian package fails to download on Arm-based hosts
> ---
>
> Key: CASSANDRA-15889
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15889
> Project: Cassandra
> Issue Type: Bug
>Reporter: Matt Davis
>Priority: Normal
> Fix For: 4.0, 3.11.x
>
>
> Following the first three steps of the [Debian install
> process|https://cassandra.apache.org/download/], after an apt-get update
> you'll see this line:
> {code:bash}
> $ sudo apt-get update
> ...
> N: Skipping acquire of configured file 'main/binary-arm64/Packages' as
> repository 'https://downloads.apache.org/cassandra/debian 311x InRelease'
> doesn't support architecture 'arm64'
> {code}
> Checking the [Debian
> repo|https://dl.bintray.com/apache/cassandra/dists/311x/main/] confirms there
> is no aarch64 variant available.
> Should you then attempt to install Cassandra:
> {code:bash}
> $ sudo apt-get install cassandra
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Package cassandra is not available, but is referred to by another package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
> E: Package 'cassandra' has no installation candidate
> {code}
> Note that the Redhat RPM contains a "noarch" arch type, so it downloads
> properly on any host. (Given that Cassandra does not use separate
> binaries/releases for different architectures, this seems to be the correct
> approach for Debian. That said, adding an aarch64 variant would also suffice.)
> Also, there is a workaround available: if you specify "amd64" as the arch in
> the deb command, it downloads and runs on aarch64 without issue:
> {code:bash}
> deb [arch=amd64
[jira] [Updated] (CASSANDRA-15889) Debian package fails to download on Arm-based hosts
[
https://issues.apache.org/jira/browse/CASSANDRA-15889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Davis updated CASSANDRA-15889:
---
Description:
Following the first three steps of the [Debian install
process|https://cassandra.apache.org/download/], after an apt-get update you'll
see this line:
{code:bash}
N: Skipping acquire of configured file 'main/binary-arm64/Packages' as
repository 'https://downloads.apache.org/cassandra/debian 311x InRelease'
doesn't support architecture 'arm64'
{code}
Checking the [Debian
repo|https://dl.bintray.com/apache/cassandra/dists/311x/main/] confirms there
is no aarch64 variant available.
Should you then attempt to install Cassandra:
{code:bash}
sudo apt-get install cassandra
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package cassandra is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'cassandra' has no installation candidate
{code}
Note that the Redhat RPM contains a "noarch" arch type, so it downloads
properly on any host. (Given that Cassandra does not use separate
binaries/releases for different architectures, this seems to be the correct
approach for Debian. That said, adding an aarch64 variant would also suffice.)
Also, there is a workaround available: if you specify "amd64" as the arch in
the deb command, it downloads and runs on aarch64 without issue:
{code:bash}
deb [arch=amd64] https://downloads.apache.org/cassandra/debian 311x main
{code}
was:
Following the first three steps of the [Debian install
process|https://cassandra.apache.org/download/], after an apt-get update you'll
see this line:
{code:bash}
N: Skipping acquire of configured file 'main/binary-arm64/Packages' as
repository 'https://downloads.apache.org/cassandra/debian 311x InRelease'
doesn't support architecture 'arm64'
{code}
Checking the [Debian
repo|https://dl.bintray.com/apache/cassandra/dists/311x/main/] confirms there
is no aarch64 variant available.
Should you then attempt to install Cassandra:
{code:bash}
sudo apt-get install cassandra
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package cassandra is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'cassandra' has no installation candidate
{code}
Note that the Redhat RPM contains a "noarch" arch type, so it downloads
properly on any host. (Given that Cassandra does not use separate
binaries/releases for different architectures, this seems to be the correct
approach for Debian. That said, adding an aarch64 variant would also suffice.)
Also, there is a workaround available: if you specify "amd64" as the arch in
the deb command, it downloads and runs without issue:
{code:bash}
deb [arch=amd64] https://downloads.apache.org/cassandra/debian 311x main
{code}
> Debian package fails to download on Arm-based hosts
> ---
>
> Key: CASSANDRA-15889
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15889
> Project: Cassandra
> Issue Type: Bug
>Reporter: Matt Davis
>Priority: Normal
> Fix For: 4.0, 3.11.x
>
>
> Following the first three steps of the [Debian install
> process|https://cassandra.apache.org/download/], after an apt-get update
> you'll see this line:
> {code:bash}
> N: Skipping acquire of configured file 'main/binary-arm64/Packages' as
> repository 'https://downloads.apache.org/cassandra/debian 311x InRelease'
> doesn't support architecture 'arm64'
> {code}
> Checking the [Debian
> repo|https://dl.bintray.com/apache/cassandra/dists/311x/main/] confirms there
> is no aarch64 variant available.
> Should you then attempt to install Cassandra:
> {code:bash}
> sudo apt-get install cassandra
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Package cassandra is not available, but is referred to by another package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
> E: Package 'cassandra' has no installation candidate
> {code}
> Note that the Redhat RPM contains a "noarch" arch type, so it downloads
> properly on any host. (Given that Cassandra does not use separate
> binaries/releases for different architectures, this seems to be the correct
> approach for Debian. That said, adding an aarch64 variant would also suffice.)
> Also, there is a workaround available: if you specify "amd64" as the arch in
> the deb command, it downloads and runs on aarch64 without issue:
> {code:bash}
> deb [arch=amd64] https://downloads.apache.org/cassandra/debian 311x main
> {code}
-
[jira] [Updated] (CASSANDRA-15889) Debian package fails to download on Arm-based hosts
[
https://issues.apache.org/jira/browse/CASSANDRA-15889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Davis updated CASSANDRA-15889:
---
Fix Version/s: 3.11.x
4.0
> Debian package fails to download on Arm-based hosts
> ---
>
> Key: CASSANDRA-15889
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15889
> Project: Cassandra
> Issue Type: Bug
>Reporter: Matt Davis
>Priority: Normal
> Fix For: 4.0, 3.11.x
>
>
> Following the first three steps of the [Debian install
> process|https://cassandra.apache.org/download/], after an apt-get update
> you'll see this line:
> {code:bash}
> N: Skipping acquire of configured file 'main/binary-arm64/Packages' as
> repository 'https://downloads.apache.org/cassandra/debian 311x InRelease'
> doesn't support architecture 'arm64'
> {code}
> Checking the [Debian
> repo|https://dl.bintray.com/apache/cassandra/dists/311x/main/] confirms there
> is no aarch64 variant available.
> Should you then attempt to install Cassandra:
> {code:bash}
> sudo apt-get install cassandra
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Package cassandra is not available, but is referred to by another package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
> E: Package 'cassandra' has no installation candidate
> {code}
> Note that the Redhat RPM contains a "noarch" arch type, so it downloads
> properly on any host. (Given that Cassandra does not use separate
> binaries/releases for different architectures, this seems to be the correct
> approach for Debian. That said, adding an aarch64 variant would also suffice.)
> Also, there is a workaround available: if you specify "amd64" as the arch in
> the deb command, it downloads and runs without issue:
> {code:bash}
> deb [arch=amd64] https://downloads.apache.org/cassandra/debian 311x main
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15889) Debian package fails to download on Arm-based hosts
Matt Davis created CASSANDRA-15889:
--
Summary: Debian package fails to download on Arm-based hosts
Key: CASSANDRA-15889
URL: https://issues.apache.org/jira/browse/CASSANDRA-15889
Project: Cassandra
Issue Type: Bug
Reporter: Matt Davis
Following the first three steps of the [Debian install
process|https://cassandra.apache.org/download/], after an apt-get update you'll
see this line:
{code:bash}
N: Skipping acquire of configured file 'main/binary-arm64/Packages' as
repository 'https://downloads.apache.org/cassandra/debian 311x InRelease'
doesn't support architecture 'arm64'
{code}
Checking the [Debian
repo|https://dl.bintray.com/apache/cassandra/dists/311x/main/] confirms there
is no aarch64 variant available.
Should you then attempt to install Cassandra:
{code:bash}
sudo apt-get install cassandra
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package cassandra is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'cassandra' has no installation candidate
{code}
Note that the Redhat RPM contains a "noarch" arch type, so it downloads
properly on any host. (Given that Cassandra does not use separate
binaries/releases for different architectures, this seems to be the correct
approach for Debian. That said, adding an aarch64 variant would also suffice.)
Also, there is a workaround available: if you specify "amd64" as the arch in
the deb command, it downloads and runs without issue:
{code:bash}
deb [arch=amd64] https://downloads.apache.org/cassandra/debian 311x main
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15885) replication_test.TestSnitchConfigurationUpdate.test_rf_expand_gossiping_property_file_snitch_multi_dc failure
[ https://issues.apache.org/jira/browse/CASSANDRA-15885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-15885: -- Reviewers: Andres de la Peña > replication_test.TestSnitchConfigurationUpdate.test_rf_expand_gossiping_property_file_snitch_multi_dc > failure > - > > Key: CASSANDRA-15885 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15885 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 10m > Remaining Estimate: 0h > > replication_test.TestSnitchConfigurationUpdate.test_rf_expand_gossiping_property_file_snitch_multi_dc > has been failing for a > [while|https://ci-cassandra.apache.org/job/Cassandra-trunk/176/testReport/dtest-large.replication_test/TestSnitchConfigurationUpdate/test_rf_expand_gossiping_property_file_snitch_multi_dc/history/]. > Also fails locally -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15872) Flaky test: testNoTreesRetainedAfterDifference - org.apache.cassandra.repair.RepairJobTest
[ https://issues.apache.org/jira/browse/CASSANDRA-15872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-15872: -- Fix Version/s: (was: 4.0-rc) 4.0-alpha5 Source Control Link: https://github.com/apache/cassandra/commit/a28d8f7590cc98ef25eced4b2968c577d0156e50 (was: https://github.com/apache/cassandra/pull/630) Resolution: Fixed Status: Resolved (was: Ready to Commit) > Flaky test: testNoTreesRetainedAfterDifference - > org.apache.cassandra.repair.RepairJobTest > -- > > Key: CASSANDRA-15872 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15872 > Project: Cassandra > Issue Type: Task > Components: Consistency/Repair >Reporter: ZhaoYang >Assignee: ZhaoYang >Priority: Normal > Fix For: 4.0-alpha5 > > > link: [https://circleci.com/gh/maedhroz/cassandra/21#tests/containers/95] > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15872) Flaky test: testNoTreesRetainedAfterDifference - org.apache.cassandra.repair.RepairJobTest
[ https://issues.apache.org/jira/browse/CASSANDRA-15872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142252#comment-17142252 ] Andres de la Peña commented on CASSANDRA-15872: --- Committed to trunk as [a28d8f7590cc98ef25eced4b2968c577d0156e50|https://github.com/apache/cassandra/commit/a28d8f7590cc98ef25eced4b2968c577d0156e50]. > Flaky test: testNoTreesRetainedAfterDifference - > org.apache.cassandra.repair.RepairJobTest > -- > > Key: CASSANDRA-15872 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15872 > Project: Cassandra > Issue Type: Task > Components: Consistency/Repair >Reporter: ZhaoYang >Assignee: ZhaoYang >Priority: Normal > Fix For: 4.0-rc > > > link: [https://circleci.com/gh/maedhroz/cassandra/21#tests/containers/95] > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Fix RepairJobsTest.testNoTreesRetainedAfterDifference by waiting for latch
This is an automated email from the ASF dual-hosted git repository.
adelapena pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new a28d8f7 Fix RepairJobsTest.testNoTreesRetainedAfterDifference by
waiting for latch
a28d8f7 is described below
commit a28d8f7590cc98ef25eced4b2968c577d0156e50
Author: Zhao Yang
AuthorDate: Mon Jun 22 17:34:55 2020 +0100
Fix RepairJobsTest.testNoTreesRetainedAfterDifference by waiting for latch
patch by Zhao Yang; reviewed by Caleb Rackliffe for CASSANDRA-15872
---
.../org/apache/cassandra/repair/RepairJobTest.java | 39 --
1 file changed, 37 insertions(+), 2 deletions(-)
diff --git a/test/unit/org/apache/cassandra/repair/RepairJobTest.java
b/test/unit/org/apache/cassandra/repair/RepairJobTest.java
index 5713898..d3af58f 100644
--- a/test/unit/org/apache/cassandra/repair/RepairJobTest.java
+++ b/test/unit/org/apache/cassandra/repair/RepairJobTest.java
@@ -28,6 +28,8 @@ import java.util.List;
import java.util.Map;
import java.util.Set;
import java.util.UUID;
+import java.util.concurrent.Callable;
+import java.util.concurrent.CompletableFuture;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.TimeoutException;
@@ -58,11 +60,13 @@ import org.apache.cassandra.repair.messages.SyncRequest;
import org.apache.cassandra.schema.KeyspaceParams;
import org.apache.cassandra.service.ActiveRepairService;
import org.apache.cassandra.streaming.PreviewKind;
+import org.apache.cassandra.streaming.SessionSummary;
import org.apache.cassandra.utils.ByteBufferUtil;
import org.apache.cassandra.utils.FBUtilities;
import org.apache.cassandra.utils.MerkleTree;
import org.apache.cassandra.utils.MerkleTrees;
import org.apache.cassandra.utils.ObjectSizes;
+import org.apache.cassandra.utils.Throwables;
import org.apache.cassandra.utils.UUIDGen;
import org.apache.cassandra.utils.asserts.SyncTaskListAssert;
@@ -91,7 +95,7 @@ public class RepairJobTest
private static InetAddressAndPort addr3;
private static InetAddressAndPort addr4;
private static InetAddressAndPort addr5;
-private RepairSession session;
+private MeasureableRepairSession session;
private RepairJob job;
private RepairJobDesc sessionJobDesc;
@@ -99,6 +103,8 @@ public class RepairJobTest
// memory retention from CASSANDRA-14096
private static class MeasureableRepairSession extends RepairSession
{
+private final List> syncCompleteCallbacks = new
ArrayList<>();
+
public MeasureableRepairSession(UUID parentRepairSession, UUID id,
CommonRange commonRange, String keyspace,
RepairParallelism parallelismDegree,
boolean isIncremental, boolean pullRepair,
boolean force, PreviewKind
previewKind, boolean optimiseStreams, String... cfnames)
@@ -110,8 +116,32 @@ public class RepairJobTest
{
DebuggableThreadPoolExecutor executor = super.createExecutor();
executor.setKeepAliveTime(THREAD_TIMEOUT_MILLIS,
TimeUnit.MILLISECONDS);
-return executor;}
+return executor;
+}
+
+@Override
+public void syncComplete(RepairJobDesc desc, SyncNodePair nodes,
boolean success, List summaries)
+{
+for (Callable callback : syncCompleteCallbacks)
+{
+try
+{
+callback.call();
+}
+catch (Exception e)
+{
+throw Throwables.cleaned(e);
+}
+}
+super.syncComplete(desc, nodes, success, summaries);
+}
+
+public void registerSyncCompleteCallback(Callable callback)
+{
+syncCompleteCallbacks.add(callback);
+}
}
+
@BeforeClass
public static void setupClass() throws UnknownHostException
{
@@ -221,10 +251,15 @@ public class RepairJobTest
// SyncTasks themselves should not contain significant memory
SyncTaskListAssert.assertThat(syncTasks).hasSizeLessThan(0.2 *
singleTreeSize);
+// block syncComplete execution until test has verified session still
retains the trees
+CompletableFuture future = new CompletableFuture<>();
+session.registerSyncCompleteCallback(future::get);
ListenableFuture> syncResults =
job.executeTasks(syncTasks);
// Immediately following execution the internal execution queue should
still retain the trees
assertThat(ObjectSizes.measureDeep(session)).isGreaterThan(singleTreeSize);
+// unblock syncComplete callback, session should remove trees
+future.complete(null);
// The session retains memory in the contained executor until the
threads expir
[jira] [Commented] (CASSANDRA-15883) Delete and save with same keys
[
https://issues.apache.org/jira/browse/CASSANDRA-15883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142192#comment-17142192
]
Brandon Williams commented on CASSANDRA-15883:
--
I mean cut and paste the output to this ticket.
> Delete and save with same keys
> --
>
> Key: CASSANDRA-15883
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15883
> Project: Cassandra
> Issue Type: Bug
>Reporter: Yazal Ulloa
>Priority: Normal
>
> I have a table like this: key1, key2, key3, column1, column2.
>
> When I delete a row with keys 1, 2, 3. and then insert a new row almost
> immediately with the same keys, cassandra does not store the new row even
> though the query executes successfully.
> How can I force Cassandra to store the new row, or do I have to change my
> data model?
> EDIT:
> I'm running Cassandra 3.11.6 in Docker, a single instance for development
> purposes.
> This has happen already with 3 tables.
> {code:java}
> // CREATE TABLE my_keyspace.my_chat ( country text, user_id timeuuid, chat_id
> bigint, email text, first_name text, last_name text, username text, PRIMARY
> KEY (country, user_id, chat_id));
> {code}
> {code:java}
> // CREATE TABLE my_keyspace.my_profile (CREATE TABLE my_keyspace.my_profile (
> country text, user_id timeuuid, profile_code text, id_doc text, id_doc_type
> text, user_email text, user_name text, PRIMARY KEY (country, user_id)) WITH
> CLUSTERING ORDER BY ( user_id DESC );
> {code}
> {code:java}
> // CREATE TABLE my_keyspace.role ( realm text, business_id timeuuid, user_id
> timeuuid, owner_id timeuuid, name text, status text, icon text, url text,
> description text, owner_email text, owner_name text, scope_id timeuuid,
> scope_name text, scopes SET, authorization boolean, user_email text,
> user_name text, views SET>, PRIMARY KEY (realm, business_id,
> user_id, owner_id, name, status)) WITH CLUSTERING ORDER BY ( business_id
> DESC, user_id DESC, owner_id DESC, name DESC, status DESC);
> {code}
> The value of the keys for this tables come from other tables or outside
> immutable data.
>
> I'm also using the Datastax OSS Java Driver v4.7.0 for comunications with
> Cassandra, but the problem have also presented using cqlsh.
>
> The queries I use are standard read by partition key, insert the whole row
> and delete by full partiion key.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15883) Delete and save with same keys
[
https://issues.apache.org/jira/browse/CASSANDRA-15883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142188#comment-17142188
]
Yazal Ulloa commented on CASSANDRA-15883:
-
[~brandon.williams] Do you mean the exact queries I'm using?
> Delete and save with same keys
> --
>
> Key: CASSANDRA-15883
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15883
> Project: Cassandra
> Issue Type: Bug
>Reporter: Yazal Ulloa
>Priority: Normal
>
> I have a table like this: key1, key2, key3, column1, column2.
>
> When I delete a row with keys 1, 2, 3. and then insert a new row almost
> immediately with the same keys, cassandra does not store the new row even
> though the query executes successfully.
> How can I force Cassandra to store the new row, or do I have to change my
> data model?
> EDIT:
> I'm running Cassandra 3.11.6 in Docker, a single instance for development
> purposes.
> This has happen already with 3 tables.
> {code:java}
> // CREATE TABLE my_keyspace.my_chat ( country text, user_id timeuuid, chat_id
> bigint, email text, first_name text, last_name text, username text, PRIMARY
> KEY (country, user_id, chat_id));
> {code}
> {code:java}
> // CREATE TABLE my_keyspace.my_profile (CREATE TABLE my_keyspace.my_profile (
> country text, user_id timeuuid, profile_code text, id_doc text, id_doc_type
> text, user_email text, user_name text, PRIMARY KEY (country, user_id)) WITH
> CLUSTERING ORDER BY ( user_id DESC );
> {code}
> {code:java}
> // CREATE TABLE my_keyspace.role ( realm text, business_id timeuuid, user_id
> timeuuid, owner_id timeuuid, name text, status text, icon text, url text,
> description text, owner_email text, owner_name text, scope_id timeuuid,
> scope_name text, scopes SET, authorization boolean, user_email text,
> user_name text, views SET>, PRIMARY KEY (realm, business_id,
> user_id, owner_id, name, status)) WITH CLUSTERING ORDER BY ( business_id
> DESC, user_id DESC, owner_id DESC, name DESC, status DESC);
> {code}
> The value of the keys for this tables come from other tables or outside
> immutable data.
>
> I'm also using the Datastax OSS Java Driver v4.7.0 for comunications with
> Cassandra, but the problem have also presented using cqlsh.
>
> The queries I use are standard read by partition key, insert the whole row
> and delete by full partiion key.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15752) Range read concurrency factor didn't consider range merger
[
https://issues.apache.org/jira/browse/CASSANDRA-15752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-15752:
--
Fix Version/s: (was: 4.0-beta)
(was: 3.11.x)
(was: 3.0.x)
4.0-alpha5
3.11.7
3.0.21
Since Version: 2.1 beta1
Source Control Link:
https://github.com/apache/cassandra/commit/abdf5085d4381351054bc2c0976bc826f4ac82e2
(was: trunk: https://github.com/apache/cassandra/pull/606)
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Range read concurrency factor didn't consider range merger
> --
>
> Key: CASSANDRA-15752
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15752
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Coordination
>Reporter: ZhaoYang
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 3.0.21, 3.11.7, 4.0-alpha5
>
>
> During range read, coordinator computes concurrency factor which is the
> number of vnode ranges to contact in parallel for the next batch.
> But in {{RangeCommandIterator}}, vnode ranges are merged by {{RangeMerger}}
> if vnode ranges share enough replicas to satisfy consistency level. eg. vnode
> range [a,b) has replica n1,n2,n3 and vnode range [b,c) has replica n2,n3,n4,
> so they can be merged as range [a,c) with replica n2, n3 for Quorum.
> Currently it counts number of merged ranges towards concurrency factor.
> Coordinator may fetch more ranges than needed.
>
> Another issue is that when executing range read on table with very small
> amount of data, concurrency factor can be bumped to {{size of total vnode
> ranges}}, eg. 10k, depending on the num of vnodes and cluster size. As a
> result, coordinator will send large number of concurrent range requests,
> potentially slowing down the cluster.. We should cap the max concurrency
> factor..
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15752) Range read concurrency factor didn't consider range merger
[
https://issues.apache.org/jira/browse/CASSANDRA-15752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142180#comment-17142180
]
Andres de la Peña commented on CASSANDRA-15752:
---
Committed to 3.0 as
[abdf5085d4381351054bc2c0976bc826f4ac82e2|https://github.com/apache/cassandra/commit/abdf5085d4381351054bc2c0976bc826f4ac82e2]
and merged up to
[3.11|https://github.com/apache/cassandra/commit/61ecfda2e68a3142a671cb50ad8786b5354c91ff]
and
[trunk|https://github.com/apache/cassandra/commit/9629c1650d53af6e624d9317c83e4bc1998b04bd].
> Range read concurrency factor didn't consider range merger
> --
>
> Key: CASSANDRA-15752
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15752
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Coordination
>Reporter: ZhaoYang
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
>
> During range read, coordinator computes concurrency factor which is the
> number of vnode ranges to contact in parallel for the next batch.
> But in {{RangeCommandIterator}}, vnode ranges are merged by {{RangeMerger}}
> if vnode ranges share enough replicas to satisfy consistency level. eg. vnode
> range [a,b) has replica n1,n2,n3 and vnode range [b,c) has replica n2,n3,n4,
> so they can be merged as range [a,c) with replica n2, n3 for Quorum.
> Currently it counts number of merged ranges towards concurrency factor.
> Coordinator may fetch more ranges than needed.
>
> Another issue is that when executing range read on table with very small
> amount of data, concurrency factor can be bumped to {{size of total vnode
> ranges}}, eg. 10k, depending on the num of vnodes and cluster size. As a
> result, coordinator will send large number of concurrent range requests,
> potentially slowing down the cluster.. We should cap the max concurrency
> factor..
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (d6d55d2 -> 61ecfda)
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from d6d55d2 changed imports for jackson classes for CompactionLogger new abdf508 Count vnode ranges towards concurrency factor instead merged ranges and cap max concurrency factor by core * 10 new 61ecfda Merge branch 'cassandra-3.0' into cassandra-3.11 The 2 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 + .../org/apache/cassandra/service/StorageProxy.java | 114 .../cassandra/db/PartitionRangeReadTest.java | 143 + 3 files changed, 235 insertions(+), 23 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (de33321 -> 9629c16)
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from de33321 switch from www.apache.org to downloads.apache.org new abdf508 Count vnode ranges towards concurrency factor instead merged ranges and cap max concurrency factor by core * 10 new 61ecfda Merge branch 'cassandra-3.0' into cassandra-3.11 new 9629c16 Merge branch 'cassandra-3.11' into trunk The 3 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 + .../org/apache/cassandra/locator/ReplicaPlan.java | 18 ++- .../org/apache/cassandra/locator/ReplicaPlans.java | 10 +- .../org/apache/cassandra/service/StorageProxy.java | 93 +++--- .../reads/ShortReadPartitionsProtection.java | 2 +- .../cassandra/db/PartitionRangeReadTest.java | 140 + .../cassandra/service/reads/DataResolverTest.java | 4 +- .../reads/repair/AbstractReadRepairTest.java | 3 +- 8 files changed, 237 insertions(+), 34 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated: Count vnode ranges towards concurrency factor instead merged ranges and cap max concurrency factor by core * 10
This is an automated email from the ASF dual-hosted git repository.
adelapena pushed a commit to branch cassandra-3.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-3.0 by this push:
new abdf508 Count vnode ranges towards concurrency factor instead merged
ranges and cap max concurrency factor by core * 10
abdf508 is described below
commit abdf5085d4381351054bc2c0976bc826f4ac82e2
Author: Zhao Yang
AuthorDate: Mon Jun 22 15:34:22 2020 +0100
Count vnode ranges towards concurrency factor instead merged ranges and cap
max concurrency factor by core * 10
patch by Zhao Yang; reviewed by Andres de la Peña, Caleb Rackliffe for
CASSANDRA-15752
---
CHANGES.txt| 1 +
.../org/apache/cassandra/service/StorageProxy.java | 115 +
.../cassandra/db/PartitionRangeReadTest.java | 143 +
3 files changed, 235 insertions(+), 24 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index d1b1416..dc50ff5 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.0.21
+ * Fixed range read concurrency factor computation and capped as 10 times tpc
cores (CASSANDRA-15752)
* Catch exception on bootstrap resume and init native transport
(CASSANDRA-15863)
* Fix replica-side filtering returning stale data with CL > ONE
(CASSANDRA-8272, CASSANDRA-8273)
* Fix duplicated row on 2.x upgrades when multi-rows range tombstones
interact with collection ones (CASSANDRA-15805)
diff --git a/src/java/org/apache/cassandra/service/StorageProxy.java
b/src/java/org/apache/cassandra/service/StorageProxy.java
index 19cd901..c7888c4 100644
--- a/src/java/org/apache/cassandra/service/StorageProxy.java
+++ b/src/java/org/apache/cassandra/service/StorageProxy.java
@@ -26,6 +26,7 @@ import java.util.concurrent.atomic.AtomicInteger;
import java.util.concurrent.atomic.AtomicLong;
import com.google.common.base.Predicate;
+import com.google.common.annotations.VisibleForTesting;
import com.google.common.cache.CacheLoader;
import com.google.common.collect.*;
import com.google.common.primitives.Ints;
@@ -99,6 +100,15 @@ public class StorageProxy implements StorageProxyMBean
private static final double CONCURRENT_SUBREQUESTS_MARGIN = 0.10;
+/**
+ * Introduce a maximum number of sub-ranges that the coordinator can
request in parallel for range queries. Previously
+ * we would request up to the maximum number of ranges but this causes
problems if the number of vnodes is large.
+ * By default we pick 10 requests per core, assuming all replicas have the
same number of cores. The idea is that we
+ * don't want a burst of range requests that will back up, hurting all
other queries. At the same time,
+ * we want to give range queries a chance to run if resources are
available.
+ */
+private static final int MAX_CONCURRENT_RANGE_REQUESTS = Math.max(1,
Integer.getInteger("cassandra.max_concurrent_range_requests",
FBUtilities.getAvailableProcessors() * 10));
+
private StorageProxy()
{
}
@@ -1838,21 +1848,33 @@ public class StorageProxy implements StorageProxyMBean
return (maxExpectedResults / DatabaseDescriptor.getNumTokens()) /
keyspace.getReplicationStrategy().getReplicationFactor();
}
-private static class RangeForQuery
+@VisibleForTesting
+public static class RangeForQuery
{
public final AbstractBounds range;
public final List liveEndpoints;
public final List filteredEndpoints;
+public final int vnodeCount;
-public RangeForQuery(AbstractBounds range,
List liveEndpoints, List filteredEndpoints)
+public RangeForQuery(AbstractBounds range,
+ List liveEndpoints,
+ List filteredEndpoints,
+ int vnodeCount)
{
this.range = range;
this.liveEndpoints = liveEndpoints;
this.filteredEndpoints = filteredEndpoints;
+this.vnodeCount = vnodeCount;
+}
+
+public int vnodeCount()
+{
+return vnodeCount;
}
}
-private static class RangeIterator extends AbstractIterator
+@VisibleForTesting
+public static class RangeIterator extends AbstractIterator
{
private final Keyspace keyspace;
private final ConsistencyLevel consistency;
@@ -1885,17 +1907,19 @@ public class StorageProxy implements StorageProxyMBean
List liveEndpoints = getLiveSortedEndpoints(keyspace,
range.right);
return new RangeForQuery(range,
liveEndpoints,
- consistency.filterForQuery(keyspace,
liveEndpoints));
+ consistency.filterForQuery(keyspace,
liveEndpoints),
+ 1);
}
[cassandra] 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository.
adelapena pushed a commit to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 61ecfda2e68a3142a671cb50ad8786b5354c91ff
Merge: d6d55d2 abdf508
Author: Andrés de la Peña
AuthorDate: Mon Jun 22 15:43:15 2020 +0100
Merge branch 'cassandra-3.0' into cassandra-3.11
# Conflicts:
# CHANGES.txt
# src/java/org/apache/cassandra/service/StorageProxy.java
CHANGES.txt| 1 +
.../org/apache/cassandra/service/StorageProxy.java | 114
.../cassandra/db/PartitionRangeReadTest.java | 143 +
3 files changed, 235 insertions(+), 23 deletions(-)
diff --cc CHANGES.txt
index 114ce07,dc50ff5..aa4be97
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,8 -1,5 +1,9 @@@
-3.0.21
+3.11.7
+ * Upgrade Jackson to 2.9.10 (CASSANDRA-15867)
+ * Fix CQL formatting of read command restrictions for slow query log
(CASSANDRA-15503)
+ * Allow sstableloader to use SSL on the native port (CASSANDRA-14904)
+Merged from 3.0:
+ * Fixed range read concurrency factor computation and capped as 10 times tpc
cores (CASSANDRA-15752)
* Catch exception on bootstrap resume and init native transport
(CASSANDRA-15863)
* Fix replica-side filtering returning stale data with CL > ONE
(CASSANDRA-8272, CASSANDRA-8273)
* Fix duplicated row on 2.x upgrades when multi-rows range tombstones
interact with collection ones (CASSANDRA-15805)
diff --cc src/java/org/apache/cassandra/service/StorageProxy.java
index 2ca2c85,c7888c4..b1e0696
--- a/src/java/org/apache/cassandra/service/StorageProxy.java
+++ b/src/java/org/apache/cassandra/service/StorageProxy.java
@@@ -2108,17 -2026,24 +2134,26 @@@ public class StorageProxy implements St
// when it was not good enough initially.
private int liveReturned;
private int rangesQueried;
+ private int batchesRequested = 0;
- public RangeCommandIterator(RangeIterator ranges,
PartitionRangeReadCommand command, int concurrencyFactor, Keyspace keyspace,
ConsistencyLevel consistency, long queryStartNanoTime)
+ public RangeCommandIterator(Iterator ranges,
+ PartitionRangeReadCommand command,
+ int concurrencyFactor,
+ int maxConcurrencyFactor,
+ int totalRangeCount,
+ Keyspace keyspace,
-ConsistencyLevel consistency)
++ConsistencyLevel consistency,
++long queryStartNanoTime)
{
this.command = command;
this.concurrencyFactor = concurrencyFactor;
+ this.maxConcurrencyFactor = maxConcurrencyFactor;
this.startTime = System.nanoTime();
- this.ranges = new RangeMerger(ranges, keyspace, consistency);
- this.totalRangeCount = ranges.rangeCount();
+ this.ranges = ranges;
+ this.totalRangeCount = totalRangeCount;
this.consistency = consistency;
this.keyspace = keyspace;
+this.queryStartNanoTime = queryStartNanoTime;
this.enforceStrictLiveness =
command.metadata().enforceStrictLiveness();
}
@@@ -2175,27 -2108,20 +2218,28 @@@
// Otherwise, compute how many rows per range we got on average
and pick a concurrency factor
// that should allow us to fetch all remaining rows with the next
batch of (concurrent) queries.
- int remainingRows = command.limits().count() - liveReturned;
+ int remainingRows = limit - liveReturned;
float rowsPerRange = (float)liveReturned / (float)rangesQueried;
- concurrencyFactor = Math.max(1, Math.min(totalRangeCount -
rangesQueried, Math.round(remainingRows / rowsPerRange)));
+ int concurrencyFactor = Math.max(1,
Math.min(maxConcurrencyFactor, Math.round(remainingRows / rowsPerRange)));
logger.trace("Didn't get enough response rows; actual rows per
range: {}; remaining rows: {}, new concurrent requests: {}",
rowsPerRange, remainingRows, concurrencyFactor);
-
+ return concurrencyFactor;
}
-private SingleRangeResponse query(RangeForQuery toQuery)
+/**
+ * Queries the provided sub-range.
+ *
+ * @param toQuery the subRange to query.
+ * @param isFirst in the case where multiple queries are sent in
parallel, whether that's the first query on
+ * that batch or not. The reason it matters is that whe paging
queries, the command (more specifically the
+ * {@code DataLimits}) may have "state" information and that state
may only be valid for the first q
[jira] [Assigned] (CASSANDRA-15885) replication_test.TestSnitchConfigurationUpdate.test_rf_expand_gossiping_property_file_snitch_multi_dc failure
[ https://issues.apache.org/jira/browse/CASSANDRA-15885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi reassigned CASSANDRA-15885: --- Assignee: Berenguer Blasi > replication_test.TestSnitchConfigurationUpdate.test_rf_expand_gossiping_property_file_snitch_multi_dc > failure > - > > Key: CASSANDRA-15885 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15885 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 10m > Remaining Estimate: 0h > > replication_test.TestSnitchConfigurationUpdate.test_rf_expand_gossiping_property_file_snitch_multi_dc > has been failing for a > [while|https://ci-cassandra.apache.org/job/Cassandra-trunk/176/testReport/dtest-large.replication_test/TestSnitchConfigurationUpdate/test_rf_expand_gossiping_property_file_snitch_multi_dc/history/]. > Also fails locally -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15872) Flaky test: testNoTreesRetainedAfterDifference - org.apache.cassandra.repair.RepairJobTest
[ https://issues.apache.org/jira/browse/CASSANDRA-15872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-15872: Status: Ready to Commit (was: Review In Progress) > Flaky test: testNoTreesRetainedAfterDifference - > org.apache.cassandra.repair.RepairJobTest > -- > > Key: CASSANDRA-15872 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15872 > Project: Cassandra > Issue Type: Task > Components: Consistency/Repair >Reporter: ZhaoYang >Assignee: ZhaoYang >Priority: Normal > Fix For: 4.0-rc > > > link: [https://circleci.com/gh/maedhroz/cassandra/21#tests/containers/95] > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15872) Flaky test: testNoTreesRetainedAfterDifference - org.apache.cassandra.repair.RepairJobTest
[ https://issues.apache.org/jira/browse/CASSANDRA-15872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142161#comment-17142161 ] Caleb Rackliffe commented on CASSANDRA-15872: - +1 > Flaky test: testNoTreesRetainedAfterDifference - > org.apache.cassandra.repair.RepairJobTest > -- > > Key: CASSANDRA-15872 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15872 > Project: Cassandra > Issue Type: Task > Components: Consistency/Repair >Reporter: ZhaoYang >Assignee: ZhaoYang >Priority: Normal > Fix For: 4.0-rc > > > link: [https://circleci.com/gh/maedhroz/cassandra/21#tests/containers/95] > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15872) Flaky test: testNoTreesRetainedAfterDifference - org.apache.cassandra.repair.RepairJobTest
[ https://issues.apache.org/jira/browse/CASSANDRA-15872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-15872: Reviewers: Caleb Rackliffe (was: Caleb Rackliffe, ZhaoYang) > Flaky test: testNoTreesRetainedAfterDifference - > org.apache.cassandra.repair.RepairJobTest > -- > > Key: CASSANDRA-15872 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15872 > Project: Cassandra > Issue Type: Task > Components: Consistency/Repair >Reporter: ZhaoYang >Assignee: ZhaoYang >Priority: Normal > Fix For: 4.0-rc > > > link: [https://circleci.com/gh/maedhroz/cassandra/21#tests/containers/95] > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15877) Followup on CASSANDRA-15600
[ https://issues.apache.org/jira/browse/CASSANDRA-15877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-15877: Reviewers: Andres de la Peña, Berenguer Blasi, Brandon Williams (was: Berenguer Blasi, Ekaterina Dimitrova) > Followup on CASSANDRA-15600 > --- > > Key: CASSANDRA-15877 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15877 > Project: Cassandra > Issue Type: Bug > Components: Feature/Virtual Nodes >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0, 4.0-alpha > > Attachments: Screen Shot 2020-06-12 at 3.21.18 PM.png > > > As part of CASSANDRA-15600 generateSplits method replaced the > generateRandomTokens for NoReplicationAwareTokenAllocator. generateSplits > should be used also in ReplicationAwareTokenAllocator. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15877) Followup on CASSANDRA-15600
[ https://issues.apache.org/jira/browse/CASSANDRA-15877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-15877: - Status: Changes Suggested (was: Review In Progress) > Followup on CASSANDRA-15600 > --- > > Key: CASSANDRA-15877 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15877 > Project: Cassandra > Issue Type: Bug > Components: Feature/Virtual Nodes >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0, 4.0-alpha > > Attachments: Screen Shot 2020-06-12 at 3.21.18 PM.png > > > As part of CASSANDRA-15600 generateSplits method replaced the > generateRandomTokens for NoReplicationAwareTokenAllocator. generateSplits > should be used also in ReplicationAwareTokenAllocator. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15863) Bootstrap resume and TestReplaceAddress fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-15863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142101#comment-17142101 ] Andres de la Peña commented on CASSANDRA-15863: --- Great, thanks (y) > Bootstrap resume and TestReplaceAddress fixes > - > > Key: CASSANDRA-15863 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15863 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission, Test/dtest >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0-alpha > > Time Spent: 10m > Remaining Estimate: 0h > > This has been > [broken|https://ci-cassandra.apache.org/job/Cassandra-trunk/159/testReport/dtest-large.replace_address_test/TestReplaceAddress/test_restart_failed_replace/history/] > for ages -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15888) DOC - Installation pages, curl command for retrieving keys
[ https://issues.apache.org/jira/browse/CASSANDRA-15888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-15888: - Reviewers: Brandon Williams (was: Brandon Williams, Brandon Williams) > DOC - Installation pages, curl command for retrieving keys > -- > > Key: CASSANDRA-15888 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15888 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Max Böhm >Assignee: Max Böhm >Priority: Normal > Labels: pull-request-available > Fix For: 4.0, 4.0-alpha5 > > > I noticed that on the *getting_started/installing* page in the Debian section > the curl command for retrieving the cassandra GPG KEYS does not work (the URL > gets redirected and no data is returned by curl). > It might be fixed by adding '-L' to the curl command or by changing > [www.apache.org|http://www.apache.org/] to downloads.apache.org on that page > (commit c93c2983cd3f did this previously but is no longer in the code). > > I have created a pull request for this issue: > [https://github.com/apache/cassandra/pull/648] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15888) DOC - Installation pages, curl command for retrieving keys
[ https://issues.apache.org/jira/browse/CASSANDRA-15888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-15888: - Fix Version/s: (was: 4.0-alpha4) 4.0-alpha5 > DOC - Installation pages, curl command for retrieving keys > -- > > Key: CASSANDRA-15888 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15888 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Max Böhm >Assignee: Max Böhm >Priority: Normal > Labels: pull-request-available > Fix For: 4.0, 4.0-alpha5 > > > I noticed that on the *getting_started/installing* page in the Debian section > the curl command for retrieving the cassandra GPG KEYS does not work (the URL > gets redirected and no data is returned by curl). > It might be fixed by adding '-L' to the curl command or by changing > [www.apache.org|http://www.apache.org/] to downloads.apache.org on that page > (commit c93c2983cd3f did this previously but is no longer in the code). > > I have created a pull request for this issue: > [https://github.com/apache/cassandra/pull/648] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15888) DOC - Installation pages, curl command for retrieving keys
[ https://issues.apache.org/jira/browse/CASSANDRA-15888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-15888: - Source Control Link: https://github.com/apache/cassandra/commit/de333212a443085fb51e6744cd268b6bd54faf9b Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed, thanks! > DOC - Installation pages, curl command for retrieving keys > -- > > Key: CASSANDRA-15888 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15888 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Max Böhm >Assignee: Max Böhm >Priority: Normal > Labels: pull-request-available > Fix For: 4.0, 4.0-alpha4 > > > I noticed that on the *getting_started/installing* page in the Debian section > the curl command for retrieving the cassandra GPG KEYS does not work (the URL > gets redirected and no data is returned by curl). > It might be fixed by adding '-L' to the curl command or by changing > [www.apache.org|http://www.apache.org/] to downloads.apache.org on that page > (commit c93c2983cd3f did this previously but is no longer in the code). > > I have created a pull request for this issue: > [https://github.com/apache/cassandra/pull/648] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15888) DOC - Installation pages, curl command for retrieving keys
[ https://issues.apache.org/jira/browse/CASSANDRA-15888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-15888: - Reviewers: Brandon Williams, Brandon Williams (was: Brandon Williams, Brandon Williams) Brandon Williams, Brandon Williams Status: Review In Progress (was: Patch Available) > DOC - Installation pages, curl command for retrieving keys > -- > > Key: CASSANDRA-15888 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15888 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Max Böhm >Assignee: Max Böhm >Priority: Normal > Labels: pull-request-available > Fix For: 4.0, 4.0-alpha4 > > > I noticed that on the *getting_started/installing* page in the Debian section > the curl command for retrieving the cassandra GPG KEYS does not work (the URL > gets redirected and no data is returned by curl). > It might be fixed by adding '-L' to the curl command or by changing > [www.apache.org|http://www.apache.org/] to downloads.apache.org on that page > (commit c93c2983cd3f did this previously but is no longer in the code). > > I have created a pull request for this issue: > [https://github.com/apache/cassandra/pull/648] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15888) DOC - Installation pages, curl command for retrieving keys
[ https://issues.apache.org/jira/browse/CASSANDRA-15888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-15888: - Status: Ready to Commit (was: Review In Progress) > DOC - Installation pages, curl command for retrieving keys > -- > > Key: CASSANDRA-15888 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15888 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Max Böhm >Assignee: Max Böhm >Priority: Normal > Labels: pull-request-available > Fix For: 4.0, 4.0-alpha4 > > > I noticed that on the *getting_started/installing* page in the Debian section > the curl command for retrieving the cassandra GPG KEYS does not work (the URL > gets redirected and no data is returned by curl). > It might be fixed by adding '-L' to the curl command or by changing > [www.apache.org|http://www.apache.org/] to downloads.apache.org on that page > (commit c93c2983cd3f did this previously but is no longer in the code). > > I have created a pull request for this issue: > [https://github.com/apache/cassandra/pull/648] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: switch from www.apache.org to downloads.apache.org
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/trunk by this push: new de33321 switch from www.apache.org to downloads.apache.org de33321 is described below commit de333212a443085fb51e6744cd268b6bd54faf9b Author: Max Böhm AuthorDate: Sat Jun 20 19:19:40 2020 +0200 switch from www.apache.org to downloads.apache.org Patch by Max Böhm, reviewed by brandonwilliams for CASSANDRA-15888 --- doc/source/getting_started/installing.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/source/getting_started/installing.rst b/doc/source/getting_started/installing.rst index f3a22f2..1d59b8b 100644 --- a/doc/source/getting_started/installing.rst +++ b/doc/source/getting_started/installing.rst @@ -180,14 +180,14 @@ Installing the Debian packages :: - $ echo "deb http://www.apache.org/dist/cassandra/debian 40x main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list - deb http://www.apache.org/dist/cassandra/debian 40x main + $ echo "deb http://downloads.apache.org/cassandra/debian 40x main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list + deb http://downloads.apache.org/cassandra/debian 40x main 3. Add the Apache Cassandra repository keys to the list of trusted keys on the server: :: - $ curl https://www.apache.org/dist/cassandra/KEYS | sudo apt-key add - + $ curl https://downloads.apache.org/cassandra/KEYS | sudo apt-key add - % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 266k 100 266k0 0 320k 0 --:--:-- --:--:-- --:--:-- 320k - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15877) Followup on CASSANDRA-15600
[ https://issues.apache.org/jira/browse/CASSANDRA-15877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142086#comment-17142086 ] Brandon Williams commented on CASSANDRA-15877: -- Did you see the comments that Andres left on your PR? > Followup on CASSANDRA-15600 > --- > > Key: CASSANDRA-15877 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15877 > Project: Cassandra > Issue Type: Bug > Components: Feature/Virtual Nodes >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0, 4.0-alpha > > Attachments: Screen Shot 2020-06-12 at 3.21.18 PM.png > > > As part of CASSANDRA-15600 generateSplits method replaced the > generateRandomTokens for NoReplicationAwareTokenAllocator. generateSplits > should be used also in ReplicationAwareTokenAllocator. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15677) Topology events are not sent to clients if the nodes use the same network interface
[
https://issues.apache.org/jira/browse/CASSANDRA-15677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15677:
-
Reviewers: Brandon Williams, Brandon Williams (was: Brandon Williams)
Brandon Williams, Brandon Williams (was: Brandon Williams)
Status: Review In Progress (was: Patch Available)
> Topology events are not sent to clients if the nodes use the same network
> interface
> ---
>
> Key: CASSANDRA-15677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15677
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Alan Boudreault
>Assignee: Bryn Cooke
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha5
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> *This bug only happens when the cassandra nodes are configured to use a
> single network interface (ip) but different ports. See CASSANDRA-7544.*
> Issue: The topology events aren't sent to clients. The problem is that the
> port is not taken into account when determining if we send it or not:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/Server.java#L624
> To reproduce:
> {code}
> # I think the cassandra-test branch is required to get the -S option
> (USE_SINGLE_INTERFACE)
> ccm create -n4 local40 -v 4.0-alpha2 -S
> {code}
>
> Then run this small python driver script:
> {code}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect()
> while True:
> print(cluster.metadata.all_hosts())
> print([h.is_up for h in cluster.metadata.all_hosts()])
> time.sleep(5)
> {code}
> Then decommission a node:
> {code}
> ccm node2 nodetool disablebinary
> ccm node2 nodetool decommission
> {code}
>
> You should see that the node is never removed from the client cluster
> metadata and the reconnector started.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15677) Topology events are not sent to clients if the nodes use the same network interface
[
https://issues.apache.org/jira/browse/CASSANDRA-15677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15677:
-
Status: Ready to Commit (was: Review In Progress)
> Topology events are not sent to clients if the nodes use the same network
> interface
> ---
>
> Key: CASSANDRA-15677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15677
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Alan Boudreault
>Assignee: Bryn Cooke
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha5
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> *This bug only happens when the cassandra nodes are configured to use a
> single network interface (ip) but different ports. See CASSANDRA-7544.*
> Issue: The topology events aren't sent to clients. The problem is that the
> port is not taken into account when determining if we send it or not:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/Server.java#L624
> To reproduce:
> {code}
> # I think the cassandra-test branch is required to get the -S option
> (USE_SINGLE_INTERFACE)
> ccm create -n4 local40 -v 4.0-alpha2 -S
> {code}
>
> Then run this small python driver script:
> {code}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect()
> while True:
> print(cluster.metadata.all_hosts())
> print([h.is_up for h in cluster.metadata.all_hosts()])
> time.sleep(5)
> {code}
> Then decommission a node:
> {code}
> ccm node2 nodetool disablebinary
> ccm node2 nodetool decommission
> {code}
>
> You should see that the node is never removed from the client cluster
> metadata and the reconnector started.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15677) Topology events are not sent to clients if the nodes use the same network interface
[
https://issues.apache.org/jira/browse/CASSANDRA-15677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15677:
-
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed both, thanks!
> Topology events are not sent to clients if the nodes use the same network
> interface
> ---
>
> Key: CASSANDRA-15677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15677
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Alan Boudreault
>Assignee: Bryn Cooke
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha5
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> *This bug only happens when the cassandra nodes are configured to use a
> single network interface (ip) but different ports. See CASSANDRA-7544.*
> Issue: The topology events aren't sent to clients. The problem is that the
> port is not taken into account when determining if we send it or not:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/Server.java#L624
> To reproduce:
> {code}
> # I think the cassandra-test branch is required to get the -S option
> (USE_SINGLE_INTERFACE)
> ccm create -n4 local40 -v 4.0-alpha2 -S
> {code}
>
> Then run this small python driver script:
> {code}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect()
> while True:
> print(cluster.metadata.all_hosts())
> print([h.is_up for h in cluster.metadata.all_hosts()])
> time.sleep(5)
> {code}
> Then decommission a node:
> {code}
> ccm node2 nodetool disablebinary
> ccm node2 nodetool decommission
> {code}
>
> You should see that the node is never removed from the client cluster
> metadata and the reconnector started.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Update driver version to prevent issues with extra events being received when a node is decommissioned.
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 02a80ef Update driver version to prevent issues with extra events
being received when a node is decommissioned.
02a80ef is described below
commit 02a80ef94fc8ea4dd5ef443869ce1a4e9f37c817
Author: bryn
AuthorDate: Fri Jun 19 13:06:06 2020 +0100
Update driver version to prevent issues with extra events being received
when a node is decommissioned.
Patch by Bryn Cooke, reviewed by brandonwilliams for CASSANDRA-15677
---
build.xml | 2 +-
jar => cassandra-driver-core-3.9.0-shaded.jar} | Bin 2725381 -> 2757525
bytes
.../distributed/test/NodeDecommissionTest.java | 57 --
.../distributed/test/TopologyChangeTest.java | 198 +
.../cassandra/auth/PasswordAuthenticatorTest.java | 3 +-
5 files changed, 201 insertions(+), 59 deletions(-)
diff --git a/build.xml b/build.xml
index 2d10819..15d4276 100644
--- a/build.xml
+++ b/build.xml
@@ -599,7 +599,7 @@
-
+
diff --git a/lib/cassandra-driver-core-3.6.0-shaded.jar
b/lib/cassandra-driver-core-3.9.0-shaded.jar
similarity index 69%
rename from lib/cassandra-driver-core-3.6.0-shaded.jar
rename to lib/cassandra-driver-core-3.9.0-shaded.jar
index ea06b02..1ecabbb 100644
Binary files a/lib/cassandra-driver-core-3.6.0-shaded.jar and
b/lib/cassandra-driver-core-3.9.0-shaded.jar differ
diff --git
a/test/distributed/org/apache/cassandra/distributed/test/NodeDecommissionTest.java
b/test/distributed/org/apache/cassandra/distributed/test/NodeDecommissionTest.java
deleted file mode 100644
index 43aaadb..000
---
a/test/distributed/org/apache/cassandra/distributed/test/NodeDecommissionTest.java
+++ /dev/null
@@ -1,57 +0,0 @@
-/*
- * Licensed to the Apache Software Foundation (ASF) under one
- * or more contributor license agreements. See the NOTICE file
- * distributed with this work for additional information
- * regarding copyright ownership. The ASF licenses this file
- * to you under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance
- * with the License. You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-
-package org.apache.cassandra.distributed.test;
-
-import java.util.concurrent.TimeUnit;
-
-import org.junit.Assert;
-import org.junit.Test;
-
-import com.datastax.driver.core.Session;
-import org.apache.cassandra.distributed.Cluster;
-
-import static org.apache.cassandra.distributed.api.Feature.GOSSIP;
-import static org.apache.cassandra.distributed.api.Feature.NATIVE_PROTOCOL;
-import static org.apache.cassandra.distributed.api.Feature.NETWORK;
-import static
org.apache.cassandra.distributed.impl.INodeProvisionStrategy.Strategy.OneNetworkInterface;
-import static org.awaitility.Awaitility.await;
-
-public class NodeDecommissionTest extends TestBaseImpl
-{
-
-@Test
-public void testDecomissionSucceedsForNodesOnTheSameInterface() throws
Throwable
-{
-try (Cluster control =
init(Cluster.build().withNodes(3).withNodeProvisionStrategy(OneNetworkInterface).withConfig(
-config -> {
-config.with(GOSSIP, NETWORK, NATIVE_PROTOCOL);
-}).start()))
-{
-final com.datastax.driver.core.Cluster cluster =
com.datastax.driver.core.Cluster.builder().addContactPoint("127.0.0.1").build();
-Session session = cluster.connect();
-control.get(3).nodetool("disablebinary");
-control.get(3).nodetool("decommission", "-f");
-await().atMost(10, TimeUnit.SECONDS)
- .untilAsserted(() -> Assert.assertEquals(2,
cluster.getMetadata().getAllHosts().size()));
-session.close();
-cluster.close();
-}
-}
-}
-
diff --git
a/test/distributed/org/apache/cassandra/distributed/test/TopologyChangeTest.java
b/test/distributed/org/apache/cassandra/distributed/test/TopologyChangeTest.java
new file mode 100644
index 000..f766775
--- /dev/null
+++
b/test/distributed/org/apache/cassandra/distributed/test/TopologyChangeTest.java
@@ -0,0 +1,198 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership
[cassandra-dtest] branch master updated: Updated tests to expect topology events for localhost clusters Post 4.0.
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git
The following commit(s) were added to refs/heads/master by this push:
new 1a65f3e Updated tests to expect topology events for localhost
clusters Post 4.0.
1a65f3e is described below
commit 1a65f3e1f631f0b69f04d17576956479e97e4e30
Author: bryn
AuthorDate: Mon Jun 22 11:44:30 2020 +0100
Updated tests to expect topology events for localhost clusters Post 4.0.
Patch by Bryn Cooke, reviewed by brandonwilliams for CASSANDRA-15677
---
pushed_notifications_test.py | 40 ++--
1 file changed, 34 insertions(+), 6 deletions(-)
diff --git a/pushed_notifications_test.py b/pushed_notifications_test.py
index 40ae18f..fb703e9 100644
--- a/pushed_notifications_test.py
+++ b/pushed_notifications_test.py
@@ -11,7 +11,7 @@ from cassandra import ReadFailure
from cassandra.query import SimpleStatement
from ccmlib.node import Node, TimeoutError
-from dtest import Tester, get_ip_from_node, create_ks
+from dtest import Tester, get_ip_from_node, get_port_from_node, create_ks
since = pytest.mark.since
logger = logging.getLogger(__name__)
@@ -121,9 +121,12 @@ class TestPushedNotifications(Tester):
@pytest.mark.no_vnodes
def test_move_single_node_localhost(self):
"""
-@jira_ticket CASSANDRA-10052
Test that we don't get NODE_MOVED notifications from nodes other than
the local one,
-when rpc_address is set to localhost (127.0.0.1).
+when rpc_address is set to localhost (127.0.0.1) Pre 4.0.
+Test that we get NODE_MOVED notifications from nodes other than the
local one,
+when rpc_address is set to localhost (127.0.0.1) Post 4.0.
+@jira_ticket CASSANDRA-10052
+@jira_ticket CASSANDRA-15677
To set-up this test we override the rpc_address to "localhost
(127.0.0.1)" for all nodes, and
therefore we must change the rpc port or else processes won't start.
@@ -148,10 +151,22 @@ class TestPushedNotifications(Tester):
node1 = list(self.cluster.nodes.values())[0]
node1.move("123")
+version = self.cluster.cassandra_version()
for waiter in waiters:
logger.debug("Waiting for notification from
{}".format(waiter.address,))
notifications = waiter.wait_for_notifications(30.0)
-assert 1 if waiter.node is node1 else 0 == len(notifications),
notifications
+if version >= '4.0':
+# CASSANDRA-15677 Post 4.0 we'll get the notifications. Check
that they are for the right node.
+assert 1 == len(notifications), notifications
+notification = notifications[0]
+change_type = notification["change_type"]
+address, port = notification["address"]
+assert "MOVED_NODE" == change_type
+assert get_ip_from_node(node1) == address
+assert get_port_from_node(node1) == port
+else:
+assert 1 if waiter.node is node1 else 0 == len(notifications),
notifications
+
def test_restart_node(self):
"""
@@ -194,8 +209,10 @@ class TestPushedNotifications(Tester):
def test_restart_node_localhost(self):
"""
-Test that we don't get client notifications when rpc_address is set to
localhost.
+Test that we don't get client notifications when rpc_address is set to
localhost Pre 4.0.
+Test that we get correct client notifications when rpc_address is set
to localhost Post 4.0.
@jira_ticket CASSANDRA-10052
+@jira_ticket CASSANDRA-15677
To set-up this test we override the rpc_address to "localhost" for all
nodes, and
therefore we must change the rpc port or else processes won't start.
@@ -219,7 +236,18 @@ class TestPushedNotifications(Tester):
# check that node1 did not send UP or DOWN notification for node2
logger.debug("Waiting for notifications from
{}".format(waiter.address,))
notifications = waiter.wait_for_notifications(timeout=30.0,
num_notifications=2)
-assert 0 == len(notifications), notifications
+version = self.cluster.cassandra_version()
+
+if version >= '4.0':
+# CASSANDRA-15677 Post 4.0 we'll get the notifications. Check that
they are for the right node.
+for notification in notifications:
+address, port = notification["address"]
+assert get_ip_from_node(node2) == address
+assert get_port_from_node(node2) == port
+assert "DOWN" == notifications[0]["change_type"], notifications
+assert "UP" == notifications[1]["change_type"], notifications
+else:
+assert 0 == len(notifications), notifications
@since("2.2")
def test
[jira] [Updated] (CASSANDRA-15867) Update Jackson version to 2.9.10.1 because there are security issues in 2.9.5
[ https://issues.apache.org/jira/browse/CASSANDRA-15867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-15867: - Status: Resolved (was: Ready to Commit) > Update Jackson version to 2.9.10.1 because there are security issues in 2.9.5 > - > > Key: CASSANDRA-15867 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15867 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.11.7, 4.0-alpha5 > > Attachments: dependency-check-report.html > > > Please see attached HTML report from OWASP dependency check for current > 4.0-alpha5 trunk branch. > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15867) Update Jackson version to 2.9.10.1 because there are security issues in 2.9.5
[ https://issues.apache.org/jira/browse/CASSANDRA-15867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-15867: - Status: Ready to Commit (was: Review In Progress) CI: https://ci-cassandra.apache.org/job/Cassandra-devbranch/159/ > Update Jackson version to 2.9.10.1 because there are security issues in 2.9.5 > - > > Key: CASSANDRA-15867 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15867 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.11.7, 4.0-alpha5 > > Attachments: dependency-check-report.html > > > Please see attached HTML report from OWASP dependency check for current > 4.0-alpha5 trunk branch. > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - 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-3.11' into trunk
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 03612b32242302950a712c92189a33c4df7e6078 Merge: 678fdf4 d6d55d2 Author: Brandon Williams AuthorDate: Mon Jun 22 09:11:31 2020 -0500 Merge branch 'cassandra-3.11' into trunk - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (678fdf4 -> 03612b3)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 678fdf4 Merge branch 'cassandra-3.11' into trunk new d6d55d2 changed imports for jackson classes for CompactionLogger new 03612b3 Merge branch 'cassandra-3.11' into trunk The 2 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: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated: changed imports for jackson classes for CompactionLogger
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-3.11 by this push:
new d6d55d2 changed imports for jackson classes for CompactionLogger
d6d55d2 is described below
commit d6d55d24b5025956f514e3aea41285ed9f7b5490
Author: Stefan Miklosovic
AuthorDate: Fri Jun 19 13:32:26 2020 +0200
changed imports for jackson classes for CompactionLogger
Patch by Stefan Miklosovic and brandonwilliams, reviewed by
brandonwilliams for CASSANDRA-15867
---
src/java/org/apache/cassandra/db/compaction/CompactionLogger.java | 8
.../cassandra/db/compaction/DateTieredCompactionStrategy.java | 6 +++---
.../apache/cassandra/db/compaction/LeveledCompactionStrategy.java | 6 +++---
test/unit/org/apache/cassandra/db/marshal/JsonConversionTest.java | 2 +-
4 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/src/java/org/apache/cassandra/db/compaction/CompactionLogger.java
b/src/java/org/apache/cassandra/db/compaction/CompactionLogger.java
index c8def3d..1a4abfe 100644
--- a/src/java/org/apache/cassandra/db/compaction/CompactionLogger.java
+++ b/src/java/org/apache/cassandra/db/compaction/CompactionLogger.java
@@ -37,13 +37,13 @@ import com.google.common.collect.MapMaker;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
+import com.fasterxml.jackson.databind.JsonNode;
+import com.fasterxml.jackson.databind.node.ArrayNode;
+import com.fasterxml.jackson.databind.node.JsonNodeFactory;
+import com.fasterxml.jackson.databind.node.ObjectNode;
import org.apache.cassandra.db.ColumnFamilyStore;
import org.apache.cassandra.io.sstable.format.SSTableReader;
import org.apache.cassandra.utils.NoSpamLogger;
-import org.codehaus.jackson.JsonNode;
-import org.codehaus.jackson.node.ArrayNode;
-import org.codehaus.jackson.node.JsonNodeFactory;
-import org.codehaus.jackson.node.ObjectNode;
public class CompactionLogger
{
diff --git
a/src/java/org/apache/cassandra/db/compaction/DateTieredCompactionStrategy.java
b/src/java/org/apache/cassandra/db/compaction/DateTieredCompactionStrategy.java
index 83d77a9..ed3b172 100644
---
a/src/java/org/apache/cassandra/db/compaction/DateTieredCompactionStrategy.java
+++
b/src/java/org/apache/cassandra/db/compaction/DateTieredCompactionStrategy.java
@@ -33,9 +33,9 @@ import org.apache.cassandra.exceptions.ConfigurationException;
import org.apache.cassandra.io.sstable.format.SSTableReader;
import org.apache.cassandra.schema.CompactionParams;
import org.apache.cassandra.utils.Pair;
-import org.codehaus.jackson.JsonNode;
-import org.codehaus.jackson.node.JsonNodeFactory;
-import org.codehaus.jackson.node.ObjectNode;
+import com.fasterxml.jackson.databind.JsonNode;
+import com.fasterxml.jackson.databind.node.JsonNodeFactory;
+import com.fasterxml.jackson.databind.node.ObjectNode;
import static com.google.common.collect.Iterables.filter;
diff --git
a/src/java/org/apache/cassandra/db/compaction/LeveledCompactionStrategy.java
b/src/java/org/apache/cassandra/db/compaction/LeveledCompactionStrategy.java
index 43c81a4..8c37bb4 100644
--- a/src/java/org/apache/cassandra/db/compaction/LeveledCompactionStrategy.java
+++ b/src/java/org/apache/cassandra/db/compaction/LeveledCompactionStrategy.java
@@ -38,9 +38,9 @@ import org.apache.cassandra.dht.Token;
import org.apache.cassandra.exceptions.ConfigurationException;
import org.apache.cassandra.io.sstable.ISSTableScanner;
import org.apache.cassandra.io.sstable.format.SSTableReader;
-import org.codehaus.jackson.JsonNode;
-import org.codehaus.jackson.node.JsonNodeFactory;
-import org.codehaus.jackson.node.ObjectNode;
+import com.fasterxml.jackson.databind.JsonNode;
+import com.fasterxml.jackson.databind.node.JsonNodeFactory;
+import com.fasterxml.jackson.databind.node.ObjectNode;
public class LeveledCompactionStrategy extends AbstractCompactionStrategy
{
diff --git a/test/unit/org/apache/cassandra/db/marshal/JsonConversionTest.java
b/test/unit/org/apache/cassandra/db/marshal/JsonConversionTest.java
index 0cebd9e..beb37e2 100644
--- a/test/unit/org/apache/cassandra/db/marshal/JsonConversionTest.java
+++ b/test/unit/org/apache/cassandra/db/marshal/JsonConversionTest.java
@@ -24,7 +24,7 @@ import java.nio.ByteBuffer;
import org.apache.cassandra.cql3.QueryOptions;
import org.apache.cassandra.transport.ProtocolVersion;
import org.apache.cassandra.utils.UUIDGen;
-import org.codehaus.jackson.map.ObjectMapper;
+import com.fasterxml.jackson.databind.ObjectMapper;
import org.junit.Test;
public class JsonConversionTest
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15863) Bootstrap resume and TestReplaceAddress fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-15863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142062#comment-17142062 ] Brandon Williams commented on CASSANDRA-15863: -- I merged everything up. > Bootstrap resume and TestReplaceAddress fixes > - > > Key: CASSANDRA-15863 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15863 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission, Test/dtest >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0-alpha > > Time Spent: 10m > Remaining Estimate: 0h > > This has been > [broken|https://ci-cassandra.apache.org/job/Cassandra-trunk/159/testReport/dtest-large.replace_address_test/TestReplaceAddress/test_restart_failed_replace/history/] > for ages -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (576cb2b -> 0c9043d)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 576cb2b update Jackson to 2.9.10 add 1843032 Catch exception on bootstrap resume and init native transport new 0c9043d Merge branch 'cassandra-3.0' into cassandra-3.11 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: - 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-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 0c9043d2eb4af53ea279bbc71fd83c388b93bdd2 Merge: 576cb2b 1843032 Author: Brandon Williams AuthorDate: Mon Jun 22 08:59:21 2020 -0500 Merge branch 'cassandra-3.0' into cassandra-3.11 - 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-3.11' into trunk
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 678fdf4ae92776e4821c34f7c05b20568e6ee0e7 Merge: 674b6cc 0c9043d Author: Brandon Williams AuthorDate: Mon Jun 22 09:00:00 2020 -0500 Merge branch 'cassandra-3.11' into trunk - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (674b6cc -> 678fdf4)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 674b6cc Update defaults for server and client TLS settings add 1843032 Catch exception on bootstrap resume and init native transport new 0c9043d Merge branch 'cassandra-3.0' into cassandra-3.11 new 678fdf4 Merge branch 'cassandra-3.11' into trunk The 2 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: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15863) Bootstrap resume and TestReplaceAddress fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-15863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142020#comment-17142020 ] Berenguer Blasi commented on CASSANDRA-15863: - Probably the GH foxing we found. [~brandon.williams] anything I can help with let me know as I'm not a committer. > Bootstrap resume and TestReplaceAddress fixes > - > > Key: CASSANDRA-15863 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15863 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission, Test/dtest >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0-alpha > > Time Spent: 10m > Remaining Estimate: 0h > > This has been > [broken|https://ci-cassandra.apache.org/job/Cassandra-trunk/159/testReport/dtest-large.replace_address_test/TestReplaceAddress/test_restart_failed_replace/history/] > for ages -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15677) Topology events are not sent to clients if the nodes use the same network interface
[
https://issues.apache.org/jira/browse/CASSANDRA-15677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryn Cooke updated CASSANDRA-15677:
---
Test and Documentation Plan:
Added a new in-jvm-dtests
Updated existing python dTests
was:Added a new in-jvm-dtest
Status: Patch Available (was: In Progress)
> Topology events are not sent to clients if the nodes use the same network
> interface
> ---
>
> Key: CASSANDRA-15677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15677
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Alan Boudreault
>Assignee: Bryn Cooke
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha5
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> *This bug only happens when the cassandra nodes are configured to use a
> single network interface (ip) but different ports. See CASSANDRA-7544.*
> Issue: The topology events aren't sent to clients. The problem is that the
> port is not taken into account when determining if we send it or not:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/Server.java#L624
> To reproduce:
> {code}
> # I think the cassandra-test branch is required to get the -S option
> (USE_SINGLE_INTERFACE)
> ccm create -n4 local40 -v 4.0-alpha2 -S
> {code}
>
> Then run this small python driver script:
> {code}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect()
> while True:
> print(cluster.metadata.all_hosts())
> print([h.is_up for h in cluster.metadata.all_hosts()])
> time.sleep(5)
> {code}
> Then decommission a node:
> {code}
> ccm node2 nodetool disablebinary
> ccm node2 nodetool decommission
> {code}
>
> You should see that the node is never removed from the client cluster
> metadata and the reconnector started.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15863) Bootstrap resume and TestReplaceAddress fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-15863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141986#comment-17141986 ] Andres de la Peña commented on CASSANDRA-15863: --- It seems that 3.0 doesn't merge cleanly into 3.11 after this, there are conflicts in that call to `StorageService#finishJoiningRing` and in `CHANGES.txt`. > Bootstrap resume and TestReplaceAddress fixes > - > > Key: CASSANDRA-15863 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15863 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission, Test/dtest >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0-alpha > > Time Spent: 10m > Remaining Estimate: 0h > > This has been > [broken|https://ci-cassandra.apache.org/job/Cassandra-trunk/159/testReport/dtest-large.replace_address_test/TestReplaceAddress/test_restart_failed_replace/history/] > for ages -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15863) Bootstrap resume and TestReplaceAddress fixes
[
https://issues.apache.org/jira/browse/CASSANDRA-15863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141986#comment-17141986
]
Andres de la Peña edited comment on CASSANDRA-15863 at 6/22/20, 12:25 PM:
--
It seems that 3.0 doesn't merge cleanly into 3.11 after this, there are
conflicts in that call to {{StorageService#finishJoiningRing}} and in
{{CHANGES.txt}}.
was (Author: adelapena):
It seems that 3.0 doesn't merge cleanly into 3.11 after this, there are
conflicts in that call to `StorageService#finishJoiningRing` and in
`CHANGES.txt`.
> Bootstrap resume and TestReplaceAddress fixes
> -
>
> Key: CASSANDRA-15863
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15863
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Bootstrap and Decommission, Test/dtest
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-alpha
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This has been
> [broken|https://ci-cassandra.apache.org/job/Cassandra-trunk/159/testReport/dtest-large.replace_address_test/TestReplaceAddress/test_restart_failed_replace/history/]
> for ages
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15873) Update Netty 4.0.44 -> 4.1.50 (fix security/performance issues)
[ https://issues.apache.org/jira/browse/CASSANDRA-15873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141982#comment-17141982 ] Aleksey Yeschenko edited comment on CASSANDRA-15873 at 6/22/20, 12:20 PM: -- [~mattsplat] running tests, dtests, and perhaps java driver test suite against this would make me comfortable enough, personally. Though I don't have time right now to do it myself. was (Author: iamaleksey): [~mattsplat] running tests, dtests, and perhaps java driver test suite against this would make me comfortable enough, personally. > Update Netty 4.0.44 -> 4.1.50 (fix security/performance issues) > --- > > Key: CASSANDRA-15873 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15873 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Matt Davis >Assignee: Matt Davis >Priority: Normal > Fix For: 3.11.x > > Attachments: dependency-check-report.html > > > See https://issues.apache.org/jira/browse/CASSANDRA-15868 for the same issue > on 4.0 / trunk. Attached is an OWASP dependency report for Netty 4.0.44, > which identifies 3 of the same vulnerabilities as above. > > Additionally, 4.1.50 contains aarch64 native libraries which can improve > performance on ARM processors. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15873) Update Netty 4.0.44 -> 4.1.50 (fix security/performance issues)
[ https://issues.apache.org/jira/browse/CASSANDRA-15873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141982#comment-17141982 ] Aleksey Yeschenko commented on CASSANDRA-15873: --- [~mattsplat] running tests, dtests, and perhaps java driver test suite against this would make me comfortable enough, personally. > Update Netty 4.0.44 -> 4.1.50 (fix security/performance issues) > --- > > Key: CASSANDRA-15873 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15873 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Matt Davis >Assignee: Matt Davis >Priority: Normal > Fix For: 3.11.x > > Attachments: dependency-check-report.html > > > See https://issues.apache.org/jira/browse/CASSANDRA-15868 for the same issue > on 4.0 / trunk. Attached is an OWASP dependency report for Netty 4.0.44, > which identifies 3 of the same vulnerabilities as above. > > Additionally, 4.1.50 contains aarch64 native libraries which can improve > performance on ARM processors. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15880) Memory leak in CompressedChunkReader
[ https://issues.apache.org/jira/browse/CASSANDRA-15880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-15880: Bug Category: Parent values: Degradation(12984)Level 1 values: Resource Management(12995) Complexity: Normal Discovered By: User Report Severity: Normal Status: Open (was: Triage Needed) > Memory leak in CompressedChunkReader > > > Key: CASSANDRA-15880 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15880 > Project: Cassandra > Issue Type: Bug > Components: Feature/Compression >Reporter: Jaroslaw Grabowski >Priority: Normal > > CompressedChunkReader uses java.lang.ThreadLocal to reuse ByteBuffer for > compressed data. ByteBuffers leak due to peculiar ThreadLocal quality. > ThreadLocals are stored in a map, where the key is a weak reference to a > ThreadLocal and the value is the user's object (ByteBuffer in this case). > When a last strong reference to a ThreadLocal is lost, weak reference to > ThreadLocal (key) is removed but the value (ByteBuffer) is kept until cleaned > by ThreadLocal heuristic expunge mechanism. See ThreadLocal's "stale entries" > for details. > When a number of long-living threads is high enough this results in thousands > of ByteBuffers stored as stale entries in ThreadLocals. In a not-so-lucky > scenario we get OutOfMemoryException. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15881) Flaky unit test: SASIIndexTest.testInsertingIncorrectValuesIntoAgeIndex
[
https://issues.apache.org/jira/browse/CASSANDRA-15881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Petrov updated CASSANDRA-15881:
Complexity: Normal
Severity: Normal
Status: Open (was: Triage Needed)
> Flaky unit test: SASIIndexTest.testInsertingIncorrectValuesIntoAgeIndex
> ---
>
> Key: CASSANDRA-15881
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15881
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 3.11.7
>
>
> The unit test {{SASIIndexTest.testInsertingIncorrectValuesIntoAgeIndex}}
> seems to be flaky in 3.11, as it can be seen in
> [cassandra-ci|https://ci-cassandra.apache.org/view/Cassandra%203.11/job/Cassandra-3.11-test/42/testReport/org.apache.cassandra.index.sasi/SASIIndexTest/testInsertingIncorrectValuesIntoAgeIndex/]
> and also locally. Trunk doesn't seem to be affected.
> {{SASIIndexTest.testIndexMemtableSwitching}} is [also
> flaky|https://ci-cassandra.apache.org/view/Cassandra%203.11/job/Cassandra-3.11-test/42/testReport/org.apache.cassandra.index.sasi/SASIIndexTest/testIndexMemtableSwitching/],
> although I haven't been able to reproduce it running it separately, but only
> when running the entire {{SASIIndexTest}}.
> These could have been introduced when merging up CASSANDRA-15778, since they
> failed for their [CircleCI
> run|https://app.circleci.com/pipelines/github/ifesdjeen/cassandra/17/workflows/0442eebe-c764-41c5-ba06-6617bcb9fc5f/jobs/2213],
> and they didn't seem to fail before that, or at least I cannot reproduce
> them locally with the previous commit.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15882) sstablemetadata should show tombstone timestamp not just the local drop time
[
https://issues.apache.org/jira/browse/CASSANDRA-15882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141928#comment-17141928
]
Alex Petrov commented on CASSANDRA-15882:
-
[~thatran] tombstone drop time seems to be consistent with the tombstone
expiration: histogram is built using local delete time. It also seems logical
that a tombstone will hang around in the sstable starting when it shouldn't be
visible anymore + gc grace. I might be missing something, so I'd appreciate if
you elaborate.
> sstablemetadata should show tombstone timestamp not just the local drop time
>
>
> Key: CASSANDRA-15882
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15882
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Thanh
>Priority: Normal
>
> issue/request:
> sstablemetadata should show tombstone timestamp not just the local drop time
>
> I'm not sure what all versions this exists in but the sstablemetadata
> tombstone "drop time" only just shows the local delete time of the
> tombstones. What's more important (what the tombstone expiration time
> depends on) is the tombstone writetime (tombstone timestamp). It's possible
> to, and a surprising number of users have done this, write a tombstone with a
> timetamp in the future (by doing "DELETE...USING TIMESTAMP
> "). When this happens, the tombstone hangs around in
> sstables for a lot longer than users expect because
> {code:java}
> tombstone_expiration_time = gc_grace_seconds + tombstone_timestamp{code}
> NOT
> {code:java}
> tombstone_expiration_time = gc_grace_seconds +
> tombstone_local_delete_time{code}
> and the sstablemetadata output doesn't help here because it only shows the
> local delete time, not the actual tombstone timestamp that's used to
> calculate tombstone expiration time.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15814) order by descending on frozen list not working
[
https://issues.apache.org/jira/browse/CASSANDRA-15814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141925#comment-17141925
]
Andres de la Peña commented on CASSANDRA-15814:
---
It seems to affect all versions since 2.1
> order by descending on frozen list not working
> --
>
> Key: CASSANDRA-15814
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15814
> Project: Cassandra
> Issue Type: Bug
>Reporter: Felipe Perez
>Assignee: Andres de la Peña
>Priority: Normal
>
> By creating a table like the following:
> {code:java}
> CREATE TABLE IF NOT EXISTS software (
> name ascii,
> version frozen>,
> data ascii,
> PRIMARY KEY(name,version)
> )
> {code}
> It works and version is ordered in an ascending order. But when trying to
> order in descending order:
> {code:java}
> CREATE TABLE IF NOT EXISTS software (
> name ascii,
> version frozen>,
> data ascii,
> PRIMARY KEY(name,version)
> ) WITH CLUSTERING ORDER BY (version DESC);
> {code}
> The table is created normally, but when trying to insert a row:
> {code:java}
> insert into software(name, version) values ('t1', [2,10,30,40,50]);
> {code}
> Cassandra throws an error:
> {code:java}
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Invalid
> list literal for version of type frozen>"
> {code}
> The goal here is that I would like to get the last version of a software.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15677) Topology events are not sent to clients if the nodes use the same network interface
[
https://issues.apache.org/jira/browse/CASSANDRA-15677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141912#comment-17141912
]
Bryn Cooke commented on CASSANDRA-15677:
I've created a PR for the dTests
https://github.com/apache/cassandra-dtest/pull/79
> Topology events are not sent to clients if the nodes use the same network
> interface
> ---
>
> Key: CASSANDRA-15677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15677
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Alan Boudreault
>Assignee: Bryn Cooke
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha5
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> *This bug only happens when the cassandra nodes are configured to use a
> single network interface (ip) but different ports. See CASSANDRA-7544.*
> Issue: The topology events aren't sent to clients. The problem is that the
> port is not taken into account when determining if we send it or not:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/Server.java#L624
> To reproduce:
> {code}
> # I think the cassandra-test branch is required to get the -S option
> (USE_SINGLE_INTERFACE)
> ccm create -n4 local40 -v 4.0-alpha2 -S
> {code}
>
> Then run this small python driver script:
> {code}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect()
> while True:
> print(cluster.metadata.all_hosts())
> print([h.is_up for h in cluster.metadata.all_hosts()])
> time.sleep(5)
> {code}
> Then decommission a node:
> {code}
> ccm node2 nodetool disablebinary
> ccm node2 nodetool decommission
> {code}
>
> You should see that the node is never removed from the client cluster
> metadata and the reconnector started.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15885) replication_test.TestSnitchConfigurationUpdate.test_rf_expand_gossiping_property_file_snitch_multi_dc failure
[ https://issues.apache.org/jira/browse/CASSANDRA-15885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141904#comment-17141904 ] Andres de la Peña commented on CASSANDRA-15885: --- Dtests running: |[3.0|https://ci-cassandra.apache.org/view/all/job/Cassandra-devbranch-dtest/179/]|[3.11|https://ci-cassandra.apache.org/view/all/job/Cassandra-devbranch-dtest/180/]|[trunk|https://ci-cassandra.apache.org/view/all/job/Cassandra-devbranch-dtest/181/]| > replication_test.TestSnitchConfigurationUpdate.test_rf_expand_gossiping_property_file_snitch_multi_dc > failure > - > > Key: CASSANDRA-15885 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15885 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 10m > Remaining Estimate: 0h > > replication_test.TestSnitchConfigurationUpdate.test_rf_expand_gossiping_property_file_snitch_multi_dc > has been failing for a > [while|https://ci-cassandra.apache.org/job/Cassandra-trunk/176/testReport/dtest-large.replication_test/TestSnitchConfigurationUpdate/test_rf_expand_gossiping_property_file_snitch_multi_dc/history/]. > Also fails locally -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15885) replication_test.TestSnitchConfigurationUpdate.test_rf_expand_gossiping_property_file_snitch_multi_dc failure
[ https://issues.apache.org/jira/browse/CASSANDRA-15885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141881#comment-17141881 ] Berenguer Blasi commented on CASSANDRA-15885: - Failure is on checking an unsorted list vs a sorted list. Contents were right but the order mismatched. > replication_test.TestSnitchConfigurationUpdate.test_rf_expand_gossiping_property_file_snitch_multi_dc > failure > - > > Key: CASSANDRA-15885 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15885 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 10m > Remaining Estimate: 0h > > replication_test.TestSnitchConfigurationUpdate.test_rf_expand_gossiping_property_file_snitch_multi_dc > has been failing for a > [while|https://ci-cassandra.apache.org/job/Cassandra-trunk/176/testReport/dtest-large.replication_test/TestSnitchConfigurationUpdate/test_rf_expand_gossiping_property_file_snitch_multi_dc/history/]. > Also fails locally -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15885) replication_test.TestSnitchConfigurationUpdate.test_rf_expand_gossiping_property_file_snitch_multi_dc failure
[ https://issues.apache.org/jira/browse/CASSANDRA-15885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-15885: Test and Documentation Plan: See PR Status: Patch Available (was: In Progress) > replication_test.TestSnitchConfigurationUpdate.test_rf_expand_gossiping_property_file_snitch_multi_dc > failure > - > > Key: CASSANDRA-15885 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15885 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 10m > Remaining Estimate: 0h > > replication_test.TestSnitchConfigurationUpdate.test_rf_expand_gossiping_property_file_snitch_multi_dc > has been failing for a > [while|https://ci-cassandra.apache.org/job/Cassandra-trunk/176/testReport/dtest-large.replication_test/TestSnitchConfigurationUpdate/test_rf_expand_gossiping_property_file_snitch_multi_dc/history/]. > Also fails locally -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15887) Document how to run Cassandra on Windows
[ https://issues.apache.org/jira/browse/CASSANDRA-15887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-15887: Change Category: Operability Complexity: Normal Priority: Low (was: Normal) Status: Open (was: Triage Needed) > Document how to run Cassandra on Windows > > > Key: CASSANDRA-15887 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15887 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: João Reis >Assignee: Berenguer Blasi >Priority: Low > > The "Getting Started" section on the website only has instructions about > installing Cassandra on Linux. > It would help us drive Cassandra adoption if we had instructions for > developers that want to run Cassandra on their Windows development > environment. > We should include instructions on how to use the existing powershell scripts > to run Cassandra on native Windows but the docs should recommend users to > prefer using WSL2/Docker before attempting to run it natively in my opinion. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15811) Improve DROP COMPACT STORAGE
[
https://issues.apache.org/jira/browse/CASSANDRA-15811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-15811:
Bug Category: Parent values: Correctness(12982)Level 1 values: Transient
Incorrect Response(12987)
Complexity: Normal
Component/s: Cluster/Schema
Discovered By: Adhoc Test
Fix Version/s: 3.11.x
3.0.x
Severity: Normal
Status: Open (was: Triage Needed)
> Improve DROP COMPACT STORAGE
>
>
> Key: CASSANDRA-15811
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15811
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Alex Petrov
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> DROP COMPACT STORAGE was introduced in CASSANDRA-10857 as one of the steps to
> deprecate Thrift. However, current semantics of dropping compact storage
> flags from tables reveal several columns that are usually empty (colum1 and
> value in non-dense case, value for dense columns, and a column with an empty
> name for super column families). Showing these columns can confuse
> application developers, especially ones that have never used thrift and/or
> made writes that assumed presence of those fields, and used compact storage
> in 3.x because is has “compact” in the name.
> There’s not much we can do in a super column family case, especially
> considering there’s no way to create a supercolumn family using CQL, but we
> can improve dense and non-dense cases. We can scan stables and make sure
> there are no signs of thrift writes in them, and if all sstables conform to
> this rule, we can not only drop the flag, but also drop columns that are
> supposed to be hidden. However, this is both not very user-friendly, and is
> probably not worth development effort.
> An alternative to scanning is to add {{FORCE DROP COMPACT}} syntax (or
> something similar) that would just drop columns unconditionally. It is likely
> that people who were using compact storage with thrift know they were doing
> that, so they'll usually use "regular" {{DROP COMPACT}}, withouot force, that
> will simply reveal the columns as it does right now.
> Since for fixing CASSANDRA-15778, and to allow EmptyType column to actually
> have data[*] we had to remove empty type validation, properly handling
> compact storage starts making more sense, but we’ll solve it through not
> having columns, hence not caring about values instead, or keeping values
> _and_ data, not requiring validation in this case. EmptyType field will have
> to be handled differently though.
> [*] as it is possible to end up with sstables upgraded from 2.x or written in
> 3.x before CASSANDRA-15373, which means not every 2.x upgraded or 3.x cluster
> is guaranteed to have empty values in this column, and this behaviour, even
> if undesired, might be used by people.
> Open question is: CASSANDRA-15373 adds validation to EmptyType that disallows
> any non-empty value to be written to it, but we already allow creating table
> via CQL, and still write data into it with thrift. It seems to have been
> unintended, but it might have become a feature people rely on. If we simply
> back port 15373 to 2.2 and 2.1, we’ll change and break behaviour. Given
> no-one complained in 3.0 and 3.11, this assumption is unlikely though.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15811) Improve DROP COMPACT STORAGE
[
https://issues.apache.org/jira/browse/CASSANDRA-15811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson reassigned CASSANDRA-15811:
---
Assignee: Marcus Eriksson
> Improve DROP COMPACT STORAGE
>
>
> Key: CASSANDRA-15811
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15811
> Project: Cassandra
> Issue Type: Bug
>Reporter: Alex Petrov
>Assignee: Marcus Eriksson
>Priority: Normal
>
> DROP COMPACT STORAGE was introduced in CASSANDRA-10857 as one of the steps to
> deprecate Thrift. However, current semantics of dropping compact storage
> flags from tables reveal several columns that are usually empty (colum1 and
> value in non-dense case, value for dense columns, and a column with an empty
> name for super column families). Showing these columns can confuse
> application developers, especially ones that have never used thrift and/or
> made writes that assumed presence of those fields, and used compact storage
> in 3.x because is has “compact” in the name.
> There’s not much we can do in a super column family case, especially
> considering there’s no way to create a supercolumn family using CQL, but we
> can improve dense and non-dense cases. We can scan stables and make sure
> there are no signs of thrift writes in them, and if all sstables conform to
> this rule, we can not only drop the flag, but also drop columns that are
> supposed to be hidden. However, this is both not very user-friendly, and is
> probably not worth development effort.
> An alternative to scanning is to add {{FORCE DROP COMPACT}} syntax (or
> something similar) that would just drop columns unconditionally. It is likely
> that people who were using compact storage with thrift know they were doing
> that, so they'll usually use "regular" {{DROP COMPACT}}, withouot force, that
> will simply reveal the columns as it does right now.
> Since for fixing CASSANDRA-15778, and to allow EmptyType column to actually
> have data[*] we had to remove empty type validation, properly handling
> compact storage starts making more sense, but we’ll solve it through not
> having columns, hence not caring about values instead, or keeping values
> _and_ data, not requiring validation in this case. EmptyType field will have
> to be handled differently though.
> [*] as it is possible to end up with sstables upgraded from 2.x or written in
> 3.x before CASSANDRA-15373, which means not every 2.x upgraded or 3.x cluster
> is guaranteed to have empty values in this column, and this behaviour, even
> if undesired, might be used by people.
> Open question is: CASSANDRA-15373 adds validation to EmptyType that disallows
> any non-empty value to be written to it, but we already allow creating table
> via CQL, and still write data into it with thrift. It seems to have been
> unintended, but it might have become a feature people rely on. If we simply
> back port 15373 to 2.2 and 2.1, we’ll change and break behaviour. Given
> no-one complained in 3.0 and 3.11, this assumption is unlikely though.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
