You should be able to registerInterest on a single key, a list of keys, or 
ALL_KEYS.  See this javadoc [1].

Object myKey = ...;
List myListOfKeys = ...;

region.registerInterest(myKey);
region.registerInterest(myListOfKeys);
region.registerInterest(‘ALL_KEYS’);
region.registerInterestRegex(‘.*’);

HTH,
Anthony

[1] 
https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/cache/Region.java#L1509-L1548

> On Nov 7, 2017, at 9:08 AM, Paul Perez <[email protected]> wrote:
> 
> Hello,
>  
> At Pymma, we try to design and implement a distributed messaging system for 
> OpenESB with Geode. 
> One of the key of the messaging system is a “distributed endpoint registry” 
> that contains the possible target endpoints for a service invocation. To make 
> it simpler, an endpoint registry is the list of all the service 
> implementation in the network accessible by OpenESB. 
> In a single instance mode, the endpoint registry looks like an complex 
> Hashmap that would contain collections.
> In a distributed mode, each instance of OpenESB has its own endpoint registry 
> but for obvious reasons, the registries MUST be synchronized. 
> So at the first glance, we though that a region on a server could be used as 
> an endpoint registry especialy because the registry is updated few time in 
> day when an endpoint is created deleted or updated.
> However, the registry is read by each instances each time a message is sent 
> on the bus (many thousands of times per second)
> Then, because of the last requirement, it is impossible to an OpenESB 
> instance to read a region on the server thousands of times per second, we 
> created a local region for each OpenESB instances and wanted to rely on 
> OpenESB mechanisms to synchronize the region. 
> To do it,  to do this through interest registration, but as soon as the keys 
> in the registry are not Strings anymore, it becomes less obvious to register 
> interest for all keys in the region. We think that continuous querying can 
> bypass this problem, but we are surprised it is that complicated to 
> synchronise client regions, that is likely to be a common use case. So are we 
> missing something here? Is there a more obvious way of doing this?
>  
> Thank you,
>  
> David Dumoulin and Paul Perez 
>  
> Pymma Consulting

Reply via email to