[
https://issues.apache.org/jira/browse/CASSANDRA-19248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18103286#comment-18103286
]
Mohammad Suhel edited comment on CASSANDRA-19248 at 8/10/26 8:39 AM:
---------------------------------------------------------------------
Hi, [~marcuse] , I spent some time looking into this ticket and the patch in PR
#3620 by [~Novice_P] ([GitHub
PR|https://github.com/apache/cassandra/pull/3620]). Tagging you since you're
the one who added the disable-by-default behaviour in CASSANDRA-17679 for this
same danger, and you touched this same area of {{StorageService}} again
recently in CASSANDRA-21235, so figured you'd have the most context.
The bug itself still seems to be there on current trunk - {{resumeBootstrap()}}
hasn't changed since the PR was opened. It's gated on {{{}isBootstrapMode() &&
SystemKeyspace.bootstrapInProgress(){}}}, which stays true for the whole
duration of an active bootstrap, not just after a failure, so
{{resumeBootstrapSequence()}} (and therefore {{{}startBootstrap(){}}}) can
still get re-triggered while a stream is already running. The PR's approach -
gating on {{isBootstrapFailed()}} instead - looks like the right direction to
me, and it's still consistent with how {{Mode.JOINING_FAILED}} works on trunk
today.
That said, I don't think the PR is mergeable as-is:
- The new {{resumeBootstrap()}} has a log message that contradicts the
condition it's under - when {{isBootstrapMode()}} is true (i.e. still actively
streaming), it logs "...is not in bootstrap mode", which reads backwards.
- The added test brings in imports that aren't ordered per the project's
checkstyle {{ImportOrder}} rule (cassandra imports need to sort last), so it'd
fail the build as-is.
- The test's own assertion looks racy - it releases a latch and then
immediately checks a plain (non-volatile) boolean that's set from a separate
thread, with no join/wait in between. That assertion can end up silently
skipped depending on timing.
- It also doesn't apply cleanly to trunk anymore, though that's just a context
conflict in a neighbouring method, nothing semantic - would need a rebase
regardless.
If it's alright with you both, I'd like to pick this up and put together a
fresh PR against current trunk that fixes these issues, [~Novice_P], Let me
know if that works for you, or if there's some context I'm missing about why
this has been sitting for so long.
was (Author: suhel):
[~marcuse] , I spent some time looking into this ticket and the patch in PR
#3620 by [~Novice_P] ([GitHub
PR|https://github.com/apache/cassandra/pull/3620]). Tagging you since you're
the one who added the disable-by-default behaviour in CASSANDRA-17679 for this
same danger, and you touched this same area of \{{StorageService}} again
recently in CASSANDRA-21235, so figured you'd have the most context.
The bug itself still seems to be there on current trunk -
\{{resumeBootstrap()}} hasn't changed since the PR was opened. It's gated on
\{{isBootstrapMode() && SystemKeyspace.bootstrapInProgress()}}, which stays
true for the whole duration of an active bootstrap, not just after a failure,
so \{{resumeBootstrapSequence()}} (and therefore \{{startBootstrap()}}) can
still get re-triggered while a stream is already running. The PR's approach -
gating on \{{isBootstrapFailed()}} instead - looks like the right direction to
me, and it's still consistent with how \{{Mode.JOINING_FAILED}} works on trunk
today.
That said, I don't think the PR is mergeable as-is:
- The new \{{resumeBootstrap()}} has a log message that contradicts the
condition it's under - when \{{isBootstrapMode()}} is true (i.e. still actively
streaming), it logs "...is not in bootstrap mode", which reads backwards.
- The added test brings in imports that aren't ordered per the project's
checkstyle \{{ImportOrder}} rule (cassandra imports need to sort last), so it'd
fail the build as-is.
- The test's own assertion looks racy - it releases a latch and then
immediately checks a plain (non-volatile) boolean that's set from a separate
thread, with no join/wait in between. That assertion can end up silently
skipped depending on timing.
- It also doesn't apply cleanly to trunk anymore, though that's just a context
conflict in a neighbouring method, nothing semantic - would need a rebase
regardless.
If it's alright with you both, I'd like to pick this up and put together a
fresh PR against current trunk that fixes these issues, [~Novice_P], Let me
know if that works for you, or if there's some context I'm missing about why
this has been sitting for so long.
> "nodetool bootstrap resume" starts unnecessary streaming session on joining
> node
> --------------------------------------------------------------------------------
>
> Key: CASSANDRA-19248
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19248
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
> Reporter: Paulo Motta
> Assignee: Sunil Ramchandra Pawar
> Priority: Normal
> Labels: lhf
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Calling {{nodetool boostrap resume}} triggers a new bootstrap streaming
> session on a joining node, even if there's a bootstrap streaming session
> currently running.
> Each time this command is called, a new bootstrap streaming session is
> started, causing the same data to be needlessly streamed from peers.
> It should only be possible to call {{nodetool bootstrap resume}} if a
> previous bootstrap attempt has failed.
> An example of multiple invocations of {{nodetool bootstrap resume}} in a
> joining node is shown below:
> {noformat}
> $ nodetool netstats
> Mode: JOINING
> Bootstrap a1cf3bf0-ab3a-11ee-9fcf-5746a7aee9ca
> /A.B.C.D
> Receiving 13 files, 14302312660 bytes total. Already received 2
> files, 52389676 bytes total
> ks1/tbl1 80/80 bytes(100%) received from idx:0/A.B.C.D
> ks2/tbl2 471/471 bytes(100%) received from idx:0/A.B.C.D
> /E.F.G.H
> /I.J.K.L
> Bootstrap 7f1e7000-ab3d-11ee-9fcf-5746a7aee9ca
> /A.B.C.D
> Receiving 13 files, 14302312660 bytes total. Already received 0
> files, 0 bytes total
> /E.F.G.H
> /I.J.K.L
> Bootstrap 9ca42500-ab3a-11ee-9fcf-5746a7aee9ca
> /A.B.C.D
> /E.F.G.H
> Receiving 13 files, 14302312660 bytes total. Already received 2
> files, 104838752 bytes total
> ks1/tbl1 80/80 bytes(100%) received from idx:0/E.F.G.H
> ks2/tbl2 471/471 bytes(100%) received from idx:0/E.F.G.H
> /I.J.K.L {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
