cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-14356) LWTs keep failing in trunk after immutable refactor
Date Mon, 18 Jun 2018 09:38:00 GMT


Aleksey Yeschenko commented on CASSANDRA-14356:

[~michaelsembwever] Change LGTM, ship it (:

> LWTs keep failing in trunk after immutable refactor
> ---------------------------------------------------
>                 Key: CASSANDRA-14356
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>         Environment: OpenJDK Runtime Environment (build 1.8.0_161-b14), Cassandra 4.0
commit c22ee2bd451d030e99cfb65be839bbc735a5352f (29.3.2018 14:01)
>            Reporter: Michael Burman
>            Assignee: Michael Burman
>            Priority: Major
>              Labels: LWT
>             Fix For: 4.0
>         Attachments: CASSANDRA-14356.diff
> In the PaxosState, the original assert check is in the form of:
> assert promised.update.metadata() == accepted.update.metadata() && accepted.update.metadata()
== mostRecentCommit.update.metadata();
> However, after the change to make TableMetadata immutable this no longer works as these
instances are not necessarily the same (or never). This causes the LWTs to fail although they're
still correctly targetting the same table.
> From IRC:
> <pcmanus> It's a bug alright. Though really, the assertion should be on the metadata
ids, cause TableMetadata#equals does more than what we want.
> <pcmanus> That is, replacing by .equals() is not ok. That would reject throw on
any change to a table metadata, while the spirit of the assumption was to sanity check both
update were on the same table.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message