Girard, There are a few things to keep in mind if you're thinking of mixing replicated and non-replicated regions.
- there is no notion of a master or primary copy for replicated regions. All entries are treated the same in all members defining the replicated region. - the Region registerInterest API is not available between servers, just from client to server. In order to achieve a registerInterest-like behavior, you need to use normal regions (data-policy="normal") in the members you want to receive updates to only certain keys. In the members that distribute to those members, the region should be replicate (REPLICATE region shortcut) or replicate proxy (REPLICATE_PROXY region shortcut). Then in the members with normal regions, do a get on the key to start receiving updates to that key. Note that the entry has to already exist when the get is done or this won't have any effect. So, another thing you can do is to put a 'register' token (any value that can be interpreted as non-data) which creates the entry if it doesn't exist. - clients should only connect to the members defining the replicated regions and not the non-replicated ones. This means that cache servers should only be started in the members defining the replicated regions. If cache servers are started in the non-replicated members, client requests to those members will cause entries to be created in them which will cause those members to receive updates they don't want. Here is a picture that tries to show this. Sorry its not as pretty as yours. In this picture, events flow from the client to its connected cache servers. From there, specific events flow to the peers. I would say we see this architecture once in a while, but its not too common. [image: Inline image 1] Barry Oglesby GemFire Advanced Customer Engineering (ACE) For immediate support please contact Pivotal Support at http://support.pivotal.io/ On Thu, Aug 6, 2015 at 8:34 AM, Bruce Schuchardt <[email protected]> wrote: > Hi Girard, > > You can mix replicated & non-replicated though the non-replicated can't > have a "partition" data policy. I think it's most common to use data > policy "empty" or "preloaded" in members that don't use a "replicate" data > policy. > > All members have to use the same "scope", so if a member already has a > cache region with "distributed-ack" scope and another member tries to > instantiate the same region with a "global" scope it will be rejected. > > Le 8/6/2015 12:52 AM, GIRARD-REYDET Vincent a écrit : > > It’s not clear to me what the “Can be mixed with replication … some > holding non-replicas” part means exactly. I understand that you can mix > replication and non-replication, but I’m not sure if it’s in the same > region (on different servers) or not. > > > > In other words, if I go for “Replicated (distributed)”, do I have to use > it on all members defining this region, with the same distribution mode? Or > can I have, for a region A, some members using Replicated (distributed) = > always storing all values, and some other members using Distributed > non-replicated = only getting the data they are interested to? See picture > attached for an example : can member M3 define region A with only a > “register interest” (this would be weird) ? > > >
