[jira] [Commented] (CASSANDRA-16677) Fix flaky ConnectionTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17376305#comment-17376305
]
Berenguer Blasi commented on CASSANDRA-16677:
-
The problem comes from trying to flush against an already closed connecttion.
Adding some stacks for future reference:
{noformat}
[junit-timeout] INFO [Messaging-EventLoop-3-7] 2021-07-06 12:17:23,858
InboundConnectionInitiator.java:464 -
/127.0.0.1:7012(/127.0.0.1:49576)->/127.0.0.1:7012-LARGE_MESSAGES-6cbecdc7
messaging connection established, version = 12, framing = LZ4, encryption =
encrypted(factory=openssl;protocol=TLSv1.3;cipher=TLS_AES_128_GCM_SHA256)
[junit-timeout] INFO [main] 2021-07-06 12:17:23,865
InboundConnectionInitiator.java:127 - Listening on address: (/127.0.0.1:17012),
nic: lo, encryption: encrypted(openssl)
[junit-timeout] INFO [main] 2021-07-06 12:17:23,865
InboundConnectionInitiator.java:127 - Listening on address: (/127.0.0.1:7012),
nic: lo, encryption: optionally encrypted(openssl)
[junit-timeout] WARN
[Messaging-OUT-/127.0.0.1:7012->/127.0.0.1:7012-LARGE_MESSAGES] 2021-07-06
12:17:23,868 OutboundConnection.java:488 -
/127.0.0.1:7012->/127.0.0.1:7012-LARGE_MESSAGES-[no-channel] dropping message
of type _TEST_1 due to error
[junit-timeout] org.apache.cassandra.net.AsyncChannelOutputPlus$FlushException:
This output stream is in an unsafe state after an asynchronous flush failed
[junit-timeout] at
org.apache.cassandra.net.AsyncChannelOutputPlus.propagateFailedFlush(AsyncChannelOutputPlus.java:201)
[junit-timeout] at
org.apache.cassandra.net.AsyncChannelOutputPlus.waitUntilFlushed(AsyncChannelOutputPlus.java:158)
[junit-timeout] at
org.apache.cassandra.net.AsyncChannelOutputPlus.flush(AsyncChannelOutputPlus.java:230)
[junit-timeout] at
org.apache.cassandra.net.AsyncChannelOutputPlus.close(AsyncChannelOutputPlus.java:248)
[junit-timeout] at
org.apache.cassandra.net.AsyncMessageOutputPlus.close(AsyncMessageOutputPlus.java:110)
[junit-timeout] at
org.apache.cassandra.net.OutboundConnection$LargeMessageDelivery.doRun(OutboundConnection.java:986)
[junit-timeout] at
org.apache.cassandra.net.OutboundConnection$Delivery.run(OutboundConnection.java:687)
[junit-timeout] at
org.apache.cassandra.net.OutboundConnection$LargeMessageDelivery.run(OutboundConnection.java:955)
[junit-timeout] at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[junit-timeout] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[junit-timeout] at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
[junit-timeout] at java.lang.Thread.run(Thread.java:748)
[junit-timeout] Caused by: io.netty.handler.ssl.SslClosedEngineException:
SSLEngine closed already
[junit-timeout] at
io.netty.handler.ssl.SslHandler.wrap(SslHandler.java:854)
[junit-timeout] at
io.netty.handler.ssl.SslHandler.wrapAndFlush(SslHandler.java:811)
[junit-timeout] at
io.netty.handler.ssl.SslHandler.flush(SslHandler.java:792)
[junit-timeout] at
io.netty.channel.AbstractChannelHandlerContext.invokeFlush0(AbstractChannelHandlerContext.java:750)
[junit-timeout] at
io.netty.channel.AbstractChannelHandlerContext.invokeFlush(AbstractChannelHandlerContext.java:742)
[junit-timeout] at
io.netty.channel.AbstractChannelHandlerContext.flush(AbstractChannelHandlerContext.java:728)
[junit-timeout] at
io.netty.channel.ChannelOutboundHandlerAdapter.flush(ChannelOutboundHandlerAdapter.java:125)
[junit-timeout] at
io.netty.channel.AbstractChannelHandlerContext.invokeFlush0(AbstractChannelHandlerContext.java:750)
[junit-timeout] at
io.netty.channel.AbstractChannelHandlerContext.invokeWriteAndFlush(AbstractChannelHandlerContext.java:765)
[junit-timeout] at
io.netty.channel.AbstractChannelHandlerContext$WriteTask.run(AbstractChannelHandlerContext.java:1071)
[junit-timeout] at
io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
[junit-timeout] at
io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
[junit-timeout] at
io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:384)
[junit-timeout] at
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
[junit-timeout] at
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
[junit-timeout] ... 2 common frames omitted
{noformat}
{noformat}
[junit-timeout] org.apache.cassandra.net.AsyncChannelOutputPlus$FlushException:
The channel this output stream was writing to has been closed
[junit-timeout] at
org.apache.cassandra.net.AsyncChannelOutputPlus.propaga
[jira] [Comment Edited] (CASSANDRA-16621) Replace spinAsserts code with Awaitility code
[
https://issues.apache.org/jira/browse/CASSANDRA-16621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17375977#comment-17375977
]
Jogesh Anand edited comment on CASSANDRA-16621 at 7/7/21, 6:04 AM:
---
[~bereng] - thanks! yeah there are some failures. When I run the failed tests
locally ie ViewComplexLivenessTest and ViewFilteringClustering1Test they
succeed on every run.
The exception that I get on the
[circle-ci|https://circleci.com/api/v1.1/project/github/djanand/cassandra/3/output/104/0?file=true&allocation-id=60deafb9c3492162b60b9b5e-0-build%2F58BCD97C]
tests is:
{code:java}
com.datastax.driver.core.exceptions.ProtocolError: An unexpected protocol error
occurred on host localhost/127.0.0.1:36945. This is a bug in this library,
please report: Must not send frame with WARNING flag for native protocol
version < 4
[junit-timeout] at
com.datastax.driver.core.exceptions.ProtocolError.copy(ProtocolError.java:66)
[junit-timeout] at
com.datastax.driver.core.exceptions.ProtocolError.copy(ProtocolError.java:27)
[junit-timeout] at
com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:35)
[junit-timeout] at
com.datastax.driver.core.DefaultResultSetFuture.getUninterruptibly(DefaultResultSetFuture.java:293)
{code}
-When debugging locally, I see that DriverThrowables class loads from
cassandra-driver-core-3.11.0-shaded.jar which has no line:35 in it.-
-This leads me to believe that the build on circle-ci is using a different
version of driver than local.-
ps: I'm using the default .circleci/config.yml
was (Author: djanand):
[~bereng] - thanks! yeah there are some failures. When I run the failed tests
locally ie ViewComplexLivenessTest and ViewFilteringClustering1Test they
succeed on every run.
The exception that I get on the
[circle-ci|https://circleci.com/api/v1.1/project/github/djanand/cassandra/3/output/104/0?file=true&allocation-id=60deafb9c3492162b60b9b5e-0-build%2F58BCD97C]
tests is:
{code:java}
com.datastax.driver.core.exceptions.ProtocolError: An unexpected protocol error
occurred on host localhost/127.0.0.1:36945. This is a bug in this library,
please report: Must not send frame with WARNING flag for native protocol
version < 4
[junit-timeout] at
com.datastax.driver.core.exceptions.ProtocolError.copy(ProtocolError.java:66)
[junit-timeout] at
com.datastax.driver.core.exceptions.ProtocolError.copy(ProtocolError.java:27)
[junit-timeout] at
com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:35)
[junit-timeout] at
com.datastax.driver.core.DefaultResultSetFuture.getUninterruptibly(DefaultResultSetFuture.java:293)
{code}
When debugging locally, I see that DriverThrowables class loads from
cassandra-driver-core-3.11.0-shaded.jar which has no line:35 in it.
This leads me to believe that the build on circle-ci is using a different
version of driver than local.
ps: I'm using the default .circleci/config.yml
> Replace spinAsserts code with Awaitility code
> -
>
> Key: CASSANDRA-16621
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16621
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Jogesh Anand
>Priority: Normal
> Labels: low-hanging-fruit
> Fix For: 4.0.x
>
>
> Currently spinAsserts does a similar thing to Awaitility which is being used
> more and more. We have now 2 ways of doing the same thing so it would be good
> to consolidate
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16774) BinLog does not close chronicle queue leaving this to GC to cleanup
[
https://issues.apache.org/jira/browse/CASSANDRA-16774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17376245#comment-17376245
]
Berenguer Blasi commented on CASSANDRA-16774:
-
The failures are unrelated. And that {{UnableToParseClientMessageTest}} I'd
swear I've seen before. So I think we're good to merge imo. +1
> BinLog does not close chronicle queue leaving this to GC to cleanup
> ---
>
> Key: CASSANDRA-16774
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16774
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python, Tool/fql
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.0.1, 4.1
>
>
> auditlog_test.py::TestAuditlog::test_archiving_fql and
> test_fql_nodetool_options fail from time to time due to the test relying on a
> race condition; we do not close chronicle queue so rotation may not happen
> before stopping archiver, the tests fail if rotation happens before stopping
> archiver (which is done based off GC).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16774) BinLog does not close chronicle queue leaving this to GC to cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-16774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17376136#comment-17376136 ] Ekaterina Dimitrova edited comment on CASSANDRA-16774 at 7/7/21, 1:12 AM: -- I haven't seen it before. It doesn't fail for me locally in 4.0.0. Considering that the failing assert is based on a grep in the logs, I would say probably there is some test flakiness somewhere and we should improve the test... I can take a look these days. This failing test doesn't exercise the code you changed was (Author: e.dimitrova): I haven't seen it before. It doesn't fail for me locally in 4.0.0. Considering that the assert is based on a grep in the logs, I would say probably there is some test flakiness somewhere and we should improve the test... I can take a look these days. This failing test doesn't exercise the code you changed > BinLog does not close chronicle queue leaving this to GC to cleanup > --- > > Key: CASSANDRA-16774 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16774 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python, Tool/fql >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0.1, 4.1 > > > auditlog_test.py::TestAuditlog::test_archiving_fql and > test_fql_nodetool_options fail from time to time due to the test relying on a > race condition; we do not close chronicle queue so rotation may not happen > before stopping archiver, the tests fail if rotation happens before stopping > archiver (which is done based off GC). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16774) BinLog does not close chronicle queue leaving this to GC to cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-16774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17376136#comment-17376136 ] Ekaterina Dimitrova commented on CASSANDRA-16774: - I haven't seen it before. It doesn't fail for me locally in 4.0.0. Considering that the assert is based on a grep in the logs, I would say probably there is some test flakiness somewhere and we should improve the test... I can take a look these days. This failing test doesn't exercise the code you changed > BinLog does not close chronicle queue leaving this to GC to cleanup > --- > > Key: CASSANDRA-16774 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16774 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python, Tool/fql >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0.1, 4.1 > > > auditlog_test.py::TestAuditlog::test_archiving_fql and > test_fql_nodetool_options fail from time to time due to the test relying on a > race condition; we do not close chronicle queue so rotation may not happen > before stopping archiver, the tests fail if rotation happens before stopping > archiver (which is done based off GC). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15663) DESCRIBE KEYSPACE does not properly quote table names
[
https://issues.apache.org/jira/browse/CASSANDRA-15663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17376134#comment-17376134
]
Ekaterina Dimitrova edited comment on CASSANDRA-15663 at 7/7/21, 12:54 AM:
---
Thanks for the ping [~adelapena]. I spent some time today on this to remind
myself of that issue.
Indeed, it seems autocomplete and maybe some other cases show quotes and the
fix we worked on in CASSANDRA-16659 is not full.
First I thought, I should just update the reserved keywords in the driver but
then I reminded myself of
[https://datastax-oss.atlassian.net/browse/PYTHON-1270] which was discussed
here and I confirmed that the reported non-keyword in CASSANDRA-16659 is
actually a keyword for DSE.
It seems CASSANDRA-16659 was not really a bug but improvement if I read
correctly PYTHON-1270.
So I guess we have two options for this case - either we keep CASSANDRA-16659
patch as partial improvement or we revert it. As far as I know from Adam, no
one planned to work on the driver improvement for now.
Probably we can document this detail in a way as a known behavior?
CC [~aboudreault] as I saw he was also updating the DSE cql keywords list so
probably there were already similar discussions and output he might be able to
share with us.
was (Author: e.dimitrova):
Thanks for the ping [~adelapena]. I spent some time today on this to remind
myself of that issue.
Indeed, it seems autocomplete and maybe some other cases show quotes and the
fix we worked on in CASSANDRA-16659 is not full.
First I thought, I should just update the reserved keywords in the driver but
then I reminded myself of
[https://datastax-oss.atlassian.net/browse/PYTHON-1270] which was discussed
here and I confirmed that the reported non-keyword in CASSANDRA-16659 is
actually a keyword for DSE.
It seems CASSANDRA-16659 was not really a bug but improvement if I read
correctly PYTHON-1270.
So I guess we have two options for this case - either we keep CASSANDRA-16659
patch as partial improvement or we revert it. As far as I know from Adam, no
one planned to work on the driver improvement for now.
Probably we can document this detail in a way as a known behavior?
CC [~aboudreault] as I saw he was also updating the DSE lists so probably there
were already similar discussions and output he might be able to share with us.
> DESCRIBE KEYSPACE does not properly quote table names
> -
>
> Key: CASSANDRA-15663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15663
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Oskar Liljeblad
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Labels: pull-request-available
> Fix For: 3.11.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> How to reproduce (3.11.6) - cqlsh:
> {code}
> CREATE KEYSPACE test1 WITH replication = \{'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> CREATE TABLE test1."default" (id text PRIMARY KEY, data text, etag text);
> DESCRIBE KEYSPACE test1;
> {code}
> Output will be:
> {code}
> CREATE TABLE test1.default (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> Output should be:
> {code}
> CREATE TABLE test1."default" (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> If you try to run {{CREATE TABLE test1.default [..]}} you will get an error
> SyntaxException: line 1:19 no viable alternative at input 'default' (CREATE
> TABLE test1.[default]...)
> Oskar Liljeblad
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15663) DESCRIBE KEYSPACE does not properly quote table names
[
https://issues.apache.org/jira/browse/CASSANDRA-15663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17376134#comment-17376134
]
Ekaterina Dimitrova commented on CASSANDRA-15663:
-
Thanks for the ping [~adelapena]. I spent some time today on this to remind
myself of that issue.
Indeed, it seems autocomplete and maybe some other cases show quotes and the
fix we worked on in CASSANDRA-16659 is not full.
First I thought, I should just update the reserved keywords in the driver but
then I reminded myself of
[https://datastax-oss.atlassian.net/browse/PYTHON-1270] which was discussed
here and I confirmed that the reported non-keyword in CASSANDRA-16659 is
actually a keyword for DSE.
It seems CASSANDRA-16659 was not really a bug but improvement if I read
correctly PYTHON-1270.
So I guess we have two options for this case - either we keep CASSANDRA-16659
patch as partial improvement or we revert it. As far as I know from Adam, no
one planned to work on the driver improvement for now.
Probably we can document this detail in a way as a known behavior?
CC [~aboudreault] as I saw he was also updating the DSE lists so probably there
were already similar discussions and output he might be able to share with us.
> DESCRIBE KEYSPACE does not properly quote table names
> -
>
> Key: CASSANDRA-15663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15663
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Oskar Liljeblad
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Labels: pull-request-available
> Fix For: 3.11.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> How to reproduce (3.11.6) - cqlsh:
> {code}
> CREATE KEYSPACE test1 WITH replication = \{'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> CREATE TABLE test1."default" (id text PRIMARY KEY, data text, etag text);
> DESCRIBE KEYSPACE test1;
> {code}
> Output will be:
> {code}
> CREATE TABLE test1.default (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> Output should be:
> {code}
> CREATE TABLE test1."default" (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> If you try to run {{CREATE TABLE test1.default [..]}} you will get an error
> SyntaxException: line 1:19 no viable alternative at input 'default' (CREATE
> TABLE test1.[default]...)
> Oskar Liljeblad
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16764) Compaction repeatedly fails validateReallocation exception
[
https://issues.apache.org/jira/browse/CASSANDRA-16764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17376067#comment-17376067
]
Richard Hesse commented on CASSANDRA-16764:
---
Right, I was afraid of that. Given that sstables are immutable, we can't
exactly go in and pop-out that bad record. Or is there a way to pipe the output
of sstabledump into another tool, stripping out the bad object with sstabledump?
> Compaction repeatedly fails validateReallocation exception
> --
>
> Key: CASSANDRA-16764
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16764
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS
>Reporter: Richard Hesse
>Priority: Normal
>
> I have a few nodes in my ring that are stuck repeatedly trying to compact the
> same tables over and over again. I've run through the usual trick of rolling
> restarts, and it doesn't seem to help. This exception is logged on the nodes:
> {code}
> ERROR [CompactionExecutor:6] 2021-06-25 20:28:30,001 CassandraDaemon.java:244
> - Exception in thread Thread[CompactionExecutor:6,1,main]
> java.lang.RuntimeException: null
> at
> org.apache.cassandra.io.util.DataOutputBuffer.validateReallocation(DataOutputBuffer.java:134)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.calculateNewSize(DataOutputBuffer.java:152)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.expandToFit(DataOutputBuffer.java:159)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.doFlush(DataOutputBuffer.java:119)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:132)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:151)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.utils.ByteBufferUtil.writeWithVIntLength(ByteBufferUtil.java:296)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.marshal.AbstractType.writeValue(AbstractType.java:426)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.ClusteringPrefix$Serializer.serializeValuesWithoutSize(ClusteringPrefix.java:323)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.Clustering$Serializer.serialize(Clustering.java:131)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.ClusteringPrefix$Serializer.serialize(ClusteringPrefix.java:266)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.Serializers$NewFormatSerializer.serialize(Serializers.java:167)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.Serializers$NewFormatSerializer.serialize(Serializers.java:154)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.sstable.IndexInfo$Serializer.serialize(IndexInfo.java:103)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.sstable.IndexInfo$Serializer.serialize(IndexInfo.java:82)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.ColumnIndex.addIndexBlock(ColumnIndex.java:216)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at org.apache.cassandra.db.ColumnIndex.add(ColumnIndex.java:264)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.ColumnIndex.buildRowIndex(ColumnIndex.java:111)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:173)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:136)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.compaction.writers.MaxSSTableSizeWriter.realAppend(MaxSSTableSizeWriter.java:98)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.append(CompactionAwareWriter.java:143)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:204)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:85)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> a
[jira] [Commented] (CASSANDRA-16774) BinLog does not close chronicle queue leaving this to GC to cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-16774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17376048#comment-17376048 ] Caleb Rackliffe commented on CASSANDRA-16774: - Tests [look good|https://ci-cassandra.apache.org/job/Cassandra-devbranch/897/], outside what appear to be 3 entirely unrelated failures. [~edimitrova] [~bereng] Any idea if the failure in [UnableToParseClientMessageTest|https://ci-cassandra.apache.org/job/Cassandra-devbranch/897/testReport/junit/org.apache.cassandra.distributed.test/UnableToParseClientMessageTest/badHeader_version_4_v4_/] is new. That's the only one I didn't find a Jira for. > BinLog does not close chronicle queue leaving this to GC to cleanup > --- > > Key: CASSANDRA-16774 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16774 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python, Tool/fql >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0.1, 4.1 > > > auditlog_test.py::TestAuditlog::test_archiving_fql and > test_fql_nodetool_options fail from time to time due to the test relying on a > race condition; we do not close chronicle queue so rotation may not happen > before stopping archiver, the tests fail if rotation happens before stopping > archiver (which is done based off GC). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-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&focusedCommentId=17376046#comment-17376046 ] Caleb Rackliffe commented on CASSANDRA-16681: - Saw this here: https://ci-cassandra.apache.org/job/Cassandra-devbranch/897/ > 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: 4.0, 4.0-rc > > 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.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16776) modify SecondaryIndexManager#indexPartition() to retrieve only columns for which indexes are actually being built
[
https://issues.apache.org/jira/browse/CASSANDRA-16776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-16776:
Test and Documentation Plan: The correctness of this improvement relies on
the existing 2i tests. Proof that it's actually an improvement is illustrated
by two new tests in {{CompactionAllocationTest}}.
Status: Patch Available (was: In Progress)
[trunk|https://github.com/apache/cassandra/pull/1098]
[CircleCI
J8|https://app.circleci.com/pipelines/github/maedhroz/cassandra/284/workflows/d095f8c2-d17d-4f9f-b5dd-0ab50f98901f]
[CircleCI
J11|https://app.circleci.com/pipelines/github/maedhroz/cassandra/284/workflows/4664cf14-7e0c-4680-8154-0a4fd340770a]
To see how the patch reduces allocations, enable compaction profiling in
{{CompactionAllocationTest}} and run the test
{{widePartitionsSingleIndexedColumn}}. (This test indexes only one of 4 normal
columns.) You should get about a 13% improvement in bytes allocated for index
builds.
ex.
{noformat}
INFO [main] 2021-07-06 15:16:01,720 CompactionAllocationTest.java:466 - ***
widePartitionsSingleIndexedColumn compaction summary
INFO [main] 2021-07-06 15:16:01,720 CompactionAllocationTest.java:467 -
463337000 bytes, 13099437 objects, 2145078 /partition, 2145 /row, 0 cpu
{noformat}
...then with the patch...
{noformat}
INFO [main] 2021-07-06 15:11:51,958 CompactionAllocationTest.java:466 - ***
widePartitionsSingleIndexedColumn compaction summary
INFO [main] 2021-07-06 15:11:51,958 CompactionAllocationTest.java:467 -
402830648 bytes, 11802336 objects, 1864956 /partition, 1864 /row, 0 cpu
{noformat}
> modify SecondaryIndexManager#indexPartition() to retrieve only columns for
> which indexes are actually being built
> -
>
> Key: CASSANDRA-16776
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16776
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/2i Index
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.x
>
> Attachments: index1.png, index2.png
>
>
> Secondary indexes are (for the moment) built as special compaction tasks via
> {{SecondaryIndexBuilder}}. From a profiling perspective, the fun begins in
> {{SecondaryIndexManager.indexPartition()}}. The work above it in
> {{SecondaryIndexBuilder}} is just key iteration.
> !index1.png!
> Two basic things happen in {{indexPartition()}}. First, we read a single
> partition in its entirety, and then we send individual rows to the
> {{Indexer}}. When we read these partitions, we use {{ColumnFilter.all()}},
> which ends up materializing full rows, even when we’re indexing a single
> column (or at least fewer columns than we need for all the indexes
> participating in the build). If we narrowed this to fetch only the necessary
> columns, we might be able to create less garbage in
> {{AbstractBTreePartition#searchIterator()}} when we create a copy of the
> underlying full row from disk.
> In some initial testing, I’ve been using a simple schema with fairly narrow
> rows.
> {noformat}
> CREATE TABLE tlp_stress.allow_filtering (
> partition_id text,
> row_id int,
> payload text,
> value int,
> PRIMARY KEY (partition_id, row_id)
> ) WITH CLUSTERING ORDER BY (row_id ASC)
> {noformat}
> The price of deserializing these rows is still visible, however, in the
> results of some basic sampling profiling.
> !index2.png!
> The possible optimization above to avoid unnecessary copying of a row’s
> columns would also narrow cell deserialization only to indexed cells, which
> would probably be very beneficial for index builds with very wide rows. One
> minor wrinkle in all of this is that since 3.0, it has been possible to
> create indexes one entire rows, rather than single columns, so we’d have to
> keep that case in mind.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16760) JMXTimer exposes attributes in inconsistent time units
[ https://issues.apache.org/jira/browse/CASSANDRA-16760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17375976#comment-17375976 ] Caleb Rackliffe edited comment on CASSANDRA-16760 at 7/6/21, 7:51 PM: -- [~yifanc] Made one minor comment on the dtest PR, but outside of that and a couple [linter items|https://app.travis-ci.com/github/apache/cassandra-dtest/builds/231838725], everything LGTM was (Author: maedhroz): [~yifanc] Made one minor comment on the dtest PR, but otherwise, everything LGTM > JMXTimer exposes attributes in inconsistent time units > -- > > Key: CASSANDRA-16760 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16760 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Observability >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Fix For: 4.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > JMXTimer objects are constructed with a duration time unit, which is fixed to > MICROSECONDS in the codebase. According to that, we should expect the time > values returned from the JXMTimer are in micros. > However, the time unit is inconsistent among the JMXTimer attributes. > Most of the attributes such as percentiles and mean values returned are in > micros, except Values and RecentValues. > Those 2 attributes expose the raw histogram values of the underlying Timer > (CodaHale) and the values are fixed to be based on nanos. > The inconsistency leads to confusion and mis-interpretation of the values, if > the end user is not familiar with the implementation details. One may > consider the Values and RecentValues are also in micros. > Besides the confusion, given the intention is to record the time values in > the micros resolution, we do not need to allocate 165 buckets in the > DecayingEstimatedHistogramReservoir. 165 buckets is necessary for nanos, but > not for micros. We can only allocate 90 buckets and it should reduce ~50% > memory footprint used by the Timers. > I'd like to propose an approach to scale the values being recorded in the > reservoirs used by Timers and reduce the allocation. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16621) Replace spinAsserts code with Awaitility code
[
https://issues.apache.org/jira/browse/CASSANDRA-16621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17375977#comment-17375977
]
Jogesh Anand edited comment on CASSANDRA-16621 at 7/6/21, 7:50 PM:
---
[~bereng] - thanks! yeah there are some failures. When I run the failed tests
locally ie ViewComplexLivenessTest and ViewFilteringClustering1Test they
succeed on every run.
The exception that I get on the
[circle-ci|https://circleci.com/api/v1.1/project/github/djanand/cassandra/3/output/104/0?file=true&allocation-id=60deafb9c3492162b60b9b5e-0-build%2F58BCD97C]
tests is:
{code:java}
com.datastax.driver.core.exceptions.ProtocolError: An unexpected protocol error
occurred on host localhost/127.0.0.1:36945. This is a bug in this library,
please report: Must not send frame with WARNING flag for native protocol
version < 4
[junit-timeout] at
com.datastax.driver.core.exceptions.ProtocolError.copy(ProtocolError.java:66)
[junit-timeout] at
com.datastax.driver.core.exceptions.ProtocolError.copy(ProtocolError.java:27)
[junit-timeout] at
com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:35)
[junit-timeout] at
com.datastax.driver.core.DefaultResultSetFuture.getUninterruptibly(DefaultResultSetFuture.java:293)
{code}
When debugging locally, I see that DriverThrowables class loads from
cassandra-driver-core-3.11.0-shaded.jar which has no line:35 in it.
This leads me to believe that the build on circle-ci is using a different
version of driver than local.
ps: I'm using the default .circleci/config.yml
was (Author: djanand):
[~bereng] - thanks! yeah there are some failures. When I run the failed tests
locally ie ViewComplexLivenessTest and ViewFilteringClustering1Test they
succeed on every run.
The exception that I get on the circle-ci tests is:
{code:java}
com.datastax.driver.core.exceptions.ProtocolError: An unexpected protocol error
occurred on host localhost/127.0.0.1:36945. This is a bug in this library,
please report: Must not send frame with WARNING flag for native protocol
version < 4
[junit-timeout] at
com.datastax.driver.core.exceptions.ProtocolError.copy(ProtocolError.java:66)
[junit-timeout] at
com.datastax.driver.core.exceptions.ProtocolError.copy(ProtocolError.java:27)
[junit-timeout] at
com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:35)
[junit-timeout] at
com.datastax.driver.core.DefaultResultSetFuture.getUninterruptibly(DefaultResultSetFuture.java:293)
{code}
When debugging locally, I see that DriverThrowables class loads from
cassandra-driver-core-3.11.0-shaded.jar which has no line:35 in it.
This leads me to believe that the build on circle-ci is using a different
version of driver than local.
ps: I'm using the default .circleci/config.yml
> Replace spinAsserts code with Awaitility code
> -
>
> Key: CASSANDRA-16621
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16621
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Jogesh Anand
>Priority: Normal
> Labels: low-hanging-fruit
> Fix For: 4.0.x
>
>
> Currently spinAsserts does a similar thing to Awaitility which is being used
> more and more. We have now 2 ways of doing the same thing so it would be good
> to consolidate
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16621) Replace spinAsserts code with Awaitility code
[
https://issues.apache.org/jira/browse/CASSANDRA-16621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17375977#comment-17375977
]
Jogesh Anand commented on CASSANDRA-16621:
--
[~bereng] - thanks! yeah there are some failures. When I run the failed tests
locally ie ViewComplexLivenessTest and ViewFilteringClustering1Test they
succeed on every run.
The exception that I get on the circle-ci tests is:
{code:java}
com.datastax.driver.core.exceptions.ProtocolError: An unexpected protocol error
occurred on host localhost/127.0.0.1:36945. This is a bug in this library,
please report: Must not send frame with WARNING flag for native protocol
version < 4
[junit-timeout] at
com.datastax.driver.core.exceptions.ProtocolError.copy(ProtocolError.java:66)
[junit-timeout] at
com.datastax.driver.core.exceptions.ProtocolError.copy(ProtocolError.java:27)
[junit-timeout] at
com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:35)
[junit-timeout] at
com.datastax.driver.core.DefaultResultSetFuture.getUninterruptibly(DefaultResultSetFuture.java:293)
{code}
When debugging locally, I see that DriverThrowables class loads from
cassandra-driver-core-3.11.0-shaded.jar which has no line:35 in it.
This leads me to believe that the build on circle-ci is using a different
version of driver than local.
ps: I'm using the default .circleci/config.yml
> Replace spinAsserts code with Awaitility code
> -
>
> Key: CASSANDRA-16621
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16621
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Jogesh Anand
>Priority: Normal
> Labels: low-hanging-fruit
> Fix For: 4.0.x
>
>
> Currently spinAsserts does a similar thing to Awaitility which is being used
> more and more. We have now 2 ways of doing the same thing so it would be good
> to consolidate
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16760) JMXTimer exposes attributes in inconsistent time units
[ https://issues.apache.org/jira/browse/CASSANDRA-16760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17375976#comment-17375976 ] Caleb Rackliffe commented on CASSANDRA-16760: - [~yifanc] Made one minor comment on the dtest PR, but otherwise, everything LGTM > JMXTimer exposes attributes in inconsistent time units > -- > > Key: CASSANDRA-16760 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16760 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Observability >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Fix For: 4.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > JMXTimer objects are constructed with a duration time unit, which is fixed to > MICROSECONDS in the codebase. According to that, we should expect the time > values returned from the JXMTimer are in micros. > However, the time unit is inconsistent among the JMXTimer attributes. > Most of the attributes such as percentiles and mean values returned are in > micros, except Values and RecentValues. > Those 2 attributes expose the raw histogram values of the underlying Timer > (CodaHale) and the values are fixed to be based on nanos. > The inconsistency leads to confusion and mis-interpretation of the values, if > the end user is not familiar with the implementation details. One may > consider the Values and RecentValues are also in micros. > Besides the confusion, given the intention is to record the time values in > the micros resolution, we do not need to allocate 165 buckets in the > DecayingEstimatedHistogramReservoir. 165 buckets is necessary for nanos, but > not for micros. We can only allocate 90 buckets and it should reduce ~50% > memory footprint used by the Timers. > I'd like to propose an approach to scale the values being recorded in the > reservoirs used by Timers and reduce the allocation. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16774) BinLog does not close chronicle queue leaving this to GC to cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-16774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17375966#comment-17375966 ] Jon Meredith commented on CASSANDRA-16774: -- +1, change looks good pending tests. > BinLog does not close chronicle queue leaving this to GC to cleanup > --- > > Key: CASSANDRA-16774 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16774 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python, Tool/fql >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0.1, 4.1 > > > auditlog_test.py::TestAuditlog::test_archiving_fql and > test_fql_nodetool_options fail from time to time due to the test relying on a > race condition; we do not close chronicle queue so rotation may not happen > before stopping archiver, the tests fail if rotation happens before stopping > archiver (which is done based off GC). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16774) BinLog does not close chronicle queue leaving this to GC to cleanup
[
https://issues.apache.org/jira/browse/CASSANDRA-16774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17375946#comment-17375946
]
Caleb Rackliffe commented on CASSANDRA-16774:
-
[~bereng] [~marcuse] [~e.dimitrova] [~jmeredithco] [~dcapwell] Here is a small
patch to back-port the change to {{cassandra-4.0.0}} (with a Jenkins run in
progress):
[branch|https://github.com/apache/cassandra/pull/1102],
[Jenkins|https://ci-cassandra.apache.org/job/Cassandra-devbranch/897/]
> BinLog does not close chronicle queue leaving this to GC to cleanup
> ---
>
> Key: CASSANDRA-16774
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16774
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python, Tool/fql
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.0.1, 4.1
>
>
> auditlog_test.py::TestAuditlog::test_archiving_fql and
> test_fql_nodetool_options fail from time to time due to the test relying on a
> race condition; we do not close chronicle queue so rotation may not happen
> before stopping archiver, the tests fail if rotation happens before stopping
> archiver (which is done based off GC).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16774) BinLog does not close chronicle queue leaving this to GC to cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-16774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17375869#comment-17375869 ] Caleb Rackliffe commented on CASSANDRA-16774: - [~bereng] I think you are correct. The simplest fix is probably just to make sure that the two line change from [this commit|https://github.com/dcapwell/cassandra/commit/f0a7ea411fe237543200b3c67a2f0fb34536c162] ends up in 4.0.0 instead of just 4.0. Seems like a reasonable candidate for a ninja-fix. > BinLog does not close chronicle queue leaving this to GC to cleanup > --- > > Key: CASSANDRA-16774 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16774 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python, Tool/fql >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0.1, 4.1 > > > auditlog_test.py::TestAuditlog::test_archiving_fql and > test_fql_nodetool_options fail from time to time due to the test relying on a > race condition; we do not close chronicle queue so rotation may not happen > before stopping archiver, the tests fail if rotation happens before stopping > archiver (which is done based off GC). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16787) Copy from csv file with duration type fields fails to import
[
https://issues.apache.org/jira/browse/CASSANDRA-16787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16787:
---
Bug Category: Parent values: Code(13163)
Complexity: Low Hanging Fruit
Discovered By: User Report
Fix Version/s: 4.0.1
Severity: Normal
Status: Open (was: Triage Needed)
> Copy from csv file with duration type fields fails to import
>
>
> Key: CASSANDRA-16787
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16787
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Brijesh Dungarakoti
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0.1
>
> Attachments: error_cassandra_copy_from_1.JPG,
> error_cassandra_copy_from_2.JPG
>
>
> Getting error:
> _cqlsh> COPY users.user_credentials_by_email FROM '/home/ubuntu/users.csv'
> WITH HEADER = FALSE AND NULL='null';_
> _Using 3 child processes_
> _Starting copy of users.user_credentials_by_email with columns [email,
> la_duration]._
> _Failed to make batch statement: Received an argument of invalid type for
> column "la_duration". Expected: ,
> Got: ; (DurationType arguments must be a Duration.)_
> _Failed to import 1 rows: TypeError - Received an argument of invalid type
> for column "la_duration". Expected: 'cassandra.cqltypes.DurationType'>, Got: ; (DurationType
> arguments must be a Duration.), given up without retries_
> _Failed to process 1 rows; failed rows written to
> import_users_user_credentials_by_email.err_
> _Processed: 1 rows; Rate: 2 rows/s; Avg. rate: 2 rows/s_
> _0 rows imported from 1 files in 0.431 seconds (0 skipped)._
> *To Reproduce:*
> CREATE KEYSPACE users WITH replication = \{'class':
> 'NetworkTopologyStrategy', 'datacenter1': '1'} AND durable_writes = true;
> CREATE TABLE users.user_credentials_by_email (
> email text,
> la_duration duration,
> PRIMARY KEY(email)
> );
> create users.csv file with:
> l...@la.com,8m26s482ms
> Run:
> COPY users.user_credentials_by_email FROM '/home/automaton/users.csv' WITH
> HEADER = FALSE AND NULL='null';
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16787) Copy from csv file with duration type fields fails to import
[
https://issues.apache.org/jira/browse/CASSANDRA-16787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17375799#comment-17375799
]
Benjamin Lerer edited comment on CASSANDRA-16787 at 7/6/21, 3:22 PM:
-
The problem seems to be that we do not have a converter for {{duration}} within
the {{copyutil.py}} script.
was (Author: blerer):
The problem seems to be that we do not have a converter for duration within the
copyutil.py script.
> Copy from csv file with duration type fields fails to import
>
>
> Key: CASSANDRA-16787
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16787
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Brijesh Dungarakoti
>Assignee: Benjamin Lerer
>Priority: Normal
> Attachments: error_cassandra_copy_from_1.JPG,
> error_cassandra_copy_from_2.JPG
>
>
> Getting error:
> _cqlsh> COPY users.user_credentials_by_email FROM '/home/ubuntu/users.csv'
> WITH HEADER = FALSE AND NULL='null';_
> _Using 3 child processes_
> _Starting copy of users.user_credentials_by_email with columns [email,
> la_duration]._
> _Failed to make batch statement: Received an argument of invalid type for
> column "la_duration". Expected: ,
> Got: ; (DurationType arguments must be a Duration.)_
> _Failed to import 1 rows: TypeError - Received an argument of invalid type
> for column "la_duration". Expected: 'cassandra.cqltypes.DurationType'>, Got: ; (DurationType
> arguments must be a Duration.), given up without retries_
> _Failed to process 1 rows; failed rows written to
> import_users_user_credentials_by_email.err_
> _Processed: 1 rows; Rate: 2 rows/s; Avg. rate: 2 rows/s_
> _0 rows imported from 1 files in 0.431 seconds (0 skipped)._
> *To Reproduce:*
> CREATE KEYSPACE users WITH replication = \{'class':
> 'NetworkTopologyStrategy', 'datacenter1': '1'} AND durable_writes = true;
> CREATE TABLE users.user_credentials_by_email (
> email text,
> la_duration duration,
> PRIMARY KEY(email)
> );
> create users.csv file with:
> l...@la.com,8m26s482ms
> Run:
> COPY users.user_credentials_by_email FROM '/home/automaton/users.csv' WITH
> HEADER = FALSE AND NULL='null';
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16787) Copy from csv file with duration type fields fails to import
[
https://issues.apache.org/jira/browse/CASSANDRA-16787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17375799#comment-17375799
]
Benjamin Lerer commented on CASSANDRA-16787:
The problem seems to be that we do not have a converter for duration within the
copyutil.py script.
> Copy from csv file with duration type fields fails to import
>
>
> Key: CASSANDRA-16787
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16787
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Brijesh Dungarakoti
>Assignee: Benjamin Lerer
>Priority: Normal
> Attachments: error_cassandra_copy_from_1.JPG,
> error_cassandra_copy_from_2.JPG
>
>
> Getting error:
> _cqlsh> COPY users.user_credentials_by_email FROM '/home/ubuntu/users.csv'
> WITH HEADER = FALSE AND NULL='null';_
> _Using 3 child processes_
> _Starting copy of users.user_credentials_by_email with columns [email,
> la_duration]._
> _Failed to make batch statement: Received an argument of invalid type for
> column "la_duration". Expected: ,
> Got: ; (DurationType arguments must be a Duration.)_
> _Failed to import 1 rows: TypeError - Received an argument of invalid type
> for column "la_duration". Expected: 'cassandra.cqltypes.DurationType'>, Got: ; (DurationType
> arguments must be a Duration.), given up without retries_
> _Failed to process 1 rows; failed rows written to
> import_users_user_credentials_by_email.err_
> _Processed: 1 rows; Rate: 2 rows/s; Avg. rate: 2 rows/s_
> _0 rows imported from 1 files in 0.431 seconds (0 skipped)._
> *To Reproduce:*
> CREATE KEYSPACE users WITH replication = \{'class':
> 'NetworkTopologyStrategy', 'datacenter1': '1'} AND durable_writes = true;
> CREATE TABLE users.user_credentials_by_email (
> email text,
> la_duration duration,
> PRIMARY KEY(email)
> );
> create users.csv file with:
> l...@la.com,8m26s482ms
> Run:
> COPY users.user_credentials_by_email FROM '/home/automaton/users.csv' WITH
> HEADER = FALSE AND NULL='null';
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16714) Fix org.apache.cassandra.utils.SlidingTimeRateTest.testConcurrentUpdateAndGet
[ https://issues.apache.org/jira/browse/CASSANDRA-16714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16714: Status: Ready to Commit (was: Review In Progress) > Fix org.apache.cassandra.utils.SlidingTimeRateTest.testConcurrentUpdateAndGet > - > > Key: CASSANDRA-16714 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16714 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Ekaterina Dimitrova >Assignee: Aleksandr Sorokoumov >Priority: Normal > Fix For: 3.11.x > > > Fix org.apache.cassandra.utils.SlidingTimeRateTest.testConcurrentUpdateAndGet > in Cassandra 3.11 > [https://jenkins-cm4.apache.org/job/Cassandra-3.11/174/testReport/junit/org.apache.cassandra.utils/SlidingTimeRateTest/testConcurrentUpdateAndGet_cdc/] > We should also propagate the fix to 4.0 where the utility class and the tests > also exist but they are not currently in use so to remove the noise the tests > are currently skipped from running at the moment. For reference - > CASSANDRA-16713 > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16510) Make ReadCommand::toCQLString return valid CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-16510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-16510:
--
Source Control Link:
https://github.com/apache/cassandra/commit/e6a311f6898b1184d7d58826021a82cbda2f9bc0
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Make ReadCommand::toCQLString return valid CQL
> --
>
> Key: CASSANDRA-16510
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16510
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax, Observability/Logging
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The method {{ReadCommand::toCQLString}} doesn't always return queries that
> are valid CQL. For example, queries for a table without clustering columns
> always add the {{WHERE}} keyword even if there isn't a restriction following
> it:
> {code:java}
> CREATE TABLE t (k int PRIMARY KEY, v int);
> SELECT * FROM t;
> -- toCQLString 3.0:SELECT * FROM k.t WHERE () = () LIMIT 100
> -- toCQLString 3.11/trunk: SELECT * FROM k.t WHERE LIMIT 100
> {code}
> Also, case sensitive names and text values are not properly quoted:
> {code:java}
> CREATE TABLE "T" ("K" text, "C" text, "V" text, PRIMARY KEY("K", "C"));
> SELECT * FROM "T" WHERE "K" = 'a' AND "C" = 'b' AND "V" = 'c' ALLOW FILTERING;
> -- toCQLString 3.0/3.11/trunk: SELECT * FROM k.T WHERE K = a AND V = c AND
> (C) = (b) LIMIT 100
> {code}
> Similar problems can be found on selections of collection items:
> {code:java}
> CREATE TABLE k.t (k int, c int, s set, m map, PRIMARY
> KEY(k, c));
> SELECT s['a'] FROM t;
> -- toCQLString trunk: SELECT s[a] FROM k.t LIMIT 100
> SELECT * FROM t WHERE m['a'] = 'b' ALLOW FILTERING;
> -- toCQLString 3.0/3.11/trunk: SELECT * FROM k.t WHERE m[a] = b LIMIT 100
> {code}
> Some similar problems with more impact than the described above are already
> being addressed in CASSANDRA-16483 and CASSANDRA-16479.
> I think we should add more exhaustive JUnit tests for
> {{ReadCommand::toCQLString}}, making sure that its output is parseable and
> equivalent to the original command. Also, we probably should make sure that
> we have {{toCQLString}} methods in all the query components that are used by
> {{ReadCommand::toCQLString}} (selection, filters, etc.). This way we can use
> them instead of generic {{toString}} methods, making it clear that they are
> supposed to return valid CQL.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16510) Make ReadCommand::toCQLString return valid CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-16510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17375678#comment-17375678
]
Andres de la Peña commented on CASSANDRA-16510:
---
Agree, we can always backport it. Committed to trunk as
[e6a311f6898b1184d7d58826021a82cbda2f9bc0|https://github.com/apache/cassandra/commit/e6a311f6898b1184d7d58826021a82cbda2f9bc0].
Thanks again for the review.
> Make ReadCommand::toCQLString return valid CQL
> --
>
> Key: CASSANDRA-16510
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16510
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax, Observability/Logging
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The method {{ReadCommand::toCQLString}} doesn't always return queries that
> are valid CQL. For example, queries for a table without clustering columns
> always add the {{WHERE}} keyword even if there isn't a restriction following
> it:
> {code:java}
> CREATE TABLE t (k int PRIMARY KEY, v int);
> SELECT * FROM t;
> -- toCQLString 3.0:SELECT * FROM k.t WHERE () = () LIMIT 100
> -- toCQLString 3.11/trunk: SELECT * FROM k.t WHERE LIMIT 100
> {code}
> Also, case sensitive names and text values are not properly quoted:
> {code:java}
> CREATE TABLE "T" ("K" text, "C" text, "V" text, PRIMARY KEY("K", "C"));
> SELECT * FROM "T" WHERE "K" = 'a' AND "C" = 'b' AND "V" = 'c' ALLOW FILTERING;
> -- toCQLString 3.0/3.11/trunk: SELECT * FROM k.T WHERE K = a AND V = c AND
> (C) = (b) LIMIT 100
> {code}
> Similar problems can be found on selections of collection items:
> {code:java}
> CREATE TABLE k.t (k int, c int, s set, m map, PRIMARY
> KEY(k, c));
> SELECT s['a'] FROM t;
> -- toCQLString trunk: SELECT s[a] FROM k.t LIMIT 100
> SELECT * FROM t WHERE m['a'] = 'b' ALLOW FILTERING;
> -- toCQLString 3.0/3.11/trunk: SELECT * FROM k.t WHERE m[a] = b LIMIT 100
> {code}
> Some similar problems with more impact than the described above are already
> being addressed in CASSANDRA-16483 and CASSANDRA-16479.
> I think we should add more exhaustive JUnit tests for
> {{ReadCommand::toCQLString}}, making sure that its output is parseable and
> equivalent to the original command. Also, we probably should make sure that
> we have {{toCQLString}} methods in all the query components that are used by
> {{ReadCommand::toCQLString}} (selection, filters, etc.). This way we can use
> them instead of generic {{toString}} methods, making it clear that they are
> supposed to return valid CQL.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Fix AbstractReadQuery::toCQLString not returning valid CQL
This is an automated email from the ASF dual-hosted git repository.
adelapena 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 e6a311f Fix AbstractReadQuery::toCQLString not returning valid CQL
e6a311f is described below
commit e6a311f6898b1184d7d58826021a82cbda2f9bc0
Author: Andrés de la Peña
AuthorDate: Tue Jul 6 13:20:34 2021 +0100
Fix AbstractReadQuery::toCQLString not returning valid CQL
patch by Andrés de la Peña; reviewed by Benjamin Lerer for CASSANDRA-16510
---
CHANGES.txt| 1 +
.../org/apache/cassandra/db/AbstractReadQuery.java | 9 +-
src/java/org/apache/cassandra/db/Clustering.java | 2 +-
src/java/org/apache/cassandra/db/DataRange.java| 24 +-
src/java/org/apache/cassandra/db/DecoratedKey.java | 32 +
.../cassandra/db/PartitionRangeReadCommand.java| 18 +-
src/java/org/apache/cassandra/db/ReadCommand.java | 15 +-
.../cassandra/db/SinglePartitionReadCommand.java | 18 +-
src/java/org/apache/cassandra/db/Slices.java | 54 +-
.../db/VirtualTablePartitionRangeReadQuery.java| 16 +-
.../db/VirtualTableSinglePartitionReadQuery.java | 18 +-
.../db/filter/AbstractClusteringIndexFilter.java | 9 +-
.../cassandra/db/filter/ClusteringIndexFilter.java | 3 +-
.../db/filter/ClusteringIndexNamesFilter.java | 31 +-
.../db/filter/ClusteringIndexSliceFilter.java | 8 +-
.../apache/cassandra/db/filter/ColumnFilter.java | 2 +-
.../cassandra/db/filter/ColumnSubselection.java| 18 +-
.../org/apache/cassandra/db/filter/RowFilter.java | 74 +-
.../apache/cassandra/db/marshal/AbstractType.java | 5 +
.../apache/cassandra/schema/ColumnMetadata.java| 5 +-
.../db/AbstractReadQueryToCQLStringTest.java | 818 +
.../cassandra/index/sasi/plan/OperationTest.java | 10 +
22 files changed, 1076 insertions(+), 114 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 0744d6a..dda7b90 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.1
+ * Fix AbstractReadQuery::toCQLString not returning valid CQL (CASSANDRA-16510)
* Log when compacting many tombstones (CASSANDRA-16780)
* Display bytes per level in tablestats for LCS tables (CASSANDRA-16799)
* Add isolated flush timer to CommitLogMetrics and ensure writes correspond
to single WaitingOnCommit data points (CASSANDRA-16701)
diff --git a/src/java/org/apache/cassandra/db/AbstractReadQuery.java
b/src/java/org/apache/cassandra/db/AbstractReadQuery.java
index ec1a6b1..374d2b2 100644
--- a/src/java/org/apache/cassandra/db/AbstractReadQuery.java
+++ b/src/java/org/apache/cassandra/db/AbstractReadQuery.java
@@ -17,6 +17,7 @@
*/
package org.apache.cassandra.db;
+import org.apache.cassandra.cql3.ColumnIdentifier;
import org.apache.cassandra.db.filter.ColumnFilter;
import org.apache.cassandra.db.filter.DataLimits;
import org.apache.cassandra.db.filter.RowFilter;
@@ -102,13 +103,17 @@ abstract class AbstractReadQuery extends MonitorableImpl
implements ReadQuery
StringBuilder sb = new StringBuilder().append("SELECT ")
.append(columnFilter().toCQLString())
.append(" FROM ")
- .append(metadata().keyspace)
+
.append(ColumnIdentifier.maybeQuote(metadata().keyspace))
.append('.')
- .append(metadata().name);
+
.append(ColumnIdentifier.maybeQuote(metadata().name));
appendCQLWhereClause(sb);
if (limits() != DataLimits.NONE)
sb.append(' ').append(limits());
+
+// ALLOW FILTERING might not be strictly necessary
+sb.append(" ALLOW FILTERING");
+
return sb.toString();
}
diff --git a/src/java/org/apache/cassandra/db/Clustering.java
b/src/java/org/apache/cassandra/db/Clustering.java
index c685638..f5184e9 100644
--- a/src/java/org/apache/cassandra/db/Clustering.java
+++ b/src/java/org/apache/cassandra/db/Clustering.java
@@ -72,7 +72,7 @@ public interface Clustering extends ClusteringPrefix
for (int i = 0; i < size(); i++)
{
ColumnMetadata c = metadata.clusteringColumns().get(i);
-sb.append(i == 0 ? "" : ", ").append(c.type.getString(get(i),
accessor()));
+sb.append(i == 0 ? "" : ",
").append(c.type.toCQLString(bufferAt(i)));
}
return sb.toString();
}
diff --git a/src/java/org/apache/cassandra/db/DataRange.java
b/src/java/org/apache/cassandra/db/DataRange.java
index 91a62b3..b322912 100644
--- a/src/java/org/apache/cassandra/db/DataRange.java
+++ b/src/java/org/apache/cassandra/db/DataRange.java
@@ -19,7 +19,6 @@
[jira] [Comment Edited] (CASSANDRA-15663) DESCRIBE KEYSPACE does not properly quote table names
[
https://issues.apache.org/jira/browse/CASSANDRA-15663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17375610#comment-17375610
]
Andres de la Peña edited comment on CASSANDRA-15663 at 7/6/21, 11:50 AM:
-
[~Ge] you are totally right, the solution in CASSANDRA-16659 is not enough
since pylib indirectly depends on {{cql_keywords_reserved}} on multiple places.
I think we should probably have a followup ticket on 4.0/4.x for either
reverting that approach and go back to using the driver keywords, or completing
the fix by removing the remaining dependencies. CC [~e.dimitrova]
As for this ticket, I agree that upgrading and patching the driver is the way
to go. However, it seems that something is missed in the upgraded driver since
it's not finding the dependency on both
[CircleCI|https://app.circleci.com/pipelines/github/adelapena/cassandra/635/workflows/762f47f2-0419-4e06-a342-d5258f1bbf16]
and
[Jenkins|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/892/tests/].
was (Author: adelapena):
[~Ge] you are totally right, the solution in CASSANDRA-16659 is not enough
since pylib indirectly depends on {{cql_keywords_reserved}} on multiple places.
I think we should probably have a followup ticket on 4.0/4.x for either
reverting that approach and go back to using the driver keywords, or completing
the fix it by removing the remaining dependencies. CC [~e.dimitrova]
As for this ticket, I agree that upgrading and patching the driver is the way
to go. However, it seems that something is missed in the upgraded driver since
it's not finding the dependency on both
[CircleCI|https://app.circleci.com/pipelines/github/adelapena/cassandra/635/workflows/762f47f2-0419-4e06-a342-d5258f1bbf16]
and
[Jenkins|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/892/tests/].
> DESCRIBE KEYSPACE does not properly quote table names
> -
>
> Key: CASSANDRA-15663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15663
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Oskar Liljeblad
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Labels: pull-request-available
> Fix For: 3.11.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> How to reproduce (3.11.6) - cqlsh:
> {code}
> CREATE KEYSPACE test1 WITH replication = \{'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> CREATE TABLE test1."default" (id text PRIMARY KEY, data text, etag text);
> DESCRIBE KEYSPACE test1;
> {code}
> Output will be:
> {code}
> CREATE TABLE test1.default (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> Output should be:
> {code}
> CREATE TABLE test1."default" (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> If you try to run {{CREATE TABLE test1.default [..]}} you will get an error
> SyntaxException: line 1:19 no viable alternative at input 'default' (CREATE
> TABLE test1.[default]...)
> Oskar Liljeblad
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15663) DESCRIBE KEYSPACE does not properly quote table names
[
https://issues.apache.org/jira/browse/CASSANDRA-15663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17375610#comment-17375610
]
Andres de la Peña commented on CASSANDRA-15663:
---
[~Ge] you are totally right, the solution in CASSANDRA-16659 is not enough
since pylib indirectly depends on {{cql_keywords_reserved}} on multiple places.
I think we should probably have a followup ticket on 4.0/4.x for either
reverting that approach and go back to using the driver keywords, or completing
the fix it by removing the remaining dependencies. CC [~e.dimitrova]
As for this ticket, I agree that upgrading and patching the driver is the way
to go. However, it seems that something is missed in the upgraded driver since
it's not finding the dependency on both
[CircleCI|https://app.circleci.com/pipelines/github/adelapena/cassandra/635/workflows/762f47f2-0419-4e06-a342-d5258f1bbf16]
and
[Jenkins|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/892/tests/].
> DESCRIBE KEYSPACE does not properly quote table names
> -
>
> Key: CASSANDRA-15663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15663
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Oskar Liljeblad
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Labels: pull-request-available
> Fix For: 3.11.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> How to reproduce (3.11.6) - cqlsh:
> {code}
> CREATE KEYSPACE test1 WITH replication = \{'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> CREATE TABLE test1."default" (id text PRIMARY KEY, data text, etag text);
> DESCRIBE KEYSPACE test1;
> {code}
> Output will be:
> {code}
> CREATE TABLE test1.default (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> Output should be:
> {code}
> CREATE TABLE test1."default" (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> If you try to run {{CREATE TABLE test1.default [..]}} you will get an error
> SyntaxException: line 1:19 no viable alternative at input 'default' (CREATE
> TABLE test1.[default]...)
> Oskar Liljeblad
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[ https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17375378#comment-17375378 ] Sam Tunnicliffe commented on CASSANDRA-16404: - bq. Sam Tunnicliffe Your are familiar with that part of the code. Would you have some time for a review? Probably not for a few days, but I will try to take a look this week if that's any use. > Provide a nodetool way of invalidating auth caches > -- > > Key: CASSANDRA-16404 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16404 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Authorization >Reporter: Sumanth Pasupuleti >Assignee: Alexey Zotov >Priority: Normal > Fix For: 4.x > > Time Spent: 40m > Remaining Estimate: 0h > > We currently have nodetool commands to invalidate certain caches like > KeyCache, RowCache and CounterCache. > Being able to invalidate auth caches as well can come in handy in situations > where, critical backend auth changes may need to be in effect right away for > all the connections, especially in configurations where cache validity is > chosen to be for a longer duration. An example can be that an authenticated > user "User1" is no longer authorized to access a table resource "table1" and > it is vital that this change is reflected right away, without having to wait > for cache expiry/refresh to trigger. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[ https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-16404: --- Status: Review In Progress (was: Patch Available) > Provide a nodetool way of invalidating auth caches > -- > > Key: CASSANDRA-16404 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16404 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Authorization >Reporter: Sumanth Pasupuleti >Assignee: Alexey Zotov >Priority: Normal > Fix For: 4.x > > Time Spent: 40m > Remaining Estimate: 0h > > We currently have nodetool commands to invalidate certain caches like > KeyCache, RowCache and CounterCache. > Being able to invalidate auth caches as well can come in handy in situations > where, critical backend auth changes may need to be in effect right away for > all the connections, especially in configurations where cache validity is > chosen to be for a longer duration. An example can be that an authenticated > user "User1" is no longer authorized to access a table resource "table1" and > it is vital that this change is reflected right away, without having to wait > for cache expiry/refresh to trigger. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[ https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17375375#comment-17375375 ] Benjamin Lerer commented on CASSANDRA-16404: [~azotcsit] Once again sorry for the delay. I did not realized that the JMX interface for that part of the code tend to be nested within the implementation classes. So I would do the same despite what I said earlier. Otherwise the patch look good to me but we would need another +1 from a committer. [~samt] Your are familiar with that part of the code. Would you have some time for a review? > Provide a nodetool way of invalidating auth caches > -- > > Key: CASSANDRA-16404 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16404 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Authorization >Reporter: Sumanth Pasupuleti >Assignee: Alexey Zotov >Priority: Normal > Fix For: 4.x > > Time Spent: 40m > Remaining Estimate: 0h > > We currently have nodetool commands to invalidate certain caches like > KeyCache, RowCache and CounterCache. > Being able to invalidate auth caches as well can come in handy in situations > where, critical backend auth changes may need to be in effect right away for > all the connections, especially in configurations where cache validity is > chosen to be for a longer duration. An example can be that an authenticated > user "User1" is no longer authorized to access a table resource "table1" and > it is vital that this change is reflected right away, without having to wait > for cache expiry/refresh to trigger. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16510) Make ReadCommand::toCQLString return valid CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-16510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17375358#comment-17375358
]
Benjamin Lerer commented on CASSANDRA-16510:
{quote}Do we agree on applying this only to trunk?{quote}
For now, I would do it only to trunk. We can always backport it later on if we
feel the need for it.
> Make ReadCommand::toCQLString return valid CQL
> --
>
> Key: CASSANDRA-16510
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16510
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax, Observability/Logging
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The method {{ReadCommand::toCQLString}} doesn't always return queries that
> are valid CQL. For example, queries for a table without clustering columns
> always add the {{WHERE}} keyword even if there isn't a restriction following
> it:
> {code:java}
> CREATE TABLE t (k int PRIMARY KEY, v int);
> SELECT * FROM t;
> -- toCQLString 3.0:SELECT * FROM k.t WHERE () = () LIMIT 100
> -- toCQLString 3.11/trunk: SELECT * FROM k.t WHERE LIMIT 100
> {code}
> Also, case sensitive names and text values are not properly quoted:
> {code:java}
> CREATE TABLE "T" ("K" text, "C" text, "V" text, PRIMARY KEY("K", "C"));
> SELECT * FROM "T" WHERE "K" = 'a' AND "C" = 'b' AND "V" = 'c' ALLOW FILTERING;
> -- toCQLString 3.0/3.11/trunk: SELECT * FROM k.T WHERE K = a AND V = c AND
> (C) = (b) LIMIT 100
> {code}
> Similar problems can be found on selections of collection items:
> {code:java}
> CREATE TABLE k.t (k int, c int, s set, m map, PRIMARY
> KEY(k, c));
> SELECT s['a'] FROM t;
> -- toCQLString trunk: SELECT s[a] FROM k.t LIMIT 100
> SELECT * FROM t WHERE m['a'] = 'b' ALLOW FILTERING;
> -- toCQLString 3.0/3.11/trunk: SELECT * FROM k.t WHERE m[a] = b LIMIT 100
> {code}
> Some similar problems with more impact than the described above are already
> being addressed in CASSANDRA-16483 and CASSANDRA-16479.
> I think we should add more exhaustive JUnit tests for
> {{ReadCommand::toCQLString}}, making sure that its output is parseable and
> equivalent to the original command. Also, we probably should make sure that
> we have {{toCQLString}} methods in all the query components that are used by
> {{ReadCommand::toCQLString}} (selection, filters, etc.). This way we can use
> them instead of generic {{toString}} methods, making it clear that they are
> supposed to return valid CQL.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
