Yes! The generic type parameters are incorrect on this API. There’s already a JIRA for this:
https://issues.apache.org/jira/browse/GEODE-3813 In the meantime you can avoid the compile error by removing the type parameters from the Region reference :( Anthony > On Nov 7, 2017, at 10:14 AM, Paul Perez <[email protected]> wrote: > > Hello Antony, > > Thank you for your prompt answer. > Yes, what you write is true but only if we don’t give a type to the key or we > give the type “String” to our key. > > But for a region Region <MyKey, MyValue>, it does not work because you > cannot invoke the method Region.registerInterest (‘ALL_KEYS’). > At the compilation you get an error since ‘ALL_KEYS’ is not an instance of > MyKey but a String. > > We Think it would be easier to create a new method in the interface Region > such as Region.registerInterestAllKeys () ; > > Could we do a feature request to solve this topic? > > Best regards > > David and Paul > > <>From: Anthony Baker [mailto:[email protected]] > Sent: 07 November 2017 17:46 > To: [email protected]; [email protected] > Subject: Re: Region registerInterest (K key) > > 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 > > <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] >> <mailto:[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
