How to get Ignite to act without blocking with TcpDiscoveryVmIpFinder, as it does with TcpDiscoveryMulticastIpFinder?

Question

Background

• I have a web application, spring.
• locally on the dev machine I have 2 tomcat instances that run the same application - this way I test how the nodes of the web farm interact with each other.
• I use the Jelastic cloud to deploy applications.
• In Jelastic, it does not work as a web farm, but it uses the role update mechanism (while AppV1working in NodeAand processes user requests, I start AppV2@NodeB, warm up and redirect user requests to it. The goal is to NodeBcopy all sessions from NodeA)

Intention

• The current release version uses a third NodeJS-based server as a shortcut for the MessageBus between nodes. But I recently noticed Ignite and thought it would be great to reduce the number of platforms (nodejs) and get only everything in Java.
• So I replaced NodeJS based messaging with Ignite messaging. Ignite is initialized using Spring's XML configuration andorg.apache.ignite.IgniteSpringBean
• When running my application locally with, TcpDiscoveryMulticastIpFinderit works fine. NodeAstarts even if not NodeB. When I start NodeB, it smoothly joins the cluster, and the nodes connect to each other and interact perfectly. The most important thing here is that I can start and stop nodes at any time, and I have non-blocking error-free operation using Ignite messaging.

Question

• Jelastic , IP- ( TcpDiscoveryVmIpFinder), - node. , NodeA , NodeB. NodeB ( ).

• TcpDiscoveryVmIpFinder
• NodeA ( NodeB )
• : NodeA (, , - )
• NodeB
• : NodeA NodeB ( ).
• NodeA
• : NodeB
• : NodeA NodeB ; 3

Answer 1

, , TcpDiscoveryVmIpFinder. A B IP- IP. readme [1]. , , node A , node B .

IP- , .

                <bean class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
                    <property name="addresses">
                        <list>
                            <value>hodeA_ip_address_or_host_name:47500..47509</value>
                            <value>hodeB_ip_address_or_host_name:47500..47509</value>
                        </list>
                    </property>
                </bean>

[1] https://apacheignite.readme.io/docs/cluster-config#static-ip-based-discovery

Answer 2

, Tomcat Jelastic Cloud. , . , .

Answer 3

( ). - , .

TcpDiscoverySpi resolvedAddresses(), , .

This solution is not ideal, because now, if NodeAnot found NodeB, he will never try to find NodeB. However, this is not a showstopper, because from the beginning NodeBhe reaches NodeA, and they begin to talk to each other. Therefore, an effective Rolling Updates mechanism works for me.

The method isCandidateRespondis a quick-resolving solution and, most likely, will vary depending on the specific case.

Here is the code snippet:

public class TcpDiscoverySpiPrecheckingImpl extends TcpDiscoverySpi {
    private Logger log = Logger.getLogger(getClass());

    @Override
    protected Collection<InetSocketAddress> resolvedAddresses() throws IgniteSpiException {
        Collection<InetSocketAddress> candidates = super.resolvedAddresses();
        Collection<InetSocketAddress> approved = new ArrayList<>();
        for (InetSocketAddress candidate : candidates) {
            if (isCandidateRespond(candidate)) {
                approved.add(candidate);
            }
        }
        return approved;
    }

    private boolean isCandidateRespond(InetSocketAddress candidate) {
        if (log.isTraceEnabled()) {
            log.trace("Checking if remote node responds: " + candidate);
        }
        URL url = null;
        try {
            url = new URL("http://" + candidate.getHostName() + "/");
            try (InputStream stream = url.openStream()) {
                return true;
            }
        } catch (Throwable t) {
            log.info("Candidate remote node didn't respond: " + url + ". Reason: " + t.getMessage());
            return false;
        }
    }
}