[jira] [Commented] (CASSANDRA-15366) Backup and Restore
[ https://issues.apache.org/jira/browse/CASSANDRA-15366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16957485#comment-16957485 ] maxwellguo commented on CASSANDRA-15366: two nodes are with the same dc name "datacenter1"? and you mean id : 1 2 are missing ， right ? all your operations are from cqlsh ? > Backup and Restore > -- > > Key: CASSANDRA-15366 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15366 > Project: Cassandra > Issue Type: Bug >Reporter: Kamal >Priority: Normal > > Hi Team, > We are testing the backup and restore of CASSANDRA in a cluster and found > that while restoring the backup from the second node to the new node (or > previous node) then complete data is not restored. > Please enlight us on it. > > Regards, > Kamal -- 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-15295) Running into deadlock when do CommitLog initialization
[ https://issues.apache.org/jira/browse/CASSANDRA-15295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15295: -- Attachment: image.png > Running into deadlock when do CommitLog initialization > -- > > Key: CASSANDRA-15295 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15295 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Zephyr Guo >Assignee: Zephyr Guo >Priority: Normal > Attachments: image.png, jstack.log, pstack.log, screenshot-1.png, > screenshot-2.png, screenshot-3.png > > > Recently, I found a cassandra(3.11.4) node stuck in STARTING status for a > long time. > I used jstack to saw what happened. The main thread stuck in > *AbstractCommitLogSegmentManager.awaitAvailableSegment* > !screenshot-1.png! > The strange thing is COMMIT-LOG-ALLOCATOR thread state was runnable but it > was not actually running. > !screenshot-2.png! > And then I used pstack to troubleshoot. I found COMMIT-LOG-ALLOCATOR block on > java class initialization. > !screenshot-3.png! > This is a deadlock obviously. CommitLog waits for a CommitLogSegment when > initializing. In this moment, the CommitLog class is not initialized and the > main thread holds the class lock. After that, COMMIT-LOG-ALLOCATOR creates a > CommitLogSegment with exception and call *CommitLog.handleCommitError*(static > method). COMMIT-LOG-ALLOCATOR will block on this line because CommitLog > class is still initializing. > > -- 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-15353) Documentation Preview - Cassandra 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-15353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] DeepakVohra reassigned CASSANDRA-15353: --- Assignee: Dinesh Joshi (was: DeepakVohra) > Documentation Preview - Cassandra 4.0 > - > > Key: CASSANDRA-15353 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15353 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: DeepakVohra >Assignee: Dinesh Joshi >Priority: Normal > > Please review, and add comments to, some of the documentation preview for > Apache Cassandra 4.0. > New Features > --- > *Audit Logging* > https://docs.google.com/document/d/1WsQYjDQ9UZ7f8P3eAATht6Vz5oNibTmhsH8cu9viLTk/edit?usp=sharing > *Full Query Logging* > https://docs.google.com/document/d/1ZNfs68ZNJXqDc_2XGM6W-tpvnejUfSh8HmkbG8u35Es/edit?usp=sharing > *Support for Java 11* > https://docs.google.com/document/d/1v7ffccqk_5Son4iwfuwZae8YUam41quewKi_6Z_PQGw/edit?usp=sharing > *Transient Replication and Cheap Quorums* > https://docs.google.com/document/d/1GyJVCmwoMb7OO9NkbGdk26YxHi9fWtfzuTBTiIEpli8/edit?usp=sharing > *Virtual Tables* > https://docs.google.com/document/d/1U8qAzQnA2HcoIzTg5IXFUySUZXD1tEIl2bam-514we8/edit?usp=sharing > Improvements > > *Improved Streaming* > https://docs.google.com/document/d/1zd6AuHBgC82v598cuDtVIkxJVDV9c0A2rrMEVFHyB4Y/edit?usp=sharing > *Improved Internode Messaging* > https://docs.google.com/document/d/1ub2DBHE7hNEKe4tuCOpdbCZ7qGqCdMAYvSTC-YamuMA/edit?usp=sharing -- 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-15353) Documentation Preview - Cassandra 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-15353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] DeepakVohra reassigned CASSANDRA-15353: --- Assignee: DeepakVohra > Documentation Preview - Cassandra 4.0 > - > > Key: CASSANDRA-15353 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15353 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: DeepakVohra >Assignee: DeepakVohra >Priority: Normal > > Please review, and add comments to, some of the documentation preview for > Apache Cassandra 4.0. > New Features > --- > *Audit Logging* > https://docs.google.com/document/d/1WsQYjDQ9UZ7f8P3eAATht6Vz5oNibTmhsH8cu9viLTk/edit?usp=sharing > *Full Query Logging* > https://docs.google.com/document/d/1ZNfs68ZNJXqDc_2XGM6W-tpvnejUfSh8HmkbG8u35Es/edit?usp=sharing > *Support for Java 11* > https://docs.google.com/document/d/1v7ffccqk_5Son4iwfuwZae8YUam41quewKi_6Z_PQGw/edit?usp=sharing > *Transient Replication and Cheap Quorums* > https://docs.google.com/document/d/1GyJVCmwoMb7OO9NkbGdk26YxHi9fWtfzuTBTiIEpli8/edit?usp=sharing > *Virtual Tables* > https://docs.google.com/document/d/1U8qAzQnA2HcoIzTg5IXFUySUZXD1tEIl2bam-514we8/edit?usp=sharing > Improvements > > *Improved Streaming* > https://docs.google.com/document/d/1zd6AuHBgC82v598cuDtVIkxJVDV9c0A2rrMEVFHyB4Y/edit?usp=sharing > *Improved Internode Messaging* > https://docs.google.com/document/d/1ub2DBHE7hNEKe4tuCOpdbCZ7qGqCdMAYvSTC-YamuMA/edit?usp=sharing -- 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-15371) Incorrect messaging service version breaks in-JVM upgrade tests on trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-15371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRA-15371:
-
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Discovered By: User Report
Severity: Low
Status: Open (was: Triage Needed)
> Incorrect messaging service version breaks in-JVM upgrade tests on trunk
>
>
> Key: CASSANDRA-15371
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15371
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
>
> The in-JVM upgrade tests on trunk currently fail because the messaging
> version for internode messaging is selected as
> {{MessagingService.current_version}},
> a regression from the implementation in CASSANDRA-15078.
--
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-15371) Incorrect messaging service version breaks in-JVM upgrade tests on trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-15371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRA-15371:
-
Test and Documentation Plan: This is a fix for a test failure
Status: Patch Available (was: Open)
> Incorrect messaging service version breaks in-JVM upgrade tests on trunk
>
>
> Key: CASSANDRA-15371
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15371
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
>
> The in-JVM upgrade tests on trunk currently fail because the messaging
> version for internode messaging is selected as
> {{MessagingService.current_version}},
> a regression from the implementation in CASSANDRA-15078.
--
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-15371) Incorrect messaging service version breaks in-JVM upgrade tests on trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-15371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRA-15371:
-
Reviewers: Dinesh Joshi
> Incorrect messaging service version breaks in-JVM upgrade tests on trunk
>
>
> Key: CASSANDRA-15371
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15371
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
>
> The in-JVM upgrade tests on trunk currently fail because the messaging
> version for internode messaging is selected as
> {{MessagingService.current_version}},
> a regression from the implementation in CASSANDRA-15078.
--
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-15332) When repair is running with tracing, if a CorruptSSTableException is thrown while building Merkle Trees the DiskFailurePolicy does not get applied
[ https://issues.apache.org/jira/browse/CASSANDRA-15332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15332: -- Component/s: Observability/Tracing > When repair is running with tracing, if a CorruptSSTableException is thrown > while building Merkle Trees the DiskFailurePolicy does not get applied > -- > > Key: CASSANDRA-15332 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15332 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair, Observability/Tracing >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: 4.0 > > Time Spent: 10m > Remaining Estimate: 0h > > When a repair is in the validation phase and is building MerkleTrees, if a > corrupt SSTable exception is thrown the disk failure policy does not get > applied -- 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-15371) Incorrect messaging service version breaks in-JVM upgrade tests on trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-15371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16957234#comment-16957234
]
Jon Meredith commented on CASSANDRA-15371:
--
This fixes upgrade test for me when run on 3.0, 3.11 and trunk.
* [2.2
changes|https://github.com/jonmeredith/cassandra/tree/CASSANDRA-15371-2.2]
[CircleCI|https://circleci.com/workflow-run/d7a1f47d-a411-4245-9924-422e8ac6f8c7]
* [3.0
changes|https://github.com/jonmeredith/cassandra/tree/CASSANDRA-15371-3.0]
[CircleCI|https://circleci.com/workflow-run/54d2ae1f-3599-426b-b0ab-6ef54edbddab]
* [3.11
changes|https://github.com/jonmeredith/cassandra/tree/CASSANDRA-15371-3.11]
[CircleCI|https://circleci.com/workflow-run/25df7f33-58a6-40cd-b64c-235515b8ad2d]
* [trunk
changes|https://github.com/jonmeredith/cassandra/tree/CASSANDRA-15371-trunk]
[CircleCI|https://circleci.com/workflow-run/577036b9-772b-4f06-8db1-3af8e0c0b049]
Currently the upgrade tests need to be run manually.
* Checkout 2.2, 3.0, 3.11 and trunk and run `ant dtest-jar` to create the
dtest jars in the build directory.
* Copy/symlink all previous version dtest jars into the build directory ({{cd
build; ln -s ../../path_to_3.11>/build/dtest-3.11.5.jar}})
* Run the upgrade test (either by hand, or from IntelliJ)
{{ant test-jvm-dtest-some
-Dtest.name=org.apache.cassandra.distributed.upgrade.UpgradeTest
-Dtest.methods=upgradeTest}}
> Incorrect messaging service version breaks in-JVM upgrade tests on trunk
>
>
> Key: CASSANDRA-15371
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15371
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
>
> The in-JVM upgrade tests on trunk currently fail because the messaging
> version for internode messaging is selected as
> {{MessagingService.current_version}},
> a regression from the implementation in CASSANDRA-15078.
--
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-15360) add mick's gpg key to project's KEYS file
[
https://issues.apache.org/jira/browse/CASSANDRA-15360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16957225#comment-16957225
]
Jon Haddad edited comment on CASSANDRA-15360 at 10/22/19 4:57 PM:
--
I've verified the existing keys weren't touched, and the fingerprint matches.
{{$ gpg --import KEYS}}
{{gpg: key F8358FA2F2833C93: 421 signatures not checked due to missing keys}}
{{gpg: key F8358FA2F2833C93: public key "Eric Evans "
imported}}
{{gpg: key F8358FA2F2833C93: 443 signatures not checked due to missing keys}}
{{gpg: key F8358FA2F2833C93: "Eric Evans " 22 new
signatures}}
{{gpg: key F758CE318D77295D: 93 signatures not checked due to missing keys}}
{{gpg: key F758CE318D77295D: public key "Eric Evans "
imported}}
{{gpg: key 4BD736A82B5C1B00: public key "Sylvain Lebresne (pcmanus)
" imported}}
{{gpg: key 749D6EEC0353B12C: public key "T Jake Luciani "
imported}}
{{gpg: key A278B781FE4B2BDA: 28 signatures not checked due to missing keys}}
{{gpg: key A278B781FE4B2BDA: public key "Michael Shuler
" imported}}
{{gpg: key FDD3B769B21C125C: 3 signatures not checked due to missing keys}}
{{gpg: key FDD3B769B21C125C: public key "Mick Semb Wever
" imported}}
{{gpg: key FDD3B769B21C125C: "Mick Semb Wever " 1 new
signature}}
{{gpg: Total number processed: 8}}
{{gpg: imported: 6}}
{{gpg: new signatures: 23}}
{{gpg: marginals needed: 3 completes needed: 1 trust model: pgp}}
{{gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u}}
{{$ gpg --list-keys}}
\{{ /Users/jhaddad/.gnupg/pubring.kb}}{{... # omitted for brevity}}{{pub
dsa3072 2010-04-26 [SC]}}
\{{ ABCD3108336F7CC6567E769FFDD3B769B21C125C}}
\{{ uid [ unknown] Mick Semb Wever }}
\{{ uid [ unknown] Mick Semb Wever }}
{{ uid [ unknown] [jpeg image of size 4671]}}
\{{ uid [ unknown] Mick Semb Wever }}
\{{ sub elg4096 2010-04-26 }}
+1, go ahead and merge
was (Author: rustyrazorblade):
I've verified the existing keys weren't touched and
{{$ gpg --import KEYS}}
{{gpg: key F8358FA2F2833C93: 421 signatures not checked due to missing keys}}
{{gpg: key F8358FA2F2833C93: public key "Eric Evans "
imported}}
{{gpg: key F8358FA2F2833C93: 443 signatures not checked due to missing keys}}
{{gpg: key F8358FA2F2833C93: "Eric Evans " 22 new
signatures}}
{{gpg: key F758CE318D77295D: 93 signatures not checked due to missing keys}}
{{gpg: key F758CE318D77295D: public key "Eric Evans "
imported}}
{{gpg: key 4BD736A82B5C1B00: public key "Sylvain Lebresne (pcmanus)
" imported}}
{{gpg: key 749D6EEC0353B12C: public key "T Jake Luciani "
imported}}
{{gpg: key A278B781FE4B2BDA: 28 signatures not checked due to missing keys}}
{{gpg: key A278B781FE4B2BDA: public key "Michael Shuler
" imported}}
{{gpg: key FDD3B769B21C125C: 3 signatures not checked due to missing keys}}
{{gpg: key FDD3B769B21C125C: public key "Mick Semb Wever
" imported}}
{{gpg: key FDD3B769B21C125C: "Mick Semb Wever " 1 new
signature}}
{{gpg: Total number processed: 8}}
{{gpg: imported: 6}}
{{gpg: new signatures: 23}}
{{gpg: marginals needed: 3 completes needed: 1 trust model: pgp}}
{{gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u}}
{{$ gpg --list-keys}}
{{ /Users/jhaddad/.gnupg/pubring.kb}}{{... # omitted for brevity}}{{pub dsa3072
2010-04-26 [SC]}}
{{ ABCD3108336F7CC6567E769FFDD3B769B21C125C}}
{{ uid [ unknown] Mick Semb Wever }}
{{ uid [ unknown] Mick Semb Wever }}
{{ uid [ unknown] [jpeg image of size 4671]}}
{{ uid [ unknown] Mick Semb Wever }}
{{ sub elg4096 2010-04-26 }}
+1, go ahead and merge
> add mick's gpg key to project's KEYS file
> -
>
> Key: CASSANDRA-15360
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15360
> Project: Cassandra
> Issue Type: Task
> Components: Packaging
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Attachments: 15360.patch
>
>
> Currently only four individual's have their key in the project's KEYS file,
> and only one of these people are taking on the release manager role.
> The patch adds my gpg public key to the project's KEYS file found at
> https://dist.apache.org/repos/dist/release/cassandra/KEYS
> My gpg public key here has the fingerprint
> ABCD 3108 336F 7CC6 567E 769F FDD3 B769 B21C 125C
> References:
> - https://www.apache.org/dev/release-signing#keys-policy
> - http://www.apache.org/legal/release-policy.html
> - [dev ML thread "Improving our frequency of (patch) releases, and letting
> committers make
> releases"|https://lists.apache.org/thread.html/660ed8c73e7b79afa610f3e45f37914ef43a4358a85a99c8b4b0288a@]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail:
[jira] [Comment Edited] (CASSANDRA-15360) add mick's gpg key to project's KEYS file
[
https://issues.apache.org/jira/browse/CASSANDRA-15360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16957225#comment-16957225
]
Jon Haddad edited comment on CASSANDRA-15360 at 10/22/19 4:57 PM:
--
I've verified the existing keys weren't touched and
{{$ gpg --import KEYS}}
{{gpg: key F8358FA2F2833C93: 421 signatures not checked due to missing keys}}
{{gpg: key F8358FA2F2833C93: public key "Eric Evans "
imported}}
{{gpg: key F8358FA2F2833C93: 443 signatures not checked due to missing keys}}
{{gpg: key F8358FA2F2833C93: "Eric Evans " 22 new
signatures}}
{{gpg: key F758CE318D77295D: 93 signatures not checked due to missing keys}}
{{gpg: key F758CE318D77295D: public key "Eric Evans "
imported}}
{{gpg: key 4BD736A82B5C1B00: public key "Sylvain Lebresne (pcmanus)
" imported}}
{{gpg: key 749D6EEC0353B12C: public key "T Jake Luciani "
imported}}
{{gpg: key A278B781FE4B2BDA: 28 signatures not checked due to missing keys}}
{{gpg: key A278B781FE4B2BDA: public key "Michael Shuler
" imported}}
{{gpg: key FDD3B769B21C125C: 3 signatures not checked due to missing keys}}
{{gpg: key FDD3B769B21C125C: public key "Mick Semb Wever
" imported}}
{{gpg: key FDD3B769B21C125C: "Mick Semb Wever " 1 new
signature}}
{{gpg: Total number processed: 8}}
{{gpg: imported: 6}}
{{gpg: new signatures: 23}}
{{gpg: marginals needed: 3 completes needed: 1 trust model: pgp}}
{{gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u}}
{{$ gpg --list-keys}}
{{ /Users/jhaddad/.gnupg/pubring.kb}}{{... # omitted for brevity}}{{pub dsa3072
2010-04-26 [SC]}}
{{ ABCD3108336F7CC6567E769FFDD3B769B21C125C}}
{{ uid [ unknown] Mick Semb Wever }}
{{ uid [ unknown] Mick Semb Wever }}
{{ uid [ unknown] [jpeg image of size 4671]}}
{{ uid [ unknown] Mick Semb Wever }}
{{ sub elg4096 2010-04-26 }}
+1, go ahead and merge
was (Author: rustyrazorblade):
I've verified the existing keys weren't touched and
{{$ gpg --import KEYS}}
{{gpg: key F8358FA2F2833C93: 421 signatures not checked due to missing keys}}
{{gpg: key F8358FA2F2833C93: public key "Eric Evans "
imported}}
{{gpg: key F8358FA2F2833C93: 443 signatures not checked due to missing keys}}
{{gpg: key F8358FA2F2833C93: "Eric Evans " 22 new
signatures}}
{{gpg: key F758CE318D77295D: 93 signatures not checked due to missing keys}}
{{gpg: key F758CE318D77295D: public key "Eric Evans "
imported}}
{{gpg: key 4BD736A82B5C1B00: public key "Sylvain Lebresne (pcmanus)
" imported}}
{{gpg: key 749D6EEC0353B12C: public key "T Jake Luciani "
imported}}
{{gpg: key A278B781FE4B2BDA: 28 signatures not checked due to missing keys}}
{{gpg: key A278B781FE4B2BDA: public key "Michael Shuler
" imported}}
{{gpg: key FDD3B769B21C125C: 3 signatures not checked due to missing keys}}
{{gpg: key FDD3B769B21C125C: public key "Mick Semb Wever
" imported}}
{{gpg: key FDD3B769B21C125C: "Mick Semb Wever " 1 new
signature}}
{{gpg: Total number processed: 8}}
{{gpg: imported: 6}}
{{gpg: new signatures: 23}}
{{gpg: marginals needed: 3 completes needed: 1 trust model: pgp}}
{{gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u}}
gpg --list-keys
/Users/jhaddad/.gnupg/pubring.kbx
# ommitted for brevity
pub dsa3072 2010-04-26 [SC]
ABCD3108336F7CC6567E769FFDD3B769B21C125C
uid [ unknown] Mick Semb Wever
uid [ unknown] Mick Semb Wever
uid [ unknown] [jpeg image of size 4671]
uid [ unknown] Mick Semb Wever
sub elg4096 2010-04-26
+1
> add mick's gpg key to project's KEYS file
> -
>
> Key: CASSANDRA-15360
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15360
> Project: Cassandra
> Issue Type: Task
> Components: Packaging
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Attachments: 15360.patch
>
>
> Currently only four individual's have their key in the project's KEYS file,
> and only one of these people are taking on the release manager role.
> The patch adds my gpg public key to the project's KEYS file found at
> https://dist.apache.org/repos/dist/release/cassandra/KEYS
> My gpg public key here has the fingerprint
> ABCD 3108 336F 7CC6 567E 769F FDD3 B769 B21C 125C
> References:
> - https://www.apache.org/dev/release-signing#keys-policy
> - http://www.apache.org/legal/release-policy.html
> - [dev ML thread "Improving our frequency of (patch) releases, and letting
> committers make
> releases"|https://lists.apache.org/thread.html/660ed8c73e7b79afa610f3e45f37914ef43a4358a85a99c8b4b0288a@]
--
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-15360) add mick's gpg key to project's KEYS file
[
https://issues.apache.org/jira/browse/CASSANDRA-15360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16957225#comment-16957225
]
Jon Haddad edited comment on CASSANDRA-15360 at 10/22/19 4:57 PM:
--
I've verified the existing keys weren't touched and
{{$ gpg --import KEYS}}
{{gpg: key F8358FA2F2833C93: 421 signatures not checked due to missing keys}}
{{gpg: key F8358FA2F2833C93: public key "Eric Evans "
imported}}
{{gpg: key F8358FA2F2833C93: 443 signatures not checked due to missing keys}}
{{gpg: key F8358FA2F2833C93: "Eric Evans " 22 new
signatures}}
{{gpg: key F758CE318D77295D: 93 signatures not checked due to missing keys}}
{{gpg: key F758CE318D77295D: public key "Eric Evans "
imported}}
{{gpg: key 4BD736A82B5C1B00: public key "Sylvain Lebresne (pcmanus)
" imported}}
{{gpg: key 749D6EEC0353B12C: public key "T Jake Luciani "
imported}}
{{gpg: key A278B781FE4B2BDA: 28 signatures not checked due to missing keys}}
{{gpg: key A278B781FE4B2BDA: public key "Michael Shuler
" imported}}
{{gpg: key FDD3B769B21C125C: 3 signatures not checked due to missing keys}}
{{gpg: key FDD3B769B21C125C: public key "Mick Semb Wever
" imported}}
{{gpg: key FDD3B769B21C125C: "Mick Semb Wever " 1 new
signature}}
{{gpg: Total number processed: 8}}
{{gpg: imported: 6}}
{{gpg: new signatures: 23}}
{{gpg: marginals needed: 3 completes needed: 1 trust model: pgp}}
{{gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u}}
gpg --list-keys
/Users/jhaddad/.gnupg/pubring.kbx
# ommitted for brevity
pub dsa3072 2010-04-26 [SC]
ABCD3108336F7CC6567E769FFDD3B769B21C125C
uid [ unknown] Mick Semb Wever
uid [ unknown] Mick Semb Wever
uid [ unknown] [jpeg image of size 4671]
uid [ unknown] Mick Semb Wever
sub elg4096 2010-04-26
+1
was (Author: rustyrazorblade):
I've verified the existing keys weren't touched and
{{$ gpg --import KEYS}}
{{gpg: key F8358FA2F2833C93: 421 signatures not checked due to missing keys}}
{{gpg: key F8358FA2F2833C93: public key "Eric Evans "
imported}}
{{gpg: key F8358FA2F2833C93: 443 signatures not checked due to missing keys}}
{{gpg: key F8358FA2F2833C93: "Eric Evans " 22 new
signatures}}
{{gpg: key F758CE318D77295D: 93 signatures not checked due to missing keys}}
{{gpg: key F758CE318D77295D: public key "Eric Evans "
imported}}
{{gpg: key 4BD736A82B5C1B00: public key "Sylvain Lebresne (pcmanus)
" imported}}
{{gpg: key 749D6EEC0353B12C: public key "T Jake Luciani "
imported}}
{{gpg: key A278B781FE4B2BDA: 28 signatures not checked due to missing keys}}
{{gpg: key A278B781FE4B2BDA: public key "Michael Shuler
" imported}}
{{gpg: key FDD3B769B21C125C: 3 signatures not checked due to missing keys}}
{{gpg: key FDD3B769B21C125C: public key "Mick Semb Wever "
imported}}
{{gpg: key FDD3B769B21C125C: "Mick Semb Wever " 1 new
signature}}
{{gpg: Total number processed: 8}}
{{gpg: imported: 6}}
{{gpg: new signatures: 23}}
{{gpg: marginals needed: 3 completes needed: 1 trust model: pgp}}
{{gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u}}
gpg --list-keys
/Users/jhaddad/.gnupg/pubring.kbx
# ommitted for brevity
pub dsa3072 2010-04-26 [SC]
ABCD3108336F7CC6567E769FFDD3B769B21C125C
uid [ unknown] Mick Semb Wever
uid [ unknown] Mick Semb Wever
uid [ unknown] [jpeg image of size 4671]
uid [ unknown] Mick Semb Wever
sub elg4096 2010-04-26 [E]
> add mick's gpg key to project's KEYS file
> -
>
> Key: CASSANDRA-15360
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15360
> Project: Cassandra
> Issue Type: Task
> Components: Packaging
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Attachments: 15360.patch
>
>
> Currently only four individual's have their key in the project's KEYS file,
> and only one of these people are taking on the release manager role.
> The patch adds my gpg public key to the project's KEYS file found at
> https://dist.apache.org/repos/dist/release/cassandra/KEYS
> My gpg public key here has the fingerprint
> ABCD 3108 336F 7CC6 567E 769F FDD3 B769 B21C 125C
> References:
> - https://www.apache.org/dev/release-signing#keys-policy
> - http://www.apache.org/legal/release-policy.html
> - [dev ML thread "Improving our frequency of (patch) releases, and letting
> committers make
> releases"|https://lists.apache.org/thread.html/660ed8c73e7b79afa610f3e45f37914ef43a4358a85a99c8b4b0288a@]
--
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-15360) add mick's gpg key to project's KEYS file
[
https://issues.apache.org/jira/browse/CASSANDRA-15360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16957225#comment-16957225
]
Jon Haddad commented on CASSANDRA-15360:
I've verified the existing keys weren't touched and
{{$ gpg --import KEYS}}
{{gpg: key F8358FA2F2833C93: 421 signatures not checked due to missing keys}}
{{gpg: key F8358FA2F2833C93: public key "Eric Evans "
imported}}
{{gpg: key F8358FA2F2833C93: 443 signatures not checked due to missing keys}}
{{gpg: key F8358FA2F2833C93: "Eric Evans " 22 new
signatures}}
{{gpg: key F758CE318D77295D: 93 signatures not checked due to missing keys}}
{{gpg: key F758CE318D77295D: public key "Eric Evans "
imported}}
{{gpg: key 4BD736A82B5C1B00: public key "Sylvain Lebresne (pcmanus)
" imported}}
{{gpg: key 749D6EEC0353B12C: public key "T Jake Luciani "
imported}}
{{gpg: key A278B781FE4B2BDA: 28 signatures not checked due to missing keys}}
{{gpg: key A278B781FE4B2BDA: public key "Michael Shuler
" imported}}
{{gpg: key FDD3B769B21C125C: 3 signatures not checked due to missing keys}}
{{gpg: key FDD3B769B21C125C: public key "Mick Semb Wever "
imported}}
{{gpg: key FDD3B769B21C125C: "Mick Semb Wever " 1 new
signature}}
{{gpg: Total number processed: 8}}
{{gpg: imported: 6}}
{{gpg: new signatures: 23}}
{{gpg: marginals needed: 3 completes needed: 1 trust model: pgp}}
{{gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u}}
gpg --list-keys
/Users/jhaddad/.gnupg/pubring.kbx
# ommitted for brevity
pub dsa3072 2010-04-26 [SC]
ABCD3108336F7CC6567E769FFDD3B769B21C125C
uid [ unknown] Mick Semb Wever
uid [ unknown] Mick Semb Wever
uid [ unknown] [jpeg image of size 4671]
uid [ unknown] Mick Semb Wever
sub elg4096 2010-04-26 [E]
> add mick's gpg key to project's KEYS file
> -
>
> Key: CASSANDRA-15360
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15360
> Project: Cassandra
> Issue Type: Task
> Components: Packaging
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Attachments: 15360.patch
>
>
> Currently only four individual's have their key in the project's KEYS file,
> and only one of these people are taking on the release manager role.
> The patch adds my gpg public key to the project's KEYS file found at
> https://dist.apache.org/repos/dist/release/cassandra/KEYS
> My gpg public key here has the fingerprint
> ABCD 3108 336F 7CC6 567E 769F FDD3 B769 B21C 125C
> References:
> - https://www.apache.org/dev/release-signing#keys-policy
> - http://www.apache.org/legal/release-policy.html
> - [dev ML thread "Improving our frequency of (patch) releases, and letting
> committers make
> releases"|https://lists.apache.org/thread.html/660ed8c73e7b79afa610f3e45f37914ef43a4358a85a99c8b4b0288a@]
--
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-15371) Incorrect messaging service version breaks in-JVM upgrade tests on trunk
Jon Meredith created CASSANDRA-15371:
Summary: Incorrect messaging service version breaks in-JVM upgrade
tests on trunk
Key: CASSANDRA-15371
URL: https://issues.apache.org/jira/browse/CASSANDRA-15371
Project: Cassandra
Issue Type: Bug
Components: Test/dtest
Reporter: Jon Meredith
Assignee: Jon Meredith
The in-JVM upgrade tests on trunk currently fail because the messaging
version for internode messaging is selected as
{{MessagingService.current_version}},
a regression from the implementation in CASSANDRA-15078.
--
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-15360) add mick's gpg key to project's KEYS file
[ https://issues.apache.org/jira/browse/CASSANDRA-15360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Haddad updated CASSANDRA-15360: --- Reviewers: Jon Haddad, Jon Haddad (was: Jon Haddad) Jon Haddad, Jon Haddad (was: Jon Haddad) Status: Review In Progress (was: Patch Available) > add mick's gpg key to project's KEYS file > - > > Key: CASSANDRA-15360 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15360 > Project: Cassandra > Issue Type: Task > Components: Packaging >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Attachments: 15360.patch > > > Currently only four individual's have their key in the project's KEYS file, > and only one of these people are taking on the release manager role. > The patch adds my gpg public key to the project's KEYS file found at > https://dist.apache.org/repos/dist/release/cassandra/KEYS > My gpg public key here has the fingerprint > ABCD 3108 336F 7CC6 567E 769F FDD3 B769 B21C 125C > References: > - https://www.apache.org/dev/release-signing#keys-policy > - http://www.apache.org/legal/release-policy.html > - [dev ML thread "Improving our frequency of (patch) releases, and letting > committers make > releases"|https://lists.apache.org/thread.html/660ed8c73e7b79afa610f3e45f37914ef43a4358a85a99c8b4b0288a@] -- 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-15360) add mick's gpg key to project's KEYS file
[ https://issues.apache.org/jira/browse/CASSANDRA-15360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Haddad updated CASSANDRA-15360: --- Reviewers: Jon Haddad > add mick's gpg key to project's KEYS file > - > > Key: CASSANDRA-15360 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15360 > Project: Cassandra > Issue Type: Task > Components: Packaging >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Attachments: 15360.patch > > > Currently only four individual's have their key in the project's KEYS file, > and only one of these people are taking on the release manager role. > The patch adds my gpg public key to the project's KEYS file found at > https://dist.apache.org/repos/dist/release/cassandra/KEYS > My gpg public key here has the fingerprint > ABCD 3108 336F 7CC6 567E 769F FDD3 B769 B21C 125C > References: > - https://www.apache.org/dev/release-signing#keys-policy > - http://www.apache.org/legal/release-policy.html > - [dev ML thread "Improving our frequency of (patch) releases, and letting > committers make > releases"|https://lists.apache.org/thread.html/660ed8c73e7b79afa610f3e45f37914ef43a4358a85a99c8b4b0288a@] -- 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-15364) Avoid over scanning data directories in LogFile.verify()
[
https://issues.apache.org/jira/browse/CASSANDRA-15364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16957064#comment-16957064
]
Marcus Eriksson commented on CASSANDRA-15364:
-
bq. As a general comment, almost every case I see where absolutePath.ifPresent
is called is known to be a ADD or REMOVE
guess I could add asserts that it exists instead, would probably be clearer
bq. Is this to handle failure in the middle of the log (while deleting on
commit we hard-stop in the middle, so recovery may see missing files)?
the null check is unnecessary, I'll remove it
bq. Took a while to parse this change, so I am curious what was the motivation?
I was mostly worried that this patch would slow things down in the "normal
case" (a tiny number of remove records in a directory with many files) by
parsing the filename and creating a Descriptor for every file in the directory
when we really don't have to.
> Avoid over scanning data directories in LogFile.verify()
>
>
> Key: CASSANDRA-15364
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15364
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> We currently list the data directory for every {{REMOVE}} record in the file
> in {{LogFile.verify()}} - this can get very expensive during startup when we
> call {{LogTransaction.removeUnfinishedLeftovers()}}. In
> {{LogRecord.getExistingFiles(Set absoluteFilePaths)}} we also fully
> parse the file name of the sstables found, here we only need to prefix match.
--
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-15370) Cant able to Build Cluster
ebinsleeba created CASSANDRA-15370:
--
Summary: Cant able to Build Cluster
Key: CASSANDRA-15370
URL: https://issues.apache.org/jira/browse/CASSANDRA-15370
Project: Cassandra
Issue Type: Bug
Components: Cluster/Gossip, Cluster/Membership, Cluster/Schema
Reporter: ebinsleeba
Hi,
While trying to Build a Cassandra cluster with the following code am facing few
issues as follows.
var cluster = Cluster.Builder().AddContactPoint("127.0.0.1").Build();
# cluster metadata throws an exception says
System.Threading.ThreadAbortException
# while debugging the cluster I found that the Metadata node is missing.
Can anybody help me out this ?. Am I missing something?
Am using VisualStudio 2015 Console Application.
I have created a KeySpace with this same code but now am not able to do
anything.
--
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-15369) Fake row deletions and range tombstones, causing digest mismatch and sstable growth
[
https://issues.apache.org/jira/browse/CASSANDRA-15369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict Elliott Smith updated CASSANDRA-15369:
---
Bug Category: Parent values: Correctness(12982)Level 1 values:
Consistency(12989)
Complexity: Impossible
Discovered By: Code Inspection
Severity: Normal
Status: Open (was: Triage Needed)
> Fake row deletions and range tombstones, causing digest mismatch and sstable
> growth
> ---
>
> Key: CASSANDRA-15369
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15369
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Local/Memtable, Local/SSTable
>Reporter: Benedict Elliott Smith
>Priority: Normal
>
> As assessed in CASSANDRA-15363, we generate fake row deletions and fake
> tombstone markers under various circumstances:
> * If we perform a clustering key query (or select a compact column):
> * Serving from a {{Memtable}}, we will generate fake row deletions
> * Serving from an sstable, we will generate fake row tombstone markers
> * If we perform a slice query, we will generate only fake row tombstone
> markers for any range tombstone that begins or ends outside of the limit of
> the requested slice
> * If we perform a multi-slice or IN query, this will occur for each
> slice/clustering
> Unfortunately, these different behaviours can lead to very different data
> stored in sstables until a full repair is run. When we read-repair, we only
> send these fake deletions or range tombstones. A fake row deletion,
> clustering RT and slice RT, each produces a different digest. So for each
> single point lookup we can produce a digest mismatch twice, and until a full
> repair is run we can encounter an unlimited number of digest mismatches
> across different overlapping queries.
> Relatedly, this seems a more problematic variant of our atomicity failures
> caused by our monotonic reads, since RTs can have an atomic effect across (up
> to) the entire partition, whereas the propagation may happen on an
> arbitrarily small portion. If the RT exists on only one node, this could
> plausibly lead to fairly problematic scenario if that node fails before the
> range can be repaired.
> At the very least, this behaviour can lead to an almost unlimited amount of
> extraneous data being stored until the range is repaired and compaction
> happens to overwrite the sub-range RTs and row deletions.
--
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-15369) Fake row deletions and range tombstones, causing digest mismatch and sstable growth
Benedict Elliott Smith created CASSANDRA-15369:
--
Summary: Fake row deletions and range tombstones, causing digest
mismatch and sstable growth
Key: CASSANDRA-15369
URL: https://issues.apache.org/jira/browse/CASSANDRA-15369
Project: Cassandra
Issue Type: Bug
Components: Consistency/Coordination, Local/Memtable, Local/SSTable
Reporter: Benedict Elliott Smith
As assessed in CASSANDRA-15363, we generate fake row deletions and fake
tombstone markers under various circumstances:
* If we perform a clustering key query (or select a compact column):
* Serving from a {{Memtable}}, we will generate fake row deletions
* Serving from an sstable, we will generate fake row tombstone markers
* If we perform a slice query, we will generate only fake row tombstone
markers for any range tombstone that begins or ends outside of the limit of the
requested slice
* If we perform a multi-slice or IN query, this will occur for each
slice/clustering
Unfortunately, these different behaviours can lead to very different data
stored in sstables until a full repair is run. When we read-repair, we only
send these fake deletions or range tombstones. A fake row deletion, clustering
RT and slice RT, each produces a different digest. So for each single point
lookup we can produce a digest mismatch twice, and until a full repair is run
we can encounter an unlimited number of digest mismatches across different
overlapping queries.
Relatedly, this seems a more problematic variant of our atomicity failures
caused by our monotonic reads, since RTs can have an atomic effect across (up
to) the entire partition, whereas the propagation may happen on an arbitrarily
small portion. If the RT exists on only one node, this could plausibly lead to
fairly problematic scenario if that node fails before the range can be
repaired.
At the very least, this behaviour can lead to an almost unlimited amount of
extraneous data being stored until the range is repaired and compaction happens
to overwrite the sub-range RTs and row deletions.
--
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-15363) Read repair in mixed mode between 2.1 and 3.0 on COMPACT STORAGE tables causes unreadable sstables after upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-15363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-15363:
--
Status: Ready to Commit (was: Review In Progress)
LGTM, +1
> Read repair in mixed mode between 2.1 and 3.0 on COMPACT STORAGE tables
> causes unreadable sstables after upgrade
>
>
> Key: CASSANDRA-15363
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15363
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> if we have a table like this:
> {{CREATE TABLE tbl (pk ascii, b boolean, v blob, PRIMARY KEY (pk)) WITH
> COMPACT STORAGE}}
> with a cluster where node1 is 2.1 and node2 is 3.0 (during upgrade):
> * node2 coordinates a delete {{DELETE FROM tbl WHERE pk = 'something'}} which
> node1 does not get
> * node1 coordinates a quorum read {{SELECT * FROM tbl WHERE id =
> 'something'}} which causes a read repair
> * this makes node1 flush an sstable like this:
> {code}
> [
> {"key": "something",
> "metadata": {"deletionInfo":
> {"markedForDeleteAt":1571388944364000,"localDeletionTime":1571388944}},
> "cells": [["b","b",1571388944364000,"t",1571388944],
>["v","v",1571388944364000,"t",1571388944]]}
> ]
> {code}
> (It has range tombstones which are covered by the partition deletion)
> Then, when we upgrade this node to 3.0 and try to read or run
> upgradesstables, we get this:
> {code}
> ERROR [node1_CompactionExecutor:1] node1 2019-10-18 10:44:11,325
> DebuggableThreadPoolExecutor.java:242 - Error in ThreadPoolExecutor
> java.lang.UnsupportedOperationException: null
> at
> org.apache.cassandra.db.LegacyLayout.extractStaticColumns(LegacyLayout.java:779)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.io.sstable.SSTableSimpleIterator$OldFormatIterator.readStaticRow(SSTableSimpleIterator.java:120)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.io.sstable.SSTableIdentityIterator.(SSTableIdentityIterator.java:57)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator$1.initializeIterator(BigTableScanner.java:362)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.maybeInit(LazilyInitializedUnfilteredRowIterator.java:48)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.isReverseOrder(LazilyInitializedUnfilteredRowIterator.java:65)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$1.reduce(UnfilteredPartitionIterators.java:103)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$1.reduce(UnfilteredPartitionIterators.java:94)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.utils.MergeIterator$OneToOne.computeNext(MergeIterator.java:442)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$2.hasNext(UnfilteredPartitionIterators.java:144)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:92)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.db.compaction.CompactionIterator.hasNext(CompactionIterator.java:227)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:190)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:89)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.db.compaction.CompactionManager$8.runMayThrow(CompactionManager.java:675)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[dtest-3.0.19.jar:na]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_121]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ~[na:1.8.0_121]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> ~[na:1.8.0_121]
> at
>
[jira] [Updated] (CASSANDRA-15368) Failing to flush Memtable without terminating process results in permanent data loss
[
https://issues.apache.org/jira/browse/CASSANDRA-15368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict Elliott Smith updated CASSANDRA-15368:
---
Bug Category: Parent values: Correctness(12982)Level 1 values:
Unrecoverable Corruption / Loss(13161)
Complexity: Challenging
Discovered By: Code Inspection
Severity: Critical
Status: Open (was: Triage Needed)
> Failing to flush Memtable without terminating process results in permanent
> data loss
>
>
> Key: CASSANDRA-15368
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15368
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Commit Log, Local/Memtable
>Reporter: Benedict Elliott Smith
>Priority: Normal
>
> {{Memtable}} do not contain records that cover a precise contiguous range of
> {{ReplayPosition}}, since there are only weak ordering constraints when
> rolling over to a new {{Memtable}} - the last operations for the old
> {{Memtable}} may obtain their {{ReplayPosition}} after the first operations
> for the new {{Memtable}}.
> Unfortunately, we treat the {{Memtable}} range as contiguous, and invalidate
> the entire range on flush. Ordinarily we only invalidate records when all
> prior {{Memtable}} have also successfully flushed. However, in the event of
> a flush that does not terminate the process (either because of disk failure
> policy, or because it is a software error), the later flush is able to
> invalidate the region of the commit log that includes records that should
> have been flushed in the prior {{Memtable}}
> More problematically, this can also occur on restart without any associated
> flush failure, as we use commit log boundaries written to our flushed
> sstables to filter {{ReplayPosition}} on recovery, which is meant to
> replicate our {{Memtable}} flush behaviour above. However, we do not know
> that earlier flushes have completed, and they may complete successfully
> out-of-order. So any flush that completes before the process terminates, but
> began after another flush that _doesn’t_ complete before the process
> terminates, has the potential to cause permanent data loss.
--
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-15363) Read repair in mixed mode between 2.1 and 3.0 on COMPACT STORAGE tables causes unreadable sstables after upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-15363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-15363:
--
Reviewers: Aleksey Yeschenko, Benedict Elliott Smith, Aleksey Yeschenko
(was: Aleksey Yeschenko, Benedict Elliott Smith)
Aleksey Yeschenko, Benedict Elliott Smith, Aleksey Yeschenko
(was: Aleksey Yeschenko, Benedict Elliott Smith)
Status: Review In Progress (was: Patch Available)
> Read repair in mixed mode between 2.1 and 3.0 on COMPACT STORAGE tables
> causes unreadable sstables after upgrade
>
>
> Key: CASSANDRA-15363
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15363
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> if we have a table like this:
> {{CREATE TABLE tbl (pk ascii, b boolean, v blob, PRIMARY KEY (pk)) WITH
> COMPACT STORAGE}}
> with a cluster where node1 is 2.1 and node2 is 3.0 (during upgrade):
> * node2 coordinates a delete {{DELETE FROM tbl WHERE pk = 'something'}} which
> node1 does not get
> * node1 coordinates a quorum read {{SELECT * FROM tbl WHERE id =
> 'something'}} which causes a read repair
> * this makes node1 flush an sstable like this:
> {code}
> [
> {"key": "something",
> "metadata": {"deletionInfo":
> {"markedForDeleteAt":1571388944364000,"localDeletionTime":1571388944}},
> "cells": [["b","b",1571388944364000,"t",1571388944],
>["v","v",1571388944364000,"t",1571388944]]}
> ]
> {code}
> (It has range tombstones which are covered by the partition deletion)
> Then, when we upgrade this node to 3.0 and try to read or run
> upgradesstables, we get this:
> {code}
> ERROR [node1_CompactionExecutor:1] node1 2019-10-18 10:44:11,325
> DebuggableThreadPoolExecutor.java:242 - Error in ThreadPoolExecutor
> java.lang.UnsupportedOperationException: null
> at
> org.apache.cassandra.db.LegacyLayout.extractStaticColumns(LegacyLayout.java:779)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.io.sstable.SSTableSimpleIterator$OldFormatIterator.readStaticRow(SSTableSimpleIterator.java:120)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.io.sstable.SSTableIdentityIterator.(SSTableIdentityIterator.java:57)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator$1.initializeIterator(BigTableScanner.java:362)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.maybeInit(LazilyInitializedUnfilteredRowIterator.java:48)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.isReverseOrder(LazilyInitializedUnfilteredRowIterator.java:65)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$1.reduce(UnfilteredPartitionIterators.java:103)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$1.reduce(UnfilteredPartitionIterators.java:94)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.utils.MergeIterator$OneToOne.computeNext(MergeIterator.java:442)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$2.hasNext(UnfilteredPartitionIterators.java:144)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:92)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.db.compaction.CompactionIterator.hasNext(CompactionIterator.java:227)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:190)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:89)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.db.compaction.CompactionManager$8.runMayThrow(CompactionManager.java:675)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[dtest-3.0.19.jar:na]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_121]
> at
[jira] [Updated] (CASSANDRA-15367) Memtable memory allocations may deadlock
[
https://issues.apache.org/jira/browse/CASSANDRA-15367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict Elliott Smith updated CASSANDRA-15367:
---
Bug Category: Parent values: Availability(12983)Level 1 values: Process
Crash(12992)
Complexity: Challenging
Discovered By: User Report
Severity: Critical
Status: Open (was: Triage Needed)
> Memtable memory allocations may deadlock
>
>
> Key: CASSANDRA-15367
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15367
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Commit Log, Local/Memtable
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
>
> * Under heavy contention, we guard modifications to a partition with a mutex,
> for the lifetime of the memtable.
> * Memtables block for the completion of all {{OpOrder.Group}} started before
> their flush began
> * Memtables permit operations from this cohort to fall-through to the
> following Memtable, in order to guarantee a precise commitLogUpperBound
> * Memtable memory limits may be lifted for operations in the first cohort,
> since they block flush (and hence block future memory allocation)
> With very unfortunate scheduling
> * A contended partition may rapidly escalate to a mutex
> * The system may reach memory limits that prevent allocations for the new
> Memtable’s cohort (C2)
> * An operation from C2 may hold the mutex when this occurs
> * Operations from a prior Memtable’s cohort (C1), for a contended partition,
> may fall-through to the next Memtable
> * The operations from C1 may execute after the above is encountered by those
> from C2
--
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-15368) Failing to flush Memtable without terminating process results in permanent data loss
Benedict Elliott Smith created CASSANDRA-15368:
--
Summary: Failing to flush Memtable without terminating process
results in permanent data loss
Key: CASSANDRA-15368
URL: https://issues.apache.org/jira/browse/CASSANDRA-15368
Project: Cassandra
Issue Type: Bug
Components: Local/Commit Log, Local/Memtable
Reporter: Benedict Elliott Smith
{{Memtable}} do not contain records that cover a precise contiguous range of
{{ReplayPosition}}, since there are only weak ordering constraints when rolling
over to a new {{Memtable}} - the last operations for the old {{Memtable}} may
obtain their {{ReplayPosition}} after the first operations for the new
{{Memtable}}.
Unfortunately, we treat the {{Memtable}} range as contiguous, and invalidate
the entire range on flush. Ordinarily we only invalidate records when all
prior {{Memtable}} have also successfully flushed. However, in the event of a
flush that does not terminate the process (either because of disk failure
policy, or because it is a software error), the later flush is able to
invalidate the region of the commit log that includes records that should have
been flushed in the prior {{Memtable}}
More problematically, this can also occur on restart without any associated
flush failure, as we use commit log boundaries written to our flushed sstables
to filter {{ReplayPosition}} on recovery, which is meant to replicate our
{{Memtable}} flush behaviour above. However, we do not know that earlier
flushes have completed, and they may complete successfully out-of-order. So
any flush that completes before the process terminates, but began after another
flush that _doesn’t_ complete before the process terminates, has the potential
to cause permanent data loss.
--
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-15367) Memtable memory allocations may deadlock
Benedict Elliott Smith created CASSANDRA-15367:
--
Summary: Memtable memory allocations may deadlock
Key: CASSANDRA-15367
URL: https://issues.apache.org/jira/browse/CASSANDRA-15367
Project: Cassandra
Issue Type: Bug
Components: Local/Commit Log, Local/Memtable
Reporter: Benedict Elliott Smith
Assignee: Benedict Elliott Smith
* Under heavy contention, we guard modifications to a partition with a mutex,
for the lifetime of the memtable.
* Memtables block for the completion of all {{OpOrder.Group}} started before
their flush began
* Memtables permit operations from this cohort to fall-through to the following
Memtable, in order to guarantee a precise commitLogUpperBound
* Memtable memory limits may be lifted for operations in the first cohort,
since they block flush (and hence block future memory allocation)
With very unfortunate scheduling
* A contended partition may rapidly escalate to a mutex
* The system may reach memory limits that prevent allocations for the new
Memtable’s cohort (C2)
* An operation from C2 may hold the mutex when this occurs
* Operations from a prior Memtable’s cohort (C1), for a contended partition,
may fall-through to the next Memtable
* The operations from C1 may execute after the above is encountered by those
from C2
--
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-15364) Avoid over scanning data directories in LogFile.verify()
[
https://issues.apache.org/jira/browse/CASSANDRA-15364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-15364:
Reviewers: David Capwell, Jordan West (was: David Capwell)
> Avoid over scanning data directories in LogFile.verify()
>
>
> Key: CASSANDRA-15364
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15364
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> We currently list the data directory for every {{REMOVE}} record in the file
> in {{LogFile.verify()}} - this can get very expensive during startup when we
> call {{LogTransaction.removeUnfinishedLeftovers()}}. In
> {{LogRecord.getExistingFiles(Set absoluteFilePaths)}} we also fully
> parse the file name of the sstables found, here we only need to prefix match.
--
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-15363) Read repair in mixed mode between 2.1 and 3.0 on COMPACT STORAGE tables causes unreadable sstables after upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-15363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-15363:
Reviewers: Aleksey Yeschenko, Benedict Elliott Smith (was: Benedict
Elliott Smith)
> Read repair in mixed mode between 2.1 and 3.0 on COMPACT STORAGE tables
> causes unreadable sstables after upgrade
>
>
> Key: CASSANDRA-15363
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15363
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> if we have a table like this:
> {{CREATE TABLE tbl (pk ascii, b boolean, v blob, PRIMARY KEY (pk)) WITH
> COMPACT STORAGE}}
> with a cluster where node1 is 2.1 and node2 is 3.0 (during upgrade):
> * node2 coordinates a delete {{DELETE FROM tbl WHERE pk = 'something'}} which
> node1 does not get
> * node1 coordinates a quorum read {{SELECT * FROM tbl WHERE id =
> 'something'}} which causes a read repair
> * this makes node1 flush an sstable like this:
> {code}
> [
> {"key": "something",
> "metadata": {"deletionInfo":
> {"markedForDeleteAt":1571388944364000,"localDeletionTime":1571388944}},
> "cells": [["b","b",1571388944364000,"t",1571388944],
>["v","v",1571388944364000,"t",1571388944]]}
> ]
> {code}
> (It has range tombstones which are covered by the partition deletion)
> Then, when we upgrade this node to 3.0 and try to read or run
> upgradesstables, we get this:
> {code}
> ERROR [node1_CompactionExecutor:1] node1 2019-10-18 10:44:11,325
> DebuggableThreadPoolExecutor.java:242 - Error in ThreadPoolExecutor
> java.lang.UnsupportedOperationException: null
> at
> org.apache.cassandra.db.LegacyLayout.extractStaticColumns(LegacyLayout.java:779)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.io.sstable.SSTableSimpleIterator$OldFormatIterator.readStaticRow(SSTableSimpleIterator.java:120)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.io.sstable.SSTableIdentityIterator.(SSTableIdentityIterator.java:57)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator$1.initializeIterator(BigTableScanner.java:362)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.maybeInit(LazilyInitializedUnfilteredRowIterator.java:48)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.isReverseOrder(LazilyInitializedUnfilteredRowIterator.java:65)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$1.reduce(UnfilteredPartitionIterators.java:103)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$1.reduce(UnfilteredPartitionIterators.java:94)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.utils.MergeIterator$OneToOne.computeNext(MergeIterator.java:442)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$2.hasNext(UnfilteredPartitionIterators.java:144)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:92)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.db.compaction.CompactionIterator.hasNext(CompactionIterator.java:227)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:190)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:89)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.db.compaction.CompactionManager$8.runMayThrow(CompactionManager.java:675)
> ~[dtest-3.0.19.jar:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[dtest-3.0.19.jar:na]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_121]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ~[na:1.8.0_121]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> ~[na:1.8.0_121]
> at
>
[jira] [Comment Edited] (CASSANDRA-15365) Add primary key liveness info when skipping illegal cells
[
https://issues.apache.org/jira/browse/CASSANDRA-15365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16956917#comment-16956917
]
Sam Tunnicliffe edited comment on CASSANDRA-15365 at 10/22/19 10:49 AM:
LGTM (just needs the JIRA # adding to the comment at {{LegacyLayout#1294}})
was (Author: beobal):
LGTM (just needs the JIRA # adding to the comment at {{LegacyLayout#1245}})
> Add primary key liveness info when skipping illegal cells
> -
>
> Key: CASSANDRA-15365
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15365
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> In CASSANDRA-15086/CASSANDRA-15178 we started skipping the illegal legacy
> cells, problem is that if the row only contains illegal cells, we return a
> totally empty row which breaks stats collection:
> https://github.com/apache/cassandra/blob/93815db9853cb592edf13d82e91dc2e9d172f01f/src/java/org/apache/cassandra/db/rows/Rows.java#L70
> If the row only has these invalid cells, we should add a primary key liveness
> info to it to match the 2.1 behaviour.
--
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-15365) Add primary key liveness info when skipping illegal cells
[
https://issues.apache.org/jira/browse/CASSANDRA-15365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-15365:
Status: Ready to Commit (was: Review In Progress)
LGTM (just needs the JIRA # adding to the comment at {{LegacyLayout#1245}})
> Add primary key liveness info when skipping illegal cells
> -
>
> Key: CASSANDRA-15365
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15365
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> In CASSANDRA-15086/CASSANDRA-15178 we started skipping the illegal legacy
> cells, problem is that if the row only contains illegal cells, we return a
> totally empty row which breaks stats collection:
> https://github.com/apache/cassandra/blob/93815db9853cb592edf13d82e91dc2e9d172f01f/src/java/org/apache/cassandra/db/rows/Rows.java#L70
> If the row only has these invalid cells, we should add a primary key liveness
> info to it to match the 2.1 behaviour.
--
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-15365) Add primary key liveness info when skipping illegal cells
[ https://issues.apache.org/jira/browse/CASSANDRA-15365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-15365: Reviewers: Sam Tunnicliffe, Sam Tunnicliffe (was: Sam Tunnicliffe) Sam Tunnicliffe, Sam Tunnicliffe (was: Sam Tunnicliffe) Status: Review In Progress (was: Patch Available) > Add primary key liveness info when skipping illegal cells > - > > Key: CASSANDRA-15365 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15365 > Project: Cassandra > Issue Type: Bug > Components: Local/SSTable >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > In CASSANDRA-15086/CASSANDRA-15178 we started skipping the illegal legacy > cells, problem is that if the row only contains illegal cells, we return a > totally empty row which breaks stats collection: > https://github.com/apache/cassandra/blob/93815db9853cb592edf13d82e91dc2e9d172f01f/src/java/org/apache/cassandra/db/rows/Rows.java#L70 > If the row only has these invalid cells, we should add a primary key liveness > info to it to match the 2.1 behaviour. -- 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
