On Thu, Mar 1, 2018 at 11:21 AM William Burns <mudokonman(a)gmail.com> wrote:
On Thu, Mar 1, 2018 at 11:14 AM Thomas SEGISMONT
<tsegismont(a)gmail.com>
wrote:
> 2018-03-01 16:36 GMT+01:00 Tristan Tarrant <ttarrant(a)redhat.com>:
>
>> You need to use the brand new CacheAdmin API:
>>
>>
>>
http://infinispan.org/docs/stable/user_guide/user_guide.html#obtaining_ca...
>
>
> 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) -> {
System.out.println("There was an exception "
+ t + "
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/resource...
>> > [2]
>> >
>>
https://github.com/tsegismont/cachedataloss/blob/master/src/main/resource...
>> >
>> > _______________________________________________
>> > infinispan-dev mailing list
>> > infinispan-dev(a)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(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev