[jira] [Comment Edited] (CASSANDRA-15072) Incomplete range results during 2.X -> 3.11.4 upgrade
[
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 < 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 < CONS
[jira] [Comment Edited] (CASSANDRA-15078) Support cross version messaging in in-jvm upgrade dtests
[
https://issues.apache.org/jira/browse/CASSANDRA-15078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810373#comment-16810373
]
Blake Eggleston edited comment on CASSANDRA-15078 at 4/5/19 4:47 PM:
-
|[2.2|https://github.com/bdeggleston/cassandra/tree/15078-2.2]|[tests|https://circleci.com/gh/bdeggleston/workflows/cassandra/tree/15078-2.2]|
|[3.0|https://github.com/bdeggleston/cassandra/tree/15078-3.0]|[tests|https://circleci.com/gh/bdeggleston/workflows/cassandra/tree/15078-3.0]|
|[3.11|https://github.com/bdeggleston/cassandra/tree/15078-3.11]|[tests|https://circleci.com/gh/bdeggleston/workflows/cassandra/tree/15072-3.11]|
|[trunk|https://github.com/bdeggleston/cassandra/tree/15078-trunk]|[tests|https://circleci.com/gh/bdeggleston/workflows/cassandra/tree/15078-trunk]|
[~ifesdjeen] / [~benedict] would one of you mind taking a look at this? It's
just adding and using hooks for getting/setting messaging versions. It also
fixes a minor issue where the {{setup}} method wasn't getting called. These
changes are in support of a test case for CASSANDRA-15072, feel free to take a
look and give feedback on that as well. -Circle is behind picking up new
branches, but I'll update with the workflow links once they're available.-
was (Author: bdeggleston):
|[2.2|https://github.com/bdeggleston/cassandra/tree/15078-2.2]|[tests|https://circleci.com/gh/bdeggleston/workflows/cassandra/tree/15078-2.2]|
|[3.0|https://github.com/bdeggleston/cassandra/tree/15078-3.0]|[tests|https://circleci.com/gh/bdeggleston/workflows/cassandra/tree/15078-3.0]|
|[3.11|https://github.com/bdeggleston/cassandra/tree/15078-3.11]|[tests|https://circleci.com/gh/bdeggleston/workflows/cassandra/tree/15072-3.11]|
|[trunk|https://github.com/bdeggleston/cassandra/tree/15078-trunk]|[tests|https://circleci.com/gh/bdeggleston/workflows/cassandra/tree/15078-trunk]|
[~ifesdjeen] / [~benedict] would one of you mind taking a look at this? It's
just adding and using hooks for getting/setting messaging versions. It also
fixes a minor issue where the {{setup}} method wasn't getting called. These
changes are in support of a test case for CASSANDRA-15072, feel free to take a
look and give feedback on that as well. Circle is behind picking up new
branches, but I'll update with the workflow links once they're available.
> Support cross version messaging in in-jvm upgrade dtests
>
>
> Key: CASSANDRA-15078
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15078
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Normal
> Fix For: 2.2.15, 3.0.19, 3.11.5, 4.0
>
>
--
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
[jira] [Comment Edited] (CASSANDRA-15078) Support cross version messaging in in-jvm upgrade dtests
[
https://issues.apache.org/jira/browse/CASSANDRA-15078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810373#comment-16810373
]
Blake Eggleston edited comment on CASSANDRA-15078 at 4/5/19 4:47 PM:
-
|[2.2|https://github.com/bdeggleston/cassandra/tree/15078-2.2]|[tests|https://circleci.com/gh/bdeggleston/workflows/cassandra/tree/15078-2.2]|
|[3.0|https://github.com/bdeggleston/cassandra/tree/15078-3.0]|[tests|https://circleci.com/gh/bdeggleston/workflows/cassandra/tree/15078-3.0]|
|[3.11|https://github.com/bdeggleston/cassandra/tree/15078-3.11]|[tests|https://circleci.com/gh/bdeggleston/workflows/cassandra/tree/15072-3.11]|
|[trunk|https://github.com/bdeggleston/cassandra/tree/15078-trunk]|[tests|https://circleci.com/gh/bdeggleston/workflows/cassandra/tree/15078-trunk]|
[~ifesdjeen] / [~benedict] would one of you mind taking a look at this? It's
just adding and using hooks for getting/setting messaging versions. It also
fixes a minor issue where the {{setup}} method wasn't getting called. These
changes are in support of a test case for CASSANDRA-15072, feel free to take a
look and give feedback on that as well. Circle is behind picking up new
branches, but I'll update with the workflow links once they're available.
was (Author: bdeggleston):
|[2.2|https://github.com/bdeggleston/cassandra/tree/15078-2.2]|
|[3.0|https://github.com/bdeggleston/cassandra/tree/15078-3.0]|
|[3.11|https://github.com/bdeggleston/cassandra/tree/15078-3.11]|
|[trunk|https://github.com/bdeggleston/cassandra/tree/15078-trunk]|
[~ifesdjeen] / [~benedict] would one of you mind taking a look at this? It's
just adding and using hooks for getting/setting messaging versions. It also
fixes a minor issue where the {{setup}} method wasn't getting called. These
changes are in support of a test case for CASSANDRA-15072, feel free to take a
look and give feedback on that as well. Circle is behind picking up new
branches, but I'll update with the workflow links once they're available.
> Support cross version messaging in in-jvm upgrade dtests
>
>
> Key: CASSANDRA-15078
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15078
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Normal
> Fix For: 2.2.15, 3.0.19, 3.11.5, 4.0
>
>
--
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
[jira] [Comment Edited] (CASSANDRA-15072) Incomplete range results during 2.X -> 3.11.4 upgrade
[
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:46 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]|
|[3.11|https://github.com/bdeggleston/cassandra/tree/15072-3.11]|
[~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 < 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 < CONSISTENCY QUORUM;
> PAGING 2;
> select * from test.test;
> QUERY
> {noformat}
> This results in:
> {noformat}
> Page size: 2
> id | bar | foo
> +---+--
[jira] [Commented] (CASSANDRA-15072) Incomplete range results during 2.X -> 3.11.4 upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-15072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810931#comment-16810931
]
Sam Tunnicliffe commented on CASSANDRA-15072:
-
This looks safe to me wrt to "the dark corners" as the new counter is only used
in this very specific use case, so if the CI looks good I'm +1 on the patch.
> 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 < 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 < 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
[jira] [Commented] (CASSANDRA-13890) Expose current compaction throughput
[
https://issues.apache.org/jira/browse/CASSANDRA-13890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810920#comment-16810920
]
Dinesh Joshi commented on CASSANDRA-13890:
--
[~benedict] Interesting thought. Could you open a Jira with details on how this
rate limiter would work? Anything that allows us to reduce threads would be
useful.
> Expose current compaction throughput
>
>
> Key: CASSANDRA-13890
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13890
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Tools
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Low
> Labels: lhf
> Fix For: 4.x
>
>
> Getting and setting the current compaction throughput limit is supported, but
> there's no means of knowing if the setting is actually making a difference.
> Let's expose the current throughput being utilized by Cassandra that's in the
> {{compactionRateLimiter}}
--
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
[jira] [Commented] (CASSANDRA-13890) Expose current compaction throughput
[
https://issues.apache.org/jira/browse/CASSANDRA-13890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810707#comment-16810707
]
Benedict commented on CASSANDRA-13890:
--
It is probably out of scope, but it would anyway be nice to produce our own
{{RateLimiter}} because the Guava one doesn't permit taking a permit
asynchronously, and this means we require an extra unnecessary thread for
"zero-copy" streaming. Baking the rate reporting into the {{RateLimiter}} for
use elsewhere we rate limit would also make a lot of sense IMO. If we're
limiting the rate, we probably care about reporting it too.
> Expose current compaction throughput
>
>
> Key: CASSANDRA-13890
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13890
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Tools
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Low
> Labels: lhf
> Fix For: 4.x
>
>
> Getting and setting the current compaction throughput limit is supported, but
> there's no means of knowing if the setting is actually making a difference.
> Let's expose the current throughput being utilized by Cassandra that's in the
> {{compactionRateLimiter}}
--
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
[jira] [Updated] (CASSANDRA-15079) Secondary Index not returning complete data
[ https://issues.apache.org/jira/browse/CASSANDRA-15079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chakravarthi Manepalli updated CASSANDRA-15079: --- Description: The result response when we query using a secondary index does not give complete data. Some of the rows are missing. After dropping the index and creating it again, the query worked fine. Observation: The missed data entry is last edited 20 days ago. I suspect may be the data which is old is not getting indexed properly through secondary indexes. was: The result response when we query using a secondary index does not give complete data. Some of the rows are missing. Observation: The missed data entry is last edited 20 days ago. I suspect may be the data which is old is not getting indexed properly through secondary indexes. > Secondary Index not returning complete data > --- > > Key: CASSANDRA-15079 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15079 > Project: Cassandra > Issue Type: Bug > Components: Feature/2i Index >Reporter: Chakravarthi Manepalli >Priority: High > Labels: performance > Attachments: missing_data_cassandra.png > > > The result response when we query using a secondary index does not give > complete data. Some of the rows are missing. After dropping the index and > creating it again, the query worked fine. > Observation: The missed data entry is last edited 20 days ago. > I suspect may be the data which is old is not getting indexed properly > through secondary indexes. -- 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
[jira] [Updated] (CASSANDRA-15079) Secondary Index not returning complete data
[ https://issues.apache.org/jira/browse/CASSANDRA-15079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chakravarthi Manepalli updated CASSANDRA-15079: --- Since Version: 3.11.3 (was: 3.11.4) > Secondary Index not returning complete data > --- > > Key: CASSANDRA-15079 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15079 > Project: Cassandra > Issue Type: Bug > Components: Feature/2i Index >Reporter: Chakravarthi Manepalli >Priority: High > Labels: performance > Attachments: missing_data_cassandra.png > > > The result response when we query using a secondary index does not give > complete data. Some of the rows are missing. > Observation: The missed data entry is last edited 20 days ago. > I suspect may be the data which is old is not getting indexed properly > through secondary indexes. -- 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
[jira] [Updated] (CASSANDRA-15079) Secondary Index not returning complete data
[ https://issues.apache.org/jira/browse/CASSANDRA-15079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chakravarthi Manepalli updated CASSANDRA-15079: --- Summary: Secondary Index not returning complete data (was: Secondary Index not returning data) > Secondary Index not returning complete data > --- > > Key: CASSANDRA-15079 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15079 > Project: Cassandra > Issue Type: Bug > Components: Feature/2i Index >Reporter: Chakravarthi Manepalli >Priority: High > Labels: performance > Attachments: missing_data_cassandra.png > > > The result response when we query using a secondary index does not give > complete data. Some of the rows are missing. > Observation: The missed data entry is last edited 20 days ago. > I suspect may be the data which is old is not getting indexed properly > through secondary indexes. -- 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
[jira] [Commented] (CASSANDRA-15079) Secondary Index not returning data
[ https://issues.apache.org/jira/browse/CASSANDRA-15079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810633#comment-16810633 ] Chakravarthi Manepalli commented on CASSANDRA-15079: Hi Cassandra Team, Currently we are trying to reproduce this issue. We were setting up a server to reproduce this issue. We will let you know if any results found. > Secondary Index not returning data > -- > > Key: CASSANDRA-15079 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15079 > Project: Cassandra > Issue Type: Bug > Components: Feature/2i Index >Reporter: Chakravarthi Manepalli >Priority: High > Labels: performance > Attachments: missing_data_cassandra.png > > > The result response when we query using a secondary index does not give > complete data. Some of the rows are missing. > Observation: The missed data entry is last edited 20 days ago. > I suspect may be the data which is old is not getting indexed properly > through secondary indexes. -- 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
[jira] [Created] (CASSANDRA-15079) Secondary Index not returning data
Chakravarthi Manepalli created CASSANDRA-15079: -- Summary: Secondary Index not returning data Key: CASSANDRA-15079 URL: https://issues.apache.org/jira/browse/CASSANDRA-15079 Project: Cassandra Issue Type: Bug Components: Feature/2i Index Reporter: Chakravarthi Manepalli Attachments: missing_data_cassandra.png The result response when we query using a secondary index does not give complete data. Some of the rows are missing. Observation: The missed data entry is last edited 20 days ago. I suspect may be the data which is old is not getting indexed properly through secondary indexes. -- 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
[jira] [Updated] (CASSANDRA-15072) Incomplete range results during 2.X -> 3.11.4 upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-15072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-15072:
Reviewers: Sam Tunnicliffe
> 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 < 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 < 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
[jira] [Updated] (CASSANDRA-15072) Incomplete range results during 2.X -> 3.11.4 upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-15072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-15072:
Status: Review In Progress (was: Patch Available)
> 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 < 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 < 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
[jira] [Commented] (CASSANDRA-15072) Incomplete range results during 2.X -> 3.11.4 upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-15072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810575#comment-16810575
]
Sam Tunnicliffe commented on CASSANDRA-15072:
-
[~bdeggleston] sure, I'll review asap
> 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 < 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 < 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
