[
https://issues.apache.org/jira/browse/CASSANDRA-9840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Kumar updated CASSANDRA-9840:
-----------------------------------
Description: This test is currently failing on trunk. I've attached the
test output and logs. It seems that the failure of the test doesn't necessarily
have anything to do with global row/key caches - as on the initial loop of the
test [neither are
used|https://github.com/riptano/cassandra-dtest/blob/master/global_row_key_cache_test.py#L15]
and we still hit failure. The test itself fails when a second validation of
values after a cluster restart fails to capture deletes issued prior to the
restart and first successful validation. However, if I add flushes prior to
restarting the cluster the test completes successfully, implying an issue with
loss of in-memory mutations due to the cluster restart. Initially I had though
this might be due to CASSANDRA-9669, but as Benedict pointed out, the fact that
this test has been succeeding consistently on both 2.1 and 2.2 branch indicates
there may be another issue at hand. (was: This test is currently failing on
trunk. I've attached the test output and logs. It seems that the failure of the
test doesn't necessarily have anything to do with global row/key caches - as on
the initial loop of the test [neither are
used|https://github.com/riptano/cassandra-dtest/blob/master/global_row_key_cache_test.py#L15].
The test itself fails when a second validation of values after a cluster
restart fails to capture deletes issued prior to the restart and first
successful validation. However, if I add flushes prior to restarting the
cluster the test completes successfully, implying an issue with loss of
in-memory mutations due to the cluster restart. Initially I had though this
might be due to CASSANDRA-9669, but as Benedict pointed out, the fact that this
test has been succeeding consistently on both 2.1 and 2.2 branch indicates
there may be another issue at hand.)
> global_row_key_cache_test.py fails; loses mutations on cluster restart
> ----------------------------------------------------------------------
>
> Key: CASSANDRA-9840
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9840
> Project: Cassandra
> Issue Type: Sub-task
> Reporter: Shawn Kumar
> Priority: Blocker
> Fix For: 3.0.x
>
> Attachments: node1.log, node2.log, node3.log, noseout.txt
>
>
> This test is currently failing on trunk. I've attached the test output and
> logs. It seems that the failure of the test doesn't necessarily have anything
> to do with global row/key caches - as on the initial loop of the test
> [neither are
> used|https://github.com/riptano/cassandra-dtest/blob/master/global_row_key_cache_test.py#L15]
> and we still hit failure. The test itself fails when a second validation of
> values after a cluster restart fails to capture deletes issued prior to the
> restart and first successful validation. However, if I add flushes prior to
> restarting the cluster the test completes successfully, implying an issue
> with loss of in-memory mutations due to the cluster restart. Initially I had
> though this might be due to CASSANDRA-9669, but as Benedict pointed out, the
> fact that this test has been succeeding consistently on both 2.1 and 2.2
> branch indicates there may be another issue at hand.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
