[jira] [Created] (CASSANDRA-16752) Python dtest queries executed after restarting a node might fail
Andres de la Peña created CASSANDRA-16752:
-
Summary: Python dtest queries executed after restarting a node
might fail
Key: CASSANDRA-16752
URL: https://issues.apache.org/jira/browse/CASSANDRA-16752
Project: Cassandra
Issue Type: Bug
Components: Test/dtest/python
Reporter: Andres de la Peña
We have multiple dtest failures in queries with CL=ALL that are executed right
after restarting a node:
*
[test_14330|https://ci-cassandra.apache.org/job/Cassandra-4.0.0/26/testReport/dtest.consistency_test/TestConsistency/test_14330/]
*
[test_multiple_repair|https://ci-cassandra.apache.org/job/Cassandra-4.0.0/29/testReport/dtest.repair_tests.incremental_repair_test/TestIncRepair/test_multiple_repair/]
*
[test_multiple_repair(offheap)|https://ci-cassandra.apache.org/job/Cassandra-4.0.0/26/testReport/dtest-offheap.repair_tests.incremental_repair_test/TestIncRepair/test_multiple_repair/]
The error is a server-side failure telling that there aren't enough replicas
alive to achieve the required consistency level:
{code:java}
tools/assertions.py:182: in assert_all
res = session.execute(simple_query) if timeout is None else
session.execute(simple_query, timeout=timeout)
../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute
return self.execute_async(query, parameters, trace, custom_payload,
timeout, execution_profile, paging_state, host, execute_as).result()
...
E cassandra.Unavailable: Error from server: code=1000 [Unavailable
exception] message="Cannot achieve consistency level ALL" info={'consistency':
'ALL', 'required_replicas': 2, 'alive_replicas': 1}
{code}
The Jenkins failure in {{test_14330}} can be reproduced in the multiplexer,
although it requires many iterations:
*
[https://app.circleci.com/pipelines/github/adelapena/cassandra/600/workflows/2f1b7455-1217-4553-985a-a255fe98ba47/jobs/5784]
*
[https://app.circleci.com/pipelines/github/adelapena/cassandra/600/workflows/2f1b7455-1217-4553-985a-a255fe98ba47/jobs/5786]
As a hint, this same test [survives the
multiplexer|https://app.circleci.com/pipelines/github/adelapena/cassandra/605/workflows/aba5e7a6-c988-40d9-ab56-7848e711b5e1]
if we add [a short
sleep|https://github.com/adelapena/cassandra-dtest/commit/28ca11bf31db4c836e9c34500d18cbb9316e3cca]
right after restarting the node.
I think that the reason for the failure is that CCM is no properly waiting for
the propagation of the node status. So, the session uses a not-restarted nodes
to run the query with CL=ALL before that node actually sees the restarted node.
The parameter {{wait_other_notice}} in {{node.start}} should guarantee that
this doesn't happen, but I suspect that it isn't working as expected. When
using the {{wait_other_notice}} option on node start, the
[{{node.watch_log_for_alive}}|https://github.com/riptano/ccm/blob/358c06781c4a8b85dcfca49449232b7405dacc0c/ccmlib/node.py#L657-L664]
function looks for the regexp {{%s.* now UP}} in the logs of the other nodes,
to ensure that they consider that node as up. However, that expression is
matched by two different log entries emitted on log restart:
{code:java}
Node /127.0.0.2:7000 has restarted, now UP
...
Node /127.0.0.2:7000 is now UP
{code}
The first message is emitted by
[{{Gossiper.handleMajorStateChange}}|https://github.com/apache/cassandra/blob/cassandra-4.0.0/src/java/org/apache/cassandra/gms/Gossiper.java#L1313],
while the second message is emitted by
[{{Gossiper.realMarkAlive}}|https://github.com/apache/cassandra/blob/cassandra-4.0.0/src/java/org/apache/cassandra/gms/Gossiper.java#L1263].
I think that we need to wait for the second one, while CCM is waiting only for
the first one.
Indeed, we can easily reproduce the failure in any of the affected dtests by
adding a sleep at the beginning of {{Gossiper.realMarkAlive}}. We can get
around the failure if we manually modify the test to wait for the right log
message, as it's done
[here|https://github.com/adelapena/cassandra-dtest/commit/7355be7dd94c91c44b78bd2ccfa1c731a00d6a63].
With that wait the test [survives the multiplexer
rounds|https://app.circleci.com/pipelines/github/adelapena/cassandra/605/workflows/6ec189fc-4701-4a27-a7af-382a6c53dd0d].
This problem seems quite unlikely to happen since the time window is very
short, but we have seen it in CI and it affects multiple Python dtests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16735) Adding columns via ALTER TABLE can generate corrupt sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-16735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-16735: Status: Ready to Commit (was: Review In Progress) LGTM +1 > Adding columns via ALTER TABLE can generate corrupt sstables > > > Key: CASSANDRA-16735 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16735 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair, Local/SSTable >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-rc2, 3.0.x, 3.11.x, 4.0-rc > > > This is similar to CASSANDRA-13004 and was caused by CASSANDRA-15899 > Basically the column placeholders introduced in 15899 can get read-repaired > in to the memtable and later flushed to disk and in some cases this can > conflict with the actual column (if the actual column is a collection for > example) and cause CorruptSSTableExceptions. > Fix is probably to just revert 15899, at least until if and when we find a > solution that we can rely on. Will post that + test next week. -- 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-16735) Adding columns via ALTER TABLE can generate corrupt sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-16735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-16735: Reviewers: Alex Petrov, Sam Tunnicliffe, Sam Tunnicliffe (was: Alex Petrov, Sam Tunnicliffe) Alex Petrov, Sam Tunnicliffe, Sam Tunnicliffe (was: Alex Petrov, Sam Tunnicliffe) Status: Review In Progress (was: Patch Available) > Adding columns via ALTER TABLE can generate corrupt sstables > > > Key: CASSANDRA-16735 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16735 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair, Local/SSTable >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-rc2, 3.0.x, 3.11.x, 4.0-rc > > > This is similar to CASSANDRA-13004 and was caused by CASSANDRA-15899 > Basically the column placeholders introduced in 15899 can get read-repaired > in to the memtable and later flushed to disk and in some cases this can > conflict with the actual column (if the actual column is a collection for > example) and cause CorruptSSTableExceptions. > Fix is probably to just revert 15899, at least until if and when we find a > solution that we can rely on. Will post that + test next week. -- 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-16697) generate-idea-files taks unnecessarily builds the project
[
https://issues.apache.org/jira/browse/CASSANDRA-16697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16697:
Reviewers: Michael Semb Wever (was: Ekaterina Dimitrova, Michael Semb
Wever)
> generate-idea-files taks unnecessarily builds the project
> -
>
> Key: CASSANDRA-16697
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16697
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Labels: IDE
> Fix For: 3.0.25, 3.11.11, 4.0.1, 4.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is especially painful when the project cannot be built because we are in
> the middle of solving some merge conflicts, but we want to fetch and update
> dependencies. It seems be to be unnecessary to build the project or to do
> other checks when we just want to load the project into our IDE.
> From what I've tested, it is enough to limit dependencies of that task to:
> {{init,maven-ant-tasks-init,resolver-dist-lib,gen-cql3-grammar,generate-jflex-java,createVersionPropFile}}
--
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-16750) Flaky AlibabaCloudSnitchTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16750:
Status: Ready to Commit (was: Review In Progress)
> Flaky AlibabaCloudSnitchTest
>
>
> Key: CASSANDRA-16750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16750
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.x
>
>
> Flaky test
> Test error
> {noformat}
> Error Message
> Forked Java VM exited abnormally. Please note the time in the report does not
> reflect the time until the VM exit.
> Stacktrace
> junit.framework.AssertionFailedError: Forked Java VM exited abnormally.
> Please note the time in the report does not reflect the time until the VM
> exit.
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$30$\^eval\_$cu1$restOf/0x0008403db840.:program(:13)
> at
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:655)
> at
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:513)
> at
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:527)
> at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:456)
> at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:413)
> at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:409)
> at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:162)
> at
> java.scripting/javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
> Log error:
> {noformat}
> AlibabaCloudSnitchTest.BeforeFirstTest failure was
> ERROR [COMMIT-LOG-ALLOCATOR] 2021-06-05 00:41:36,750 Exiting due to error
> while processing commit log during initialization.
> java.lang.RuntimeException: Tried to hard link to file that does not exist
> build/test/cassandra/commitlog/CommitLog-7-1622853696662.log
> at
> org.apache.cassandra.io.util.FileUtils.createHardLink(FileUtils.java:184)
> at
> org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDC.createSegment(CommitLogSegmentManagerCDC.java:149)
>
[jira] [Commented] (CASSANDRA-16750) Flaky AlibabaCloudSnitchTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17365565#comment-17365565
]
Ekaterina Dimitrova commented on CASSANDRA-16750:
-
Good catch, +1. I believe this is a trick used also in other tests.
> Flaky AlibabaCloudSnitchTest
>
>
> Key: CASSANDRA-16750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16750
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.x
>
>
> Flaky test
> Test error
> {noformat}
> Error Message
> Forked Java VM exited abnormally. Please note the time in the report does not
> reflect the time until the VM exit.
> Stacktrace
> junit.framework.AssertionFailedError: Forked Java VM exited abnormally.
> Please note the time in the report does not reflect the time until the VM
> exit.
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$30$\^eval\_$cu1$restOf/0x0008403db840.:program(:13)
> at
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:655)
> at
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:513)
> at
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:527)
> at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:456)
> at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:413)
> at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:409)
> at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:162)
> at
> java.scripting/javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
> Log error:
> {noformat}
> AlibabaCloudSnitchTest.BeforeFirstTest failure was
> ERROR [COMMIT-LOG-ALLOCATOR] 2021-06-05 00:41:36,750 Exiting due to error
> while processing commit log during initialization.
> java.lang.RuntimeException: Tried to hard link to file that does not exist
> build/test/cassandra/commitlog/CommitLog-7-1622853696662.log
> at
> org.apache.cassandra.io.util.FileUtils.createHardLink(FileUtils.java:184)
> at
>
[jira] [Updated] (CASSANDRA-16750) Flaky AlibabaCloudSnitchTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16750:
Reviewers: Ekaterina Dimitrova, Ekaterina Dimitrova (was: Ekaterina
Dimitrova)
Ekaterina Dimitrova, Ekaterina Dimitrova
Status: Review In Progress (was: Patch Available)
> Flaky AlibabaCloudSnitchTest
>
>
> Key: CASSANDRA-16750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16750
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.x
>
>
> Flaky test
> Test error
> {noformat}
> Error Message
> Forked Java VM exited abnormally. Please note the time in the report does not
> reflect the time until the VM exit.
> Stacktrace
> junit.framework.AssertionFailedError: Forked Java VM exited abnormally.
> Please note the time in the report does not reflect the time until the VM
> exit.
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$30$\^eval\_$cu1$restOf/0x0008403db840.:program(:13)
> at
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:655)
> at
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:513)
> at
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:527)
> at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:456)
> at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:413)
> at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:409)
> at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:162)
> at
> java.scripting/javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
> Log error:
> {noformat}
> AlibabaCloudSnitchTest.BeforeFirstTest failure was
> ERROR [COMMIT-LOG-ALLOCATOR] 2021-06-05 00:41:36,750 Exiting due to error
> while processing commit log during initialization.
> java.lang.RuntimeException: Tried to hard link to file that does not exist
> build/test/cassandra/commitlog/CommitLog-7-1622853696662.log
> at
>
[jira] [Comment Edited] (CASSANDRA-7450) Make repair -pr work within a datacenter
[
https://issues.apache.org/jira/browse/CASSANDRA-7450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17365083#comment-17365083
]
Laurenceau Julien edited comment on CASSANDRA-7450 at 6/18/21, 2:46 PM:
Datastax documentation may need an update because it still states:
> {color:#1d1c1d}Additional guidance for {color}{{nodetool
> repair}}{color:#1d1c1d} options: Does not support the use of
> {color}{{-local}}{color:#1d1c1d} with the {color}{{-pr}}{color:#1d1c1d}
> option unless the datacenter nodes have all the data for all ranges{color}
[https://docs.datastax.com/en/cassandra-oss/3.x/cassandra/operations/opsRepairNodesManualRepair.html|https://docs.datastax.com/en/cassandra-oss/3.x/cassandra/operations/opsRepairNodesManualRepair.html?hl=repai]
Apache documentation is OK
was (Author: julienlau):
Datastax documentation may need an update because it still states:
> {color:#1d1c1d}Additional guidance for {color}{{nodetool
> repair}}{color:#1d1c1d} options: Does not support the use of
> {color}{{-local}}{color:#1d1c1d} with the {color}{{-pr}}{color:#1d1c1d}
> option unless the datacenter nodes have all the data for all ranges{color}
[https://docs.datastax.com/en/cassandra-oss/3.x/cassandra/operations/opsRepairNodesManualRepair.html|https://docs.datastax.com/en/cassandra-oss/3.x/cassandra/operations/opsRepairNodesManualRepair.html?hl=repai]
> Make repair -pr work within a datacenter
>
>
> Key: CASSANDRA-7450
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7450
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Streaming and Messaging
>Reporter: Sylvain Lebresne
>Assignee: Paulo Motta (Deprecated)
>Priority: Normal
> Labels: bootcamp, repair
> Fix For: 2.1.1
>
> Attachments: 2.1-CASSANDRA-7450-v1.txt, 2.1-CASSANDRA-7450-v2.txt,
> 7450-2.1-v3.txt
>
>
> As was noticed in CASSANDRA-7317, using '-pr' alongside '-local' for repair
> doesn't really work properly, and disabling the combination was definitively
> the right short time fix. However, the main goal of '-pr' is to make it easy
> to repair a full cluster without doing any duplication of work. Doing the
> same only within a data-center is obviously desirable.
> I think a reasonably simple solution would be modify the behavior of '-pr'
> when it's limited to only one DC. If applied to nodeX in dcY, instead of
> repairing only the "primary" range of nodeX for the whole ring, we'll repair
> that range but also all ranges that are "primary" for a node not in dcY and
> for which nodeX is the first node of dcY found in ring order. Basically we'll
> ensure that running 'repair -local -pr' on every nodes of a given DC will
> repair all ranges for the nodes of that DC without repairing the same range
> twice.
--
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-7450) Make repair -pr work within a datacenter
[
https://issues.apache.org/jira/browse/CASSANDRA-7450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17365083#comment-17365083
]
Laurenceau Julien edited comment on CASSANDRA-7450 at 6/18/21, 2:45 PM:
Datastax documentation may need an update because it still states:
> {color:#1d1c1d}Additional guidance for {color}{{nodetool
> repair}}{color:#1d1c1d} options: Does not support the use of
> {color}{{-local}}{color:#1d1c1d} with the {color}{{-pr}}{color:#1d1c1d}
> option unless the datacenter nodes have all the data for all ranges{color}
[https://docs.datastax.com/en/cassandra-oss/3.x/cassandra/operations/opsRepairNodesManualRepair.html|https://docs.datastax.com/en/cassandra-oss/3.x/cassandra/operations/opsRepairNodesManualRepair.html?hl=repai]
was (Author: julienlau):
Datastax documentation may need an update because it still states:
> {color:#1d1c1d}Additional guidance for {color}{{nodetool
> repair}}{color:#1d1c1d} options: Does not support the use of
> {color}{{-local}}{color:#1d1c1d} with the {color}{{-pr}}{color:#1d1c1d}
> option unless the datacenter nodes have all the data for all ranges{color}
https://docs.datastax.com/en/cassandra-oss/3.x/cassandra/operations/opsRepairNodesManualRepair.html?hl=repai
> Make repair -pr work within a datacenter
>
>
> Key: CASSANDRA-7450
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7450
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Streaming and Messaging
>Reporter: Sylvain Lebresne
>Assignee: Paulo Motta (Deprecated)
>Priority: Normal
> Labels: bootcamp, repair
> Fix For: 2.1.1
>
> Attachments: 2.1-CASSANDRA-7450-v1.txt, 2.1-CASSANDRA-7450-v2.txt,
> 7450-2.1-v3.txt
>
>
> As was noticed in CASSANDRA-7317, using '-pr' alongside '-local' for repair
> doesn't really work properly, and disabling the combination was definitively
> the right short time fix. However, the main goal of '-pr' is to make it easy
> to repair a full cluster without doing any duplication of work. Doing the
> same only within a data-center is obviously desirable.
> I think a reasonably simple solution would be modify the behavior of '-pr'
> when it's limited to only one DC. If applied to nodeX in dcY, instead of
> repairing only the "primary" range of nodeX for the whole ring, we'll repair
> that range but also all ranges that are "primary" for a node not in dcY and
> for which nodeX is the first node of dcY found in ring order. Basically we'll
> ensure that running 'repair -local -pr' on every nodes of a given DC will
> repair all ranges for the nodes of that DC without repairing the same range
> twice.
--
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-7450) Make repair -pr work within a datacenter
[
https://issues.apache.org/jira/browse/CASSANDRA-7450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17365083#comment-17365083
]
Laurenceau Julien edited comment on CASSANDRA-7450 at 6/18/21, 2:45 PM:
Datastax documentation may need an update because it still states:
> {color:#1d1c1d}Additional guidance for {color}{{nodetool
> repair}}{color:#1d1c1d} options: Does not support the use of
> {color}{{-local}}{color:#1d1c1d} with the {color}{{-pr}}{color:#1d1c1d}
> option unless the datacenter nodes have all the data for all ranges{color}
https://docs.datastax.com/en/cassandra-oss/3.x/cassandra/operations/opsRepairNodesManualRepair.html?hl=repai
was (Author: julienlau):
Datastax documentation may need an update because it still states:
> {color:#1d1c1d}Additional guidance for {color}{{nodetool
> repair}}{color:#1d1c1d} options: Does not support the use of
> {color}{{-local}}{color:#1d1c1d} with the {color}{{-pr}}{color:#1d1c1d}
> option unless the datacenter nodes have all the data for all ranges{color}
> Make repair -pr work within a datacenter
>
>
> Key: CASSANDRA-7450
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7450
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Streaming and Messaging
>Reporter: Sylvain Lebresne
>Assignee: Paulo Motta (Deprecated)
>Priority: Normal
> Labels: bootcamp, repair
> Fix For: 2.1.1
>
> Attachments: 2.1-CASSANDRA-7450-v1.txt, 2.1-CASSANDRA-7450-v2.txt,
> 7450-2.1-v3.txt
>
>
> As was noticed in CASSANDRA-7317, using '-pr' alongside '-local' for repair
> doesn't really work properly, and disabling the combination was definitively
> the right short time fix. However, the main goal of '-pr' is to make it easy
> to repair a full cluster without doing any duplication of work. Doing the
> same only within a data-center is obviously desirable.
> I think a reasonably simple solution would be modify the behavior of '-pr'
> when it's limited to only one DC. If applied to nodeX in dcY, instead of
> repairing only the "primary" range of nodeX for the whole ring, we'll repair
> that range but also all ranges that are "primary" for a node not in dcY and
> for which nodeX is the first node of dcY found in ring order. Basically we'll
> ensure that running 'repair -local -pr' on every nodes of a given DC will
> repair all ranges for the nodes of that DC without repairing the same range
> twice.
--
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-7450) Make repair -pr work within a datacenter
[
https://issues.apache.org/jira/browse/CASSANDRA-7450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17365083#comment-17365083
]
Laurenceau Julien edited comment on CASSANDRA-7450 at 6/18/21, 2:44 PM:
Datastax documentation may need an update because it still states:
> {color:#1d1c1d}Additional guidance for {color}{{nodetool
> repair}}{color:#1d1c1d} options: Does not support the use of
> {color}{{-local}}{color:#1d1c1d} with the {color}{{-pr}}{color:#1d1c1d}
> option unless the datacenter nodes have all the data for all ranges{color}
was (Author: julienlau):
It may be necessary to update the documentation which still states:
> {color:#1d1c1d}Additional guidance for {color}{{nodetool
> repair}}{color:#1d1c1d} options: Does not support the use of
> {color}{{-local}}{color:#1d1c1d} with the {color}{{-pr}}{color:#1d1c1d}
> option unless the datacenter nodes have all the data for all ranges{color}
> Make repair -pr work within a datacenter
>
>
> Key: CASSANDRA-7450
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7450
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Streaming and Messaging
>Reporter: Sylvain Lebresne
>Assignee: Paulo Motta (Deprecated)
>Priority: Normal
> Labels: bootcamp, repair
> Fix For: 2.1.1
>
> Attachments: 2.1-CASSANDRA-7450-v1.txt, 2.1-CASSANDRA-7450-v2.txt,
> 7450-2.1-v3.txt
>
>
> As was noticed in CASSANDRA-7317, using '-pr' alongside '-local' for repair
> doesn't really work properly, and disabling the combination was definitively
> the right short time fix. However, the main goal of '-pr' is to make it easy
> to repair a full cluster without doing any duplication of work. Doing the
> same only within a data-center is obviously desirable.
> I think a reasonably simple solution would be modify the behavior of '-pr'
> when it's limited to only one DC. If applied to nodeX in dcY, instead of
> repairing only the "primary" range of nodeX for the whole ring, we'll repair
> that range but also all ranges that are "primary" for a node not in dcY and
> for which nodeX is the first node of dcY found in ring order. Basically we'll
> ensure that running 'repair -local -pr' on every nodes of a given DC will
> repair all ranges for the nodes of that DC without repairing the same range
> twice.
--
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-16735) Adding columns via ALTER TABLE can generate corrupt sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-16735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17365536#comment-17365536 ] Ekaterina Dimitrova commented on CASSANDRA-16735: - Thank you for all your work [~marcuse]! :) I was wondering, should we really remove the _readWithSchemaDisagreement_ test? PS Indeed, sstableverify test is a known issue, not related to this patch > Adding columns via ALTER TABLE can generate corrupt sstables > > > Key: CASSANDRA-16735 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16735 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair, Local/SSTable >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-rc2, 3.0.x, 3.11.x, 4.0-rc > > > This is similar to CASSANDRA-13004 and was caused by CASSANDRA-15899 > Basically the column placeholders introduced in 15899 can get read-repaired > in to the memtable and later flushed to disk and in some cases this can > conflict with the actual column (if the actual column is a collection for > example) and cause CorruptSSTableExceptions. > Fix is probably to just revert 15899, at least until if and when we find a > solution that we can rely on. Will post that + test next week. -- 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-16751) Static column added in compact tables through Cassandra-stress tool
[
https://issues.apache.org/jira/browse/CASSANDRA-16751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16751:
Bug Category: Parent values: Correctness(12982)
Complexity: Normal
Component/s: Tool/stress
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> Static column added in compact tables through Cassandra-stress tool
> ---
>
> Key: CASSANDRA-16751
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16751
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/stress
>Reporter: Radha
>Priority: Normal
>
> I have Cassandra 3.11.9 installed on my setup. I used the Cassandra-stress
> tool to create data for my cluster.
> # cassandra-stress write n=800 -log file=/tmp/1 level=verbose -mode native
> cql3 user=cassandra password=cassandra -node nodeip
> I saw that two tables were created "counter1 and standard1".
> The "counter1" table had no data and also was created with the following
> configuration:
> cassandra@cqlsh> desc table keyspace1.counter1;
> cassandra@cqlsh> CREATE TABLE keyspace1.counter1 (
> key blob,
> column1 text,
> *"C0" counter static,*
> *"C1" counter static,*
> *"C2" counter static,*
> *"C3" counter static,*
> *"C4" counter static,*
> value counter,
> PRIMARY KEY (key, column1)
> ) *WITH COMPACT STORAGE*
> AND CLUSTERING ORDER BY (column1 ASC)
> AND bloom_filter_fp_chance = 0.01
> AND caching = \{'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = \{'enabled': 'false'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> Now if I try to create a similar schema manually with above-mentioned
> schema, I get the following error. InvalidRequest: Error from server:
> code=2200 [Invalid query] message="Static columns are not supported in
> COMPACT STORAGE tables"
>
> I further read more about this error and found that static columns cannot
> be used with COMPACT STORAGE tables.
> Here is the documentation for the same :
> 1.
> https://docs.datastax.com/en/cql-oss/3.3/cql/cql_using/useCompactStorage.html
> 2. https://programmersought.com/article/81431553936/
>
> I raised the same on dev as well as user Cassandra forum. I have got a reply
> from Benjamin Lerer that this is a bug and hence raising the JIRA.
> *Query details:*
> https://lists.apache.org/thread.html/rf9c74e8e3d431ff395f73677a616a9fcd70a46f3ea0500b71ca4d91d%40%3Cdev.cassandra.apache.org%3E
--
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-16751) Static column added in compact tables through Cassandra-stress tool
[
https://issues.apache.org/jira/browse/CASSANDRA-16751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radha updated CASSANDRA-16751:
--
Summary: Static column added in compact tables through Cassandra-stress
tool (was: Regarding static column added in compact tables through
Cassandra-stress tool)
> Static column added in compact tables through Cassandra-stress tool
> ---
>
> Key: CASSANDRA-16751
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16751
> Project: Cassandra
> Issue Type: Bug
>Reporter: Radha
>Priority: Normal
>
> I have Cassandra 3.11.9 installed on my setup. I used the Cassandra-stress
> tool to create data for my cluster.
> # cassandra-stress write n=800 -log file=/tmp/1 level=verbose -mode native
> cql3 user=cassandra password=cassandra -node nodeip
> I saw that two tables were created "counter1 and standard1".
> The "counter1" table had no data and also was created with the following
> configuration:
> cassandra@cqlsh> desc table keyspace1.counter1;
> cassandra@cqlsh> CREATE TABLE keyspace1.counter1 (
> key blob,
> column1 text,
> *"C0" counter static,*
> *"C1" counter static,*
> *"C2" counter static,*
> *"C3" counter static,*
> *"C4" counter static,*
> value counter,
> PRIMARY KEY (key, column1)
> ) *WITH COMPACT STORAGE*
> AND CLUSTERING ORDER BY (column1 ASC)
> AND bloom_filter_fp_chance = 0.01
> AND caching = \{'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = \{'enabled': 'false'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> Now if I try to create a similar schema manually with above-mentioned
> schema, I get the following error. InvalidRequest: Error from server:
> code=2200 [Invalid query] message="Static columns are not supported in
> COMPACT STORAGE tables"
>
> I further read more about this error and found that static columns cannot
> be used with COMPACT STORAGE tables.
> Here is the documentation for the same :
> 1.
> https://docs.datastax.com/en/cql-oss/3.3/cql/cql_using/useCompactStorage.html
> 2. https://programmersought.com/article/81431553936/
>
> I raised the same on dev as well as user Cassandra forum. I have got a reply
> from Benjamin Lerer that this is a bug and hence raising the JIRA.
> *Query details:*
> https://lists.apache.org/thread.html/rf9c74e8e3d431ff395f73677a616a9fcd70a46f3ea0500b71ca4d91d%40%3Cdev.cassandra.apache.org%3E
--
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-16733) Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16733:
---
Fix Version/s: (was: 4.0-rc)
(was: 3.11.x)
(was: 3.0.x)
4.0
3.11.11
3.0.25
Since Version: 3.0.16
Source Control Link:
https://github.com/apache/cassandra/commit/9b6dd382bdf4a71c06091736ff98cb1307ff0e97
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed into 3.0 at 9b6dd382bdf4a71c06091736ff98cb1307ff0e97 and merged into
3.11, 4.0.0, 4.0 and trunk
> Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
> --
>
> Key: CASSANDRA-16733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16733
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.0.25, 3.11.11, 4.0-rc2, 4.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> {{ALTER ... DROP COMPACT STORAGE}} statements have not been extensively
> tested and suffer from several issues like:
> * As COMPACT tables did not have primary key liveness there empty rows
> inserted AFTER the ALTER will be returned whereas the one inserted before
> the ALTER will not.
> * Also due to the lack of primary key liveness the amount of SSTables being
> read will increase resulting in slower queries (CASSANDRA-16675)
> * After DROP COMPACT it becomes possible to ALTER the table in a way that
> makes all the row disappears
> * There is a loss of functionality around null clustering when dropping
> compact storage (CASSANDRA-16069)
> To avoid running into those issues this ticket will introduce a new flag that
> allow operators to disable those statements on their clusters.
> see https://www.mail-archive.com/dev@cassandra.apache.org/msg16789.html
--
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-16733) Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17365500#comment-17365500
]
Benjamin Lerer commented on CASSANDRA-16733:
Thank you very much for your help with the test issues [~adelapena],
[~brandon.williams] and [~e.dimitrova].
> Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
> --
>
> Key: CASSANDRA-16733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16733
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-rc2, 3.0.x, 3.11.x, 4.0-rc
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> {{ALTER ... DROP COMPACT STORAGE}} statements have not been extensively
> tested and suffer from several issues like:
> * As COMPACT tables did not have primary key liveness there empty rows
> inserted AFTER the ALTER will be returned whereas the one inserted before
> the ALTER will not.
> * Also due to the lack of primary key liveness the amount of SSTables being
> read will increase resulting in slower queries (CASSANDRA-16675)
> * After DROP COMPACT it becomes possible to ALTER the table in a way that
> makes all the row disappears
> * There is a loss of functionality around null clustering when dropping
> compact storage (CASSANDRA-16069)
> To avoid running into those issues this ticket will introduce a new flag that
> allow operators to disable those statements on their clusters.
> see https://www.mail-archive.com/dev@cassandra.apache.org/msg16789.html
--
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-16733) Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16733:
---
Status: Ready to Commit (was: Review In Progress)
> Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
> --
>
> Key: CASSANDRA-16733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16733
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-rc2, 3.0.x, 3.11.x, 4.0-rc
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> {{ALTER ... DROP COMPACT STORAGE}} statements have not been extensively
> tested and suffer from several issues like:
> * As COMPACT tables did not have primary key liveness there empty rows
> inserted AFTER the ALTER will be returned whereas the one inserted before
> the ALTER will not.
> * Also due to the lack of primary key liveness the amount of SSTables being
> read will increase resulting in slower queries (CASSANDRA-16675)
> * After DROP COMPACT it becomes possible to ALTER the table in a way that
> makes all the row disappears
> * There is a loss of functionality around null clustering when dropping
> compact storage (CASSANDRA-16069)
> To avoid running into those issues this ticket will introduce a new flag that
> allow operators to disable those statements on their clusters.
> see https://www.mail-archive.com/dev@cassandra.apache.org/msg16789.html
--
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-dtest] branch trunk updated: Tests changes for CASSANDRA-16733
This is an automated email from the ASF dual-hosted git repository.
blerer pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git
The following commit(s) were added to refs/heads/trunk by this push:
new 7a73630 Tests changes for CASSANDRA-16733
7a73630 is described below
commit 7a73630c997c9c1265a1248aff3ddcf6a05e549d
Author: Benjamin Lerer
AuthorDate: Tue Jun 15 15:14:48 2021 +0200
Tests changes for CASSANDRA-16733
---
cql_test.py| 2 +-
upgrade_tests/drop_compact_storage_upgrade_test.py | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/cql_test.py b/cql_test.py
index 360df42..2bec188 100644
--- a/cql_test.py
+++ b/cql_test.py
@@ -732,7 +732,7 @@ class TestMiscellaneousCQL(CQLTester):
"""
cluster = self.cluster
-
+cluster.set_configuration_options({'enable_drop_compact_storage':
'true'})
cluster.populate(3).start()
node1, node2, node3 = cluster.nodelist()
diff --git a/upgrade_tests/drop_compact_storage_upgrade_test.py
b/upgrade_tests/drop_compact_storage_upgrade_test.py
index 338eb26..848aab9 100644
--- a/upgrade_tests/drop_compact_storage_upgrade_test.py
+++ b/upgrade_tests/drop_compact_storage_upgrade_test.py
@@ -70,6 +70,7 @@ class TestDropCompactStorage(Tester):
node.stop(wait_other_notice=False)
self.set_node_to_current_version(node)
+
node.set_configuration_options(values={'enable_drop_compact_storage': 'true'})
node.start(wait_for_binary_proto=True)
session = self.patient_exclusive_cql_connection(node1)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (b857aa1 -> 91c12bd)
This is an automated email from the ASF dual-hosted git repository. blerer pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from b857aa1 Merge branch 'cassandra-3.0' into cassandra-3.11 add 9b6dd38 Add flag to disable ALTER...DROP COMPACT STORAGE statements add 91c12bd Merge branch cassandra-3.0 into cassandra-3.11 No new revisions were added by this update. Summary of changes: CHANGES.txt | 1 + NEWS.txt | 16 ++-- conf/cassandra.yaml | 4 src/java/org/apache/cassandra/config/Config.java | 2 ++ .../org/apache/cassandra/config/DatabaseDescriptor.java | 11 +++ .../cassandra/cql3/statements/AlterTableStatement.java | 4 test/conf/cassandra.yaml | 1 + .../upgrade/CompactStorage2to3UpgradeTest.java | 7 ++- .../distributed/upgrade/DropCompactStorageTest.java | 4 +--- .../cassandra/distributed/upgrade/UpgradeTestBase.java | 10 ++ .../cassandra/cql3/validation/operations/AlterTest.java | 11 +++ 11 files changed, 65 insertions(+), 6 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0.0 updated (33414cc -> bdb7c3b)
This is an automated email from the ASF dual-hosted git repository. blerer pushed a change to branch cassandra-4.0.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 33414cc Merge branch 'cassandra-3.11' into cassandra-4.0.0 add 6ef3eaf update IDEA setup generation to mark test/conf as test resources add ba2538d Merge branch 'cassandra-3.0' into cassandra-3.11 add d54eff3 Remove full project building from the generate-idea-files ant target add b857aa1 Merge branch 'cassandra-3.0' into cassandra-3.11 add 9b6dd38 Add flag to disable ALTER...DROP COMPACT STORAGE statements add 91c12bd Merge branch cassandra-3.0 into cassandra-3.11 add bdb7c3b Merge branch cassandra-3.11 into cassandra-4.0.0 No new revisions were added by this update. Summary of changes: CHANGES.txt | 1 + NEWS.txt | 11 +-- conf/cassandra.yaml | 4 doc/source/configuration/cass_yaml_file.rst | 8 src/java/org/apache/cassandra/config/Config.java | 2 ++ src/java/org/apache/cassandra/config/DatabaseDescriptor.java | 11 +++ .../cassandra/cql3/statements/schema/AlterTableStatement.java | 5 - test/conf/cassandra.yaml | 1 + .../org/apache/cassandra/distributed/test/CountersTest.java | 2 +- .../distributed/upgrade/CompactStorageUpgradeTest.java| 2 +- .../apache/cassandra/distributed/upgrade/UpgradeTestBase.java | 10 ++ .../cassandra/cql3/validation/operations/AlterTest.java | 11 +++ 12 files changed, 63 insertions(+), 5 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch cassandra-4.0 into trunk
This is an automated email from the ASF dual-hosted git repository. blerer pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit c9130d454c4d43a05498c4fad7a1e3d434784791 Merge: 72dca97 d51f9d2 Author: Benjamin Lerer AuthorDate: Fri Jun 18 15:17:52 2021 +0200 Merge branch cassandra-4.0 into trunk CHANGES.txt | 1 + NEWS.txt | 11 +-- conf/cassandra.yaml | 4 doc/source/configuration/cass_yaml_file.rst | 8 src/java/org/apache/cassandra/config/Config.java | 2 ++ src/java/org/apache/cassandra/config/DatabaseDescriptor.java | 11 +++ .../cassandra/cql3/statements/schema/AlterTableStatement.java | 5 - test/conf/cassandra.yaml | 1 + .../org/apache/cassandra/distributed/test/CountersTest.java | 2 +- .../distributed/upgrade/CompactStorageUpgradeTest.java| 2 +- .../apache/cassandra/distributed/upgrade/UpgradeTestBase.java | 10 ++ .../cassandra/cql3/validation/operations/AlterTest.java | 11 +++ 12 files changed, 63 insertions(+), 5 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated (d54eff3 -> 9b6dd38)
This is an automated email from the ASF dual-hosted git repository. blerer pushed a change to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from d54eff3 Remove full project building from the generate-idea-files ant target add 9b6dd38 Add flag to disable ALTER...DROP COMPACT STORAGE statements No new revisions were added by this update. Summary of changes: CHANGES.txt | 1 + NEWS.txt| 13 - conf/cassandra.yaml | 4 src/java/org/apache/cassandra/config/Config.java| 2 ++ .../org/apache/cassandra/config/DatabaseDescriptor.java | 11 +++ .../cassandra/cql3/statements/AlterTableStatement.java | 4 test/conf/cassandra.yaml| 1 + .../distributed/upgrade/CompactStorage2to3UpgradeTest.java | 6 +- .../distributed/upgrade/DropCompactStorageTest.java | 2 +- .../cassandra/distributed/upgrade/UpgradeTestBase.java | 11 ++- .../cassandra/cql3/validation/operations/AlterTest.java | 11 +++ 11 files changed, 62 insertions(+), 4 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (72dca97 -> c9130d4)
This is an automated email from the ASF dual-hosted git repository. blerer pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 72dca97 Merge branch 'cassandra-4.0' into trunk add 9b6dd38 Add flag to disable ALTER...DROP COMPACT STORAGE statements add 91c12bd Merge branch cassandra-3.0 into cassandra-3.11 add bdb7c3b Merge branch cassandra-3.11 into cassandra-4.0.0 add d51f9d2 Merge branch cassandra-4.0.0 into cassandra-4.0 new c9130d4 Merge branch cassandra-4.0 into trunk The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt | 1 + NEWS.txt | 11 +-- conf/cassandra.yaml | 4 doc/source/configuration/cass_yaml_file.rst | 8 src/java/org/apache/cassandra/config/Config.java | 2 ++ src/java/org/apache/cassandra/config/DatabaseDescriptor.java | 11 +++ .../cassandra/cql3/statements/schema/AlterTableStatement.java | 5 - test/conf/cassandra.yaml | 1 + .../org/apache/cassandra/distributed/test/CountersTest.java | 2 +- .../distributed/upgrade/CompactStorageUpgradeTest.java| 2 +- .../apache/cassandra/distributed/upgrade/UpgradeTestBase.java | 10 ++ .../cassandra/cql3/validation/operations/AlterTest.java | 11 +++ 12 files changed, 63 insertions(+), 5 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0 updated (bd1ffa7 -> d51f9d2)
This is an automated email from the ASF dual-hosted git repository. blerer pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from bd1ffa7 Merge branch 'cassandra-3.11' into cassandra-4.0 add 9b6dd38 Add flag to disable ALTER...DROP COMPACT STORAGE statements add 91c12bd Merge branch cassandra-3.0 into cassandra-3.11 add bdb7c3b Merge branch cassandra-3.11 into cassandra-4.0.0 add d51f9d2 Merge branch cassandra-4.0.0 into cassandra-4.0 No new revisions were added by this update. Summary of changes: CHANGES.txt | 1 + NEWS.txt | 11 +-- conf/cassandra.yaml | 4 doc/source/configuration/cass_yaml_file.rst | 8 src/java/org/apache/cassandra/config/Config.java | 2 ++ src/java/org/apache/cassandra/config/DatabaseDescriptor.java | 11 +++ .../cassandra/cql3/statements/schema/AlterTableStatement.java | 5 - test/conf/cassandra.yaml | 1 + .../org/apache/cassandra/distributed/test/CountersTest.java | 2 +- .../distributed/upgrade/CompactStorageUpgradeTest.java| 2 +- .../apache/cassandra/distributed/upgrade/UpgradeTestBase.java | 10 ++ .../cassandra/cql3/validation/operations/AlterTest.java | 11 +++ 12 files changed, 63 insertions(+), 5 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16751) Regarding static column added in compact tables through Cassandra-stress tool
Radha created CASSANDRA-16751:
-
Summary: Regarding static column added in compact tables through
Cassandra-stress tool
Key: CASSANDRA-16751
URL: https://issues.apache.org/jira/browse/CASSANDRA-16751
Project: Cassandra
Issue Type: Bug
Reporter: Radha
I have Cassandra 3.11.9 installed on my setup. I used the Cassandra-stress
tool to create data for my cluster.
# cassandra-stress write n=800 -log file=/tmp/1 level=verbose -mode native
cql3 user=cassandra password=cassandra -node nodeip
I saw that two tables were created "counter1 and standard1".
The "counter1" table had no data and also was created with the following
configuration:
cassandra@cqlsh> desc table keyspace1.counter1;
cassandra@cqlsh> CREATE TABLE keyspace1.counter1 (
key blob,
column1 text,
*"C0" counter static,*
*"C1" counter static,*
*"C2" counter static,*
*"C3" counter static,*
*"C4" counter static,*
value counter,
PRIMARY KEY (key, column1)
) *WITH COMPACT STORAGE*
AND CLUSTERING ORDER BY (column1 ASC)
AND bloom_filter_fp_chance = 0.01
AND caching = \{'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND comment = ''
AND compaction = {'class':
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
'max_threshold': '32', 'min_threshold': '4'}
AND compression = \{'enabled': 'false'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';
Now if I try to create a similar schema manually with above-mentioned
schema, I get the following error. InvalidRequest: Error from server:
code=2200 [Invalid query] message="Static columns are not supported in
COMPACT STORAGE tables"
I further read more about this error and found that static columns cannot
be used with COMPACT STORAGE tables.
Here is the documentation for the same :
1. https://docs.datastax.com/en/cql-oss/3.3/cql/cql_using/useCompactStorage.html
2. https://programmersought.com/article/81431553936/
I raised the same on dev as well as user Cassandra forum. I have got a reply
from Benjamin Lerer that this is a bug and hence raising the JIRA.
*Query details:*
https://lists.apache.org/thread.html/rf9c74e8e3d431ff395f73677a616a9fcd70a46f3ea0500b71ca4d91d%40%3Cdev.cassandra.apache.org%3E
--
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-16715) WEBSITE - June 2021 updates
[ https://issues.apache.org/jira/browse/CASSANDRA-16715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-16715: -- Source Control Link: https://github.com/apache/cassandra-website/commit/3b95a5ea868c9b845b5311d60ea4705549846347 Resolution: Fixed Status: Resolved (was: Ready to Commit) > WEBSITE - June 2021 updates > --- > > Key: CASSANDRA-16715 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16715 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Melissa Logan >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0-rc2, 4.0 > > Attachments: CASSANDRA-16715-updates.zip, c16715-blog-index.png, > c16715-blog-post-changelog_7.png, c16715-blog-post-k8s_sig_2.png, > c16715-case_studies-hornet.png, c16715-ecosystem.png, > c16715-homepage-community_spotlight.png, c16715-homepage-logo-hornet.png, > c16715-homepage-logo-instagram.png > > > Sharing a batch of HTML updates to be made to the website that includes: > * Added 2 blog posts > * Added folder with 2 images to img/blog for Cassandra and Kubernetes SIG > update > * Added Hornet logo and Cassandra Kubernetes SIG image > * Added new Case Study for Hornet > * Added 40 items to Ecosystem page including Cassandra Cloud Offerings, > Cassandra Tools, Cassandra Kubernetes Operators, and Developer Frameworks > * Updated blog site > * Updated Instagram logo > * Updated Community Spotlights on the homepage > > -- 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-website] 02/02: add plausible tracking
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch asf-site in repository https://gitbox.apache.org/repos/asf/cassandra-website.git commit 3e65eb039259b03746bd376f2efa1649375c4e61 Author: mck AuthorDate: Fri Jun 18 12:13:41 2021 +0200 add plausible tracking --- content/blog/Apache-Cassandra-Changelog-7-May-2021.html | 2 +- content/blog/Cassandra-and-Kubernetes-SIG-Update-2.html | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/content/blog/Apache-Cassandra-Changelog-7-May-2021.html b/content/blog/Apache-Cassandra-Changelog-7-May-2021.html index 7217c97..e2e49ca 100644 --- a/content/blog/Apache-Cassandra-Changelog-7-May-2021.html +++ b/content/blog/Apache-Cassandra-Changelog-7-May-2021.html @@ -12,7 +12,7 @@ - +https://plausible.cassandra.apache.org/js/plausible.js";> diff --git a/content/blog/Cassandra-and-Kubernetes-SIG-Update-2.html b/content/blog/Cassandra-and-Kubernetes-SIG-Update-2.html index 240a562..8530864 100644 --- a/content/blog/Cassandra-and-Kubernetes-SIG-Update-2.html +++ b/content/blog/Cassandra-and-Kubernetes-SIG-Update-2.html @@ -12,7 +12,7 @@ - +https://plausible.cassandra.apache.org/js/plausible.js";> - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-site updated (47afc10 -> 3e65eb0)
This is an automated email from the ASF dual-hosted git repository.
mck pushed a change to branch asf-site
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git.
from 47afc10 Update quickstart page
new 3b95a5e CASSANDRA-16715 Updated website with content for June 2021
new 3e65eb0 add plausible tracking
The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
... => Apache-Cassandra-Changelog-7-May-2021.html} | 70 ---
... => Cassandra-and-Kubernetes-SIG-Update-2.html} | 99 +
content/blog/index.html| 2 +
content/case-studies/index.html| 13 ++-
content/ecosystem/index.html | 44 -
.../apache-cassandra-cluster-on-kubernetes.png | Bin 0 -> 204312 bytes
.../cass-operator-diagram.png | Bin 0 -> 136349 bytes
content/img/companies/hornet.png | Bin 0 -> 47921 bytes
content/img/companies/instagram.png| Bin 0 -> 148858 bytes
content/img/plain-kub-cass.jpg | Bin 0 -> 23161 bytes
content/index.html | 44 -
11 files changed, 179 insertions(+), 93 deletions(-)
copy content/blog/{Apache-Cassandra-Changelog-6-April-2021.html =>
Apache-Cassandra-Changelog-7-May-2021.html} (57%)
copy content/blog/{Testing-Apache-Cassandra-4.html =>
Cassandra-and-Kubernetes-SIG-Update-2.html} (51%)
create mode 100644
content/img/blog-post-cassandra-and-kubernetes-sig-update/apache-cassandra-cluster-on-kubernetes.png
create mode 100644
content/img/blog-post-cassandra-and-kubernetes-sig-update/cass-operator-diagram.png
create mode 100644 content/img/companies/hornet.png
create mode 100644 content/img/companies/instagram.png
create mode 100644 content/img/plain-kub-cass.jpg
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16715) WEBSITE - June 2021 updates
[ https://issues.apache.org/jira/browse/CASSANDRA-16715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-16715: -- Status: Ready to Commit (was: Review In Progress) > WEBSITE - June 2021 updates > --- > > Key: CASSANDRA-16715 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16715 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Melissa Logan >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0-rc2, 4.0 > > Attachments: CASSANDRA-16715-updates.zip, c16715-blog-index.png, > c16715-blog-post-changelog_7.png, c16715-blog-post-k8s_sig_2.png, > c16715-case_studies-hornet.png, c16715-ecosystem.png, > c16715-homepage-community_spotlight.png, c16715-homepage-logo-hornet.png, > c16715-homepage-logo-instagram.png > > > Sharing a batch of HTML updates to be made to the website that includes: > * Added 2 blog posts > * Added folder with 2 images to img/blog for Cassandra and Kubernetes SIG > update > * Added Hornet logo and Cassandra Kubernetes SIG image > * Added new Case Study for Hornet > * Added 40 items to Ecosystem page including Cassandra Cloud Offerings, > Cassandra Tools, Cassandra Kubernetes Operators, and Developer Frameworks > * Updated blog site > * Updated Instagram logo > * Updated Community Spotlights on the homepage > > -- 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-16715) WEBSITE - June 2021 updates
[ https://issues.apache.org/jira/browse/CASSANDRA-16715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17365420#comment-17365420 ] Erick Ramirez commented on CASSANDRA-16715: --- REVIEW COMPLETED - Ready to commit. Homepage - added blog posts to Community Spotlight: !c16715-homepage-community_spotlight.png|width=300! Homepage - added new logos for Hornet & Instagram: !c16715-homepage-logo-hornet.png|width=300! !c16715-homepage-logo-instagram.png|width=300! Blog - added 2 new posts: !c16715-blog-index.png|width=300! !c16715-blog-post-k8s_sig_2.png|width=300! !c16715-blog-post-changelog_7.png|width=300! Case Studies - added Hornet: !c16715-case_studies-hornet.png|width=300! Ecosystem - added 40 new items: !c16715-ecosystem.png|width=300! > WEBSITE - June 2021 updates > --- > > Key: CASSANDRA-16715 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16715 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Melissa Logan >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0-rc2, 4.0 > > Attachments: CASSANDRA-16715-updates.zip, c16715-blog-index.png, > c16715-blog-post-changelog_7.png, c16715-blog-post-k8s_sig_2.png, > c16715-case_studies-hornet.png, c16715-ecosystem.png, > c16715-homepage-community_spotlight.png, c16715-homepage-logo-hornet.png, > c16715-homepage-logo-instagram.png > > > Sharing a batch of HTML updates to be made to the website that includes: > * Added 2 blog posts > * Added folder with 2 images to img/blog for Cassandra and Kubernetes SIG > update > * Added Hornet logo and Cassandra Kubernetes SIG image > * Added new Case Study for Hornet > * Added 40 items to Ecosystem page including Cassandra Cloud Offerings, > Cassandra Tools, Cassandra Kubernetes Operators, and Developer Frameworks > * Updated blog site > * Updated Instagram logo > * Updated Community Spotlights on the homepage > > -- 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-16715) WEBSITE - June 2021 updates
[ https://issues.apache.org/jira/browse/CASSANDRA-16715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-16715: -- Attachment: c16715-homepage-logo-instagram.png c16715-homepage-logo-hornet.png c16715-homepage-community_spotlight.png c16715-blog-post-changelog_7.png c16715-case_studies-hornet.png c16715-ecosystem.png c16715-blog-post-k8s_sig_2.png c16715-blog-index.png > WEBSITE - June 2021 updates > --- > > Key: CASSANDRA-16715 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16715 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Melissa Logan >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0-rc2, 4.0 > > Attachments: CASSANDRA-16715-updates.zip, c16715-blog-index.png, > c16715-blog-post-changelog_7.png, c16715-blog-post-k8s_sig_2.png, > c16715-case_studies-hornet.png, c16715-ecosystem.png, > c16715-homepage-community_spotlight.png, c16715-homepage-logo-hornet.png, > c16715-homepage-logo-instagram.png > > > Sharing a batch of HTML updates to be made to the website that includes: > * Added 2 blog posts > * Added folder with 2 images to img/blog for Cassandra and Kubernetes SIG > update > * Added Hornet logo and Cassandra Kubernetes SIG image > * Added new Case Study for Hornet > * Added 40 items to Ecosystem page including Cassandra Cloud Offerings, > Cassandra Tools, Cassandra Kubernetes Operators, and Developer Frameworks > * Updated blog site > * Updated Instagram logo > * Updated Community Spotlights on the homepage > > -- 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-website] branch asf-staging updated (dd7040e -> c760e5f)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. discard dd7040e Hack in plausible tracking discard fd61721 CASSANDRA-16715 Updated website with content for June 2021 new 991e18b CASSANDRA-16715 Updated website with content for June 2021 new c760e5f Hack in plausible tracking 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 (dd7040e) \ N -- N -- N refs/heads/asf-staging (c760e5f) 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 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../blog/Cassandra-and-Kubernetes-SIG-Update-2.html| 4 ++-- .../cass-operator-diagram.png | Bin 0 -> 136349 bytes 2 files changed, 2 insertions(+), 2 deletions(-) create mode 100644 content/img/blog-post-cassandra-and-kubernetes-sig-update/cass-operator-diagram.png - 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 (b653a3d -> dd7040e)
This is an automated email from the ASF dual-hosted git repository.
mck pushed a change to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git.
discard b653a3d Hack in plausible tracking
discard 85e58d6 CASSANDRA-16715 Updated website with content for June 2021
new fd61721 CASSANDRA-16715 Updated website with content for June 2021
new dd7040e Hack in plausible tracking
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 (b653a3d)
\
N -- N -- N refs/heads/asf-staging (dd7040e)
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 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
.../apache-cassandra-cluster-on-kubernetes.png | Bin
.../cass-operator-diagram.png | Bin 136349 -> 0 bytes
content/index.html | 4 ++--
3 files changed, 2 insertions(+), 2 deletions(-)
rename content/img/{blog =>
}/blog-post-cassandra-and-kubernetes-sig-update/apache-cassandra-cluster-on-kubernetes.png
(100%)
delete mode 100644
content/img/blog/blog-post-cassandra-and-kubernetes-sig-update/cass-operator-diagram.png
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16733) Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17365405#comment-17365405
]
Benjamin Lerer commented on CASSANDRA-16733:
I updated the CI runs they now look good.
> Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
> --
>
> Key: CASSANDRA-16733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16733
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-rc2, 3.0.x, 3.11.x, 4.0-rc
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> {{ALTER ... DROP COMPACT STORAGE}} statements have not been extensively
> tested and suffer from several issues like:
> * As COMPACT tables did not have primary key liveness there empty rows
> inserted AFTER the ALTER will be returned whereas the one inserted before
> the ALTER will not.
> * Also due to the lack of primary key liveness the amount of SSTables being
> read will increase resulting in slower queries (CASSANDRA-16675)
> * After DROP COMPACT it becomes possible to ALTER the table in a way that
> makes all the row disappears
> * There is a loss of functionality around null clustering when dropping
> compact storage (CASSANDRA-16069)
> To avoid running into those issues this ticket will introduce a new flag that
> allow operators to disable those statements on their clusters.
> see https://www.mail-archive.com/dev@cassandra.apache.org/msg16789.html
--
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-16733) Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361857#comment-17361857
]
Benjamin Lerer edited comment on CASSANDRA-16733 at 6/18/21, 9:35 AM:
--
|| Branch || CI ||
|[3.0|https://github.com/apache/cassandra/pull/1061]|[J8|https://app.circleci.com/pipelines/github/blerer/cassandra?branch=CASSANDRA-16733-3.0]|
|[3.11|https://github.com/apache/cassandra/pull/1062]|[J8|https://app.circleci.com/pipelines/github/blerer/cassandra/166/workflows/637b5eda-690d-4c71-8d25-e02cd83d11f2]|
|[4.0|https://github.com/apache/cassandra/pull/1063]|[J8|https://app.circleci.com/pipelines/github/blerer/cassandra/149/workflows/275bba43-e1ff-4604-94af-c8343b49db27],
[J11|https://app.circleci.com/pipelines/github/blerer/cassandra/162/workflows/43d06df1-4c1e-40a7-b41b-9507e3545042]|
was (Author: blerer):
|| Branch || CI ||
|[3.0|https://github.com/apache/cassandra/pull/1061]|[J8|https://app.circleci.com/pipelines/github/blerer/cassandra/147/workflows/69eda7e1-5e16-487e-9395-673ee0cfa1ca]|
|[3.11|https://github.com/apache/cassandra/pull/1062]|[J8|https://app.circleci.com/pipelines/github/blerer/cassandra/146/workflows/1e2e31e1-d46f-4fcd-b9f7-d7829f5c9b3b]|
|[4.0|https://github.com/apache/cassandra/pull/1063]|[J8|https://app.circleci.com/pipelines/github/blerer/cassandra/148/workflows/429e34ca-0ad1-4bda-aacc-bbc3a96c7c0d],
[J11|https://app.circleci.com/pipelines/github/blerer/cassandra/148/workflows/a3d47204-e2b2-4680-8550-4d81857fb3dd]|
> Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
> --
>
> Key: CASSANDRA-16733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16733
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-rc2, 3.0.x, 3.11.x, 4.0-rc
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> {{ALTER ... DROP COMPACT STORAGE}} statements have not been extensively
> tested and suffer from several issues like:
> * As COMPACT tables did not have primary key liveness there empty rows
> inserted AFTER the ALTER will be returned whereas the one inserted before
> the ALTER will not.
> * Also due to the lack of primary key liveness the amount of SSTables being
> read will increase resulting in slower queries (CASSANDRA-16675)
> * After DROP COMPACT it becomes possible to ALTER the table in a way that
> makes all the row disappears
> * There is a loss of functionality around null clustering when dropping
> compact storage (CASSANDRA-16069)
> To avoid running into those issues this ticket will introduce a new flag that
> allow operators to disable those statements on their clusters.
> see https://www.mail-archive.com/dev@cassandra.apache.org/msg16789.html
--
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-16750) Flaky AlibabaCloudSnitchTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17365395#comment-17365395
]
Berenguer Blasi edited comment on CASSANDRA-16750 at 6/18/21, 9:24 AM:
---
CDC creates a hard link on
{{[CommitLogSegmentManagerCDC.createSegment()|https://github.com/apache/cassandra/blob/cassandra-4.0.0/src/java/org/apache/cassandra/db/commitlog/CommitLogSegmentManagerCDC.java#L149]}}
but this happens in an async operation originating at
{{AbstractCommitLogSegmentManager.start()}}. We can see
[here|https://github.com/apache/cassandra/pull/1074/files#diff-b5c6007ec3a4b31965b4dc10e8c8c50766237f1ce8ac88011035b91215060fc8R51]
the test calls {{cleanup()}} just after staring the commit log service. This
can remove files from under the commit log's feet making the hardlinking fail.
We need to wait for completion.
It can be repro'd easily in a 1K circle run and the fix indeed passes now
was (Author: bereng):
CDC creates a hard link on
{{[CommitLogSegmentManagerCDC.createSegment()|https://github.com/apache/cassandra/blob/cassandra-4.0.0/src/java/org/apache/cassandra/db/commitlog/CommitLogSegmentManagerCDC.java#L149]}}
but this happens in an async operation originating at
{{AbstractCommitLogSegmentManager.start()}}. We can see
[here|https://github.com/apache/cassandra/pull/1074/files#diff-b5c6007ec3a4b31965b4dc10e8c8c50766237f1ce8ac88011035b91215060fc8R51]
the test calls {{cleanup()}} just after staring the commit log service. This
can remove files from under the commit log's feet making the hardlinking fail.
We need to wait for completion.
> Flaky AlibabaCloudSnitchTest
>
>
> Key: CASSANDRA-16750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16750
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.x
>
>
> Flaky test
> Test error
> {noformat}
> Error Message
> Forked Java VM exited abnormally. Please note the time in the report does not
> reflect the time until the VM exit.
> Stacktrace
> junit.framework.AssertionFailedError: Forked Java VM exited abnormally.
> Please note the time in the report does not reflect the time until the VM
> exit.
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$30$\^eval\_$cu1$restOf/0x0008403db840.:program(:13)
> at
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:655)
> at
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:513)
> at
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:527)
> at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:456)
> at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:413)
> at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:409)
> at
>
[jira] [Comment Edited] (CASSANDRA-16750) Flaky AlibabaCloudSnitchTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17365395#comment-17365395
]
Berenguer Blasi edited comment on CASSANDRA-16750 at 6/18/21, 9:24 AM:
---
CDC creates a hard link on
{{[CommitLogSegmentManagerCDC.createSegment()|https://github.com/apache/cassandra/blob/cassandra-4.0.0/src/java/org/apache/cassandra/db/commitlog/CommitLogSegmentManagerCDC.java#L149]}}
but this happens in an async operation originating at
{{AbstractCommitLogSegmentManager.start()}}. We can see
[here|https://github.com/apache/cassandra/pull/1074/files#diff-b5c6007ec3a4b31965b4dc10e8c8c50766237f1ce8ac88011035b91215060fc8R51]
the test calls {{cleanup()}} just after staring the commit log service. This
can remove files from under the commit log's feet making the hardlinking fail.
We need to wait for completion.
was (Author: bereng):
CDC creates a hard link on {{CommitLogSegmentManagerCDC.createSegment()}} but
this happens in an async operation originating at
{{AbstractCommitLogSegmentManager.start()}}. We can see
[here|https://github.com/apache/cassandra/pull/1074/files#diff-b5c6007ec3a4b31965b4dc10e8c8c50766237f1ce8ac88011035b91215060fc8R51]
the test calls {{cleanup()}} just after staring the commit log service. This
can remove files from under the commit log's feet making the hardlinking fail.
We need to wait for completion.
> Flaky AlibabaCloudSnitchTest
>
>
> Key: CASSANDRA-16750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16750
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.x
>
>
> Flaky test
> Test error
> {noformat}
> Error Message
> Forked Java VM exited abnormally. Please note the time in the report does not
> reflect the time until the VM exit.
> Stacktrace
> junit.framework.AssertionFailedError: Forked Java VM exited abnormally.
> Please note the time in the report does not reflect the time until the VM
> exit.
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$30$\^eval\_$cu1$restOf/0x0008403db840.:program(:13)
> at
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:655)
> at
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:513)
> at
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:527)
> at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:456)
> at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:413)
> at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:409)
> at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:162)
> at
> java.scripting/javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264)
> at
[jira] [Commented] (CASSANDRA-16750) Flaky AlibabaCloudSnitchTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17365395#comment-17365395
]
Berenguer Blasi commented on CASSANDRA-16750:
-
CDC creates a hard link on {{CommitLogSegmentManagerCDC.createSegment()}} but
this happens in an async operation originating at
{{AbstractCommitLogSegmentManager.start()}}. We can see
[here|https://github.com/apache/cassandra/pull/1074/files#diff-b5c6007ec3a4b31965b4dc10e8c8c50766237f1ce8ac88011035b91215060fc8R51]
the test calls {{cleanup()}} just after staring the commit log service. This
can remove files from under the commit log's feet making the hardlinking fail.
We need to wait for completion.
> Flaky AlibabaCloudSnitchTest
>
>
> Key: CASSANDRA-16750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16750
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.x
>
>
> Flaky test
> Test error
> {noformat}
> Error Message
> Forked Java VM exited abnormally. Please note the time in the report does not
> reflect the time until the VM exit.
> Stacktrace
> junit.framework.AssertionFailedError: Forked Java VM exited abnormally.
> Please note the time in the report does not reflect the time until the VM
> exit.
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$30$\^eval\_$cu1$restOf/0x0008403db840.:program(:13)
> at
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:655)
> at
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:513)
> at
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:527)
> at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:456)
> at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:413)
> at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:409)
> at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:162)
> at
> java.scripting/javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
> Log error:
> {noformat}
> AlibabaCloudSnitchTest.BeforeFirstTest failure was
[jira] [Commented] (CASSANDRA-16735) Adding columns via ALTER TABLE can generate corrupt sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-16735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17365393#comment-17365393 ] Marcus Eriksson commented on CASSANDRA-16735: - removed the failing 15899 tests, now the cci runs look good (the sstableverify test fails locally without this patch as well) > Adding columns via ALTER TABLE can generate corrupt sstables > > > Key: CASSANDRA-16735 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16735 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair, Local/SSTable >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-rc2, 3.0.x, 3.11.x, 4.0-rc > > > This is similar to CASSANDRA-13004 and was caused by CASSANDRA-15899 > Basically the column placeholders introduced in 15899 can get read-repaired > in to the memtable and later flushed to disk and in some cases this can > conflict with the actual column (if the actual column is a collection for > example) and cause CorruptSSTableExceptions. > Fix is probably to just revert 15899, at least until if and when we find a > solution that we can rely on. Will post that + test next week. -- 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-16750) Flaky AlibabaCloudSnitchTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-16750:
Test and Documentation Plan: See PR
Status: Patch Available (was: Open)
> Flaky AlibabaCloudSnitchTest
>
>
> Key: CASSANDRA-16750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16750
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.x
>
>
> Flaky test
> Test error
> {noformat}
> Error Message
> Forked Java VM exited abnormally. Please note the time in the report does not
> reflect the time until the VM exit.
> Stacktrace
> junit.framework.AssertionFailedError: Forked Java VM exited abnormally.
> Please note the time in the report does not reflect the time until the VM
> exit.
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$30$\^eval\_$cu1$restOf/0x0008403db840.:program(:13)
> at
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:655)
> at
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:513)
> at
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:527)
> at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:456)
> at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:413)
> at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:409)
> at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:162)
> at
> java.scripting/javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
> Log error:
> {noformat}
> AlibabaCloudSnitchTest.BeforeFirstTest failure was
> ERROR [COMMIT-LOG-ALLOCATOR] 2021-06-05 00:41:36,750 Exiting due to error
> while processing commit log during initialization.
> java.lang.RuntimeException: Tried to hard link to file that does not exist
> build/test/cassandra/commitlog/CommitLog-7-1622853696662.log
> at
> org.apache.cassandra.io.util.FileUtils.createHardLink(FileUtils.java:184)
> at
>
[jira] [Updated] (CASSANDRA-16750) Flaky AlibabaCloudSnitchTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-16750:
Bug Category: Parent values: Correctness(12982)
Complexity: Normal
Discovered By: Unit Test
Fix Version/s: 4.x
4.0
4.0-rc2
Severity: Normal
Status: Open (was: Triage Needed)
> Flaky AlibabaCloudSnitchTest
>
>
> Key: CASSANDRA-16750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16750
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.x
>
>
> Flaky test
> Test error
> {noformat}
> Error Message
> Forked Java VM exited abnormally. Please note the time in the report does not
> reflect the time until the VM exit.
> Stacktrace
> junit.framework.AssertionFailedError: Forked Java VM exited abnormally.
> Please note the time in the report does not reflect the time until the VM
> exit.
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$30$\^eval\_$cu1$restOf/0x0008403db840.:program(:13)
> at
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:655)
> at
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:513)
> at
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:527)
> at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:456)
> at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:413)
> at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:409)
> at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:162)
> at
> java.scripting/javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
> Log error:
> {noformat}
> AlibabaCloudSnitchTest.BeforeFirstTest failure was
> ERROR [COMMIT-LOG-ALLOCATOR] 2021-06-05 00:41:36,750 Exiting due to error
> while processing commit log during initialization.
> java.lang.RuntimeException: Tried to hard link to file that does not exist
> build/test/cassandra/commitlog/CommitLog-7-1622853696662.log
> at
>
[cassandra-website] branch asf-staging updated (43a1dbf -> b653a3d)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. from 43a1dbf Update quickstart page new 85e58d6 CASSANDRA-16715 Updated website with content for June 2021 new b653a3d Hack in plausible tracking The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: ... => Apache-Cassandra-Changelog-7-May-2021.html} | 72 --- ... => Cassandra-and-Kubernetes-SIG-Update-2.html} | 99 + content/blog/index.html| 2 + content/case-studies/index.html| 13 ++- content/doc/3.11.10/architecture/dynamo.html | 2 +- content/doc/3.11.10/architecture/guarantees.html | 2 +- content/doc/3.11.10/architecture/index.html| 2 +- content/doc/3.11.10/architecture/overview.html | 2 +- .../doc/3.11.10/architecture/storage_engine.html | 2 +- content/doc/3.11.10/bugs.html | 2 +- .../configuration/cassandra_config_file.html | 2 +- content/doc/3.11.10/configuration/index.html | 2 +- content/doc/3.11.10/contactus.html | 2 +- content/doc/3.11.10/cql/appendices.html| 2 +- content/doc/3.11.10/cql/changes.html | 2 +- content/doc/3.11.10/cql/ddl.html | 2 +- content/doc/3.11.10/cql/definitions.html | 2 +- content/doc/3.11.10/cql/dml.html | 2 +- content/doc/3.11.10/cql/functions.html | 2 +- content/doc/3.11.10/cql/index.html | 2 +- content/doc/3.11.10/cql/indexes.html | 2 +- content/doc/3.11.10/cql/json.html | 2 +- content/doc/3.11.10/cql/mvs.html | 2 +- content/doc/3.11.10/cql/security.html | 2 +- content/doc/3.11.10/cql/triggers.html | 2 +- content/doc/3.11.10/cql/types.html | 2 +- content/doc/3.11.10/data_modeling/index.html | 2 +- content/doc/3.11.10/development/code_style.html| 2 +- content/doc/3.11.10/development/how_to_commit.html | 2 +- content/doc/3.11.10/development/how_to_review.html | 2 +- content/doc/3.11.10/development/ide.html | 2 +- content/doc/3.11.10/development/index.html | 2 +- content/doc/3.11.10/development/patches.html | 2 +- content/doc/3.11.10/development/testing.html | 2 +- content/doc/3.11.10/faq/index.html | 2 +- content/doc/3.11.10/genindex.html | 2 +- .../doc/3.11.10/getting_started/configuring.html | 2 +- content/doc/3.11.10/getting_started/drivers.html | 2 +- content/doc/3.11.10/getting_started/index.html | 2 +- .../doc/3.11.10/getting_started/installing.html| 2 +- content/doc/3.11.10/getting_started/querying.html | 2 +- content/doc/3.11.10/index.html | 2 +- content/doc/3.11.10/operating/backups.html | 2 +- content/doc/3.11.10/operating/bloom_filters.html | 2 +- content/doc/3.11.10/operating/bulk_loading.html| 2 +- content/doc/3.11.10/operating/cdc.html | 2 +- content/doc/3.11.10/operating/compaction.html | 2 +- content/doc/3.11.10/operating/compression.html | 2 +- content/doc/3.11.10/operating/hardware.html| 2 +- content/doc/3.11.10/operating/hints.html | 2 +- content/doc/3.11.10/operating/index.html | 2 +- content/doc/3.11.10/operating/metrics.html | 2 +- content/doc/3.11.10/operating/read_repair.html | 2 +- content/doc/3.11.10/operating/repair.html | 2 +- content/doc/3.11.10/operating/security.html| 2 +- content/doc/3.11.10/operating/snitch.html | 2 +- content/doc/3.11.10/operating/topo_changes.html| 2 +- content/doc/3.11.10/search.html| 2 +- content/doc/3.11.10/tools/cqlsh.html | 2 +- content/doc/3.11.10/tools/index.html | 2 +- content/doc/3.11.10/tools/nodetool.html| 2 +- content/doc/3.11.10/troubleshooting/index.html | 2 +- content/doc/4.0-rc2/architecture/dynamo.html | 2 +- content/doc/4.0-rc2/architecture/guarantees.html | 2 +- content/doc/4.0-rc2/architecture/index.html| 2 +- content/doc/4.0-rc2/architecture/overview.html | 2 +- .../doc/4.0-rc2/architecture/storage_engine.html | 2 +- content/doc/4.0-rc2/bugs.html | 2 +- .../configuration/cass_cl_archive_file.html| 2 +- .../4.0-rc2/configuration/cass_env_sh_file.html| 2 +- .../configuration/cass_jvm_options_file.html | 2 +-
[cassandra-website] 03/03: Update quickstart page
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git
commit 43a1dbf48cf2dcd06ad2412c05b89d994c392611
Author: polymetric
AuthorDate: Thu May 6 17:44:13 2021 -0400
Update quickstart page
note spin-up time, fix volume mount, fix insert command
remove apparently unnecessary docker rm command, remove the network
ref: https://github.com/apache/cassandra-website/pull/55
patch by polymetric; reviewed by Mick Semb Wever
---
content/quickstart/index.html | 78 ++-
1 file changed, 47 insertions(+), 31 deletions(-)
diff --git a/content/quickstart/index.html b/content/quickstart/index.html
index dda5960..304f3d3 100644
--- a/content/quickstart/index.html
+++ b/content/quickstart/index.html
@@ -172,7 +172,6 @@
Interested in getting started with Cassandra? Follow these
instructions.
STEP 1:
GET CASSANDRA USING DOCKER
-
You'll need to have Docker
Desktop for Mac, Docker Desktop for Windows, or
similar
software installed on your computer.
@@ -184,76 +183,93 @@
STEP 2:
START CASSANDRA
+ A Docker network allows us
to access the container's ports without exposing them on the host.
- docker run --name
cassandra cassandra
+
+docker network create cassandra
+docker run --rm -d --name cassandra --hostname
cassandra --network cassandra cassandra
+
STEP 3:
CREATE FILES
- In the directory where you
plan to run the next step, create these two files so that some data can be
automatically inserted in the next step.
- A
cqlshrc file will log into the Cassandra database with the default
superuser:
+The Cassandra Query Language (CQL) is very similar
to SQL but suited for the JOINless structure of Cassandra.
+Create a file named data.cql and paste
the following CQL script in it. This script will create a keyspace, the layer
at which Cassandra replicates its data, a table to hold the data, and insert
some data into that table:
-
[authentication]
- username =
cassandra
- password =
cassandra
-
-
- Create a scripts
directory and change to that directory. The following data.cql file
will create a keyspace, the layer at which Cassandra replicates its data, a
table to hold the data, and insert some data:
-
-
- # Create a
keyspace
+ -- Create a
keyspace
CREATE KEYSPACE
IF NOT EXISTS store WITH REPLICATION = { 'class' : 'SimpleStrategy',
'replication_factor' : '1' };
- # Create a
table
+ -- Create a
table
CREATE TABLE IF
NOT EXISTS store.shopping_cart (
userid
text PRIMARY KEY,
item_count int,
last_update_timestamp timestamp
);
[jira] [Created] (CASSANDRA-16750) Flaky AlibabaCloudSnitchTest
Berenguer Blasi created CASSANDRA-16750:
---
Summary: Flaky AlibabaCloudSnitchTest
Key: CASSANDRA-16750
URL: https://issues.apache.org/jira/browse/CASSANDRA-16750
Project: Cassandra
Issue Type: Bug
Components: Test/unit
Reporter: Berenguer Blasi
Assignee: Berenguer Blasi
Flaky test
Test error
{noformat}
Error Message
Forked Java VM exited abnormally. Please note the time in the report does not
reflect the time until the VM exit.
Stacktrace
junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please
note the time in the report does not reflect the time until the VM exit.
at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.util.Vector.forEach(Vector.java:1388)
at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.util.Vector.forEach(Vector.java:1388)
at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.util.Vector.forEach(Vector.java:1388)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at
jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$30$\^eval\_$cu1$restOf/0x0008403db840.:program(:13)
at
jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:655)
at
jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:513)
at
jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:527)
at
jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:456)
at
jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:413)
at
jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:409)
at
jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:162)
at
java.scripting/javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264)
at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.util.Vector.forEach(Vector.java:1388)
at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
{noformat}
Log error:
{noformat}
AlibabaCloudSnitchTest.BeforeFirstTest failure was
ERROR [COMMIT-LOG-ALLOCATOR] 2021-06-05 00:41:36,750 Exiting due to error while
processing commit log during initialization.
java.lang.RuntimeException: Tried to hard link to file that does not exist
build/test/cassandra/commitlog/CommitLog-7-1622853696662.log
at
org.apache.cassandra.io.util.FileUtils.createHardLink(FileUtils.java:184)
at
org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDC.createSegment(CommitLogSegmentManagerCDC.java:149)
at
org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$1.runMayThrow(AbstractCommitLogSegmentManager.java:115)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.lang.Thread.run(Thread.java:748)
[jira] [Updated] (CASSANDRA-16649) Add Versions.Major.v4X to Java DTests (after cassandra-4.0 branch was created)
[ https://issues.apache.org/jira/browse/CASSANDRA-16649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16649: --- Reviewers: Alex Petrov > Add Versions.Major.v4X to Java DTests (after cassandra-4.0 branch was created) > -- > > Key: CASSANDRA-16649 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16649 > Project: Cassandra > Issue Type: Sub-task > Components: Test/dtest/java >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.x > > > - > https://github.com/apache/cassandra-in-jvm-dtest-api/compare/trunk...thelastpickle:mck/16649 > - > https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/16649/trunk > -- 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-16649) Add Versions.Major.v4X to Java DTests (after cassandra-4.0 branch was created)
[ https://issues.apache.org/jira/browse/CASSANDRA-16649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16649: --- Fix Version/s: 3.11.x 3.0.x 2.2.x > Add Versions.Major.v4X to Java DTests (after cassandra-4.0 branch was created) > -- > > Key: CASSANDRA-16649 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16649 > Project: Cassandra > Issue Type: Sub-task > Components: Test/dtest/java >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.x > > > - > https://github.com/apache/cassandra-in-jvm-dtest-api/compare/trunk...thelastpickle:mck/16649 > - > https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/16649/trunk > -- 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-16649) Add Versions.Major.v4X to Java DTests (after cassandra-4.0 branch was created)
[ https://issues.apache.org/jira/browse/CASSANDRA-16649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17365293#comment-17365293 ] Alex Petrov commented on CASSANDRA-16649: - Left a small comment (create files during tests vs storing them in repository) in dtest. Since most of version and comparing was already implemented, I personally would have just added support for 4.x and rc/beta/alpha. However, I do not have a strong opinion in this specific case, since it's used in tests. If we do run into dependency conflict and one of our dependencies has semver4j as a transitive dependency, we can just revert and implement it "natively". Just to make sure this is mentioned: changes made to dtests have to be applied to all branches that have dtest api referenced. +1 > Add Versions.Major.v4X to Java DTests (after cassandra-4.0 branch was created) > -- > > Key: CASSANDRA-16649 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16649 > Project: Cassandra > Issue Type: Sub-task > Components: Test/dtest/java >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 4.0.x, 4.x > > > - > https://github.com/apache/cassandra-in-jvm-dtest-api/compare/trunk...thelastpickle:mck/16649 > - > https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/16649/trunk > -- 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-16649) Add Versions.Major.v4X to Java DTests (after cassandra-4.0 branch was created)
[
https://issues.apache.org/jira/browse/CASSANDRA-16649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17365274#comment-17365274
]
Michael Semb Wever commented on CASSANDRA-16649:
bq. I'm thinking that solving that is going to be easier, and more
maintainable, by using SemVer4j inside Versions.Major.
The full suite of changes is the following:
For _cassandra-in-jvm-dtest-api _
1.
https://github.com/apache/cassandra-in-jvm-dtest-api/compare/trunk...thelastpickle:mck/16649
2. https://github.com/thelastpickle/cassandra-in-jvm-dtest-api/pull/1
3. https://github.com/thelastpickle/cassandra-in-jvm-dtest-api/pull/2
That implements version 4.0 and 4.1 in (1), introduces the SemVer4j library for
internal version parsing and handling in (2), and introduces SemVer4j into the
API replacing the {{Versions.Major}} enum with SemVer4j's {{Semer}} class in
(3).
For _cassandra-4.0_
A.
https://github.com/apache/cassandra/compare/cassandra-4.0...thelastpickle:mck/16649/4.0
B. https://github.com/thelastpickle/cassandra/pull/1
(A) is the changes required for 1, and (B) is the changes required for 3.
In addition, (A) changes upgrades from testing the single explicit path, to
testing all upgrade paths that are (globally) supported within the specified
{{from}} and {{to}} range. Where {{to}} is not specified it is implied to be
the {{CURRENT}} version.
The final patches for all of these put together are
- cassandra-in-jvm-dtest-api ::
https://github.com/apache/cassandra-in-jvm-dtest-api/compare/trunk...thelastpickle:mck/16649_all
- cassandra-4.0 ::
https://github.com/apache/cassandra/compare/cassandra-4.0...thelastpickle:mck/16649_all/4.0
> Add Versions.Major.v4X to Java DTests (after cassandra-4.0 branch was created)
> --
>
> Key: CASSANDRA-16649
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16649
> Project: Cassandra
> Issue Type: Sub-task
> Components: Test/dtest/java
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> -
> https://github.com/apache/cassandra-in-jvm-dtest-api/compare/trunk...thelastpickle:mck/16649
> -
> https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/16649/trunk
>
--
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
