[
https://issues.apache.org/jira/browse/CASSANDRA-15072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810407#comment-16810407
]
Blake Eggleston edited comment on CASSANDRA-15072 at 4/5/19 4:48 PM:
---------------------------------------------------------------------
|[3.0|https://github.com/bdeggleston/cassandra/tree/15072-3.0]|[tests|https://circleci.com/gh/bdeggleston/workflows/cassandra/tree/15072-3.0]|
|[3.11|https://github.com/bdeggleston/cassandra/tree/15072-3.11]|[tests|https://circleci.com/workflow-run/4567dbed-be97-49e5-8c82-66e320e074ca]|
[~beobal] do you have time to review this? It seems to be related to
CASSANDRA-11087.
A few notes:
* From what I can tell, returning a row per cell is the right thing to do in
this case, so I'm using a modified result counter to only going entire
partitions in this specific case. However, I'm not familiar enough with all the
dark corners of the 2.1 storage engine to be sure that's appropriate, or won't
break something else.
* Doing a point read with the partition key also returns a row per cell, but
works correctly because the 2.2 coordinator seems to just discard the limit in
that case.
* If you're not familiar with the in-jvm dtests yet, and want to run the one
in this patch, you'll want to run {{ant dtest-jar}} on this branch and [this
2.2 branch|https://github.com/bdeggleston/cassandra/tree/15078-2.2], and put
the 2.2 dtest jar in the 3.0 build directory.
* -CircleCI seems to be behind picking up new branches to test, but I'll
update this with links to the workflows once it catches up.-
was (Author: bdeggleston):
|[3.0|https://github.com/bdeggleston/cassandra/tree/15072-3.0]|[tests|https://circleci.com/gh/bdeggleston/workflows/cassandra/tree/15072-3.0]|
|[3.11|https://github.com/bdeggleston/cassandra/tree/15072-3.11]|[tests|https://circleci.com/workflow-run/4567dbed-be97-49e5-8c82-66e320e074ca]|
[~beobal] do you have time to review this? It seems to be related to
CASSANDRA-11087.
A few notes:
* From what I can tell, returning a row per cell is the right thing to do in
this case, so I'm using a modified result counter to only going entire
partitions in this specific case. However, I'm not familiar enough with all the
dark corners of the 2.1 storage engine to be sure that's appropriate, or won't
break something else.
* Doing a point read with the partition key also returns a row per cell, but
works correctly because the 2.2 coordinator seems to just discard the limit in
that case.
* If you're not familiar with the in-jvm dtests yet, and want to run the one
in this patch, you'll want to run {{ant dtest-jar}} on this branch and [this
2.2 branch|https://github.com/bdeggleston/cassandra/tree/15078-2.2], and put
the 2.2 dtest jar in the 3.0 build directory.
* CircleCI seems to be behind picking up new branches to test, but I'll update
this with links to the workflows once it catches up.
> Incomplete range results during 2.X -> 3.11.4 upgrade
> -----------------------------------------------------
>
> Key: CASSANDRA-15072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15072
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Coordination
> Reporter: Muir Manders
> Assignee: Blake Eggleston
> Priority: High
> Attachments: eriksw-repro.sh
>
>
> Hello
> During an upgrade from 2.1.17 to 3.11.4, our application starting getting
> back incomplete results for range queries. When all nodes were upgraded
> (before upgrading sstables), we stopped getting incomplete results. I was
> able to reproduce it and listed steps below. It seems to require the random
> partitioner and compact storage to reproduce reliably. It also reproduces
> coming from 2.1.21 and 2.2.14. You seem to get the bad behavior when an old
> node is your coordinator and it has to talk to an upgraded replica.
> {noformat}
> ccm create test -v 2.1.17 -n 3
> ccm updateconf 'partitioner: org.apache.cassandra.dht.RandomPartitioner'
> ccm node1 updateconf 'initial_token: 0'
> ccm node2 updateconf 'initial_token: 56713727820156410577229101238628035242'
> ccm node3 updateconf 'initial_token: 113427455640312821154458202477256070484'
> ccm start
> ccm node1 cqlsh <<SCHEMA
> CREATE KEYSPACE test WITH REPLICATION = {'class': 'SimpleStrategy',
> 'replication_factor': 3};
> CREATE COLUMNFAMILY test.test (
> id text,
> foo text,
> bar text,
> PRIMARY KEY (id)
> ) WITH COMPACT STORAGE;
> CONSISTENCY QUORUM;
> INSERT INTO test.test (id, foo, bar) values ('1', 'hi', 'there');
> INSERT INTO test.test (id, foo, bar) values ('2', 'hi', 'there');
> SCHEMA
> ccm node1 stop
> ccm node1 setdir -v 3.11.4
> ccm node1 start
> ccm node2 stop
> ccm node2 setdir -v 3.11.4
> ccm node2 start
> # here I use 3.X cqlsh to connect to 2.X node so I can lower the page size (to
> # allow for simpler test setup)
> cqlsh 127.0.0.3 <<QUERY
> CONSISTENCY QUORUM;
> PAGING 2;
> select * from test.test;
> QUERY
> {noformat}
> This results in:
> {noformat}
> Page size: 2
> id | bar | foo
> ----+-------+-----
> 2 | there | hi
> (1 rows)
> {noformat}
> Running it against the upgraded node (node1):
> {noformat}
> Page size: 2
> id | bar | foo
> ----+-------+-----
> 2 | there | hi
> 1 | there | hi
> (2 rows)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
