DanielLeens commented on issue #12734: URL: https://github.com/apache/seatunnel/issues/12734#issuecomment-6123940614
Thanks for the precise analysis and proposed direction. I checked the current `dev` implementation at `4ae4fee30165e9f082f80b05ec5a8f3bb810b474`. The failure mode is real in the TCP/IP joiner: `joinViaPossibleMembers()` retries the configured addresses, but when they are all blacklisted it only lets a non-lite member elect itself. A lite member cannot complete that fallback; after the unsuccessful mastership attempt there is no path that makes those temporarily blacklisted addresses eligible for the next connection attempt before the overall join timeout expires. I also found no open or merged PR covering this joiner path. The retry-and-unblacklist direction is therefore reasonable. For the first fix, though, please keep it as small as possible and reuse the joiner's existing retry cadence rather than adding a new user-facing property. In the lite-member and all-blacklisted case, wait for the existing retry interval, clear the temporary blacklist for the candidate addresses, and let the next loop iteration retry them. The behavior must remain limited to lite members; a regular member's current self-election path must not change. Please include focused coverage for: 1. a worker starting first, initially failing its master addresses, then joining after a master starts before `hazelcast.max.join.seconds`; 2. a worker with no master ever becoming available, which must still time out and must never self-elect; 3. the unchanged non-lite-member path; and 4. the discovery joiner subclass, which inherits this TCP/IP retry logic. Please open one focused PR against `dev` and link it here. The PR should document the timing used by the test so reviewers can verify that the worker really passed through the blacklist/retry path. -- 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]
