SEZ9 commented on PR #12755: URL: https://github.com/apache/seatunnel/pull/12755#issuecomment-6244592547
Thanks for the detailed rundown on 19a3592c — the breakdown of F1/F3 into three distinct WARN/WARN/INFO states, the FINE-level `blacklist()`/`unblacklist()` override for F4, the en/zh doc note for F5, the `interrupt()`+`join()` plus `HazelcastInstanceFactory.shutdownAll()` in `finally` for F6, and the description/Javadoc sync for F7 all sound like they address what was raised. I'll take another pass over the head to confirm. One gap: your list covers five points, but there were seven findings, and **F2** isn't mentioned. That one was about the lite-member `continue` path skipping `clusterService.setMasterAddressToJoin(null)`, so a master address learned earlier could keep the retry loop pinned to a dead master instead of re-asking the other candidates. Could you confirm whether 19a3592c also resets the master-address-to-join on that branch (or explain why it isn't needed)? If it's already handled, a pointer to where would help me close it out quickly. Also, for F1/F3 — beyond the corrected log messages, does the empty-candidate case now re-run discovery (or otherwise avoid sleeping out the full join window with nothing to retry)? Just want to make sure the behavior, not only the logging, is covered. Once F2 is clarified I should be able to wrap up the review. <!-- streview-comment:1830 --> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
