petrov-mg commented on code in PR #13217:
URL: https://github.com/apache/ignite/pull/13217#discussion_r3381756047
##########
modules/core/src/main/java/org/apache/ignite/internal/processors/rollingupgrade/RollingUpgradeProcessor.java:
##########
@@ -85,26 +78,25 @@ public RollingUpgradeProcessor(GridKernalContext ctx) {
/** {@inheritDoc} */
@Override public void onKernalStart(boolean active) throws
IgniteCheckedException {
- DiscoverySpi spi = ctx.config().getDiscoverySpi();
-
- if (spi instanceof TcpDiscoverySpi)
- ring = ((TcpDiscoverySpi)spi).discoveryRing();
-
startLatch.countDown();
}
/** {@inheritDoc} */
@Override public void start() throws IgniteCheckedException {
- ctx.event().addLocalEventListener(new GridLocalEventListener() {
- @Override public void onEvent(Event evt) {
+ ctx.event().addLocalEventListener(
+ evt -> {
UUID nodeId = ((DiscoveryEvent)evt).eventNode().id();
synchronized (lock) {
if (lastJoiningNode != null &&
lastJoiningNode.id().equals(nodeId))
Review Comment:
> Then it fails in a later validation step
> it can send the join request again with the same node ID
> As a result, rolling upgrade can be disabled while a 2.19 node is still
joining a 2.18 cluster
It does not look like a problem - the joining node will fail validation
again and will not join the cluster.
Anyway I don't think that it is good idea to get around some specific
Discovery implementation quirks in RollingUpgradeProcessor.
##########
modules/core/src/main/java/org/apache/ignite/internal/processors/rollingupgrade/RollingUpgradeProcessor.java:
##########
@@ -85,26 +78,25 @@ public RollingUpgradeProcessor(GridKernalContext ctx) {
/** {@inheritDoc} */
@Override public void onKernalStart(boolean active) throws
IgniteCheckedException {
- DiscoverySpi spi = ctx.config().getDiscoverySpi();
-
- if (spi instanceof TcpDiscoverySpi)
- ring = ((TcpDiscoverySpi)spi).discoveryRing();
-
startLatch.countDown();
}
/** {@inheritDoc} */
@Override public void start() throws IgniteCheckedException {
- ctx.event().addLocalEventListener(new GridLocalEventListener() {
- @Override public void onEvent(Event evt) {
+ ctx.event().addLocalEventListener(
+ evt -> {
UUID nodeId = ((DiscoveryEvent)evt).eventNode().id();
synchronized (lock) {
if (lastJoiningNode != null &&
lastJoiningNode.id().equals(nodeId))
Review Comment:
> Then it fails in a later validation step
> it can send the join request again with the same node ID
> As a result, rolling upgrade can be disabled while a 2.19 node is still
joining a 2.18 cluster
It does not look like a problem - the joining node will fail validation
again and will not join the cluster.
Anyway I don't think that it is good idea to get around some specific
Discovery implementation quirks in RollingUpgradeProcessor.
--
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]
