[jira] [Commented] (CASSANDRA-7695) Inserting the same row in parallel causes bad data to be returned to the client
[ https://issues.apache.org/jira/browse/CASSANDRA-7695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14095316#comment-14095316 ] Norman Maurer commented on CASSANDRA-7695: -- Hey guys I finally found the root cause of the problem and fixed it in Netty. That said I think it is also possible to see the same problem when using non-unsafe ByteBufs (if you are lucky enough). This problem was easier to reproduce on OSX as for this to happen you need to produce some series of incomplete / complete writes to trigger that, and this is easier on OSX stock network configuration. The issue and fix can be found here: https://github.com/netty/netty/issues/2761 Inserting the same row in parallel causes bad data to be returned to the client --- Key: CASSANDRA-7695 URL: https://issues.apache.org/jira/browse/CASSANDRA-7695 Project: Cassandra Issue Type: Bug Environment: Linux 3.12.21, JVM 1.7u60 Cassandra server 2.1.0 RC 5 Cassandra datastax client version 2.1.0RC1 Reporter: Johan Bjork Assignee: T Jake Luciani Priority: Blocker Labels: qa-resolved Fix For: 2.1.0 Attachments: 7695-workaround.txt, PutFailureRepro.java, bad-data-tid43-get, bad-data-tid43-put Running the attached test program against a cassandra 2.1 server results in scrambled data returned by the SELECT statement. Running it against latest stable works fine. Attached: * Program that reproduces the failure * Example output files from mentioned test-program with the scrambled output. Failure mode: The value returned by 'get' is scrambled, the size is correct but some bytes have shifted locations in the returned buffer. Cluster info: For the test we set up a single cassandra node using the stock configuration file. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7695) Inserting the same row in parallel causes bad data to be returned to the client
[ https://issues.apache.org/jira/browse/CASSANDRA-7695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14095526#comment-14095526 ] Norman Maurer commented on CASSANDRA-7695: -- [~tjake] yay :) Inserting the same row in parallel causes bad data to be returned to the client --- Key: CASSANDRA-7695 URL: https://issues.apache.org/jira/browse/CASSANDRA-7695 Project: Cassandra Issue Type: Bug Environment: Linux 3.12.21, JVM 1.7u60 Cassandra server 2.1.0 RC 5 Cassandra datastax client version 2.1.0RC1 Reporter: Johan Bjork Assignee: T Jake Luciani Priority: Blocker Labels: qa-resolved Fix For: 2.1.0 Attachments: 0001-CASSANDRA-7695-Workaround-Netty-bug-by-not-use-Compo.patch, 7695-workaround.txt, PutFailureRepro.java, bad-data-tid43-get, bad-data-tid43-put Running the attached test program against a cassandra 2.1 server results in scrambled data returned by the SELECT statement. Running it against latest stable works fine. Attached: * Program that reproduces the failure * Example output files from mentioned test-program with the scrambled output. Failure mode: The value returned by 'get' is scrambled, the size is correct but some bytes have shifted locations in the returned buffer. Cluster info: For the test we set up a single cassandra node using the stock configuration file. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7695) Inserting the same row in parallel causes bad data to be returned to the client
[ https://issues.apache.org/jira/browse/CASSANDRA-7695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14095525#comment-14095525 ] T Jake Luciani commented on CASSANDRA-7695: --- The patch seems to address the issue. Inserting the same row in parallel causes bad data to be returned to the client --- Key: CASSANDRA-7695 URL: https://issues.apache.org/jira/browse/CASSANDRA-7695 Project: Cassandra Issue Type: Bug Environment: Linux 3.12.21, JVM 1.7u60 Cassandra server 2.1.0 RC 5 Cassandra datastax client version 2.1.0RC1 Reporter: Johan Bjork Assignee: T Jake Luciani Priority: Blocker Labels: qa-resolved Fix For: 2.1.0 Attachments: 0001-CASSANDRA-7695-Workaround-Netty-bug-by-not-use-Compo.patch, 7695-workaround.txt, PutFailureRepro.java, bad-data-tid43-get, bad-data-tid43-put Running the attached test program against a cassandra 2.1 server results in scrambled data returned by the SELECT statement. Running it against latest stable works fine. Attached: * Program that reproduces the failure * Example output files from mentioned test-program with the scrambled output. Failure mode: The value returned by 'get' is scrambled, the size is correct but some bytes have shifted locations in the returned buffer. Cluster info: For the test we set up a single cassandra node using the stock configuration file. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7695) Inserting the same row in parallel causes bad data to be returned to the client
[
https://issues.apache.org/jira/browse/CASSANDRA-7695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14093338#comment-14093338
]
Trustin Lee commented on CASSANDRA-7695:
I tried to reproduce the problem by myself with the following prodecure, but I
was unsuccessful so far:
{code}
# cd ~
# git clone https://github.com/apache/cassandra.git
# cd cassandra
# git checkout -t origin/cassandra-2.1
# git reset --hard 756c85e86fc9e2de492c23c3e6c10e4b4511293a
# ant clean artifacts
# cd ~
# tar xvfz cassandra/build/apache-cassandra-2.1.0-rc5-SNAPSHOT-bin.tar.gz
# cd apache-cassandra-2.1.0-rc5-SNAPSHOT
# bin/cassandra -f
{code}
In other terminal:
{code}
# cd ~
# git clone https://github.com/iamaleksey/castorture.git
# git checkout -t origin/7695
# bin/build
# bin/torture
{code}
How long does it usually take to see the failure? (I waited for more than 15
minutes)
Inserting the same row in parallel causes bad data to be returned to the
client
---
Key: CASSANDRA-7695
URL: https://issues.apache.org/jira/browse/CASSANDRA-7695
Project: Cassandra
Issue Type: Bug
Environment: Linux 3.12.21, JVM 1.7u60
Cassandra server 2.1.0 RC 5
Cassandra datastax client version 2.1.0RC1
Reporter: Johan Bjork
Assignee: T Jake Luciani
Priority: Blocker
Labels: qa-resolved
Fix For: 2.1.0
Attachments: 7695-workaround.txt, PutFailureRepro.java,
bad-data-tid43-get, bad-data-tid43-put
Running the attached test program against a cassandra 2.1 server results in
scrambled data returned by the SELECT statement. Running it against latest
stable works fine.
Attached:
* Program that reproduces the failure
* Example output files from mentioned test-program with the scrambled output.
Failure mode:
The value returned by 'get' is scrambled, the size is correct but some bytes
have shifted locations in the returned buffer.
Cluster info:
For the test we set up a single cassandra node using the stock configuration
file.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7695) Inserting the same row in parallel causes bad data to be returned to the client
[
https://issues.apache.org/jira/browse/CASSANDRA-7695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14093373#comment-14093373
]
Trustin Lee commented on CASSANDRA-7695:
I also tried:
{code}
# bin/torture -rnative -wthrift
{code}
and got this:
{code}
INFO 14:46:00,573 Reactivating 127.0.0.1
Exception in thread pool-13-thread-13 Exception in thread pool-13-thread-34
Exception in thread pool-13-thread-29 Exception in thread pool-13-thread-2
Exception in thread pool-13-thread-40 Exception in thread pool-13-thread-24
Exception in thread pool-13-thread-3 Exception in thread pool-13-thread-32
Exception in thread pool-13-thread-4 Exception in thread pool-13-thread-26
Exception in thread pool-13-thread-6 Exception in thread pool-13-thread-36
Exception in thread pool-13-thread-12 Exception in thread pool-13-thread-35
Exception in thread pool-13-thread-15 Exception in thread pool-13-thread-21
Exception in thread pool-13-thread-37 Exception in thread pool-13-thread-19
Exception in thread pool-13-thread-7 Exception in thread pool-13-thread-17
Exception in thread pool-13-thread-8 Exception in thread pool-13-thread-27
Exception in thread pool-13-thread-14 Exception in thread pool-13-thread-22
Exception in thread pool-13-thread-9 Exception in thread pool-13-thread-38
Exception in thread pool-13-thread-39 java.lang.OutOfMemoryError: Java heap
space
at java.util.Arrays.copyOf(Arrays.java:2271)
at java.io.ByteArrayOutputStream.grow(ByteArrayOutputStream.java:113)
at
java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:93)
at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:140)
at
org.apache.thrift.transport.TFramedTransport.write(TFramedTransport.java:146)
at
org.apache.thrift.protocol.TBinaryProtocol.writeBinary(TBinaryProtocol.java:196)
at
org.apache.cassandra.thrift.Cassandra$execute_prepared_cql3_query_args.write(Cassandra.java:41253)
at org.apache.thrift.TServiceClient.sendBase(TServiceClient.java:63)
at
org.apache.cassandra.thrift.Cassandra$Client.send_execute_prepared_cql3_query(Cassandra.java:1683)
at
org.apache.cassandra.thrift.Cassandra$Client.execute_prepared_cql3_query(Cassandra.java:1673)
at
com.netflix.astyanax.thrift.ThriftCql3Query.execute_prepared_cql_query(ThriftCql3Query.java:29)
at
com.netflix.astyanax.thrift.AbstractThriftCqlQuery$3$1.internalExecute(AbstractThriftCqlQuery.java:93)
at
com.netflix.astyanax.thrift.AbstractThriftCqlQuery$3$1.internalExecute(AbstractThriftCqlQuery.java:83)
at
com.netflix.astyanax.thrift.AbstractOperationImpl.execute(AbstractOperationImpl.java:60)
at
com.netflix.astyanax.thrift.AbstractOperationImpl.execute(AbstractOperationImpl.java:28)
at
com.netflix.astyanax.thrift.ThriftSyncConnectionFactoryImpl$ThriftConnection.execute(ThriftSyncConnectionFactoryImpl.java:151)
at
com.netflix.astyanax.connectionpool.impl.AbstractExecuteWithFailoverImpl.tryOperation(AbstractExecuteWithFailoverImpl.java:119)
at
com.netflix.astyanax.connectionpool.impl.AbstractHostPartitionConnectionPool.executeWithFailover(AbstractHostPartitionConnectionPool.java:338)
at
com.netflix.astyanax.thrift.AbstractThriftCqlQuery$3.execute(AbstractThriftCqlQuery.java:81)
at
org.apache.cassandra.castorture.Torturer$2.thriftInsert(Torturer.java:146)
at org.apache.cassandra.castorture.Torturer$2.insert(Torturer.java:127)
at org.apache.cassandra.castorture.Torturer$2.run(Torturer.java:106)
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}
It seems to me that it's not a failure due to data corruption though.
Inserting the same row in parallel causes bad data to be returned to the
client
---
Key: CASSANDRA-7695
URL: https://issues.apache.org/jira/browse/CASSANDRA-7695
Project: Cassandra
Issue Type: Bug
Environment: Linux 3.12.21, JVM 1.7u60
Cassandra server 2.1.0 RC 5
Cassandra datastax client version 2.1.0RC1
Reporter: Johan Bjork
Assignee: T Jake Luciani
Priority: Blocker
Labels: qa-resolved
Fix For: 2.1.0
Attachments: 7695-workaround.txt, PutFailureRepro.java,
bad-data-tid43-get, bad-data-tid43-put
Running the attached test program against a cassandra 2.1 server results in
scrambled data returned by the SELECT statement. Running it against latest
stable works fine.
Attached:
* Program that reproduces the failure
* Example output files from mentioned test-program with
[jira] [Commented] (CASSANDRA-7695) Inserting the same row in parallel causes bad data to be returned to the client
[ https://issues.apache.org/jira/browse/CASSANDRA-7695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14093386#comment-14093386 ] Jonathan Ellis commented on CASSANDRA-7695: --- /cc [~norman] Inserting the same row in parallel causes bad data to be returned to the client --- Key: CASSANDRA-7695 URL: https://issues.apache.org/jira/browse/CASSANDRA-7695 Project: Cassandra Issue Type: Bug Environment: Linux 3.12.21, JVM 1.7u60 Cassandra server 2.1.0 RC 5 Cassandra datastax client version 2.1.0RC1 Reporter: Johan Bjork Assignee: T Jake Luciani Priority: Blocker Labels: qa-resolved Fix For: 2.1.0 Attachments: 7695-workaround.txt, PutFailureRepro.java, bad-data-tid43-get, bad-data-tid43-put Running the attached test program against a cassandra 2.1 server results in scrambled data returned by the SELECT statement. Running it against latest stable works fine. Attached: * Program that reproduces the failure * Example output files from mentioned test-program with the scrambled output. Failure mode: The value returned by 'get' is scrambled, the size is correct but some bytes have shifted locations in the returned buffer. Cluster info: For the test we set up a single cassandra node using the stock configuration file. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7695) Inserting the same row in parallel causes bad data to be returned to the client
[ https://issues.apache.org/jira/browse/CASSANDRA-7695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14093390#comment-14093390 ] Aleksey Yeschenko commented on CASSANDRA-7695: -- [~trustin] We know the issue is there, and Netty guys are already working on it. No need to repro. Your stacktrace is just OOM though. Inserting the same row in parallel causes bad data to be returned to the client --- Key: CASSANDRA-7695 URL: https://issues.apache.org/jira/browse/CASSANDRA-7695 Project: Cassandra Issue Type: Bug Environment: Linux 3.12.21, JVM 1.7u60 Cassandra server 2.1.0 RC 5 Cassandra datastax client version 2.1.0RC1 Reporter: Johan Bjork Assignee: T Jake Luciani Priority: Blocker Labels: qa-resolved Fix For: 2.1.0 Attachments: 7695-workaround.txt, PutFailureRepro.java, bad-data-tid43-get, bad-data-tid43-put Running the attached test program against a cassandra 2.1 server results in scrambled data returned by the SELECT statement. Running it against latest stable works fine. Attached: * Program that reproduces the failure * Example output files from mentioned test-program with the scrambled output. Failure mode: The value returned by 'get' is scrambled, the size is correct but some bytes have shifted locations in the returned buffer. Cluster info: For the test we set up a single cassandra node using the stock configuration file. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7695) Inserting the same row in parallel causes bad data to be returned to the client
[ https://issues.apache.org/jira/browse/CASSANDRA-7695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14093401#comment-14093401 ] Trustin Lee commented on CASSANDRA-7695: I am the Netty guy. :-) Inserting the same row in parallel causes bad data to be returned to the client --- Key: CASSANDRA-7695 URL: https://issues.apache.org/jira/browse/CASSANDRA-7695 Project: Cassandra Issue Type: Bug Environment: Linux 3.12.21, JVM 1.7u60 Cassandra server 2.1.0 RC 5 Cassandra datastax client version 2.1.0RC1 Reporter: Johan Bjork Assignee: T Jake Luciani Priority: Blocker Labels: qa-resolved Fix For: 2.1.0 Attachments: 7695-workaround.txt, PutFailureRepro.java, bad-data-tid43-get, bad-data-tid43-put Running the attached test program against a cassandra 2.1 server results in scrambled data returned by the SELECT statement. Running it against latest stable works fine. Attached: * Program that reproduces the failure * Example output files from mentioned test-program with the scrambled output. Failure mode: The value returned by 'get' is scrambled, the size is correct but some bytes have shifted locations in the returned buffer. Cluster info: For the test we set up a single cassandra node using the stock configuration file. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7695) Inserting the same row in parallel causes bad data to be returned to the client
[ https://issues.apache.org/jira/browse/CASSANDRA-7695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14093407#comment-14093407 ] Aleksey Yeschenko commented on CASSANDRA-7695: -- bq. I am the Netty guy. Lol. Yes, I know now. Norman's looking into it. FWIW the issue is hard to repro on non-OSX, so it might be that. Inserting the same row in parallel causes bad data to be returned to the client --- Key: CASSANDRA-7695 URL: https://issues.apache.org/jira/browse/CASSANDRA-7695 Project: Cassandra Issue Type: Bug Environment: Linux 3.12.21, JVM 1.7u60 Cassandra server 2.1.0 RC 5 Cassandra datastax client version 2.1.0RC1 Reporter: Johan Bjork Assignee: T Jake Luciani Priority: Blocker Labels: qa-resolved Fix For: 2.1.0 Attachments: 7695-workaround.txt, PutFailureRepro.java, bad-data-tid43-get, bad-data-tid43-put Running the attached test program against a cassandra 2.1 server results in scrambled data returned by the SELECT statement. Running it against latest stable works fine. Attached: * Program that reproduces the failure * Example output files from mentioned test-program with the scrambled output. Failure mode: The value returned by 'get' is scrambled, the size is correct but some bytes have shifted locations in the returned buffer. Cluster info: For the test we set up a single cassandra node using the stock configuration file. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7695) Inserting the same row in parallel causes bad data to be returned to the client
[ https://issues.apache.org/jira/browse/CASSANDRA-7695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14093421#comment-14093421 ] Trustin Lee commented on CASSANDRA-7695: He actually asked me to look into last night. Anyways, I'm on Linux 3.14.16, and that's why I cannot reproduce it. Let me try it again later on OS X. Inserting the same row in parallel causes bad data to be returned to the client --- Key: CASSANDRA-7695 URL: https://issues.apache.org/jira/browse/CASSANDRA-7695 Project: Cassandra Issue Type: Bug Environment: Linux 3.12.21, JVM 1.7u60 Cassandra server 2.1.0 RC 5 Cassandra datastax client version 2.1.0RC1 Reporter: Johan Bjork Assignee: T Jake Luciani Priority: Blocker Labels: qa-resolved Fix For: 2.1.0 Attachments: 7695-workaround.txt, PutFailureRepro.java, bad-data-tid43-get, bad-data-tid43-put Running the attached test program against a cassandra 2.1 server results in scrambled data returned by the SELECT statement. Running it against latest stable works fine. Attached: * Program that reproduces the failure * Example output files from mentioned test-program with the scrambled output. Failure mode: The value returned by 'get' is scrambled, the size is correct but some bytes have shifted locations in the returned buffer. Cluster info: For the test we set up a single cassandra node using the stock configuration file. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7695) Inserting the same row in parallel causes bad data to be returned to the client
[ https://issues.apache.org/jira/browse/CASSANDRA-7695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14089282#comment-14089282 ] Benedict commented on CASSANDRA-7695: - LGTM. Would prefer we call the test NativeTransportBufferRecycleTest, and comment it to explain. Also remove the LOCAL_QUORUM, since it's meaningless here and don't want to confuse future readers. It's also not clear why we're bothering to 'dump keys', but this is a test so I'm not going to vet it too hard. Inserting the same row in parallel causes bad data to be returned to the client --- Key: CASSANDRA-7695 URL: https://issues.apache.org/jira/browse/CASSANDRA-7695 Project: Cassandra Issue Type: Bug Environment: Linux 3.12.21, JVM 1.7u60 Cassandra server 2.1.0 RC 5 Cassandra datastax client version 2.1.0RC1 Reporter: Johan Bjork Assignee: T Jake Luciani Priority: Blocker Fix For: 2.1.0 Attachments: 7695-workaround.txt, PutFailureRepro.java, bad-data-tid43-get, bad-data-tid43-put Running the attached test program against a cassandra 2.1 server results in scrambled data returned by the SELECT statement. Running it against latest stable works fine. Attached: * Program that reproduces the failure * Example output files from mentioned test-program with the scrambled output. Failure mode: The value returned by 'get' is scrambled, the size is correct but some bytes have shifted locations in the returned buffer. Cluster info: For the test we set up a single cassandra node using the stock configuration file. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7695) Inserting the same row in parallel causes bad data to be returned to the client
[ https://issues.apache.org/jira/browse/CASSANDRA-7695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14089607#comment-14089607 ] T Jake Luciani commented on CASSANDRA-7695: --- Committed with nits (forgot to change the test name). I ran stress locally and noticed no difference in performance. Inserting the same row in parallel causes bad data to be returned to the client --- Key: CASSANDRA-7695 URL: https://issues.apache.org/jira/browse/CASSANDRA-7695 Project: Cassandra Issue Type: Bug Environment: Linux 3.12.21, JVM 1.7u60 Cassandra server 2.1.0 RC 5 Cassandra datastax client version 2.1.0RC1 Reporter: Johan Bjork Assignee: T Jake Luciani Priority: Blocker Fix For: 2.1.0 Attachments: 7695-workaround.txt, PutFailureRepro.java, bad-data-tid43-get, bad-data-tid43-put Running the attached test program against a cassandra 2.1 server results in scrambled data returned by the SELECT statement. Running it against latest stable works fine. Attached: * Program that reproduces the failure * Example output files from mentioned test-program with the scrambled output. Failure mode: The value returned by 'get' is scrambled, the size is correct but some bytes have shifted locations in the returned buffer. Cluster info: For the test we set up a single cassandra node using the stock configuration file. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7695) Inserting the same row in parallel causes bad data to be returned to the client
[ https://issues.apache.org/jira/browse/CASSANDRA-7695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14089783#comment-14089783 ] Ryan McGuire commented on CASSANDRA-7695: - [quick performance sanity check|http://riptano.github.io/cassandra_performance/graph_v3/graph.html?stats=stats.7695.json] Inserting the same row in parallel causes bad data to be returned to the client --- Key: CASSANDRA-7695 URL: https://issues.apache.org/jira/browse/CASSANDRA-7695 Project: Cassandra Issue Type: Bug Environment: Linux 3.12.21, JVM 1.7u60 Cassandra server 2.1.0 RC 5 Cassandra datastax client version 2.1.0RC1 Reporter: Johan Bjork Assignee: T Jake Luciani Priority: Blocker Labels: qa-resolved Fix For: 2.1.0 Attachments: 7695-workaround.txt, PutFailureRepro.java, bad-data-tid43-get, bad-data-tid43-put Running the attached test program against a cassandra 2.1 server results in scrambled data returned by the SELECT statement. Running it against latest stable works fine. Attached: * Program that reproduces the failure * Example output files from mentioned test-program with the scrambled output. Failure mode: The value returned by 'get' is scrambled, the size is correct but some bytes have shifted locations in the returned buffer. Cluster info: For the test we set up a single cassandra node using the stock configuration file. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7695) Inserting the same row in parallel causes bad data to be returned to the client
[ https://issues.apache.org/jira/browse/CASSANDRA-7695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14087931#comment-14087931 ] T Jake Luciani commented on CASSANDRA-7695: --- Looks like this is a netty issue fixed in the latest release https://github.com/netty/netty/issues/2580 Upgrading to 4.0.21-Final fixes the issue for me, I'll turn this test into a long unit test so we can have coverage Inserting the same row in parallel causes bad data to be returned to the client --- Key: CASSANDRA-7695 URL: https://issues.apache.org/jira/browse/CASSANDRA-7695 Project: Cassandra Issue Type: Bug Environment: Linux 3.12.21, JVM 1.7u60 Cassandra server 2.1.0 RC 5 Cassandra datastax client version 2.1.0RC1 Reporter: Johan Bjork Assignee: T Jake Luciani Priority: Blocker Fix For: 2.1.0 Attachments: PutFailureRepro.java, bad-data-tid43-get, bad-data-tid43-put Running the attached test program against a cassandra 2.1 server results in scrambled data returned by the SELECT statement. Running it against latest stable works fine. Attached: * Program that reproduces the failure * Example output files from mentioned test-program with the scrambled output. Failure mode: The value returned by 'get' is scrambled, the size is correct but some bytes have shifted locations in the returned buffer. Cluster info: For the test we set up a single cassandra node using the stock configuration file. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7695) Inserting the same row in parallel causes bad data to be returned to the client
[ https://issues.apache.org/jira/browse/CASSANDRA-7695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14087975#comment-14087975 ] T Jake Luciani commented on CASSANDRA-7695: --- I spoke too soon 21 breaks too, the following flag does fix the issue ./bin/cassandra -f -Dio.netty.tryUnsafe=false which is the work around for the netty issue linked above. Inserting the same row in parallel causes bad data to be returned to the client --- Key: CASSANDRA-7695 URL: https://issues.apache.org/jira/browse/CASSANDRA-7695 Project: Cassandra Issue Type: Bug Environment: Linux 3.12.21, JVM 1.7u60 Cassandra server 2.1.0 RC 5 Cassandra datastax client version 2.1.0RC1 Reporter: Johan Bjork Assignee: T Jake Luciani Priority: Blocker Fix For: 2.1.0 Attachments: PutFailureRepro.java, bad-data-tid43-get, bad-data-tid43-put Running the attached test program against a cassandra 2.1 server results in scrambled data returned by the SELECT statement. Running it against latest stable works fine. Attached: * Program that reproduces the failure * Example output files from mentioned test-program with the scrambled output. Failure mode: The value returned by 'get' is scrambled, the size is correct but some bytes have shifted locations in the returned buffer. Cluster info: For the test we set up a single cassandra node using the stock configuration file. -- This message was sent by Atlassian JIRA (v6.2#6252)
