[infinispan-dev] Embedded mode: how-to get all caches started on all nodes?

[William Burns]

On Thu, Mar 1, 2018 at 11:14 AM Thomas SEGISMONT <tsegismont at gmail.com>
wrote:

> 2018-03-01 16:36 GMT+01:00 Tristan Tarrant <ttarrant at redhat.com>:
>
>> You need to use the brand new CacheAdmin API:
>>
>>
>> http://infinispan.org/docs/stable/user_guide/user_guide.html#obtaining_caches
>
>
> I'll look into that for Vert.x 3.6 which will be based on Infinispan 9.2.
>
> Is there any way to achieve these goals with 9.1.x?
>

You could try using the ClusterExecutor to invoke getCache across all
nodes. Note it has to return null since a Cache is not Serializable.

String cacheName = ;
cache.getCacheManager().executor().submitConsumer(cm -> {
         cm.getCache(cacheName);
         return null;
      }, (a, v, t) -> {
            if (v != null) {
               System.out.println("There was an exception retrieving " +
cacheName + " from node: " + a);
            }
         }
      );


>
>
>
>>
>>
>> Tristan
>>
>> On 3/1/18 4:30 PM, Thomas SEGISMONT wrote:
>> > Hi,
>> >
>> > This email follows up on my testing of the Infinispan Cluster Manager
>> > for Vert.x on Kubernetes.
>> >
>> > In one of the tests, we want to make sure that, after a rolling update
>> > of the application, the data submitted to Vert.x' AsyncMap is still
>> > present. And I found that when the underlying cache is predefined in
>> > infinispan.xml, the data is present, otherwise it's not.
>> >
>> > I pushed a simple reproducer on GitHub:
>> > https://github.com/tsegismont/cachedataloss
>> >
>> > The code does this:
>> > - a first node is started, and creates data
>> > - new nodes are started, but they don't invoke cacheManager.getCache
>> > - the initial member is killed
>> > - a "testing" member is started, printing out the data in the console
>> >
>> > Here are my findings.
>> >
>> > 1/ Even when caches are declared in infinispan.xml, the data is lost
>> > after the initial member goes away.
>> >
>> > A little digging showed that the caches are really distributed only
>> > after you invoke cacheManager.getCache
>> >
>> > 2/ Checking cluster status "starts" triggers distribution
>> >
>> > I was wondering why the behavior was not the same as with my Vert.x
>> > testing on Openshift. And then realized the only difference was the
>> > cluster readiness check, which reads the cluster health. So I updated
>> > the reproducer code to add such a check (still without invoking
>> > cacheManager.getCache). Then the caches defined in infinispan.xml have
>> > their data distributed.
>> >
>> > So,
>> >
>> > 1/ How can I make sure caches are distributed on all nodes, even if some
>> > nodes never try to get a reference with cacheManager.getCache, or don't
>> > check cluster health?
>> > 2/ Are we doing something wrong with our way to declare the default
>> > configuration for caches [1][2]?
>> >
>> > Thanks,
>> > Thomas
>> >
>> > [1]
>> >
>> https://github.com/tsegismont/cachedataloss/blob/master/src/main/resources/infinispan.xml#L10
>> > [2]
>> >
>> https://github.com/tsegismont/cachedataloss/blob/master/src/main/resources/infinispan.xml#L22
>> >
>> > _______________________________________________
>> > infinispan-dev mailing list
>> > infinispan-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> >
>>
>> --
>> Tristan Tarrant
>> Infinispan Lead and Data Grid Architect
>> JBoss, a division of Red Hat
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20180301/b171fabf/attachment.html