Re: [PR] Cassandra 18852: Make bulk writer resilient to cluster resize events [cassandra-analytics]
arjunashok commented on code in PR #17:
URL:
https://github.com/apache/cassandra-analytics/pull/17#discussion_r1422019437
##
cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/bulkwriter/token/ConsistencyLevel.java:
##
@@ -59,42 +87,34 @@ public boolean isLocal()
}
@Override
-public boolean checkConsistency(Collection failedInsts,
-ReplicationFactor
replicationFactor,
+public boolean checkConsistency(Set writeReplicas,
+Set pendingReplicas,
+Set replacementInstances,
+Set blockedInstances,
+Set failedInstanceIps,
String localDC)
{
-
Preconditions.checkArgument(replicationFactor.getReplicationStrategy() !=
ReplicationFactor.ReplicationStrategy.SimpleStrategy,
-"EACH_QUORUM doesn't make sense
for SimpleStrategy keyspaces");
-
-for (String datacenter :
replicationFactor.getOptions().keySet())
-{
-int rf = replicationFactor.getOptions().get(datacenter);
-if (failedInsts.stream()
- .filter(instance ->
instance.getDataCenter().matches(datacenter))
- .count() > (rf - (rf / 2 + 1)))
-{
-return false;
-}
-}
-
-return true;
+return (failedInstanceIps.size() + blockedInstances.size()) <=
(writeReplicas.size() - (writeReplicas.size() / 2 + 1));
Review Comment:
Correct, the idea was to keep this class confined to CL validation
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
Re: [PR] Cassandra 18852: Make bulk writer resilient to cluster resize events [cassandra-analytics]
arjunashok commented on code in PR #17:
URL:
https://github.com/apache/cassandra-analytics/pull/17#discussion_r1422015166
##
cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/bulkwriter/CommitCoordinator.java:
##
@@ -128,61 +128,51 @@ private Stream>
commit(Map> uploadRanges)
{
-if (cluster.instanceIsAvailable(instance))
Review Comment:
The expectation is for the instance to be available or transitioning at this
point. If the instance does happen to be down, it should result in a commit
failure, which is further evaluated against the CL requirements.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
Re: [PR] Cassandra 18852: Make bulk writer resilient to cluster resize events [cassandra-analytics]
arjunashok commented on code in PR #17:
URL:
https://github.com/apache/cassandra-analytics/pull/17#discussion_r1422010350
##
cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/bulkwriter/TableSchema.java:
##
@@ -94,6 +95,12 @@ public Object[] normalize(Object[] row)
}
public Object[] getKeyColumns(Object[] allColumns)
+{
+return getKeyColumns(allColumns, keyFieldPositions);
+}
+
+@NotNull
+public static Object[] getKeyColumns(Object[] allColumns, List
keyFieldPositions)
Review Comment:
Testing only. Added
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18688) Limit Java runtime in 5.0 to JDK 11 and 17 in scripts; add a flag to opt out of that
[ https://issues.apache.org/jira/browse/CASSANDRA-18688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795192#comment-17795192 ] Berenguer Blasi commented on CASSANDRA-18688: - +1 go ahead. Thanks [~skokoori] for all your work > Limit Java runtime in 5.0 to JDK 11 and 17 in scripts; add a flag to opt out > of that > > > Key: CASSANDRA-18688 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18688 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: shylaja kokoori >Priority: Normal > Fix For: 5.0.x, 5.x > > Time Spent: 3.5h > Remaining Estimate: 0h > > Currently, we limit our users from building with non-default Java versions in > build.xml. > They can easily hack build.xml for test purposes with different versions. > Cassandra–5.0 will be run on JDK11 and JDK17, but on startup, we do not limit > people to those two, but only to everything >= 11. We should also put an > upper limit of 17 in our Cassandra startup scripts. We can also add a flag to > opt-out if someone wants to test with newer versions. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
Re: [PR] Cassandra 18852: Make bulk writer resilient to cluster resize events [cassandra-analytics]
arjunashok commented on code in PR #17:
URL:
https://github.com/apache/cassandra-analytics/pull/17#discussion_r1422005002
##
cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/bulkwriter/CassandraClusterInfo.java:
##
@@ -339,140 +336,190 @@ public String getLowestCassandraVersion()
return cassandraVersion;
}
-public String getVersionFromFeature()
+@Override
+public Map getInstanceAvailability()
{
-return null;
+TokenRangeMapping mapping = getTokenRangeMapping(true);
+Map result =
+mapping.getReplicaMetadata()
+ .stream()
+ .map(RingInstance::new)
+ .collect(Collectors.toMap(Function.identity(),
this::determineInstanceAvailability));
+
+if (LOGGER.isDebugEnabled())
+{
+result.forEach((inst, avail) -> LOGGER.debug("Instance {} has
availability {}", inst, avail));
+}
+return result;
}
-protected List getAllNodeSettings()
+private InstanceAvailability determineInstanceAvailability(RingInstance
instance)
{
-List allNodeSettings =
FutureUtils.bestEffortGet(allNodeSettingFutures,
-
conf.getSidecarRequestMaxRetryDelayInSeconds(),
-
TimeUnit.SECONDS);
-
-if (allNodeSettings.isEmpty())
+if (!instanceIsUp(instance.getRingInstance()))
{
-throw new RuntimeException(String.format("Unable to determine the
node settings. 0/%d instances available.",
-
allNodeSettingFutures.size()));
+return InstanceAvailability.UNAVAILABLE_DOWN;
}
-else if (allNodeSettings.size() < allNodeSettingFutures.size())
+if (instanceIsBlocked(instance))
{
-LOGGER.warn("{}/{} instances were used to determine the node
settings",
-allNodeSettings.size(), allNodeSettingFutures.size());
+return InstanceAvailability.UNAVAILABLE_BLOCKED;
}
-
-return allNodeSettings;
-}
-
-public String getVersionFromSidecar()
-{
-NodeSettings nodeSettings = this.nodeSettings.get();
-if (nodeSettings != null)
+if (instanceIsNormal(instance.getRingInstance()) ||
+instanceIsTransitioning(instance.getRingInstance()) ||
+instanceIsBeingReplaced(instance.getRingInstance()))
{
-return nodeSettings.releaseVersion();
+return InstanceAvailability.AVAILABLE;
}
-return getLowestVersion(getAllNodeSettings());
+LOGGER.info("No valid state found for instance {}", instance);
+// If it's not one of the above, it's inherently INVALID.
+return InstanceAvailability.INVALID_STATE;
}
-protected RingResponse getRingResponse()
+private TokenRangeMapping getTokenRangeReplicas()
{
-RingResponse currentRingResponse = ringResponse;
-if (currentRingResponse != null)
+Map> writeReplicasByDC;
+Map> pendingReplicasByDC;
+List replicaMetadata;
+Set blockedInstances;
+Set replacementInstances;
+Multimap> tokenRangesByInstance;
+try
{
-return currentRingResponse;
-}
+TokenRangeReplicasResponse response =
getTokenRangesAndReplicaSets();
+replicaMetadata = response.replicaMetadata();
-synchronized (this)
-{
-if (ringResponse == null)
+tokenRangesByInstance =
getTokenRangesByInstance(response.writeReplicas(), response.replicaMetadata());
+LOGGER.info("Retrieved token ranges for {} instances from write
replica set ",
+tokenRangesByInstance.size());
+
+replacementInstances = response.replicaMetadata()
+ .stream()
+ .filter(m ->
m.state().equalsIgnoreCase(InstanceState.REPLACING.toString()))
+ .map(RingInstance::new)
+ .collect(Collectors.toSet());
+
+blockedInstances = response.replicaMetadata().stream()
+ .map(RingInstance::new)
+ .filter(this::instanceIsBlocked)
+ .collect(Collectors.toSet());
+
+Set blockedIps = blockedInstances.stream().map(i ->
i.getRingInstance().address())
+
.collect(Collectors.toSet());
+
+// Each token range has hosts by DC. We collate them across all
ranges into all hosts by DC
+writeReplicasByDC = response.writeReplicas()
+.stream()
+
Re: [PR] Cassandra 18852: Make bulk writer resilient to cluster resize events [cassandra-analytics]
arjunashok commented on code in PR #17:
URL:
https://github.com/apache/cassandra-analytics/pull/17#discussion_r1422004520
##
cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/bulkwriter/CassandraClusterInfo.java:
##
@@ -339,140 +336,190 @@ public String getLowestCassandraVersion()
return cassandraVersion;
}
-public String getVersionFromFeature()
+@Override
+public Map getInstanceAvailability()
{
-return null;
+TokenRangeMapping mapping = getTokenRangeMapping(true);
+Map result =
+mapping.getReplicaMetadata()
+ .stream()
+ .map(RingInstance::new)
+ .collect(Collectors.toMap(Function.identity(),
this::determineInstanceAvailability));
+
+if (LOGGER.isDebugEnabled())
+{
+result.forEach((inst, avail) -> LOGGER.debug("Instance {} has
availability {}", inst, avail));
+}
+return result;
}
-protected List getAllNodeSettings()
+private InstanceAvailability determineInstanceAvailability(RingInstance
instance)
{
-List allNodeSettings =
FutureUtils.bestEffortGet(allNodeSettingFutures,
-
conf.getSidecarRequestMaxRetryDelayInSeconds(),
-
TimeUnit.SECONDS);
-
-if (allNodeSettings.isEmpty())
+if (!instanceIsUp(instance.getRingInstance()))
{
-throw new RuntimeException(String.format("Unable to determine the
node settings. 0/%d instances available.",
-
allNodeSettingFutures.size()));
+return InstanceAvailability.UNAVAILABLE_DOWN;
}
-else if (allNodeSettings.size() < allNodeSettingFutures.size())
+if (instanceIsBlocked(instance))
{
-LOGGER.warn("{}/{} instances were used to determine the node
settings",
-allNodeSettings.size(), allNodeSettingFutures.size());
+return InstanceAvailability.UNAVAILABLE_BLOCKED;
}
-
-return allNodeSettings;
-}
-
-public String getVersionFromSidecar()
-{
-NodeSettings nodeSettings = this.nodeSettings.get();
-if (nodeSettings != null)
+if (instanceIsNormal(instance.getRingInstance()) ||
+instanceIsTransitioning(instance.getRingInstance()) ||
+instanceIsBeingReplaced(instance.getRingInstance()))
{
-return nodeSettings.releaseVersion();
+return InstanceAvailability.AVAILABLE;
}
-return getLowestVersion(getAllNodeSettings());
+LOGGER.info("No valid state found for instance {}", instance);
+// If it's not one of the above, it's inherently INVALID.
+return InstanceAvailability.INVALID_STATE;
}
-protected RingResponse getRingResponse()
+private TokenRangeMapping getTokenRangeReplicas()
{
-RingResponse currentRingResponse = ringResponse;
-if (currentRingResponse != null)
+Map> writeReplicasByDC;
+Map> pendingReplicasByDC;
+List replicaMetadata;
+Set blockedInstances;
+Set replacementInstances;
+Multimap> tokenRangesByInstance;
+try
{
-return currentRingResponse;
-}
+TokenRangeReplicasResponse response =
getTokenRangesAndReplicaSets();
+replicaMetadata = response.replicaMetadata();
-synchronized (this)
-{
-if (ringResponse == null)
+tokenRangesByInstance =
getTokenRangesByInstance(response.writeReplicas(), response.replicaMetadata());
+LOGGER.info("Retrieved token ranges for {} instances from write
replica set ",
+tokenRangesByInstance.size());
+
+replacementInstances = response.replicaMetadata()
+ .stream()
+ .filter(m ->
m.state().equalsIgnoreCase(InstanceState.REPLACING.toString()))
+ .map(RingInstance::new)
+ .collect(Collectors.toSet());
+
+blockedInstances = response.replicaMetadata().stream()
+ .map(RingInstance::new)
+ .filter(this::instanceIsBlocked)
+ .collect(Collectors.toSet());
+
+Set blockedIps = blockedInstances.stream().map(i ->
i.getRingInstance().address())
+
.collect(Collectors.toSet());
+
+// Each token range has hosts by DC. We collate them across all
ranges into all hosts by DC
+writeReplicasByDC = response.writeReplicas()
+.stream()
+
[jira] [Commented] (CASSANDRA-19001) Check whether the startup warnings for unknown modules represent a legit problem or cosmetic issue
[
https://issues.apache.org/jira/browse/CASSANDRA-19001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795188#comment-17795188
]
Berenguer Blasi commented on CASSANDRA-19001:
-
I think, gut feeling, CI env was really unstable given the large number of
failures that look related to env so that's probably the cause. I checked the
code/tests and they lgtm, I tested and got greens, you checked things and they
lgty, you tested and you got greens. I don't think we have any other threads to
start pulling. But if you have some idea of further things to look a ticket can
be opened but what to look for?
> Check whether the startup warnings for unknown modules represent a legit
> problem or cosmetic issue
> --
>
> Key: CASSANDRA-19001
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19001
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc, 5.0.x, 5.x
>
>
> During the 5.0 alpha 2 release
> [vote|https://lists.apache.org/thread/lt3x0obr5cpbcydf5490pj6b2q0mz5zr],
> [~paulo] raised the following concerns:
> {code:java}
> Launched a tarball-based 5.0-alpha2 container on top of
> "eclipse-temurin:17-jre-focal" and the server starts up fine, can run
> nodetool and cqlsh.
> I got these seemingly harmless JDK17 warnings during startup and when
> running nodetool (no warnings on JDK11):
> WARNING: Unknown module: jdk.attach specified to --add-exports
> WARNING: Unknown module: jdk.compiler specified to --add-exports
> WARNING: Unknown module: jdk.compiler specified to --add-opens
> WARNING: A terminally deprecated method in java.lang.System has been called
> WARNING: System::setSecurityManager has been called by
> org.apache.cassandra.security.ThreadAwareSecurityManager
> (file:/opt/cassandra/lib/apache-cassandra-5.0-alpha2-SNAPSHOT.jar)
> WARNING: Please consider reporting this to the maintainers of
> org.apache.cassandra.security.ThreadAwareSecurityManager
> WARNING: System::setSecurityManager will be removed in a future release
> Anybody knows if these warnings are legit/expected ? We can create
> follow-up tickets if needed.
> $ java --version
> openjdk 17.0.9 2023-10-17
> OpenJDK Runtime Environment Temurin-17.0.9+9 (build 17.0.9+9)
> OpenJDK 64-Bit Server VM Temurin-17.0.9+9 (build 17.0.9+9, mixed mode,
> sharing)
> {code}
> {code:java}
> Clarification: - When running nodetool only the "Unknown module" warnings
> show up. All warnings show up during startup.{code}
> We need to verify whether this presents a real problem in the features where
> those modules are expected to be used, or if it is a false alarm.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19150) Make alignment of values in rows in CQLSH configurable.
[
https://issues.apache.org/jira/browse/CASSANDRA-19150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795158#comment-17795158
]
Brad Schoening commented on CASSANDRA-19150:
Thanks, the example is very helpful. I wonder what other front ends such as
Intellij or psql use for tabular output. I tried this in Excel, and when
entering text and numeric data, it auto aligned the text right and the numbers
left.
Would changing the default to left aligned for numbers only, and right align
text work well?
> Make alignment of values in rows in CQLSH configurable.
> ---
>
> Key: CASSANDRA-19150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19150
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Attachments: Screenshot 2023-12-04 at 00.38.16.png, Screenshot
> 2023-12-09 at 16.58.25.png, signature.asc
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We need to make this
> https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1101
> configurable so values in columns are either all on left or on right side of
> the column (basically change col.rjust to col.ljust).
> By default, it would be like it is now but there would be configuration
> property in cqlsh for that as well as a corresponding CQLSH command
> (optional), something like
> {code}
> ALIGNMENT LEFT|RIGHT
> {code}
> cc [~bschoeni]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19150) Make alignment of values in rows in CQLSH configurable.
[
https://issues.apache.org/jira/browse/CASSANDRA-19150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795158#comment-17795158
]
Brad Schoening edited comment on CASSANDRA-19150 at 12/11/23 4:26 AM:
--
[~mmuzaf] Thanks, the example is very helpful. I wonder what other front ends
such as Intellij or psql use for tabular output. I tried this in Excel, and
when entering text and numeric data, it auto aligned the text right and the
numbers left.
Would changing the default to left aligned for numbers only, and right align
text work well?
was (Author: bschoeni):
Thanks, the example is very helpful. I wonder what other front ends such as
Intellij or psql use for tabular output. I tried this in Excel, and when
entering text and numeric data, it auto aligned the text right and the numbers
left.
Would changing the default to left aligned for numbers only, and right align
text work well?
> Make alignment of values in rows in CQLSH configurable.
> ---
>
> Key: CASSANDRA-19150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19150
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Attachments: Screenshot 2023-12-04 at 00.38.16.png, Screenshot
> 2023-12-09 at 16.58.25.png, signature.asc
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We need to make this
> https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1101
> configurable so values in columns are either all on left or on right side of
> the column (basically change col.rjust to col.ljust).
> By default, it would be like it is now but there would be configuration
> property in cqlsh for that as well as a corresponding CQLSH command
> (optional), something like
> {code}
> ALIGNMENT LEFT|RIGHT
> {code}
> cc [~bschoeni]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra-website) branch asf-staging updated (fcb0be4d -> 1a199654)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard fcb0be4d generate docs for 28519203 new 1a199654 generate docs for 28519203 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (fcb0be4d) \ N -- N -- N refs/heads/asf-staging (1a199654) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4883726 -> 4883726 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19126) Streaming appears to be incompatible with different storage_compatibility_mode settings
[
https://issues.apache.org/jira/browse/CASSANDRA-19126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795089#comment-17795089
]
Branimir Lambov commented on CASSANDRA-19126:
-
> Precise fix for this would be to use the same compatibility mode for bulk
> loader and the node.
While this would fix the test, it would not do anything about the underlying
problem. C* 5 nodes in different compatibility mode should be able to stream
with each other. One should at least be able to stream whole sstables from
legacy mode to current.
Current to legacy mode when CASSANDRA-19012 is done also makes sense, but it
might violate the downgradability promise while such data is not compacted. We
probably need a warning if current-format data is streamed to a node in legacy
mode (e.g. suggesting one does upgradesstables before downgrading below 5.0).
> Streaming appears to be incompatible with different
> storage_compatibility_mode settings
> ---
>
> Key: CASSANDRA-19126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19126
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming, Legacy/Streaming and Messaging,
> Messaging/Internode, Tool/bulk load
>Reporter: Branimir Lambov
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> In particular, SSTableLoader appears to be incompatible with
> storage_compatibility_mode: NONE, which manifests as a failure of
> {{org.apache.cassandra.distributed.test.SSTableLoaderEncryptionOptionsTest}}
> when the flag is turned on (found during CASSANDRA-18753 testing). Setting
> {{storage_compatibility_mode: NONE}} in the tool configuration yaml does not
> help (according to the docs, this setting is not picked up).
> This is likely a bigger problem as the acceptable streaming version for C* 5
> is 12 only in legacy mode and 13 only in none, i.e. two C* 5 nodes do not
> appear to be able to stream with each other if their setting for the
> compatibility mode is different.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19126) Streaming appears to be incompatible with different storage_compatibility_mode settings
[
https://issues.apache.org/jira/browse/CASSANDRA-19126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795089#comment-17795089
]
Branimir Lambov edited comment on CASSANDRA-19126 at 12/10/23 4:57 PM:
---
bq. Precise fix for this would be to use the same compatibility mode for bulk
loader and the node.
While this would fix the test, it would not do anything about the underlying
problem. C* 5 nodes in different compatibility mode should be able to stream
with each other. One should at least be able to stream whole sstables from
legacy mode to current.
Current to legacy mode when CASSANDRA-19012 is done also makes sense, but it
might violate the downgradability promise while such data is not compacted. We
probably need a warning if current-format data is streamed to a node in legacy
mode (e.g. suggesting one does upgradesstables before downgrading below 5.0).
was (Author: blambov):
> Precise fix for this would be to use the same compatibility mode for bulk
> loader and the node.
While this would fix the test, it would not do anything about the underlying
problem. C* 5 nodes in different compatibility mode should be able to stream
with each other. One should at least be able to stream whole sstables from
legacy mode to current.
Current to legacy mode when CASSANDRA-19012 is done also makes sense, but it
might violate the downgradability promise while such data is not compacted. We
probably need a warning if current-format data is streamed to a node in legacy
mode (e.g. suggesting one does upgradesstables before downgrading below 5.0).
> Streaming appears to be incompatible with different
> storage_compatibility_mode settings
> ---
>
> Key: CASSANDRA-19126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19126
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming, Legacy/Streaming and Messaging,
> Messaging/Internode, Tool/bulk load
>Reporter: Branimir Lambov
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> In particular, SSTableLoader appears to be incompatible with
> storage_compatibility_mode: NONE, which manifests as a failure of
> {{org.apache.cassandra.distributed.test.SSTableLoaderEncryptionOptionsTest}}
> when the flag is turned on (found during CASSANDRA-18753 testing). Setting
> {{storage_compatibility_mode: NONE}} in the tool configuration yaml does not
> help (according to the docs, this setting is not picked up).
> This is likely a bigger problem as the acceptable streaming version for C* 5
> is 12 only in legacy mode and 13 only in none, i.e. two C* 5 nodes do not
> appear to be able to stream with each other if their setting for the
> compatibility mode is different.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra-website) branch asf-staging updated (6ac64c09 -> fcb0be4d)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 6ac64c09 generate docs for 28519203 new fcb0be4d generate docs for 28519203 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (6ac64c09) \ N -- N -- N refs/heads/asf-staging (fcb0be4d) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4883726 -> 4883726 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
