[ 
https://issues.apache.org/jira/browse/IGNITE-4111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16715144#comment-16715144
 ] 

Alexei Scherbakov commented on IGNITE-4111:
-------------------------------------------

This fails in master with NPE:
{noformat}
package org.apache.ignite.internal.processors.cache;

import org.apache.ignite.cache.affinity.rendezvous.RendezvousAffinityFunction;
import org.apache.ignite.configuration.CacheConfiguration;
import org.apache.ignite.configuration.IgniteConfiguration;
import org.apache.ignite.failure.StopNodeFailureHandler;
import org.apache.ignite.internal.IgniteEx;
import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;

import static org.apache.ignite.cache.CacheAtomicityMode.TRANSACTIONAL;
import static org.apache.ignite.cache.CacheWriteSynchronizationMode.FULL_SYNC;

/**
 */
public class ClientReconnectSelfTest extends GridCommonAbstractTest {
    /** IP finder. */
    private static final TcpDiscoveryVmIpFinder IP_FINDER = new 
TcpDiscoveryVmIpFinder(true);

    /** {@inheritDoc} */
    @Override protected IgniteConfiguration getConfiguration(String 
igniteInstanceName) throws Exception {
        IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);

        cfg.setConsistentId("node" + igniteInstanceName);
        cfg.setFailureHandler(new StopNodeFailureHandler());

        ((TcpDiscoverySpi)cfg.getDiscoverySpi()).setIpFinder(IP_FINDER);

        boolean client = igniteInstanceName.startsWith("client");

        cfg.setClientMode(client);

        if (!client) {
            CacheConfiguration ccfg = new 
CacheConfiguration(DEFAULT_CACHE_NAME);

            ccfg.setAtomicityMode(TRANSACTIONAL);
            ccfg.setBackups(1);
            ccfg.setWriteSynchronizationMode(FULL_SYNC);
            ccfg.setOnheapCacheEnabled(false);
            ccfg.setAffinity(new RendezvousAffinityFunction(false, 32));

            cfg.setCacheConfiguration(ccfg);
        }

        return cfg;
    }

    /** */
    public void testReconnect() throws Exception {
        try {
            IgniteEx crd = (IgniteEx)startGridsMultiThreaded(1);

            IgniteEx client = startGrid("client");

            stopGrid(0);

            crd = startGrid(0);
            crd.cluster().active(true);

            awaitPartitionMapExchange();
        }
        finally {
            stopAllGrids();
        }
    }
}
{noformat}

> Communication fails to send message if target node did not finish join process
> ------------------------------------------------------------------------------
>
>                 Key: IGNITE-4111
>                 URL: https://issues.apache.org/jira/browse/IGNITE-4111
>             Project: Ignite
>          Issue Type: Bug
>          Components: general
>            Reporter: Semen Boikov
>            Assignee: Amelchev Nikita
>            Priority: Minor
>             Fix For: 2.8
>
>         Attachments: test onFirstMessage hang.log
>
>
> Currently this scenario is possible:
> - joining node sent join request and waits for 
> TcpDiscoveryNodeAddFinishedMessage inside ServerImpl.joinTopology
> - others nodes already see this node and can send messages to it (for example 
> try to run compute job on this node)
> - joining node can not receive message: TcpCommunicationSpi will hang inside 
> 'onFirstMessage' on 'getSpiContext' call, so sending node will get error 
> trying to establish connection
> Possible fix: if in onFirstMessage() spi context is not available, then 
> TcpCommunicationSpi  should send special response which indicates that this 
> node is not ready yet, and sender should retry after some time.
> Also need check internal code for places where message can be unnecessarily 
> sent to node: one such place is 
> GridCachePartitionExchangeManager.refreshPartitions - message is sent to all 
> known nodes, but here we can filter by node order / finished exchage version.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to