[jira] [Updated] (CASSANDRA-13047) Point cqlsh help to the new doc
[ https://issues.apache.org/jira/browse/CASSANDRA-13047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-13047: Test and Documentation Plan: See PRs Status: Patch Available (was: In Progress) > Point cqlsh help to the new doc > --- > > Key: CASSANDRA-13047 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13047 > Project: Cassandra > Issue Type: Bug > Components: Legacy/CQL >Reporter: Sylvain Lebresne >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0 > > > Cqlsh still points to the "old" textile CQL doc, but that's not really > maintain anymore now that we have the new doc (which include everything the > old doc had and more). We should update cqlsh to point to the new doc so we > can remove the old one completely. > Any takers? -- 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-15805) Potential duplicate rows on 2.X->3.X upgrade when multi-rows range tombstones interacts with collection tombstones
[
https://issues.apache.org/jira/browse/CASSANDRA-15805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108165#comment-17108165
]
Marcus Eriksson commented on CASSANDRA-15805:
-
This LGTM, two minor ignoreable comments;
* lazily initialise the {{outOfOrderAtom}} queue in {{AtomIterator}} as it will
be infrequently used (and maybe name it {{outOfOrderAtoms}} )
* consume the peeked atom ({{atoms.next()}}) before calling
{{atoms.pushOutOfOrder}} in {{UnfilteredIterator#readRow}} to make it obvious
we can't consume the atom we just pushed
> Potential duplicate rows on 2.X->3.X upgrade when multi-rows range tombstones
> interacts with collection tombstones
> --
>
> Key: CASSANDRA-15805
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15805
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Local/SSTable
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> The legacy reading code ({{LegacyLayout}} and
> {{UnfilteredDeserializer.OldFormatDeserializer}}) does not handle correctly
> the case where a range tombstone covering multiple rows interacts with a
> collection tombstone.
> A simple example of this problem is if one runs on 2.X:
> {noformat}
> CREATE TABLE t (
> k int,
> c1 text,
> c2 text,
> a text,
> b set,
> c text,
> PRIMARY KEY((k), c1, c2)
> );
> // Delete all rows where c1 is 'A'
> DELETE FROM t USING TIMESTAMP 1 WHERE k = 0 AND c1 = 'A';
> // Inserts a row covered by that previous range tombstone
> INSERT INTO t(k, c1, c2, a, b, c) VALUES (0, 'A', 'X', 'foo', {'whatever'},
> 'bar') USING TIMESTAMP 2;
> // Delete the collection of that previously inserted row
> DELETE b FROM t USING TIMESTAMP 3 WHERE k = 0 AND c1 = 'A' and c2 = 'X';
> {noformat}
> If the following is ran on 2.X (with everything either flushed in the same
> table or compacted together), then this will result in the inserted row being
> duplicated (one part containing the {{a}} column, the other the {{c}} one).
> I will note that this is _not_ a duplicate of CASSANDRA-15789 and this
> reproduce even with the fix to {{LegacyLayout}} of this ticket. That said,
> the additional code added to CASSANDRA-15789 to force merging duplicated rows
> if they are produced _will_ end up fixing this as a consequence (assuming
> there is no variation of this problem that leads to other visible issues than
> duplicated rows). That said, I "think" we'd still rather fix the source of
> the issue.
--
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-15805) Potential duplicate rows on 2.X->3.X upgrade when multi-rows range tombstones interacts with collection tombstones
[
https://issues.apache.org/jira/browse/CASSANDRA-15805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108165#comment-17108165
]
Marcus Eriksson edited comment on CASSANDRA-15805 at 5/15/20, 10:55 AM:
This LGTM, two minor ignoreable comments;
* lazily initialise the {{outOfOrderAtom}} queue in {{AtomIterator}} as it will
be infrequently used (and maybe name it {{outOfOrderAtoms}} )
* consume the peeked atom ({{atoms.next()}}) before calling
{{atoms.pushOutOfOrder}} in {{UnfilteredIterator#readRow}} to make it more
obvious we can't consume the atom we just pushed
was (Author: krummas):
This LGTM, two minor ignoreable comments;
* lazily initialise the {{outOfOrderAtom}} queue in {{AtomIterator}} as it will
be infrequently used (and maybe name it {{outOfOrderAtoms}} )
* consume the peeked atom ({{atoms.next()}}) before calling
{{atoms.pushOutOfOrder}} in {{UnfilteredIterator#readRow}} to make it obvious
we can't consume the atom we just pushed
> Potential duplicate rows on 2.X->3.X upgrade when multi-rows range tombstones
> interacts with collection tombstones
> --
>
> Key: CASSANDRA-15805
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15805
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Local/SSTable
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> The legacy reading code ({{LegacyLayout}} and
> {{UnfilteredDeserializer.OldFormatDeserializer}}) does not handle correctly
> the case where a range tombstone covering multiple rows interacts with a
> collection tombstone.
> A simple example of this problem is if one runs on 2.X:
> {noformat}
> CREATE TABLE t (
> k int,
> c1 text,
> c2 text,
> a text,
> b set,
> c text,
> PRIMARY KEY((k), c1, c2)
> );
> // Delete all rows where c1 is 'A'
> DELETE FROM t USING TIMESTAMP 1 WHERE k = 0 AND c1 = 'A';
> // Inserts a row covered by that previous range tombstone
> INSERT INTO t(k, c1, c2, a, b, c) VALUES (0, 'A', 'X', 'foo', {'whatever'},
> 'bar') USING TIMESTAMP 2;
> // Delete the collection of that previously inserted row
> DELETE b FROM t USING TIMESTAMP 3 WHERE k = 0 AND c1 = 'A' and c2 = 'X';
> {noformat}
> If the following is ran on 2.X (with everything either flushed in the same
> table or compacted together), then this will result in the inserted row being
> duplicated (one part containing the {{a}} column, the other the {{c}} one).
> I will note that this is _not_ a duplicate of CASSANDRA-15789 and this
> reproduce even with the fix to {{LegacyLayout}} of this ticket. That said,
> the additional code added to CASSANDRA-15789 to force merging duplicated rows
> if they are produced _will_ end up fixing this as a consequence (assuming
> there is no variation of this problem that leads to other visible issues than
> duplicated rows). That said, I "think" we'd still rather fix the source of
> the issue.
--
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-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-14298: -- Resolution: Fixed Status: Resolved (was: Open) > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Legacy/Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Normal > Labels: cqlsh, dtest, pull-request-available > Fix For: 4.0, 4.0-alpha1 > > Attachments: CASSANDRA-14298-blogposts-and-ratefile-workarounds.txt, > CASSANDRA-14298.txt, cqlsh_tests_notes.md > > Time Spent: 20m > Remaining Estimate: 0h > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- 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-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-14298: -- Status: Open (was: Resolved) Somehow is resolved w/resolution unresolved. Re-opening to fix. > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Legacy/Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Normal > Labels: cqlsh, dtest, pull-request-available > Fix For: 4.0, 4.0-alpha1 > > Attachments: CASSANDRA-14298-blogposts-and-ratefile-workarounds.txt, > CASSANDRA-14298.txt, cqlsh_tests_notes.md > > Time Spent: 20m > Remaining Estimate: 0h > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- 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-15056) SimpleClient should pass connection properties as options
[ https://issues.apache.org/jira/browse/CASSANDRA-15056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-15056: -- Resolution: Fixed Status: Resolved (was: Open) > SimpleClient should pass connection properties as options > - > > Key: CASSANDRA-15056 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15056 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client, Test/unit >Reporter: Sumanth Pasupuleti >Assignee: Sumanth Pasupuleti >Priority: Normal > Labels: pull-request-available > Fix For: 4.0, 4.0-alpha1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > As of today. SimpleClient does not pass CHECKSUM or COMPRESSION as options to > the server. In order for these parameters to take effect on the server side, > they should be passed as options. -- 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-15056) SimpleClient should pass connection properties as options
[ https://issues.apache.org/jira/browse/CASSANDRA-15056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-15056: -- Status: Open (was: Resolved) Some how status: resolved w/Resolution: Unresolved. Re-opening to fix. > SimpleClient should pass connection properties as options > - > > Key: CASSANDRA-15056 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15056 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client, Test/unit >Reporter: Sumanth Pasupuleti >Assignee: Sumanth Pasupuleti >Priority: Normal > Labels: pull-request-available > Fix For: 4.0, 4.0-alpha1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > As of today. SimpleClient does not pass CHECKSUM or COMPRESSION as options to > the server. In order for these parameters to take effect on the server side, > they should be passed as options. -- 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-14802) calculatePendingRanges assigns more pending ranges than necessary
[
https://issues.apache.org/jira/browse/CASSANDRA-14802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-14802:
--
Status: Open (was: Resolved)
Some how status: resolved w/Resolution: Unresolved. Re-opening to fix.
> calculatePendingRanges assigns more pending ranges than necessary
> --
>
> Key: CASSANDRA-14802
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14802
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Coordination, Legacy/Distributed Metadata
>Reporter: Benedict Elliott Smith
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 4.0, 4.0-alpha1
>
>
> This might be a good thing, but should probably be configurable, and made
> consistent. Presently, in a number of circumstances where there are multiple
> range movements, {{calculatePendingRanges}} will assign a pending range to a
> node that will not ultimately own it. If done consistently, this might make
> range movements resilient to node failures / aborted range movements, since
> all nodes will be receiving all ranges they might own under any incomplete
> range ownership movements. But done inconsistently it seems only to reduce
> availability in the cluster, by potentially increasing the number of pending
> nodes unnecessarily.
--
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-14802) calculatePendingRanges assigns more pending ranges than necessary
[
https://issues.apache.org/jira/browse/CASSANDRA-14802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-14802:
--
Resolution: Fixed
Status: Resolved (was: Open)
> calculatePendingRanges assigns more pending ranges than necessary
> --
>
> Key: CASSANDRA-14802
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14802
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Coordination, Legacy/Distributed Metadata
>Reporter: Benedict Elliott Smith
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 4.0, 4.0-alpha1
>
>
> This might be a good thing, but should probably be configurable, and made
> consistent. Presently, in a number of circumstances where there are multiple
> range movements, {{calculatePendingRanges}} will assign a pending range to a
> node that will not ultimately own it. If done consistently, this might make
> range movements resilient to node failures / aborted range movements, since
> all nodes will be receiving all ranges they might own under any incomplete
> range ownership movements. But done inconsistently it seems only to reduce
> availability in the cluster, by potentially increasing the number of pending
> nodes unnecessarily.
--
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-15727) Internode messaging connection setup between 4.0 and legacy SSL 3.0 fails if initial connection version incorrect
[
https://issues.apache.org/jira/browse/CASSANDRA-15727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108321#comment-17108321
]
Aleksey Yeschenko commented on CASSANDRA-15727:
---
bq. Sorry that I'm late to this party, but might it be cleaner to move the
setting of messagingVersion into attempt since we already do it there, and
remove it from onCompletedHandshake/RETRY and the class constructor? This would
capture all possible reasons messagingVersion might have changed, and reduce
the verbosity of this particular point in the code, possibly keeping its intent
a bit clearer.
Good call. I'll ninja it, if nobody objects.
> Internode messaging connection setup between 4.0 and legacy SSL 3.0 fails if
> initial connection version incorrect
> -
>
> Key: CASSANDRA-15727
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15727
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0, 4.0-alpha5
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This was discovered while testing upgrading an SSL enabled cluster from 3.0
> to 4.0. The 3.0 cluster was configured to only listen on the ssl storage
> port. When the upgraded 4.0 node started it received a gossip messsage that
> triggered a shadow round before it had correctly set the messaging versions
> for the other endpoints.
> Sending the message created the connection, but because the endpoint
> defaulted to {{VERSION_40}} the initial connect attempt was to the regular
> {{storage_port}}. The 3.0 node was only listening on the
> {{ssl_storage_port}}, so the connection was refused and the
> {{OutboundConnection.onFailure}} handler was called. As the shadow
> gossip round had queued up a message, the {{hasPending}} branch was followed
> and the connection was rescheduled, however the port is never recalculated as
> the original settings are used so it always fails.
> Meanwhile, the node discovered information about peers through inbound
> connection and gossip updating the messaging version for the endpoint which
> could have been used to make a valid connection.
--
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: Ninja-follow-up to CASSANDRA-15727 (move code slightly)
This is an automated email from the ASF dual-hosted git repository.
aleksey 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 17caa28 Ninja-follow-up to CASSANDRA-15727 (move code slightly)
17caa28 is described below
commit 17caa288c311e0364f81f78a85831c36f0f4917e
Author: Aleksey Yeshchenko
AuthorDate: Fri May 15 15:34:35 2020 +0100
Ninja-follow-up to CASSANDRA-15727 (move code slightly)
---
.../apache/cassandra/net/OutboundConnection.java | 36 ++
1 file changed, 17 insertions(+), 19 deletions(-)
diff --git a/src/java/org/apache/cassandra/net/OutboundConnection.java
b/src/java/org/apache/cassandra/net/OutboundConnection.java
index 315d086..d7ebcd8 100644
--- a/src/java/org/apache/cassandra/net/OutboundConnection.java
+++ b/src/java/org/apache/cassandra/net/OutboundConnection.java
@@ -1084,25 +1084,7 @@ public class OutboundConnection
if (hasPending())
{
Promise> result = new
AsyncPromise<>(eventLoop);
-state = new Connecting(state.disconnected(),
- result,
- eventLoop.schedule(() ->
- {
- // Re-evaluate messagingVersion
before re-attempting the connection in case
- // endpointToVersion were
updated. This happens if the outbound connection
- // is made before the
endpointToVersion table is initially constructed or out
- // of date (e.g. if outbound
connections are established for gossip
- // as a result of an inbound
connection) and can result in the wrong outbound
- // port being selected if
configured with enable_legacy_ssl_storage_port=true.
- int maybeUpdatedVersion =
template.endpointToVersion().get(template.to);
- if (maybeUpdatedVersion !=
messagingVersion)
- {
- logger.trace("Endpoint
version changed from {} to {} since connection initialized, updating.",
-
messagingVersion, maybeUpdatedVersion);
- messagingVersion =
maybeUpdatedVersion;
- }
- attempt(result);
- }, max(100, retryRateMillis),
MILLISECONDS));
+state = new Connecting(state.disconnected(), result,
eventLoop.schedule(() -> attempt(result), max(100, retryRateMillis),
MILLISECONDS));
retryRateMillis = min(1000, retryRateMillis * 2);
}
else
@@ -1194,6 +1176,22 @@ public class OutboundConnection
{
++connectionAttempts;
+/*
+ * Re-evaluate messagingVersion before re-attempting the
connection in case
+ * endpointToVersion were updated. This happens if the
outbound connection
+ * is made before the endpointToVersion table is initially
constructed or out
+ * of date (e.g. if outbound connections are established for
gossip
+ * as a result of an inbound connection) and can result in the
wrong outbound
+ * port being selected if configured with
enable_legacy_ssl_storage_port=true.
+ */
+int knownMessagingVersion = messagingVersion();
+if (knownMessagingVersion != messagingVersion)
+{
+logger.trace("Endpoint version changed from {} to {} since
connection initialized, updating.",
+ messagingVersion, knownMessagingVersion);
+messagingVersion = knownMessagingVersion;
+}
+
settings = template;
if (messagingVersion > settings.acceptVersions.max)
messagingVersion = settings.acceptVersions.max;
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15727) Internode messaging connection setup between 4.0 and legacy SSL 3.0 fails if initial connection version incorrect
[
https://issues.apache.org/jira/browse/CASSANDRA-15727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108321#comment-17108321
]
Aleksey Yeschenko edited comment on CASSANDRA-15727 at 5/15/20, 2:36 PM:
-
bq. Sorry that I'm late to this party, but might it be cleaner to move the
setting of messagingVersion into attempt since we already do it there, and
remove it from onCompletedHandshake/RETRY and the class constructor? This would
capture all possible reasons messagingVersion might have changed, and reduce
the verbosity of this particular point in the code, possibly keeping its intent
a bit clearer.
Good call. I'll ninja it, if nobody objects.
EDIT: may or may have not done it in 17caa288c311e0364f81f78a85831c36f0f4917e
was (Author: iamaleksey):
bq. Sorry that I'm late to this party, but might it be cleaner to move the
setting of messagingVersion into attempt since we already do it there, and
remove it from onCompletedHandshake/RETRY and the class constructor? This would
capture all possible reasons messagingVersion might have changed, and reduce
the verbosity of this particular point in the code, possibly keeping its intent
a bit clearer.
Good call. I'll ninja it, if nobody objects.
> Internode messaging connection setup between 4.0 and legacy SSL 3.0 fails if
> initial connection version incorrect
> -
>
> Key: CASSANDRA-15727
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15727
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0, 4.0-alpha5
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This was discovered while testing upgrading an SSL enabled cluster from 3.0
> to 4.0. The 3.0 cluster was configured to only listen on the ssl storage
> port. When the upgraded 4.0 node started it received a gossip messsage that
> triggered a shadow round before it had correctly set the messaging versions
> for the other endpoints.
> Sending the message created the connection, but because the endpoint
> defaulted to {{VERSION_40}} the initial connect attempt was to the regular
> {{storage_port}}. The 3.0 node was only listening on the
> {{ssl_storage_port}}, so the connection was refused and the
> {{OutboundConnection.onFailure}} handler was called. As the shadow
> gossip round had queued up a message, the {{hasPending}} branch was followed
> and the connection was rescheduled, however the port is never recalculated as
> the original settings are used so it always fails.
> Meanwhile, the node discovered information about peers through inbound
> connection and gossip updating the messaging version for the endpoint which
> could have been used to make a valid connection.
--
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-15778) CorruptSSTableException after a 2.1 SSTable is upgraded to 3.0, failing reads
[
https://issues.apache.org/jira/browse/CASSANDRA-15778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108389#comment-17108389
]
Alex Petrov commented on CASSANDRA-15778:
-
After thinking about it for longer time and talking with [~slebresne] and
[~aleksey], I think there're no good solution to this problem. At the moment
{{EmptyType}} assumes that it's fixed-size, therefore doesn't write its size
(only writes bytes). This means that anyone who has already written the value,
won't be able to read it back, and writing a generic scrub tool for that will
be non-trivial since we can have arbitrary bytes there.
>From the alternatives, I think everything we have right now is risky to some
>degree:
* if we inherit {{EmptyType}} from {{BytesType}}, we change semantics of the
empty type, which can have unforeseen consequences
* if we change schema and migrate from {{EmptyType}} to {{BytesType}}, we'll
end up showing the hidden column. To keep it hidden, we'll have to add a flag
to table metadata
* if we just migrate {{EmptyType}} from fixed-size to variable-size
(basically by not overriding {{valueLengthIfFixed}}), it'll work in principle
because of {{BufferCell#hasValue}}, but this also might be risky
So the only reasonable thing to do seems to handle this particular case: people
who still have their 2.1 sstables, and they haven't upgraded, and they're
(somewhat) interested in the data they've written. People who're not interested
in the data they're written receive the same solution, but can just drop the
column.
I suggest we do the following:
* we keep the existing validation that forbids writes into {{EmptyType}}
columns and make {{EmptyType}} write method no-op to be on an even safer side
* we add a way to "unbreak" cql-created thrift-written tables by adding new
{{ALTER TABLE FIX EMPTY TYPE}} (naming is just for example here) statement,
which would _only_ work for cql-created dense tables and nothing else, and
would turn hidden {{EmptyType}} column to {{BytesType}}.
Main reason to ask for human intervention is that we'd like to avoid changes
that can add new problems whie not bein fully satisfactory for the given
problem. This will give anyone with a problem a clear path to a solution
without risking already existing setups.
This also implies that in [CASSANDRA-15811], we'll simply drop {{EmptyType}}
column entirely when doing {{DROP COMPACT STORAGE}}, so no surprising column
without data will show up.
> CorruptSSTableException after a 2.1 SSTable is upgraded to 3.0, failing reads
> -
>
> Key: CASSANDRA-15778
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15778
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction, Local/SSTable
>Reporter: Sumanth Pasupuleti
>Assignee: Alex Petrov
>Priority: Normal
> Fix For: 3.0.x
>
>
> Below is the exception with stack trace. This issue is consistently
> reproduce-able.
> {code:java}
> ERROR [SharedPool-Worker-1] 2020-05-01 14:57:57,661
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[SharedPool-Worker-1,5,main]ERROR [SharedPool-Worker-1] 2020-05-01
> 14:57:57,661 AbstractLocalAwareExecutorService.java:169 - Uncaught exception
> on thread
> Thread[SharedPool-Worker-1,5,main]org.apache.cassandra.io.sstable.CorruptSSTableException:
> Corrupted:
> /mnt/data/cassandra/data// at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:349)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:220)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.columniterator.SSTableIterator.hasNext(SSTableIterator.java:33)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:95)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:95)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:
[jira] [Commented] (CASSANDRA-15727) Internode messaging connection setup between 4.0 and legacy SSL 3.0 fails if initial connection version incorrect
[
https://issues.apache.org/jira/browse/CASSANDRA-15727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108400#comment-17108400
]
Jon Meredith commented on CASSANDRA-15727:
--
Looks like an improvement to me. Thanks for both your help.
> Internode messaging connection setup between 4.0 and legacy SSL 3.0 fails if
> initial connection version incorrect
> -
>
> Key: CASSANDRA-15727
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15727
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0, 4.0-alpha5
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This was discovered while testing upgrading an SSL enabled cluster from 3.0
> to 4.0. The 3.0 cluster was configured to only listen on the ssl storage
> port. When the upgraded 4.0 node started it received a gossip messsage that
> triggered a shadow round before it had correctly set the messaging versions
> for the other endpoints.
> Sending the message created the connection, but because the endpoint
> defaulted to {{VERSION_40}} the initial connect attempt was to the regular
> {{storage_port}}. The 3.0 node was only listening on the
> {{ssl_storage_port}}, so the connection was refused and the
> {{OutboundConnection.onFailure}} handler was called. As the shadow
> gossip round had queued up a message, the {{hasPending}} branch was followed
> and the connection was rescheduled, however the port is never recalculated as
> the original settings are used so it always fails.
> Meanwhile, the node discovered information about peers through inbound
> connection and gossip updating the messaging version for the endpoint which
> could have been used to make a valid connection.
--
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-15685) flaky testWithMismatchingPending - org.apache.cassandra.distributed.test.PreviewRepairTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108460#comment-17108460
]
David Capwell commented on CASSANDRA-15685:
---
For others, Ekaterina and I chatted offline.
The preview repair tests assert that previews did not report inconsistencies,
but since it uses a AtomicBoolean to handle concurrent cases, and the default
is false, it can lead to a false negative; if we don't see the notification
then we wouldn't flip the boolean from false to true. Every test asserts
false, so it is not failing right now, but it also won't detect regressions.
The issue is also true in the nodetool case as it may not see the notification
so isn't aware of the results.
Thanks Ekaterina for all the hard work! =D
> flaky testWithMismatchingPending -
> org.apache.cassandra.distributed.test.PreviewRepairTest
> --
>
> Key: CASSANDRA-15685
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15685
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Kevin Gallardo
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Attachments: log-CASSANDRA-15685.txt, output
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Observed in:
> https://app.circleci.com/pipelines/github/newkek/cassandra/34/workflows/1c6b157d-13c3-48a9-85fb-9fe8c153256b/jobs/191/tests
> Failure:
> {noformat}
> testWithMismatchingPending -
> org.apache.cassandra.distributed.test.PreviewRepairTest
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.distributed.test.PreviewRepairTest.testWithMismatchingPending(PreviewRepairTest.java:97)
> {noformat}
> [Circle
> CI|https://circleci.com/gh/dcapwell/cassandra/tree/bug%2FCASSANDRA-15685]
--
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-15790) EmptyType doesn't override writeValue so could attempt to write bytes when expected not to
[
https://issues.apache.org/jira/browse/CASSANDRA-15790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108580#comment-17108580
]
David Capwell commented on CASSANDRA-15790:
---
since its ready for commit sending the patches for 3.0 and 3.11 now.
> EmptyType doesn't override writeValue so could attempt to write bytes when
> expected not to
> --
>
> Key: CASSANDRA-15790
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15790
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-alpha
>
>
> EmptyType.writeValues is defined here
> https://github.com/apache/cassandra/blob/e394dc0bb32f612a476269010930c617dd1ed3cb/src/java/org/apache/cassandra/db/marshal/AbstractType.java#L407-L414
> {code}
> public void writeValue(ByteBuffer value, DataOutputPlus out) throws
> IOException
> {
> assert value.hasRemaining();
> if (valueLengthIfFixed() >= 0)
> out.write(value);
> else
> ByteBufferUtil.writeWithVIntLength(value, out);
> }
> {code}
> This is fine when the value is empty as the write of empty no-ops (the
> readValue also noops since the length is 0), but if the value is not empty
> (possible during upgrades or random bugs) then this could silently cause
> corruption; ideally this should throw a exception if the ByteBuffer has data.
> This was called from
> org.apache.cassandra.db.rows.BufferCell.Serializer#serialize, here we check
> to see if data is present or not and update the flags. If data is present
> then and only then do we call type.writeValue (which requires bytes is not
> empty). The problem is that EmptyType never expects writes to happen, but it
> still writes them; and does not read them (since it says it is fixed length
> of 0, so does read(buffer, 0)).
--
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-15778) CorruptSSTableException after a 2.1 SSTable is upgraded to 3.0, failing reads
[
https://issues.apache.org/jira/browse/CASSANDRA-15778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108618#comment-17108618
]
David Capwell commented on CASSANDRA-15778:
---
Alex and I spoke offline, dumping here for context.
There are a few cases we want to worry about, and some cases which we don't
feel are important to worry about:
Cases we feel are important to worry about
1) upgrade from 2.1 to 3.0 *or* 3.11
2) CQL Table with values written to the previous blob type (hidden type only
exposed via Thrift)
3) Thrift tables with arbitrary types
Cases we don't feel are important to worry about
1) upgrade from 3.0 to 3.0 or 3.11
Given this, we came up with a proposal that should address the above concerns.
1) while upgrading from 2.1 to 3.0 or 3.11, legacy schema migration should
default to BytesType, but allow an override to switch to EmptyType; BytesType
will cause the column to be no longer hidden [1][2].
2) if override is set to EmptyType and data is found to be rejected in
validation, then DROP COMPACT STORAGE will be needed and should add an option
to expose this column. This means the hidden column will now be exposed and
will allow alter statements to change the type or drop it completely.
3) Attempt to add a more meaningful exception which tells users about this fix.
Right now the exception is "EmptyType only accept empty values", this is not
actionable and can cause confusion.
4) For clusters already upgraded to 3.0 or 3.11, the only impact would be the
options added to DROP COMPACT STORAGE which would allow the column to be
exposed or not [3]; we have not worked out the default behaviors of this.
[1] - This is actually an open disagreement. Alex's point is that this affects
a small user base, but would expose the field to all users upgrading. My point
is summarized in [2].
[2] - The reason to default to BytesTypes is because the rolling upgrade case.
Since there may be data present, the default of EmptyType is unsafe as it would
cause the token range impacted to be unavailable to the users. Schema
migrations are not allowed in mixed mode so the only way to resolve this would
be to complete the upgrade, which may cause a larger outage for users. If the
user is aware of this behavior and know its safe, they may choose to switch to
the EmptyType case.
[3] - There is an assumption that all clusters are 3.0.20+, the reason for this
assumption is that validation checks were in 3.0.20 (see CASSANDRA-15373) and
would protect against corrupting the SSTable in the upgrade or compaction case.
If the cluster is 3.0.19 or earlier, then corruption would have happened as
the EmptyType was writing the bytes but was not reading them (see
CASSANDRA-15790). As of this moment we are not aware of a generic way to
repair this data as we don't know what those bytes were so couldn't account for
them generically (they are written without length).
> CorruptSSTableException after a 2.1 SSTable is upgraded to 3.0, failing reads
> -
>
> Key: CASSANDRA-15778
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15778
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction, Local/SSTable
>Reporter: Sumanth Pasupuleti
>Assignee: Alex Petrov
>Priority: Normal
> Fix For: 3.0.x
>
>
> Below is the exception with stack trace. This issue is consistently
> reproduce-able.
> {code:java}
> ERROR [SharedPool-Worker-1] 2020-05-01 14:57:57,661
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[SharedPool-Worker-1,5,main]ERROR [SharedPool-Worker-1] 2020-05-01
> 14:57:57,661 AbstractLocalAwareExecutorService.java:169 - Uncaught exception
> on thread
> Thread[SharedPool-Worker-1,5,main]org.apache.cassandra.io.sstable.CorruptSSTableException:
> Corrupted:
> /mnt/data/cassandra/data// at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:349)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:220)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.columniterator.SSTableIterator.hasNext(SSTableIterator.java:33)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:95)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
> ~[nf-cassandra-3.0.19.8.jar:3.0.19.8] at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> ~[nf-cassandra-3.
[jira] [Commented] (CASSANDRA-14200) NullPointerException when dumping sstable with null value for timestamp column
[
https://issues.apache.org/jira/browse/CASSANDRA-14200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108649#comment-17108649
]
Thanh commented on CASSANDRA-14200:
---
You can see the NPE by inserting data using JSON like this:
{code:java}
create table tsest3(id int PRIMARY KEY ,fname text, lname text, ts_field1
timestamp, dept text, ts_field2 timestamp);
insert into tsest3 JSON
'{"id":7,"fname":"sally","lname":"field","ts_field1":"","dept":"dept1","ts_field2":null}';{code}
The problem is introduced when you try setting a timestamp field to null using
JSON '\{"ts_field1":""}' //this will give sstabledump NPE
instead of
JSON '\{"ts_field1":null}' //this is fine, no NPE here
> NullPointerException when dumping sstable with null value for timestamp column
> --
>
> Key: CASSANDRA-14200
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14200
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Simon Zhou
>Assignee: Simon Zhou
>Priority: Normal
> Fix For: 3.0.x
>
>
> We have an sstable whose schema has a column of type timestamp and it's not
> part of primary key. When dumping the sstable using sstabledump there is NPE
> like this:
> {code:java}
> Exception in thread "main" java.lang.NullPointerException
> at java.util.Calendar.setTime(Calendar.java:1770)
> at java.text.SimpleDateFormat.format(SimpleDateFormat.java:943)
> at java.text.SimpleDateFormat.format(SimpleDateFormat.java:936)
> at java.text.DateFormat.format(DateFormat.java:345)
> at
> org.apache.cassandra.db.marshal.TimestampType.toJSONString(TimestampType.java:93)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeCell(JsonTransformer.java:442)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeColumnData(JsonTransformer.java:376)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeRow(JsonTransformer.java:280)
> at
> org.apache.cassandra.tools.JsonTransformer.serializePartition(JsonTransformer.java:215)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at org.apache.cassandra.tools.JsonTransformer.toJson(JsonTransformer.java:104)
> at org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:242){code}
> The reason is that we use a null Date when there is no value for this column:
> {code}
> public Date deserialize(ByteBuffer bytes)
> {
> return bytes.remaining() == 0 ? null : new
> Date(ByteBufferUtil.toLong(bytes));
> }
> {code}
> It seems that we should not deserialize columns with null values.
--
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-15790) EmptyType doesn't override writeValue so could attempt to write bytes when expected not to
[
https://issues.apache.org/jira/browse/CASSANDRA-15790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108653#comment-17108653
]
David Capwell commented on CASSANDRA-15790:
---
Added patch for 3.0 and ran dtests. I saw some tests failed so I ran against
cassandra-3.0:
https://app.circleci.com/pipelines/github/dcapwell/cassandra/284/workflows/29833185-6f82-47ed-9372-0136d4109b88/jobs/1383.
looks like my patch has the same failures as cassandra-3.0, so my patch
doesn't look to regress 3.0
working on patch for 3.11 now.
> EmptyType doesn't override writeValue so could attempt to write bytes when
> expected not to
> --
>
> Key: CASSANDRA-15790
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15790
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-alpha
>
>
> EmptyType.writeValues is defined here
> https://github.com/apache/cassandra/blob/e394dc0bb32f612a476269010930c617dd1ed3cb/src/java/org/apache/cassandra/db/marshal/AbstractType.java#L407-L414
> {code}
> public void writeValue(ByteBuffer value, DataOutputPlus out) throws
> IOException
> {
> assert value.hasRemaining();
> if (valueLengthIfFixed() >= 0)
> out.write(value);
> else
> ByteBufferUtil.writeWithVIntLength(value, out);
> }
> {code}
> This is fine when the value is empty as the write of empty no-ops (the
> readValue also noops since the length is 0), but if the value is not empty
> (possible during upgrades or random bugs) then this could silently cause
> corruption; ideally this should throw a exception if the ByteBuffer has data.
> This was called from
> org.apache.cassandra.db.rows.BufferCell.Serializer#serialize, here we check
> to see if data is present or not and update the flags. If data is present
> then and only then do we call type.writeValue (which requires bytes is not
> empty). The problem is that EmptyType never expects writes to happen, but it
> still writes them; and does not read them (since it says it is fixed length
> of 0, so does read(buffer, 0)).
--
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-14200) NullPointerException when dumping sstable with null value for timestamp column
[
https://issues.apache.org/jira/browse/CASSANDRA-14200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108654#comment-17108654
]
Thanh commented on CASSANDRA-14200:
---
You can workaround the problem by updating the bad "null" timestamp cell using
update set =null where =;
but you'll still see the NPE until the sstable containing the "bad" null value
is compacted with the sstable containing the "good" null value.
> NullPointerException when dumping sstable with null value for timestamp column
> --
>
> Key: CASSANDRA-14200
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14200
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Simon Zhou
>Assignee: Simon Zhou
>Priority: Normal
> Fix For: 3.0.x
>
>
> We have an sstable whose schema has a column of type timestamp and it's not
> part of primary key. When dumping the sstable using sstabledump there is NPE
> like this:
> {code:java}
> Exception in thread "main" java.lang.NullPointerException
> at java.util.Calendar.setTime(Calendar.java:1770)
> at java.text.SimpleDateFormat.format(SimpleDateFormat.java:943)
> at java.text.SimpleDateFormat.format(SimpleDateFormat.java:936)
> at java.text.DateFormat.format(DateFormat.java:345)
> at
> org.apache.cassandra.db.marshal.TimestampType.toJSONString(TimestampType.java:93)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeCell(JsonTransformer.java:442)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeColumnData(JsonTransformer.java:376)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeRow(JsonTransformer.java:280)
> at
> org.apache.cassandra.tools.JsonTransformer.serializePartition(JsonTransformer.java:215)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at org.apache.cassandra.tools.JsonTransformer.toJson(JsonTransformer.java:104)
> at org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:242){code}
> The reason is that we use a null Date when there is no value for this column:
> {code}
> public Date deserialize(ByteBuffer bytes)
> {
> return bytes.remaining() == 0 ? null : new
> Date(ByteBufferUtil.toLong(bytes));
> }
> {code}
> It seems that we should not deserialize columns with null values.
--
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-14200) NullPointerException when dumping sstable with null value for timestamp column
[
https://issues.apache.org/jira/browse/CASSANDRA-14200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108654#comment-17108654
]
Thanh edited comment on CASSANDRA-14200 at 5/15/20, 8:59 PM:
-
You can workaround the problem by updating the bad "null" value to a "good"
null value using
update set =null where =;
but you'll still see the NPE until the sstable containing the "bad" null value
is compacted with the sstable containing the "good" null value.
was (Author: thatran):
You can workaround the problem by updating the bad "null" timestamp cell using
update set =null where =;
but you'll still see the NPE until the sstable containing the "bad" null value
is compacted with the sstable containing the "good" null value.
> NullPointerException when dumping sstable with null value for timestamp column
> --
>
> Key: CASSANDRA-14200
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14200
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Simon Zhou
>Assignee: Simon Zhou
>Priority: Normal
> Fix For: 3.0.x
>
>
> We have an sstable whose schema has a column of type timestamp and it's not
> part of primary key. When dumping the sstable using sstabledump there is NPE
> like this:
> {code:java}
> Exception in thread "main" java.lang.NullPointerException
> at java.util.Calendar.setTime(Calendar.java:1770)
> at java.text.SimpleDateFormat.format(SimpleDateFormat.java:943)
> at java.text.SimpleDateFormat.format(SimpleDateFormat.java:936)
> at java.text.DateFormat.format(DateFormat.java:345)
> at
> org.apache.cassandra.db.marshal.TimestampType.toJSONString(TimestampType.java:93)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeCell(JsonTransformer.java:442)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeColumnData(JsonTransformer.java:376)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeRow(JsonTransformer.java:280)
> at
> org.apache.cassandra.tools.JsonTransformer.serializePartition(JsonTransformer.java:215)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at org.apache.cassandra.tools.JsonTransformer.toJson(JsonTransformer.java:104)
> at org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:242){code}
> The reason is that we use a null Date when there is no value for this column:
> {code}
> public Date deserialize(ByteBuffer bytes)
> {
> return bytes.remaining() == 0 ? null : new
> Date(ByteBufferUtil.toLong(bytes));
> }
> {code}
> It seems that we should not deserialize columns with null values.
--
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-15807) Support multiple keyspaces in Cassandra-Diff
[ https://issues.apache.org/jira/browse/CASSANDRA-15807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108672#comment-17108672 ] Yifan Cai commented on CASSANDRA-15807: --- PR: https://github.com/apache/cassandra-diff/pull/8 Code: https://github.com/yifan-c/cassandra-diff/tree/support-multiple-keyspaces At a high level, in order to support comparing tables among multiple keyspaces, it now uses pair to locate the table. The compare logic remains the same. The changes is relatively invasive as it changes the input format and the schema for job metadata. Given the tool is at its early stage, I think it is OK. Feel free to raise it if any objections. End-to-end testing performed locally to verify the spark job runs and api service is working as expected. Changed items: * Replaced discrete inputs, keyspace and tables, with one list of keyspace table pairs. Now a table is identified by keyspace and table name. * The scheme of JobMetadataDb is updated correspondingly to replace all 'table_name' with 'keyspace_table_name' and replace table_names with keyspace_table_names * DBService in api service is changed to make sure it can query with the new schema. * Updated the ReadMe with an example of running with multiple keyspaces. > Support multiple keyspaces in Cassandra-Diff > > > Key: CASSANDRA-15807 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15807 > Project: Cassandra > Issue Type: Improvement > Components: Tool/diff >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > > Adding the support to run diff comparison of tables across multiple keyspaces > to avoid bringing up multiple spark jobs and give a better view of data diffs > in the whole cluster. > Cassandra-diff currently only support compare multiple tables under one > single keyspace. -- 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-15807) Support multiple keyspaces in Cassandra-Diff
[ https://issues.apache.org/jira/browse/CASSANDRA-15807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108674#comment-17108674 ] Yifan Cai commented on CASSANDRA-15807: --- cc [~marcuse] > Support multiple keyspaces in Cassandra-Diff > > > Key: CASSANDRA-15807 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15807 > Project: Cassandra > Issue Type: Improvement > Components: Tool/diff >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > > Adding the support to run diff comparison of tables across multiple keyspaces > to avoid bringing up multiple spark jobs and give a better view of data diffs > in the whole cluster. > Cassandra-diff currently only support compare multiple tables under one > single keyspace. -- 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-15807) Support multiple keyspaces in Cassandra-Diff
[ https://issues.apache.org/jira/browse/CASSANDRA-15807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-15807: -- Source Control Link: https://github.com/apache/cassandra-diff/pull/8 > Support multiple keyspaces in Cassandra-Diff > > > Key: CASSANDRA-15807 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15807 > Project: Cassandra > Issue Type: Improvement > Components: Tool/diff >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > > Adding the support to run diff comparison of tables across multiple keyspaces > to avoid bringing up multiple spark jobs and give a better view of data diffs > in the whole cluster. > Cassandra-diff currently only support compare multiple tables under one > single keyspace. -- 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-15807) Support multiple keyspaces in Cassandra-Diff
[ https://issues.apache.org/jira/browse/CASSANDRA-15807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-15807: -- Test and Documentation Plan: unit test. local E2E test Status: Patch Available (was: Open) > Support multiple keyspaces in Cassandra-Diff > > > Key: CASSANDRA-15807 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15807 > Project: Cassandra > Issue Type: Improvement > Components: Tool/diff >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > > Adding the support to run diff comparison of tables across multiple keyspaces > to avoid bringing up multiple spark jobs and give a better view of data diffs > in the whole cluster. > Cassandra-diff currently only support compare multiple tables under one > single keyspace. -- 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-14200) NullPointerException when dumping sstable with null value for timestamp column
[
https://issues.apache.org/jira/browse/CASSANDRA-14200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108654#comment-17108654
]
Thanh edited comment on CASSANDRA-14200 at 5/15/20, 9:26 PM:
-
You can workaround the problem by updating the bad "null" value to a "good"
null value using
update set =null where =;
but you'll still see the NPE until the sstable containing the "bad" null value
is compacted with the sstable containing the "good" null value (since existing
sstables are immutable)
was (Author: thatran):
You can workaround the problem by updating the bad "null" value to a "good"
null value using
update set =null where =;
but you'll still see the NPE until the sstable containing the "bad" null value
is compacted with the sstable containing the "good" null value.
> NullPointerException when dumping sstable with null value for timestamp column
> --
>
> Key: CASSANDRA-14200
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14200
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Simon Zhou
>Assignee: Simon Zhou
>Priority: Normal
> Fix For: 3.0.x
>
>
> We have an sstable whose schema has a column of type timestamp and it's not
> part of primary key. When dumping the sstable using sstabledump there is NPE
> like this:
> {code:java}
> Exception in thread "main" java.lang.NullPointerException
> at java.util.Calendar.setTime(Calendar.java:1770)
> at java.text.SimpleDateFormat.format(SimpleDateFormat.java:943)
> at java.text.SimpleDateFormat.format(SimpleDateFormat.java:936)
> at java.text.DateFormat.format(DateFormat.java:345)
> at
> org.apache.cassandra.db.marshal.TimestampType.toJSONString(TimestampType.java:93)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeCell(JsonTransformer.java:442)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeColumnData(JsonTransformer.java:376)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeRow(JsonTransformer.java:280)
> at
> org.apache.cassandra.tools.JsonTransformer.serializePartition(JsonTransformer.java:215)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at org.apache.cassandra.tools.JsonTransformer.toJson(JsonTransformer.java:104)
> at org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:242){code}
> The reason is that we use a null Date when there is no value for this column:
> {code}
> public Date deserialize(ByteBuffer bytes)
> {
> return bytes.remaining() == 0 ? null : new
> Date(ByteBufferUtil.toLong(bytes));
> }
> {code}
> It seems that we should not deserialize columns with null values.
--
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-15790) EmptyType doesn't override writeValue so could attempt to write bytes when expected not to
[
https://issues.apache.org/jira/browse/CASSANDRA-15790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108734#comment-17108734
]
David Capwell edited comment on CASSANDRA-15790 at 5/15/20, 11:08 PM:
--
3.11 is failing and 2 are CQLSH tests, one couldn't connect to the server...
this all looks unrelated to this patch.
was (Author: dcapwell):
3.11 is failing and 2 are CQLSH tests, one couldn't connect to the server...
> EmptyType doesn't override writeValue so could attempt to write bytes when
> expected not to
> --
>
> Key: CASSANDRA-15790
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15790
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-alpha
>
>
> EmptyType.writeValues is defined here
> https://github.com/apache/cassandra/blob/e394dc0bb32f612a476269010930c617dd1ed3cb/src/java/org/apache/cassandra/db/marshal/AbstractType.java#L407-L414
> {code}
> public void writeValue(ByteBuffer value, DataOutputPlus out) throws
> IOException
> {
> assert value.hasRemaining();
> if (valueLengthIfFixed() >= 0)
> out.write(value);
> else
> ByteBufferUtil.writeWithVIntLength(value, out);
> }
> {code}
> This is fine when the value is empty as the write of empty no-ops (the
> readValue also noops since the length is 0), but if the value is not empty
> (possible during upgrades or random bugs) then this could silently cause
> corruption; ideally this should throw a exception if the ByteBuffer has data.
> This was called from
> org.apache.cassandra.db.rows.BufferCell.Serializer#serialize, here we check
> to see if data is present or not and update the flags. If data is present
> then and only then do we call type.writeValue (which requires bytes is not
> empty). The problem is that EmptyType never expects writes to happen, but it
> still writes them; and does not read them (since it says it is fixed length
> of 0, so does read(buffer, 0)).
--
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-15790) EmptyType doesn't override writeValue so could attempt to write bytes when expected not to
[
https://issues.apache.org/jira/browse/CASSANDRA-15790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108734#comment-17108734
]
David Capwell commented on CASSANDRA-15790:
---
3.11 is failing and 2 are CQLSH tests, one couldn't connect to the server...
> EmptyType doesn't override writeValue so could attempt to write bytes when
> expected not to
> --
>
> Key: CASSANDRA-15790
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15790
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-alpha
>
>
> EmptyType.writeValues is defined here
> https://github.com/apache/cassandra/blob/e394dc0bb32f612a476269010930c617dd1ed3cb/src/java/org/apache/cassandra/db/marshal/AbstractType.java#L407-L414
> {code}
> public void writeValue(ByteBuffer value, DataOutputPlus out) throws
> IOException
> {
> assert value.hasRemaining();
> if (valueLengthIfFixed() >= 0)
> out.write(value);
> else
> ByteBufferUtil.writeWithVIntLength(value, out);
> }
> {code}
> This is fine when the value is empty as the write of empty no-ops (the
> readValue also noops since the length is 0), but if the value is not empty
> (possible during upgrades or random bugs) then this could silently cause
> corruption; ideally this should throw a exception if the ByteBuffer has data.
> This was called from
> org.apache.cassandra.db.rows.BufferCell.Serializer#serialize, here we check
> to see if data is present or not and update the flags. If data is present
> then and only then do we call type.writeValue (which requires bytes is not
> empty). The problem is that EmptyType never expects writes to happen, but it
> still writes them; and does not read them (since it says it is fixed length
> of 0, so does read(buffer, 0)).
--
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-15816) Transports are stopped in the wrong order
Jeff Jirsa created CASSANDRA-15816: -- Summary: Transports are stopped in the wrong order Key: CASSANDRA-15816 URL: https://issues.apache.org/jira/browse/CASSANDRA-15816 Project: Cassandra Issue Type: Bug Components: Messaging/Internode Reporter: Jeff Jirsa Stopping gossip while native is running is almost always wrong, change the order of shutdown and log a warning when done manually -- 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-15817) Prevent repair from overrunning compaction
Jeff Jirsa created CASSANDRA-15817: -- Summary: Prevent repair from overrunning compaction Key: CASSANDRA-15817 URL: https://issues.apache.org/jira/browse/CASSANDRA-15817 Project: Cassandra Issue Type: Bug Components: Consistency/Repair Reporter: Jeff Jirsa Repair can run and stream faster than a host can compact. At some point, if a host is sufficiently out of sync, or compaction is especially expensive, it makes sense to intentionally block repair so that compaction can catch up -- 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-15817) Prevent repair from overrunning compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-15817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa reassigned CASSANDRA-15817: -- Bug Category: Parent values: Degradation(12984)Level 1 values: Resource Management(12995) Complexity: Low Hanging Fruit Discovered By: User Report Severity: Low Source Control Link: https://github.com/apache/cassandra/pull/592 Assignee: Jeff Jirsa > Prevent repair from overrunning compaction > -- > > Key: CASSANDRA-15817 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15817 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Jeff Jirsa >Assignee: Jeff Jirsa >Priority: Low > Time Spent: 10m > Remaining Estimate: 0h > > Repair can run and stream faster than a host can compact. At some point, if a > host is sufficiently out of sync, or compaction is especially expensive, it > makes sense to intentionally block repair so that compaction can catch up -- 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-15817) Prevent repair from overrunning compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-15817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa updated CASSANDRA-15817: --- Status: Open (was: Triage Needed) > Prevent repair from overrunning compaction > -- > > Key: CASSANDRA-15817 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15817 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Jeff Jirsa >Assignee: Jeff Jirsa >Priority: Low > Time Spent: 10m > Remaining Estimate: 0h > > Repair can run and stream faster than a host can compact. At some point, if a > host is sufficiently out of sync, or compaction is especially expensive, it > makes sense to intentionally block repair so that compaction can catch up -- 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-15817) Prevent repair from overrunning compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-15817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa updated CASSANDRA-15817: --- Test and Documentation Plan: Tested by hand; disabled by default (via very large value) and not included in cassandra.yaml or NEWS.txt Status: Patch Available (was: In Progress) > Prevent repair from overrunning compaction > -- > > Key: CASSANDRA-15817 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15817 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Jeff Jirsa >Assignee: Jeff Jirsa >Priority: Low > Time Spent: 10m > Remaining Estimate: 0h > > Repair can run and stream faster than a host can compact. At some point, if a > host is sufficiently out of sync, or compaction is especially expensive, it > makes sense to intentionally block repair so that compaction can catch up -- 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-15816) Transports are stopped in the wrong order
[ https://issues.apache.org/jira/browse/CASSANDRA-15816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa updated CASSANDRA-15816: --- Bug Category: Parent values: Availability(12983) Complexity: Low Hanging Fruit Discovered By: User Report Severity: Low Assignee: Jeff Jirsa Status: Open (was: Triage Needed) > Transports are stopped in the wrong order > - > > Key: CASSANDRA-15816 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15816 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode >Reporter: Jeff Jirsa >Assignee: Jeff Jirsa >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > Stopping gossip while native is running is almost always wrong, change the > order of shutdown and log a warning when done manually -- 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-15816) Transports are stopped in the wrong order
[ https://issues.apache.org/jira/browse/CASSANDRA-15816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa updated CASSANDRA-15816: --- Test and Documentation Plan: N/A. Status: Patch Available (was: In Progress) > Transports are stopped in the wrong order > - > > Key: CASSANDRA-15816 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15816 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode >Reporter: Jeff Jirsa >Assignee: Jeff Jirsa >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > Stopping gossip while native is running is almost always wrong, change the > order of shutdown and log a warning when done manually -- 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-15816) Transports are stopped in the wrong order
[ https://issues.apache.org/jira/browse/CASSANDRA-15816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa updated CASSANDRA-15816: --- Source Control Link: https://github.com/apache/cassandra/pull/593 > Transports are stopped in the wrong order > - > > Key: CASSANDRA-15816 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15816 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode >Reporter: Jeff Jirsa >Assignee: Jeff Jirsa >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > Stopping gossip while native is running is almost always wrong, change the > order of shutdown and log a warning when done manually -- 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-15817) Prevent repair from overrunning compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-15817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15817: -- Reviewers: David Capwell, David Capwell (was: David Capwell) David Capwell, David Capwell Status: Review In Progress (was: Patch Available) LGTM +1 I ran the unit test and jvm-dtests, all passed. > Prevent repair from overrunning compaction > -- > > Key: CASSANDRA-15817 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15817 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Jeff Jirsa >Assignee: Jeff Jirsa >Priority: Low > Time Spent: 10m > Remaining Estimate: 0h > > Repair can run and stream faster than a host can compact. At some point, if a > host is sufficiently out of sync, or compaction is especially expensive, it > makes sense to intentionally block repair so that compaction can catch up -- 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
