2 Replies Latest reply on Jul 6, 2012 5:47 AM by dan.berindei

    Problems to form a cluster

    dudalov

      I have problems to form a cluster when I run Java application on two boxes. The nodes see each other and JGroups tries to build a cluster but something goes wrong. I see messages

         "not member of view ..... discarding it" on one box (Sound), and

         "sender not in table"  - on another box (dmitry-13dcf93a)

       

      I verified that the boxes passed included into jgroups-3.0.6.Final.jar tests: McastReceiverTest/McastSenderTest. The tests worked fine with and without the property -Djava.net.preferIPv4Stack=true. Running two instances of that application on the same box works fine as well. For all these cases I use the same (default) configuration with jgroups UDP. Please see the attached files:

        - infinispan-cache.xml - Infinispan config-file for which JGroups configuration file is resolved to the infinispan-jgroups.xml

        - infinispan-jgroups.xml is default UDP configuration that comes with infinispan-5.1.2

        

      The configuration where it doesn't work:

      To build a cluster I start a node on a box called Sound, which is Windows 7 (64 bit)

      and then I start the second node on VM dmitry-13dcf93a that runs Windows XP inside VMware workstation on the same box Sound. VM network adapter is Bridged.

      The log-files named correspondently. Tests were performed with the following log settings

      log4j.logger.org.jboss=INFO

      log4j.logger.org.infinispan=TRACE

      log4j.logger.org.jgroups=INFO

      log4j.logger.org.jgroups.protocol=TRACE

       

      The application does very basic. It creates a manager using configuration files and tries to use replicated cache.

       

      _manager = new DefaultCacheManager(infinispanConfig, false);

      _manager.getGlobalConfiguration().getTransportProperties().setProperty("configurationFile", jgroupsConfig);

      _manager.start();

       

      Configuration defaultCacheConfig = _manager.getDefaultCacheConfiguration();

      Configuration config = new ConfigurationBuilder().read(defaultCacheConfig)

          .eviction().maxEntries(cacheSize)

          .build();

      _manager.defineConfiguration(cacheName, config);   

      _manager.getCache(cacheName);

       

       

      So I'm afraid the problem is related to the configuration of boxes where I ran the tests. How can I tell if these boxes miss some requirements? The tests were executed with -Djava.net.preferIPv4Stack=true.  Anything else to try?

        • 1. Re: Problems to form a cluster
          dudalov

          Switching to jgroups-tcp.xml resolved the issue. With TCP almost configuration the cluster was formed despite some scary looking warnings in the beginning. So the boxes seem to have acceptable configuration and the problem might be specific to UDP.

          • 2. Re: Problems to form a cluster
            dan.berindei

            Dmitry, sorry for the delay.

             

            I think you had a missing 's' in your log4j configuration (org.jgroups.protocols), I don't see messages from any protocol like UDP.

             

            From what I've seen the dmitry-13dcf93a node keeps suspecting the Sound node, installing a new view by itself, then merging back in the same view, over and over again. The question is why does dmitry-13dcf93a suspect the other node in the first place, and we'd need the FD_SOCK/FD_ALL logs to find the answer.