Changing indexing to be more consistent would be a great thing to propose. Udo, would you please consider championing this issue on the dev@geode list?
Thanks, Kirk On Sun, Nov 8, 2015 at 3:15 PM, Udo Kohlmeyer <[email protected]> wrote: > @Jason/Anil, > > Why are the index creation semantics for partitioned and replicate regions > different? > > This might just be my thinking, but the implicit creation of indexes > across the cluster might fly in the face of the "shared nothing" > architecture. > > But I can understand from a usability and user experience perspective, if > I (as a user) define an index, I'd want it to be defined across all nodes. > Now, with the implicit creation of and the index on NodeB, why would the > functionality be different for Replicate regions? > > Surely consistency would be the best approach here? A user defines an > index (AX) on region (X). Which means, all nodes that contain region (X) > should contain index (AX). > > That said, I might have missed this, but are we moving towards a per > region configuration paradigm. Where we can define a region, with > indexes,cache*Adapters. All that a user has to decide, is what distributed > system the region needs to be deployed on. Which I admit will be a better > fit into a global cluster configuration. > > Kindest Regards > ----------------------------- > *Udo Kohlmeyer * | *Snr Solutions Architect * | *Pivotal* > Mobile: +61 409-279-160 | [email protected] > www.pivotal.io > On 07/11/15 17:30, agingade wrote: > > Yes...that's right... > > -------- Original message -------- > From: John Blum <[email protected]> <[email protected]> > Date: 11/06/2015 6:38 PM (GMT-08:00) > To: [email protected] > Subject: Re: Indexes with WAN replication > > Ok, 1 more scenario... > > What happens when Node A defines PR1, but does not define an Index. > > Then Node B comes online, defined PR1 and also defines an Index. I am > assuming here that Node B will exchange PR information and also send A an > index create message in this case, similar to scenario 3, but in the > opposite order? > > Thanks, > John > > > On Fri, Nov 6, 2015 at 12:26 PM, Jason Huynh <[email protected]> wrote: > >> Scenario 1: NodeA and NodeB are up and running with a Partitioned Region >> (let's call this PR1) >> Now if an index is created on PR1 on NodeA, the message will be >> distributed to NodeB. >> >> Scenario 2: Startup both nodes with index defined in cache.xml: >> Both will start and create the PR and indexes defined. Both will send a >> create message to the other, where an IndexExistsException will be logged >> on at least one side but the end result should be both have the index. >> >> Scenario 3: Startup NodeA with index defined in cache.xml and some time >> later start up NodeB >> NodeB on creation of PR1 I think we exchange information, part of this >> processing will trigger an index create message to be sent to the newly >> created member if the region created is a partitioned region. >> >> Attempting to answer your questions now: >> >> So, in my scenario, suppose the cluster with Nodes A and B are not using >> Cluster Config, but both define a PARTITION Region (X) using cache.xml >> where Node A defines Index AX. Your saying Node B will "implicitly" define >> the same Index (i.e. AX) even though it was not "explicitly" defined in >> cache.xml for Node B on PARTITION Region X? >> I think this fits into Scenario 3 >> >> What happens if Node B goes down? Where does Node B get the Index >> information for PARTITION Region X? (primary?) >> Also Scenario 3 >> >> What happens if Node A (primary for Region X) and B both define the same >> Index (X) but with different definitions? (IndexExistsException?) >> Scenario 2 >> >> On Fri, Nov 6, 2015 at 11:31 AM, John Blum < <[email protected]> >> [email protected]> wrote: >> >>> Jason, is that true even without Cluster Config? I thought this applied >>> to both REPLICATE and PARTITION Regions (well any type of Region for that >>> matter... Local-only, NORMAL, etc). >>> >>> So, in my scenario, suppose the cluster with Nodes A and B are not using >>> Cluster Config, but both define a PARTITION Region (X) using cache.xml >>> where Node A defines Index AX. Your saying Node B will "implicitly" define >>> the same Index (i.e. AX) even though it was not "explicitly" defined in >>> cache.xml for Node B on PARTITION Region X? >>> >>> What happens if Node B goes down? Where does Node B get the Index >>> information for PARTITION Region X? (primary?) >>> >>> What happens if Node A (primary for Region X) and B both define the same >>> Index (X) but with different definitions? (IndexExistsException?) >>> >>> Thanks, >>> John >>> >>> >>> >>> On Fri, Nov 6, 2015 at 10:40 AM, Jason Huynh < <[email protected]> >>> [email protected]> wrote: >>> >>>> I think what John said is true for an index on a replicated region. If >>>> the index is created on a partitioned region, it will be distributed to the >>>> other nodes. >>>> >>>> On Fri, Nov 6, 2015 at 10:28 AM, John Blum < <[email protected]> >>>> [email protected]> wrote: >>>> >>>>> I think it is also worth nothing that that behavior is the same within >>>>> the same peer/distributed system as well. If Node A and B in the same >>>>> cluster define the same Region (X), but only Node A defines Index AX, that >>>>> index will not exist in Region X on Node B.\ >>>>> >>>>> -j >>>>> >>>>> On Fri, Nov 6, 2015 at 9:55 AM, Anilkumar Gingade < >>>>> <[email protected]>[email protected]> wrote: >>>>> >>>>>> Nikhil, >>>>>> >>>>>> Indexes are on regions; they are not replicated on their own...When >>>>>> data is changed in the region; that will be applied to indexes on that >>>>>> region. >>>>>> >>>>>> -Anil. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Nov 6, 2015 at 7:23 AM, Nikhil Chandrappa < >>>>>> <[email protected]>[email protected]> wrote: >>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> I am working on configuring WAN replication between two cluster, I >>>>>>> had a question on indexes. >>>>>>> >>>>>>> Changes made to Indexes in one Gem cluster, does it get replicated >>>>>>> in remote Gem cluster? >>>>>>> >>>>>>> Thanks, >>>>>>> Nikhil >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> -John >>>>> 503-504-8657 >>>>> john.blum10101 (skype) >>>>> >>>> >>>> >>> >>> >>> -- >>> -John >>> 503-504-8657 >>> john.blum10101 (skype) >>> >> >> > > > -- > -John > 503-504-8657 > john.blum10101 (skype) > > >
