[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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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
[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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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)
[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-tabpanel&focusedCommentId=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)
