[jira] [Commented] (CASSANDRA-13911) IllegalStateException thrown by UPI.Serializer.hasNext() for some SELECT queries
[ https://issues.apache.org/jira/browse/CASSANDRA-13911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17779034#comment-17779034 ] Szymon Miezal commented on CASSANDRA-13911: --- [~aleksey] The reason I have asked is that I have found that for {{SELECT DISTINCT queries SRP kicks in even though all of the rows seem to be easily fitting into the requested }}LIMIT. The test that replicates the scenario I am referring to https://github.com/szymon-miezal/cassandra-dtest/commit/56c0b1a7d01550b140d07503368f69b254431c76 {code:java} 127.0.0.1 0:00:00.003267 Parsing SELECT DISTINCT pk FROM test.test Native-Transport-Requests-1 127.0.0.1 0:00:00.004578 Preparing statement Native-Transport-Requests-1 127.0.0.1 0:00:00.015112 Computing ranges to query Native-Transport-Requests-1 127.0.0.1 0:00:00.015321 Submitting range requests on 2 ranges with a concurrency of 1 (0.0 rows per range expected) Native-Transport-Requests-1 127.0.0.1 0:00:00.016695 Enqueuing request to /127.0.0.1 Native-Transport-Requests-1 127.0.0.1 0:00:00.016948 Executing single-partition query on peers Native-Transport-Requests-1 127.0.0.1 0:00:00.017021 Acquiring sstable references Native-Transport-Requests-1 127.0.0.1 0:00:00.017086 Merging memtable contents Native-Transport-Requests-1 127.0.0.1 0:00:00.017262 Read 0 live rows and 0 tombstone cells Native-Transport-Requests-1 127.0.0.1 0:00:00.018357 Enqueuing request to /127.0.0.2 Native-Transport-Requests-1 127.0.0.1 0:00:00.018547 Submitted 1 concurrent range requests Native-Transport-Requests-1 127.0.0.1 0:00:00.018663 Sending RANGE_SLICE message to /127.0.0.2 MessagingService-Outgoing-/127.0.0.2-Small 127.0.0.1 0:00:00.020153 Sending RANGE_SLICE message to /127.0.0.1 MessagingService-Outgoing-/127.0.0.1-Small 127.0.0.1 0:00:00.020760 RANGE_SLICE message received from /127.0.0.1 MessagingService-Incoming-/127.0.0.1 127.0.0.1 0:00:00.021036 Executing seq scan across 0 sstables for (min(-9223372036854775808), min(-9223372036854775808)] ReadStage-3 127.0.0.1 0:00:00.021805 Read 10 live rows and 0 tombstone cells ReadStage-3 127.0.0.2 0:00:00.001305 RANGE_SLICE message received from /127.0.0.1 MessagingService-Incoming-/127.0.0.2 127.0.0.1 0:00:00.021972 Enqueuing response to /127.0.0.1 ReadStage-3 127.0.0.1 0:00:00.022209 Sending REQUEST_RESPONSE message to /127.0.0.1 MessagingService-Outgoing-/127.0.0.1-Small 127.0.0.1 0:00:00.022540 REQUEST_RESPONSE message received from /127.0.0.1 MessagingService-Incoming-/127.0.0.1 127.0.0.1 0:00:00.022798 Processing response from /127.0.0.1 RequestResponseStage-3 127.0.0.2 0:00:00.003844 Executing seq scan across 0 sstables for (min(-9223372036854775808), min(-9223372036854775808)] ReadStage-2 127.0.0.2 0:00:00.004773 Read 10 live rows and 0 tombstone cells ReadStage-2 127.0.0.2 0:00:00.004917 Enqueuing response to /127.0.0.1 ReadStage-2 127.0.0.2 0:00:00.005219 Sending REQUEST_RESPONSE message to /127.0.0.1 MessagingService-Outgoing-/127.0.0.1-Small 127.0.0.1 0:00:00.026714 REQUEST_RESPONSE message received from /127.0.0.2 MessagingService-Incoming-/127.0.0.1 127.0.0.1 0:00:00.027008 Processing response from /127.0.0.2 RequestResponseStage-2 127.0.0.1 0:00:00.040391 Requesting 4990 extra rows from /127.0.0.2 for short read protection Native-Transport-Requests-1 127.0.0.1 0:00:00.040788 Sending RANGE_SLICE message to /127.0.0.2 MessagingService-Outgoing-/127.0.0.2-Small 127.0.0.2 0:00:00.13 RANGE_SLICE message received from /127.0.0.1 MessagingService-Incoming-/127.0.0.2 127.0.0.2 0:00:00.000344 Executing seq scan across 0 sstables for (random_key_8, min(-9223372036854775808)] ReadStage-4 127.0.0.2 0:00:00.000567 Read 0 live rows and 0 tombstone cells ReadStage-4 127.0.0.2 0:00:00.000684 Enqueuing response to /127.0.0.1 ReadStage-4 127.0.0.1 0:00:00.042362 REQUEST_RESPONSE message received from /127.0.0.2 MessagingService-Incoming-/127.0.0.1 127.0.0.2 0:00:00.000872 Sending REQUEST_RESPONSE message to /127.0.0.1 MessagingService-Outgoing-/127.0.0.1-Small 127.0.0.1 0:00:00.042675 Processing response from /127.0.0.2 RequestResponseStage-5 127.0.0.1 0:00:00.043017 Requesting 4990 extra rows from /127.0.0.1 for short read protection Native-Transport-Requests-1 127.0.0.1 0:00:00.043534 Executing seq scan across 0 sstables for (random_key_8, min(-9223372036854775808)] ReadStage-3 127.0.0.1 0:00:00.043742 Read 0 live rows and 0 tombstone cells ReadStage-3 {code} The above trace shows additional tow requests happening: {code:java
[jira] [Commented] (CASSANDRA-13911) IllegalStateException thrown by UPI.Serializer.hasNext() for some SELECT queries
[ https://issues.apache.org/jira/browse/CASSANDRA-13911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17776585#comment-17776585 ] Aleksey Yeschenko commented on CASSANDRA-13911: --- Indeed, if hidden is the right word for it. This was a pretty nasty one. > IllegalStateException thrown by UPI.Serializer.hasNext() for some SELECT > queries > > > Key: CASSANDRA-13911 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13911 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Coordination >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > Fix For: 3.0.15, 3.11.1 > > > Certain combinations of rows, in presence of per partition limit (set > explicitly in 3.6+ or implicitly to 1 via DISTINCT) cause > {{UnfilteredPartitionIterators.Serializer.hasNext()}} to throw > {{IllegalStateException}} . > Relevant code snippet: > {code} > // We can't answer this until the previously returned iterator has been fully > consumed, > // so complain if that's not the case. > if (next != null && next.hasNext()) > throw new IllegalStateException("Cannot call hasNext() until the previous > iterator has been fully consumed"); > {code} > Since {{UnfilteredPartitionIterators.Serializer}} and > {{UnfilteredRowIteratorSerializer.serializer}} deserialize partitions/rows > lazily, it is required for correct operation of the partition iterator to > have the previous partition fully consumed, so that deserializing the next > one can start from the correct position in the byte buffer. However, that > condition won’t always be satisfied, as there are legitimate combinations of > rows that do not consume every row in every partition. > For example, look at [this > dtest|https://github.com/iamaleksey/cassandra-dtest/commits/13911]. > In case we end up with a following pattern of rows: > {code} > node1, partition 0 | 0 > node2, partition 0 | x x > {code} > , where {{x}} and {{x}} a row tombstones for rows 1 and 2, it’s sufficient > for {{MergeIterator}} to only look at row 0 in partition from node1 and at > row tombstone 1 from node2 to satisfy the per partition limit of 1. The > stopping merge result counter will stop iteration right there, leaving row > tombstone 2 from node2 unvisited and not deseiralized. Switching to the next > partition will in turn trigger the {{IllegalStateException}} because we > aren’t done yet. > The stopping counter is behaving correctly, so is the {{MergeIterator}}. I’ll > note that simply removing that condition is not enough to fix the problem > properly - it’d just cause us to deseiralize garbage, trying to deserialize a > new partition from a position in the bytebuffer that precedes remaining rows > in the previous partition. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13911) IllegalStateException thrown by UPI.Serializer.hasNext() for some SELECT queries
[ https://issues.apache.org/jira/browse/CASSANDRA-13911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17776534#comment-17776534 ] Szymon Miezal commented on CASSANDRA-13911: --- Possibly the answer is hidden in the two following tests (committed at https://github.com/apache/cassandra-dtest/commit/b0f34e3a6b41c3be5f86dcb8db4f32de9436b071): * [https://github.com/apache/cassandra-dtest/blob/0a8fea03d2f66463478ec4a49387bfb035dd403a/consistency_test.py#L1073] * [https://github.com/apache/cassandra-dtest/blob/0a8fea03d2f66463478ec4a49387bfb035dd403a/consistency_test.py#L1009] > IllegalStateException thrown by UPI.Serializer.hasNext() for some SELECT > queries > > > Key: CASSANDRA-13911 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13911 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Coordination >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > Fix For: 3.0.15, 3.11.1 > > > Certain combinations of rows, in presence of per partition limit (set > explicitly in 3.6+ or implicitly to 1 via DISTINCT) cause > {{UnfilteredPartitionIterators.Serializer.hasNext()}} to throw > {{IllegalStateException}} . > Relevant code snippet: > {code} > // We can't answer this until the previously returned iterator has been fully > consumed, > // so complain if that's not the case. > if (next != null && next.hasNext()) > throw new IllegalStateException("Cannot call hasNext() until the previous > iterator has been fully consumed"); > {code} > Since {{UnfilteredPartitionIterators.Serializer}} and > {{UnfilteredRowIteratorSerializer.serializer}} deserialize partitions/rows > lazily, it is required for correct operation of the partition iterator to > have the previous partition fully consumed, so that deserializing the next > one can start from the correct position in the byte buffer. However, that > condition won’t always be satisfied, as there are legitimate combinations of > rows that do not consume every row in every partition. > For example, look at [this > dtest|https://github.com/iamaleksey/cassandra-dtest/commits/13911]. > In case we end up with a following pattern of rows: > {code} > node1, partition 0 | 0 > node2, partition 0 | x x > {code} > , where {{x}} and {{x}} a row tombstones for rows 1 and 2, it’s sufficient > for {{MergeIterator}} to only look at row 0 in partition from node1 and at > row tombstone 1 from node2 to satisfy the per partition limit of 1. The > stopping merge result counter will stop iteration right there, leaving row > tombstone 2 from node2 unvisited and not deseiralized. Switching to the next > partition will in turn trigger the {{IllegalStateException}} because we > aren’t done yet. > The stopping counter is behaving correctly, so is the {{MergeIterator}}. I’ll > note that simply removing that condition is not enough to fix the problem > properly - it’d just cause us to deseiralize garbage, trying to deserialize a > new partition from a position in the bytebuffer that precedes remaining rows > in the previous partition. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13911) IllegalStateException thrown by UPI.Serializer.hasNext() for some SELECT queries
[ https://issues.apache.org/jira/browse/CASSANDRA-13911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17776257#comment-17776257 ] Szymon Miezal commented on CASSANDRA-13911: --- Does anyone remember what was the motivation for this particular condition change [https://github.com/apache/cassandra/commit/1efdf330e291a41cd8051e0c1195f75b5d352370#diff-212cd446e1b8c2aeb27818def0ba8c67370a1e00c5f657c85e42f0d43adfe05bR559?] I have found that [https://github.com/apache/cassandra-dtest/commit/51ad68ec45c7a40de1c51b31651632f2e87ceaa4] passes without it as well which is suspicious. The motivation for the questions is that I have found that in case of DISTINCT queries we are making an additional SRP call for every call of https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/service/DataResolver.java#L729 due to exactly that condition. > IllegalStateException thrown by UPI.Serializer.hasNext() for some SELECT > queries > > > Key: CASSANDRA-13911 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13911 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Coordination >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > Fix For: 3.0.15, 3.11.1 > > > Certain combinations of rows, in presence of per partition limit (set > explicitly in 3.6+ or implicitly to 1 via DISTINCT) cause > {{UnfilteredPartitionIterators.Serializer.hasNext()}} to throw > {{IllegalStateException}} . > Relevant code snippet: > {code} > // We can't answer this until the previously returned iterator has been fully > consumed, > // so complain if that's not the case. > if (next != null && next.hasNext()) > throw new IllegalStateException("Cannot call hasNext() until the previous > iterator has been fully consumed"); > {code} > Since {{UnfilteredPartitionIterators.Serializer}} and > {{UnfilteredRowIteratorSerializer.serializer}} deserialize partitions/rows > lazily, it is required for correct operation of the partition iterator to > have the previous partition fully consumed, so that deserializing the next > one can start from the correct position in the byte buffer. However, that > condition won’t always be satisfied, as there are legitimate combinations of > rows that do not consume every row in every partition. > For example, look at [this > dtest|https://github.com/iamaleksey/cassandra-dtest/commits/13911]. > In case we end up with a following pattern of rows: > {code} > node1, partition 0 | 0 > node2, partition 0 | x x > {code} > , where {{x}} and {{x}} a row tombstones for rows 1 and 2, it’s sufficient > for {{MergeIterator}} to only look at row 0 in partition from node1 and at > row tombstone 1 from node2 to satisfy the per partition limit of 1. The > stopping merge result counter will stop iteration right there, leaving row > tombstone 2 from node2 unvisited and not deseiralized. Switching to the next > partition will in turn trigger the {{IllegalStateException}} because we > aren’t done yet. > The stopping counter is behaving correctly, so is the {{MergeIterator}}. I’ll > note that simply removing that condition is not enough to fix the problem > properly - it’d just cause us to deseiralize garbage, trying to deserialize a > new partition from a position in the bytebuffer that precedes remaining rows > in the previous partition. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13911) IllegalStateException thrown by UPI.Serializer.hasNext() for some SELECT queries
[ https://issues.apache.org/jira/browse/CASSANDRA-13911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16187022#comment-16187022 ] Aleksey Yeschenko commented on CASSANDRA-13911: --- Thanks. [3.0 utests|https://circleci.com/gh/iamaleksey/cassandra/43] have the usual unrelated failures (mostly MV schema races). [3.11 utests|https://circleci.com/gh/iamaleksey/cassandra/44] have the common {{CommitLogSegmentManagerTest}} failure, and [4.0 utests|https://circleci.com/gh/iamaleksey/cassandra/45] have an unrelated {{StreamTransferTaskTest}} failure + the usual {{ViewFilteringTest}} timeouts. Basically baseline. [3.0 dtests|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/347/] only have the usual suspects (also we need to do something about {{Could not do a git clone}} issue already). [3.11 dtests|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/348/] and [4.0 dtests|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/349/] are a bit more noisy but nothing related fails for a good reason. The flakiness and timeouts on jenkins are pretty bad overall though. Committed as [1efdf330e291a41cd8051e0c1195f75b5d352370|https://github.com/apache/cassandra/commit/1efdf330e291a41cd8051e0c1195f75b5d352370] to 3.0 and merged with 3.11 and trunk. Dtest committed as [51ad68ec45c7a40de1c51b31651632f2e87ceaa4|https://github.com/apache/cassandra-dtest/commit/51ad68ec45c7a40de1c51b31651632f2e87ceaa4]. > IllegalStateException thrown by UPI.Serializer.hasNext() for some SELECT > queries > > > Key: CASSANDRA-13911 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13911 > Project: Cassandra > Issue Type: Bug > Components: Coordination >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko > Fix For: 3.0.15, 3.11.1 > > > Certain combinations of rows, in presence of per partition limit (set > explicitly in 3.6+ or implicitly to 1 via DISTINCT) cause > {{UnfilteredPartitionIterators.Serializer.hasNext()}} to throw > {{IllegalStateException}} . > Relevant code snippet: > {code} > // We can't answer this until the previously returned iterator has been fully > consumed, > // so complain if that's not the case. > if (next != null && next.hasNext()) > throw new IllegalStateException("Cannot call hasNext() until the previous > iterator has been fully consumed"); > {code} > Since {{UnfilteredPartitionIterators.Serializer}} and > {{UnfilteredRowIteratorSerializer.serializer}} deserialize partitions/rows > lazily, it is required for correct operation of the partition iterator to > have the previous partition fully consumed, so that deserializing the next > one can start from the correct position in the byte buffer. However, that > condition won’t always be satisfied, as there are legitimate combinations of > rows that do not consume every row in every partition. > For example, look at [this > dtest|https://github.com/iamaleksey/cassandra-dtest/commits/13911]. > In case we end up with a following pattern of rows: > {code} > node1, partition 0 | 0 > node2, partition 0 | x x > {code} > , where {{x}} and {{x}} a row tombstones for rows 1 and 2, it’s sufficient > for {{MergeIterator}} to only look at row 0 in partition from node1 and at > row tombstone 1 from node2 to satisfy the per partition limit of 1. The > stopping merge result counter will stop iteration right there, leaving row > tombstone 2 from node2 unvisited and not deseiralized. Switching to the next > partition will in turn trigger the {{IllegalStateException}} because we > aren’t done yet. > The stopping counter is behaving correctly, so is the {{MergeIterator}}. I’ll > note that simply removing that condition is not enough to fix the problem > properly - it’d just cause us to deseiralize garbage, trying to deserialize a > new partition from a position in the bytebuffer that precedes remaining rows > in the previous partition. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13911) IllegalStateException thrown by UPI.Serializer.hasNext() for some SELECT queries
[ https://issues.apache.org/jira/browse/CASSANDRA-13911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16185799#comment-16185799 ] Sam Tunnicliffe commented on CASSANDRA-13911: - +1 > IllegalStateException thrown by UPI.Serializer.hasNext() for some SELECT > queries > > > Key: CASSANDRA-13911 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13911 > Project: Cassandra > Issue Type: Bug > Components: Coordination >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko > Fix For: 3.0.15, 3.11.1 > > > Certain combinations of rows, in presence of per partition limit (set > explicitly in 3.6+ or implicitly to 1 via DISTINCT) cause > {{UnfilteredPartitionIterators.Serializer.hasNext()}} to throw > {{IllegalStateException}} . > Relevant code snippet: > {code} > // We can't answer this until the previously returned iterator has been fully > consumed, > // so complain if that's not the case. > if (next != null && next.hasNext()) > throw new IllegalStateException("Cannot call hasNext() until the previous > iterator has been fully consumed"); > {code} > Since {{UnfilteredPartitionIterators.Serializer}} and > {{UnfilteredRowIteratorSerializer.serializer}} deserialize partitions/rows > lazily, it is required for correct operation of the partition iterator to > have the previous partition fully consumed, so that deserializing the next > one can start from the correct position in the byte buffer. However, that > condition won’t always be satisfied, as there are legitimate combinations of > rows that do not consume every row in every partition. > For example, look at [this > dtest|https://github.com/iamaleksey/cassandra-dtest/commits/13911]. > In case we end up with a following pattern of rows: > {code} > node1, partition 0 | 0 > node2, partition 0 | x x > {code} > , where {{x}} and {{x}} a row tombstones for rows 1 and 2, it’s sufficient > for {{MergeIterator}} to only look at row 0 in partition from node1 and at > row tombstone 1 from node2 to satisfy the per partition limit of 1. The > stopping merge result counter will stop iteration right there, leaving row > tombstone 2 from node2 unvisited and not deseiralized. Switching to the next > partition will in turn trigger the {{IllegalStateException}} because we > aren’t done yet. > The stopping counter is behaving correctly, so is the {{MergeIterator}}. I’ll > note that simply removing that condition is not enough to fix the problem > properly - it’d just cause us to deseiralize garbage, trying to deserialize a > new partition from a position in the bytebuffer that precedes remaining rows > in the previous partition. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13911) IllegalStateException thrown by UPI.Serializer.hasNext() for some SELECT queries
[ https://issues.apache.org/jira/browse/CASSANDRA-13911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16185724#comment-16185724 ] Aleksey Yeschenko commented on CASSANDRA-13911: --- Branches with fixes here: [3.0|https://github.com/iamaleksey/cassandra/commits/13911-3.0], [3.11|https://github.com/iamaleksey/cassandra/commits/13911-3.11], [4.0|https://github.com/iamaleksey/cassandra/commits/13911-4.0]. 3.11 needs an extra dtest to show that the change in {{DataResolver}} is necessary (using {{PER PARTITION LIMIT}} > 1), working on it. Tests are running. > IllegalStateException thrown by UPI.Serializer.hasNext() for some SELECT > queries > > > Key: CASSANDRA-13911 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13911 > Project: Cassandra > Issue Type: Bug > Components: Coordination >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko > Fix For: 3.0.15, 3.11.1 > > > Certain combinations of rows, in presence of per partition limit (set > explicitly in 3.6+ or implicitly to 1 via DISTINCT) cause > {{UnfilteredPartitionIterators.Serializer.hasNext()}} to throw > {{IllegalStateException}} . > Relevant code snippet: > {code} > // We can't answer this until the previously returned iterator has been fully > consumed, > // so complain if that's not the case. > if (next != null && next.hasNext()) > throw new IllegalStateException("Cannot call hasNext() until the previous > iterator has been fully consumed"); > {code} > Since {{UnfilteredPartitionIterators.Serializer}} and > {{UnfilteredRowIteratorSerializer.serializer}} deserialize partitions/rows > lazily, it is required for correct operation of the partition iterator to > have the previous partition fully consumed, so that deserializing the next > one can start from the correct position in the byte buffer. However, that > condition won’t always be satisfied, as there are legitimate combinations of > rows that do not consume every row in every partition. > For example, look at [this > dtest|https://github.com/iamaleksey/cassandra-dtest/commits/13911]. > In case we end up with a following pattern of rows: > {code} > node1, partition 0 | 0 > node2, partition 0 | x x > {code} > , where {{x}} and {{x}} a row tombstones for rows 1 and 2, it’s sufficient > for {{MergeIterator}} to only look at row 0 in partition from node1 and at > row tombstone 1 from node2 to satisfy the per partition limit of 1. The > stopping merge result counter will stop iteration right there, leaving row > tombstone 2 from node2 unvisited and not deseiralized. Switching to the next > partition will in turn trigger the {{IllegalStateException}} because we > aren’t done yet. > The stopping counter is behaving correctly, so is the {{MergeIterator}}. I’ll > note that simply removing that condition is not enough to fix the problem > properly - it’d just cause us to deseiralize garbage, trying to deserialize a > new partition from a position in the bytebuffer that precedes remaining rows > in the previous partition. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org