[jira] [Commented] (CASSANDRA-17017) Add required -f / --force option to nodetool verify
[ https://issues.apache.org/jira/browse/CASSANDRA-17017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511026#comment-17511026 ] Berenguer Blasi commented on CASSANDRA-17017: - bq. I mentioned that this is a known issue and works w/the correct dtest branch locally Ok sorry, bad wording. I mean that if sstableverify is failing and you can't get circle to work, then I'd fire a jenkins devbranch so you have a 'complete' CI :-) > Add required -f / --force option to nodetool verify > --- > > Key: CASSANDRA-17017 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17017 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.1 > > > nodetool verify has some pretty significant problems with it (see > CASSANDRA-9947). > Until such time as we do the heavy(er) lift to fix the command, we should > make it harder for people to shoot themselves in the foot with it. Adding a > required "-f" flag to it with a requisite "Do you really know what you're > doing? Check out this JIRA first" seems like it'd be the right thing to do in > the interim. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17332) Add support for vnodes in jvm-dtest
[ https://issues.apache.org/jira/browse/CASSANDRA-17332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510977#comment-17510977 ] David Capwell commented on CASSANDRA-17332: --- [~ifesdjeen] [~jmckenzie] trunk patch is ready for review. Once looks good, just need to release jvm-dtest api and update the version in this PR (and confirm upgrade tests not broken in other branches) > Add support for vnodes in jvm-dtest > --- > > Key: CASSANDRA-17332 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17332 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > Time Spent: 50m > Remaining Estimate: 0h > > Right now python dtests need to keep running after being ported to jvm-dtests > as vnode support is not present, to fully deprecate the python dtests, we > need vnode support in jvm-dtest. > Sadly, to add support we need to break binary compatibility, but can maintain > source compatibility… so will need to bump every jar across every branch > (mostly due to TokenSupplier) -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17473) sstables changing in snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-17473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Brown updated CASSANDRA-17473:
Description:
We use cassandra snapshots and tar to make full backups of our cassandra
clusters. Sometimes, tar fails with a message like
{{tar:
data/addresses/addresses-eb0196100b7d11ec852b1541747d640a/snapshots/backup20220318183708/nb-167-big-Data.db:
file changed as we read it}}
This is kind of strange, since we're reading from a snapshot.
The (very simplified) relevant snippet looks roughly like
{code:java}
nice nodetool "${JMX_ARGS[@]}" snapshot -t "$TAG" "${KEYSPACES[@]}"
tar --hard-dereference -czpf data///snapshots/"$TAG"/{code}
This happens maybe 1% of the time when taking backups.
There are no concurrent snapshots going on, but there are concurrent
compactions and repairs, of course. If it matters, this cluster _is_ running
incremental repairs.
This is on Cassandra 4.0.3.
It seems wrong to me that an sstable could ever be written to while it's in a
snapshot.
was:
We use cassandra snapshots and
{tar}
to make full backups of our cassandra clusters. Sometimes, tar fails with a
message like
{{tar:
data/addresses/addresses-eb0196100b7d11ec852b1541747d640a/snapshots/backup20220318183708/nb-167-big-Data.db:
file changed as we read it}}
This is kind of strange, since we're reading from a snapshot.
The (very simplified) relevant snippet looks roughly like
{code:java}
nice nodetool "${JMX_ARGS[@]}" snapshot -t "$TAG" "${KEYSPACES[@]}"
tar --hard-dereference -czpf data///snapshots/"$TAG"/{code}
This happens maybe 1% of the time when taking backups.
There are no concurrent snapshots going on, but there are concurrent
compactions and repairs, of course. If it matters, this cluster _is_ running
incremental repairs.
This is on Cassandra 4.0.3.
It seems wrong to me that an sstable could ever be written to while it's in a
snapshot.
> sstables changing in snapshots
> --
>
> Key: CASSANDRA-17473
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17473
> Project: Cassandra
> Issue Type: Bug
>Reporter: James Brown
>Priority: Normal
>
> We use cassandra snapshots and tar to make full backups of our cassandra
> clusters. Sometimes, tar fails with a message like
> {{tar:
> data/addresses/addresses-eb0196100b7d11ec852b1541747d640a/snapshots/backup20220318183708/nb-167-big-Data.db:
> file changed as we read it}}
> This is kind of strange, since we're reading from a snapshot.
> The (very simplified) relevant snippet looks roughly like
> {code:java}
> nice nodetool "${JMX_ARGS[@]}" snapshot -t "$TAG" "${KEYSPACES[@]}"
> tar --hard-dereference -czpf data///snapshots/"$TAG"/{code}
> This happens maybe 1% of the time when taking backups.
> There are no concurrent snapshots going on, but there are concurrent
> compactions and repairs, of course. If it matters, this cluster _is_ running
> incremental repairs.
> This is on Cassandra 4.0.3.
> It seems wrong to me that an sstable could ever be written to while it's in a
> snapshot.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17473) sstables changing in snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-17473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Brown updated CASSANDRA-17473:
Description:
We use cassandra snapshots and
{tar}
to make full backups of our cassandra clusters. Sometimes, tar fails with a
message like
{{tar:
data/addresses/addresses-eb0196100b7d11ec852b1541747d640a/snapshots/backup20220318183708/nb-167-big-Data.db:
file changed as we read it}}
This is kind of strange, since we're reading from a snapshot.
The (very simplified) relevant snippet looks roughly like
{code:java}
nice nodetool "${JMX_ARGS[@]}" snapshot -t "$TAG" "${KEYSPACES[@]}"
tar --hard-dereference -czpf data///snapshots/"$TAG"/{code}
This happens maybe 1% of the time when taking backups.
There are no concurrent snapshots going on, but there are concurrent
compactions and repairs, of course. If it matters, this cluster _is_ running
incremental repairs.
This is on Cassandra 4.0.3.
It seems wrong to me that an sstable could ever be written to while it's in a
snapshot.
was:
We use cassandra snapshots and {tar} to make full backups of our cassandra
clusters. Sometimes, tar fails with a message like
{{tar:
data/addresses/addresses-eb0196100b7d11ec852b1541747d640a/snapshots/backup20220318183708/nb-167-big-Data.db:
file changed as we read it}}
This is kind of strange, since we're reading from a snapshot.
The (very simplified) relevant snippet looks roughly like
{{nice nodetool "${JMX_ARGS[@]}" snapshot -t "$TAG" "${KEYSPACES[@]}"}}
{{tar --hard-dereference -czpf data/*/*/snapshots/"$TAG"/}}
This happens maybe 1% of the time when taking backups.
There are no concurrent snapshots going on, but there are concurrent
compactions and repairs, of course. If it matters, this cluster _is_ running
incremental repairs.
This is on Cassandra 4.0.3.
It seems wrong to me that an sstable could ever be written to while it's in a
snapshot.
> sstables changing in snapshots
> --
>
> Key: CASSANDRA-17473
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17473
> Project: Cassandra
> Issue Type: Bug
>Reporter: James Brown
>Priority: Normal
>
> We use cassandra snapshots and
> {tar}
> to make full backups of our cassandra clusters. Sometimes, tar fails with a
> message like
> {{tar:
> data/addresses/addresses-eb0196100b7d11ec852b1541747d640a/snapshots/backup20220318183708/nb-167-big-Data.db:
> file changed as we read it}}
> This is kind of strange, since we're reading from a snapshot.
> The (very simplified) relevant snippet looks roughly like
> {code:java}
> nice nodetool "${JMX_ARGS[@]}" snapshot -t "$TAG" "${KEYSPACES[@]}"
> tar --hard-dereference -czpf data///snapshots/"$TAG"/{code}
> This happens maybe 1% of the time when taking backups.
> There are no concurrent snapshots going on, but there are concurrent
> compactions and repairs, of course. If it matters, this cluster _is_ running
> incremental repairs.
> This is on Cassandra 4.0.3.
> It seems wrong to me that an sstable could ever be written to while it's in a
> snapshot.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17473) sstables changing in snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-17473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Brown updated CASSANDRA-17473:
Description:
We use cassandra snapshots and {tar} to make full backups of our cassandra
clusters. Sometimes, tar fails with a message like
{{tar:
data/addresses/addresses-eb0196100b7d11ec852b1541747d640a/snapshots/backup20220318183708/nb-167-big-Data.db:
file changed as we read it}}
This is kind of strange, since we're reading from a snapshot.
The (very simplified) relevant snippet looks roughly like
{{nice nodetool "${JMX_ARGS[@]}" snapshot -t "$TAG" "${KEYSPACES[@]}"}}
{{tar --hard-dereference -czpf data/*/*/snapshots/"$TAG"/}}
This happens maybe 1% of the time when taking backups.
There are no concurrent snapshots going on, but there are concurrent
compactions and repairs, of course. If it matters, this cluster _is_ running
incremental repairs.
This is on Cassandra 4.0.3.
It seems wrong to me that an sstable could ever be written to while it's in a
snapshot.
was:
We use cassandra snapshots and {tar} to make full backups of our cassandra
clusters. Sometimes, tar fails with a message like
{{tar:
data/addresses/addresses-eb0196100b7d11ec852b1541747d640a/snapshots/backup20220318183708/nb-167-big-Data.db:
file changed as we read it}}
This is kind of strange, since we're reading from a snapshot.
The (very simplified) relevant snippet looks roughly like
{{nice nodetool "${JMX_ARGS[@]}" snapshot -t "$TAG" "${KEYSPACES[@]}"
tar --hard-dereference -czpf data/*/*/snapshots/"$TAG"/}}
This happens maybe 1% of the time when taking backups.
There are no concurrent snapshots going on, but there are concurrent
compactions and repairs, of course. If it matters, this cluster _is_ running
incremental repairs.
This is on Cassandra 4.0.3.
It seems wrong to me that an sstable could ever be written to while it's in a
snapshot.
> sstables changing in snapshots
> --
>
> Key: CASSANDRA-17473
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17473
> Project: Cassandra
> Issue Type: Bug
>Reporter: James Brown
>Priority: Normal
>
> We use cassandra snapshots and {tar} to make full backups of our cassandra
> clusters. Sometimes, tar fails with a message like
> {{tar:
> data/addresses/addresses-eb0196100b7d11ec852b1541747d640a/snapshots/backup20220318183708/nb-167-big-Data.db:
> file changed as we read it}}
> This is kind of strange, since we're reading from a snapshot.
> The (very simplified) relevant snippet looks roughly like
> {{nice nodetool "${JMX_ARGS[@]}" snapshot -t "$TAG" "${KEYSPACES[@]}"}}
> {{tar --hard-dereference -czpf data/*/*/snapshots/"$TAG"/}}
> This happens maybe 1% of the time when taking backups.
> There are no concurrent snapshots going on, but there are concurrent
> compactions and repairs, of course. If it matters, this cluster _is_ running
> incremental repairs.
> This is on Cassandra 4.0.3.
> It seems wrong to me that an sstable could ever be written to while it's in a
> snapshot.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17473) sstables changing in snapshots
James Brown created CASSANDRA-17473:
---
Summary: sstables changing in snapshots
Key: CASSANDRA-17473
URL: https://issues.apache.org/jira/browse/CASSANDRA-17473
Project: Cassandra
Issue Type: Bug
Reporter: James Brown
We use cassandra snapshots and {tar} to make full backups of our cassandra
clusters. Sometimes, tar fails with a message like
{{tar:
data/addresses/addresses-eb0196100b7d11ec852b1541747d640a/snapshots/backup20220318183708/nb-167-big-Data.db:
file changed as we read it}}
This is kind of strange, since we're reading from a snapshot.
The (very simplified) relevant snippet looks roughly like
{{nice nodetool "${JMX_ARGS[@]}" snapshot -t "$TAG" "${KEYSPACES[@]}"
tar --hard-dereference -czpf data/*/*/snapshots/"$TAG"/}}
This happens maybe 1% of the time when taking backups.
There are no concurrent snapshots going on, but there are concurrent
compactions and repairs, of course. If it matters, this cluster _is_ running
incremental repairs.
This is on Cassandra 4.0.3.
It seems wrong to me that an sstable could ever be written to while it's in a
snapshot.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17286) Test Failure: org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion-cdc
[ https://issues.apache.org/jira/browse/CASSANDRA-17286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Meredith updated CASSANDRA-17286: - Since Version: 4.1 Source Control Link: https://github.com/apache/cassandra/commit/4dd0e2391a5adda7fe091cb4e85bd5e648760f78 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Test Failure: > org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion-cdc > --- > > Key: CASSANDRA-17286 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17286 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Josh McKenzie >Assignee: Jon Meredith >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > Looks like it's a straight up flaky test: > > [https://ci-cassandra.apache.org/job/Cassandra-trunk/899/testReport/org.apache.cassandra.db.lifecycle/LogTransactionTest/testGetTemporaryFilesSafeAfterObsoletion_cdc/] > > Failed 3 times in the last 17 runs. Flakiness: 31%, Stability: 82% > h3. Error Message > java.nio.file.NoSuchFileException: > /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db > h3. Stacktrace > java.io.UncheckedIOException: java.nio.file.NoSuchFileException: > /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db > at > org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:695) > at org.apache.cassandra.io.util.PathUtils.toRealPath(PathUtils.java:514) at > org.apache.cassandra.io.util.PathUtils.toCanonicalPath(PathUtils.java:502) at > org.apache.cassandra.io.util.File.toCanonical(File.java:411) at > java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) > at > java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655) > at > java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) > at > java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) > at > java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913) > at > java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) > at > java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578) > at > org.apache.cassandra.db.lifecycle.LogTransactionTest.listFiles(LogTransactionTest.java:1333) > at > org.apache.cassandra.db.lifecycle.LogTransactionTest.getTemporaryFiles(LogTransactionTest.java:1317) > at > org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion(LogTransactionTest.java:1182) > 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) > Caused by: java.nio.file.NoSuchFileException: > /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db > at > java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) > at > java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) > at > java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) > at java.base/sun.nio.fs.UnixPath.toRealPath(UnixPath.java:860) at > org.apache.cassandra.io.util.PathUtils.toRealPath(PathUtils.java:510) -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Test Failure: org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion-cdc
This is an automated email from the ASF dual-hosted git repository.
jonmeredith pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 94580a2 Test Failure:
org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion-cdc
94580a2 is described below
commit 94580a272e77439e4150926a1bd1e723a36236e6
Author: Jon Meredith
AuthorDate: Tue Mar 22 15:14:00 2022 -0600
Test Failure:
org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion-cdc
patch by Jon Meredith; reviewed by Josh McKenzie for CASSANDRA-17286
---
.../cassandra/db/lifecycle/LogTransactionTest.java | 28 +-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git
a/test/unit/org/apache/cassandra/db/lifecycle/LogTransactionTest.java
b/test/unit/org/apache/cassandra/db/lifecycle/LogTransactionTest.java
index 133a51d..2e9cd42 100644
--- a/test/unit/org/apache/cassandra/db/lifecycle/LogTransactionTest.java
+++ b/test/unit/org/apache/cassandra/db/lifecycle/LogTransactionTest.java
@@ -19,7 +19,9 @@ package org.apache.cassandra.db.lifecycle;
import java.io.IOException;
+import java.io.UncheckedIOException;
import java.nio.file.Files;
+import java.nio.file.NoSuchFileException;
import java.util.Arrays;
import java.util.Collection;
import java.util.Collections;
@@ -30,6 +32,7 @@ import java.util.Set;
import java.util.function.BiConsumer;
import java.util.function.Consumer;
import java.util.stream.Collectors;
+import java.util.stream.Stream;
import com.google.common.collect.ImmutableSet;
import com.google.common.collect.Iterables;
@@ -54,6 +57,7 @@ import org.apache.cassandra.io.util.FileHandle;
import org.apache.cassandra.io.util.FileUtils;
import org.apache.cassandra.schema.MockSchema;
import org.apache.cassandra.utils.AlwaysPresentFilter;
+import org.apache.cassandra.utils.Throwables;
import org.apache.cassandra.utils.concurrent.AbstractTransactionalTest;
import org.apache.cassandra.utils.concurrent.Transactional;
@@ -1356,6 +1360,28 @@ public class LogTransactionTest extends
AbstractTransactionalTest
return listFiles(folder, Directories.FileType.FINAL);
}
+// Used by listFiles - this test is deliberately racing with files being
+// removed and cleaned up, so it is possible that files are removed
between listing and getting their
+// canonical names, in which case they can be dropped from the stream.
+private static Stream toCanonicalIgnoringNotFound(File file)
+{
+try
+{
+return Stream.of(file.toCanonical());
+}
+catch (UncheckedIOException io)
+{
+if (Throwables.isCausedBy(io, t -> t instanceof
NoSuchFileException))
+{
+return Stream.empty();
+}
+else
+{
+throw io;
+}
+}
+}
+
static Set listFiles(File folder, Directories.FileType... types)
{
Collection match = Arrays.asList(types);
@@ -1363,7 +1389,7 @@ public class LogTransactionTest extends
AbstractTransactionalTest
(file, type) -> match.contains(type),
Directories.OnTxnErr.IGNORE).list()
.stream()
- .map(File::toCanonical)
+
.flatMap(LogTransactionTest::toCanonicalIgnoringNotFound)
.collect(Collectors.toSet());
}
}
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16304) Consider implementing ClusteringComparator without a lambda
[
https://issues.apache.org/jira/browse/CASSANDRA-16304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510940#comment-17510940
]
Brandon Williams commented on CASSANDRA-16304:
--
It's not abandoned, just inactive due to no need for modification... until now,
potentially.
> Consider implementing ClusteringComparator without a lambda
> ---
>
> Key: CASSANDRA-16304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16304
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Adrian Cole
>Priority: Normal
> Fix For: 4.x
>
>
> Using lambdas forces jamm to do things that can easily break. It might be
> safer to implement things like ClusteringComparator directly as classes or as
> an enum
> {noformat}
> Unexpected exception during request
> (org.apache.cassandra.transport.messages.ErrorMessage)
> java.lang.UnsupportedOperationException: can't get field offset on a hidden
> class: private final org.apache.cassandra.db.ClusteringComparator
> org.apache.cassandra.db.ClusteringComparator$$Lambda$165/0x00010028ab60.arg$1
> at jdk.unsupported/sun.misc.Unsafe.objectFieldOffset(Unknown Source)
> at
> org.github.jamm.MemoryLayoutSpecification.sizeOfInstanceWithUnsafe(MemoryLayoutSpecification.java:108)
> at
> org.github.jamm.MemoryLayoutSpecification.sizeOfWithUnsafe(MemoryLayoutSpecification.java:89)
> at org.github.jamm.MemoryMeter.measure(MemoryMeter.java:217)
> at org.github.jamm.MemoryMeter.measureDeep(MemoryMeter.java:259)
> at
> org.apache.cassandra.utils.ObjectSizes.measureDeep(ObjectSizes.java:155)
> at
> org.apache.cassandra.cql3.QueryProcessor.storePreparedStatement(QueryProcessor.java:454)
> at
> org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:424)
> at
> org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:408)
> at
> org.apache.cassandra.transport.messages.PrepareMessage.execute(PrepareMessage.java:114)
> at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:253)
> at
> org.apache.cassandra.transport.Message$Dispatcher.processRequest(Message.java:725)
> at
> org.apache.cassandra.transport.Message$Dispatcher.lambda$channelRead0$0(Message.java:630)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Unknown Source)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16304) Consider implementing ClusteringComparator without a lambda
[
https://issues.apache.org/jira/browse/CASSANDRA-16304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510931#comment-17510931
]
Sylwester Lachiewicz commented on CASSANDRA-16304:
--
JAMM looks like an abandoned project [https://github.com/jbellis/jamm] - any
potential alternatives?
> Consider implementing ClusteringComparator without a lambda
> ---
>
> Key: CASSANDRA-16304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16304
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Adrian Cole
>Priority: Normal
> Fix For: 4.x
>
>
> Using lambdas forces jamm to do things that can easily break. It might be
> safer to implement things like ClusteringComparator directly as classes or as
> an enum
> {noformat}
> Unexpected exception during request
> (org.apache.cassandra.transport.messages.ErrorMessage)
> java.lang.UnsupportedOperationException: can't get field offset on a hidden
> class: private final org.apache.cassandra.db.ClusteringComparator
> org.apache.cassandra.db.ClusteringComparator$$Lambda$165/0x00010028ab60.arg$1
> at jdk.unsupported/sun.misc.Unsafe.objectFieldOffset(Unknown Source)
> at
> org.github.jamm.MemoryLayoutSpecification.sizeOfInstanceWithUnsafe(MemoryLayoutSpecification.java:108)
> at
> org.github.jamm.MemoryLayoutSpecification.sizeOfWithUnsafe(MemoryLayoutSpecification.java:89)
> at org.github.jamm.MemoryMeter.measure(MemoryMeter.java:217)
> at org.github.jamm.MemoryMeter.measureDeep(MemoryMeter.java:259)
> at
> org.apache.cassandra.utils.ObjectSizes.measureDeep(ObjectSizes.java:155)
> at
> org.apache.cassandra.cql3.QueryProcessor.storePreparedStatement(QueryProcessor.java:454)
> at
> org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:424)
> at
> org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:408)
> at
> org.apache.cassandra.transport.messages.PrepareMessage.execute(PrepareMessage.java:114)
> at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:253)
> at
> org.apache.cassandra.transport.Message$Dispatcher.processRequest(Message.java:725)
> at
> org.apache.cassandra.transport.Message$Dispatcher.lambda$channelRead0$0(Message.java:630)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Unknown Source)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17467) Timestamp issue with Cassandra 4.0.3 with Timezone value
[
https://issues.apache.org/jira/browse/CASSANDRA-17467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17467:
-
Test and Documentation Plan: run CI
Status: Patch Available (was: Open)
> Timestamp issue with Cassandra 4.0.3 with Timezone value
>
>
> Key: CASSANDRA-17467
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17467
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Anand B
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> Hello Team ,
>
> Facing one issue related to the timestamp type in cassandra 4.0.3 version .
> This is not repro in 3.11.x and works fine in 3.11.
>
> when i have table with timestamp as fields :
>
> CREATE TABLE timetest (
> id int PRIMARY KEY,
> enddate timestamp,
> startdate timestamp
> )
> *Now when try to insert the record like :*
> INSERT INTO timetest (id,startdate,enddate) VALUES (1 ,'2022-03-20 12:48:56
> +0530','2022-03-20 12:48:56 +0530')
> I am receiving error:
>
> "{color:#de350b}InvalidRequest{color}: Error from server: code=2200 [Invalid
> query] message="Unable to parse a date/time from '2022-03-20 12:48:56 +0530'".
> **
> *This works fine on 3.11 but fails on 4.x.*
>
> *same issue if we query the record:*
>
> select * from timetest where id = 1 and enddate = '2022-03-20 12:48:56 +0530';
> {color:#de350b}InvalidRequest{color}: Error from server: code=2200 [Invalid
> query] message="Unable to parse a date/time from '2022-03-20 12:48:56 +0530'"
>
>
> {color:#ffab00}*If we change the timestamp value and remove the extra space
> which is present before the timezone value then it works fine in 4.x*{color}
>
> if we change timestamp value From {'2022-03-20 12:48:{color:#de350b}56
> +0530{color}'} To {'2022-03-20 12:48:{color:#ffab00}56+0530{color}’} then
> 4.0.3 accept this value otherwise not. but 3.11 was accepting both the values.
>
> This is causing a challenge for upgrading from 3.11 to 4.x.
>
> Seeking help on this issue and any fix / workaround or suitable Cassandra
> version which is higher than 3.11 but lesser then 4.0.3 which can be used to
> fix this issue asap.
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17217) LocalReadSizeWarningTest#failThresholdSinglePartition is flaky
[
https://issues.apache.org/jira/browse/CASSANDRA-17217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510918#comment-17510918
]
Bernardo Botella Corbi commented on CASSANDRA-17217:
I just updated the PR following [~yifanc] suggestion and splitting the tests.
I've also run the tests over 1000 times with no errors (similarly to what I did
with my previous commit). Hopefully this fixes the flakiness.
Thanks a lot for checking [~adelapena]
> LocalReadSizeWarningTest#failThresholdSinglePartition is flaky
> --
>
> Key: CASSANDRA-17217
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17217
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Bernardo Botella Corbi
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The test
> {{org.apache.cassandra.distributed.test.trackwarnings.LocalReadSizeWarningTest#failThresholdSinglePartition}}
> seems to be flaky.
> It was discovered during CASSANDRA-17195 with [this CI
> run|https://app.circleci.com/pipelines/github/adelapena/cassandra/1217/workflows/b366e352-0862-485a-acdc-5b75fe1ef575/jobs/11188].
> The failure can be reproduced running the test repeatedly for trunk, as it
> can be seen
> [here|https://app.circleci.com/pipelines/github/adelapena/cassandra/1219/workflows/a0c1fb7f-8a07-4fcf-97a4-7caf207dad78].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17467) Timestamp issue with Cassandra 4.0.3 with Timezone value
[
https://issues.apache.org/jira/browse/CASSANDRA-17467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510914#comment-17510914
]
Brandon Williams commented on CASSANDRA-17467:
--
In CASSANDRA-15976, we switched from using
[SimpleDateFormat|https://docs.oracle.com/javase/10/docs/api/java/text/SimpleDateFormat.html]
to
[DateTimeFormatter|https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html]
which have _nearly_ identical formats. Previously this case was caught by the
'-MM-dd HH:mm:ss z' SDF pattern, but 'z' in DTF format does not cover this
and instead needs the 'X' identifier.
||Branch||CI||
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17467-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/405/workflows/1bab3bb5-abf9-4a0e-9ff0-c40288b27038]
,
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/405/workflows/cd5d68ca-c145-4be8-a057-3aca3c350b56]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17467-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/404/workflows/693a48ec-0e75-461d-9ec2-4ed272470622]
,
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/404/workflows/25b0fc44-4770-4cc0-bf82-c76651419818]|
> Timestamp issue with Cassandra 4.0.3 with Timezone value
>
>
> Key: CASSANDRA-17467
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17467
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Anand B
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> Hello Team ,
>
> Facing one issue related to the timestamp type in cassandra 4.0.3 version .
> This is not repro in 3.11.x and works fine in 3.11.
>
> when i have table with timestamp as fields :
>
> CREATE TABLE timetest (
> id int PRIMARY KEY,
> enddate timestamp,
> startdate timestamp
> )
> *Now when try to insert the record like :*
> INSERT INTO timetest (id,startdate,enddate) VALUES (1 ,'2022-03-20 12:48:56
> +0530','2022-03-20 12:48:56 +0530')
> I am receiving error:
>
> "{color:#de350b}InvalidRequest{color}: Error from server: code=2200 [Invalid
> query] message="Unable to parse a date/time from '2022-03-20 12:48:56 +0530'".
> **
> *This works fine on 3.11 but fails on 4.x.*
>
> *same issue if we query the record:*
>
> select * from timetest where id = 1 and enddate = '2022-03-20 12:48:56 +0530';
> {color:#de350b}InvalidRequest{color}: Error from server: code=2200 [Invalid
> query] message="Unable to parse a date/time from '2022-03-20 12:48:56 +0530'"
>
>
> {color:#ffab00}*If we change the timestamp value and remove the extra space
> which is present before the timezone value then it works fine in 4.x*{color}
>
> if we change timestamp value From {'2022-03-20 12:48:{color:#de350b}56
> +0530{color}'} To {'2022-03-20 12:48:{color:#ffab00}56+0530{color}’} then
> 4.0.3 accept this value otherwise not. but 3.11 was accepting both the values.
>
> This is causing a challenge for upgrading from 3.11 to 4.x.
>
> Seeking help on this issue and any fix / workaround or suitable Cassandra
> version which is higher than 3.11 but lesser then 4.0.3 which can be used to
> fix this issue asap.
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17286) Test Failure: org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion-cdc
[ https://issues.apache.org/jira/browse/CASSANDRA-17286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Meredith updated CASSANDRA-17286: - Status: Needs Committer (was: Patch Available) > Test Failure: > org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion-cdc > --- > > Key: CASSANDRA-17286 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17286 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Josh McKenzie >Assignee: Jon Meredith >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > Looks like it's a straight up flaky test: > > [https://ci-cassandra.apache.org/job/Cassandra-trunk/899/testReport/org.apache.cassandra.db.lifecycle/LogTransactionTest/testGetTemporaryFilesSafeAfterObsoletion_cdc/] > > Failed 3 times in the last 17 runs. Flakiness: 31%, Stability: 82% > h3. Error Message > java.nio.file.NoSuchFileException: > /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db > h3. Stacktrace > java.io.UncheckedIOException: java.nio.file.NoSuchFileException: > /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db > at > org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:695) > at org.apache.cassandra.io.util.PathUtils.toRealPath(PathUtils.java:514) at > org.apache.cassandra.io.util.PathUtils.toCanonicalPath(PathUtils.java:502) at > org.apache.cassandra.io.util.File.toCanonical(File.java:411) at > java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) > at > java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655) > at > java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) > at > java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) > at > java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913) > at > java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) > at > java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578) > at > org.apache.cassandra.db.lifecycle.LogTransactionTest.listFiles(LogTransactionTest.java:1333) > at > org.apache.cassandra.db.lifecycle.LogTransactionTest.getTemporaryFiles(LogTransactionTest.java:1317) > at > org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion(LogTransactionTest.java:1182) > 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) > Caused by: java.nio.file.NoSuchFileException: > /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db > at > java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) > at > java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) > at > java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) > at java.base/sun.nio.fs.UnixPath.toRealPath(UnixPath.java:860) at > org.apache.cassandra.io.util.PathUtils.toRealPath(PathUtils.java:510) -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17286) Test Failure: org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion-cdc
[ https://issues.apache.org/jira/browse/CASSANDRA-17286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Meredith updated CASSANDRA-17286: - Status: Ready to Commit (was: Review In Progress) > Test Failure: > org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion-cdc > --- > > Key: CASSANDRA-17286 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17286 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Josh McKenzie >Assignee: Jon Meredith >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > Looks like it's a straight up flaky test: > > [https://ci-cassandra.apache.org/job/Cassandra-trunk/899/testReport/org.apache.cassandra.db.lifecycle/LogTransactionTest/testGetTemporaryFilesSafeAfterObsoletion_cdc/] > > Failed 3 times in the last 17 runs. Flakiness: 31%, Stability: 82% > h3. Error Message > java.nio.file.NoSuchFileException: > /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db > h3. Stacktrace > java.io.UncheckedIOException: java.nio.file.NoSuchFileException: > /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db > at > org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:695) > at org.apache.cassandra.io.util.PathUtils.toRealPath(PathUtils.java:514) at > org.apache.cassandra.io.util.PathUtils.toCanonicalPath(PathUtils.java:502) at > org.apache.cassandra.io.util.File.toCanonical(File.java:411) at > java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) > at > java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655) > at > java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) > at > java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) > at > java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913) > at > java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) > at > java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578) > at > org.apache.cassandra.db.lifecycle.LogTransactionTest.listFiles(LogTransactionTest.java:1333) > at > org.apache.cassandra.db.lifecycle.LogTransactionTest.getTemporaryFiles(LogTransactionTest.java:1317) > at > org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion(LogTransactionTest.java:1182) > 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) > Caused by: java.nio.file.NoSuchFileException: > /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db > at > java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) > at > java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) > at > java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) > at java.base/sun.nio.fs.UnixPath.toRealPath(UnixPath.java:860) at > org.apache.cassandra.io.util.PathUtils.toRealPath(PathUtils.java:510) -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17286) Test Failure: org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion-cdc
[ https://issues.apache.org/jira/browse/CASSANDRA-17286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Meredith updated CASSANDRA-17286: - Status: Review In Progress (was: Needs Committer) > Test Failure: > org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion-cdc > --- > > Key: CASSANDRA-17286 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17286 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Josh McKenzie >Assignee: Jon Meredith >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > Looks like it's a straight up flaky test: > > [https://ci-cassandra.apache.org/job/Cassandra-trunk/899/testReport/org.apache.cassandra.db.lifecycle/LogTransactionTest/testGetTemporaryFilesSafeAfterObsoletion_cdc/] > > Failed 3 times in the last 17 runs. Flakiness: 31%, Stability: 82% > h3. Error Message > java.nio.file.NoSuchFileException: > /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db > h3. Stacktrace > java.io.UncheckedIOException: java.nio.file.NoSuchFileException: > /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db > at > org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:695) > at org.apache.cassandra.io.util.PathUtils.toRealPath(PathUtils.java:514) at > org.apache.cassandra.io.util.PathUtils.toCanonicalPath(PathUtils.java:502) at > org.apache.cassandra.io.util.File.toCanonical(File.java:411) at > java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) > at > java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655) > at > java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) > at > java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) > at > java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913) > at > java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) > at > java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578) > at > org.apache.cassandra.db.lifecycle.LogTransactionTest.listFiles(LogTransactionTest.java:1333) > at > org.apache.cassandra.db.lifecycle.LogTransactionTest.getTemporaryFiles(LogTransactionTest.java:1317) > at > org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion(LogTransactionTest.java:1182) > 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) > Caused by: java.nio.file.NoSuchFileException: > /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db > at > java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) > at > java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) > at > java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) > at java.base/sun.nio.fs.UnixPath.toRealPath(UnixPath.java:860) at > org.apache.cassandra.io.util.PathUtils.toRealPath(PathUtils.java:510) -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17286) Test Failure: org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion-cdc
[ https://issues.apache.org/jira/browse/CASSANDRA-17286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510911#comment-17510911 ] Jon Meredith commented on CASSANDRA-17286: -- Starting commit CI Results (pending): ||Branch||Source||Circle CI||Jenkins|| |trunk|[branch|https://github.com/jonmeredith/cassandra/tree/commit_remote_branch/CASSANDRA-17286-trunk-E28E66B8-C13F-4E4E-904A-B1F1602587F8]|[build|https://app.circleci.com/pipelines/github/jonmeredith/cassandra?branch=commit_remote_branch%2FCASSANDRA-17286-trunk-E28E66B8-C13F-4E4E-904A-B1F1602587F8]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1534/]| > Test Failure: > org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion-cdc > --- > > Key: CASSANDRA-17286 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17286 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Josh McKenzie >Assignee: Jon Meredith >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > Looks like it's a straight up flaky test: > > [https://ci-cassandra.apache.org/job/Cassandra-trunk/899/testReport/org.apache.cassandra.db.lifecycle/LogTransactionTest/testGetTemporaryFilesSafeAfterObsoletion_cdc/] > > Failed 3 times in the last 17 runs. Flakiness: 31%, Stability: 82% > h3. Error Message > java.nio.file.NoSuchFileException: > /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db > h3. Stacktrace > java.io.UncheckedIOException: java.nio.file.NoSuchFileException: > /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db > at > org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:695) > at org.apache.cassandra.io.util.PathUtils.toRealPath(PathUtils.java:514) at > org.apache.cassandra.io.util.PathUtils.toCanonicalPath(PathUtils.java:502) at > org.apache.cassandra.io.util.File.toCanonical(File.java:411) at > java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) > at > java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655) > at > java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) > at > java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) > at > java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913) > at > java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) > at > java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578) > at > org.apache.cassandra.db.lifecycle.LogTransactionTest.listFiles(LogTransactionTest.java:1333) > at > org.apache.cassandra.db.lifecycle.LogTransactionTest.getTemporaryFiles(LogTransactionTest.java:1317) > at > org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion(LogTransactionTest.java:1182) > 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) > Caused by: java.nio.file.NoSuchFileException: > /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db > at > java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) > at > java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) > at > java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) > at java.base/sun.nio.fs.UnixPath.toRealPath(UnixPath.java:860) at > org.apache.cassandra.io.util.PathUtils.toRealPath(PathUtils.java:510) -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17467) Timestamp issue with Cassandra 4.0.3 with Timezone value
[
https://issues.apache.org/jira/browse/CASSANDRA-17467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-17467:
Assignee: Brandon Williams
> Timestamp issue with Cassandra 4.0.3 with Timezone value
>
>
> Key: CASSANDRA-17467
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17467
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Anand B
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> Hello Team ,
>
> Facing one issue related to the timestamp type in cassandra 4.0.3 version .
> This is not repro in 3.11.x and works fine in 3.11.
>
> when i have table with timestamp as fields :
>
> CREATE TABLE timetest (
> id int PRIMARY KEY,
> enddate timestamp,
> startdate timestamp
> )
> *Now when try to insert the record like :*
> INSERT INTO timetest (id,startdate,enddate) VALUES (1 ,'2022-03-20 12:48:56
> +0530','2022-03-20 12:48:56 +0530')
> I am receiving error:
>
> "{color:#de350b}InvalidRequest{color}: Error from server: code=2200 [Invalid
> query] message="Unable to parse a date/time from '2022-03-20 12:48:56 +0530'".
> **
> *This works fine on 3.11 but fails on 4.x.*
>
> *same issue if we query the record:*
>
> select * from timetest where id = 1 and enddate = '2022-03-20 12:48:56 +0530';
> {color:#de350b}InvalidRequest{color}: Error from server: code=2200 [Invalid
> query] message="Unable to parse a date/time from '2022-03-20 12:48:56 +0530'"
>
>
> {color:#ffab00}*If we change the timestamp value and remove the extra space
> which is present before the timezone value then it works fine in 4.x*{color}
>
> if we change timestamp value From {'2022-03-20 12:48:{color:#de350b}56
> +0530{color}'} To {'2022-03-20 12:48:{color:#ffab00}56+0530{color}’} then
> 4.0.3 accept this value otherwise not. but 3.11 was accepting both the values.
>
> This is causing a challenge for upgrading from 3.11 to 4.x.
>
> Seeking help on this issue and any fix / workaround or suitable Cassandra
> version which is higher than 3.11 but lesser then 4.0.3 which can be used to
> fix this issue asap.
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17286) Test Failure: org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion-cdc
[ https://issues.apache.org/jira/browse/CASSANDRA-17286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510848#comment-17510848 ] Josh McKenzie commented on CASSANDRA-17286: --- +1 > Test Failure: > org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion-cdc > --- > > Key: CASSANDRA-17286 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17286 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Josh McKenzie >Assignee: Jon Meredith >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > Looks like it's a straight up flaky test: > > [https://ci-cassandra.apache.org/job/Cassandra-trunk/899/testReport/org.apache.cassandra.db.lifecycle/LogTransactionTest/testGetTemporaryFilesSafeAfterObsoletion_cdc/] > > Failed 3 times in the last 17 runs. Flakiness: 31%, Stability: 82% > h3. Error Message > java.nio.file.NoSuchFileException: > /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db > h3. Stacktrace > java.io.UncheckedIOException: java.nio.file.NoSuchFileException: > /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db > at > org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:695) > at org.apache.cassandra.io.util.PathUtils.toRealPath(PathUtils.java:514) at > org.apache.cassandra.io.util.PathUtils.toCanonicalPath(PathUtils.java:502) at > org.apache.cassandra.io.util.File.toCanonical(File.java:411) at > java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) > at > java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655) > at > java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) > at > java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) > at > java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913) > at > java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) > at > java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578) > at > org.apache.cassandra.db.lifecycle.LogTransactionTest.listFiles(LogTransactionTest.java:1333) > at > org.apache.cassandra.db.lifecycle.LogTransactionTest.getTemporaryFiles(LogTransactionTest.java:1317) > at > org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion(LogTransactionTest.java:1182) > 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) > Caused by: java.nio.file.NoSuchFileException: > /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db > at > java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) > at > java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) > at > java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) > at java.base/sun.nio.fs.UnixPath.toRealPath(UnixPath.java:860) at > org.apache.cassandra.io.util.PathUtils.toRealPath(PathUtils.java:510) -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17286) Test Failure: org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion-cdc
[ https://issues.apache.org/jira/browse/CASSANDRA-17286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17286: -- Reviewers: Josh McKenzie > Test Failure: > org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion-cdc > --- > > Key: CASSANDRA-17286 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17286 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Josh McKenzie >Assignee: Jon Meredith >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > Looks like it's a straight up flaky test: > > [https://ci-cassandra.apache.org/job/Cassandra-trunk/899/testReport/org.apache.cassandra.db.lifecycle/LogTransactionTest/testGetTemporaryFilesSafeAfterObsoletion_cdc/] > > Failed 3 times in the last 17 runs. Flakiness: 31%, Stability: 82% > h3. Error Message > java.nio.file.NoSuchFileException: > /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db > h3. Stacktrace > java.io.UncheckedIOException: java.nio.file.NoSuchFileException: > /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db > at > org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:695) > at org.apache.cassandra.io.util.PathUtils.toRealPath(PathUtils.java:514) at > org.apache.cassandra.io.util.PathUtils.toCanonicalPath(PathUtils.java:502) at > org.apache.cassandra.io.util.File.toCanonical(File.java:411) at > java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) > at > java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655) > at > java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) > at > java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) > at > java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913) > at > java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) > at > java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578) > at > org.apache.cassandra.db.lifecycle.LogTransactionTest.listFiles(LogTransactionTest.java:1333) > at > org.apache.cassandra.db.lifecycle.LogTransactionTest.getTemporaryFiles(LogTransactionTest.java:1317) > at > org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion(LogTransactionTest.java:1182) > 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) > Caused by: java.nio.file.NoSuchFileException: > /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db > at > java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) > at > java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) > at > java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) > at java.base/sun.nio.fs.UnixPath.toRealPath(UnixPath.java:860) at > org.apache.cassandra.io.util.PathUtils.toRealPath(PathUtils.java:510) -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17286) Test Failure: org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion-cdc
[ https://issues.apache.org/jira/browse/CASSANDRA-17286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Meredith updated CASSANDRA-17286: - Test and Documentation Plan: Modified test to tolerate expected race between listing and accessing file. Status: Patch Available (was: Open) > Test Failure: > org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion-cdc > --- > > Key: CASSANDRA-17286 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17286 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Josh McKenzie >Assignee: Jon Meredith >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > Looks like it's a straight up flaky test: > > [https://ci-cassandra.apache.org/job/Cassandra-trunk/899/testReport/org.apache.cassandra.db.lifecycle/LogTransactionTest/testGetTemporaryFilesSafeAfterObsoletion_cdc/] > > Failed 3 times in the last 17 runs. Flakiness: 31%, Stability: 82% > h3. Error Message > java.nio.file.NoSuchFileException: > /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db > h3. Stacktrace > java.io.UncheckedIOException: java.nio.file.NoSuchFileException: > /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db > at > org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:695) > at org.apache.cassandra.io.util.PathUtils.toRealPath(PathUtils.java:514) at > org.apache.cassandra.io.util.PathUtils.toCanonicalPath(PathUtils.java:502) at > org.apache.cassandra.io.util.File.toCanonical(File.java:411) at > java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) > at > java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655) > at > java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) > at > java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) > at > java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913) > at > java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) > at > java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578) > at > org.apache.cassandra.db.lifecycle.LogTransactionTest.listFiles(LogTransactionTest.java:1333) > at > org.apache.cassandra.db.lifecycle.LogTransactionTest.getTemporaryFiles(LogTransactionTest.java:1317) > at > org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion(LogTransactionTest.java:1182) > 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) > Caused by: java.nio.file.NoSuchFileException: > /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db > at > java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) > at > java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) > at > java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) > at java.base/sun.nio.fs.UnixPath.toRealPath(UnixPath.java:860) at > org.apache.cassandra.io.util.PathUtils.toRealPath(PathUtils.java:510) -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17286) Test Failure: org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion-cdc
[ https://issues.apache.org/jira/browse/CASSANDRA-17286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Meredith updated CASSANDRA-17286: - Complexity: Low Hanging Fruit Discovered By: Unit Test Severity: Low Status: Open (was: Triage Needed) > Test Failure: > org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion-cdc > --- > > Key: CASSANDRA-17286 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17286 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Josh McKenzie >Assignee: Jon Meredith >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > Looks like it's a straight up flaky test: > > [https://ci-cassandra.apache.org/job/Cassandra-trunk/899/testReport/org.apache.cassandra.db.lifecycle/LogTransactionTest/testGetTemporaryFilesSafeAfterObsoletion_cdc/] > > Failed 3 times in the last 17 runs. Flakiness: 31%, Stability: 82% > h3. Error Message > java.nio.file.NoSuchFileException: > /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db > h3. Stacktrace > java.io.UncheckedIOException: java.nio.file.NoSuchFileException: > /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db > at > org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:695) > at org.apache.cassandra.io.util.PathUtils.toRealPath(PathUtils.java:514) at > org.apache.cassandra.io.util.PathUtils.toCanonicalPath(PathUtils.java:502) at > org.apache.cassandra.io.util.File.toCanonical(File.java:411) at > java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) > at > java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655) > at > java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) > at > java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) > at > java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913) > at > java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) > at > java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578) > at > org.apache.cassandra.db.lifecycle.LogTransactionTest.listFiles(LogTransactionTest.java:1333) > at > org.apache.cassandra.db.lifecycle.LogTransactionTest.getTemporaryFiles(LogTransactionTest.java:1317) > at > org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion(LogTransactionTest.java:1182) > 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) > Caused by: java.nio.file.NoSuchFileException: > /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db > at > java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) > at > java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) > at > java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) > at java.base/sun.nio.fs.UnixPath.toRealPath(UnixPath.java:860) at > org.apache.cassandra.io.util.PathUtils.toRealPath(PathUtils.java:510) -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17286) Test Failure: org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion-cdc
[ https://issues.apache.org/jira/browse/CASSANDRA-17286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510847#comment-17510847 ] Jon Meredith commented on CASSANDRA-17286: -- Fault due to concurrently listing a directory followed by operations on the files while files are being removed concurrently. Modify listFiles to ignore NoSuchFileExceptions on the stream of listed files. [Branch|https://github.com/jonmeredith/cassandra/tree/C17286-trunk] [PR|https://github.com/apache/cassandra/pull/1519] [CircleCI|https://app.circleci.com/pipelines/github/jonmeredith/cassandra?branch=C17286-trunk=all] > Test Failure: > org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion-cdc > --- > > Key: CASSANDRA-17286 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17286 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Josh McKenzie >Assignee: Jon Meredith >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > Looks like it's a straight up flaky test: > > [https://ci-cassandra.apache.org/job/Cassandra-trunk/899/testReport/org.apache.cassandra.db.lifecycle/LogTransactionTest/testGetTemporaryFilesSafeAfterObsoletion_cdc/] > > Failed 3 times in the last 17 runs. Flakiness: 31%, Stability: 82% > h3. Error Message > java.nio.file.NoSuchFileException: > /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db > h3. Stacktrace > java.io.UncheckedIOException: java.nio.file.NoSuchFileException: > /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db > at > org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:695) > at org.apache.cassandra.io.util.PathUtils.toRealPath(PathUtils.java:514) at > org.apache.cassandra.io.util.PathUtils.toCanonicalPath(PathUtils.java:502) at > org.apache.cassandra.io.util.File.toCanonical(File.java:411) at > java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) > at > java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655) > at > java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) > at > java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) > at > java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913) > at > java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) > at > java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578) > at > org.apache.cassandra.db.lifecycle.LogTransactionTest.listFiles(LogTransactionTest.java:1333) > at > org.apache.cassandra.db.lifecycle.LogTransactionTest.getTemporaryFiles(LogTransactionTest.java:1317) > at > org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion(LogTransactionTest.java:1182) > 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) > Caused by: java.nio.file.NoSuchFileException: > /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db > at > java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) > at > java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) > at > java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) > at java.base/sun.nio.fs.UnixPath.toRealPath(UnixPath.java:860) at > org.apache.cassandra.io.util.PathUtils.toRealPath(PathUtils.java:510) -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17472) On CFS.flushLargestMemtable, log candidate at info instead of debug
[
https://issues.apache.org/jira/browse/CASSANDRA-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17472:
--
Fix Version/s: 4.1
Source Control Link:
https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=commit;h=fbd6b047915d9810bf5e3131ba11c9374b3834a3
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed. Thanks [~brandon.williams]
> On CFS.flushLargestMemtable, log candidate at info instead of debug
> ---
>
> Key: CASSANDRA-17472
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17472
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Memtable
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 4.1
>
>
> When flushing the largest memtable in
> {{{}ColumnFamilyStore.flushLargestMemtable{}}}, we should log at info that a
> memtable was flushed due to this case rather than at debug. We don't expect
> this to trigger often and this information is useful for operators and
> shouldn't require elevated logging to see it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17472) On CFS.flushLargestMemtable, log candidate at info instead of debug
[
https://issues.apache.org/jira/browse/CASSANDRA-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17472:
--
Status: Ready to Commit (was: Review In Progress)
> On CFS.flushLargestMemtable, log candidate at info instead of debug
> ---
>
> Key: CASSANDRA-17472
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17472
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Memtable
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> When flushing the largest memtable in
> {{{}ColumnFamilyStore.flushLargestMemtable{}}}, we should log at info that a
> memtable was flushed due to this case rather than at debug. We don't expect
> this to trigger often and this information is useful for operators and
> shouldn't require elevated logging to see it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17472) On CFS.flushLargestMemtable, log candidate at info instead of debug
[
https://issues.apache.org/jira/browse/CASSANDRA-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17472:
--
Status: Review In Progress (was: Patch Available)
> On CFS.flushLargestMemtable, log candidate at info instead of debug
> ---
>
> Key: CASSANDRA-17472
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17472
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Memtable
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> When flushing the largest memtable in
> {{{}ColumnFamilyStore.flushLargestMemtable{}}}, we should log at info that a
> memtable was flushed due to this case rather than at debug. We don't expect
> this to trigger often and this information is useful for operators and
> shouldn't require elevated logging to see it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Log largest memtable on flush at info rather than debug
This is an automated email from the ASF dual-hosted git repository.
jmckenzie pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new fbd6b04 Log largest memtable on flush at info rather than debug
fbd6b04 is described below
commit fbd6b047915d9810bf5e3131ba11c9374b3834a3
Author: Josh McKenzie
AuthorDate: Tue Mar 22 12:41:58 2022 -0400
Log largest memtable on flush at info rather than debug
Patch by Josh McKenzie; reviewed by Brandon Williams for CASSANDRA-17472
---
CHANGES.txt | 1 +
src/java/org/apache/cassandra/db/ColumnFamilyStore.java | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index e8bc60b..d54a5a7 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.1
+ * Log largest memtable flush at info instead of debug (CASSANDRA-17472)
* Add native transport rate limiter options to example cassandra.yaml, and
expose metric for dispatch rate (CASSANDRA-17423)
* Add diagnostic events for guardrails (CASSANDRA-17197)
* Increase cqlsh version (CASSANDRA-17432)
diff --git a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
index b257790..906e109 100644
--- a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
+++ b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
@@ -1344,7 +1344,7 @@ public class ColumnFamilyStore implements
ColumnFamilyStoreMBean
float flushingOffHeap =
Memtable.MEMORY_POOL.offHeap.reclaimingRatio();
float thisOnHeap =
largest.getAllocator().onHeap().ownershipRatio();
float thisOffHeap =
largest.getAllocator().offHeap().ownershipRatio();
-logger.debug("Flushing largest {} to free up room. Used total: {},
live: {}, flushing: {}, this: {}",
+logger.info("Flushing largest {} to free up room. Used total: {},
live: {}, flushing: {}, this: {}",
largest.cfs, ratio(usedOnHeap, usedOffHeap),
ratio(liveOnHeap, liveOffHeap),
ratio(flushingOnHeap, flushingOffHeap),
ratio(thisOnHeap, thisOffHeap));
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17472) On CFS.flushLargestMemtable, log candidate at info instead of debug
[
https://issues.apache.org/jira/browse/CASSANDRA-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17472:
--
Reviewers: Brandon Williams
> On CFS.flushLargestMemtable, log candidate at info instead of debug
> ---
>
> Key: CASSANDRA-17472
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17472
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Memtable
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> When flushing the largest memtable in
> {{{}ColumnFamilyStore.flushLargestMemtable{}}}, we should log at info that a
> memtable was flushed due to this case rather than at debug. We don't expect
> this to trigger often and this information is useful for operators and
> shouldn't require elevated logging to see it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17471) Provide JMX endpoint for transient full logging of blocking read repairs
[ https://issues.apache.org/jira/browse/CASSANDRA-17471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510838#comment-17510838 ] Josh McKenzie commented on CASSANDRA-17471: --- CI looks clean. 1 failing unit test unrelated, 1 failing dtest unrelated. > Provide JMX endpoint for transient full logging of blocking read repairs > > > Key: CASSANDRA-17471 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17471 > Project: Cassandra > Issue Type: New Feature > Components: Observability/Logging >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > While working with live clusters that have elevated blocking read repairs (a > not uncommon scenario), it'd be helpful to have the ability to enable full > logging of blocking read repairs for a finite amount of time to get insight > into what's going on without having to heavily disrupt a cluster with a > bounce or config change. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-11262) Repair scheduling - Global configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-11262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas reassigned CASSANDRA-11262: Assignee: Marcus Olsson (was: C. Scott Andreas) > Repair scheduling - Global configuration > > > Key: CASSANDRA-11262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11262 > Project: Cassandra > Issue Type: Sub-task > Components: Consistency/Repair >Reporter: Marcus Olsson >Assignee: Marcus Olsson >Priority: Low > > Make it possible to configure the maintenance scheduler on all nodes. Should > include the possibility to pause repairs on all nodes. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-11262) Repair scheduling - Global configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-11262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas reassigned CASSANDRA-11262: Assignee: C. Scott Andreas (was: Marcus Olsson) > Repair scheduling - Global configuration > > > Key: CASSANDRA-11262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11262 > Project: Cassandra > Issue Type: Sub-task > Components: Consistency/Repair >Reporter: Marcus Olsson >Assignee: C. Scott Andreas >Priority: Low > > Make it possible to configure the maintenance scheduler on all nodes. Should > include the possibility to pause repairs on all nodes. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17467) Timestamp issue with Cassandra 4.0.3 with Timezone value
[
https://issues.apache.org/jira/browse/CASSANDRA-17467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510825#comment-17510825
]
Brandon Williams commented on CASSANDRA-17467:
--
Release times cannot be predicted in project, but I will push for one when this
is completed.
> Timestamp issue with Cassandra 4.0.3 with Timezone value
>
>
> Key: CASSANDRA-17467
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17467
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Anand B
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> Hello Team ,
>
> Facing one issue related to the timestamp type in cassandra 4.0.3 version .
> This is not repro in 3.11.x and works fine in 3.11.
>
> when i have table with timestamp as fields :
>
> CREATE TABLE timetest (
> id int PRIMARY KEY,
> enddate timestamp,
> startdate timestamp
> )
> *Now when try to insert the record like :*
> INSERT INTO timetest (id,startdate,enddate) VALUES (1 ,'2022-03-20 12:48:56
> +0530','2022-03-20 12:48:56 +0530')
> I am receiving error:
>
> "{color:#de350b}InvalidRequest{color}: Error from server: code=2200 [Invalid
> query] message="Unable to parse a date/time from '2022-03-20 12:48:56 +0530'".
> **
> *This works fine on 3.11 but fails on 4.x.*
>
> *same issue if we query the record:*
>
> select * from timetest where id = 1 and enddate = '2022-03-20 12:48:56 +0530';
> {color:#de350b}InvalidRequest{color}: Error from server: code=2200 [Invalid
> query] message="Unable to parse a date/time from '2022-03-20 12:48:56 +0530'"
>
>
> {color:#ffab00}*If we change the timestamp value and remove the extra space
> which is present before the timezone value then it works fine in 4.x*{color}
>
> if we change timestamp value From {'2022-03-20 12:48:{color:#de350b}56
> +0530{color}'} To {'2022-03-20 12:48:{color:#ffab00}56+0530{color}’} then
> 4.0.3 accept this value otherwise not. but 3.11 was accepting both the values.
>
> This is causing a challenge for upgrading from 3.11 to 4.x.
>
> Seeking help on this issue and any fix / workaround or suitable Cassandra
> version which is higher than 3.11 but lesser then 4.0.3 which can be used to
> fix this issue asap.
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17467) Timestamp issue with Cassandra 4.0.3 with Timezone value
[
https://issues.apache.org/jira/browse/CASSANDRA-17467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510825#comment-17510825
]
Brandon Williams edited comment on CASSANDRA-17467 at 3/22/22, 6:45 PM:
Release times cannot be predicted in the project, but I will push for one when
this is completed.
was (Author: brandon.williams):
Release times cannot be predicted in project, but I will push for one when this
is completed.
> Timestamp issue with Cassandra 4.0.3 with Timezone value
>
>
> Key: CASSANDRA-17467
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17467
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Anand B
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> Hello Team ,
>
> Facing one issue related to the timestamp type in cassandra 4.0.3 version .
> This is not repro in 3.11.x and works fine in 3.11.
>
> when i have table with timestamp as fields :
>
> CREATE TABLE timetest (
> id int PRIMARY KEY,
> enddate timestamp,
> startdate timestamp
> )
> *Now when try to insert the record like :*
> INSERT INTO timetest (id,startdate,enddate) VALUES (1 ,'2022-03-20 12:48:56
> +0530','2022-03-20 12:48:56 +0530')
> I am receiving error:
>
> "{color:#de350b}InvalidRequest{color}: Error from server: code=2200 [Invalid
> query] message="Unable to parse a date/time from '2022-03-20 12:48:56 +0530'".
> **
> *This works fine on 3.11 but fails on 4.x.*
>
> *same issue if we query the record:*
>
> select * from timetest where id = 1 and enddate = '2022-03-20 12:48:56 +0530';
> {color:#de350b}InvalidRequest{color}: Error from server: code=2200 [Invalid
> query] message="Unable to parse a date/time from '2022-03-20 12:48:56 +0530'"
>
>
> {color:#ffab00}*If we change the timestamp value and remove the extra space
> which is present before the timezone value then it works fine in 4.x*{color}
>
> if we change timestamp value From {'2022-03-20 12:48:{color:#de350b}56
> +0530{color}'} To {'2022-03-20 12:48:{color:#ffab00}56+0530{color}’} then
> 4.0.3 accept this value otherwise not. but 3.11 was accepting both the values.
>
> This is causing a challenge for upgrading from 3.11 to 4.x.
>
> Seeking help on this issue and any fix / workaround or suitable Cassandra
> version which is higher than 3.11 but lesser then 4.0.3 which can be used to
> fix this issue asap.
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17467) Timestamp issue with Cassandra 4.0.3 with Timezone value
[
https://issues.apache.org/jira/browse/CASSANDRA-17467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510824#comment-17510824
]
Anand B edited comment on CASSANDRA-17467 at 3/22/22, 6:44 PM:
---
Thanks [~brandon.williams] .
*Any tentative timeline , when 4.0.4 release will be out ?*
This will help us to plan accordingly.
was (Author: JIRAUSER286890):
Thanks [~brandon.williams] .
Any tentative timeline , when 4.0.4 release will be out ?
This will help us to plan accordingly.
> Timestamp issue with Cassandra 4.0.3 with Timezone value
>
>
> Key: CASSANDRA-17467
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17467
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Anand B
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> Hello Team ,
>
> Facing one issue related to the timestamp type in cassandra 4.0.3 version .
> This is not repro in 3.11.x and works fine in 3.11.
>
> when i have table with timestamp as fields :
>
> CREATE TABLE timetest (
> id int PRIMARY KEY,
> enddate timestamp,
> startdate timestamp
> )
> *Now when try to insert the record like :*
> INSERT INTO timetest (id,startdate,enddate) VALUES (1 ,'2022-03-20 12:48:56
> +0530','2022-03-20 12:48:56 +0530')
> I am receiving error:
>
> "{color:#de350b}InvalidRequest{color}: Error from server: code=2200 [Invalid
> query] message="Unable to parse a date/time from '2022-03-20 12:48:56 +0530'".
> **
> *This works fine on 3.11 but fails on 4.x.*
>
> *same issue if we query the record:*
>
> select * from timetest where id = 1 and enddate = '2022-03-20 12:48:56 +0530';
> {color:#de350b}InvalidRequest{color}: Error from server: code=2200 [Invalid
> query] message="Unable to parse a date/time from '2022-03-20 12:48:56 +0530'"
>
>
> {color:#ffab00}*If we change the timestamp value and remove the extra space
> which is present before the timezone value then it works fine in 4.x*{color}
>
> if we change timestamp value From {'2022-03-20 12:48:{color:#de350b}56
> +0530{color}'} To {'2022-03-20 12:48:{color:#ffab00}56+0530{color}’} then
> 4.0.3 accept this value otherwise not. but 3.11 was accepting both the values.
>
> This is causing a challenge for upgrading from 3.11 to 4.x.
>
> Seeking help on this issue and any fix / workaround or suitable Cassandra
> version which is higher than 3.11 but lesser then 4.0.3 which can be used to
> fix this issue asap.
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17467) Timestamp issue with Cassandra 4.0.3 with Timezone value
[
https://issues.apache.org/jira/browse/CASSANDRA-17467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510824#comment-17510824
]
Anand B commented on CASSANDRA-17467:
-
Thanks [~brandon.williams] .
Any tentative timeline , when 4.0.4 release will be out ?
This will help us to plan accordingly.
> Timestamp issue with Cassandra 4.0.3 with Timezone value
>
>
> Key: CASSANDRA-17467
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17467
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Anand B
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> Hello Team ,
>
> Facing one issue related to the timestamp type in cassandra 4.0.3 version .
> This is not repro in 3.11.x and works fine in 3.11.
>
> when i have table with timestamp as fields :
>
> CREATE TABLE timetest (
> id int PRIMARY KEY,
> enddate timestamp,
> startdate timestamp
> )
> *Now when try to insert the record like :*
> INSERT INTO timetest (id,startdate,enddate) VALUES (1 ,'2022-03-20 12:48:56
> +0530','2022-03-20 12:48:56 +0530')
> I am receiving error:
>
> "{color:#de350b}InvalidRequest{color}: Error from server: code=2200 [Invalid
> query] message="Unable to parse a date/time from '2022-03-20 12:48:56 +0530'".
> **
> *This works fine on 3.11 but fails on 4.x.*
>
> *same issue if we query the record:*
>
> select * from timetest where id = 1 and enddate = '2022-03-20 12:48:56 +0530';
> {color:#de350b}InvalidRequest{color}: Error from server: code=2200 [Invalid
> query] message="Unable to parse a date/time from '2022-03-20 12:48:56 +0530'"
>
>
> {color:#ffab00}*If we change the timestamp value and remove the extra space
> which is present before the timezone value then it works fine in 4.x*{color}
>
> if we change timestamp value From {'2022-03-20 12:48:{color:#de350b}56
> +0530{color}'} To {'2022-03-20 12:48:{color:#ffab00}56+0530{color}’} then
> 4.0.3 accept this value otherwise not. but 3.11 was accepting both the values.
>
> This is causing a challenge for upgrading from 3.11 to 4.x.
>
> Seeking help on this issue and any fix / workaround or suitable Cassandra
> version which is higher than 3.11 but lesser then 4.0.3 which can be used to
> fix this issue asap.
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17286) Test Failure: org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion-cdc
[ https://issues.apache.org/jira/browse/CASSANDRA-17286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Meredith reassigned CASSANDRA-17286: Assignee: Jon Meredith (was: Josh McKenzie) > Test Failure: > org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion-cdc > --- > > Key: CASSANDRA-17286 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17286 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Josh McKenzie >Assignee: Jon Meredith >Priority: Normal > Fix For: 4.x > > > Looks like it's a straight up flaky test: > > [https://ci-cassandra.apache.org/job/Cassandra-trunk/899/testReport/org.apache.cassandra.db.lifecycle/LogTransactionTest/testGetTemporaryFilesSafeAfterObsoletion_cdc/] > > Failed 3 times in the last 17 runs. Flakiness: 31%, Stability: 82% > h3. Error Message > java.nio.file.NoSuchFileException: > /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db > h3. Stacktrace > java.io.UncheckedIOException: java.nio.file.NoSuchFileException: > /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db > at > org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:695) > at org.apache.cassandra.io.util.PathUtils.toRealPath(PathUtils.java:514) at > org.apache.cassandra.io.util.PathUtils.toCanonicalPath(PathUtils.java:502) at > org.apache.cassandra.io.util.File.toCanonical(File.java:411) at > java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) > at > java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655) > at > java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) > at > java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) > at > java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913) > at > java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) > at > java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578) > at > org.apache.cassandra.db.lifecycle.LogTransactionTest.listFiles(LogTransactionTest.java:1333) > at > org.apache.cassandra.db.lifecycle.LogTransactionTest.getTemporaryFiles(LogTransactionTest.java:1317) > at > org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion(LogTransactionTest.java:1182) > 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) > Caused by: java.nio.file.NoSuchFileException: > /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db > at > java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) > at > java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) > at > java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) > at java.base/sun.nio.fs.UnixPath.toRealPath(UnixPath.java:860) at > org.apache.cassandra.io.util.PathUtils.toRealPath(PathUtils.java:510) -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17281) Remove support for Javascript UDF from trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-17281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova reassigned CASSANDRA-17281: --- Assignee: (was: Ekaterina Dimitrova) > Remove support for Javascript UDF from trunk > > > Key: CASSANDRA-17281 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17281 > Project: Cassandra > Issue Type: Task > Components: Feature/UDF >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > [Consensus |https://lists.apache.org/thread/mnxh94lg9v94bfntq88051z3ww16q2fk] > was reached to remove JavaScript UDF with the next major release. > We need to leave an interface for those who would like to supply a UDF > implementation. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-11871) Allow to aggregate by time intervals
[
https://issues.apache.org/jira/browse/CASSANDRA-11871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510792#comment-17510792
]
Benjamin Lerer edited comment on CASSANDRA-11871 at 3/22/22, 5:51 PM:
--
[PR|https://github.com/apache/cassandra/pull/1510]
[DTest PR|https://github.com/apache/cassandra-dtest/pull/178]
[CI|https://app.circleci.com/pipelines/github/blerer/cassandra/275/workflows/2214fd4c-c6aa-412e-ab3a-bd89f451bc5b]
The patch refactors the code to allow the use of native monotonic scalar
functions on the last element of the GROUP BY clause.
It also introduces a new floor function that can be use to group rows by time
intervals
was (Author: blerer):
[PR|https://github.com/apache/cassandra/pull/1510]
[DTest PR|https://github.com/apache/cassandra-dtest/pull/178]
[CI|https://app.circleci.com/pipelines/github/blerer/cassandra/275/workflows/2214fd4c-c6aa-412e-ab3a-bd89f451bc5b]
> Allow to aggregate by time intervals
>
>
> Key: CASSANDRA-11871
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11871
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.x
>
>
> For time series data it can be usefull to aggregate by time intervals.
> The idea would be to add support for one or several functions in the {{GROUP
> BY}} clause.
> Regarding the implementation, even if in general I also prefer to follow the
> SQL syntax, I do not believe it will be a good fit for Cassandra.
> If we have a table like:
> {code}
> CREATE TABLE trades
> {
> symbol text,
> date date,
> time time,
> priceMantissa int,
> priceExponent tinyint,
> volume int,
> PRIMARY KEY ((symbol, date), time)
> };
> {code}
> The trades will be inserted with an increasing time and sorted in the same
> order. As we can have to process a large amount of data, we want to try to
> limit ourself to the cases where we can build the groups on the flight (which
> is not a requirement in the SQL world).
> If we want to get the number of trades per minutes with the SQL syntax we
> will have to write:
> {{SELECT hour(time), minute(time), count() FROM Trades WHERE symbol = 'AAPL'
> AND date = '2016-01-11' GROUP BY hour(time), minute(time);}}
> which is fine. The problem is that if the user invert by mistake the
> functions like that:
> {{SELECT hour(time), minute(time), count() FROM Trades WHERE symbol = 'AAPL'
> AND date = '2016-01-11' GROUP BY minute(time), hour(time);}}
> the query will return weird results.
> The only way to prevent that would be to check the function order and make
> sure that we do not allow to skip functions (e.g. {{GROUP BY hour(time),
> second(time)}}).
> In my opinion a function like {{floor(, )}} will be
> much better as it does not allow for this type of mistakes and is much more
> flexible (you can create 5 minutes buckets if you want to).
> {{SELECT floor(time, m), count() FROM Trades WHERE symbol = 'AAPL' AND date =
> '2016-01-11' GROUP BY floor(time, m);}}
> An important aspect to keep in mind with a function like {{floor}} is the
> starting point. For a query like: {{SELECT floor(time, m), count() FROM
> Trades WHERE symbol = 'AAPL' AND date = '2016-01-11' AND time >= '01:30:00'
> AND time =< '07:30:00' GROUP BY floor(time, 2h);}}, I think that ideally the
> result should return 3 groups: {{01:30:00}}, {{03:30:00}} and {{05:30:00}}.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-11871) Allow to aggregate by time intervals
[
https://issues.apache.org/jira/browse/CASSANDRA-11871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-11871:
---
Test and Documentation Plan: The patch add new unit tests and DTests
Status: Patch Available (was: In Progress)
> Allow to aggregate by time intervals
>
>
> Key: CASSANDRA-11871
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11871
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.x
>
>
> For time series data it can be usefull to aggregate by time intervals.
> The idea would be to add support for one or several functions in the {{GROUP
> BY}} clause.
> Regarding the implementation, even if in general I also prefer to follow the
> SQL syntax, I do not believe it will be a good fit for Cassandra.
> If we have a table like:
> {code}
> CREATE TABLE trades
> {
> symbol text,
> date date,
> time time,
> priceMantissa int,
> priceExponent tinyint,
> volume int,
> PRIMARY KEY ((symbol, date), time)
> };
> {code}
> The trades will be inserted with an increasing time and sorted in the same
> order. As we can have to process a large amount of data, we want to try to
> limit ourself to the cases where we can build the groups on the flight (which
> is not a requirement in the SQL world).
> If we want to get the number of trades per minutes with the SQL syntax we
> will have to write:
> {{SELECT hour(time), minute(time), count() FROM Trades WHERE symbol = 'AAPL'
> AND date = '2016-01-11' GROUP BY hour(time), minute(time);}}
> which is fine. The problem is that if the user invert by mistake the
> functions like that:
> {{SELECT hour(time), minute(time), count() FROM Trades WHERE symbol = 'AAPL'
> AND date = '2016-01-11' GROUP BY minute(time), hour(time);}}
> the query will return weird results.
> The only way to prevent that would be to check the function order and make
> sure that we do not allow to skip functions (e.g. {{GROUP BY hour(time),
> second(time)}}).
> In my opinion a function like {{floor(, )}} will be
> much better as it does not allow for this type of mistakes and is much more
> flexible (you can create 5 minutes buckets if you want to).
> {{SELECT floor(time, m), count() FROM Trades WHERE symbol = 'AAPL' AND date =
> '2016-01-11' GROUP BY floor(time, m);}}
> An important aspect to keep in mind with a function like {{floor}} is the
> starting point. For a query like: {{SELECT floor(time, m), count() FROM
> Trades WHERE symbol = 'AAPL' AND date = '2016-01-11' AND time >= '01:30:00'
> AND time =< '07:30:00' GROUP BY floor(time, 2h);}}, I think that ideally the
> result should return 3 groups: {{01:30:00}}, {{03:30:00}} and {{05:30:00}}.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-11871) Allow to aggregate by time intervals
[
https://issues.apache.org/jira/browse/CASSANDRA-11871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510792#comment-17510792
]
Benjamin Lerer edited comment on CASSANDRA-11871 at 3/22/22, 5:46 PM:
--
[PR|https://github.com/apache/cassandra/pull/1510]
[DTest PR|https://github.com/apache/cassandra-dtest/pull/178]
[CI|https://app.circleci.com/pipelines/github/blerer/cassandra/275/workflows/2214fd4c-c6aa-412e-ab3a-bd89f451bc5b]
was (Author: blerer):
[PR|https://github.com/apache/cassandra/pull/1510]
[CI|https://app.circleci.com/pipelines/github/blerer/cassandra/275/workflows/2214fd4c-c6aa-412e-ab3a-bd89f451bc5b]
[DTest PR|https://github.com/apache/cassandra-dtest/pull/178]
> Allow to aggregate by time intervals
>
>
> Key: CASSANDRA-11871
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11871
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.x
>
>
> For time series data it can be usefull to aggregate by time intervals.
> The idea would be to add support for one or several functions in the {{GROUP
> BY}} clause.
> Regarding the implementation, even if in general I also prefer to follow the
> SQL syntax, I do not believe it will be a good fit for Cassandra.
> If we have a table like:
> {code}
> CREATE TABLE trades
> {
> symbol text,
> date date,
> time time,
> priceMantissa int,
> priceExponent tinyint,
> volume int,
> PRIMARY KEY ((symbol, date), time)
> };
> {code}
> The trades will be inserted with an increasing time and sorted in the same
> order. As we can have to process a large amount of data, we want to try to
> limit ourself to the cases where we can build the groups on the flight (which
> is not a requirement in the SQL world).
> If we want to get the number of trades per minutes with the SQL syntax we
> will have to write:
> {{SELECT hour(time), minute(time), count() FROM Trades WHERE symbol = 'AAPL'
> AND date = '2016-01-11' GROUP BY hour(time), minute(time);}}
> which is fine. The problem is that if the user invert by mistake the
> functions like that:
> {{SELECT hour(time), minute(time), count() FROM Trades WHERE symbol = 'AAPL'
> AND date = '2016-01-11' GROUP BY minute(time), hour(time);}}
> the query will return weird results.
> The only way to prevent that would be to check the function order and make
> sure that we do not allow to skip functions (e.g. {{GROUP BY hour(time),
> second(time)}}).
> In my opinion a function like {{floor(, )}} will be
> much better as it does not allow for this type of mistakes and is much more
> flexible (you can create 5 minutes buckets if you want to).
> {{SELECT floor(time, m), count() FROM Trades WHERE symbol = 'AAPL' AND date =
> '2016-01-11' GROUP BY floor(time, m);}}
> An important aspect to keep in mind with a function like {{floor}} is the
> starting point. For a query like: {{SELECT floor(time, m), count() FROM
> Trades WHERE symbol = 'AAPL' AND date = '2016-01-11' AND time >= '01:30:00'
> AND time =< '07:30:00' GROUP BY floor(time, 2h);}}, I think that ideally the
> result should return 3 groups: {{01:30:00}}, {{03:30:00}} and {{05:30:00}}.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-11871) Allow to aggregate by time intervals
[
https://issues.apache.org/jira/browse/CASSANDRA-11871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510792#comment-17510792
]
Benjamin Lerer commented on CASSANDRA-11871:
[PR|https://github.com/apache/cassandra/pull/1510]
[CI|https://app.circleci.com/pipelines/github/blerer/cassandra/275/workflows/2214fd4c-c6aa-412e-ab3a-bd89f451bc5b]
[DTest PR|https://github.com/apache/cassandra-dtest/pull/178]
> Allow to aggregate by time intervals
>
>
> Key: CASSANDRA-11871
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11871
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.x
>
>
> For time series data it can be usefull to aggregate by time intervals.
> The idea would be to add support for one or several functions in the {{GROUP
> BY}} clause.
> Regarding the implementation, even if in general I also prefer to follow the
> SQL syntax, I do not believe it will be a good fit for Cassandra.
> If we have a table like:
> {code}
> CREATE TABLE trades
> {
> symbol text,
> date date,
> time time,
> priceMantissa int,
> priceExponent tinyint,
> volume int,
> PRIMARY KEY ((symbol, date), time)
> };
> {code}
> The trades will be inserted with an increasing time and sorted in the same
> order. As we can have to process a large amount of data, we want to try to
> limit ourself to the cases where we can build the groups on the flight (which
> is not a requirement in the SQL world).
> If we want to get the number of trades per minutes with the SQL syntax we
> will have to write:
> {{SELECT hour(time), minute(time), count() FROM Trades WHERE symbol = 'AAPL'
> AND date = '2016-01-11' GROUP BY hour(time), minute(time);}}
> which is fine. The problem is that if the user invert by mistake the
> functions like that:
> {{SELECT hour(time), minute(time), count() FROM Trades WHERE symbol = 'AAPL'
> AND date = '2016-01-11' GROUP BY minute(time), hour(time);}}
> the query will return weird results.
> The only way to prevent that would be to check the function order and make
> sure that we do not allow to skip functions (e.g. {{GROUP BY hour(time),
> second(time)}}).
> In my opinion a function like {{floor(, )}} will be
> much better as it does not allow for this type of mistakes and is much more
> flexible (you can create 5 minutes buckets if you want to).
> {{SELECT floor(time, m), count() FROM Trades WHERE symbol = 'AAPL' AND date =
> '2016-01-11' GROUP BY floor(time, m);}}
> An important aspect to keep in mind with a function like {{floor}} is the
> starting point. For a query like: {{SELECT floor(time, m), count() FROM
> Trades WHERE symbol = 'AAPL' AND date = '2016-01-11' AND time >= '01:30:00'
> AND time =< '07:30:00' GROUP BY floor(time, 2h);}}, I think that ideally the
> result should return 3 groups: {{01:30:00}}, {{03:30:00}} and {{05:30:00}}.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17472) On CFS.flushLargestMemtable, log candidate at info instead of debug
[
https://issues.apache.org/jira/browse/CASSANDRA-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510752#comment-17510752
]
Brandon Williams commented on CASSANDRA-17472:
--
+1 when CI returns with nothing interesting.
> On CFS.flushLargestMemtable, log candidate at info instead of debug
> ---
>
> Key: CASSANDRA-17472
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17472
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Memtable
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> When flushing the largest memtable in
> {{{}ColumnFamilyStore.flushLargestMemtable{}}}, we should log at info that a
> memtable was flushed due to this case rather than at debug. We don't expect
> this to trigger often and this information is useful for operators and
> shouldn't require elevated logging to see it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17458) Test Failure: org.apache.cassandra.db.SinglePartitionSliceCommandTest.testPartitionDeletionRangeDeletionTie
[
https://issues.apache.org/jira/browse/CASSANDRA-17458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17458:
-
Complexity: Normal
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> Test Failure:
> org.apache.cassandra.db.SinglePartitionSliceCommandTest.testPartitionDeletionRangeDeletionTie
> ---
>
> Key: CASSANDRA-17458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17458
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Intermittent failure on
> {{org.apache.cassandra.db.SinglePartitionSliceCommandTest#testPartitionDeletionRangeDeletionTie}}
> for trunk:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1024/testReport/org.apache.cassandra.db/SinglePartitionSliceCommandTest/testPartitionDeletionRangeDeletionTie/]
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1018/testReport/org.apache.cassandra.db/SinglePartitionSliceCommandTest/testPartitionDeletionRangeDeletionTie/]
> {code:java}
> Failed 1 times in the last 11 runs. Flakiness: 10%, Stability: 90%
> Error Message
> Expected [Row[info=[ts=11] ]: c1=1, c2=1 | [v=1 ts=11]] but got [Marker
> INCL_START_BOUND(1, 1)@10/1647704834, Row[info=[ts=11] ]: c1=1, c2=1 | [v=1
> ts=11], Marker INCL_END_BOUND(1, 1)@10/1647704834] expected:<[[[v=1 ts=11]]]>
> but was:<[org.apache.cassandra.db.rows.RangeTombstoneBoundMarker@3db1ed73,
> [[v=1 ts=11]],
> org.apache.cassandra.db.rows.RangeTombstoneBoundMarker@1ea92553]>
> Stacktrace
> junit.framework.AssertionFailedError: Expected [Row[info=[ts=11] ]: c1=1,
> c2=1 | [v=1 ts=11]] but got [Marker INCL_START_BOUND(1, 1)@10/1647704834,
> Row[info=[ts=11] ]: c1=1, c2=1 | [v=1 ts=11], Marker INCL_END_BOUND(1,
> 1)@10/1647704834] expected:<[[[v=1 ts=11]]]> but
> was:<[org.apache.cassandra.db.rows.RangeTombstoneBoundMarker@3db1ed73, [[v=1
> ts=11]], org.apache.cassandra.db.rows.RangeTombstoneBoundMarker@1ea92553]>
> at
> org.apache.cassandra.db.SinglePartitionSliceCommandTest.testPartitionDeletionRangeDeletionTie(SinglePartitionSliceCommandTest.java:463)
> 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)
> Standard Output
> INFO [main] 2022-03-19 15:51:43,646 YamlConfigurationLoader.java:103 -
> Configuration location:
> file:/home/cassandra/cassandra/test/conf/cassandra.yaml
> DEBUG [main] 2022-03-19 15:51:43,653 YamlConfigurationLoader.java:124 -
> Loading settings from file:/home/cassandra/cassandra/test/conf/cassandra.yaml
> INFO [main] 2022-03-19 15:51:43,971 Config.java:1119 - Node
> configuration:[allocate_tokens_for_keyspace=null;
> allocate_tokens_for_local_replication_factor=null;
> allow_extra_insecure_udfs=false; all
> ...[truncated 192995 chars]...
> ome/cassandra/cassandra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-37-big-Data.db:level=0,
>
> /home/cassandra/cassandra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-39-big-Data.db:level=0,
>
> /home/cassandra/cassandra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-38-big-Data.db:level=0,
>
> /home/cassandra/cassandra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-40-big-Data.db:level=0,
> ]
> {code}
> Failures can also be hit with CircleCI test multiplexer:
> [https://app.circleci.com/pipelines/github/adelapena/cassandra/1387/workflows/0f37a726-1dc2-4584-86f9-e99ecc40f551]
> CircleCI results show failures on three separate assertions, with a ~3%
> flakiness.
> The same test looks ok in 4.0, as suggested by Butler and [this repeated
> Circle
> run|https://app.circleci.com/pipelines/github/adelapena/cassandra/1388/workflows/6b69d654-3d19-4f2a-aeb9-dc405c6ddd2b].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17458) Test Failure: org.apache.cassandra.db.SinglePartitionSliceCommandTest.testPartitionDeletionRangeDeletionTie
[
https://issues.apache.org/jira/browse/CASSANDRA-17458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510750#comment-17510750
]
Brandon Williams commented on CASSANDRA-17458:
--
[~sathyakplm] that's simply not enough iterations. You can loop the test in
bash 100 times like this:
{code}
$ for x in `seq 1 100`;do ant testsome
-Dtest.name=org.apache.cassandra.db.SinglePartitionSliceCommandTest
-Dtest.methods=testPartitionDeletionRangeDeletionTie || break; done
{code}
and it will fail before completing the iterations.
> Test Failure:
> org.apache.cassandra.db.SinglePartitionSliceCommandTest.testPartitionDeletionRangeDeletionTie
> ---
>
> Key: CASSANDRA-17458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17458
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Intermittent failure on
> {{org.apache.cassandra.db.SinglePartitionSliceCommandTest#testPartitionDeletionRangeDeletionTie}}
> for trunk:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1024/testReport/org.apache.cassandra.db/SinglePartitionSliceCommandTest/testPartitionDeletionRangeDeletionTie/]
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1018/testReport/org.apache.cassandra.db/SinglePartitionSliceCommandTest/testPartitionDeletionRangeDeletionTie/]
> {code:java}
> Failed 1 times in the last 11 runs. Flakiness: 10%, Stability: 90%
> Error Message
> Expected [Row[info=[ts=11] ]: c1=1, c2=1 | [v=1 ts=11]] but got [Marker
> INCL_START_BOUND(1, 1)@10/1647704834, Row[info=[ts=11] ]: c1=1, c2=1 | [v=1
> ts=11], Marker INCL_END_BOUND(1, 1)@10/1647704834] expected:<[[[v=1 ts=11]]]>
> but was:<[org.apache.cassandra.db.rows.RangeTombstoneBoundMarker@3db1ed73,
> [[v=1 ts=11]],
> org.apache.cassandra.db.rows.RangeTombstoneBoundMarker@1ea92553]>
> Stacktrace
> junit.framework.AssertionFailedError: Expected [Row[info=[ts=11] ]: c1=1,
> c2=1 | [v=1 ts=11]] but got [Marker INCL_START_BOUND(1, 1)@10/1647704834,
> Row[info=[ts=11] ]: c1=1, c2=1 | [v=1 ts=11], Marker INCL_END_BOUND(1,
> 1)@10/1647704834] expected:<[[[v=1 ts=11]]]> but
> was:<[org.apache.cassandra.db.rows.RangeTombstoneBoundMarker@3db1ed73, [[v=1
> ts=11]], org.apache.cassandra.db.rows.RangeTombstoneBoundMarker@1ea92553]>
> at
> org.apache.cassandra.db.SinglePartitionSliceCommandTest.testPartitionDeletionRangeDeletionTie(SinglePartitionSliceCommandTest.java:463)
> 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)
> Standard Output
> INFO [main] 2022-03-19 15:51:43,646 YamlConfigurationLoader.java:103 -
> Configuration location:
> file:/home/cassandra/cassandra/test/conf/cassandra.yaml
> DEBUG [main] 2022-03-19 15:51:43,653 YamlConfigurationLoader.java:124 -
> Loading settings from file:/home/cassandra/cassandra/test/conf/cassandra.yaml
> INFO [main] 2022-03-19 15:51:43,971 Config.java:1119 - Node
> configuration:[allocate_tokens_for_keyspace=null;
> allocate_tokens_for_local_replication_factor=null;
> allow_extra_insecure_udfs=false; all
> ...[truncated 192995 chars]...
> ome/cassandra/cassandra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-37-big-Data.db:level=0,
>
> /home/cassandra/cassandra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-39-big-Data.db:level=0,
>
> /home/cassandra/cassandra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-38-big-Data.db:level=0,
>
> /home/cassandra/cassandra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-40-big-Data.db:level=0,
> ]
> {code}
> Failures can also be hit with CircleCI test multiplexer:
> [https://app.circleci.com/pipelines/github/adelapena/cassandra/1387/workflows/0f37a726-1dc2-4584-86f9-e99ecc40f551]
> CircleCI results show failures on three separate assertions, with a ~3%
> flakiness.
> The same test looks ok in 4.0, as suggested by Butler and [this repeated
> Circle
> run|https://app.circleci.com/pipelines/github/adelapena/cassandra/1388/workflows/6b69d654-3d19-4f2a-aeb9-dc405c6ddd2b].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17472) On CFS.flushLargestMemtable, log candidate at info instead of debug
[
https://issues.apache.org/jira/browse/CASSANDRA-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17472:
--
Test and Documentation Plan: No new testing or documentation needed.
Status: Patch Available (was: Open)
> On CFS.flushLargestMemtable, log candidate at info instead of debug
> ---
>
> Key: CASSANDRA-17472
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17472
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Memtable
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> When flushing the largest memtable in
> {{{}ColumnFamilyStore.flushLargestMemtable{}}}, we should log at info that a
> memtable was flushed due to this case rather than at debug. We don't expect
> this to trigger often and this information is useful for operators and
> shouldn't require elevated logging to see it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17472) On CFS.flushLargestMemtable, log candidate at info instead of debug
[
https://issues.apache.org/jira/browse/CASSANDRA-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17472:
--
Change Category: Operability
Complexity: Low Hanging Fruit
Status: Open (was: Triage Needed)
> On CFS.flushLargestMemtable, log candidate at info instead of debug
> ---
>
> Key: CASSANDRA-17472
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17472
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Memtable
>Reporter: Josh McKenzie
>Priority: Normal
>
> When flushing the largest memtable in
> {{{}ColumnFamilyStore.flushLargestMemtable{}}}, we should log at info that a
> memtable was flushed due to this case rather than at debug. We don't expect
> this to trigger often and this information is useful for operators and
> shouldn't require elevated logging to see it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17472) On CFS.flushLargestMemtable, log candidate at info instead of debug
[
https://issues.apache.org/jira/browse/CASSANDRA-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie reassigned CASSANDRA-17472:
-
Assignee: Josh McKenzie
> On CFS.flushLargestMemtable, log candidate at info instead of debug
> ---
>
> Key: CASSANDRA-17472
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17472
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Memtable
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> When flushing the largest memtable in
> {{{}ColumnFamilyStore.flushLargestMemtable{}}}, we should log at info that a
> memtable was flushed due to this case rather than at debug. We don't expect
> this to trigger often and this information is useful for operators and
> shouldn't require elevated logging to see it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17472) On CFS.flushLargestMemtable, log candidate at info instead of debug
[
https://issues.apache.org/jira/browse/CASSANDRA-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510745#comment-17510745
]
Josh McKenzie commented on CASSANDRA-17472:
---
[PR|https://github.com/apache/cassandra/pull/1518]
[JDK8
CI|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/187/workflows/40d6f589-2ff2-48fd-b676-564ae2e29865]
[JDK11
CI|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/187/workflows/7a7da043-1728-4944-927d-4b7820986312]
> On CFS.flushLargestMemtable, log candidate at info instead of debug
> ---
>
> Key: CASSANDRA-17472
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17472
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Memtable
>Reporter: Josh McKenzie
>Priority: Normal
>
> When flushing the largest memtable in
> {{{}ColumnFamilyStore.flushLargestMemtable{}}}, we should log at info that a
> memtable was flushed due to this case rather than at debug. We don't expect
> this to trigger often and this information is useful for operators and
> shouldn't require elevated logging to see it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17472) On CFS.flushLargestMemtable, log candidate at info instead of debug
Josh McKenzie created CASSANDRA-17472:
-
Summary: On CFS.flushLargestMemtable, log candidate at info
instead of debug
Key: CASSANDRA-17472
URL: https://issues.apache.org/jira/browse/CASSANDRA-17472
Project: Cassandra
Issue Type: Improvement
Components: Local/Memtable
Reporter: Josh McKenzie
When flushing the largest memtable in
{{{}ColumnFamilyStore.flushLargestMemtable{}}}, we should log at info that a
memtable was flushed due to this case rather than at debug. We don't expect
this to trigger often and this information is useful for operators and
shouldn't require elevated logging to see it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17395) WEBSITE - homepage update
[ https://issues.apache.org/jira/browse/CASSANDRA-17395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRA-17395: --- Labels: pull-request-available (was: ) > WEBSITE - homepage update > - > > Key: CASSANDRA-17395 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17395 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Fix For: NA > > > This ticket is to capture the work associated with updating the Apache > Cassandra homepage and a few edits to blog posts to fix incorrect dates and > text. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17471) Provide JMX endpoint for transient full logging of blocking read repairs
[ https://issues.apache.org/jira/browse/CASSANDRA-17471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510736#comment-17510736 ] Josh McKenzie commented on CASSANDRA-17471: --- [PR|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/185/workflows/f185d636-4af8-40d8-8f87-fbeba0c84cd6] [JDK8 CI|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/185/workflows/ea3548a5-3903-47be-a50a-83a39bffd4b6] [JDK11 CI|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/185/workflows/f185d636-4af8-40d8-8f87-fbeba0c84cd6] > Provide JMX endpoint for transient full logging of blocking read repairs > > > Key: CASSANDRA-17471 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17471 > Project: Cassandra > Issue Type: New Feature > Components: Observability/Logging >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > While working with live clusters that have elevated blocking read repairs (a > not uncommon scenario), it'd be helpful to have the ability to enable full > logging of blocking read repairs for a finite amount of time to get insight > into what's going on without having to heavily disrupt a cluster with a > bounce or config change. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17471) Provide JMX endpoint for transient full logging of blocking read repairs
[ https://issues.apache.org/jira/browse/CASSANDRA-17471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17471: -- Test and Documentation Plan: No added documentation nor testing needed; JMX endpoint addition for operators Status: Patch Available (was: Open) > Provide JMX endpoint for transient full logging of blocking read repairs > > > Key: CASSANDRA-17471 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17471 > Project: Cassandra > Issue Type: New Feature > Components: Observability/Logging >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > While working with live clusters that have elevated blocking read repairs (a > not uncommon scenario), it'd be helpful to have the ability to enable full > logging of blocking read repairs for a finite amount of time to get insight > into what's going on without having to heavily disrupt a cluster with a > bounce or config change. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17471) Provide JMX endpoint for transient full logging of blocking read repairs
[ https://issues.apache.org/jira/browse/CASSANDRA-17471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17471: -- Change Category: Operability Complexity: Low Hanging Fruit Status: Open (was: Triage Needed) > Provide JMX endpoint for transient full logging of blocking read repairs > > > Key: CASSANDRA-17471 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17471 > Project: Cassandra > Issue Type: New Feature > Components: Observability/Logging >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > While working with live clusters that have elevated blocking read repairs (a > not uncommon scenario), it'd be helpful to have the ability to enable full > logging of blocking read repairs for a finite amount of time to get insight > into what's going on without having to heavily disrupt a cluster with a > bounce or config change. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17395) WEBSITE - homepage update
[ https://issues.apache.org/jira/browse/CASSANDRA-17395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17395: - Status: Patch Available (was: Open) https://github.com/apache/cassandra-website/pull/113 > WEBSITE - homepage update > - > > Key: CASSANDRA-17395 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17395 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > Fix For: NA > > > This ticket is to capture the work associated with updating the Apache > Cassandra homepage and a few edits to blog posts to fix incorrect dates and > text. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17395) WEBSITE - homepage update
[ https://issues.apache.org/jira/browse/CASSANDRA-17395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17395: - Fix Version/s: NA Status: Open (was: Triage Needed) > WEBSITE - homepage update > - > > Key: CASSANDRA-17395 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17395 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > Fix For: NA > > > This ticket is to capture the work associated with updating the Apache > Cassandra homepage and a few edits to blog posts to fix incorrect dates and > text. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17458) Test Failure: org.apache.cassandra.db.SinglePartitionSliceCommandTest.testPartitionDeletionRangeDeletionTie
[
https://issues.apache.org/jira/browse/CASSANDRA-17458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510729#comment-17510729
]
Sathyanarayanan Saravanamuthu commented on CASSANDRA-17458:
---
[~adelapena] , I tried running the test 11 times and it did not fail even once.
Do we have any way to reproduce. I tried this in trunk.
> Test Failure:
> org.apache.cassandra.db.SinglePartitionSliceCommandTest.testPartitionDeletionRangeDeletionTie
> ---
>
> Key: CASSANDRA-17458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17458
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Intermittent failure on
> {{org.apache.cassandra.db.SinglePartitionSliceCommandTest#testPartitionDeletionRangeDeletionTie}}
> for trunk:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1024/testReport/org.apache.cassandra.db/SinglePartitionSliceCommandTest/testPartitionDeletionRangeDeletionTie/]
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1018/testReport/org.apache.cassandra.db/SinglePartitionSliceCommandTest/testPartitionDeletionRangeDeletionTie/]
> {code:java}
> Failed 1 times in the last 11 runs. Flakiness: 10%, Stability: 90%
> Error Message
> Expected [Row[info=[ts=11] ]: c1=1, c2=1 | [v=1 ts=11]] but got [Marker
> INCL_START_BOUND(1, 1)@10/1647704834, Row[info=[ts=11] ]: c1=1, c2=1 | [v=1
> ts=11], Marker INCL_END_BOUND(1, 1)@10/1647704834] expected:<[[[v=1 ts=11]]]>
> but was:<[org.apache.cassandra.db.rows.RangeTombstoneBoundMarker@3db1ed73,
> [[v=1 ts=11]],
> org.apache.cassandra.db.rows.RangeTombstoneBoundMarker@1ea92553]>
> Stacktrace
> junit.framework.AssertionFailedError: Expected [Row[info=[ts=11] ]: c1=1,
> c2=1 | [v=1 ts=11]] but got [Marker INCL_START_BOUND(1, 1)@10/1647704834,
> Row[info=[ts=11] ]: c1=1, c2=1 | [v=1 ts=11], Marker INCL_END_BOUND(1,
> 1)@10/1647704834] expected:<[[[v=1 ts=11]]]> but
> was:<[org.apache.cassandra.db.rows.RangeTombstoneBoundMarker@3db1ed73, [[v=1
> ts=11]], org.apache.cassandra.db.rows.RangeTombstoneBoundMarker@1ea92553]>
> at
> org.apache.cassandra.db.SinglePartitionSliceCommandTest.testPartitionDeletionRangeDeletionTie(SinglePartitionSliceCommandTest.java:463)
> 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)
> Standard Output
> INFO [main] 2022-03-19 15:51:43,646 YamlConfigurationLoader.java:103 -
> Configuration location:
> file:/home/cassandra/cassandra/test/conf/cassandra.yaml
> DEBUG [main] 2022-03-19 15:51:43,653 YamlConfigurationLoader.java:124 -
> Loading settings from file:/home/cassandra/cassandra/test/conf/cassandra.yaml
> INFO [main] 2022-03-19 15:51:43,971 Config.java:1119 - Node
> configuration:[allocate_tokens_for_keyspace=null;
> allocate_tokens_for_local_replication_factor=null;
> allow_extra_insecure_udfs=false; all
> ...[truncated 192995 chars]...
> ome/cassandra/cassandra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-37-big-Data.db:level=0,
>
> /home/cassandra/cassandra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-39-big-Data.db:level=0,
>
> /home/cassandra/cassandra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-38-big-Data.db:level=0,
>
> /home/cassandra/cassandra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-40-big-Data.db:level=0,
> ]
> {code}
> Failures can also be hit with CircleCI test multiplexer:
> [https://app.circleci.com/pipelines/github/adelapena/cassandra/1387/workflows/0f37a726-1dc2-4584-86f9-e99ecc40f551]
> CircleCI results show failures on three separate assertions, with a ~3%
> flakiness.
> The same test looks ok in 4.0, as suggested by Butler and [this repeated
> Circle
> run|https://app.circleci.com/pipelines/github/adelapena/cassandra/1388/workflows/6b69d654-3d19-4f2a-aeb9-dc405c6ddd2b].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17468) WEBSITE - blog corrections and fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-17468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17468: - Status: Patch Available (was: Open) https://github.com/apache/cassandra-website/pull/112 > WEBSITE - blog corrections and fixes > > > Key: CASSANDRA-17468 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17468 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Fix For: NA > > > This ticket is to capture the work associated with updating/fixing the Apache > Cassandra website with text/formatting/link edits. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17468) WEBSITE - blog corrections and fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-17468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17468: - Fix Version/s: NA Status: Open (was: Triage Needed) > WEBSITE - blog corrections and fixes > > > Key: CASSANDRA-17468 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17468 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Fix For: NA > > > This ticket is to capture the work associated with updating/fixing the Apache > Cassandra website with text/formatting/link edits. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17468) WEBSITE - blog corrections and fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-17468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRA-17468: --- Labels: pull-request-available (was: ) > WEBSITE - blog corrections and fixes > > > Key: CASSANDRA-17468 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17468 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > > This ticket is to capture the work associated with updating/fixing the Apache > Cassandra website with text/formatting/link edits. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17468) WEBSITE - blog corrections and fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-17468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17468: - Summary: WEBSITE - blog corrections and fixes (was: WEBSITE - content updates and fixes) > WEBSITE - blog corrections and fixes > > > Key: CASSANDRA-17468 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17468 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Priority: Normal > > This ticket is to capture the work associated with updating/fixing the Apache > Cassandra website with text/formatting/link edits. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17468) WEBSITE - content updates and fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-17468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17468: - Test and Documentation Plan: Blogs: * "Apache Cassandra and Java SE 11 support" date corrected * "Apache Cassandra Changelog #12" formatting fix * "Using Arithmetic Operators in Cassandra 4.0" formatting fix * "Behind the scenes of an Apache Cassandra Release" formatting fix was: Blogs: * "Apache Cassandra and Java SE 11 support" date corrected * "Apache Cassandra Changelog #12" formatting fix * "Behind the scenes of an Apache Cassandra Release" formatting fix > WEBSITE - content updates and fixes > --- > > Key: CASSANDRA-17468 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17468 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Priority: Normal > > This ticket is to capture the work associated with updating/fixing the Apache > Cassandra website with text/formatting/link edits. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17471) Provide JMX endpoint for transient full logging of blocking read repairs
[ https://issues.apache.org/jira/browse/CASSANDRA-17471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie reassigned CASSANDRA-17471: - Assignee: Josh McKenzie > Provide JMX endpoint for transient full logging of blocking read repairs > > > Key: CASSANDRA-17471 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17471 > Project: Cassandra > Issue Type: New Feature > Components: Observability/Logging >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > While working with live clusters that have elevated blocking read repairs (a > not uncommon scenario), it'd be helpful to have the ability to enable full > logging of blocking read repairs for a finite amount of time to get insight > into what's going on without having to heavily disrupt a cluster with a > bounce or config change. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17471) Provide JMX endpoint for transient full logging of blocking read repairs
Josh McKenzie created CASSANDRA-17471: - Summary: Provide JMX endpoint for transient full logging of blocking read repairs Key: CASSANDRA-17471 URL: https://issues.apache.org/jira/browse/CASSANDRA-17471 Project: Cassandra Issue Type: New Feature Components: Observability/Logging Reporter: Josh McKenzie While working with live clusters that have elevated blocking read repairs (a not uncommon scenario), it'd be helpful to have the ability to enable full logging of blocking read repairs for a finite amount of time to get insight into what's going on without having to heavily disrupt a cluster with a bounce or config change. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17448) allow users to change cqlsh history location using env variable
[ https://issues.apache.org/jira/browse/CASSANDRA-17448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510695#comment-17510695 ] Brandon Williams commented on CASSANDRA-17448: -- bq. I am building it as we speak, will put it here later. Well, that is part of the review. > allow users to change cqlsh history location using env variable > --- > > Key: CASSANDRA-17448 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17448 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1 > > > User on GH sent: > I just started using cassandra and found that it creates history folder in my > home directory. I personally don't like it and all my folders follow XDG > standard. I found stackoverflow question related to it which says that it's > not possible to do without configuring source code of cqlsh.py. > In this pull request I added a feature to choose history directory using > environment variable. The name of variable is CQL_HISTORY. Why ? Because > postgres and node-repl use approximately the same convention > (NODE_REPL_HISTORY,PSQL_HISTORY). If you want I can change the name. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17017) Add required -f / --force option to nodetool verify
[ https://issues.apache.org/jira/browse/CASSANDRA-17017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510693#comment-17510693 ] Brandon Williams commented on CASSANDRA-17017: -- bq. Didn't realize I had to change it in 34 different places. bq. give the custom dtest in circle testing one more shot The generate.sh script can handle all this for you. Hope that helps. > Add required -f / --force option to nodetool verify > --- > > Key: CASSANDRA-17017 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17017 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.1 > > > nodetool verify has some pretty significant problems with it (see > CASSANDRA-9947). > Until such time as we do the heavy(er) lift to fix the command, we should > make it harder for people to shoot themselves in the foot with it. Adding a > required "-f" flag to it with a requisite "Do you really know what you're > doing? Check out this JIRA first" seems like it'd be the right thing to do in > the interim. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17448) allow users to change cqlsh history location using env variable
[ https://issues.apache.org/jira/browse/CASSANDRA-17448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510691#comment-17510691 ] Stefan Miklosovic commented on CASSANDRA-17448: --- [~brandon.williams] would you mind to review? Same PR [https://github.com/apache/cassandra/pull/1508/files] I am building it as we speak, will put it here later. > allow users to change cqlsh history location using env variable > --- > > Key: CASSANDRA-17448 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17448 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1 > > > User on GH sent: > I just started using cassandra and found that it creates history folder in my > home directory. I personally don't like it and all my folders follow XDG > standard. I found stackoverflow question related to it which says that it's > not possible to do without configuring source code of cqlsh.py. > In this pull request I added a feature to choose history directory using > environment variable. The name of variable is CQL_HISTORY. Why ? Because > postgres and node-repl use approximately the same convention > (NODE_REPL_HISTORY,PSQL_HISTORY). If you want I can change the name. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17266) DESCRIBE KEYSPACE / MATERIALIZED VIEW generates invalid CQL for views
[
https://issues.apache.org/jira/browse/CASSANDRA-17266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-17266:
--
Status: Patch Available (was: In Progress)
> DESCRIBE KEYSPACE / MATERIALIZED VIEW generates invalid CQL for views
> -
>
> Key: CASSANDRA-17266
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17266
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Oleg Zhovtanyuk
>Assignee: Stefan Miklosovic
>Priority: Normal
> Labels: lhf
> Fix For: 4.0.x
>
>
> Materialized views do not allow default_time_to_live option in CQL (see
> CASSANDRA-12868).
> But, if the MV was created without this option, DESCRIBE KEYSPACE /
> MATERIALIZED VIEW command generates CQL that includes it.
> E.g.
> {code:java}
> CREATE KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> USE test;
> CREATE TABLE test_table(
> id text,
> date text,
> col1 text,
> col2 text,
> PRIMARY KEY(id,date)
> ) WITH default_time_to_live = 60 AND CLUSTERING ORDER BY (date DESC);
> CREATE MATERIALIZED VIEW test_view AS
> SELECT id, date, col1
> FROM test_table
> WHERE id IS NOT NULL AND date IS NOT NULL
> PRIMARY KEY(id, date);{code}
> It is OK.
> {code:java}
> DESCRIBE MATERIALIZED VIEW test_view; {code}
> returns the same CQL + all default options:
> {code:java}
> CREATE MATERIALIZED VIEW test.test_view AS
> SELECT id, date, col1
> FROM test.test_table
> WHERE id IS NOT NULL AND date IS NOT NULL
> PRIMARY KEY (id, date)
> WITH CLUSTERING ORDER BY (date ASC)
> AND additional_write_policy = '99p'
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND cdc = false
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '16', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND default_time_to_live = 0
> AND extensions = {}
> 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 = 'BLOCKING'
> AND speculative_retry = '99p';
> {code}
> Note the 'default_time_to_live = 0' clause! If this veiw is dropped,
> re-creating it using DESCRIBE output would fail with
> {noformat}
> Cannot set default_time_to_live for a materialized view. Data in a
> materialized view always expire at the same time than the corresponding data
> in the parent table.{noformat}
> +Additional Information for newcomers:+
> The code writting the table parameters is in {{TableParams.appendCqlTo}} and
> is called through {{TableMetadata.appendTableOptions}}. Those method will
> need to have a new parameter specifying if the call is for a table or a
> materialized view.
> Some unit test need to be adapted in {{DescribeStatementTest}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17266) DESCRIBE KEYSPACE / MATERIALIZED VIEW generates invalid CQL for views
[
https://issues.apache.org/jira/browse/CASSANDRA-17266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510685#comment-17510685
]
Stefan Miklosovic commented on CASSANDRA-17266:
---
4.0 [https://github.com/instaclustr/cassandra/tree/CASSANDRA-17266-4.0]
trunk [https://github.com/instaclustr/cassandra/tree/CASSANDRA-17266]
modified dtest -
[https://github.com/smiklosovic/cassandra-dtest/tree/CASSANDRA-17266]
build 4.0:
[https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1532/]
build trunk:
[https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1533/]
> DESCRIBE KEYSPACE / MATERIALIZED VIEW generates invalid CQL for views
> -
>
> Key: CASSANDRA-17266
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17266
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Oleg Zhovtanyuk
>Assignee: Stefan Miklosovic
>Priority: Normal
> Labels: lhf
> Fix For: 4.0.x
>
>
> Materialized views do not allow default_time_to_live option in CQL (see
> CASSANDRA-12868).
> But, if the MV was created without this option, DESCRIBE KEYSPACE /
> MATERIALIZED VIEW command generates CQL that includes it.
> E.g.
> {code:java}
> CREATE KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> USE test;
> CREATE TABLE test_table(
> id text,
> date text,
> col1 text,
> col2 text,
> PRIMARY KEY(id,date)
> ) WITH default_time_to_live = 60 AND CLUSTERING ORDER BY (date DESC);
> CREATE MATERIALIZED VIEW test_view AS
> SELECT id, date, col1
> FROM test_table
> WHERE id IS NOT NULL AND date IS NOT NULL
> PRIMARY KEY(id, date);{code}
> It is OK.
> {code:java}
> DESCRIBE MATERIALIZED VIEW test_view; {code}
> returns the same CQL + all default options:
> {code:java}
> CREATE MATERIALIZED VIEW test.test_view AS
> SELECT id, date, col1
> FROM test.test_table
> WHERE id IS NOT NULL AND date IS NOT NULL
> PRIMARY KEY (id, date)
> WITH CLUSTERING ORDER BY (date ASC)
> AND additional_write_policy = '99p'
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND cdc = false
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '16', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND default_time_to_live = 0
> AND extensions = {}
> 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 = 'BLOCKING'
> AND speculative_retry = '99p';
> {code}
> Note the 'default_time_to_live = 0' clause! If this veiw is dropped,
> re-creating it using DESCRIBE output would fail with
> {noformat}
> Cannot set default_time_to_live for a materialized view. Data in a
> materialized view always expire at the same time than the corresponding data
> in the parent table.{noformat}
> +Additional Information for newcomers:+
> The code writting the table parameters is in {{TableParams.appendCqlTo}} and
> is called through {{TableMetadata.appendTableOptions}}. Those method will
> need to have a new parameter specifying if the call is for a table or a
> materialized view.
> Some unit test need to be adapted in {{DescribeStatementTest}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17470) Default directory permissions for /var/lib/cassandra could be more restrictive
[
https://issues.apache.org/jira/browse/CASSANDRA-17470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17470:
-
Change Category: Operability
Complexity: Normal
Component/s: Packaging
Fix Version/s: 4.x
Status: Open (was: Triage Needed)
> Default directory permissions for /var/lib/cassandra could be more restrictive
> --
>
> Key: CASSANDRA-17470
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17470
> Project: Cassandra
> Issue Type: Improvement
> Components: Packaging
>Reporter: Sebastian Schulze
>Priority: Normal
> Fix For: 4.x
>
>
> I noticed that the default permissions for /var/lib/cassandra and everything
> below seem to be "world readable", e.g. "{{{}drwxr-xr-x 6 cassandra
> cassandra{}}}".
> It might depend on the distribution / package used, but I can at least
> confirm this for the official Cassandra Debian packages as well as the Docker
> containers. Out of curiosity I compared it to Postgres and MySQL to see which
> defaults they would opt for and they are
> {{drwxr-x--- 2 mysql mysql 4.0K Mar 22 10:00 mysql}}
> and respectively
> {{drwx-- 19 postgres postgres 4.0K Mar 22 10:01 data}}
> which is way more appropriate in my option. ([Here is a Gist with the script
> to compare
> them|https://gist.github.com/bascht/31fa749d4121b9898902d5d557a01f82])
> If there is no particular reason behind this, I would suggest that the
> default packages should have stricter ulimits that restricts access to the
> data directory to the cassandra user & group.
> (See also this [mailing list
> thread|https://lists.apache.org/thread/gyoqb4xnq4ry0c726f0ntz83rvn0w5kx])
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17470) Default directory permissions for /var/lib/cassandra could be more restrictive
Sebastian Schulze created CASSANDRA-17470:
-
Summary: Default directory permissions for /var/lib/cassandra
could be more restrictive
Key: CASSANDRA-17470
URL: https://issues.apache.org/jira/browse/CASSANDRA-17470
Project: Cassandra
Issue Type: Improvement
Reporter: Sebastian Schulze
I noticed that the default permissions for /var/lib/cassandra and everything
below seem to be "world readable", e.g. "{{{}drwxr-xr-x 6 cassandra
cassandra{}}}".
It might depend on the distribution / package used, but I can at least confirm
this for the official Cassandra Debian packages as well as the Docker
containers. Out of curiosity I compared it to Postgres and MySQL to see which
defaults they would opt for and they are
{{drwxr-x--- 2 mysql mysql 4.0K Mar 22 10:00 mysql}}
and respectively
{{drwx-- 19 postgres postgres 4.0K Mar 22 10:01 data}}
which is way more appropriate in my option. ([Here is a Gist with the script to
compare them|https://gist.github.com/bascht/31fa749d4121b9898902d5d557a01f82])
If there is no particular reason behind this, I would suggest that the default
packages should have stricter ulimits that restricts access to the data
directory to the cassandra user & group.
(See also this [mailing list
thread|https://lists.apache.org/thread/gyoqb4xnq4ry0c726f0ntz83rvn0w5kx])
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17465) python unit tests don't cleanup test keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-17465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-17465:
--
Reviewers: Stefan Miklosovic
Status: Review In Progress (was: Patch Available)
> python unit tests don't cleanup test keyspace
> -
>
> Key: CASSANDRA-17465
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17465
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
>
> The python unit tests in pylib/cqlshlib creates a temporary keyspace
> cqlshtests_, but does not drop it upon completion.
> To reproduce:
> {code:java}
> $ pytest
> $ cqlsh
> cassandra@cqlsh> describe keyspaces
> cqlshtests_oatjjlyyxh ...
> {code}
> The above keyspace, created with a 10 character random suffix, will remain
> after the tests are run. This will then cause subsequent runs of
> test_cqlsh_completion to fail.
>
> {code:java}
> cqlshlib/test/test_cqlsh_completion.py:138: in _trycompletions_inner
> E AssertionError: Items in the second set but not the first:
> E 'cqlshtests_oatjjlyyxh'
> {code}
> test/cassconnect.py;'s remove_db() has the code to perform this, but does not
> seem to be properly called.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17017) Add required -f / --force option to nodetool verify
[
https://issues.apache.org/jira/browse/CASSANDRA-17017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510518#comment-17510518
]
Josh McKenzie commented on CASSANDRA-17017:
---
{quote} - CI is failing sstableverify{quote}
I mentioned that this is a known issue and works w/the correct dtest branch
locally
{quote} - Some of your non circle commits change circle files. Be careful as
that sounds like an accident waiting to happen on merge?{quote}
I have a "fully revert all .circleci changes pre commit" step in my personal
workflow that should take care of this; I was one-off attempting to get the
thing to respect my custom DTEST_REPO changes. Didn't realize I had to change
it in 34 different places.
{quote} - I see some unrelated changes to CHANGES.txt i.e. Do you need to
rebase maybe?{quote}
Just needed a rebase. Done.
I'll update the docs and give the custom dtest in circle testing one more shot
in a few.
> Add required -f / --force option to nodetool verify
> ---
>
> Key: CASSANDRA-17017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17017
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 4.1
>
>
> nodetool verify has some pretty significant problems with it (see
> CASSANDRA-9947).
> Until such time as we do the heavy(er) lift to fix the command, we should
> make it harder for people to shoot themselves in the foot with it. Adding a
> required "-f" flag to it with a requisite "Do you really know what you're
> doing? Check out this JIRA first" seems like it'd be the right thing to do in
> the interim.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15510) BTree: Improve Building, Inserting and Transforming
[
https://issues.apache.org/jira/browse/CASSANDRA-15510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510512#comment-17510512
]
Benedict Elliott Smith commented on CASSANDRA-15510:
FYI I'm on holiday for a couple of weeks, so I'm unlikely to find time to
counter-review before April.
> BTree: Improve Building, Inserting and Transforming
> ---
>
> Key: CASSANDRA-15510
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15510
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Time Spent: 7h 20m
> Remaining Estimate: 0h
>
> This work was originally undertaken as a follow-up to CASSANDRA-15367 to
> ensure performance is strictly improved, but it may no longer be needed for
> that purpose. It’s still hugely impactful, however. It remains to be
> decided where this should land.
> The current {{BTree}} implementation is suboptimal in a number of ways, with
> very little focus having been given to its performance besides its
> memory-occupancy. This patch aims to address that, specifically improving
> the performance and allocations involved in: building, transforming and
> inserting into a tree.
> To facilitate this work, the {{BTree}} definition is modified slightly, so
> that we can perform some simple arithmetic on tree sizes. Specifically,
> trees of depth n are defined to have a maximum capacity of {{branchFactor^n -
> 1}}, which translates into capping the number of leaf children at
> {{branchFactor-1}}, as opposed to {{branchFactor}}. Since {{branchFactor}}
> is a power of 2, this permits fast tree size arithmetic, enabling some of
> these changes.
> h2. Building
> The static build method has been modified to utilise dedicated
> {{buildPerfect}} methods that build either perfectly dense or perfectly
> sparse sub-trees. These perfect trees all share their {{sizeMap}} with each
> other, and can be built more efficiently than trees of arbitrary size. The
> specifics are described in detail in the comments, but this building block
> can be used to construct trees of any size, using at most one child at each
> level that is not either perfectly sparse or perfectly dense. Bulk methods
> are used where possible.
> For large trees this can produce up to 30x throughput improvement and 30%
> allocation reduction vs 3.0 (TBC, and to be tested vs 4.0).
> {{FastBuilder}} is introduced for building a tree in-order (or in reverse)
> without duplicate elements to resolve, without necessarily knowing the size
> upfront. This meets the needs of most use cases. Data is built directly
> into nodes, with up to one already-constructed node, and one partially
> constructed node, on each level, being mutated to share their contents in the
> event of insufficient data to populate the tree. These builders are
> thread-locally shared. These leads to minimal copying, the same sharing of
> {{sizeMap}} as above, zero wasted allocations, and results in minimal
> difference in performance between utilising the less-ergonomic static build
> and builder approach.
> For large trees this leads to ~4.5x throughput improvement, and 70% reduction
> in allocations vs a normal Builder. For small trees performance is
> comparable, but allocations similarly reduced.
> h2. Inserting
> It turns out that we only ever insert another tree into a tree, so we exploit
> this to implement an efficient union of two trees, operating on them directly
> via stacks in the transformer, instead of via a collection interface. A
> builder-like object is introduced that shares functionality with
> {{FastBuilder}}, and permits us to build the result of the union directly
> into the final nodes, reusing as much of the original trees as possible.
> Bulk methods are used where possible.
> The result is not _uniformly_ faster, but is _significantly_ faster on
> average: median _improvement_ of 1.4x (that is, 2.4x total throughput), mean
> improvement of 10x. Worst reduction is 30%, and it may be that we can
> isolate and alleviate that. Allocations are also reduced significantly, with
> a median of 30% and mean of 42% for the tested workloads. As the trees get
> larger the improvement drops, but remains uniformly lower.
> h2. Transforming
> Transformations garbage overhead is minimal, i.e. the main allocations are
> those necessary to represent the new tree. It is significantly faster and
> particularly more efficient when removing elements, utilising the shared
> functionality of the builder and transformer objects to define an efficient
> builder that reuses as much of the original tree as possible.
> We also
[jira] [Updated] (CASSANDRA-17465) python unit tests don't cleanup test keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-17465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brad Schoening updated CASSANDRA-17465:
---
Description:
The python unit tests in pylib/cqlshlib creates a temporary keyspace
cqlshtests_, but does not drop it upon completion.
To reproduce:
{code:java}
$ pytest
$ cqlsh
cassandra@cqlsh> describe keyspaces
cqlshtests_oatjjlyyxh ...
{code}
The above keyspace, created with a 10 character random suffix, will remain
after the tests are run. This will then cause subsequent runs of
test_cqlsh_completion to fail.
{code:java}
cqlshlib/test/test_cqlsh_completion.py:138: in _trycompletions_inner
E AssertionError: Items in the second set but not the first:
E 'cqlshtests_oatjjlyyxh'
{code}
test/cassconnect.py;'s remove_db() has the code to perform this, but does not
seem to be properly called.
was:
The python unit test pylib/cqlshlib creates a temporary keyspace
cqlshtests_, but does not drop it upon completion.
To reproduce:
{code:java}
$ pytest
$ cqlsh
cassandra@cqlsh> describe keyspaces
cqlshtests_oatjjlyyxh ...
{code}
The above keyspace, created with a 10 character random suffix, will remain
after the tests are run. This will then cause subsequent runs of
test_cqlsh_completion to fail.
{code:java}
cqlshlib/test/test_cqlsh_completion.py:138: in _trycompletions_inner
E AssertionError: Items in the second set but not the first:
E 'cqlshtests_oatjjlyyxh'
{code}
test/cassconnect.py;'s remove_db() has the code to perform this, but does not
seem to be properly called.
> python unit tests don't cleanup test keyspace
> -
>
> Key: CASSANDRA-17465
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17465
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
>
> The python unit tests in pylib/cqlshlib creates a temporary keyspace
> cqlshtests_, but does not drop it upon completion.
> To reproduce:
> {code:java}
> $ pytest
> $ cqlsh
> cassandra@cqlsh> describe keyspaces
> cqlshtests_oatjjlyyxh ...
> {code}
> The above keyspace, created with a 10 character random suffix, will remain
> after the tests are run. This will then cause subsequent runs of
> test_cqlsh_completion to fail.
>
> {code:java}
> cqlshlib/test/test_cqlsh_completion.py:138: in _trycompletions_inner
> E AssertionError: Items in the second set but not the first:
> E 'cqlshtests_oatjjlyyxh'
> {code}
> test/cassconnect.py;'s remove_db() has the code to perform this, but does not
> seem to be properly called.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17465) python unit tests don't cleanup test keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-17465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brad Schoening reassigned CASSANDRA-17465:
--
Assignee: Brad Schoening
> python unit tests don't cleanup test keyspace
> -
>
> Key: CASSANDRA-17465
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17465
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
>
> The python unit test pylib/cqlshlib creates a temporary keyspace
> cqlshtests_, but does not drop it upon completion.
> To reproduce:
> {code:java}
> $ pytest
> $ cqlsh
> cassandra@cqlsh> describe keyspaces
> cqlshtests_oatjjlyyxh ...
> {code}
> The above keyspace, created with a 10 character random suffix, will remain
> after the tests are run. This will then cause subsequent runs of
> test_cqlsh_completion to fail.
>
> {code:java}
> cqlshlib/test/test_cqlsh_completion.py:138: in _trycompletions_inner
> E AssertionError: Items in the second set but not the first:
> E 'cqlshtests_oatjjlyyxh'
> {code}
> test/cassconnect.py;'s remove_db() has the code to perform this, but does not
> seem to be properly called.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17465) python unit tests don't cleanup test keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-17465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brad Schoening updated CASSANDRA-17465:
---
Test and Documentation Plan: Ran pytest and with cqlsh observed temporary
keyspace is dropped
Status: Patch Available (was: Open)
> python unit tests don't cleanup test keyspace
> -
>
> Key: CASSANDRA-17465
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17465
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
>
> The python unit test pylib/cqlshlib creates a temporary keyspace
> cqlshtests_, but does not drop it upon completion.
> To reproduce:
> {code:java}
> $ pytest
> $ cqlsh
> cassandra@cqlsh> describe keyspaces
> cqlshtests_oatjjlyyxh ...
> {code}
> The above keyspace, created with a 10 character random suffix, will remain
> after the tests are run. This will then cause subsequent runs of
> test_cqlsh_completion to fail.
>
> {code:java}
> cqlshlib/test/test_cqlsh_completion.py:138: in _trycompletions_inner
> E AssertionError: Items in the second set but not the first:
> E 'cqlshtests_oatjjlyyxh'
> {code}
> test/cassconnect.py;'s remove_db() has the code to perform this, but does not
> seem to be properly called.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17456) Test Failures: write_failures_test.TestMultiDCWriteFailures.test_oversized_mutation
[
https://issues.apache.org/jira/browse/CASSANDRA-17456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510474#comment-17510474
]
Benedict Elliott Smith commented on CASSANDRA-17456:
Yes, to be clear I meant only to remove the _CommitLog_ size restrictions, and
move the size restriction to one that is entirely imposed on the client
connection. Increasing the default permitted size would be a way to minimise
the chance of this change breaking applications when introduced, without
modifying the default commit log behaviour. Though I would be fine to simply
move to rejecting the oversized mutations at the client connection (and perhaps
also internode) without any other changes.
> Test Failures:
> write_failures_test.TestMultiDCWriteFailures.test_oversized_mutation
> ---
>
> Key: CASSANDRA-17456
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17456
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1002/testReport/dtest-offheap.write_failures_test/TestMultiDCWriteFailures/test_oversized_mutation/
> {code:java}
> Error Message
> AssertionError: assert 0 == 8 + where 8 = JolokiaAgent.read_attribute of 0x7f1fca78dac0>>('org.apache.cassandra.metrics:type=Storage,name=TotalHints',
> 'Count') +where > =
> .read_attribute +
> and 'org.apache.cassandra.metrics:type=Storage,name=TotalHints' =
> make_mbean('metrics', type='Storage', name='TotalHints')
> Stacktrace
> self =
> def test_oversized_mutation(self):
> """
> Test that multi-DC write failures return operation failed rather
> than a timeout.
> @jira_ticket CASSANDRA-16334.
> """
>
> cluster = self.cluster
> cluster.populate([2, 2])
> cluster.set_configuration_options(values={'max_mutation_size_in_kb':
> 128})
> cluster.start()
>
> node1 = cluster.nodelist()[0]
> session = self.patient_exclusive_cql_connection(node1)
>
> session.execute("CREATE KEYSPACE k WITH replication = {'class':
> 'NetworkTopologyStrategy', 'dc1': 2, 'dc2': 2}")
> session.execute("CREATE TABLE k.t (key int PRIMARY KEY, val blob)")
>
> payload = '1' * 1024 * 256
> query = "INSERT INTO k.t (key, val) VALUES (1,
> textAsBlob('{}'))".format(payload)
>
> assert_write_failure(session, query, ConsistencyLevel.LOCAL_ONE)
> assert_write_failure(session, query, ConsistencyLevel.ONE)
>
> # verify that no hints are created
> with JolokiaAgent(node1) as jmx:
> > assert 0 == jmx.read_attribute(make_mbean('metrics',
> > type='Storage', name='TotalHints'), 'Count')
> E AssertionError: assert 0 == 8
> E+ where 8 = 0x7f1fca78dac0>>('org.apache.cassandra.metrics:type=Storage,name=TotalHints',
> 'Count')
> E+where > =
> .read_attribute
> E+and
> 'org.apache.cassandra.metrics:type=Storage,name=TotalHints' =
> make_mbean('metrics', type='Storage', name='TotalHints')
> write_failures_test.py:277: AssertionError
> REST API
> CloudBees CI Client Controller 2.319.3.4-rolling
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17459) OWASP failures, 3/2022
[
https://issues.apache.org/jira/browse/CASSANDRA-17459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17459:
-
Fix Version/s: 4.1
4.0.4
(was: 4.x)
(was: 4.0.x)
Since Version: NA
Source Control Link:
https://github.com/apache/cassandra/commit/592cee30640f7d5ca0fc80cefb1c9dad24a58a81
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed, thanks.
> OWASP failures, 3/2022
> --
>
> Key: CASSANDRA-17459
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17459
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1, 4.0.4
>
>
> On trunk there are a few failures:
> {quote}
> Dependency-Check Failure:
> One or more dependencies were identified with vulnerabilities that have a
> CVSS score greater than or equal to '1.0':
> cassandra-driver-core-3.11.0-shaded.jar: CVE-2021-44521
> jackson-databind-2.12.5.jar: CVE-2020-36518
> See the dependency-check report for more details.
> {quote}
> Notably, we have bitten ourselves with CVE-2021-44521, which the driver has
> echoed, which we depend on.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
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: Suppress CVE-2021-44521
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/cassandra-4.0 by this push: new 592cee3 Suppress CVE-2021-44521 592cee3 is described below commit 592cee30640f7d5ca0fc80cefb1c9dad24a58a81 Author: Brandon Williams AuthorDate: Mon Mar 21 12:50:25 2022 -0500 Suppress CVE-2021-44521 Patch by brandonwilliams; reviewed by bereng for CASSANDRA-17459 --- .build/dependency-check-suppressions.xml | 1 + CHANGES.txt | 1 + 2 files changed, 2 insertions(+) diff --git a/.build/dependency-check-suppressions.xml b/.build/dependency-check-suppressions.xml index 0003951..7633085 100644 --- a/.build/dependency-check-suppressions.xml +++ b/.build/dependency-check-suppressions.xml @@ -26,6 +26,7 @@ CVE-2018-8016 CVE-2020-13946 CVE-2020-17516 +CVE-2021-44521 diff --git a/CHANGES.txt b/CHANGES.txt index 1e710a3..5b13f9b 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 4.0.4 + * Suppress CVE-2021-44521 from driver (CASSANDRA-17459) * Upgrade jackson to 2.13.2 (CASSANDRA-17460) * Make sstableloader honour native port option (CASSANDRA-17210) * Reject snapshot names with special character (CASSANDRA-15297) - 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. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 305cb940c3be63f2eb74a745d60d70abaa0d2e2c Merge: 94c2ad5 592cee3 Author: Brandon Williams AuthorDate: Tue Mar 22 07:42:08 2022 -0500 Merge branch 'cassandra-4.0' into trunk .build/dependency-check-suppressions.xml | 1 + CHANGES.txt | 1 + 2 files changed, 2 insertions(+) diff --cc CHANGES.txt index cc23bc3,5b13f9b..e8bc60b --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,115 -1,5 +1,116 @@@ -4.0.4 +4.1 + * Add native transport rate limiter options to example cassandra.yaml, and expose metric for dispatch rate (CASSANDRA-17423) + * Add diagnostic events for guardrails (CASSANDRA-17197) + * Increase cqlsh version (CASSANDRA-17432) + * Update SUPPORTED_UPGRADE_PATHS to include 3.0 and 3.x to 4.1 paths and remove obsolete tests (CASSANDRA-17362) + * Support DELETE in CQLSSTableWriter (CASSANDRA-14797) + * Failed inbound internode authentication failures generate ugly warning with stack trace (CASSANDRA-17068) + * Expose gossip information in system_views.gossip_info virtual table (CASSANDRA-17002) + * Add guardrails for collection items and size (CASSANDRA-17153) + * Improve guardrails messages (CASSANDRA-17430) + * Remove all usages of junit.framework and ban them via Checkstyle (CASSANDRA-17316) + * Add guardrails for read/write consistency levels (CASSANDRA-17188) + * Add guardrail for SELECT IN terms and their cartesian product (CASSANDRA-17187) + * remove unused imports in cqlsh.py and cqlshlib (CASSANDRA-17413) + * deprecate property windows_timer_interval (CASSANDRA-17404) + * Expose streaming as a vtable (CASSANDRA-17390) + * Expose all client options via system_views.clients and nodetool clientstats (CASSANDRA-16378) + * Make startup checks configurable (CASSANDRA-17220) + * Add guardrail for number of partition keys on IN queries (CASSANDRA-17186) + * update Python test framework from nose to pytest (CASSANDRA-17293) + * Fix improper CDC commit log segments deletion in non-blocking mode (CASSANDRA-17233) + * Add support for string concatenations through the + operator (CASSANDRA-17190) + * Limit the maximum hints size per host (CASSANDRA-17142) + * Add a virtual table for exposing batch metrics (CASSANDRA-17225) + * Flatten guardrails config (CASSANDRA-17353) + * Instance failed to start up due to NPE in StartupClusterConnectivityChecker (CASSANDRA-17347) + * add the shorter version of version flag (-v) in cqlsh (CASSANDRA-17236) + * Make vtables accessible via internode messaging (CASSANDRA-17295) + * Add support for PEM based key material for SSL (CASSANDRA-17031) + * Standardize storage configuration parameters' names. Support unit suffixes. (CASSANDRA-15234) + * Remove support for Windows (CASSANDRA-16956) + * Runtime-configurable YAML option to prohibit USE statements (CASSANDRA-17318) + * When streaming sees a ClosedChannelException this triggers the disk failure policy (CASSANDRA-17116) + * Add a virtual table for exposing prepared statements metrics (CASSANDRA-17224) + * Remove python 2.x support from cqlsh (CASSANDRA-17242) + * Prewarm role and credential caches to avoid timeouts at startup (CASSANDRA-16958) + * Make capacity/validity/updateinterval/activeupdate for Auth Caches configurable via nodetool (CASSANDRA-17063) + * Added startup check for read_ahead_kb setting (CASSANDRA-16436) + * Avoid unecessary array allocations and initializations when performing query checks (CASSANDRA-17209) + * Add guardrail for list operations that require read before write (CASSANDRA-17154) + * Migrate thresholds for number of keyspaces and tables to guardrails (CASSANDRA-17195) + * Remove self-reference in SSTableTidier (CASSANDRA-17205) + * Add guardrail for query page size (CASSANDRA-17189) + * Allow column_index_size_in_kb to be configurable through nodetool (CASSANDRA-17121) + * Emit a metric for number of local read and write calls + * Add non-blocking mode for CDC writes (CASSANDRA-17001) + * Add guardrails framework (CASSANDRA-17147) + * Harden resource management on SSTable components to prevent future leaks (CASSANDRA-17174) + * Make nodes more resilient to local unrelated files during startup (CASSANDRA-17082) + * repair prepare message would produce a wrong error message if network timeout happened rather than reply wait timeout (CASSANDRA-16992) + * Log queries that fail on timeout or unavailable errors up to once per minute by default (CASSANDRA-17159) + * Refactor normal/preview/IR repair to standardize repair cleanup and error handling of failed RepairJobs (CASSANDRA-17069) + * Log missing peers in StartupClusterConnectivityChecker (CASSANDRA-17130) + * Introduce separate rate limiting settings for entire SSTable streaming (CASSANDRA-17065) + * Implement Virtual Tables for Auth Caches
[cassandra] branch trunk updated (94c2ad5 -> 305cb94)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 94c2ad5 Merge branch 'cassandra-4.0' into trunk new 592cee3 Suppress CVE-2021-44521 new 305cb94 Merge branch 'cassandra-4.0' into trunk The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .build/dependency-check-suppressions.xml | 1 + CHANGES.txt | 1 + 2 files changed, 2 insertions(+) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17460) Upgrade jackson-databind for CVE-2020-36518
[ https://issues.apache.org/jira/browse/CASSANDRA-17460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17460: - Fix Version/s: 4.1 4.0.4 (was: 4.x) (was: 4.0.x) Source Control Link: https://github.com/apache/cassandra/commit/b465fec7707555a1bfc8ac80fd60b9e97f1f Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed, thank you for reviewing. > Upgrade jackson-databind for CVE-2020-36518 > --- > > Key: CASSANDRA-17460 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17460 > Project: Cassandra > Issue Type: Sub-task > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.1, 4.0.4 > > > jackson-databind-2.12.5.jar is vulnerable and should be upgraded. -- This message was sent by Atlassian Jira (v8.20.1#820001) - 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. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 94c2ad5304b687cf78a7ddbc660a2651c9d04dc1 Merge: 6a3edec b465fec Author: Brandon Williams AuthorDate: Tue Mar 22 07:32:13 2022 -0500 Merge branch 'cassandra-4.0' into trunk CHANGES.txt | 1 + build.xml | 8 2 files changed, 5 insertions(+), 4 deletions(-) diff --cc CHANGES.txt index 6244eef,1e710a3..cc23bc3 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,115 -1,5 +1,116 @@@ -4.0.4 +4.1 + * Add native transport rate limiter options to example cassandra.yaml, and expose metric for dispatch rate (CASSANDRA-17423) + * Add diagnostic events for guardrails (CASSANDRA-17197) + * Increase cqlsh version (CASSANDRA-17432) + * Update SUPPORTED_UPGRADE_PATHS to include 3.0 and 3.x to 4.1 paths and remove obsolete tests (CASSANDRA-17362) + * Support DELETE in CQLSSTableWriter (CASSANDRA-14797) + * Failed inbound internode authentication failures generate ugly warning with stack trace (CASSANDRA-17068) + * Expose gossip information in system_views.gossip_info virtual table (CASSANDRA-17002) + * Add guardrails for collection items and size (CASSANDRA-17153) + * Improve guardrails messages (CASSANDRA-17430) + * Remove all usages of junit.framework and ban them via Checkstyle (CASSANDRA-17316) + * Add guardrails for read/write consistency levels (CASSANDRA-17188) + * Add guardrail for SELECT IN terms and their cartesian product (CASSANDRA-17187) + * remove unused imports in cqlsh.py and cqlshlib (CASSANDRA-17413) + * deprecate property windows_timer_interval (CASSANDRA-17404) + * Expose streaming as a vtable (CASSANDRA-17390) + * Expose all client options via system_views.clients and nodetool clientstats (CASSANDRA-16378) + * Make startup checks configurable (CASSANDRA-17220) + * Add guardrail for number of partition keys on IN queries (CASSANDRA-17186) + * update Python test framework from nose to pytest (CASSANDRA-17293) + * Fix improper CDC commit log segments deletion in non-blocking mode (CASSANDRA-17233) + * Add support for string concatenations through the + operator (CASSANDRA-17190) + * Limit the maximum hints size per host (CASSANDRA-17142) + * Add a virtual table for exposing batch metrics (CASSANDRA-17225) + * Flatten guardrails config (CASSANDRA-17353) + * Instance failed to start up due to NPE in StartupClusterConnectivityChecker (CASSANDRA-17347) + * add the shorter version of version flag (-v) in cqlsh (CASSANDRA-17236) + * Make vtables accessible via internode messaging (CASSANDRA-17295) + * Add support for PEM based key material for SSL (CASSANDRA-17031) + * Standardize storage configuration parameters' names. Support unit suffixes. (CASSANDRA-15234) + * Remove support for Windows (CASSANDRA-16956) + * Runtime-configurable YAML option to prohibit USE statements (CASSANDRA-17318) + * When streaming sees a ClosedChannelException this triggers the disk failure policy (CASSANDRA-17116) + * Add a virtual table for exposing prepared statements metrics (CASSANDRA-17224) + * Remove python 2.x support from cqlsh (CASSANDRA-17242) + * Prewarm role and credential caches to avoid timeouts at startup (CASSANDRA-16958) + * Make capacity/validity/updateinterval/activeupdate for Auth Caches configurable via nodetool (CASSANDRA-17063) + * Added startup check for read_ahead_kb setting (CASSANDRA-16436) + * Avoid unecessary array allocations and initializations when performing query checks (CASSANDRA-17209) + * Add guardrail for list operations that require read before write (CASSANDRA-17154) + * Migrate thresholds for number of keyspaces and tables to guardrails (CASSANDRA-17195) + * Remove self-reference in SSTableTidier (CASSANDRA-17205) + * Add guardrail for query page size (CASSANDRA-17189) + * Allow column_index_size_in_kb to be configurable through nodetool (CASSANDRA-17121) + * Emit a metric for number of local read and write calls + * Add non-blocking mode for CDC writes (CASSANDRA-17001) + * Add guardrails framework (CASSANDRA-17147) + * Harden resource management on SSTable components to prevent future leaks (CASSANDRA-17174) + * Make nodes more resilient to local unrelated files during startup (CASSANDRA-17082) + * repair prepare message would produce a wrong error message if network timeout happened rather than reply wait timeout (CASSANDRA-16992) + * Log queries that fail on timeout or unavailable errors up to once per minute by default (CASSANDRA-17159) + * Refactor normal/preview/IR repair to standardize repair cleanup and error handling of failed RepairJobs (CASSANDRA-17069) + * Log missing peers in StartupClusterConnectivityChecker (CASSANDRA-17130) + * Introduce separate rate limiting settings for entire SSTable streaming (CASSANDRA-17065) + * Implement Virtual Tables for Auth Caches (CASSANDRA-16914) + * Actively update
[cassandra] branch trunk updated (6a3edec -> 94c2ad5)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 6a3edec Merge branch 'cassandra-4.0' into trunk new b465fec Upgrade jackson to 2.13.2 new 94c2ad5 Merge branch 'cassandra-4.0' into trunk The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt | 1 + build.xml | 8 2 files changed, 5 insertions(+), 4 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: Upgrade jackson to 2.13.2
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/cassandra-4.0 by this push: new b465fec Upgrade jackson to 2.13.2 b465fec is described below commit b465fec7707555a1bfc8ac80fd60b9e97f1f Author: Brandon Williams AuthorDate: Mon Mar 21 07:24:20 2022 -0500 Upgrade jackson to 2.13.2 Patch by brandonwilliams; reviewed by bereng for CASSANDRA-17460 --- CHANGES.txt | 1 + build.xml | 6 +++--- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/CHANGES.txt b/CHANGES.txt index 2ed1fba..1e710a3 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 4.0.4 + * Upgrade jackson to 2.13.2 (CASSANDRA-17460) * Make sstableloader honour native port option (CASSANDRA-17210) * Reject snapshot names with special character (CASSANDRA-15297) * Fix ObjectSizes implementation and usages (CASSANDRA-17402) diff --git a/build.xml b/build.xml index 6cd135f..5630228 100644 --- a/build.xml +++ b/build.xml @@ -528,9 +528,9 @@ - - - + + + - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16677) Fix flaky ConnectionTest
[ https://issues.apache.org/jira/browse/CASSANDRA-16677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-16677: -- Component/s: Test/unit > Fix flaky ConnectionTest > > > Key: CASSANDRA-16677 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16677 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode, Test/unit >Reporter: Brandon Williams >Priority: Normal > Fix For: 4.0.x > > Attachments: TEST-org.apache.cassandra.net.ConnectionTest.log.xz > > > https://ci-cassandra.apache.org/job/Cassandra-devbranch/785/testReport/junit/org.apache.cassandra.net/ConnectionTest/testMessageDeliveryOnReconnect_compression/ > https://app.circleci.com/pipelines/github/adelapena/cassandra/460/workflows/cf7dcec6-612c-45d1-8471-623bde481dca/jobs/4069 > https://app.circleci.com/pipelines/github/adelapena/cassandra/460/workflows/b750cd38-0263-4b5e-9bb8-a8be98214378/jobs/4065 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17467) Timestamp issue with Cassandra 4.0.3 with Timezone value
[
https://issues.apache.org/jira/browse/CASSANDRA-17467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510452#comment-17510452
]
Brandon Williams commented on CASSANDRA-17467:
--
I intend for any fix to be available in 4.0.4.
> Timestamp issue with Cassandra 4.0.3 with Timezone value
>
>
> Key: CASSANDRA-17467
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17467
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Anand B
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> Hello Team ,
>
> Facing one issue related to the timestamp type in cassandra 4.0.3 version .
> This is not repro in 3.11.x and works fine in 3.11.
>
> when i have table with timestamp as fields :
>
> CREATE TABLE timetest (
> id int PRIMARY KEY,
> enddate timestamp,
> startdate timestamp
> )
> *Now when try to insert the record like :*
> INSERT INTO timetest (id,startdate,enddate) VALUES (1 ,'2022-03-20 12:48:56
> +0530','2022-03-20 12:48:56 +0530')
> I am receiving error:
>
> "{color:#de350b}InvalidRequest{color}: Error from server: code=2200 [Invalid
> query] message="Unable to parse a date/time from '2022-03-20 12:48:56 +0530'".
> **
> *This works fine on 3.11 but fails on 4.x.*
>
> *same issue if we query the record:*
>
> select * from timetest where id = 1 and enddate = '2022-03-20 12:48:56 +0530';
> {color:#de350b}InvalidRequest{color}: Error from server: code=2200 [Invalid
> query] message="Unable to parse a date/time from '2022-03-20 12:48:56 +0530'"
>
>
> {color:#ffab00}*If we change the timestamp value and remove the extra space
> which is present before the timezone value then it works fine in 4.x*{color}
>
> if we change timestamp value From {'2022-03-20 12:48:{color:#de350b}56
> +0530{color}'} To {'2022-03-20 12:48:{color:#ffab00}56+0530{color}’} then
> 4.0.3 accept this value otherwise not. but 3.11 was accepting both the values.
>
> This is causing a challenge for upgrading from 3.11 to 4.x.
>
> Seeking help on this issue and any fix / workaround or suitable Cassandra
> version which is higher than 3.11 but lesser then 4.0.3 which can be used to
> fix this issue asap.
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16677) Fix flaky ConnectionTest
[ https://issues.apache.org/jira/browse/CASSANDRA-16677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510451#comment-17510451 ] Andres de la Peña commented on CASSANDRA-16677: --- More failures on [https://ci-cassandra.apache.org/job/Cassandra-trunk/1032/testReport/org.apache.cassandra.transport/CQLConnectionTest] They can be reproduced with the multiplexer: https://app.circleci.com/pipelines/github/adelapena/cassandra/1405/workflows/88fb8e4f-7a3f-42f9-a6db-5d14a652b54e > Fix flaky ConnectionTest > > > Key: CASSANDRA-16677 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16677 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode >Reporter: Brandon Williams >Priority: Normal > Fix For: 4.0.x > > Attachments: TEST-org.apache.cassandra.net.ConnectionTest.log.xz > > > https://ci-cassandra.apache.org/job/Cassandra-devbranch/785/testReport/junit/org.apache.cassandra.net/ConnectionTest/testMessageDeliveryOnReconnect_compression/ > https://app.circleci.com/pipelines/github/adelapena/cassandra/460/workflows/cf7dcec6-612c-45d1-8471-623bde481dca/jobs/4069 > https://app.circleci.com/pipelines/github/adelapena/cassandra/460/workflows/b750cd38-0263-4b5e-9bb8-a8be98214378/jobs/4065 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17449) Remove unused python modules
[ https://issues.apache.org/jira/browse/CASSANDRA-17449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17449: - Fix Version/s: 4.1 (was: 4.x) > Remove unused python modules > - > > Key: CASSANDRA-17449 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17449 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Brad Schoening >Assignee: Sathyanarayanan Saravanamuthu >Priority: Normal > Fix For: 4.1 > > Time Spent: 1h > Remaining Estimate: 0h > > The following python modules listed in pylib/requirements.txt appear unused > in the python code and should be removed from requirements: > * decorator > * docopt > * flaky > * mock > * psutil > * pycodestyle -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17449) Remove unused python modules
[ https://issues.apache.org/jira/browse/CASSANDRA-17449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510446#comment-17510446 ] Andres de la Peña commented on CASSANDRA-17449: --- Just ignore my previous comment, we already have tickets for those flakies (CASSANDRA-16677 and CASSANDRA-16681), but they weren't linked on Butler. > Remove unused python modules > - > > Key: CASSANDRA-17449 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17449 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Brad Schoening >Assignee: Sathyanarayanan Saravanamuthu >Priority: Normal > Fix For: 4.x > > Time Spent: 1h > Remaining Estimate: 0h > > The following python modules listed in pylib/requirements.txt appear unused > in the python code and should be removed from requirements: > * decorator > * docopt > * flaky > * mock > * psutil > * pycodestyle -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16681) org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
[ https://issues.apache.org/jira/browse/CASSANDRA-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510441#comment-17510441 ] Andres de la Peña commented on CASSANDRA-16681: --- New error on trunk: [https://ci-cassandra.apache.org/job/Cassandra-trunk/1032/testReport/org.apache.cassandra.utils.memory/LongBufferPoolTest/testPoolAllocateWithRecyclePartially_2/] It can be reproduced [with CircleCI|https://app.circleci.com/pipelines/github/adelapena/cassandra/1406/workflows/ef197b74-0805-404f-bdcd-851cdd75a846]. > org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky > -- > > Key: CASSANDRA-16681 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16681 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.11.x, 4.0.x > > Time Spent: 20m > Remaining Estimate: 0h > > Jenkins history: > [https://jenkins-cm4.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.utils.memory/LongBufferPoolTest/testPoolAllocateWithRecyclePartially/history/] > Fails being run in a loop in CircleCI: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/844/workflows/945011f4-00ac-4678-89f6-5c0db0a40169/jobs/5008 > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16681) org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
[ https://issues.apache.org/jira/browse/CASSANDRA-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-16681: -- Fix Version/s: 4.x > org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky > -- > > Key: CASSANDRA-16681 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16681 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.x > > Time Spent: 20m > Remaining Estimate: 0h > > Jenkins history: > [https://jenkins-cm4.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.utils.memory/LongBufferPoolTest/testPoolAllocateWithRecyclePartially/history/] > Fails being run in a loop in CircleCI: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/844/workflows/945011f4-00ac-4678-89f6-5c0db0a40169/jobs/5008 > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17444) DOC - Update title for topologies, CDC archiving properties pages
[
https://issues.apache.org/jira/browse/CASSANDRA-17444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-17444:
--
Fix Version/s: 4.0.3
3.11.12
Source Control Link:
https://github.com/apache/cassandra/commit/84f629752fea8fa060d24c912369d90070bcfc52
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed and waiting for builds to complete.
||Branch||PR||Commit||Build||
|{{trunk}}|[#1513|https://github.com/apache/cassandra/pull/1513]|[84f6297|https://github.com/apache/cassandra/commit/84f629752fea8fa060d24c912369d90070bcfc52]|[#1033|https://ci-cassandra.apache.org/job/Cassandra-trunk/1033/]|
|{{4.0}}|[#1514|https://github.com/apache/cassandra/pull/1514]|[84f6297|https://github.com/apache/cassandra/commit/84f629752fea8fa060d24c912369d90070bcfc52]|[#363|https://ci-cassandra.apache.org/job/Cassandra-4.0/363/]|
|{{3.11}}|[#1515|https://github.com/apache/cassandra/pull/1515]|[84f6297|https://github.com/apache/cassandra/commit/84f629752fea8fa060d24c912369d90070bcfc52]|[#340|https://ci-cassandra.apache.org/job/Cassandra-3.11/340/]|
> DOC - Update title for topologies, CDC archiving properties pages
> -
>
> Key: CASSANDRA-17444
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17444
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: taku333
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 4.0.3, 3.11.12
>
> Attachments: c17444-01-configuration-topologies.png,
> c17444-02-configuration-commitlog_archiving.png
>
>
> Documentation revision request.
> Below are details.
> https://github.com/apache/cassandra/pull/1469
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17444) DOC - Update title for topologies, CDC archiving properties pages
[
https://issues.apache.org/jira/browse/CASSANDRA-17444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510221#comment-17510221
]
Erick Ramirez edited comment on CASSANDRA-17444 at 3/22/22, 11:28 AM:
--
I've detected a few more errors on the Configuration pages plus we need
separate PRs for the other versions so I've submitted multiple PRs in place of
[~taku333] 's:
||Branch||PR||
|{{trunk}}|[#1513|https://github.com/apache/cassandra/pull/1513]|
|{{4.0}}|[#1514|https://github.com/apache/cassandra/pull/1514]|
|{{3.11}}|[#1515|https://github.com/apache/cassandra/pull/1515]|
was (Author: JIRAUSER285101):
I've detected a few more errors on the Configuration pages plus we need
separate PRs for the other versions so I've submitted multiple PRs in place of
[~taku333] 's:
||Branch||PR||
|{{trunk}}|[#1513|https://github.com/apache/cassandra/pull/1513]|
|{{4.0}}|[#1514|https://github.com/apache/cassandra/pull/1514]|
|{{3.11}}|[#1515|https://github.com/apache/cassandra/pull/1515]|
> DOC - Update title for topologies, CDC archiving properties pages
> -
>
> Key: CASSANDRA-17444
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17444
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: taku333
>Assignee: Erick Ramirez
>Priority: Normal
> Attachments: c17444-01-configuration-topologies.png,
> c17444-02-configuration-commitlog_archiving.png
>
>
> Documentation revision request.
> Below are details.
> https://github.com/apache/cassandra/pull/1469
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
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 (311e26b -> 84f6297)
This is an automated email from the ASF dual-hosted git repository. erickramirezau pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 311e26b Merge branch 'cassandra-3.0' into cassandra-3.11 add 84f6297 Fixed Configuration index, topologies, CDC archiving properties pages (3.11) No new revisions were added by this update. Summary of changes: .../pages/configuration/cass_cl_archive_file.adoc | 40 ++ .../pages/configuration/cass_topo_file.adoc| 5 ++- .../cassandra/pages/configuration/index.adoc | 2 +- 3 files changed, 29 insertions(+), 18 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. erickramirezau pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 6a3edecd21eba5001ebe5ffcf5397fc8a6c7c1e3 Merge: 952263d a14700b Author: Erick Ramirez AuthorDate: Tue Mar 22 11:13:23 2022 + Merge branch 'cassandra-4.0' into trunk .../pages/configuration/cass_cl_archive_file.adoc | 40 ++ .../pages/configuration/cass_topo_file.adoc| 5 ++- .../cassandra/pages/configuration/index.adoc | 2 +- 3 files changed, 29 insertions(+), 18 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (952263d -> 6a3edec)
This is an automated email from the ASF dual-hosted git repository. erickramirezau pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 952263d removing unused Python packages in pylib add 84f6297 Fixed Configuration index, topologies, CDC archiving properties pages (3.11) add a14700b Merge branch 'cassandra-3.11' into cassandra-4.0 new 6a3edec 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: .../pages/configuration/cass_cl_archive_file.adoc | 40 ++ .../pages/configuration/cass_topo_file.adoc| 5 ++- .../cassandra/pages/configuration/index.adoc | 2 +- 3 files changed, 29 insertions(+), 18 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 (d48df91 -> a14700b)
This is an automated email from the ASF dual-hosted git repository. erickramirezau pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from d48df91 make sstableloader honour native port option add 84f6297 Fixed Configuration index, topologies, CDC archiving properties pages (3.11) add a14700b Merge branch 'cassandra-3.11' into cassandra-4.0 No new revisions were added by this update. Summary of changes: .../pages/configuration/cass_cl_archive_file.adoc | 40 ++ .../pages/configuration/cass_topo_file.adoc| 5 ++- .../cassandra/pages/configuration/index.adoc | 2 +- 3 files changed, 29 insertions(+), 18 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17449) Remove unused python modules
[
https://issues.apache.org/jira/browse/CASSANDRA-17449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510404#comment-17510404
]
Andres de la Peña edited comment on CASSANDRA-17449 at 3/22/22, 10:59 AM:
--
The Jenkins run for this commit has a new failures on
{{{}org.apache.cassandra.transport.CQLConnectionTest{}}}:
*
[handleErrorDuringNegotiation-cdc|https://ci-cassandra.apache.org/job/Cassandra-trunk/1032/testReport/org.apache.cassandra.transport/CQLConnectionTest/handleErrorDuringNegotiation_cdc_2/]
*
[handleFrameCorruptionAfterNegotiation-cdc|https://ci-cassandra.apache.org/job/Cassandra-trunk/1032/testReport/org.apache.cassandra.transport/CQLConnectionTest/handleFrameCorruptionAfterNegotiation_cdc/]
And also for
[{{org.apache.cassandra.utils.memory.LongBufferPoolTest.testPoolAllocateWithRecyclePartially}}|https://ci-cassandra.apache.org/job/Cassandra-trunk/1032/testReport/org.apache.cassandra.utils.memory/LongBufferPoolTest/testPoolAllocateWithRecyclePartially/]
.
Not sure these can be related to the changes or are just previously existing
flakies.
was (Author: adelapena):
The Jenkins run for this commit has a new failures on
{{{}org.apache.cassandra.transport.CQLConnectionTest{}}}:
*
[handleErrorDuringNegotiation-cdc|https://ci-cassandra.apache.org/job/Cassandra-trunk/1032/testReport/org.apache.cassandra.transport/CQLConnectionTest/handleErrorDuringNegotiation_cdc_2/]
*
[handleFrameCorruptionAfterNegotiation-cdc|https://ci-cassandra.apache.org/job/Cassandra-trunk/1032/testReport/org.apache.cassandra.transport/CQLConnectionTest/handleFrameCorruptionAfterNegotiation_cdc/]
Not sure these can be related to the changes or are just previously existing
flakies.
> Remove unused python modules
> -
>
> Key: CASSANDRA-17449
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17449
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Brad Schoening
>Assignee: Sathyanarayanan Saravanamuthu
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The following python modules listed in pylib/requirements.txt appear unused
> in the python code and should be removed from requirements:
> * decorator
> * docopt
> * flaky
> * mock
> * psutil
> * pycodestyle
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17449) Remove unused python modules
[
https://issues.apache.org/jira/browse/CASSANDRA-17449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510404#comment-17510404
]
Andres de la Peña commented on CASSANDRA-17449:
---
The Jenkins run for this commit has a new failures on
{{{}org.apache.cassandra.transport.CQLConnectionTest{}}}:
*
[handleErrorDuringNegotiation-cdc|https://ci-cassandra.apache.org/job/Cassandra-trunk/1032/testReport/org.apache.cassandra.transport/CQLConnectionTest/handleErrorDuringNegotiation_cdc_2/]
*
[handleFrameCorruptionAfterNegotiation-cdc|https://ci-cassandra.apache.org/job/Cassandra-trunk/1032/testReport/org.apache.cassandra.transport/CQLConnectionTest/handleFrameCorruptionAfterNegotiation_cdc/]
Not sure these can be related to the changes or are just previously existing
flakies.
> Remove unused python modules
> -
>
> Key: CASSANDRA-17449
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17449
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Brad Schoening
>Assignee: Sathyanarayanan Saravanamuthu
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The following python modules listed in pylib/requirements.txt appear unused
> in the python code and should be removed from requirements:
> * decorator
> * docopt
> * flaky
> * mock
> * psutil
> * pycodestyle
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
