cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergio Bossa (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-10130) Node failure during 2i update after streaming can have incomplete 2i when restarted
Date Tue, 16 May 2017 08:48:05 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-10130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16012006#comment-16012006
] 

Sergio Bossa commented on CASSANDRA-10130:
------------------------------------------

Some more feedback by my side too.

I think there still is a subtle concurrency issue, due to the fact we have some methods managing
the "index status" in the system keyspace via the counter, and other methods directly messing
with the system keyspace and/or the pending builds map; i.e., what happens if the index is
unregistered while it is being rebuilt? Probably an [NPE|https://github.com/apache/cassandra/compare/trunk...adelapena:10130-trunk#diff-3f2c8994c4ff8748c3faf7e70958520dR424].
I would suggest to clean it up a bit by avoiding to keep "pending builds" in the map after
they're all done, that is after the index has been marked as built: by doing so, you can just
remove the pending build inside {{markIndexBuilt}} if the counter reaches 0 (you'd have to
guard the {{mark*}} methods rather than the counter ones), and hence keep the "build management"
code inside the two "mark building/built" methods only.

I'm kinda unsure if we should actually call {{markIndexBuilding}} inside {{createIndex}}:
what if the user forgets to call {{markIndexBuilt}} inside the initialization task? There's
no such contract forcing the user to do that. So, as a corollary, we should probably accept
calls to {{markIndexBuilt}} even without a previous {{markIndexBuilding}} call (that is, making
it idempotent).

Also, {{buildAllIndexesBlocking}} doesn't follow the "mark building/built" pattern: isn't
that a weird anomaly? I know the {{StreamReceiveTask}} does that, but what about other callers?

Regarding {{PendingIndexBuildsCounter}}, it isn't really just a counter, I would rename it
(i.e. just {{PendingBuild}}), and rename its methods as well for further clarity; or we could
ditch it altogether as suggested by [~pauloricardomg].

Finally regarding:

bq. the user will expect the index NOT to be rebuilt on restart if there was a subsequent
successful rebuild.

Is it what [~adelapena] actually meant? I do not think the index is actually rebuilt on restart
if successfully rebuilt manually, or am I missing the point?

> Node failure during 2i update after streaming can have incomplete 2i when restarted
> -----------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-10130
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10130
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Coordination
>            Reporter: Yuki Morishita
>            Assignee: Andrés de la Peña
>            Priority: Minor
>
> Since MV/2i update happens after SSTables are received, node failure during MV/2i update
can leave received SSTables live when restarted while MV/2i are partially up to date.
> We can add some kind of tracking mechanism to automatically rebuild at the startup, or
at least warn user when the node restarts.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org


Mime
View raw message