7 Replies Latest reply on Aug 16, 2016 3:44 AM by Gustavo Fernandes

    Unable to get embedded infinispan to join cluster

    Wesley Hartford Newbie

      I have a small (two node) cluster of standalone infinispan nodes running in Kubernetes. Kubernetes does not allow me to take advantage of the multicast cluster discovery features, so I have a gossip router as well which provides cluster discovery. This works quite well, as soon as the infinispan nodes start up, they see each other. To build this cluster, I'm using the following docker images:

      • jboss/jgroups-gossip:latest
      • jboss/infinispan-server:8.2.3.Final-2
        • Passing the two command line arguments causes infinispan to use the gossip router:
          • -Djboss.default.jgroups.stack=tcp-gossip
          • -Djgroups.gossip.initial_hosts=gossip[12001]

       

      I've been able to use a hotrod remote client to interact with this cluster without issue. After connecting to one of the nodes, it immediately sees the other, and can interact with the default cache. As far as I can find, hotrod clients lack the ability to create new caches which has led me to a different approach.

       

      I'm now trying to have my application use an embedded infinispan to join the cluster, but I haven't been able to get that to happen after several days of frustration. The code I'm using is quite simple, I've attached the Java class, the infinispan.xml and the jgroups.xml.

       

      So I guess I have a few questions:

      • Is it a reasonable approach to have an application using embedded infinispan join a cluster of standalone instances?
      • If that is a reasonable approach, is there anything I should be doing differently to make this work?
      • Should I just be using a hotrod client? Are there any plans to allow a hotrod client to create caches with custom configurations at runtime?
      • One of the motivations in having the application join the cluster was to have any data in replicated caches local to the application, while having distributed caches reside on the cluster of dedicated instances; is there a better way to accomplish this?

       

      Thanks so much for your time.