[
https://issues.apache.org/jira/browse/CASSANDRA-5354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-5354:
----------------------------------------
Attachment: 5354.txt
For the record and from what I can tell, this is no due to CASSANDRA-4858 that
did not changed the prior behavior, but the fix for CASSANDRA-833 never really
worked. What happened is that:
* CASSANDRA-833 was committed and reversed right away (we don't remember why).
* CASSANDRA-3979 was committed. That patch made {{blockFor}} a constant
initialized in WriteResponseHandler ctor to consistencyLevel.blockFor() (and
used to initialize the size of {{responses}} in particular). This was correct
at the time, CASSANDRA-833 had been reverted.
* The rebase of CASSANDRA-833 was committed. That rebase changed blockFor() in
AbstractWriteResponseHandler to be blockForCL() (the "old" blockFor) + the
pending endpoints. However, WriteResponseHandler was not modify to use that
blockFor() method to initial the {{responses}} variable.
As a result, CASSANDRA-833 never "worked".
Anyway, attaching patch to hopefully fix this. I note that it includes a small
part of the original 833 patch in DatacenterSyncWriteResponseHandler that
apparently didn't made it in the rebase but I think is needed.
> CL regression in the presence of bootstrapping nodes
> ----------------------------------------------------
>
> Key: CASSANDRA-5354
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5354
> Project: Cassandra
> Issue Type: Bug
> Reporter: Jonathan Ellis
> Assignee: Sylvain Lebresne
> Attachments: 5354.txt
>
>
> It looks like CASSANDRA-4858 broke CASSANDRA-833 again; pendingEndpoints is
> not provided to or accounted by blockFor.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
