[
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: [email protected]
For additional commands, e-mail: [email protected]
