[jira] [Comment Edited] (CASSANDRA-15565) Fix flaky test org.apache.cassandra.index.internal.CassandraIndexTest indexCorrectlyMarkedAsBuildAndRemoved
[
https://issues.apache.org/jira/browse/CASSANDRA-15565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17050184#comment-17050184
]
Jorge Bay edited comment on CASSANDRA-15565 at 3/4/20, 11:02 AM:
-
I've been trying to reproduce with no luck. I've run the test and the suite in
loop in CircleCI:
- [https://circleci.com/gh/jorgebay/cassandra/7]
- [https://circleci.com/gh/jorgebay/cassandra/12]
I've also run it in loop in my local machine.
>From the error message in the ticket, it's related to the initial condition of
>the test, it expects no other index present. The failure is mostly due to an
>issue with the cleanup of a prior test.
I'll submit a patch -using {{KEYSPACE_PER_TEST}}-, that way it will less
likely to fail in cascade after another test.
was (Author: jorgebg):
I've been trying to reproduce with no luck. I've run the test and the suite in
loop in CircleCI:
- https://circleci.com/gh/jorgebay/cassandra/7
- https://circleci.com/gh/jorgebay/cassandra/12
I've also run it in loop in my local machine.
>From the error message in the ticket, it's related to the initial condition of
>the test, it expects no other index present. The failure is mostly due to an
>issue with the cleanup of a prior test.
I'll submit a patch using {{KEYSPACE_PER_TEST}}, that way it will less likely
to fail in cascade after another test.
> Fix flaky test org.apache.cassandra.index.internal.CassandraIndexTest
> indexCorrectlyMarkedAsBuildAndRemoved
> ---
>
> Key: CASSANDRA-15565
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15565
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Jorge Bay
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
> junit.framework.AssertionFailedError: Got more rows than expected. Expected 1
> but got 4.
> at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:1098)
> at
> org.apache.cassandra.index.internal.CassandraIndexTest.indexCorrectlyMarkedAsBuildAndRemoved(CassandraIndexTest.java:499)
> 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)
> {code}
> The failure was seen on java 11.
--
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-15565) Fix flaky test org.apache.cassandra.index.internal.CassandraIndexTest indexCorrectlyMarkedAsBuildAndRemoved
[
https://issues.apache.org/jira/browse/CASSANDRA-15565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorge Bay updated CASSANDRA-15565:
--
Test and Documentation Plan: The fix involves using a before/after size
comparison to avoid failing as a result of another test failure.
Status: Patch Available (was: Open)
[PR|https://github.com/apache/cassandra/pull/461] and
[CI|https://app.circleci.com/pipelines/github/jorgebay/cassandra?branch=CASSANDRA-15565-fix].
> Fix flaky test org.apache.cassandra.index.internal.CassandraIndexTest
> indexCorrectlyMarkedAsBuildAndRemoved
> ---
>
> Key: CASSANDRA-15565
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15565
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Jorge Bay
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
> junit.framework.AssertionFailedError: Got more rows than expected. Expected 1
> but got 4.
> at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:1098)
> at
> org.apache.cassandra.index.internal.CassandraIndexTest.indexCorrectlyMarkedAsBuildAndRemoved(CassandraIndexTest.java:499)
> 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)
> {code}
> The failure was seen on java 11.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15565) Fix flaky test org.apache.cassandra.index.internal.CassandraIndexTest indexCorrectlyMarkedAsBuildAndRemoved
[
https://issues.apache.org/jira/browse/CASSANDRA-15565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorge Bay reassigned CASSANDRA-15565:
-
Assignee: Jorge Bay
> Fix flaky test org.apache.cassandra.index.internal.CassandraIndexTest
> indexCorrectlyMarkedAsBuildAndRemoved
> ---
>
> Key: CASSANDRA-15565
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15565
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Jorge Bay
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> {code}
> junit.framework.AssertionFailedError: Got more rows than expected. Expected 1
> but got 4.
> at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:1098)
> at
> org.apache.cassandra.index.internal.CassandraIndexTest.indexCorrectlyMarkedAsBuildAndRemoved(CassandraIndexTest.java:499)
> 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)
> {code}
> The failure was seen on java 11.
--
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-15565) Fix flaky test org.apache.cassandra.index.internal.CassandraIndexTest indexCorrectlyMarkedAsBuildAndRemoved
[
https://issues.apache.org/jira/browse/CASSANDRA-15565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17050184#comment-17050184
]
Jorge Bay commented on CASSANDRA-15565:
---
I've been trying to reproduce with no luck. I've run the test and the suite in
loop in CircleCI:
- https://circleci.com/gh/jorgebay/cassandra/7
- https://circleci.com/gh/jorgebay/cassandra/12
I've also run it in loop in my local machine.
>From the error message in the ticket, it's related to the initial condition of
>the test, it expects no other index present. The failure is mostly due to an
>issue with the cleanup of a prior test.
I'll submit a patch using {{KEYSPACE_PER_TEST}}, that way it will less likely
to fail in cascade after another test.
> Fix flaky test org.apache.cassandra.index.internal.CassandraIndexTest
> indexCorrectlyMarkedAsBuildAndRemoved
> ---
>
> Key: CASSANDRA-15565
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15565
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> {code}
> junit.framework.AssertionFailedError: Got more rows than expected. Expected 1
> but got 4.
> at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:1098)
> at
> org.apache.cassandra.index.internal.CassandraIndexTest.indexCorrectlyMarkedAsBuildAndRemoved(CassandraIndexTest.java:499)
> 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)
> {code}
> The failure was seen on java 11.
--
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-2848) Make the Client API support passing down timeouts
[ https://issues.apache.org/jira/browse/CASSANDRA-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Bay updated CASSANDRA-2848: - Reviewers: Dinesh Joshi, Jorge Bay (was: Dinesh Joshi) > Make the Client API support passing down timeouts > - > > Key: CASSANDRA-2848 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2848 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Client, Messaging/Internode >Reporter: Chris Goffinet >Assignee: Yifan Cai >Priority: Low > Labels: protocolv5 > Fix For: 4.0-beta > > Attachments: 2848-trunk-v2.txt, 2848-trunk.txt > > > Having a max server RPC timeout is good for worst case, but many applications > that have middleware in front of Cassandra, might have higher timeout > requirements. In a fail fast environment, if my application starting at say > the front-end, only has 20ms to process a request, and it must connect to X > services down the stack, by the time it hits Cassandra, we might only have > 10ms. I propose we provide the ability to specify the timeout on each call we > do optionally. -- 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-2848) Make the Client API support passing down timeouts
[ https://issues.apache.org/jira/browse/CASSANDRA-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17049255#comment-17049255 ] Jorge Bay commented on CASSANDRA-2848: -- I can help reviewing it and perform some end to end tests with a client driver. > Make the Client API support passing down timeouts > - > > Key: CASSANDRA-2848 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2848 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Client, Messaging/Internode >Reporter: Chris Goffinet >Assignee: Yifan Cai >Priority: Low > Labels: protocolv5 > Fix For: 4.0-beta > > Attachments: 2848-trunk-v2.txt, 2848-trunk.txt > > > Having a max server RPC timeout is good for worst case, but many applications > that have middleware in front of Cassandra, might have higher timeout > requirements. In a fail fast environment, if my application starting at say > the front-end, only has 20ms to process a request, and it must connect to X > services down the stack, by the time it hits Cassandra, we might only have > 10ms. I propose we provide the ability to specify the timeout on each call we > do optionally. -- 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-15299) CASSANDRA-13304 follow-up: improve checksumming and compression in protocol v5-beta
[
https://issues.apache.org/jira/browse/CASSANDRA-15299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17047432#comment-17047432
]
Jorge Bay commented on CASSANDRA-15299:
---
Let me know if I can help in anyway with this ticket (early review / tests).
> CASSANDRA-13304 follow-up: improve checksumming and compression in protocol
> v5-beta
> ---
>
> Key: CASSANDRA-15299
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15299
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Labels: protocolv5
> Fix For: 4.0-beta
>
>
> CASSANDRA-13304 made an important improvement to our native protocol: it
> introduced checksumming/CRC32 to request and response bodies. It’s an
> important step forward, but it doesn’t cover the entire stream. In
> particular, the message header is not covered by a checksum or a crc, which
> poses a correctness issue if, for example, {{streamId}} gets corrupted.
> Additionally, we aren’t quite using CRC32 correctly, in two ways:
> 1. We are calculating the CRC32 of the *decompressed* value instead of
> computing the CRC32 on the bytes written on the wire - losing the properties
> of the CRC32. In some cases, due to this sequencing, attempting to decompress
> a corrupt stream can cause a segfault by LZ4.
> 2. When using CRC32, the CRC32 value is written in the incorrect byte order,
> also losing some of the protections.
> See https://users.ece.cmu.edu/~koopman/pubs/KoopmanCRCWebinar9May2012.pdf for
> explanation for the two points above.
> Separately, there are some long-standing issues with the protocol - since
> *way* before CASSANDRA-13304. Importantly, both checksumming and compression
> operate on individual message bodies rather than frames of multiple complete
> messages. In reality, this has several important additional downsides. To
> name a couple:
> # For compression, we are getting poor compression ratios for smaller
> messages - when operating on tiny sequences of bytes. In reality, for most
> small requests and responses we are discarding the compressed value as it’d
> be smaller than the uncompressed one - incurring both redundant allocations
> and compressions.
> # For checksumming and CRC32 we pay a high overhead price for small messages.
> 4 bytes extra is *a lot* for an empty write response, for example.
> To address the correctness issue of {{streamId}} not being covered by the
> checksum/CRC32 and the inefficiency in compression and checksumming/CRC32, we
> should switch to a framing protocol with multiple messages in a single frame.
> I suggest we reuse the framing protocol recently implemented for internode
> messaging in CASSANDRA-15066 to the extent that its logic can be borrowed,
> and that we do it before native protocol v5 graduates from beta. See
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderCrc.java
> and
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderLZ4.java.
--
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-15299) CASSANDRA-13304 follow-up: improve checksumming and compression in protocol v5-beta
[
https://issues.apache.org/jira/browse/CASSANDRA-15299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17047432#comment-17047432
]
Jorge Bay edited comment on CASSANDRA-15299 at 2/28/20 10:27 AM:
-
Let me know if I can help in any way with this ticket (early review / tests).
was (Author: jorgebg):
Let me know if I can help in anyway with this ticket (early review / tests).
> CASSANDRA-13304 follow-up: improve checksumming and compression in protocol
> v5-beta
> ---
>
> Key: CASSANDRA-15299
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15299
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Labels: protocolv5
> Fix For: 4.0-beta
>
>
> CASSANDRA-13304 made an important improvement to our native protocol: it
> introduced checksumming/CRC32 to request and response bodies. It’s an
> important step forward, but it doesn’t cover the entire stream. In
> particular, the message header is not covered by a checksum or a crc, which
> poses a correctness issue if, for example, {{streamId}} gets corrupted.
> Additionally, we aren’t quite using CRC32 correctly, in two ways:
> 1. We are calculating the CRC32 of the *decompressed* value instead of
> computing the CRC32 on the bytes written on the wire - losing the properties
> of the CRC32. In some cases, due to this sequencing, attempting to decompress
> a corrupt stream can cause a segfault by LZ4.
> 2. When using CRC32, the CRC32 value is written in the incorrect byte order,
> also losing some of the protections.
> See https://users.ece.cmu.edu/~koopman/pubs/KoopmanCRCWebinar9May2012.pdf for
> explanation for the two points above.
> Separately, there are some long-standing issues with the protocol - since
> *way* before CASSANDRA-13304. Importantly, both checksumming and compression
> operate on individual message bodies rather than frames of multiple complete
> messages. In reality, this has several important additional downsides. To
> name a couple:
> # For compression, we are getting poor compression ratios for smaller
> messages - when operating on tiny sequences of bytes. In reality, for most
> small requests and responses we are discarding the compressed value as it’d
> be smaller than the uncompressed one - incurring both redundant allocations
> and compressions.
> # For checksumming and CRC32 we pay a high overhead price for small messages.
> 4 bytes extra is *a lot* for an empty write response, for example.
> To address the correctness issue of {{streamId}} not being covered by the
> checksum/CRC32 and the inefficiency in compression and checksumming/CRC32, we
> should switch to a framing protocol with multiple messages in a single frame.
> I suggest we reuse the framing protocol recently implemented for internode
> messaging in CASSANDRA-15066 to the extent that its logic can be borrowed,
> and that we do it before native protocol v5 graduates from beta. See
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderCrc.java
> and
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderLZ4.java.
--
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-15349) Add “Going away” message to the client protocol
[
https://issues.apache.org/jira/browse/CASSANDRA-15349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16969057#comment-16969057
]
Jorge Bay commented on CASSANDRA-15349:
---
I think the client should close the connection after draining, whenever
possible. This would allow completing the "going away" flow in a short period
of time on a healthy cluster.
The node could start rejecting new requests immediately with {{Overloaded}} to
facilitate draining and moving traffic to the other nodes.
I like the idea of reusing existing timeout settings ({{max(readtimeout,
writetimeout)}}), instead of introducing a new one.
> Add “Going away” message to the client protocol
> ---
>
> Key: CASSANDRA-15349
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15349
> Project: Cassandra
> Issue Type: New Feature
> Components: Messaging/Client
>Reporter: Alex Petrov
>Priority: Normal
>
> Add “Going away” message that allows node to announce its shutdown and let
> clients gracefully shutdown and not attempt further requests.
--
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-15349) Add “Going away” message to the client protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-15349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16968235#comment-16968235 ] Jorge Bay commented on CASSANDRA-15349: --- >From the driver side, we currently register to events only on the control >connection because the events are relevant to the state of the cluster as a >whole. In this case, given that is per connection (really per host, but its usually 1 connection per host) it could make sense to receive an event directly on each connection. We could reuse the existing event flow, adding a new event that all driver connections register to, something like "GOING_AWAY" that will tell the driver to drain the connection and close it, while avoiding to send additional requests to that node. The server node could wait for a window for all the client connections to be closed, starting tcp termination on the remaining connections. > Add “Going away” message to the client protocol > --- > > Key: CASSANDRA-15349 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15349 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Client >Reporter: Alex Petrov >Priority: Normal > Labels: client-impacting > > Add “Going away” message that allows node to announce its shutdown and let > clients gracefully shutdown and not attempt further requests. -- 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-15349) Add “Going away” message to the client protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-15349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16948380#comment-16948380 ] Jorge Bay commented on CASSANDRA-15349: --- Should we introduce this along a time window, between announcement and the actual close of the client connections? Currently the drivers get the protocol event from a single control connection. We should give time from the event to propagate to the rest of nodes and from there to clients. Otherwise, if the event is sent in close succession to the client connection tcp close, it won't be of much benefit. > Add “Going away” message to the client protocol > --- > > Key: CASSANDRA-15349 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15349 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Client >Reporter: Alex Petrov >Priority: Normal > Labels: client-impacting > > Add “Going away” message that allows node to announce its shutdown and let > clients gracefully shutdown and not attempt further requests. -- 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-15350) Add CAS “uncertainty” and “contention" messages that are currently propagated as a WriteTimeoutException.
[ https://issues.apache.org/jira/browse/CASSANDRA-15350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Bay updated CASSANDRA-15350: -- Labels: client-impacting protocolv5 (was: protocolv5) > Add CAS “uncertainty” and “contention" messages that are currently propagated > as a WriteTimeoutException. > - > > Key: CASSANDRA-15350 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15350 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Lightweight Transactions >Reporter: Alex Petrov >Priority: Normal > Labels: client-impacting, protocolv5 > > Right now, CAS uncertainty introduced in > https://issues.apache.org/jira/browse/CASSANDRA-6013 is propagating as > WriteTimeout. One of this conditions it manifests is when there’s at least > one acceptor that has accepted the value, which means that this value _may_ > still get accepted during the later round, despite the proposer failure. > Similar problem happens with CAS contention, which is also indistinguishable > from the “regular” timeout, even though it is visible in metrics correctly. -- 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-15299) CASSANDRA-13304 follow-up: improve checksumming and compression in protocol v5-beta
[
https://issues.apache.org/jira/browse/CASSANDRA-15299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16936567#comment-16936567
]
Jorge Bay commented on CASSANDRA-15299:
---
bq. we should switch to a framing protocol with multiple messages in a single
frame
Can you share what you had in mind? Would this mechanism be also available when
checksumming and/or compression is disabled? Are you thinking some kind of
window for flushing messages?
> CASSANDRA-13304 follow-up: improve checksumming and compression in protocol
> v5-beta
> ---
>
> Key: CASSANDRA-15299
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15299
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Labels: client-impacting, protocolv5
> Fix For: 4.0-beta
>
>
> CASSANDRA-13304 made an important improvement to our native protocol: it
> introduced checksumming/CRC32 to request and response bodies. It’s an
> important step forward, but it doesn’t cover the entire stream. In
> parcicular, the message header is not covered by a checksum or a crc, which
> poses a correctness issue if, for example, {{streamId}} gets corrupted.
> Additionally, we aren’t quite using CRC32 correctly, in two ways:
> 1. We are calculating the CRC32 of the *decompressed* value instead of
> computing the CRC32 on the bytes written on the wire - losing the properties
> of the CRC32. In some cases, due to this sequencing, attempting to decompress
> a corrupt stream can cause a segfault by LZ4.
> 2. When using CRC32, the CRC32 value is written in the incorrect byte order,
> also losing some of the protections.
> See https://users.ece.cmu.edu/~koopman/pubs/KoopmanCRCWebinar9May2012.pdf for
> explanation for the two points above.
> Separately, there are some long-standing issues with the protocol - since
> *way* before CASSANDRA-13304. Importantly, both checksumming and compression
> operate on individual message bodies rather than frames of multiple complete
> messages. In reality, this has several important additional downsides. To
> name a couple:
> # For compression, we are getting poor compression ratios for smaller
> messages - when operating on tiny sequences of bytes. In reality, for most
> small requests and responses we are discarding the compressed value as it’d
> be smaller than the uncompressed one - incurring both redundant allocations
> and compressions.
> # For checksumming and CRC32 we pay a high overhead price for small messages.
> 4 bytes extra is *a lot* for an empty write response, for example.
> To address the correctness issue of {{streamId}} not being covered by the
> checksum/CRC32 and the inefficiency in compression and checksumming/CRC32, we
> should switch to a framing protocol with multiple messages in a single frame.
> I suggest we reuse the framing protocol recently implemented for internode
> messaging in CASSANDRA-15066 to the extent that its logic can be borrowed,
> and that we do it before native protocol v5 graduates from beta. See
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderCrc.java
> and
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderLZ4.java.
--
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-14973) Bring v5 driver out of beta, introduce v6 before 4.0 release is cut
[ https://issues.apache.org/jira/browse/CASSANDRA-14973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Bay updated CASSANDRA-14973: -- Labels: client-impacting protocolv5 (was: ) > Bring v5 driver out of beta, introduce v6 before 4.0 release is cut > --- > > Key: CASSANDRA-14973 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14973 > Project: Cassandra > Issue Type: Task >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Urgent > Labels: client-impacting, protocolv5 > Fix For: 4.0, 4.0-rc > > > In http://issues.apache.org/jira/browse/CASSANDRA-12142, we’ve introduced > Beta flag for v5 protocol. However, up till now, v5 is in beta both in > [Cassandra|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/ProtocolVersion.java#L46] > and in > [java-driver|https://github.com/datastax/java-driver/blob/3.x/driver-core/src/main/java/com/datastax/driver/core/ProtocolVersion.java#L35]. > > Before the final 4.0 release is cut, we need to bring v5 out of beta and > finalise native protocol spec, and start bringing all new changes to v6 > protocol, which will be in beta. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15299) CASSANDRA-13304 follow-up: improve checksumming and compression in protocol v5-beta
[
https://issues.apache.org/jira/browse/CASSANDRA-15299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorge Bay updated CASSANDRA-15299:
--
Labels: client-impacting protocolv5 (was: )
> CASSANDRA-13304 follow-up: improve checksumming and compression in protocol
> v5-beta
> ---
>
> Key: CASSANDRA-15299
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15299
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Labels: client-impacting, protocolv5
> Fix For: 4.0-beta
>
>
> CASSANDRA-13304 made an important improvement to our native protocol: it
> introduced checksumming/CRC32 to request and response bodies. It’s an
> important step forward, but it doesn’t cover the entire stream. In
> parcicular, the message header is not covered by a checksum or a crc, which
> poses a correctness issue if, for example, {{streamId}} gets corrupted.
> Additionally, we aren’t quite using CRC32 correctly, in two ways:
> 1. We are calculating the CRC32 of the *decompressed* value instead of
> computing the CRC32 on the bytes written on the wire - losing the properties
> of the CRC32. In some cases, due to this sequencing, attempting to decompress
> a corrupt stream can cause a segfault by LZ4.
> 2. When using CRC32, the CRC32 value is written in the incorrect byte order,
> also losing some of the protections.
> See https://users.ece.cmu.edu/~koopman/pubs/KoopmanCRCWebinar9May2012.pdf for
> explanation for the two points above.
> Separately, there are some long-standing issues with the protocol - since
> *way* before CASSANDRA-13304. Importantly, both checksumming and compression
> operate on individual message bodies rather than frames of multiple complete
> messages. In reality, this has several important additional downsides. To
> name a couple:
> # For compression, we are getting poor compression ratios for smaller
> messages - when operating on tiny sequences of bytes. In reality, for most
> small requests and responses we are discarding the compressed value as it’d
> be smaller than the uncompressed one - incurring both redundant allocations
> and compressions.
> # For checksumming and CRC32 we pay a high overhead price for small messages.
> 4 bytes extra is *a lot* for an empty write response, for example.
> To address the correctness issue of {{streamId}} not being covered by the
> checksum/CRC32 and the inefficiency in compression and checksumming/CRC32, we
> should switch to a framing protocol with multiple messages in a single frame.
> I suggest we reuse the framing protocol recently implemented for internode
> messaging in CASSANDRA-15066 to the extent that its logic can be borrowed,
> and that we do it before native protocol v5 graduates from beta. See
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderCrc.java
> and
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderLZ4.java.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14688) Update protocol spec and class level doc with protocol checksumming details
[
https://issues.apache.org/jira/browse/CASSANDRA-14688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorge Bay updated CASSANDRA-14688:
--
Labels: protocolv5 (was: )
> Update protocol spec and class level doc with protocol checksumming details
> ---
>
> Key: CASSANDRA-14688
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14688
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/Documentation and Website
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Labels: protocolv5
> Fix For: 4.0, 4.0-beta
>
>
> CASSANDRA-13304 provides an option to add checksumming to the frame body of
> native protocol messages. The native protocol spec needs to be updated to
> reflect this ASAP. We should also verify that the javadoc comments describing
> the on-wire format in
> {{o.a.c.transport.frame.checksum.ChecksummingTransformer}} are up to date.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13527) Protocol [short] is used as unsigned and signed value
[
https://issues.apache.org/jira/browse/CASSANDRA-13527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorge Bay updated CASSANDRA-13527:
--
Labels: client-impacting (was: )
> Protocol [short] is used as unsigned and signed value
> -
>
> Key: CASSANDRA-13527
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13527
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jorge Bay
> Labels: client-impacting
>
> The protocol specification describes {{\[short\]}} as unsigned int16, but
> then on the section {{2.3. stream}} it describes it like a signed int16,
> being {{0x7fff}} the maximum positive value.
> Additionally, {{\[int\]}} and {{\[long\]}} are signed, making the identifier
> {{\[short\]}} somewhat confusing.
> For disambiguation, it would be nice to introduce {{\[ushort\]}} or
> {{\[unsigned short\]}} (replacing most entries) and leave {{\[short\]}} as
> signed value, mainly for stream ids.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-13527) Protocol [short] is used as unsigned and signed value
Jorge Bay created CASSANDRA-13527:
-
Summary: Protocol [short] is used as unsigned and signed value
Key: CASSANDRA-13527
URL: https://issues.apache.org/jira/browse/CASSANDRA-13527
Project: Cassandra
Issue Type: Bug
Reporter: Jorge Bay
The protocol specification describes {{\[short\]}} as unsigned int16, but then
on the section {{2.3. stream}} it describes it like a signed int16, being
{{0x7fff}} the maximum positive value.
Additionally, {{\[int\]}} and {{\[long\]}} are signed, making the identifier
{{\[short\]}} somewhat confusing.
For disambiguation, it would be nice to introduce {{\[ushort\]}} or
{{\[unsigned short\]}} (replacing most entries) and leave {{\[short\]}} as
signed value, mainly for stream ids.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-9996) Extra "keyspace updated" SchemaChange when creating/removing a table
[
https://issues.apache.org/jira/browse/CASSANDRA-9996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15936412#comment-15936412
]
Jorge Bay commented on CASSANDRA-9996:
--
This looks like a duplicate of CASSANDRA-9646.
> Extra "keyspace updated" SchemaChange when creating/removing a table
>
>
> Key: CASSANDRA-9996
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9996
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
>Reporter: Olivier Michallat
>Priority: Minor
> Fix For: 2.2.x
>
>
> When a table gets created or removed, 2.2 sends an extra "keyspace updated"
> schema change event in addition to the normal "table created" event. 2.1 only
> sends table created.
> In {{LegacySchemaTables#mergeKeyspaces}}, the keyspace is added to
> {{altered}} so it calls {{Schema#updateKeyspace}}, which triggers the event.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CASSANDRA-10041) "timeout during write query at consistency ONE" when updating counter at consistency QUORUM and 2 of 3 nodes alive
[
https://issues.apache.org/jira/browse/CASSANDRA-10041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15229862#comment-15229862
]
Jorge Bay commented on CASSANDRA-10041:
---
The difference with CASSANDRA-9620 is that this one can not be identified in
the retry policy.
Batch log writes that timeout contain that information in the error
{{writeType}}, which allows [retry
policies|https://github.com/datastax/java-driver/blob/3.0/driver-core/src/main/java/com/datastax/driver/core/policies/DefaultRetryPolicy.java#L108]
/ any clients to identify it and retry accordingly.
In this case, it is not possible to identify in which phase the counter
mutation failed.
> "timeout during write query at consistency ONE" when updating counter at
> consistency QUORUM and 2 of 3 nodes alive
> --
>
> Key: CASSANDRA-10041
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10041
> Project: Cassandra
> Issue Type: Bug
> Environment: centos 6.6 server, java version "1.8.0_45", cassandra
> 2.1.8, 3 machines, keyspace with replication factor 3
>Reporter: Anton Lebedevich
> Fix For: 2.1.x
>
>
> Test scenario is: kill -9 one node, wait 60 seconds, start it back, wait till
> it becomes available, wait 120 seconds (during that time all 3 nodes are up),
> repeat with the next node. Application reads from one table and updates
> counters in another table with consistency QUORUM. When one node out of 3 is
> killed application logs this exception for several seconds:
> {noformat}
> Caused by: com.datastax.driver.core.exceptions.WriteTimeoutException:
> Cassandra timeout during write query at consistency ONE (1 replica were
> required but only 0 acknowledged the write)
> at
> com.datastax.driver.core.Responses$Error$1.decode(Responses.java:57)
> ~[com.datastax.cassandra.cassandra-driver-core-2.1.6.jar:na]
> at
> com.datastax.driver.core.Responses$Error$1.decode(Responses.java:37)
> ~[com.datastax.cassandra.cassandra-driver-core-2.1.6.jar:na]
> at
> com.datastax.driver.core.Message$ProtocolDecoder.decode(Message.java:204)
> ~[com.datastax.cassandra.cassandra-driver-core-2.1.6.jar:na]
> at
> com.datastax.driver.core.Message$ProtocolDecoder.decode(Message.java:195)
> ~[com.datastax.cassandra.cassandra-driver-core-2.1.6.jar:na]
> at
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:89)
> [io.netty.netty-codec-4.0.27.Final.jar:4.0.27.Final]
> ... 13 common frames omitted
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10041) "timeout during write query at consistency ONE" when updating counter at consistency QUORUM and 2 of 3 nodes alive
[
https://issues.apache.org/jira/browse/CASSANDRA-10041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15228233#comment-15228233
]
Jorge Bay commented on CASSANDRA-10041:
---
I was able to reproduce it with 3.0.x:
{code}
ccm create test -n 3 -b -s -v 3.0.4
ccm node1 cqlsh
CREATE KEYSPACE ks1 WITH replication = {'class': 'SimpleStrategy',
'replication_factor' : 3};
USE ks1;
CREATE TABLE tbl1 (id int PRIMARY KEY, c counter);
CONSISTENCY QUORUM
UPDATE tbl1 SET c = c + 1 WHERE id = 1;
exit
ccm node2 pause
ccm node1 cqlsh
USE ks1
CONSISTENCY QUORUM
UPDATE tbl1 SET c = c + 1 WHERE id = 1;
{code}
> "timeout during write query at consistency ONE" when updating counter at
> consistency QUORUM and 2 of 3 nodes alive
> --
>
> Key: CASSANDRA-10041
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10041
> Project: Cassandra
> Issue Type: Bug
> Environment: centos 6.6 server, java version "1.8.0_45", cassandra
> 2.1.8, 3 machines, keyspace with replication factor 3
>Reporter: Anton Lebedevich
>Assignee: Sylvestor George
> Fix For: 2.1.x
>
>
> Test scenario is: kill -9 one node, wait 60 seconds, start it back, wait till
> it becomes available, wait 120 seconds (during that time all 3 nodes are up),
> repeat with the next node. Application reads from one table and updates
> counters in another table with consistency QUORUM. When one node out of 3 is
> killed application logs this exception for several seconds:
> {noformat}
> Caused by: com.datastax.driver.core.exceptions.WriteTimeoutException:
> Cassandra timeout during write query at consistency ONE (1 replica were
> required but only 0 acknowledged the write)
> at
> com.datastax.driver.core.Responses$Error$1.decode(Responses.java:57)
> ~[com.datastax.cassandra.cassandra-driver-core-2.1.6.jar:na]
> at
> com.datastax.driver.core.Responses$Error$1.decode(Responses.java:37)
> ~[com.datastax.cassandra.cassandra-driver-core-2.1.6.jar:na]
> at
> com.datastax.driver.core.Message$ProtocolDecoder.decode(Message.java:204)
> ~[com.datastax.cassandra.cassandra-driver-core-2.1.6.jar:na]
> at
> com.datastax.driver.core.Message$ProtocolDecoder.decode(Message.java:195)
> ~[com.datastax.cassandra.cassandra-driver-core-2.1.6.jar:na]
> at
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:89)
> [io.netty.netty-codec-4.0.27.Final.jar:4.0.27.Final]
> ... 13 common frames omitted
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10365) Consider storing types by their CQL names in schema tables instead of fully-qualified internal class names
[ https://issues.apache.org/jira/browse/CASSANDRA-10365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14954884#comment-14954884 ] Jorge Bay commented on CASSANDRA-10365: --- I agree: if the goal is to hide implementation details, can we come up with a new notation for UDT that provides name, keyspace and fields, without the need to resolve UDT based on a name? > Consider storing types by their CQL names in schema tables instead of > fully-qualified internal class names > -- > > Key: CASSANDRA-10365 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10365 > Project: Cassandra > Issue Type: Improvement >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko > Labels: client-impacting > Fix For: 3.0.0 rc2 > > > Consider saving CQL types names for column, UDF/UDA arguments and return > types, and UDT components. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9646) Duplicated schema change event for table creation
[ https://issues.apache.org/jira/browse/CASSANDRA-9646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Bay updated CASSANDRA-9646: - Labels: client-impacting (was: ) > Duplicated schema change event for table creation > - > > Key: CASSANDRA-9646 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9646 > Project: Cassandra > Issue Type: Bug > Environment: OSX 10.9 >Reporter: Jorge Bay > Labels: client-impacting > > When I create a table (or a function), I'm getting notifications for 2 > changes: > - Target:"KEYSPACE" and type: "UPDATED" > - Target: "TABLE" AND type "CREATED". > I think the first one should not be there. This only occurs with C* 2.2. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-9646) Duplicated schema change event for table creation
Jorge Bay created CASSANDRA-9646: Summary: Duplicated schema change event for table creation Key: CASSANDRA-9646 URL: https://issues.apache.org/jira/browse/CASSANDRA-9646 Project: Cassandra Issue Type: Bug Environment: OSX 10.9 Reporter: Jorge Bay When I create a table (or a function), I'm getting notifications for 2 changes: - Target:"KEYSPACE" and type: "UPDATED" - Target: "TABLE" AND type "CREATED". I think the first one should not be there. This only occurs with C* 2.2. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9620) Write timeout error for batch request gives wrong consistency
[
https://issues.apache.org/jira/browse/CASSANDRA-9620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593277#comment-14593277
]
Jorge Bay commented on CASSANDRA-9620:
--
You are right, it is for the batch log.
Maybe it would be a good idea to adjust the error message (either on Cassandra
side or at driver level) to let users know that what failed was the initial
batch log write as the current message can cause the user to understand that
they are not sending the correct consistency level.
> Write timeout error for batch request gives wrong consistency
> -
>
> Key: CASSANDRA-9620
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9620
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jorge Bay
>
> In case there is a write time out error when executing a batch with a
> consistency higher than ONE, error information returned is incorrect:
> {{"Cassandra timeout during write query at consistency ONE (0 replica(s)
> acknowledged the write over 1 required"}}
> *Consistency is always ONE and required acks is always 1*.
> To reproduce (pseudo-code):
> {code:java}
> //create a 2 node cluster
> createTwoNodeCluster();
> var session = cluster.connect();
> session.execute("create keyspace ks1 WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor' : 2}");
> session.execute("create table ks1.tbl1 (k text primary key, i int)");
> session.execute(new SimpleStatement("INSERT INTO ks1.tbl1 (k, i) VALUES
> ('one', 1)").setConsistencyLevel(ConsistencyLevel.ALL));
> //Stop the second node
> stopNode2();
> var batch = new BatchStatement();
> batch.add(new SimpleStatement("INSERT INTO ks1.tbl1 (k, i) VALUES ('two',
> 2)"));
> batch.add(new SimpleStatement("INSERT INTO ks1.tbl1 (k, i) VALUES ('three',
> 3)"));
> //This line will throw a WriteTimeoutException with a wrong consistency
> //Caused by an error response from Cassandra
> session.execute(batch.setConsistencyLevel(ConsistencyLevel.ALL));
> {code}
> Wrong error information could affect driver retry policies.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-9620) Write timeout error for batch request gives wrong consistency
Jorge Bay created CASSANDRA-9620:
Summary: Write timeout error for batch request gives wrong
consistency
Key: CASSANDRA-9620
URL: https://issues.apache.org/jira/browse/CASSANDRA-9620
Project: Cassandra
Issue Type: Bug
Reporter: Jorge Bay
In case there is a write time out error when executing a batch with a
consistency higher than ONE, error information returned is incorrect:
{{"Cassandra timeout during write query at consistency ONE (0 replica(s)
acknowledged the write over 1 required"}}
*Consistency is always ONE and required acks is always 1*.
To reproduce (pseudo-code):
{code:java}
//create a 2 node cluster
createTwoNodeCluster();
var session = cluster.connect();
session.execute("create keyspace ks1 WITH replication = {'class':
'SimpleStrategy', 'replication_factor' : 2}");
session.execute("create table ks1.tbl1 (k text primary key, i int)");
session.execute(new SimpleStatement("INSERT INTO ks1.tbl1 (k, i) VALUES ('one',
1)").setConsistencyLevel(ConsistencyLevel.ALL));
//Stop the second node
stopNode2();
var batch = new BatchStatement();
batch.add(new SimpleStatement("INSERT INTO ks1.tbl1 (k, i) VALUES ('two', 2)"));
batch.add(new SimpleStatement("INSERT INTO ks1.tbl1 (k, i) VALUES ('three',
3)"));
//This line will throw a WriteTimeoutException with a wrong consistency
//Caused by an error response from Cassandra
session.execute(batch.setConsistencyLevel(ConsistencyLevel.ALL));
{code}
Wrong error information could affect driver retry policies.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9411) Bound statement executions fail after adding a collection-type column
[
https://issues.apache.org/jira/browse/CASSANDRA-9411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14554482#comment-14554482
]
Jorge Bay commented on CASSANDRA-9411:
--
Server stack trace using C* 2.0.13:
{code}
ERROR [Native-Transport-Requests:53] 2015-05-21 17:04:10,840 ErrorMessage.java
(line 231) Unexpected exception during request
java.lang.ArrayIndexOutOfBoundsException: 2
at
org.apache.cassandra.cql3.statements.ColumnGroupMap.add(ColumnGroupMap.java:51)
at
org.apache.cassandra.cql3.statements.ColumnGroupMap.access$200(ColumnGroupMap.java:35)
at
org.apache.cassandra.cql3.statements.ColumnGroupMap$Builder.add(ColumnGroupMap.java:167)
at
org.apache.cassandra.cql3.statements.SelectStatement.processColumnFamily(SelectStatement.java:1237)
at
org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:1123)
at
org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:286)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:242)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:64)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:158)
at
org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:309)
at
org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:132)
at
org.apache.cassandra.transport.Message$Dispatcher.messageReceived(Message.java:321)
at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at
org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
at
org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.doRun(ChannelUpstreamEventRunnable.java:43)
at
org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:67)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{code}
> Bound statement executions fail after adding a collection-type column
> -
>
> Key: CASSANDRA-9411
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9411
> Project: Cassandra
> Issue Type: Bug
> Environment: Cassandra 2.0.13.
> OS X 10.9
>Reporter: Jorge Bay
>Assignee: Benjamin Lerer
> Fix For: 2.0.x
>
>
> After adding a collection-type column to an existing table, executions of
> statements that are already prepared result in server error (error code 0),
> with the error message {{java.lang.ArrayIndexOutOfBoundsException}}.
> To reproduce it.
> {code:java}
> session.execute("CREATE TABLE tbl1 (a text, b text, c text, PRIMARY KEY (a,
> b))");
> //prepare initially
> PreparedStatement ps = session.prepare("SELECT a, b, c FROM tbl1");
> //insert some data
> session.execute("INSERT INTO tbl1 (a, b, c) VALUES ('a1', 'b1', 'c1')");
> //Executes successfully as expected
> session.execute(ps.bind());
> //Add a column of a collection type
> session.execute("ALTER TABLE tbl1 ADD d set");
> //All following executions fail
> session.execute(ps.bind());
> {code}
> Some notes:
> - This only occurs for SELECT with fields (not with SELECT *)
> - This only occurs with C* 2.0. Probably because CASSANDRA-7910 was applied
> for 2.1+
> - This only occurs if the column added is a collection type (list / set / map)
> - This occurs with all SELECT statements using that column family, that were
> already prepared.
> Repreparing it on all hosts fixes the issue, but for that, the user should
> normally restart existing application (even if the existing apps/apps
> versions don't handle this new field).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-9411) Bound statement executions fail after adding a collection-type column
[
https://issues.apache.org/jira/browse/CASSANDRA-9411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14554382#comment-14554382
]
Jorge Bay edited comment on CASSANDRA-9411 at 5/21/15 3:06 PM:
---
Server Stack trace, C* 2.0.11:
{code}
ERROR [Native-Transport-Requests:53] 2015-05-21 16:49:24,657 ErrorMessage.java
(line 230) Unexpected exception during request
java.lang.ArrayIndexOutOfBoundsException: 2
at
org.apache.cassandra.cql3.statements.ColumnGroupMap.add(ColumnGroupMap.java:48)
at
org.apache.cassandra.cql3.statements.ColumnGroupMap.access$200(ColumnGroupMap.java:32)
at
org.apache.cassandra.cql3.statements.ColumnGroupMap$Builder.add(ColumnGroupMap.java:140)
at
org.apache.cassandra.cql3.statements.SelectStatement.processColumnFamily(SelectStatement.java:1176)
at
org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:1079)
at
org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:285)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:241)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:65)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:158)
at
org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:309)
at
org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:132)
at
org.apache.cassandra.transport.Message$Dispatcher.messageReceived(Message.java:321)
at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at
org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
at
org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.doRun(ChannelUpstreamEventRunnable.java:43)
at
org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:67)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{code}
was (Author: jorgebg):
Server Stack trace:
{code}
ERROR [Native-Transport-Requests:53] 2015-05-21 16:49:24,657 ErrorMessage.java
(line 230) Unexpected exception during request
java.lang.ArrayIndexOutOfBoundsException: 2
at
org.apache.cassandra.cql3.statements.ColumnGroupMap.add(ColumnGroupMap.java:48)
at
org.apache.cassandra.cql3.statements.ColumnGroupMap.access$200(ColumnGroupMap.java:32)
at
org.apache.cassandra.cql3.statements.ColumnGroupMap$Builder.add(ColumnGroupMap.java:140)
at
org.apache.cassandra.cql3.statements.SelectStatement.processColumnFamily(SelectStatement.java:1176)
at
org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:1079)
at
org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:285)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:241)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:65)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:158)
at
org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:309)
at
org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:132)
at
org.apache.cassandra.transport.Message$Dispatcher.messageReceived(Message.java:321)
at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at
org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
at
org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.doRun(ChannelUpstreamEventRunnable.java:43)
at
org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:67)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{code}
> Bound statement executions fail after adding a collection-type column
> -
>
> Key: CASSANDRA-9411
> URL: https://issues.apache.org/jira/b
[jira] [Commented] (CASSANDRA-9411) Bound statement executions fail after adding a collection-type column
[
https://issues.apache.org/jira/browse/CASSANDRA-9411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14554382#comment-14554382
]
Jorge Bay commented on CASSANDRA-9411:
--
Server Stack trace:
{code}
ERROR [Native-Transport-Requests:53] 2015-05-21 16:49:24,657 ErrorMessage.java
(line 230) Unexpected exception during request
java.lang.ArrayIndexOutOfBoundsException: 2
at
org.apache.cassandra.cql3.statements.ColumnGroupMap.add(ColumnGroupMap.java:48)
at
org.apache.cassandra.cql3.statements.ColumnGroupMap.access$200(ColumnGroupMap.java:32)
at
org.apache.cassandra.cql3.statements.ColumnGroupMap$Builder.add(ColumnGroupMap.java:140)
at
org.apache.cassandra.cql3.statements.SelectStatement.processColumnFamily(SelectStatement.java:1176)
at
org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:1079)
at
org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:285)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:241)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:65)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:158)
at
org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:309)
at
org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:132)
at
org.apache.cassandra.transport.Message$Dispatcher.messageReceived(Message.java:321)
at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at
org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
at
org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.doRun(ChannelUpstreamEventRunnable.java:43)
at
org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:67)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{code}
> Bound statement executions fail after adding a collection-type column
> -
>
> Key: CASSANDRA-9411
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9411
> Project: Cassandra
> Issue Type: Bug
> Environment: Cassandra 2.0.13.
> OS X 10.9
>Reporter: Jorge Bay
>Assignee: Benjamin Lerer
> Fix For: 2.0.x
>
>
> After adding a collection-type column to an existing table, executions of
> statements that are already prepared result in server error (error code 0),
> with the error message {{java.lang.ArrayIndexOutOfBoundsException}}.
> To reproduce it.
> {code:java}
> session.execute("CREATE TABLE tbl1 (a text, b text, c text, PRIMARY KEY (a,
> b))");
> //prepare initially
> PreparedStatement ps = session.prepare("SELECT a, b, c FROM tbl1");
> //insert some data
> session.execute("INSERT INTO tbl1 (a, b, c) VALUES ('a1', 'b1', 'c1')");
> //Executes successfully as expected
> session.execute(ps.bind());
> //Add a column of a collection type
> session.execute("ALTER TABLE tbl1 ADD d set");
> //All following executions fail
> session.execute(ps.bind());
> {code}
> Some notes:
> - This only occurs for SELECT with fields (not with SELECT *)
> - This only occurs with C* 2.0. Probably because CASSANDRA-7910 was applied
> for 2.1+
> - This only occurs if the column added is a collection type (list / set / map)
> - This occurs with all SELECT statements using that column family, that were
> already prepared.
> Repreparing it on all hosts fixes the issue, but for that, the user should
> normally restart existing application (even if the existing apps/apps
> versions don't handle this new field).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-9451) Startup message response for unsupported protocol versions is incorrect
Jorge Bay created CASSANDRA-9451:
Summary: Startup message response for unsupported protocol
versions is incorrect
Key: CASSANDRA-9451
URL: https://issues.apache.org/jira/browse/CASSANDRA-9451
Project: Cassandra
Issue Type: Bug
Environment: OS X 10.9
Cassandra 2.1.5
Reporter: Jorge Bay
The response to a STARTUP request with protocol v4 on a C* 2.1 host is an error
with an incorrect error code (0).
Instead of the error code being "Protocol error" ({{0x000A}}) it has error code
0 and message (wrapped by netty):
{{"io.netty.handler.codec.DecoderException:
org.apache.cassandra.transport.ProtocolException: Invalid or unsupported
protocol version: 4"}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-9411) Bound statement executions fail after adding a collection-type column
Jorge Bay created CASSANDRA-9411:
Summary: Bound statement executions fail after adding a
collection-type column
Key: CASSANDRA-9411
URL: https://issues.apache.org/jira/browse/CASSANDRA-9411
Project: Cassandra
Issue Type: Bug
Environment: Cassandra 2.0.13.
OS X 10.9
Reporter: Jorge Bay
After adding a collection-type column to an existing table, executions of
statements that are already prepared result in server error (error code 0),
with the error message {{java.lang.ArrayIndexOutOfBoundsException}}.
To reproduce it.
{code:java}
session.execute("CREATE TABLE tbl1 (a text, b text, c text, PRIMARY KEY (a,
b))");
//prepare initially
PreparedStatement ps = session.prepare("SELECT a, b, c FROM tbl1");
//insert some data
session.execute("INSERT INTO tbl1 (a, b, c) VALUES ('a1', 'b1', 'c1')");
//Executes successfully as expected
session.execute(ps.bind());
//Add a column of a collection type
session.execute("ALTER TABLE tbl1 ADD d set");
//All following executions fail
session.execute(ps.bind());
{code}
Some notes:
- This only occurs for SELECT with fields (not with SELECT *)
- This only occurs with C* 2.0. Probably because CASSANDRA-7910 was applied for
2.1+
- This only occurs if the column added is a collection type (list / set / map)
- This occurs with all SELECT statements using that column family, that were
already prepared.
Repreparing it on all hosts fixes the issue, but for that, the user should
normally restart existing application (even if the existing apps/apps versions
don't handle this new field).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7679) Batch DDL
[
https://issues.apache.org/jira/browse/CASSANDRA-7679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14275488#comment-14275488
]
Jorge Bay commented on CASSANDRA-7679:
--
Sorry guys, dismiss my comment (insert a shame meme here): The wait for the
schema agreement after a schema change response was never implemented in the C#
driver and I though it was the common behaviour across all drivers.
> Batch DDL
> -
>
> Key: CASSANDRA-7679
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7679
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>
> Just an idea: To improve speed of DDL in clusters with lots of
> Keyspaces/Tables/Columns it might help to collect a bunch of schema changes
> and propagate them as a single bunch of changes.
> Such a DDL batch would
> # execute DDLs locally and collect all mutations
> # broadcast all mutations at once
> # schema agreement
> # return list via native protocol to the client
> So {{DefsTables.mergeSchemaInternal}} (which seems to be the expensive part)
> would only execute once per DDL batch on each node.
> DDL batches would not be atomic.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7679) Batch DDL
[
https://issues.apache.org/jira/browse/CASSANDRA-7679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14275227#comment-14275227
]
Jorge Bay commented on CASSANDRA-7679:
--
Consider the example using any driver with a round robin policy:
{code:java}
session.execute("CREATE TABLE tbl1 ...");
session.execute("INSERT INTO tbl1...");
{code}
In a multinode cluster, this will fail. [This includes any getting started
example that you can
find|http://www.datastax.com/documentation/developer/java-driver/2.1/java-driver/quick_start/qsSimpleClientAddSession_t.html].
I don't think its a good idea to force users to wait an undetermined amount of
time (even if its small) for them to be sure that the schema change was applied
in the cluster. This prevents tools similar to Rails Migrations (as a general
pattern) to be used with C*.
IMO, the "batching" (allowing multiple schema changes in one request) is not as
important as allowing users know that the schema change was applied in the
cluster.
> Batch DDL
> -
>
> Key: CASSANDRA-7679
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7679
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>
> Just an idea: To improve speed of DDL in clusters with lots of
> Keyspaces/Tables/Columns it might help to collect a bunch of schema changes
> and propagate them as a single bunch of changes.
> Such a DDL batch would
> # execute DDLs locally and collect all mutations
> # broadcast all mutations at once
> # schema agreement
> # return list via native protocol to the client
> So {{DefsTables.mergeSchemaInternal}} (which seems to be the expensive part)
> would only execute once per DDL batch on each node.
> DDL batches would not be atomic.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-8604) Batch Schema Changes at protocol level
Jorge Bay created CASSANDRA-8604: Summary: Batch Schema Changes at protocol level Key: CASSANDRA-8604 URL: https://issues.apache.org/jira/browse/CASSANDRA-8604 Project: Cassandra Issue Type: Improvement Reporter: Jorge Bay It would be nice to have a way to send to a cluster several DDL queries in 1 request and get a response when the schema change has been applied on all the (live) nodes. This could be helpful for dev teams that are used to create schema changes db scripts and deploy them as part of a version change (ie: Rails migrations). Also it can avoid race conditions between schema changes and querying that schema (in test env or other deployments). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8123) List appends when inserting in the same value
[ https://issues.apache.org/jira/browse/CASSANDRA-8123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14173462#comment-14173462 ] Jorge Bay commented on CASSANDRA-8123: -- Known gotcha is good enough. > List appends when inserting in the same value > - > > Key: CASSANDRA-8123 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8123 > Project: Cassandra > Issue Type: Bug > Environment: C* 2.1.0 and C* 2.0.10 >Reporter: Jorge Bay >Priority: Minor > > List append when inserting in the same value > I'm getting list appends when executing multiple times concurrently an INSERT > (or update) of a list column value on the same partition: > "INSERT INTO cf1 VALUES (id, list_sample) VALUES (id1, ['one', 'two']);" > It could result into a list with the values appended: ['one', 'two', 'one', > 'two', ...] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8123) List appends when inserting in the same value
[ https://issues.apache.org/jira/browse/CASSANDRA-8123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14172434#comment-14172434 ] Jorge Bay commented on CASSANDRA-8123: -- I understand what is causing it, but I think the behavior is unexpected: from an api perspective, the operation is to set the value to a new value. If the values are different with the same timestamp, any of the values should "win" but not append (appending is like doing a sum of 2 values in a single-value column, in the same situation). > List appends when inserting in the same value > - > > Key: CASSANDRA-8123 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8123 > Project: Cassandra > Issue Type: Bug > Environment: C* 2.1.0 and C* 2.0.10 >Reporter: Jorge Bay >Priority: Minor > > List append when inserting in the same value > I'm getting list appends when executing multiple times concurrently an INSERT > (or update) of a list column value on the same partition: > "INSERT INTO cf1 VALUES (id, list_sample) VALUES (id1, ['one', 'two']);" > It could result into a list with the values appended: ['one', 'two', 'one', > 'two', ...] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8123) List appends when inserting in the same value
[ https://issues.apache.org/jira/browse/CASSANDRA-8123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14172423#comment-14172423 ] Jorge Bay commented on CASSANDRA-8123: -- Just 1 node, 2 connections and issuing the insert request 100. Different threads and executing the requests 50 times per connection in parallel. > List appends when inserting in the same value > - > > Key: CASSANDRA-8123 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8123 > Project: Cassandra > Issue Type: Bug > Environment: C* 2.1.0 and C* 2.0.10 >Reporter: Jorge Bay >Priority: Minor > > List append when inserting in the same value > I'm getting list appends when executing multiple times concurrently an INSERT > (or update) of a list column value on the same partition: > "INSERT INTO cf1 VALUES (id, list_sample) VALUES (id1, ['one', 'two']);" > It could result into a list with the values appended: ['one', 'two', 'one', > 'two', ...] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-8123) List appends when inserting in the same value
[ https://issues.apache.org/jira/browse/CASSANDRA-8123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14172423#comment-14172423 ] Jorge Bay edited comment on CASSANDRA-8123 at 10/15/14 2:43 PM: Just 1 node, 2 connections and issuing the insert request 100 times. 2 Different threads and executing the requests 50 times per connection in parallel. was (Author: jorgebg): Just 1 node, 2 connections and issuing the insert request 100. Different threads and executing the requests 50 times per connection in parallel. > List appends when inserting in the same value > - > > Key: CASSANDRA-8123 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8123 > Project: Cassandra > Issue Type: Bug > Environment: C* 2.1.0 and C* 2.0.10 >Reporter: Jorge Bay >Priority: Minor > > List append when inserting in the same value > I'm getting list appends when executing multiple times concurrently an INSERT > (or update) of a list column value on the same partition: > "INSERT INTO cf1 VALUES (id, list_sample) VALUES (id1, ['one', 'two']);" > It could result into a list with the values appended: ['one', 'two', 'one', > 'two', ...] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8123) List appends when inserting in the same value
[ https://issues.apache.org/jira/browse/CASSANDRA-8123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14172326#comment-14172326 ] Jorge Bay commented on CASSANDRA-8123: -- I understand that if I'm going for unique values, I should use a set but I think the behavior is unexpected. > List appends when inserting in the same value > - > > Key: CASSANDRA-8123 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8123 > Project: Cassandra > Issue Type: Bug > Environment: C* 2.1.0 and C* 2.0.10 >Reporter: Jorge Bay >Priority: Minor > > List append when inserting in the same value > I'm getting list appends when executing multiple times concurrently an INSERT > (or update) of a list column value on the same partition: > "INSERT INTO cf1 VALUES (id, list_sample) VALUES (id1, ['one', 'two']);" > It could result into a list with the values appended: ['one', 'two', 'one', > 'two', ...] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-8123) List appends when inserting in the same value
Jorge Bay created CASSANDRA-8123: Summary: List appends when inserting in the same value Key: CASSANDRA-8123 URL: https://issues.apache.org/jira/browse/CASSANDRA-8123 Project: Cassandra Issue Type: Bug Environment: C* 2.1.0 and C* 2.0.10 Reporter: Jorge Bay Priority: Minor List append when inserting in the same value I'm getting list appends when executing multiple times concurrently an INSERT (or update) of a list column value on the same partition: "INSERT INTO cf1 VALUES (id, list_sample) VALUES (id1, ['one', 'two']);" It could result into a list with the values appended: ['one', 'two', 'one', 'two', ...] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7492) Udt inner collections under protocol 2
[
https://issues.apache.org/jira/browse/CASSANDRA-7492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051383#comment-14051383
]
Jorge Bay commented on CASSANDRA-7492:
--
If it involves deserialization of stored value vs and serialization to the
output value in a different format, I agree it looks like an unnecessary
overhead...
For the C# driver it makes sense to only support Udts under protocol 3, so you
can "wont fix" this.
> Udt inner collections under protocol 2
> --
>
> Key: CASSANDRA-7492
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7492
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Cassandra 2.1-rc2
>Reporter: Jorge Bay
>Priority: Minor
>
> Consider the following schema:
> {code:sql}
> CREATE TYPE phone (alias text, number text, country_code int);
> CREATE TYPE contact (first_name text, last_name text, birth_date timestamp,
> phones set, emails set);
> CREATE TABLE users_contacts (id int PRIMARY KEY, contact_value contact);
> {code}
> Under protocol v2, Cassandra serializes the phone *set* within contact udt,
> it uses protocol v3 collections format (4 byte lengths).
> As an UDT is a composition of other types, it makes sense to maintain the
> other types formatting (in this case 2 byte length).
> Possibly related to CASSANDRA-7472
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CASSANDRA-7492) Udt inner collections under protocol 2
Jorge Bay created CASSANDRA-7492:
Summary: Udt inner collections under protocol 2
Key: CASSANDRA-7492
URL: https://issues.apache.org/jira/browse/CASSANDRA-7492
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: Cassandra 2.1-rc2
Reporter: Jorge Bay
Consider the following schema:
{code:sql}
CREATE TYPE phone (alias text, number text, country_code int);
CREATE TYPE contact (first_name text, last_name text, birth_date timestamp,
phones set, emails set);
CREATE TABLE users_contacts (id int PRIMARY KEY, contact_value contact);
{code}
Under protocol v2, Cassandra serializes the phone *set* within contact udt, it
uses protocol v3 collections format (4 byte lengths).
As an UDT is a composition of other types, it makes sense to maintain the other
types formatting (in this case 2 byte length).
Possibly related to CASSANDRA-7472
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7451) Launch scripts on Windows don't handle spaces gracefully
[ https://issues.apache.org/jira/browse/CASSANDRA-7451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14044796#comment-14044796 ] Jorge Bay commented on CASSANDRA-7451: -- Looks good! +1 > Launch scripts on Windows don't handle spaces gracefully > > > Key: CASSANDRA-7451 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7451 > Project: Cassandra > Issue Type: Bug > Environment: 2.1.X >Reporter: Joshua McKenzie >Assignee: Joshua McKenzie >Priority: Minor > Labels: Windows > Fix For: 2.1.0 > > Attachments: 7451_v1.txt > > > There's also some .ps1 problems after we get past just the .bat. Should be > some trivial escaping to fix. > C:\src - Copy\cassandra\bin>cassandra.bat > Detected powershell execution permissions. Running with enhanced startup > scripts. > Processing -File 'C:\src' failed because the file does not have a '.ps1' > extension. Specify a valid PowerShell script file name, and then try again. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7378) Protocol: Autoprepare flag for QUERY and BATCH requests
[ https://issues.apache.org/jira/browse/CASSANDRA-7378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14030355#comment-14030355 ] Jorge Bay commented on CASSANDRA-7378: -- My main concern is to lower the complexity from the user perspective, but it is true that it would add a few bytes extra (there are still 16 bytes from the md5) per request, if implemented as I proposed. If implemented as Tyler proposes, it will save bandwidth and roundtrips but it will still require some "state management" by the driver. About preparing statements at app startup, it is a possibility but again it adds complexity to the user, forcing the user to store the prepared statement result (id) at a global scope... > Protocol: Autoprepare flag for QUERY and BATCH requests > --- > > Key: CASSANDRA-7378 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7378 > Project: Cassandra > Issue Type: Improvement > Components: API >Reporter: Jorge Bay >Priority: Minor > > Currently the flow for executing a prepared statement in the native protocol > is: > - PREPARE request > - prepared response (queryid) > - EXECUTE request (using queryid) > - RESULT response > - or UNPREPARED error response > As is today, it is the responsibility of the driver or client to maintain the > query id and to send a EXECUTE message using this query id and to expect for > UNPREPARED error response in case the query got evicted or the node was > restarted. > With the following implications: > - Before making a EXECUTE request, there is no way to know if it got evicted. > - Before sending a PREPARE request, there is no way to know if that query has > been already prepared on that host (by another connection), . > - There isn't anything else the client can do with the prepared id (no much > use from the client perspective). > It would be nice to have a flag in the QUERY and BATCH requests that when > set, the Cassandra node will prepare (if not already prepared) and execute > the prepared query. This way we could save a few extra roundtrips and make > the protocol flow for prepared statements a little more simple. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7378) Protocol: Autoprepare flag for QUERY and BATCH requests
[ https://issues.apache.org/jira/browse/CASSANDRA-7378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Bay updated CASSANDRA-7378: - Component/s: API > Protocol: Autoprepare flag for QUERY and BATCH requests > --- > > Key: CASSANDRA-7378 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7378 > Project: Cassandra > Issue Type: Improvement > Components: API >Reporter: Jorge Bay >Priority: Minor > > Currently the flow for executing a prepared statement in the native protocol > is: > - PREPARE request > - prepared response (queryid) > - EXECUTE request (using queryid) > - RESULT response > - or UNPREPARED error response > As is today, it is the responsibility of the driver or client to maintain the > query id and to send a EXECUTE message using this query id and to expect for > UNPREPARED error response in case the query got evicted or the node was > restarted. > With the following implications: > - Before making a EXECUTE request, there is no way to know if it got evicted. > - Before sending a PREPARE request, there is no way to know if that query has > been already prepared on that host (by another connection), . > - There isn't anything else the client can do with the prepared id (no much > use from the client perspective). > It would be nice to have a flag in the QUERY and BATCH requests that when > set, the Cassandra node will prepare (if not already prepared) and execute > the prepared query. This way we could save a few extra roundtrips and make > the protocol flow for prepared statements a little more simple. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CASSANDRA-7378) Protocol: Autoprepare flag for QUERY and BATCH requests
Jorge Bay created CASSANDRA-7378: Summary: Protocol: Autoprepare flag for QUERY and BATCH requests Key: CASSANDRA-7378 URL: https://issues.apache.org/jira/browse/CASSANDRA-7378 Project: Cassandra Issue Type: Improvement Reporter: Jorge Bay Priority: Minor Currently the flow for executing a prepared statement in the native protocol is: - PREPARE request - prepared response (queryid) - EXECUTE request (using queryid) - RESULT response - or UNPREPARED error response As is today, it is the responsibility of the driver or client to maintain the query id and to send a EXECUTE message using this query id and to expect for UNPREPARED error response in case the query got evicted or the node was restarted. With the following implications: - Before making a EXECUTE request, there is no way to know if it got evicted. - Before sending a PREPARE request, there is no way to know if that query has been already prepared on that host (by another connection), . - There isn't anything else the client can do with the prepared id (no much use from the client perspective). It would be nice to have a flag in the QUERY and BATCH requests that when set, the Cassandra node will prepare (if not already prepared) and execute the prepared query. This way we could save a few extra roundtrips and make the protocol flow for prepared statements a little more simple. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CASSANDRA-6644) CQL: Select every nth row within the same partition key
[ https://issues.apache.org/jira/browse/CASSANDRA-6644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13887669#comment-13887669 ] Jorge Bay edited comment on CASSANDRA-6644 at 1/31/14 12:32 PM: I don't think it matches the requirements of aggregation and filtering of [#CASSANDRA-4914] ... What I'm proposing is a way to instruct the server how to "move the cursor" when reading a wide row. When you store data at high rate for measurement / metrics, it is useful to retrieve information at "lower rate" for analysis, but anyway people can vote on it :) was (Author: jorgebg): I don't think it matches the requirements of aggregation and filtering of https://issues.apache.org/jira/browse/CASSANDRA-4914 ... What I'm proposing is a way to instruct the server how to "move the cursor" when reading a wide row. When you store data at high rate for measurement / metrics, it is useful to retrieve information at "lower rate" for analysis, but anyway people can vote on it :) > CQL: Select every nth row within the same partition key > --- > > Key: CASSANDRA-6644 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6644 > Project: Cassandra > Issue Type: Wish >Reporter: Jorge Bay > > In a time-series schema (like metrics), it is common to create > roollups/buckets with datapoints at different rate. > It would be nice to have a keyword in CQL to be able to retrieve one every > nth row (within a single storage engine wide row). > For example, in the following schema: > CREATE TABLE metrics ( > ...metric_id varchar, > ...ts timestamp, > ...value float, > ...PRIMARY KEY (metric_id, ts) > ... ); > The following query, will retrieve 1 in every 3 rows: > (SKIP keyword or something like that, but don't focus on the syntax) > SELECT ts, value WHERE metric_id = ? SKIP 2; > This would be very useful for continuous (and somehow linear) metrics. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6644) CQL: Select every nth row within the same partition key
[ https://issues.apache.org/jira/browse/CASSANDRA-6644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13887697#comment-13887697 ] Jorge Bay commented on CASSANDRA-6644: -- You are right, it looks like the only way would be to filter out rows in the coordinator. > CQL: Select every nth row within the same partition key > --- > > Key: CASSANDRA-6644 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6644 > Project: Cassandra > Issue Type: Wish >Reporter: Jorge Bay > > In a time-series schema (like metrics), it is common to create > roollups/buckets with datapoints at different rate. > It would be nice to have a keyword in CQL to be able to retrieve one every > nth row (within a single storage engine wide row). > For example, in the following schema: > CREATE TABLE metrics ( > ...metric_id varchar, > ...ts timestamp, > ...value float, > ...PRIMARY KEY (metric_id, ts) > ... ); > The following query, will retrieve 1 in every 3 rows: > (SKIP keyword or something like that, but don't focus on the syntax) > SELECT ts, value WHERE metric_id = ? SKIP 2; > This would be very useful for continuous (and somehow linear) metrics. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6644) CQL: Select every nth row within the same partition key
[ https://issues.apache.org/jira/browse/CASSANDRA-6644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Bay updated CASSANDRA-6644: - Description: In a time-series schema (like metrics), it is common to create roollups/buckets with datapoints at different rate. It would be nice to have a keyword in CQL to be able to retrieve one every nth row (within a single storage engine wide row). For example, in the following schema: CREATE TABLE metrics ( ...metric_id varchar, ...ts timestamp, ...value float, ...PRIMARY KEY (metric_id, ts) ... ); The following query, will retrieve 1 in every 3 rows: (SKIP keyword or something like that, but don't focus on the syntax) SELECT ts, value WHERE metric_id = ? SKIP 2; This would be very useful for continuous (and somehow linear) metrics. was: In a time-series schema (like metrics), it is common to create roollups/buckets with datapoints at different rate. It would be nice to have a keyword in CQL to be able to retrieve one every nth row (within a single storage engine wide row). For example, in the following schema: CREATE TABLE metrics ( ...metric_id varchar, ...ts timestamp, ...value float, ...PRIMARY KEY (metric_id, ts) ... ); The following query, will retrieve 1 in every 3 rows: - - SKIP keyword or something like that SELECT ts, value WHERE metric_id = ? SKIP 2; This would be very useful for continuous (and somehow linear) metrics. > CQL: Select every nth row within the same partition key > --- > > Key: CASSANDRA-6644 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6644 > Project: Cassandra > Issue Type: Wish >Reporter: Jorge Bay > > In a time-series schema (like metrics), it is common to create > roollups/buckets with datapoints at different rate. > It would be nice to have a keyword in CQL to be able to retrieve one every > nth row (within a single storage engine wide row). > For example, in the following schema: > CREATE TABLE metrics ( > ...metric_id varchar, > ...ts timestamp, > ...value float, > ...PRIMARY KEY (metric_id, ts) > ... ); > The following query, will retrieve 1 in every 3 rows: > (SKIP keyword or something like that, but don't focus on the syntax) > SELECT ts, value WHERE metric_id = ? SKIP 2; > This would be very useful for continuous (and somehow linear) metrics. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6644) CQL: Select every nth row within the same partition key
[ https://issues.apache.org/jira/browse/CASSANDRA-6644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Bay updated CASSANDRA-6644: - Description: In a time-series schema (like metrics), it is common to create roollups/buckets with datapoints at different rate. It would be nice to have a keyword in CQL to be able to retrieve one every nth row (within a single storage engine wide row). For example, in the following schema: CREATE TABLE metrics ( ...metric_id varchar, ...ts timestamp, ...value float, ...PRIMARY KEY (metric_id, ts) ... ); The following query, will retrieve 1 in every 3 rows: - - SKIP keyword or something like that SELECT ts, value WHERE metric_id = ? SKIP 2; This would be very useful for continuous (and somehow linear) metrics. was: In a time-series schema (like metrics), it is common to create roollups/buckets with datapoints at different rate. It would be nice to have a keyword in CQL to be able to retrieve one every nth row (within a single storage engine wide row). For example, in the following schema: CREATE TABLE metrics ( ...metric_id varchar, ...ts timestamp, ...value float, ...PRIMARY KEY (metric_id, ts) ... ); The following query, will retrieve 1 in every 3 rows: -- SKIP keyword or something like that SELECT ts, value WHERE metric_id = ? SKIP 2; This would be very useful for continuous (and somehow linear) metrics. > CQL: Select every nth row within the same partition key > --- > > Key: CASSANDRA-6644 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6644 > Project: Cassandra > Issue Type: Wish >Reporter: Jorge Bay > > In a time-series schema (like metrics), it is common to create > roollups/buckets with datapoints at different rate. > It would be nice to have a keyword in CQL to be able to retrieve one every > nth row (within a single storage engine wide row). > For example, in the following schema: > CREATE TABLE metrics ( > ...metric_id varchar, > ...ts timestamp, > ...value float, > ...PRIMARY KEY (metric_id, ts) > ... ); > The following query, will retrieve 1 in every 3 rows: > - - SKIP keyword or something like that > SELECT ts, value WHERE metric_id = ? SKIP 2; > This would be very useful for continuous (and somehow linear) metrics. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6644) CQL: Select every nth row within the same partition key
[ https://issues.apache.org/jira/browse/CASSANDRA-6644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13887669#comment-13887669 ] Jorge Bay commented on CASSANDRA-6644: -- I don't think it matches the requirements of aggregation and filtering of https://issues.apache.org/jira/browse/CASSANDRA-4914 ... What I'm proposing is a way to instruct the server how to "move the cursor" when reading a wide row. When you store data at high rate for measurement / metrics, it is useful to retrieve information at "lower rate" for analysis, but anyway people can vote on it :) > CQL: Select every nth row within the same partition key > --- > > Key: CASSANDRA-6644 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6644 > Project: Cassandra > Issue Type: Wish >Reporter: Jorge Bay > > In a time-series schema (like metrics), it is common to create > roollups/buckets with datapoints at different rate. > It would be nice to have a keyword in CQL to be able to retrieve one every > nth row (within a single storage engine wide row). > For example, in the following schema: > CREATE TABLE metrics ( > ...metric_id varchar, > ...ts timestamp, > ...value float, > ...PRIMARY KEY (metric_id, ts) > ... ); > The following query, will retrieve 1 in every 3 rows: > -- SKIP keyword or something like that > SELECT ts, value WHERE metric_id = ? SKIP 2; > This would be very useful for continuous (and somehow linear) metrics. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CASSANDRA-6644) CQL: Select every nth row within the same partition key
Jorge Bay created CASSANDRA-6644: Summary: CQL: Select every nth row within the same partition key Key: CASSANDRA-6644 URL: https://issues.apache.org/jira/browse/CASSANDRA-6644 Project: Cassandra Issue Type: Wish Reporter: Jorge Bay In a time-series schema (like metrics), it is common to create roollups/buckets with datapoints at different rate. It would be nice to have a keyword in CQL to be able to retrieve one every nth row (within a single storage engine wide row). For example, in the following schema: CREATE TABLE metrics ( ...metric_id varchar, ...ts timestamp, ...value float, ...PRIMARY KEY (metric_id, ts) ... ); The following query, will retrieve 1 in every 3 rows: -- SKIP keyword or something like that SELECT ts, value WHERE metric_id = ? SKIP 2; This would be very useful for continuous (and somehow linear) metrics. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
