You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Jinmei Liao <ji...@pivotal.io> on 2018/04/19 21:58:20 UTC
[Proposal]: behavior change when region doesn't exist in cluster configuration
Scenario:
a locator with cluster configuration enabled and a server started with a
cache.xml that has /regionA defined and connected to this locator. So the
initial state is the locator has an empty cluster configuration for the
cluster, but the server has a region defined in it's cache.
Old behavior:
when user execute "create index --region=/regionA ...." command using gfsh,
the index creation is successful on the server, and the server returns a
xml section that contains both <region> and <index> elements, CC is updated
with this xml, so the end result is: both region and index end up in the
cluster configuration.
Problem with old behavior:
Not sure if the region is a cluster wide configuration. What if a region
with the same name, but different type exists on different servers? the xml
returned by different server might be different.
New behavior:
when user execute "create index --region=/regionA ...." command using gfsh,
the index creation is successful on the server. We failed to find the
region in the existing cluster configuration, so cluster configuration will
NOT be updated.
I would also suggest that this would not apply to index alone, any element
inside region would have the same behavior change if we approve this.
Thanks!
--
Cheers
Jinmei
Re: [Proposal]: behavior change when region doesn't exist in cluster configuration
Posted by Jinmei Liao <ji...@pivotal.io>.
Hi, John, I was also surprised with the old behavior. I believe it's a bug
that just accidentally served as a "feature".
On Fri, Apr 27, 2018 at 3:42 PM, John Blum <jb...@pivotal.io> wrote:
> Hi Jinmei-
>
> Regarding this...
>
> "
>
> *So the current behavior is, when a customer starts a server with
> cache.xmlthat has a region defined, and then later on issues a gfsh command
> `createindex` on that region, the command output would be something like:*
>
>
>
>
>
>
>
>
> *>create index .....Member |
> Status----------------------------server-1 | Index successfully
> created.Cluster configuration for "cluster" is not updatedRegion XYZ does
> not exist in the cluster configuration (or something tothis effect).*"
>
> I don't think the Cluster Config should be updated in this case (which I
> guess is consistent with the new behavior, which I thought was also the old
> behavior, but anyway...)
>
> cache.xml, like *Spring* config, like using the Geode public API to
> configure/change (e.g. using *AttributesMutator* to add a custom/node
> specific *CacheListener/Loader* or *Writer*, perhaps) the node's
> configuration is an "augmenting" behavior.
>
> Also, a Region's "configuration", whether that be the DataPolicy or several
> other factors, cannot differ between different nodes in the cluster also
> hosting the same Region, by "name", (especially if that is a PARTITION
> Region.
>
> -j
>
>
>
> On Fri, Apr 27, 2018 at 3:40 PM, Jason Huynh <jh...@pivotal.io> wrote:
>
> > *correction to my last email, I was using java api and not cache.xml
> >
> > On Fri, Apr 27, 2018 at 3:40 PM Jason Huynh <jh...@pivotal.io> wrote:
> >
> > > Hi Jinmei and Naba,
> > >
> > > I don't think you can define two regions with the same name and
> different
> > > types. We would throw an IllegalStateException for the node that tried
> > to
> > > create the region second. At least that was the behavior I was seeing
> > when
> > > I tried to create a replicate region and a partitioned region with the
> > same
> > > name (admittedly using the java api and not cluster config). So then
> if
> > > you run a gfsh command to create an index, it would only create the
> index
> > > on the first node and report back to cluster config the first nodes
> > > configuration and the new index.
> > >
> > > Going back to the original proposal, if the user ever wanted to have
> the
> > > cluster config updated with the region, how would they sync up their
> > > cluster config without bringing everything down? Sure they can export
> > xml
> > > and bring up another server with xml but that doesn't get them migrated
> > to
> > > cluster config...
> > >
> > >
> > >
> > > On Fri, Apr 27, 2018 at 2:48 PM Jinmei Liao <ji...@pivotal.io> wrote:
> > >
> > >> Hi, Naba, I believe this is possible even before, with or without
> using
> > >> cluster configuration. That's why we have to say stuff defined using
> > >> cache.xml is not mean to be a cluster wide configuration.
> > >>
> > >> On Fri, Apr 27, 2018 at 2:40 PM, Nabarun Nag <nn...@apache.org> wrote:
> > >>
> > >> > With the new implementation, will it allow two different regions
> with
> > >> the
> > >> > same exact name to exist in the cluster ?
> > >> >
> > >> > I meant like server A had a cache.xml with region “test” with
> > different
> > >> > properties as to the cache.xml in server B for region “test”. And
> the
> > >> > locator had an empty cluster config.
> > >> >
> > >> > So now when servers A and B start, they will have different regions
> > but
> > >> the
> > >> > same name “test”. Because there is no sync up with locator’s cluster
> > >> > config.
> > >> >
> > >> > Pardon me if my understanding is wrong.
> > >> >
> > >> >
> > >> > Regards
> > >> > Nabarun
> > >> >
> > >> >
> > >> > On Fri, Apr 27, 2018 at 2:23 PM Jinmei Liao <ji...@pivotal.io>
> > wrote:
> > >> >
> > >> > > My point is: we can't keep "mending" the wrong behavior, otherwise
> > we
> > >> can
> > >> > > not move forward.
> > >> > >
> > >> > > On Fri, Apr 27, 2018 at 2:22 PM, Jinmei Liao <ji...@pivotal.io>
> > >> wrote:
> > >> > >
> > >> > > > So the current behavior is, when a customer starts a server with
> > >> > > cache.xml
> > >> > > > that has a region defined, and then later on issues a gfsh
> command
> > >> > > `create
> > >> > > > index` on that region, the command output would be something
> like:
> > >> > > > >create index .....
> > >> > > > Member | Status
> > >> > > > ----------------------------
> > >> > > > server-1 | Index successfully created.
> > >> > > >
> > >> > > > Cluster configuration for "cluster" is not updated
> > >> > > > Region XYZ does not exist in the cluster configuration (or
> > >> something to
> > >> > > > this effect).
> > >> > > >
> > >> > > > The command result would tell user exactly what happened and
> what
> > >> not
> > >> > > > happened. The point is, a server's own cache.xml is NOT meant to
> > be
> > >> a
> > >> > > > "cluster" wide configuration. If customer is in the habit of
> > >> starting
> > >> > up
> > >> > > > server with cache.xml but yet still want to have consistent
> > >> > region/index
> > >> > > > defined in the cluster, export a server's config and use that to
> > >> start
> > >> > > > another server.
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > On Fri, Apr 27, 2018 at 2:03 PM, Diane Hardman <
> > dhardman@pivotal.io
> > >> >
> > >> > > > wrote:
> > >> > > >
> > >> > > >> I talked with Barbara and understand the long term effort to
> > >> deprecate
> > >> > > >> cache.xml in favor of cluster config and I heartily agree.
> > >> > > >> I think a good step in that direction is to provide a migration
> > >> tool
> > >> > for
> > >> > > >> users that reads all cache.xml files for current members and
> > store
> > >> > them
> > >> > > in
> > >> > > >> cluster config, throwing exceptions and logging errors when
> > region
> > >> > > >> definitions conflict (for the same region name) on different
> > >> servers
> > >> > in
> > >> > > >> the
> > >> > > >> same cluster.
> > >> > > >> We might then consider removing the cache.xml files and rely on
> > >> gfsh
> > >> > and
> > >> > > >> (in the future, hopefully) Java API's to keep cluster config
> > >> > up-to-date.
> > >> > > >>
> > >> > > >> Thanks!
> > >> > > >>
> > >> > > >> On Fri, Apr 27, 2018 at 12:56 PM, Jinmei Liao <
> jiliao@pivotal.io
> > >
> > >> > > wrote:
> > >> > > >>
> > >> > > >> > The decision is to go with the new behavior (I believe :-)).
> > The
> > >> > > region
> > >> > > >> > does not exist in the cluster configuration to begin with
> since
> > >> it's
> > >> > > not
> > >> > > >> > created using gfsh, so we have no way of checking unless we
> > make
> > >> an
> > >> > > >> extra
> > >> > > >> > trip to the region to find out what kind of region it is, but
> > >> again
> > >> > > >> > different server might have different opinion about what it
> is.
> > >> > > >> >
> > >> > > >> > On Fri, Apr 27, 2018 at 12:49 PM, Diane Hardman <
> > >> > dhardman@pivotal.io>
> > >> > > >> > wrote:
> > >> > > >> >
> > >> > > >> > > Since we are working on enhancing Lucene support to allow
> > >> adding a
> > >> > > >> Lucene
> > >> > > >> > > index to an existing region containing data, I am very
> > >> interested
> > >> > in
> > >> > > >> the
> > >> > > >> > > decision here.
> > >> > > >> > > Like Mike, I also prefer keeping the original behavior of
> > >> updating
> > >> > > >> > cluster
> > >> > > >> > > config with both the region and the index if it was not
> there
> > >> > > before.
> > >> > > >> > > Is there something preventing you from checking cluster
> > config
> > >> > for a
> > >> > > >> > region
> > >> > > >> > > of the same name but different properties and, if so,
> > throwing
> > >> an
> > >> > > >> > exception
> > >> > > >> > > (or warning)
> > >> > > >> > > that cluster config could not be updated due to this
> > collision?
> > >> > > >> > >
> > >> > > >> > > On Thu, Apr 19, 2018 at 3:35 PM, Michael Stolz <
> > >> mstolz@pivotal.io
> > >> > >
> > >> > > >> > wrote:
> > >> > > >> > >
> > >> > > >> > > > Ok. Yes we do have to take the leap :)
> > >> > > >> > > > Let's keep thinking that way.
> > >> > > >> > > >
> > >> > > >> > > > --
> > >> > > >> > > > Mike Stolz
> > >> > > >> > > > Principal Engineer, GemFire Product Lead
> > >> > > >> > > > Mobile: +1-631-835-4771 <(631)%20835-4771>
> > >> > > >> > > > Download the GemFire book here.
> > >> > > >> > > > <https://content.pivotal.io/
> ebooks/scaling-data-services-
> > >> > > >> > > > with-pivotal-gemfire>
> > >> > > >> > > >
> > >> > > >> > > > On Thu, Apr 19, 2018 at 6:29 PM, Jinmei Liao <
> > >> jiliao@pivotal.io
> > >> > >
> > >> > > >> > wrote:
> > >> > > >> > > >
> > >> > > >> > > > > but this proposed change is one of the effort toward
> > >> > > "deprecating
> > >> > > >> > > > > cache.xml". I think we've got to take the leap at one
> > >> > point.....
> > >> > > >> > > > >
> > >> > > >> > > > > On Thu, Apr 19, 2018 at 3:14 PM, Michael Stolz <
> > >> > > mstolz@pivotal.io
> > >> > > >> >
> > >> > > >> > > > wrote:
> > >> > > >> > > > >
> > >> > > >> > > > > > Hmmm...I think I liked the old behavior better. It
> was
> > a
> > >> > kind
> > >> > > of
> > >> > > >> > > bridge
> > >> > > >> > > > > to
> > >> > > >> > > > > > cluster config.
> > >> > > >> > > > > >
> > >> > > >> > > > > > I still think we need to be putting much more effort
> > into
> > >> > > >> > deprecating
> > >> > > >> > > > > > cache.xml and much less effort into fixing the
> > (possibly)
> > >> > > >> hundreds
> > >> > > >> > of
> > >> > > >> > > > > bugs
> > >> > > >> > > > > > related to using both cache.xml and cluster
> > >> configuration at
> > >> > > the
> > >> > > >> > same
> > >> > > >> > > > > time.
> > >> > > >> > > > > > If we can make cluster config complete enough, and
> > >> deprecate
> > >> > > >> > > cache.xml,
> > >> > > >> > > > > > people will stop using cache.xml.
> > >> > > >> > > > > >
> > >> > > >> > > > > >
> > >> > > >> > > > > >
> > >> > > >> > > > > > --
> > >> > > >> > > > > > Mike Stolz
> > >> > > >> > > > > > Principal Engineer, GemFire Product Lead
> > >> > > >> > > > > > Mobile: +1-631-835-4771 <(631)%20835-4771>
> > >> > > >> > > > > > Download the GemFire book here.
> > >> > > >> > > > > > <
> > >> https://content.pivotal.io/ebooks/scaling-data-services-
> > >> > > >> > > > > > with-pivotal-gemfire>
> > >> > > >> > > > > >
> > >> > > >> > > > > > On Thu, Apr 19, 2018 at 5:58 PM, Jinmei Liao <
> > >> > > jiliao@pivotal.io
> > >> > > >> >
> > >> > > >> > > > wrote:
> > >> > > >> > > > > >
> > >> > > >> > > > > > > Scenario:
> > >> > > >> > > > > > > a locator with cluster configuration enabled and a
> > >> server
> > >> > > >> started
> > >> > > >> > > > with
> > >> > > >> > > > > a
> > >> > > >> > > > > > > cache.xml that has /regionA defined and connected
> to
> > >> this
> > >> > > >> > locator.
> > >> > > >> > > So
> > >> > > >> > > > > the
> > >> > > >> > > > > > > initial state is the locator has an empty cluster
> > >> > > >> configuration
> > >> > > >> > for
> > >> > > >> > > > the
> > >> > > >> > > > > > > cluster, but the server has a region defined in
> it's
> > >> > cache.
> > >> > > >> > > > > > >
> > >> > > >> > > > > > > Old behavior:
> > >> > > >> > > > > > > when user execute "create index --region=/regionA
> > ...."
> > >> > > >> command
> > >> > > >> > > using
> > >> > > >> > > > > > gfsh,
> > >> > > >> > > > > > > the index creation is successful on the server, and
> > the
> > >> > > server
> > >> > > >> > > > returns
> > >> > > >> > > > > a
> > >> > > >> > > > > > > xml section that contains both <region> and <index>
> > >> > > elements,
> > >> > > >> CC
> > >> > > >> > is
> > >> > > >> > > > > > updated
> > >> > > >> > > > > > > with this xml, so the end result is: both region
> and
> > >> index
> > >> > > >> end up
> > >> > > >> > > in
> > >> > > >> > > > > the
> > >> > > >> > > > > > > cluster configuration.
> > >> > > >> > > > > > >
> > >> > > >> > > > > > > Problem with old behavior:
> > >> > > >> > > > > > > Not sure if the region is a cluster wide
> > configuration.
> > >> > What
> > >> > > >> if a
> > >> > > >> > > > > region
> > >> > > >> > > > > > > with the same name, but different type exists on
> > >> different
> > >> > > >> > servers?
> > >> > > >> > > > the
> > >> > > >> > > > > > xml
> > >> > > >> > > > > > > returned by different server might be different.
> > >> > > >> > > > > > >
> > >> > > >> > > > > > > New behavior:
> > >> > > >> > > > > > > when user execute "create index --region=/regionA
> > ...."
> > >> > > >> command
> > >> > > >> > > using
> > >> > > >> > > > > > gfsh,
> > >> > > >> > > > > > > the index creation is successful on the server. We
> > >> failed
> > >> > to
> > >> > > >> find
> > >> > > >> > > the
> > >> > > >> > > > > > > region in the existing cluster configuration, so
> > >> cluster
> > >> > > >> > > > configuration
> > >> > > >> > > > > > will
> > >> > > >> > > > > > > NOT be updated.
> > >> > > >> > > > > > >
> > >> > > >> > > > > > > I would also suggest that this would not apply to
> > index
> > >> > > alone,
> > >> > > >> > any
> > >> > > >> > > > > > element
> > >> > > >> > > > > > > inside region would have the same behavior change
> if
> > we
> > >> > > >> approve
> > >> > > >> > > this.
> > >> > > >> > > > > > >
> > >> > > >> > > > > > > Thanks!
> > >> > > >> > > > > > >
> > >> > > >> > > > > > > --
> > >> > > >> > > > > > > Cheers
> > >> > > >> > > > > > >
> > >> > > >> > > > > > > Jinmei
> > >> > > >> > > > > > >
> > >> > > >> > > > > >
> > >> > > >> > > > >
> > >> > > >> > > > >
> > >> > > >> > > > >
> > >> > > >> > > > > --
> > >> > > >> > > > > Cheers
> > >> > > >> > > > >
> > >> > > >> > > > > Jinmei
> > >> > > >> > > > >
> > >> > > >> > > >
> > >> > > >> > >
> > >> > > >> >
> > >> > > >> >
> > >> > > >> >
> > >> > > >> > --
> > >> > > >> > Cheers
> > >> > > >> >
> > >> > > >> > Jinmei
> > >> > > >> >
> > >> > > >>
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > --
> > >> > > > Cheers
> > >> > > >
> > >> > > > Jinmei
> > >> > > >
> > >> > >
> > >> > >
> > >> > >
> > >> > > --
> > >> > > Cheers
> > >> > >
> > >> > > Jinmei
> > >> > >
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> Cheers
> > >>
> > >> Jinmei
> > >>
> > >
> >
>
>
>
> --
> -John
> john.blum10101 (skype)
>
--
Cheers
Jinmei
Re: [Proposal]: behavior change when region doesn't exist in cluster configuration
Posted by John Blum <jb...@pivotal.io>.
Hi Jinmei-
Regarding this...
"
*So the current behavior is, when a customer starts a server with
cache.xmlthat has a region defined, and then later on issues a gfsh command
`createindex` on that region, the command output would be something like:*
*>create index .....Member |
Status----------------------------server-1 | Index successfully
created.Cluster configuration for "cluster" is not updatedRegion XYZ does
not exist in the cluster configuration (or something tothis effect).*"
I don't think the Cluster Config should be updated in this case (which I
guess is consistent with the new behavior, which I thought was also the old
behavior, but anyway...)
cache.xml, like *Spring* config, like using the Geode public API to
configure/change (e.g. using *AttributesMutator* to add a custom/node
specific *CacheListener/Loader* or *Writer*, perhaps) the node's
configuration is an "augmenting" behavior.
Also, a Region's "configuration", whether that be the DataPolicy or several
other factors, cannot differ between different nodes in the cluster also
hosting the same Region, by "name", (especially if that is a PARTITION
Region.
-j
On Fri, Apr 27, 2018 at 3:40 PM, Jason Huynh <jh...@pivotal.io> wrote:
> *correction to my last email, I was using java api and not cache.xml
>
> On Fri, Apr 27, 2018 at 3:40 PM Jason Huynh <jh...@pivotal.io> wrote:
>
> > Hi Jinmei and Naba,
> >
> > I don't think you can define two regions with the same name and different
> > types. We would throw an IllegalStateException for the node that tried
> to
> > create the region second. At least that was the behavior I was seeing
> when
> > I tried to create a replicate region and a partitioned region with the
> same
> > name (admittedly using the java api and not cluster config). So then if
> > you run a gfsh command to create an index, it would only create the index
> > on the first node and report back to cluster config the first nodes
> > configuration and the new index.
> >
> > Going back to the original proposal, if the user ever wanted to have the
> > cluster config updated with the region, how would they sync up their
> > cluster config without bringing everything down? Sure they can export
> xml
> > and bring up another server with xml but that doesn't get them migrated
> to
> > cluster config...
> >
> >
> >
> > On Fri, Apr 27, 2018 at 2:48 PM Jinmei Liao <ji...@pivotal.io> wrote:
> >
> >> Hi, Naba, I believe this is possible even before, with or without using
> >> cluster configuration. That's why we have to say stuff defined using
> >> cache.xml is not mean to be a cluster wide configuration.
> >>
> >> On Fri, Apr 27, 2018 at 2:40 PM, Nabarun Nag <nn...@apache.org> wrote:
> >>
> >> > With the new implementation, will it allow two different regions with
> >> the
> >> > same exact name to exist in the cluster ?
> >> >
> >> > I meant like server A had a cache.xml with region “test” with
> different
> >> > properties as to the cache.xml in server B for region “test”. And the
> >> > locator had an empty cluster config.
> >> >
> >> > So now when servers A and B start, they will have different regions
> but
> >> the
> >> > same name “test”. Because there is no sync up with locator’s cluster
> >> > config.
> >> >
> >> > Pardon me if my understanding is wrong.
> >> >
> >> >
> >> > Regards
> >> > Nabarun
> >> >
> >> >
> >> > On Fri, Apr 27, 2018 at 2:23 PM Jinmei Liao <ji...@pivotal.io>
> wrote:
> >> >
> >> > > My point is: we can't keep "mending" the wrong behavior, otherwise
> we
> >> can
> >> > > not move forward.
> >> > >
> >> > > On Fri, Apr 27, 2018 at 2:22 PM, Jinmei Liao <ji...@pivotal.io>
> >> wrote:
> >> > >
> >> > > > So the current behavior is, when a customer starts a server with
> >> > > cache.xml
> >> > > > that has a region defined, and then later on issues a gfsh command
> >> > > `create
> >> > > > index` on that region, the command output would be something like:
> >> > > > >create index .....
> >> > > > Member | Status
> >> > > > ----------------------------
> >> > > > server-1 | Index successfully created.
> >> > > >
> >> > > > Cluster configuration for "cluster" is not updated
> >> > > > Region XYZ does not exist in the cluster configuration (or
> >> something to
> >> > > > this effect).
> >> > > >
> >> > > > The command result would tell user exactly what happened and what
> >> not
> >> > > > happened. The point is, a server's own cache.xml is NOT meant to
> be
> >> a
> >> > > > "cluster" wide configuration. If customer is in the habit of
> >> starting
> >> > up
> >> > > > server with cache.xml but yet still want to have consistent
> >> > region/index
> >> > > > defined in the cluster, export a server's config and use that to
> >> start
> >> > > > another server.
> >> > > >
> >> > > >
> >> > > >
> >> > > > On Fri, Apr 27, 2018 at 2:03 PM, Diane Hardman <
> dhardman@pivotal.io
> >> >
> >> > > > wrote:
> >> > > >
> >> > > >> I talked with Barbara and understand the long term effort to
> >> deprecate
> >> > > >> cache.xml in favor of cluster config and I heartily agree.
> >> > > >> I think a good step in that direction is to provide a migration
> >> tool
> >> > for
> >> > > >> users that reads all cache.xml files for current members and
> store
> >> > them
> >> > > in
> >> > > >> cluster config, throwing exceptions and logging errors when
> region
> >> > > >> definitions conflict (for the same region name) on different
> >> servers
> >> > in
> >> > > >> the
> >> > > >> same cluster.
> >> > > >> We might then consider removing the cache.xml files and rely on
> >> gfsh
> >> > and
> >> > > >> (in the future, hopefully) Java API's to keep cluster config
> >> > up-to-date.
> >> > > >>
> >> > > >> Thanks!
> >> > > >>
> >> > > >> On Fri, Apr 27, 2018 at 12:56 PM, Jinmei Liao <jiliao@pivotal.io
> >
> >> > > wrote:
> >> > > >>
> >> > > >> > The decision is to go with the new behavior (I believe :-)).
> The
> >> > > region
> >> > > >> > does not exist in the cluster configuration to begin with since
> >> it's
> >> > > not
> >> > > >> > created using gfsh, so we have no way of checking unless we
> make
> >> an
> >> > > >> extra
> >> > > >> > trip to the region to find out what kind of region it is, but
> >> again
> >> > > >> > different server might have different opinion about what it is.
> >> > > >> >
> >> > > >> > On Fri, Apr 27, 2018 at 12:49 PM, Diane Hardman <
> >> > dhardman@pivotal.io>
> >> > > >> > wrote:
> >> > > >> >
> >> > > >> > > Since we are working on enhancing Lucene support to allow
> >> adding a
> >> > > >> Lucene
> >> > > >> > > index to an existing region containing data, I am very
> >> interested
> >> > in
> >> > > >> the
> >> > > >> > > decision here.
> >> > > >> > > Like Mike, I also prefer keeping the original behavior of
> >> updating
> >> > > >> > cluster
> >> > > >> > > config with both the region and the index if it was not there
> >> > > before.
> >> > > >> > > Is there something preventing you from checking cluster
> config
> >> > for a
> >> > > >> > region
> >> > > >> > > of the same name but different properties and, if so,
> throwing
> >> an
> >> > > >> > exception
> >> > > >> > > (or warning)
> >> > > >> > > that cluster config could not be updated due to this
> collision?
> >> > > >> > >
> >> > > >> > > On Thu, Apr 19, 2018 at 3:35 PM, Michael Stolz <
> >> mstolz@pivotal.io
> >> > >
> >> > > >> > wrote:
> >> > > >> > >
> >> > > >> > > > Ok. Yes we do have to take the leap :)
> >> > > >> > > > Let's keep thinking that way.
> >> > > >> > > >
> >> > > >> > > > --
> >> > > >> > > > Mike Stolz
> >> > > >> > > > Principal Engineer, GemFire Product Lead
> >> > > >> > > > Mobile: +1-631-835-4771 <(631)%20835-4771>
> >> > > >> > > > Download the GemFire book here.
> >> > > >> > > > <https://content.pivotal.io/ebooks/scaling-data-services-
> >> > > >> > > > with-pivotal-gemfire>
> >> > > >> > > >
> >> > > >> > > > On Thu, Apr 19, 2018 at 6:29 PM, Jinmei Liao <
> >> jiliao@pivotal.io
> >> > >
> >> > > >> > wrote:
> >> > > >> > > >
> >> > > >> > > > > but this proposed change is one of the effort toward
> >> > > "deprecating
> >> > > >> > > > > cache.xml". I think we've got to take the leap at one
> >> > point.....
> >> > > >> > > > >
> >> > > >> > > > > On Thu, Apr 19, 2018 at 3:14 PM, Michael Stolz <
> >> > > mstolz@pivotal.io
> >> > > >> >
> >> > > >> > > > wrote:
> >> > > >> > > > >
> >> > > >> > > > > > Hmmm...I think I liked the old behavior better. It was
> a
> >> > kind
> >> > > of
> >> > > >> > > bridge
> >> > > >> > > > > to
> >> > > >> > > > > > cluster config.
> >> > > >> > > > > >
> >> > > >> > > > > > I still think we need to be putting much more effort
> into
> >> > > >> > deprecating
> >> > > >> > > > > > cache.xml and much less effort into fixing the
> (possibly)
> >> > > >> hundreds
> >> > > >> > of
> >> > > >> > > > > bugs
> >> > > >> > > > > > related to using both cache.xml and cluster
> >> configuration at
> >> > > the
> >> > > >> > same
> >> > > >> > > > > time.
> >> > > >> > > > > > If we can make cluster config complete enough, and
> >> deprecate
> >> > > >> > > cache.xml,
> >> > > >> > > > > > people will stop using cache.xml.
> >> > > >> > > > > >
> >> > > >> > > > > >
> >> > > >> > > > > >
> >> > > >> > > > > > --
> >> > > >> > > > > > Mike Stolz
> >> > > >> > > > > > Principal Engineer, GemFire Product Lead
> >> > > >> > > > > > Mobile: +1-631-835-4771 <(631)%20835-4771>
> >> > > >> > > > > > Download the GemFire book here.
> >> > > >> > > > > > <
> >> https://content.pivotal.io/ebooks/scaling-data-services-
> >> > > >> > > > > > with-pivotal-gemfire>
> >> > > >> > > > > >
> >> > > >> > > > > > On Thu, Apr 19, 2018 at 5:58 PM, Jinmei Liao <
> >> > > jiliao@pivotal.io
> >> > > >> >
> >> > > >> > > > wrote:
> >> > > >> > > > > >
> >> > > >> > > > > > > Scenario:
> >> > > >> > > > > > > a locator with cluster configuration enabled and a
> >> server
> >> > > >> started
> >> > > >> > > > with
> >> > > >> > > > > a
> >> > > >> > > > > > > cache.xml that has /regionA defined and connected to
> >> this
> >> > > >> > locator.
> >> > > >> > > So
> >> > > >> > > > > the
> >> > > >> > > > > > > initial state is the locator has an empty cluster
> >> > > >> configuration
> >> > > >> > for
> >> > > >> > > > the
> >> > > >> > > > > > > cluster, but the server has a region defined in it's
> >> > cache.
> >> > > >> > > > > > >
> >> > > >> > > > > > > Old behavior:
> >> > > >> > > > > > > when user execute "create index --region=/regionA
> ...."
> >> > > >> command
> >> > > >> > > using
> >> > > >> > > > > > gfsh,
> >> > > >> > > > > > > the index creation is successful on the server, and
> the
> >> > > server
> >> > > >> > > > returns
> >> > > >> > > > > a
> >> > > >> > > > > > > xml section that contains both <region> and <index>
> >> > > elements,
> >> > > >> CC
> >> > > >> > is
> >> > > >> > > > > > updated
> >> > > >> > > > > > > with this xml, so the end result is: both region and
> >> index
> >> > > >> end up
> >> > > >> > > in
> >> > > >> > > > > the
> >> > > >> > > > > > > cluster configuration.
> >> > > >> > > > > > >
> >> > > >> > > > > > > Problem with old behavior:
> >> > > >> > > > > > > Not sure if the region is a cluster wide
> configuration.
> >> > What
> >> > > >> if a
> >> > > >> > > > > region
> >> > > >> > > > > > > with the same name, but different type exists on
> >> different
> >> > > >> > servers?
> >> > > >> > > > the
> >> > > >> > > > > > xml
> >> > > >> > > > > > > returned by different server might be different.
> >> > > >> > > > > > >
> >> > > >> > > > > > > New behavior:
> >> > > >> > > > > > > when user execute "create index --region=/regionA
> ...."
> >> > > >> command
> >> > > >> > > using
> >> > > >> > > > > > gfsh,
> >> > > >> > > > > > > the index creation is successful on the server. We
> >> failed
> >> > to
> >> > > >> find
> >> > > >> > > the
> >> > > >> > > > > > > region in the existing cluster configuration, so
> >> cluster
> >> > > >> > > > configuration
> >> > > >> > > > > > will
> >> > > >> > > > > > > NOT be updated.
> >> > > >> > > > > > >
> >> > > >> > > > > > > I would also suggest that this would not apply to
> index
> >> > > alone,
> >> > > >> > any
> >> > > >> > > > > > element
> >> > > >> > > > > > > inside region would have the same behavior change if
> we
> >> > > >> approve
> >> > > >> > > this.
> >> > > >> > > > > > >
> >> > > >> > > > > > > Thanks!
> >> > > >> > > > > > >
> >> > > >> > > > > > > --
> >> > > >> > > > > > > Cheers
> >> > > >> > > > > > >
> >> > > >> > > > > > > Jinmei
> >> > > >> > > > > > >
> >> > > >> > > > > >
> >> > > >> > > > >
> >> > > >> > > > >
> >> > > >> > > > >
> >> > > >> > > > > --
> >> > > >> > > > > Cheers
> >> > > >> > > > >
> >> > > >> > > > > Jinmei
> >> > > >> > > > >
> >> > > >> > > >
> >> > > >> > >
> >> > > >> >
> >> > > >> >
> >> > > >> >
> >> > > >> > --
> >> > > >> > Cheers
> >> > > >> >
> >> > > >> > Jinmei
> >> > > >> >
> >> > > >>
> >> > > >
> >> > > >
> >> > > >
> >> > > > --
> >> > > > Cheers
> >> > > >
> >> > > > Jinmei
> >> > > >
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Cheers
> >> > >
> >> > > Jinmei
> >> > >
> >> >
> >>
> >>
> >>
> >> --
> >> Cheers
> >>
> >> Jinmei
> >>
> >
>
--
-John
john.blum10101 (skype)
Re: [Proposal]: behavior change when region doesn't exist in cluster configuration
Posted by Jinmei Liao <ji...@pivotal.io>.
Hi, Jason, I am able to start two servers using different cache.xml that
each define a region with the same name but with different attribute. This
might be because on one server, the region is defined as "local".
ServerA.xml
<?xml version="1.0" encoding="UTF-8"?><cache xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance" xmlns="
http://geode.apache.org/schema/cache" xsi:schemaLocation="
http://geode.apache.org/schema/cache
http://geode.apache.org/schema/cache/cache-1.0.xsd" version="1.0"
is-server="true">
<cache-server/>
<disk-store name="DEFAULT"/>
<region name="regionA" refid="REPLICATE">
</region>
<resource-manager eviction-heap-percentage="80"/>
</cache>
ServerB.xml
<?xml version="1.0" encoding="UTF-8"?><cache xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance" xmlns="
http://geode.apache.org/schema/cache" xsi:schemaLocation="
http://geode.apache.org/schema/cache
http://geode.apache.org/schema/cache/cache-1.0.xsd" version="1.0"
is-server="true">
<cache-server/>
<disk-store name="DEFAULT"/>
<region name="regionA">
<region-attributes scope="local">
<eviction-attributes>
<lru-heap-percentage action="local-destroy"/>
</eviction-attributes>
</region-attributes>
</region>
<resource-manager eviction-heap-percentage="80"/>
</cache>
On Fri, Apr 27, 2018 at 3:40 PM, Jason Huynh <jh...@pivotal.io> wrote:
> *correction to my last email, I was using java api and not cache.xml
>
> On Fri, Apr 27, 2018 at 3:40 PM Jason Huynh <jh...@pivotal.io> wrote:
>
> > Hi Jinmei and Naba,
> >
> > I don't think you can define two regions with the same name and different
> > types. We would throw an IllegalStateException for the node that tried
> to
> > create the region second. At least that was the behavior I was seeing
> when
> > I tried to create a replicate region and a partitioned region with the
> same
> > name (admittedly using the java api and not cluster config). So then if
> > you run a gfsh command to create an index, it would only create the index
> > on the first node and report back to cluster config the first nodes
> > configuration and the new index.
> >
> > Going back to the original proposal, if the user ever wanted to have the
> > cluster config updated with the region, how would they sync up their
> > cluster config without bringing everything down? Sure they can export
> xml
> > and bring up another server with xml but that doesn't get them migrated
> to
> > cluster config...
> >
> >
> >
> > On Fri, Apr 27, 2018 at 2:48 PM Jinmei Liao <ji...@pivotal.io> wrote:
> >
> >> Hi, Naba, I believe this is possible even before, with or without using
> >> cluster configuration. That's why we have to say stuff defined using
> >> cache.xml is not mean to be a cluster wide configuration.
> >>
> >> On Fri, Apr 27, 2018 at 2:40 PM, Nabarun Nag <nn...@apache.org> wrote:
> >>
> >> > With the new implementation, will it allow two different regions with
> >> the
> >> > same exact name to exist in the cluster ?
> >> >
> >> > I meant like server A had a cache.xml with region “test” with
> different
> >> > properties as to the cache.xml in server B for region “test”. And the
> >> > locator had an empty cluster config.
> >> >
> >> > So now when servers A and B start, they will have different regions
> but
> >> the
> >> > same name “test”. Because there is no sync up with locator’s cluster
> >> > config.
> >> >
> >> > Pardon me if my understanding is wrong.
> >> >
> >> >
> >> > Regards
> >> > Nabarun
> >> >
> >> >
> >> > On Fri, Apr 27, 2018 at 2:23 PM Jinmei Liao <ji...@pivotal.io>
> wrote:
> >> >
> >> > > My point is: we can't keep "mending" the wrong behavior, otherwise
> we
> >> can
> >> > > not move forward.
> >> > >
> >> > > On Fri, Apr 27, 2018 at 2:22 PM, Jinmei Liao <ji...@pivotal.io>
> >> wrote:
> >> > >
> >> > > > So the current behavior is, when a customer starts a server with
> >> > > cache.xml
> >> > > > that has a region defined, and then later on issues a gfsh command
> >> > > `create
> >> > > > index` on that region, the command output would be something like:
> >> > > > >create index .....
> >> > > > Member | Status
> >> > > > ----------------------------
> >> > > > server-1 | Index successfully created.
> >> > > >
> >> > > > Cluster configuration for "cluster" is not updated
> >> > > > Region XYZ does not exist in the cluster configuration (or
> >> something to
> >> > > > this effect).
> >> > > >
> >> > > > The command result would tell user exactly what happened and what
> >> not
> >> > > > happened. The point is, a server's own cache.xml is NOT meant to
> be
> >> a
> >> > > > "cluster" wide configuration. If customer is in the habit of
> >> starting
> >> > up
> >> > > > server with cache.xml but yet still want to have consistent
> >> > region/index
> >> > > > defined in the cluster, export a server's config and use that to
> >> start
> >> > > > another server.
> >> > > >
> >> > > >
> >> > > >
> >> > > > On Fri, Apr 27, 2018 at 2:03 PM, Diane Hardman <
> dhardman@pivotal.io
> >> >
> >> > > > wrote:
> >> > > >
> >> > > >> I talked with Barbara and understand the long term effort to
> >> deprecate
> >> > > >> cache.xml in favor of cluster config and I heartily agree.
> >> > > >> I think a good step in that direction is to provide a migration
> >> tool
> >> > for
> >> > > >> users that reads all cache.xml files for current members and
> store
> >> > them
> >> > > in
> >> > > >> cluster config, throwing exceptions and logging errors when
> region
> >> > > >> definitions conflict (for the same region name) on different
> >> servers
> >> > in
> >> > > >> the
> >> > > >> same cluster.
> >> > > >> We might then consider removing the cache.xml files and rely on
> >> gfsh
> >> > and
> >> > > >> (in the future, hopefully) Java API's to keep cluster config
> >> > up-to-date.
> >> > > >>
> >> > > >> Thanks!
> >> > > >>
> >> > > >> On Fri, Apr 27, 2018 at 12:56 PM, Jinmei Liao <jiliao@pivotal.io
> >
> >> > > wrote:
> >> > > >>
> >> > > >> > The decision is to go with the new behavior (I believe :-)).
> The
> >> > > region
> >> > > >> > does not exist in the cluster configuration to begin with since
> >> it's
> >> > > not
> >> > > >> > created using gfsh, so we have no way of checking unless we
> make
> >> an
> >> > > >> extra
> >> > > >> > trip to the region to find out what kind of region it is, but
> >> again
> >> > > >> > different server might have different opinion about what it is.
> >> > > >> >
> >> > > >> > On Fri, Apr 27, 2018 at 12:49 PM, Diane Hardman <
> >> > dhardman@pivotal.io>
> >> > > >> > wrote:
> >> > > >> >
> >> > > >> > > Since we are working on enhancing Lucene support to allow
> >> adding a
> >> > > >> Lucene
> >> > > >> > > index to an existing region containing data, I am very
> >> interested
> >> > in
> >> > > >> the
> >> > > >> > > decision here.
> >> > > >> > > Like Mike, I also prefer keeping the original behavior of
> >> updating
> >> > > >> > cluster
> >> > > >> > > config with both the region and the index if it was not there
> >> > > before.
> >> > > >> > > Is there something preventing you from checking cluster
> config
> >> > for a
> >> > > >> > region
> >> > > >> > > of the same name but different properties and, if so,
> throwing
> >> an
> >> > > >> > exception
> >> > > >> > > (or warning)
> >> > > >> > > that cluster config could not be updated due to this
> collision?
> >> > > >> > >
> >> > > >> > > On Thu, Apr 19, 2018 at 3:35 PM, Michael Stolz <
> >> mstolz@pivotal.io
> >> > >
> >> > > >> > wrote:
> >> > > >> > >
> >> > > >> > > > Ok. Yes we do have to take the leap :)
> >> > > >> > > > Let's keep thinking that way.
> >> > > >> > > >
> >> > > >> > > > --
> >> > > >> > > > Mike Stolz
> >> > > >> > > > Principal Engineer, GemFire Product Lead
> >> > > >> > > > Mobile: +1-631-835-4771 <(631)%20835-4771>
> >> > > >> > > > Download the GemFire book here.
> >> > > >> > > > <https://content.pivotal.io/ebooks/scaling-data-services-
> >> > > >> > > > with-pivotal-gemfire>
> >> > > >> > > >
> >> > > >> > > > On Thu, Apr 19, 2018 at 6:29 PM, Jinmei Liao <
> >> jiliao@pivotal.io
> >> > >
> >> > > >> > wrote:
> >> > > >> > > >
> >> > > >> > > > > but this proposed change is one of the effort toward
> >> > > "deprecating
> >> > > >> > > > > cache.xml". I think we've got to take the leap at one
> >> > point.....
> >> > > >> > > > >
> >> > > >> > > > > On Thu, Apr 19, 2018 at 3:14 PM, Michael Stolz <
> >> > > mstolz@pivotal.io
> >> > > >> >
> >> > > >> > > > wrote:
> >> > > >> > > > >
> >> > > >> > > > > > Hmmm...I think I liked the old behavior better. It was
> a
> >> > kind
> >> > > of
> >> > > >> > > bridge
> >> > > >> > > > > to
> >> > > >> > > > > > cluster config.
> >> > > >> > > > > >
> >> > > >> > > > > > I still think we need to be putting much more effort
> into
> >> > > >> > deprecating
> >> > > >> > > > > > cache.xml and much less effort into fixing the
> (possibly)
> >> > > >> hundreds
> >> > > >> > of
> >> > > >> > > > > bugs
> >> > > >> > > > > > related to using both cache.xml and cluster
> >> configuration at
> >> > > the
> >> > > >> > same
> >> > > >> > > > > time.
> >> > > >> > > > > > If we can make cluster config complete enough, and
> >> deprecate
> >> > > >> > > cache.xml,
> >> > > >> > > > > > people will stop using cache.xml.
> >> > > >> > > > > >
> >> > > >> > > > > >
> >> > > >> > > > > >
> >> > > >> > > > > > --
> >> > > >> > > > > > Mike Stolz
> >> > > >> > > > > > Principal Engineer, GemFire Product Lead
> >> > > >> > > > > > Mobile: +1-631-835-4771 <(631)%20835-4771>
> >> > > >> > > > > > Download the GemFire book here.
> >> > > >> > > > > > <
> >> https://content.pivotal.io/ebooks/scaling-data-services-
> >> > > >> > > > > > with-pivotal-gemfire>
> >> > > >> > > > > >
> >> > > >> > > > > > On Thu, Apr 19, 2018 at 5:58 PM, Jinmei Liao <
> >> > > jiliao@pivotal.io
> >> > > >> >
> >> > > >> > > > wrote:
> >> > > >> > > > > >
> >> > > >> > > > > > > Scenario:
> >> > > >> > > > > > > a locator with cluster configuration enabled and a
> >> server
> >> > > >> started
> >> > > >> > > > with
> >> > > >> > > > > a
> >> > > >> > > > > > > cache.xml that has /regionA defined and connected to
> >> this
> >> > > >> > locator.
> >> > > >> > > So
> >> > > >> > > > > the
> >> > > >> > > > > > > initial state is the locator has an empty cluster
> >> > > >> configuration
> >> > > >> > for
> >> > > >> > > > the
> >> > > >> > > > > > > cluster, but the server has a region defined in it's
> >> > cache.
> >> > > >> > > > > > >
> >> > > >> > > > > > > Old behavior:
> >> > > >> > > > > > > when user execute "create index --region=/regionA
> ...."
> >> > > >> command
> >> > > >> > > using
> >> > > >> > > > > > gfsh,
> >> > > >> > > > > > > the index creation is successful on the server, and
> the
> >> > > server
> >> > > >> > > > returns
> >> > > >> > > > > a
> >> > > >> > > > > > > xml section that contains both <region> and <index>
> >> > > elements,
> >> > > >> CC
> >> > > >> > is
> >> > > >> > > > > > updated
> >> > > >> > > > > > > with this xml, so the end result is: both region and
> >> index
> >> > > >> end up
> >> > > >> > > in
> >> > > >> > > > > the
> >> > > >> > > > > > > cluster configuration.
> >> > > >> > > > > > >
> >> > > >> > > > > > > Problem with old behavior:
> >> > > >> > > > > > > Not sure if the region is a cluster wide
> configuration.
> >> > What
> >> > > >> if a
> >> > > >> > > > > region
> >> > > >> > > > > > > with the same name, but different type exists on
> >> different
> >> > > >> > servers?
> >> > > >> > > > the
> >> > > >> > > > > > xml
> >> > > >> > > > > > > returned by different server might be different.
> >> > > >> > > > > > >
> >> > > >> > > > > > > New behavior:
> >> > > >> > > > > > > when user execute "create index --region=/regionA
> ...."
> >> > > >> command
> >> > > >> > > using
> >> > > >> > > > > > gfsh,
> >> > > >> > > > > > > the index creation is successful on the server. We
> >> failed
> >> > to
> >> > > >> find
> >> > > >> > > the
> >> > > >> > > > > > > region in the existing cluster configuration, so
> >> cluster
> >> > > >> > > > configuration
> >> > > >> > > > > > will
> >> > > >> > > > > > > NOT be updated.
> >> > > >> > > > > > >
> >> > > >> > > > > > > I would also suggest that this would not apply to
> index
> >> > > alone,
> >> > > >> > any
> >> > > >> > > > > > element
> >> > > >> > > > > > > inside region would have the same behavior change if
> we
> >> > > >> approve
> >> > > >> > > this.
> >> > > >> > > > > > >
> >> > > >> > > > > > > Thanks!
> >> > > >> > > > > > >
> >> > > >> > > > > > > --
> >> > > >> > > > > > > Cheers
> >> > > >> > > > > > >
> >> > > >> > > > > > > Jinmei
> >> > > >> > > > > > >
> >> > > >> > > > > >
> >> > > >> > > > >
> >> > > >> > > > >
> >> > > >> > > > >
> >> > > >> > > > > --
> >> > > >> > > > > Cheers
> >> > > >> > > > >
> >> > > >> > > > > Jinmei
> >> > > >> > > > >
> >> > > >> > > >
> >> > > >> > >
> >> > > >> >
> >> > > >> >
> >> > > >> >
> >> > > >> > --
> >> > > >> > Cheers
> >> > > >> >
> >> > > >> > Jinmei
> >> > > >> >
> >> > > >>
> >> > > >
> >> > > >
> >> > > >
> >> > > > --
> >> > > > Cheers
> >> > > >
> >> > > > Jinmei
> >> > > >
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Cheers
> >> > >
> >> > > Jinmei
> >> > >
> >> >
> >>
> >>
> >>
> >> --
> >> Cheers
> >>
> >> Jinmei
> >>
> >
>
--
Cheers
Jinmei
Re: [Proposal]: behavior change when region doesn't exist in cluster configuration
Posted by Jason Huynh <jh...@pivotal.io>.
*correction to my last email, I was using java api and not cache.xml
On Fri, Apr 27, 2018 at 3:40 PM Jason Huynh <jh...@pivotal.io> wrote:
> Hi Jinmei and Naba,
>
> I don't think you can define two regions with the same name and different
> types. We would throw an IllegalStateException for the node that tried to
> create the region second. At least that was the behavior I was seeing when
> I tried to create a replicate region and a partitioned region with the same
> name (admittedly using the java api and not cluster config). So then if
> you run a gfsh command to create an index, it would only create the index
> on the first node and report back to cluster config the first nodes
> configuration and the new index.
>
> Going back to the original proposal, if the user ever wanted to have the
> cluster config updated with the region, how would they sync up their
> cluster config without bringing everything down? Sure they can export xml
> and bring up another server with xml but that doesn't get them migrated to
> cluster config...
>
>
>
> On Fri, Apr 27, 2018 at 2:48 PM Jinmei Liao <ji...@pivotal.io> wrote:
>
>> Hi, Naba, I believe this is possible even before, with or without using
>> cluster configuration. That's why we have to say stuff defined using
>> cache.xml is not mean to be a cluster wide configuration.
>>
>> On Fri, Apr 27, 2018 at 2:40 PM, Nabarun Nag <nn...@apache.org> wrote:
>>
>> > With the new implementation, will it allow two different regions with
>> the
>> > same exact name to exist in the cluster ?
>> >
>> > I meant like server A had a cache.xml with region “test” with different
>> > properties as to the cache.xml in server B for region “test”. And the
>> > locator had an empty cluster config.
>> >
>> > So now when servers A and B start, they will have different regions but
>> the
>> > same name “test”. Because there is no sync up with locator’s cluster
>> > config.
>> >
>> > Pardon me if my understanding is wrong.
>> >
>> >
>> > Regards
>> > Nabarun
>> >
>> >
>> > On Fri, Apr 27, 2018 at 2:23 PM Jinmei Liao <ji...@pivotal.io> wrote:
>> >
>> > > My point is: we can't keep "mending" the wrong behavior, otherwise we
>> can
>> > > not move forward.
>> > >
>> > > On Fri, Apr 27, 2018 at 2:22 PM, Jinmei Liao <ji...@pivotal.io>
>> wrote:
>> > >
>> > > > So the current behavior is, when a customer starts a server with
>> > > cache.xml
>> > > > that has a region defined, and then later on issues a gfsh command
>> > > `create
>> > > > index` on that region, the command output would be something like:
>> > > > >create index .....
>> > > > Member | Status
>> > > > ----------------------------
>> > > > server-1 | Index successfully created.
>> > > >
>> > > > Cluster configuration for "cluster" is not updated
>> > > > Region XYZ does not exist in the cluster configuration (or
>> something to
>> > > > this effect).
>> > > >
>> > > > The command result would tell user exactly what happened and what
>> not
>> > > > happened. The point is, a server's own cache.xml is NOT meant to be
>> a
>> > > > "cluster" wide configuration. If customer is in the habit of
>> starting
>> > up
>> > > > server with cache.xml but yet still want to have consistent
>> > region/index
>> > > > defined in the cluster, export a server's config and use that to
>> start
>> > > > another server.
>> > > >
>> > > >
>> > > >
>> > > > On Fri, Apr 27, 2018 at 2:03 PM, Diane Hardman <dhardman@pivotal.io
>> >
>> > > > wrote:
>> > > >
>> > > >> I talked with Barbara and understand the long term effort to
>> deprecate
>> > > >> cache.xml in favor of cluster config and I heartily agree.
>> > > >> I think a good step in that direction is to provide a migration
>> tool
>> > for
>> > > >> users that reads all cache.xml files for current members and store
>> > them
>> > > in
>> > > >> cluster config, throwing exceptions and logging errors when region
>> > > >> definitions conflict (for the same region name) on different
>> servers
>> > in
>> > > >> the
>> > > >> same cluster.
>> > > >> We might then consider removing the cache.xml files and rely on
>> gfsh
>> > and
>> > > >> (in the future, hopefully) Java API's to keep cluster config
>> > up-to-date.
>> > > >>
>> > > >> Thanks!
>> > > >>
>> > > >> On Fri, Apr 27, 2018 at 12:56 PM, Jinmei Liao <ji...@pivotal.io>
>> > > wrote:
>> > > >>
>> > > >> > The decision is to go with the new behavior (I believe :-)). The
>> > > region
>> > > >> > does not exist in the cluster configuration to begin with since
>> it's
>> > > not
>> > > >> > created using gfsh, so we have no way of checking unless we make
>> an
>> > > >> extra
>> > > >> > trip to the region to find out what kind of region it is, but
>> again
>> > > >> > different server might have different opinion about what it is.
>> > > >> >
>> > > >> > On Fri, Apr 27, 2018 at 12:49 PM, Diane Hardman <
>> > dhardman@pivotal.io>
>> > > >> > wrote:
>> > > >> >
>> > > >> > > Since we are working on enhancing Lucene support to allow
>> adding a
>> > > >> Lucene
>> > > >> > > index to an existing region containing data, I am very
>> interested
>> > in
>> > > >> the
>> > > >> > > decision here.
>> > > >> > > Like Mike, I also prefer keeping the original behavior of
>> updating
>> > > >> > cluster
>> > > >> > > config with both the region and the index if it was not there
>> > > before.
>> > > >> > > Is there something preventing you from checking cluster config
>> > for a
>> > > >> > region
>> > > >> > > of the same name but different properties and, if so, throwing
>> an
>> > > >> > exception
>> > > >> > > (or warning)
>> > > >> > > that cluster config could not be updated due to this collision?
>> > > >> > >
>> > > >> > > On Thu, Apr 19, 2018 at 3:35 PM, Michael Stolz <
>> mstolz@pivotal.io
>> > >
>> > > >> > wrote:
>> > > >> > >
>> > > >> > > > Ok. Yes we do have to take the leap :)
>> > > >> > > > Let's keep thinking that way.
>> > > >> > > >
>> > > >> > > > --
>> > > >> > > > Mike Stolz
>> > > >> > > > Principal Engineer, GemFire Product Lead
>> > > >> > > > Mobile: +1-631-835-4771 <(631)%20835-4771>
>> > > >> > > > Download the GemFire book here.
>> > > >> > > > <https://content.pivotal.io/ebooks/scaling-data-services-
>> > > >> > > > with-pivotal-gemfire>
>> > > >> > > >
>> > > >> > > > On Thu, Apr 19, 2018 at 6:29 PM, Jinmei Liao <
>> jiliao@pivotal.io
>> > >
>> > > >> > wrote:
>> > > >> > > >
>> > > >> > > > > but this proposed change is one of the effort toward
>> > > "deprecating
>> > > >> > > > > cache.xml". I think we've got to take the leap at one
>> > point.....
>> > > >> > > > >
>> > > >> > > > > On Thu, Apr 19, 2018 at 3:14 PM, Michael Stolz <
>> > > mstolz@pivotal.io
>> > > >> >
>> > > >> > > > wrote:
>> > > >> > > > >
>> > > >> > > > > > Hmmm...I think I liked the old behavior better. It was a
>> > kind
>> > > of
>> > > >> > > bridge
>> > > >> > > > > to
>> > > >> > > > > > cluster config.
>> > > >> > > > > >
>> > > >> > > > > > I still think we need to be putting much more effort into
>> > > >> > deprecating
>> > > >> > > > > > cache.xml and much less effort into fixing the (possibly)
>> > > >> hundreds
>> > > >> > of
>> > > >> > > > > bugs
>> > > >> > > > > > related to using both cache.xml and cluster
>> configuration at
>> > > the
>> > > >> > same
>> > > >> > > > > time.
>> > > >> > > > > > If we can make cluster config complete enough, and
>> deprecate
>> > > >> > > cache.xml,
>> > > >> > > > > > people will stop using cache.xml.
>> > > >> > > > > >
>> > > >> > > > > >
>> > > >> > > > > >
>> > > >> > > > > > --
>> > > >> > > > > > Mike Stolz
>> > > >> > > > > > Principal Engineer, GemFire Product Lead
>> > > >> > > > > > Mobile: +1-631-835-4771 <(631)%20835-4771>
>> > > >> > > > > > Download the GemFire book here.
>> > > >> > > > > > <
>> https://content.pivotal.io/ebooks/scaling-data-services-
>> > > >> > > > > > with-pivotal-gemfire>
>> > > >> > > > > >
>> > > >> > > > > > On Thu, Apr 19, 2018 at 5:58 PM, Jinmei Liao <
>> > > jiliao@pivotal.io
>> > > >> >
>> > > >> > > > wrote:
>> > > >> > > > > >
>> > > >> > > > > > > Scenario:
>> > > >> > > > > > > a locator with cluster configuration enabled and a
>> server
>> > > >> started
>> > > >> > > > with
>> > > >> > > > > a
>> > > >> > > > > > > cache.xml that has /regionA defined and connected to
>> this
>> > > >> > locator.
>> > > >> > > So
>> > > >> > > > > the
>> > > >> > > > > > > initial state is the locator has an empty cluster
>> > > >> configuration
>> > > >> > for
>> > > >> > > > the
>> > > >> > > > > > > cluster, but the server has a region defined in it's
>> > cache.
>> > > >> > > > > > >
>> > > >> > > > > > > Old behavior:
>> > > >> > > > > > > when user execute "create index --region=/regionA ...."
>> > > >> command
>> > > >> > > using
>> > > >> > > > > > gfsh,
>> > > >> > > > > > > the index creation is successful on the server, and the
>> > > server
>> > > >> > > > returns
>> > > >> > > > > a
>> > > >> > > > > > > xml section that contains both <region> and <index>
>> > > elements,
>> > > >> CC
>> > > >> > is
>> > > >> > > > > > updated
>> > > >> > > > > > > with this xml, so the end result is: both region and
>> index
>> > > >> end up
>> > > >> > > in
>> > > >> > > > > the
>> > > >> > > > > > > cluster configuration.
>> > > >> > > > > > >
>> > > >> > > > > > > Problem with old behavior:
>> > > >> > > > > > > Not sure if the region is a cluster wide configuration.
>> > What
>> > > >> if a
>> > > >> > > > > region
>> > > >> > > > > > > with the same name, but different type exists on
>> different
>> > > >> > servers?
>> > > >> > > > the
>> > > >> > > > > > xml
>> > > >> > > > > > > returned by different server might be different.
>> > > >> > > > > > >
>> > > >> > > > > > > New behavior:
>> > > >> > > > > > > when user execute "create index --region=/regionA ...."
>> > > >> command
>> > > >> > > using
>> > > >> > > > > > gfsh,
>> > > >> > > > > > > the index creation is successful on the server. We
>> failed
>> > to
>> > > >> find
>> > > >> > > the
>> > > >> > > > > > > region in the existing cluster configuration, so
>> cluster
>> > > >> > > > configuration
>> > > >> > > > > > will
>> > > >> > > > > > > NOT be updated.
>> > > >> > > > > > >
>> > > >> > > > > > > I would also suggest that this would not apply to index
>> > > alone,
>> > > >> > any
>> > > >> > > > > > element
>> > > >> > > > > > > inside region would have the same behavior change if we
>> > > >> approve
>> > > >> > > this.
>> > > >> > > > > > >
>> > > >> > > > > > > Thanks!
>> > > >> > > > > > >
>> > > >> > > > > > > --
>> > > >> > > > > > > Cheers
>> > > >> > > > > > >
>> > > >> > > > > > > Jinmei
>> > > >> > > > > > >
>> > > >> > > > > >
>> > > >> > > > >
>> > > >> > > > >
>> > > >> > > > >
>> > > >> > > > > --
>> > > >> > > > > Cheers
>> > > >> > > > >
>> > > >> > > > > Jinmei
>> > > >> > > > >
>> > > >> > > >
>> > > >> > >
>> > > >> >
>> > > >> >
>> > > >> >
>> > > >> > --
>> > > >> > Cheers
>> > > >> >
>> > > >> > Jinmei
>> > > >> >
>> > > >>
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > Cheers
>> > > >
>> > > > Jinmei
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > Cheers
>> > >
>> > > Jinmei
>> > >
>> >
>>
>>
>>
>> --
>> Cheers
>>
>> Jinmei
>>
>
Re: [Proposal]: behavior change when region doesn't exist in cluster configuration
Posted by Jason Huynh <jh...@pivotal.io>.
Hi Jinmei and Naba,
I don't think you can define two regions with the same name and different
types. We would throw an IllegalStateException for the node that tried to
create the region second. At least that was the behavior I was seeing when
I tried to create a replicate region and a partitioned region with the same
name (admittedly using the java api and not cluster config). So then if
you run a gfsh command to create an index, it would only create the index
on the first node and report back to cluster config the first nodes
configuration and the new index.
Going back to the original proposal, if the user ever wanted to have the
cluster config updated with the region, how would they sync up their
cluster config without bringing everything down? Sure they can export xml
and bring up another server with xml but that doesn't get them migrated to
cluster config...
On Fri, Apr 27, 2018 at 2:48 PM Jinmei Liao <ji...@pivotal.io> wrote:
> Hi, Naba, I believe this is possible even before, with or without using
> cluster configuration. That's why we have to say stuff defined using
> cache.xml is not mean to be a cluster wide configuration.
>
> On Fri, Apr 27, 2018 at 2:40 PM, Nabarun Nag <nn...@apache.org> wrote:
>
> > With the new implementation, will it allow two different regions with the
> > same exact name to exist in the cluster ?
> >
> > I meant like server A had a cache.xml with region “test” with different
> > properties as to the cache.xml in server B for region “test”. And the
> > locator had an empty cluster config.
> >
> > So now when servers A and B start, they will have different regions but
> the
> > same name “test”. Because there is no sync up with locator’s cluster
> > config.
> >
> > Pardon me if my understanding is wrong.
> >
> >
> > Regards
> > Nabarun
> >
> >
> > On Fri, Apr 27, 2018 at 2:23 PM Jinmei Liao <ji...@pivotal.io> wrote:
> >
> > > My point is: we can't keep "mending" the wrong behavior, otherwise we
> can
> > > not move forward.
> > >
> > > On Fri, Apr 27, 2018 at 2:22 PM, Jinmei Liao <ji...@pivotal.io>
> wrote:
> > >
> > > > So the current behavior is, when a customer starts a server with
> > > cache.xml
> > > > that has a region defined, and then later on issues a gfsh command
> > > `create
> > > > index` on that region, the command output would be something like:
> > > > >create index .....
> > > > Member | Status
> > > > ----------------------------
> > > > server-1 | Index successfully created.
> > > >
> > > > Cluster configuration for "cluster" is not updated
> > > > Region XYZ does not exist in the cluster configuration (or something
> to
> > > > this effect).
> > > >
> > > > The command result would tell user exactly what happened and what not
> > > > happened. The point is, a server's own cache.xml is NOT meant to be a
> > > > "cluster" wide configuration. If customer is in the habit of starting
> > up
> > > > server with cache.xml but yet still want to have consistent
> > region/index
> > > > defined in the cluster, export a server's config and use that to
> start
> > > > another server.
> > > >
> > > >
> > > >
> > > > On Fri, Apr 27, 2018 at 2:03 PM, Diane Hardman <dh...@pivotal.io>
> > > > wrote:
> > > >
> > > >> I talked with Barbara and understand the long term effort to
> deprecate
> > > >> cache.xml in favor of cluster config and I heartily agree.
> > > >> I think a good step in that direction is to provide a migration tool
> > for
> > > >> users that reads all cache.xml files for current members and store
> > them
> > > in
> > > >> cluster config, throwing exceptions and logging errors when region
> > > >> definitions conflict (for the same region name) on different servers
> > in
> > > >> the
> > > >> same cluster.
> > > >> We might then consider removing the cache.xml files and rely on gfsh
> > and
> > > >> (in the future, hopefully) Java API's to keep cluster config
> > up-to-date.
> > > >>
> > > >> Thanks!
> > > >>
> > > >> On Fri, Apr 27, 2018 at 12:56 PM, Jinmei Liao <ji...@pivotal.io>
> > > wrote:
> > > >>
> > > >> > The decision is to go with the new behavior (I believe :-)). The
> > > region
> > > >> > does not exist in the cluster configuration to begin with since
> it's
> > > not
> > > >> > created using gfsh, so we have no way of checking unless we make
> an
> > > >> extra
> > > >> > trip to the region to find out what kind of region it is, but
> again
> > > >> > different server might have different opinion about what it is.
> > > >> >
> > > >> > On Fri, Apr 27, 2018 at 12:49 PM, Diane Hardman <
> > dhardman@pivotal.io>
> > > >> > wrote:
> > > >> >
> > > >> > > Since we are working on enhancing Lucene support to allow
> adding a
> > > >> Lucene
> > > >> > > index to an existing region containing data, I am very
> interested
> > in
> > > >> the
> > > >> > > decision here.
> > > >> > > Like Mike, I also prefer keeping the original behavior of
> updating
> > > >> > cluster
> > > >> > > config with both the region and the index if it was not there
> > > before.
> > > >> > > Is there something preventing you from checking cluster config
> > for a
> > > >> > region
> > > >> > > of the same name but different properties and, if so, throwing
> an
> > > >> > exception
> > > >> > > (or warning)
> > > >> > > that cluster config could not be updated due to this collision?
> > > >> > >
> > > >> > > On Thu, Apr 19, 2018 at 3:35 PM, Michael Stolz <
> mstolz@pivotal.io
> > >
> > > >> > wrote:
> > > >> > >
> > > >> > > > Ok. Yes we do have to take the leap :)
> > > >> > > > Let's keep thinking that way.
> > > >> > > >
> > > >> > > > --
> > > >> > > > Mike Stolz
> > > >> > > > Principal Engineer, GemFire Product Lead
> > > >> > > > Mobile: +1-631-835-4771 <(631)%20835-4771>
> > > >> > > > Download the GemFire book here.
> > > >> > > > <https://content.pivotal.io/ebooks/scaling-data-services-
> > > >> > > > with-pivotal-gemfire>
> > > >> > > >
> > > >> > > > On Thu, Apr 19, 2018 at 6:29 PM, Jinmei Liao <
> jiliao@pivotal.io
> > >
> > > >> > wrote:
> > > >> > > >
> > > >> > > > > but this proposed change is one of the effort toward
> > > "deprecating
> > > >> > > > > cache.xml". I think we've got to take the leap at one
> > point.....
> > > >> > > > >
> > > >> > > > > On Thu, Apr 19, 2018 at 3:14 PM, Michael Stolz <
> > > mstolz@pivotal.io
> > > >> >
> > > >> > > > wrote:
> > > >> > > > >
> > > >> > > > > > Hmmm...I think I liked the old behavior better. It was a
> > kind
> > > of
> > > >> > > bridge
> > > >> > > > > to
> > > >> > > > > > cluster config.
> > > >> > > > > >
> > > >> > > > > > I still think we need to be putting much more effort into
> > > >> > deprecating
> > > >> > > > > > cache.xml and much less effort into fixing the (possibly)
> > > >> hundreds
> > > >> > of
> > > >> > > > > bugs
> > > >> > > > > > related to using both cache.xml and cluster configuration
> at
> > > the
> > > >> > same
> > > >> > > > > time.
> > > >> > > > > > If we can make cluster config complete enough, and
> deprecate
> > > >> > > cache.xml,
> > > >> > > > > > people will stop using cache.xml.
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > > > --
> > > >> > > > > > Mike Stolz
> > > >> > > > > > Principal Engineer, GemFire Product Lead
> > > >> > > > > > Mobile: +1-631-835-4771 <(631)%20835-4771>
> > > >> > > > > > Download the GemFire book here.
> > > >> > > > > > <https://content.pivotal.io/ebooks/scaling-data-services-
> > > >> > > > > > with-pivotal-gemfire>
> > > >> > > > > >
> > > >> > > > > > On Thu, Apr 19, 2018 at 5:58 PM, Jinmei Liao <
> > > jiliao@pivotal.io
> > > >> >
> > > >> > > > wrote:
> > > >> > > > > >
> > > >> > > > > > > Scenario:
> > > >> > > > > > > a locator with cluster configuration enabled and a
> server
> > > >> started
> > > >> > > > with
> > > >> > > > > a
> > > >> > > > > > > cache.xml that has /regionA defined and connected to
> this
> > > >> > locator.
> > > >> > > So
> > > >> > > > > the
> > > >> > > > > > > initial state is the locator has an empty cluster
> > > >> configuration
> > > >> > for
> > > >> > > > the
> > > >> > > > > > > cluster, but the server has a region defined in it's
> > cache.
> > > >> > > > > > >
> > > >> > > > > > > Old behavior:
> > > >> > > > > > > when user execute "create index --region=/regionA ...."
> > > >> command
> > > >> > > using
> > > >> > > > > > gfsh,
> > > >> > > > > > > the index creation is successful on the server, and the
> > > server
> > > >> > > > returns
> > > >> > > > > a
> > > >> > > > > > > xml section that contains both <region> and <index>
> > > elements,
> > > >> CC
> > > >> > is
> > > >> > > > > > updated
> > > >> > > > > > > with this xml, so the end result is: both region and
> index
> > > >> end up
> > > >> > > in
> > > >> > > > > the
> > > >> > > > > > > cluster configuration.
> > > >> > > > > > >
> > > >> > > > > > > Problem with old behavior:
> > > >> > > > > > > Not sure if the region is a cluster wide configuration.
> > What
> > > >> if a
> > > >> > > > > region
> > > >> > > > > > > with the same name, but different type exists on
> different
> > > >> > servers?
> > > >> > > > the
> > > >> > > > > > xml
> > > >> > > > > > > returned by different server might be different.
> > > >> > > > > > >
> > > >> > > > > > > New behavior:
> > > >> > > > > > > when user execute "create index --region=/regionA ...."
> > > >> command
> > > >> > > using
> > > >> > > > > > gfsh,
> > > >> > > > > > > the index creation is successful on the server. We
> failed
> > to
> > > >> find
> > > >> > > the
> > > >> > > > > > > region in the existing cluster configuration, so cluster
> > > >> > > > configuration
> > > >> > > > > > will
> > > >> > > > > > > NOT be updated.
> > > >> > > > > > >
> > > >> > > > > > > I would also suggest that this would not apply to index
> > > alone,
> > > >> > any
> > > >> > > > > > element
> > > >> > > > > > > inside region would have the same behavior change if we
> > > >> approve
> > > >> > > this.
> > > >> > > > > > >
> > > >> > > > > > > Thanks!
> > > >> > > > > > >
> > > >> > > > > > > --
> > > >> > > > > > > Cheers
> > > >> > > > > > >
> > > >> > > > > > > Jinmei
> > > >> > > > > > >
> > > >> > > > > >
> > > >> > > > >
> > > >> > > > >
> > > >> > > > >
> > > >> > > > > --
> > > >> > > > > Cheers
> > > >> > > > >
> > > >> > > > > Jinmei
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >> >
> > > >> >
> > > >> > --
> > > >> > Cheers
> > > >> >
> > > >> > Jinmei
> > > >> >
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Cheers
> > > >
> > > > Jinmei
> > > >
> > >
> > >
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
>
>
>
> --
> Cheers
>
> Jinmei
>
Re: [Proposal]: behavior change when region doesn't exist in cluster configuration
Posted by Jinmei Liao <ji...@pivotal.io>.
Hi, Naba, I believe this is possible even before, with or without using
cluster configuration. That's why we have to say stuff defined using
cache.xml is not mean to be a cluster wide configuration.
On Fri, Apr 27, 2018 at 2:40 PM, Nabarun Nag <nn...@apache.org> wrote:
> With the new implementation, will it allow two different regions with the
> same exact name to exist in the cluster ?
>
> I meant like server A had a cache.xml with region “test” with different
> properties as to the cache.xml in server B for region “test”. And the
> locator had an empty cluster config.
>
> So now when servers A and B start, they will have different regions but the
> same name “test”. Because there is no sync up with locator’s cluster
> config.
>
> Pardon me if my understanding is wrong.
>
>
> Regards
> Nabarun
>
>
> On Fri, Apr 27, 2018 at 2:23 PM Jinmei Liao <ji...@pivotal.io> wrote:
>
> > My point is: we can't keep "mending" the wrong behavior, otherwise we can
> > not move forward.
> >
> > On Fri, Apr 27, 2018 at 2:22 PM, Jinmei Liao <ji...@pivotal.io> wrote:
> >
> > > So the current behavior is, when a customer starts a server with
> > cache.xml
> > > that has a region defined, and then later on issues a gfsh command
> > `create
> > > index` on that region, the command output would be something like:
> > > >create index .....
> > > Member | Status
> > > ----------------------------
> > > server-1 | Index successfully created.
> > >
> > > Cluster configuration for "cluster" is not updated
> > > Region XYZ does not exist in the cluster configuration (or something to
> > > this effect).
> > >
> > > The command result would tell user exactly what happened and what not
> > > happened. The point is, a server's own cache.xml is NOT meant to be a
> > > "cluster" wide configuration. If customer is in the habit of starting
> up
> > > server with cache.xml but yet still want to have consistent
> region/index
> > > defined in the cluster, export a server's config and use that to start
> > > another server.
> > >
> > >
> > >
> > > On Fri, Apr 27, 2018 at 2:03 PM, Diane Hardman <dh...@pivotal.io>
> > > wrote:
> > >
> > >> I talked with Barbara and understand the long term effort to deprecate
> > >> cache.xml in favor of cluster config and I heartily agree.
> > >> I think a good step in that direction is to provide a migration tool
> for
> > >> users that reads all cache.xml files for current members and store
> them
> > in
> > >> cluster config, throwing exceptions and logging errors when region
> > >> definitions conflict (for the same region name) on different servers
> in
> > >> the
> > >> same cluster.
> > >> We might then consider removing the cache.xml files and rely on gfsh
> and
> > >> (in the future, hopefully) Java API's to keep cluster config
> up-to-date.
> > >>
> > >> Thanks!
> > >>
> > >> On Fri, Apr 27, 2018 at 12:56 PM, Jinmei Liao <ji...@pivotal.io>
> > wrote:
> > >>
> > >> > The decision is to go with the new behavior (I believe :-)). The
> > region
> > >> > does not exist in the cluster configuration to begin with since it's
> > not
> > >> > created using gfsh, so we have no way of checking unless we make an
> > >> extra
> > >> > trip to the region to find out what kind of region it is, but again
> > >> > different server might have different opinion about what it is.
> > >> >
> > >> > On Fri, Apr 27, 2018 at 12:49 PM, Diane Hardman <
> dhardman@pivotal.io>
> > >> > wrote:
> > >> >
> > >> > > Since we are working on enhancing Lucene support to allow adding a
> > >> Lucene
> > >> > > index to an existing region containing data, I am very interested
> in
> > >> the
> > >> > > decision here.
> > >> > > Like Mike, I also prefer keeping the original behavior of updating
> > >> > cluster
> > >> > > config with both the region and the index if it was not there
> > before.
> > >> > > Is there something preventing you from checking cluster config
> for a
> > >> > region
> > >> > > of the same name but different properties and, if so, throwing an
> > >> > exception
> > >> > > (or warning)
> > >> > > that cluster config could not be updated due to this collision?
> > >> > >
> > >> > > On Thu, Apr 19, 2018 at 3:35 PM, Michael Stolz <mstolz@pivotal.io
> >
> > >> > wrote:
> > >> > >
> > >> > > > Ok. Yes we do have to take the leap :)
> > >> > > > Let's keep thinking that way.
> > >> > > >
> > >> > > > --
> > >> > > > Mike Stolz
> > >> > > > Principal Engineer, GemFire Product Lead
> > >> > > > Mobile: +1-631-835-4771
> > >> > > > Download the GemFire book here.
> > >> > > > <https://content.pivotal.io/ebooks/scaling-data-services-
> > >> > > > with-pivotal-gemfire>
> > >> > > >
> > >> > > > On Thu, Apr 19, 2018 at 6:29 PM, Jinmei Liao <jiliao@pivotal.io
> >
> > >> > wrote:
> > >> > > >
> > >> > > > > but this proposed change is one of the effort toward
> > "deprecating
> > >> > > > > cache.xml". I think we've got to take the leap at one
> point.....
> > >> > > > >
> > >> > > > > On Thu, Apr 19, 2018 at 3:14 PM, Michael Stolz <
> > mstolz@pivotal.io
> > >> >
> > >> > > > wrote:
> > >> > > > >
> > >> > > > > > Hmmm...I think I liked the old behavior better. It was a
> kind
> > of
> > >> > > bridge
> > >> > > > > to
> > >> > > > > > cluster config.
> > >> > > > > >
> > >> > > > > > I still think we need to be putting much more effort into
> > >> > deprecating
> > >> > > > > > cache.xml and much less effort into fixing the (possibly)
> > >> hundreds
> > >> > of
> > >> > > > > bugs
> > >> > > > > > related to using both cache.xml and cluster configuration at
> > the
> > >> > same
> > >> > > > > time.
> > >> > > > > > If we can make cluster config complete enough, and deprecate
> > >> > > cache.xml,
> > >> > > > > > people will stop using cache.xml.
> > >> > > > > >
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > --
> > >> > > > > > Mike Stolz
> > >> > > > > > Principal Engineer, GemFire Product Lead
> > >> > > > > > Mobile: +1-631-835-4771
> > >> > > > > > Download the GemFire book here.
> > >> > > > > > <https://content.pivotal.io/ebooks/scaling-data-services-
> > >> > > > > > with-pivotal-gemfire>
> > >> > > > > >
> > >> > > > > > On Thu, Apr 19, 2018 at 5:58 PM, Jinmei Liao <
> > jiliao@pivotal.io
> > >> >
> > >> > > > wrote:
> > >> > > > > >
> > >> > > > > > > Scenario:
> > >> > > > > > > a locator with cluster configuration enabled and a server
> > >> started
> > >> > > > with
> > >> > > > > a
> > >> > > > > > > cache.xml that has /regionA defined and connected to this
> > >> > locator.
> > >> > > So
> > >> > > > > the
> > >> > > > > > > initial state is the locator has an empty cluster
> > >> configuration
> > >> > for
> > >> > > > the
> > >> > > > > > > cluster, but the server has a region defined in it's
> cache.
> > >> > > > > > >
> > >> > > > > > > Old behavior:
> > >> > > > > > > when user execute "create index --region=/regionA ...."
> > >> command
> > >> > > using
> > >> > > > > > gfsh,
> > >> > > > > > > the index creation is successful on the server, and the
> > server
> > >> > > > returns
> > >> > > > > a
> > >> > > > > > > xml section that contains both <region> and <index>
> > elements,
> > >> CC
> > >> > is
> > >> > > > > > updated
> > >> > > > > > > with this xml, so the end result is: both region and index
> > >> end up
> > >> > > in
> > >> > > > > the
> > >> > > > > > > cluster configuration.
> > >> > > > > > >
> > >> > > > > > > Problem with old behavior:
> > >> > > > > > > Not sure if the region is a cluster wide configuration.
> What
> > >> if a
> > >> > > > > region
> > >> > > > > > > with the same name, but different type exists on different
> > >> > servers?
> > >> > > > the
> > >> > > > > > xml
> > >> > > > > > > returned by different server might be different.
> > >> > > > > > >
> > >> > > > > > > New behavior:
> > >> > > > > > > when user execute "create index --region=/regionA ...."
> > >> command
> > >> > > using
> > >> > > > > > gfsh,
> > >> > > > > > > the index creation is successful on the server. We failed
> to
> > >> find
> > >> > > the
> > >> > > > > > > region in the existing cluster configuration, so cluster
> > >> > > > configuration
> > >> > > > > > will
> > >> > > > > > > NOT be updated.
> > >> > > > > > >
> > >> > > > > > > I would also suggest that this would not apply to index
> > alone,
> > >> > any
> > >> > > > > > element
> > >> > > > > > > inside region would have the same behavior change if we
> > >> approve
> > >> > > this.
> > >> > > > > > >
> > >> > > > > > > Thanks!
> > >> > > > > > >
> > >> > > > > > > --
> > >> > > > > > > Cheers
> > >> > > > > > >
> > >> > > > > > > Jinmei
> > >> > > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > > --
> > >> > > > > Cheers
> > >> > > > >
> > >> > > > > Jinmei
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Cheers
> > >> >
> > >> > Jinmei
> > >> >
> > >>
> > >
> > >
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>
--
Cheers
Jinmei
Re: [Proposal]: behavior change when region doesn't exist in cluster configuration
Posted by Nabarun Nag <nn...@apache.org>.
With the new implementation, will it allow two different regions with the
same exact name to exist in the cluster ?
I meant like server A had a cache.xml with region “test” with different
properties as to the cache.xml in server B for region “test”. And the
locator had an empty cluster config.
So now when servers A and B start, they will have different regions but the
same name “test”. Because there is no sync up with locator’s cluster config.
Pardon me if my understanding is wrong.
Regards
Nabarun
On Fri, Apr 27, 2018 at 2:23 PM Jinmei Liao <ji...@pivotal.io> wrote:
> My point is: we can't keep "mending" the wrong behavior, otherwise we can
> not move forward.
>
> On Fri, Apr 27, 2018 at 2:22 PM, Jinmei Liao <ji...@pivotal.io> wrote:
>
> > So the current behavior is, when a customer starts a server with
> cache.xml
> > that has a region defined, and then later on issues a gfsh command
> `create
> > index` on that region, the command output would be something like:
> > >create index .....
> > Member | Status
> > ----------------------------
> > server-1 | Index successfully created.
> >
> > Cluster configuration for "cluster" is not updated
> > Region XYZ does not exist in the cluster configuration (or something to
> > this effect).
> >
> > The command result would tell user exactly what happened and what not
> > happened. The point is, a server's own cache.xml is NOT meant to be a
> > "cluster" wide configuration. If customer is in the habit of starting up
> > server with cache.xml but yet still want to have consistent region/index
> > defined in the cluster, export a server's config and use that to start
> > another server.
> >
> >
> >
> > On Fri, Apr 27, 2018 at 2:03 PM, Diane Hardman <dh...@pivotal.io>
> > wrote:
> >
> >> I talked with Barbara and understand the long term effort to deprecate
> >> cache.xml in favor of cluster config and I heartily agree.
> >> I think a good step in that direction is to provide a migration tool for
> >> users that reads all cache.xml files for current members and store them
> in
> >> cluster config, throwing exceptions and logging errors when region
> >> definitions conflict (for the same region name) on different servers in
> >> the
> >> same cluster.
> >> We might then consider removing the cache.xml files and rely on gfsh and
> >> (in the future, hopefully) Java API's to keep cluster config up-to-date.
> >>
> >> Thanks!
> >>
> >> On Fri, Apr 27, 2018 at 12:56 PM, Jinmei Liao <ji...@pivotal.io>
> wrote:
> >>
> >> > The decision is to go with the new behavior (I believe :-)). The
> region
> >> > does not exist in the cluster configuration to begin with since it's
> not
> >> > created using gfsh, so we have no way of checking unless we make an
> >> extra
> >> > trip to the region to find out what kind of region it is, but again
> >> > different server might have different opinion about what it is.
> >> >
> >> > On Fri, Apr 27, 2018 at 12:49 PM, Diane Hardman <dh...@pivotal.io>
> >> > wrote:
> >> >
> >> > > Since we are working on enhancing Lucene support to allow adding a
> >> Lucene
> >> > > index to an existing region containing data, I am very interested in
> >> the
> >> > > decision here.
> >> > > Like Mike, I also prefer keeping the original behavior of updating
> >> > cluster
> >> > > config with both the region and the index if it was not there
> before.
> >> > > Is there something preventing you from checking cluster config for a
> >> > region
> >> > > of the same name but different properties and, if so, throwing an
> >> > exception
> >> > > (or warning)
> >> > > that cluster config could not be updated due to this collision?
> >> > >
> >> > > On Thu, Apr 19, 2018 at 3:35 PM, Michael Stolz <ms...@pivotal.io>
> >> > wrote:
> >> > >
> >> > > > Ok. Yes we do have to take the leap :)
> >> > > > Let's keep thinking that way.
> >> > > >
> >> > > > --
> >> > > > Mike Stolz
> >> > > > Principal Engineer, GemFire Product Lead
> >> > > > Mobile: +1-631-835-4771
> >> > > > Download the GemFire book here.
> >> > > > <https://content.pivotal.io/ebooks/scaling-data-services-
> >> > > > with-pivotal-gemfire>
> >> > > >
> >> > > > On Thu, Apr 19, 2018 at 6:29 PM, Jinmei Liao <ji...@pivotal.io>
> >> > wrote:
> >> > > >
> >> > > > > but this proposed change is one of the effort toward
> "deprecating
> >> > > > > cache.xml". I think we've got to take the leap at one point.....
> >> > > > >
> >> > > > > On Thu, Apr 19, 2018 at 3:14 PM, Michael Stolz <
> mstolz@pivotal.io
> >> >
> >> > > > wrote:
> >> > > > >
> >> > > > > > Hmmm...I think I liked the old behavior better. It was a kind
> of
> >> > > bridge
> >> > > > > to
> >> > > > > > cluster config.
> >> > > > > >
> >> > > > > > I still think we need to be putting much more effort into
> >> > deprecating
> >> > > > > > cache.xml and much less effort into fixing the (possibly)
> >> hundreds
> >> > of
> >> > > > > bugs
> >> > > > > > related to using both cache.xml and cluster configuration at
> the
> >> > same
> >> > > > > time.
> >> > > > > > If we can make cluster config complete enough, and deprecate
> >> > > cache.xml,
> >> > > > > > people will stop using cache.xml.
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > --
> >> > > > > > Mike Stolz
> >> > > > > > Principal Engineer, GemFire Product Lead
> >> > > > > > Mobile: +1-631-835-4771
> >> > > > > > Download the GemFire book here.
> >> > > > > > <https://content.pivotal.io/ebooks/scaling-data-services-
> >> > > > > > with-pivotal-gemfire>
> >> > > > > >
> >> > > > > > On Thu, Apr 19, 2018 at 5:58 PM, Jinmei Liao <
> jiliao@pivotal.io
> >> >
> >> > > > wrote:
> >> > > > > >
> >> > > > > > > Scenario:
> >> > > > > > > a locator with cluster configuration enabled and a server
> >> started
> >> > > > with
> >> > > > > a
> >> > > > > > > cache.xml that has /regionA defined and connected to this
> >> > locator.
> >> > > So
> >> > > > > the
> >> > > > > > > initial state is the locator has an empty cluster
> >> configuration
> >> > for
> >> > > > the
> >> > > > > > > cluster, but the server has a region defined in it's cache.
> >> > > > > > >
> >> > > > > > > Old behavior:
> >> > > > > > > when user execute "create index --region=/regionA ...."
> >> command
> >> > > using
> >> > > > > > gfsh,
> >> > > > > > > the index creation is successful on the server, and the
> server
> >> > > > returns
> >> > > > > a
> >> > > > > > > xml section that contains both <region> and <index>
> elements,
> >> CC
> >> > is
> >> > > > > > updated
> >> > > > > > > with this xml, so the end result is: both region and index
> >> end up
> >> > > in
> >> > > > > the
> >> > > > > > > cluster configuration.
> >> > > > > > >
> >> > > > > > > Problem with old behavior:
> >> > > > > > > Not sure if the region is a cluster wide configuration. What
> >> if a
> >> > > > > region
> >> > > > > > > with the same name, but different type exists on different
> >> > servers?
> >> > > > the
> >> > > > > > xml
> >> > > > > > > returned by different server might be different.
> >> > > > > > >
> >> > > > > > > New behavior:
> >> > > > > > > when user execute "create index --region=/regionA ...."
> >> command
> >> > > using
> >> > > > > > gfsh,
> >> > > > > > > the index creation is successful on the server. We failed to
> >> find
> >> > > the
> >> > > > > > > region in the existing cluster configuration, so cluster
> >> > > > configuration
> >> > > > > > will
> >> > > > > > > NOT be updated.
> >> > > > > > >
> >> > > > > > > I would also suggest that this would not apply to index
> alone,
> >> > any
> >> > > > > > element
> >> > > > > > > inside region would have the same behavior change if we
> >> approve
> >> > > this.
> >> > > > > > >
> >> > > > > > > Thanks!
> >> > > > > > >
> >> > > > > > > --
> >> > > > > > > Cheers
> >> > > > > > >
> >> > > > > > > Jinmei
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > > --
> >> > > > > Cheers
> >> > > > >
> >> > > > > Jinmei
> >> > > > >
> >> > > >
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > Cheers
> >> >
> >> > Jinmei
> >> >
> >>
> >
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>
>
>
> --
> Cheers
>
> Jinmei
>
Re: [Proposal]: behavior change when region doesn't exist in cluster configuration
Posted by Jinmei Liao <ji...@pivotal.io>.
My point is: we can't keep "mending" the wrong behavior, otherwise we can
not move forward.
On Fri, Apr 27, 2018 at 2:22 PM, Jinmei Liao <ji...@pivotal.io> wrote:
> So the current behavior is, when a customer starts a server with cache.xml
> that has a region defined, and then later on issues a gfsh command `create
> index` on that region, the command output would be something like:
> >create index .....
> Member | Status
> ----------------------------
> server-1 | Index successfully created.
>
> Cluster configuration for "cluster" is not updated
> Region XYZ does not exist in the cluster configuration (or something to
> this effect).
>
> The command result would tell user exactly what happened and what not
> happened. The point is, a server's own cache.xml is NOT meant to be a
> "cluster" wide configuration. If customer is in the habit of starting up
> server with cache.xml but yet still want to have consistent region/index
> defined in the cluster, export a server's config and use that to start
> another server.
>
>
>
> On Fri, Apr 27, 2018 at 2:03 PM, Diane Hardman <dh...@pivotal.io>
> wrote:
>
>> I talked with Barbara and understand the long term effort to deprecate
>> cache.xml in favor of cluster config and I heartily agree.
>> I think a good step in that direction is to provide a migration tool for
>> users that reads all cache.xml files for current members and store them in
>> cluster config, throwing exceptions and logging errors when region
>> definitions conflict (for the same region name) on different servers in
>> the
>> same cluster.
>> We might then consider removing the cache.xml files and rely on gfsh and
>> (in the future, hopefully) Java API's to keep cluster config up-to-date.
>>
>> Thanks!
>>
>> On Fri, Apr 27, 2018 at 12:56 PM, Jinmei Liao <ji...@pivotal.io> wrote:
>>
>> > The decision is to go with the new behavior (I believe :-)). The region
>> > does not exist in the cluster configuration to begin with since it's not
>> > created using gfsh, so we have no way of checking unless we make an
>> extra
>> > trip to the region to find out what kind of region it is, but again
>> > different server might have different opinion about what it is.
>> >
>> > On Fri, Apr 27, 2018 at 12:49 PM, Diane Hardman <dh...@pivotal.io>
>> > wrote:
>> >
>> > > Since we are working on enhancing Lucene support to allow adding a
>> Lucene
>> > > index to an existing region containing data, I am very interested in
>> the
>> > > decision here.
>> > > Like Mike, I also prefer keeping the original behavior of updating
>> > cluster
>> > > config with both the region and the index if it was not there before.
>> > > Is there something preventing you from checking cluster config for a
>> > region
>> > > of the same name but different properties and, if so, throwing an
>> > exception
>> > > (or warning)
>> > > that cluster config could not be updated due to this collision?
>> > >
>> > > On Thu, Apr 19, 2018 at 3:35 PM, Michael Stolz <ms...@pivotal.io>
>> > wrote:
>> > >
>> > > > Ok. Yes we do have to take the leap :)
>> > > > Let's keep thinking that way.
>> > > >
>> > > > --
>> > > > Mike Stolz
>> > > > Principal Engineer, GemFire Product Lead
>> > > > Mobile: +1-631-835-4771
>> > > > Download the GemFire book here.
>> > > > <https://content.pivotal.io/ebooks/scaling-data-services-
>> > > > with-pivotal-gemfire>
>> > > >
>> > > > On Thu, Apr 19, 2018 at 6:29 PM, Jinmei Liao <ji...@pivotal.io>
>> > wrote:
>> > > >
>> > > > > but this proposed change is one of the effort toward "deprecating
>> > > > > cache.xml". I think we've got to take the leap at one point.....
>> > > > >
>> > > > > On Thu, Apr 19, 2018 at 3:14 PM, Michael Stolz <mstolz@pivotal.io
>> >
>> > > > wrote:
>> > > > >
>> > > > > > Hmmm...I think I liked the old behavior better. It was a kind of
>> > > bridge
>> > > > > to
>> > > > > > cluster config.
>> > > > > >
>> > > > > > I still think we need to be putting much more effort into
>> > deprecating
>> > > > > > cache.xml and much less effort into fixing the (possibly)
>> hundreds
>> > of
>> > > > > bugs
>> > > > > > related to using both cache.xml and cluster configuration at the
>> > same
>> > > > > time.
>> > > > > > If we can make cluster config complete enough, and deprecate
>> > > cache.xml,
>> > > > > > people will stop using cache.xml.
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > --
>> > > > > > Mike Stolz
>> > > > > > Principal Engineer, GemFire Product Lead
>> > > > > > Mobile: +1-631-835-4771
>> > > > > > Download the GemFire book here.
>> > > > > > <https://content.pivotal.io/ebooks/scaling-data-services-
>> > > > > > with-pivotal-gemfire>
>> > > > > >
>> > > > > > On Thu, Apr 19, 2018 at 5:58 PM, Jinmei Liao <jiliao@pivotal.io
>> >
>> > > > wrote:
>> > > > > >
>> > > > > > > Scenario:
>> > > > > > > a locator with cluster configuration enabled and a server
>> started
>> > > > with
>> > > > > a
>> > > > > > > cache.xml that has /regionA defined and connected to this
>> > locator.
>> > > So
>> > > > > the
>> > > > > > > initial state is the locator has an empty cluster
>> configuration
>> > for
>> > > > the
>> > > > > > > cluster, but the server has a region defined in it's cache.
>> > > > > > >
>> > > > > > > Old behavior:
>> > > > > > > when user execute "create index --region=/regionA ...."
>> command
>> > > using
>> > > > > > gfsh,
>> > > > > > > the index creation is successful on the server, and the server
>> > > > returns
>> > > > > a
>> > > > > > > xml section that contains both <region> and <index> elements,
>> CC
>> > is
>> > > > > > updated
>> > > > > > > with this xml, so the end result is: both region and index
>> end up
>> > > in
>> > > > > the
>> > > > > > > cluster configuration.
>> > > > > > >
>> > > > > > > Problem with old behavior:
>> > > > > > > Not sure if the region is a cluster wide configuration. What
>> if a
>> > > > > region
>> > > > > > > with the same name, but different type exists on different
>> > servers?
>> > > > the
>> > > > > > xml
>> > > > > > > returned by different server might be different.
>> > > > > > >
>> > > > > > > New behavior:
>> > > > > > > when user execute "create index --region=/regionA ...."
>> command
>> > > using
>> > > > > > gfsh,
>> > > > > > > the index creation is successful on the server. We failed to
>> find
>> > > the
>> > > > > > > region in the existing cluster configuration, so cluster
>> > > > configuration
>> > > > > > will
>> > > > > > > NOT be updated.
>> > > > > > >
>> > > > > > > I would also suggest that this would not apply to index alone,
>> > any
>> > > > > > element
>> > > > > > > inside region would have the same behavior change if we
>> approve
>> > > this.
>> > > > > > >
>> > > > > > > Thanks!
>> > > > > > >
>> > > > > > > --
>> > > > > > > Cheers
>> > > > > > >
>> > > > > > > Jinmei
>> > > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > > Cheers
>> > > > >
>> > > > > Jinmei
>> > > > >
>> > > >
>> > >
>> >
>> >
>> >
>> > --
>> > Cheers
>> >
>> > Jinmei
>> >
>>
>
>
>
> --
> Cheers
>
> Jinmei
>
--
Cheers
Jinmei
Re: [Proposal]: behavior change when region doesn't exist in cluster configuration
Posted by Jinmei Liao <ji...@pivotal.io>.
So the current behavior is, when a customer starts a server with cache.xml
that has a region defined, and then later on issues a gfsh command `create
index` on that region, the command output would be something like:
>create index .....
Member | Status
----------------------------
server-1 | Index successfully created.
Cluster configuration for "cluster" is not updated
Region XYZ does not exist in the cluster configuration (or something to
this effect).
The command result would tell user exactly what happened and what not
happened. The point is, a server's own cache.xml is NOT meant to be a
"cluster" wide configuration. If customer is in the habit of starting up
server with cache.xml but yet still want to have consistent region/index
defined in the cluster, export a server's config and use that to start
another server.
On Fri, Apr 27, 2018 at 2:03 PM, Diane Hardman <dh...@pivotal.io> wrote:
> I talked with Barbara and understand the long term effort to deprecate
> cache.xml in favor of cluster config and I heartily agree.
> I think a good step in that direction is to provide a migration tool for
> users that reads all cache.xml files for current members and store them in
> cluster config, throwing exceptions and logging errors when region
> definitions conflict (for the same region name) on different servers in the
> same cluster.
> We might then consider removing the cache.xml files and rely on gfsh and
> (in the future, hopefully) Java API's to keep cluster config up-to-date.
>
> Thanks!
>
> On Fri, Apr 27, 2018 at 12:56 PM, Jinmei Liao <ji...@pivotal.io> wrote:
>
> > The decision is to go with the new behavior (I believe :-)). The region
> > does not exist in the cluster configuration to begin with since it's not
> > created using gfsh, so we have no way of checking unless we make an extra
> > trip to the region to find out what kind of region it is, but again
> > different server might have different opinion about what it is.
> >
> > On Fri, Apr 27, 2018 at 12:49 PM, Diane Hardman <dh...@pivotal.io>
> > wrote:
> >
> > > Since we are working on enhancing Lucene support to allow adding a
> Lucene
> > > index to an existing region containing data, I am very interested in
> the
> > > decision here.
> > > Like Mike, I also prefer keeping the original behavior of updating
> > cluster
> > > config with both the region and the index if it was not there before.
> > > Is there something preventing you from checking cluster config for a
> > region
> > > of the same name but different properties and, if so, throwing an
> > exception
> > > (or warning)
> > > that cluster config could not be updated due to this collision?
> > >
> > > On Thu, Apr 19, 2018 at 3:35 PM, Michael Stolz <ms...@pivotal.io>
> > wrote:
> > >
> > > > Ok. Yes we do have to take the leap :)
> > > > Let's keep thinking that way.
> > > >
> > > > --
> > > > Mike Stolz
> > > > Principal Engineer, GemFire Product Lead
> > > > Mobile: +1-631-835-4771
> > > > Download the GemFire book here.
> > > > <https://content.pivotal.io/ebooks/scaling-data-services-
> > > > with-pivotal-gemfire>
> > > >
> > > > On Thu, Apr 19, 2018 at 6:29 PM, Jinmei Liao <ji...@pivotal.io>
> > wrote:
> > > >
> > > > > but this proposed change is one of the effort toward "deprecating
> > > > > cache.xml". I think we've got to take the leap at one point.....
> > > > >
> > > > > On Thu, Apr 19, 2018 at 3:14 PM, Michael Stolz <ms...@pivotal.io>
> > > > wrote:
> > > > >
> > > > > > Hmmm...I think I liked the old behavior better. It was a kind of
> > > bridge
> > > > > to
> > > > > > cluster config.
> > > > > >
> > > > > > I still think we need to be putting much more effort into
> > deprecating
> > > > > > cache.xml and much less effort into fixing the (possibly)
> hundreds
> > of
> > > > > bugs
> > > > > > related to using both cache.xml and cluster configuration at the
> > same
> > > > > time.
> > > > > > If we can make cluster config complete enough, and deprecate
> > > cache.xml,
> > > > > > people will stop using cache.xml.
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Mike Stolz
> > > > > > Principal Engineer, GemFire Product Lead
> > > > > > Mobile: +1-631-835-4771
> > > > > > Download the GemFire book here.
> > > > > > <https://content.pivotal.io/ebooks/scaling-data-services-
> > > > > > with-pivotal-gemfire>
> > > > > >
> > > > > > On Thu, Apr 19, 2018 at 5:58 PM, Jinmei Liao <ji...@pivotal.io>
> > > > wrote:
> > > > > >
> > > > > > > Scenario:
> > > > > > > a locator with cluster configuration enabled and a server
> started
> > > > with
> > > > > a
> > > > > > > cache.xml that has /regionA defined and connected to this
> > locator.
> > > So
> > > > > the
> > > > > > > initial state is the locator has an empty cluster configuration
> > for
> > > > the
> > > > > > > cluster, but the server has a region defined in it's cache.
> > > > > > >
> > > > > > > Old behavior:
> > > > > > > when user execute "create index --region=/regionA ...." command
> > > using
> > > > > > gfsh,
> > > > > > > the index creation is successful on the server, and the server
> > > > returns
> > > > > a
> > > > > > > xml section that contains both <region> and <index> elements,
> CC
> > is
> > > > > > updated
> > > > > > > with this xml, so the end result is: both region and index end
> up
> > > in
> > > > > the
> > > > > > > cluster configuration.
> > > > > > >
> > > > > > > Problem with old behavior:
> > > > > > > Not sure if the region is a cluster wide configuration. What
> if a
> > > > > region
> > > > > > > with the same name, but different type exists on different
> > servers?
> > > > the
> > > > > > xml
> > > > > > > returned by different server might be different.
> > > > > > >
> > > > > > > New behavior:
> > > > > > > when user execute "create index --region=/regionA ...." command
> > > using
> > > > > > gfsh,
> > > > > > > the index creation is successful on the server. We failed to
> find
> > > the
> > > > > > > region in the existing cluster configuration, so cluster
> > > > configuration
> > > > > > will
> > > > > > > NOT be updated.
> > > > > > >
> > > > > > > I would also suggest that this would not apply to index alone,
> > any
> > > > > > element
> > > > > > > inside region would have the same behavior change if we approve
> > > this.
> > > > > > >
> > > > > > > Thanks!
> > > > > > >
> > > > > > > --
> > > > > > > Cheers
> > > > > > >
> > > > > > > Jinmei
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Cheers
> > > > >
> > > > > Jinmei
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>
--
Cheers
Jinmei
Re: [Proposal]: behavior change when region doesn't exist in cluster configuration
Posted by John Blum <jb...@pivotal.io>.
I would also ask/remind us to carefully consider anything that might be
needed, or required, in the API as well.
We must thoughtfully compliment the, or a, API (i.e. programmatically) with
anything you can do in/from *Gfsh*.
The API is a first class citizen and how most users will consume product,
and arguably the most important asset, IMO, more so than any tool/service.
-j
On Fri, Apr 27, 2018 at 2:03 PM, Diane Hardman <dh...@pivotal.io> wrote:
> I talked with Barbara and understand the long term effort to deprecate
> cache.xml in favor of cluster config and I heartily agree.
> I think a good step in that direction is to provide a migration tool for
> users that reads all cache.xml files for current members and store them in
> cluster config, throwing exceptions and logging errors when region
> definitions conflict (for the same region name) on different servers in the
> same cluster.
> We might then consider removing the cache.xml files and rely on gfsh and
> (in the future, hopefully) Java API's to keep cluster config up-to-date.
>
> Thanks!
>
> On Fri, Apr 27, 2018 at 12:56 PM, Jinmei Liao <ji...@pivotal.io> wrote:
>
> > The decision is to go with the new behavior (I believe :-)). The region
> > does not exist in the cluster configuration to begin with since it's not
> > created using gfsh, so we have no way of checking unless we make an extra
> > trip to the region to find out what kind of region it is, but again
> > different server might have different opinion about what it is.
> >
> > On Fri, Apr 27, 2018 at 12:49 PM, Diane Hardman <dh...@pivotal.io>
> > wrote:
> >
> > > Since we are working on enhancing Lucene support to allow adding a
> Lucene
> > > index to an existing region containing data, I am very interested in
> the
> > > decision here.
> > > Like Mike, I also prefer keeping the original behavior of updating
> > cluster
> > > config with both the region and the index if it was not there before.
> > > Is there something preventing you from checking cluster config for a
> > region
> > > of the same name but different properties and, if so, throwing an
> > exception
> > > (or warning)
> > > that cluster config could not be updated due to this collision?
> > >
> > > On Thu, Apr 19, 2018 at 3:35 PM, Michael Stolz <ms...@pivotal.io>
> > wrote:
> > >
> > > > Ok. Yes we do have to take the leap :)
> > > > Let's keep thinking that way.
> > > >
> > > > --
> > > > Mike Stolz
> > > > Principal Engineer, GemFire Product Lead
> > > > Mobile: +1-631-835-4771
> > > > Download the GemFire book here.
> > > > <https://content.pivotal.io/ebooks/scaling-data-services-
> > > > with-pivotal-gemfire>
> > > >
> > > > On Thu, Apr 19, 2018 at 6:29 PM, Jinmei Liao <ji...@pivotal.io>
> > wrote:
> > > >
> > > > > but this proposed change is one of the effort toward "deprecating
> > > > > cache.xml". I think we've got to take the leap at one point.....
> > > > >
> > > > > On Thu, Apr 19, 2018 at 3:14 PM, Michael Stolz <ms...@pivotal.io>
> > > > wrote:
> > > > >
> > > > > > Hmmm...I think I liked the old behavior better. It was a kind of
> > > bridge
> > > > > to
> > > > > > cluster config.
> > > > > >
> > > > > > I still think we need to be putting much more effort into
> > deprecating
> > > > > > cache.xml and much less effort into fixing the (possibly)
> hundreds
> > of
> > > > > bugs
> > > > > > related to using both cache.xml and cluster configuration at the
> > same
> > > > > time.
> > > > > > If we can make cluster config complete enough, and deprecate
> > > cache.xml,
> > > > > > people will stop using cache.xml.
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Mike Stolz
> > > > > > Principal Engineer, GemFire Product Lead
> > > > > > Mobile: +1-631-835-4771
> > > > > > Download the GemFire book here.
> > > > > > <https://content.pivotal.io/ebooks/scaling-data-services-
> > > > > > with-pivotal-gemfire>
> > > > > >
> > > > > > On Thu, Apr 19, 2018 at 5:58 PM, Jinmei Liao <ji...@pivotal.io>
> > > > wrote:
> > > > > >
> > > > > > > Scenario:
> > > > > > > a locator with cluster configuration enabled and a server
> started
> > > > with
> > > > > a
> > > > > > > cache.xml that has /regionA defined and connected to this
> > locator.
> > > So
> > > > > the
> > > > > > > initial state is the locator has an empty cluster configuration
> > for
> > > > the
> > > > > > > cluster, but the server has a region defined in it's cache.
> > > > > > >
> > > > > > > Old behavior:
> > > > > > > when user execute "create index --region=/regionA ...." command
> > > using
> > > > > > gfsh,
> > > > > > > the index creation is successful on the server, and the server
> > > > returns
> > > > > a
> > > > > > > xml section that contains both <region> and <index> elements,
> CC
> > is
> > > > > > updated
> > > > > > > with this xml, so the end result is: both region and index end
> up
> > > in
> > > > > the
> > > > > > > cluster configuration.
> > > > > > >
> > > > > > > Problem with old behavior:
> > > > > > > Not sure if the region is a cluster wide configuration. What
> if a
> > > > > region
> > > > > > > with the same name, but different type exists on different
> > servers?
> > > > the
> > > > > > xml
> > > > > > > returned by different server might be different.
> > > > > > >
> > > > > > > New behavior:
> > > > > > > when user execute "create index --region=/regionA ...." command
> > > using
> > > > > > gfsh,
> > > > > > > the index creation is successful on the server. We failed to
> find
> > > the
> > > > > > > region in the existing cluster configuration, so cluster
> > > > configuration
> > > > > > will
> > > > > > > NOT be updated.
> > > > > > >
> > > > > > > I would also suggest that this would not apply to index alone,
> > any
> > > > > > element
> > > > > > > inside region would have the same behavior change if we approve
> > > this.
> > > > > > >
> > > > > > > Thanks!
> > > > > > >
> > > > > > > --
> > > > > > > Cheers
> > > > > > >
> > > > > > > Jinmei
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Cheers
> > > > >
> > > > > Jinmei
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>
--
-John
john.blum10101 (skype)
Re: [Proposal]: behavior change when region doesn't exist in cluster configuration
Posted by Diane Hardman <dh...@pivotal.io>.
I talked with Barbara and understand the long term effort to deprecate
cache.xml in favor of cluster config and I heartily agree.
I think a good step in that direction is to provide a migration tool for
users that reads all cache.xml files for current members and store them in
cluster config, throwing exceptions and logging errors when region
definitions conflict (for the same region name) on different servers in the
same cluster.
We might then consider removing the cache.xml files and rely on gfsh and
(in the future, hopefully) Java API's to keep cluster config up-to-date.
Thanks!
On Fri, Apr 27, 2018 at 12:56 PM, Jinmei Liao <ji...@pivotal.io> wrote:
> The decision is to go with the new behavior (I believe :-)). The region
> does not exist in the cluster configuration to begin with since it's not
> created using gfsh, so we have no way of checking unless we make an extra
> trip to the region to find out what kind of region it is, but again
> different server might have different opinion about what it is.
>
> On Fri, Apr 27, 2018 at 12:49 PM, Diane Hardman <dh...@pivotal.io>
> wrote:
>
> > Since we are working on enhancing Lucene support to allow adding a Lucene
> > index to an existing region containing data, I am very interested in the
> > decision here.
> > Like Mike, I also prefer keeping the original behavior of updating
> cluster
> > config with both the region and the index if it was not there before.
> > Is there something preventing you from checking cluster config for a
> region
> > of the same name but different properties and, if so, throwing an
> exception
> > (or warning)
> > that cluster config could not be updated due to this collision?
> >
> > On Thu, Apr 19, 2018 at 3:35 PM, Michael Stolz <ms...@pivotal.io>
> wrote:
> >
> > > Ok. Yes we do have to take the leap :)
> > > Let's keep thinking that way.
> > >
> > > --
> > > Mike Stolz
> > > Principal Engineer, GemFire Product Lead
> > > Mobile: +1-631-835-4771
> > > Download the GemFire book here.
> > > <https://content.pivotal.io/ebooks/scaling-data-services-
> > > with-pivotal-gemfire>
> > >
> > > On Thu, Apr 19, 2018 at 6:29 PM, Jinmei Liao <ji...@pivotal.io>
> wrote:
> > >
> > > > but this proposed change is one of the effort toward "deprecating
> > > > cache.xml". I think we've got to take the leap at one point.....
> > > >
> > > > On Thu, Apr 19, 2018 at 3:14 PM, Michael Stolz <ms...@pivotal.io>
> > > wrote:
> > > >
> > > > > Hmmm...I think I liked the old behavior better. It was a kind of
> > bridge
> > > > to
> > > > > cluster config.
> > > > >
> > > > > I still think we need to be putting much more effort into
> deprecating
> > > > > cache.xml and much less effort into fixing the (possibly) hundreds
> of
> > > > bugs
> > > > > related to using both cache.xml and cluster configuration at the
> same
> > > > time.
> > > > > If we can make cluster config complete enough, and deprecate
> > cache.xml,
> > > > > people will stop using cache.xml.
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Mike Stolz
> > > > > Principal Engineer, GemFire Product Lead
> > > > > Mobile: +1-631-835-4771
> > > > > Download the GemFire book here.
> > > > > <https://content.pivotal.io/ebooks/scaling-data-services-
> > > > > with-pivotal-gemfire>
> > > > >
> > > > > On Thu, Apr 19, 2018 at 5:58 PM, Jinmei Liao <ji...@pivotal.io>
> > > wrote:
> > > > >
> > > > > > Scenario:
> > > > > > a locator with cluster configuration enabled and a server started
> > > with
> > > > a
> > > > > > cache.xml that has /regionA defined and connected to this
> locator.
> > So
> > > > the
> > > > > > initial state is the locator has an empty cluster configuration
> for
> > > the
> > > > > > cluster, but the server has a region defined in it's cache.
> > > > > >
> > > > > > Old behavior:
> > > > > > when user execute "create index --region=/regionA ...." command
> > using
> > > > > gfsh,
> > > > > > the index creation is successful on the server, and the server
> > > returns
> > > > a
> > > > > > xml section that contains both <region> and <index> elements, CC
> is
> > > > > updated
> > > > > > with this xml, so the end result is: both region and index end up
> > in
> > > > the
> > > > > > cluster configuration.
> > > > > >
> > > > > > Problem with old behavior:
> > > > > > Not sure if the region is a cluster wide configuration. What if a
> > > > region
> > > > > > with the same name, but different type exists on different
> servers?
> > > the
> > > > > xml
> > > > > > returned by different server might be different.
> > > > > >
> > > > > > New behavior:
> > > > > > when user execute "create index --region=/regionA ...." command
> > using
> > > > > gfsh,
> > > > > > the index creation is successful on the server. We failed to find
> > the
> > > > > > region in the existing cluster configuration, so cluster
> > > configuration
> > > > > will
> > > > > > NOT be updated.
> > > > > >
> > > > > > I would also suggest that this would not apply to index alone,
> any
> > > > > element
> > > > > > inside region would have the same behavior change if we approve
> > this.
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > > > --
> > > > > > Cheers
> > > > > >
> > > > > > Jinmei
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Cheers
> > > >
> > > > Jinmei
> > > >
> > >
> >
>
>
>
> --
> Cheers
>
> Jinmei
>
Re: [Proposal]: behavior change when region doesn't exist in cluster configuration
Posted by Jinmei Liao <ji...@pivotal.io>.
The decision is to go with the new behavior (I believe :-)). The region
does not exist in the cluster configuration to begin with since it's not
created using gfsh, so we have no way of checking unless we make an extra
trip to the region to find out what kind of region it is, but again
different server might have different opinion about what it is.
On Fri, Apr 27, 2018 at 12:49 PM, Diane Hardman <dh...@pivotal.io> wrote:
> Since we are working on enhancing Lucene support to allow adding a Lucene
> index to an existing region containing data, I am very interested in the
> decision here.
> Like Mike, I also prefer keeping the original behavior of updating cluster
> config with both the region and the index if it was not there before.
> Is there something preventing you from checking cluster config for a region
> of the same name but different properties and, if so, throwing an exception
> (or warning)
> that cluster config could not be updated due to this collision?
>
> On Thu, Apr 19, 2018 at 3:35 PM, Michael Stolz <ms...@pivotal.io> wrote:
>
> > Ok. Yes we do have to take the leap :)
> > Let's keep thinking that way.
> >
> > --
> > Mike Stolz
> > Principal Engineer, GemFire Product Lead
> > Mobile: +1-631-835-4771
> > Download the GemFire book here.
> > <https://content.pivotal.io/ebooks/scaling-data-services-
> > with-pivotal-gemfire>
> >
> > On Thu, Apr 19, 2018 at 6:29 PM, Jinmei Liao <ji...@pivotal.io> wrote:
> >
> > > but this proposed change is one of the effort toward "deprecating
> > > cache.xml". I think we've got to take the leap at one point.....
> > >
> > > On Thu, Apr 19, 2018 at 3:14 PM, Michael Stolz <ms...@pivotal.io>
> > wrote:
> > >
> > > > Hmmm...I think I liked the old behavior better. It was a kind of
> bridge
> > > to
> > > > cluster config.
> > > >
> > > > I still think we need to be putting much more effort into deprecating
> > > > cache.xml and much less effort into fixing the (possibly) hundreds of
> > > bugs
> > > > related to using both cache.xml and cluster configuration at the same
> > > time.
> > > > If we can make cluster config complete enough, and deprecate
> cache.xml,
> > > > people will stop using cache.xml.
> > > >
> > > >
> > > >
> > > > --
> > > > Mike Stolz
> > > > Principal Engineer, GemFire Product Lead
> > > > Mobile: +1-631-835-4771
> > > > Download the GemFire book here.
> > > > <https://content.pivotal.io/ebooks/scaling-data-services-
> > > > with-pivotal-gemfire>
> > > >
> > > > On Thu, Apr 19, 2018 at 5:58 PM, Jinmei Liao <ji...@pivotal.io>
> > wrote:
> > > >
> > > > > Scenario:
> > > > > a locator with cluster configuration enabled and a server started
> > with
> > > a
> > > > > cache.xml that has /regionA defined and connected to this locator.
> So
> > > the
> > > > > initial state is the locator has an empty cluster configuration for
> > the
> > > > > cluster, but the server has a region defined in it's cache.
> > > > >
> > > > > Old behavior:
> > > > > when user execute "create index --region=/regionA ...." command
> using
> > > > gfsh,
> > > > > the index creation is successful on the server, and the server
> > returns
> > > a
> > > > > xml section that contains both <region> and <index> elements, CC is
> > > > updated
> > > > > with this xml, so the end result is: both region and index end up
> in
> > > the
> > > > > cluster configuration.
> > > > >
> > > > > Problem with old behavior:
> > > > > Not sure if the region is a cluster wide configuration. What if a
> > > region
> > > > > with the same name, but different type exists on different servers?
> > the
> > > > xml
> > > > > returned by different server might be different.
> > > > >
> > > > > New behavior:
> > > > > when user execute "create index --region=/regionA ...." command
> using
> > > > gfsh,
> > > > > the index creation is successful on the server. We failed to find
> the
> > > > > region in the existing cluster configuration, so cluster
> > configuration
> > > > will
> > > > > NOT be updated.
> > > > >
> > > > > I would also suggest that this would not apply to index alone, any
> > > > element
> > > > > inside region would have the same behavior change if we approve
> this.
> > > > >
> > > > > Thanks!
> > > > >
> > > > > --
> > > > > Cheers
> > > > >
> > > > > Jinmei
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
>
--
Cheers
Jinmei
Re: [Proposal]: behavior change when region doesn't exist in cluster configuration
Posted by Diane Hardman <dh...@pivotal.io>.
Since we are working on enhancing Lucene support to allow adding a Lucene
index to an existing region containing data, I am very interested in the
decision here.
Like Mike, I also prefer keeping the original behavior of updating cluster
config with both the region and the index if it was not there before.
Is there something preventing you from checking cluster config for a region
of the same name but different properties and, if so, throwing an exception
(or warning)
that cluster config could not be updated due to this collision?
On Thu, Apr 19, 2018 at 3:35 PM, Michael Stolz <ms...@pivotal.io> wrote:
> Ok. Yes we do have to take the leap :)
> Let's keep thinking that way.
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Lead
> Mobile: +1-631-835-4771
> Download the GemFire book here.
> <https://content.pivotal.io/ebooks/scaling-data-services-
> with-pivotal-gemfire>
>
> On Thu, Apr 19, 2018 at 6:29 PM, Jinmei Liao <ji...@pivotal.io> wrote:
>
> > but this proposed change is one of the effort toward "deprecating
> > cache.xml". I think we've got to take the leap at one point.....
> >
> > On Thu, Apr 19, 2018 at 3:14 PM, Michael Stolz <ms...@pivotal.io>
> wrote:
> >
> > > Hmmm...I think I liked the old behavior better. It was a kind of bridge
> > to
> > > cluster config.
> > >
> > > I still think we need to be putting much more effort into deprecating
> > > cache.xml and much less effort into fixing the (possibly) hundreds of
> > bugs
> > > related to using both cache.xml and cluster configuration at the same
> > time.
> > > If we can make cluster config complete enough, and deprecate cache.xml,
> > > people will stop using cache.xml.
> > >
> > >
> > >
> > > --
> > > Mike Stolz
> > > Principal Engineer, GemFire Product Lead
> > > Mobile: +1-631-835-4771
> > > Download the GemFire book here.
> > > <https://content.pivotal.io/ebooks/scaling-data-services-
> > > with-pivotal-gemfire>
> > >
> > > On Thu, Apr 19, 2018 at 5:58 PM, Jinmei Liao <ji...@pivotal.io>
> wrote:
> > >
> > > > Scenario:
> > > > a locator with cluster configuration enabled and a server started
> with
> > a
> > > > cache.xml that has /regionA defined and connected to this locator. So
> > the
> > > > initial state is the locator has an empty cluster configuration for
> the
> > > > cluster, but the server has a region defined in it's cache.
> > > >
> > > > Old behavior:
> > > > when user execute "create index --region=/regionA ...." command using
> > > gfsh,
> > > > the index creation is successful on the server, and the server
> returns
> > a
> > > > xml section that contains both <region> and <index> elements, CC is
> > > updated
> > > > with this xml, so the end result is: both region and index end up in
> > the
> > > > cluster configuration.
> > > >
> > > > Problem with old behavior:
> > > > Not sure if the region is a cluster wide configuration. What if a
> > region
> > > > with the same name, but different type exists on different servers?
> the
> > > xml
> > > > returned by different server might be different.
> > > >
> > > > New behavior:
> > > > when user execute "create index --region=/regionA ...." command using
> > > gfsh,
> > > > the index creation is successful on the server. We failed to find the
> > > > region in the existing cluster configuration, so cluster
> configuration
> > > will
> > > > NOT be updated.
> > > >
> > > > I would also suggest that this would not apply to index alone, any
> > > element
> > > > inside region would have the same behavior change if we approve this.
> > > >
> > > > Thanks!
> > > >
> > > > --
> > > > Cheers
> > > >
> > > > Jinmei
> > > >
> > >
> >
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>
Re: [Proposal]: behavior change when region doesn't exist in cluster configuration
Posted by Michael Stolz <ms...@pivotal.io>.
Ok. Yes we do have to take the leap :)
Let's keep thinking that way.
--
Mike Stolz
Principal Engineer, GemFire Product Lead
Mobile: +1-631-835-4771
Download the GemFire book here.
<https://content.pivotal.io/ebooks/scaling-data-services-with-pivotal-gemfire>
On Thu, Apr 19, 2018 at 6:29 PM, Jinmei Liao <ji...@pivotal.io> wrote:
> but this proposed change is one of the effort toward "deprecating
> cache.xml". I think we've got to take the leap at one point.....
>
> On Thu, Apr 19, 2018 at 3:14 PM, Michael Stolz <ms...@pivotal.io> wrote:
>
> > Hmmm...I think I liked the old behavior better. It was a kind of bridge
> to
> > cluster config.
> >
> > I still think we need to be putting much more effort into deprecating
> > cache.xml and much less effort into fixing the (possibly) hundreds of
> bugs
> > related to using both cache.xml and cluster configuration at the same
> time.
> > If we can make cluster config complete enough, and deprecate cache.xml,
> > people will stop using cache.xml.
> >
> >
> >
> > --
> > Mike Stolz
> > Principal Engineer, GemFire Product Lead
> > Mobile: +1-631-835-4771
> > Download the GemFire book here.
> > <https://content.pivotal.io/ebooks/scaling-data-services-
> > with-pivotal-gemfire>
> >
> > On Thu, Apr 19, 2018 at 5:58 PM, Jinmei Liao <ji...@pivotal.io> wrote:
> >
> > > Scenario:
> > > a locator with cluster configuration enabled and a server started with
> a
> > > cache.xml that has /regionA defined and connected to this locator. So
> the
> > > initial state is the locator has an empty cluster configuration for the
> > > cluster, but the server has a region defined in it's cache.
> > >
> > > Old behavior:
> > > when user execute "create index --region=/regionA ...." command using
> > gfsh,
> > > the index creation is successful on the server, and the server returns
> a
> > > xml section that contains both <region> and <index> elements, CC is
> > updated
> > > with this xml, so the end result is: both region and index end up in
> the
> > > cluster configuration.
> > >
> > > Problem with old behavior:
> > > Not sure if the region is a cluster wide configuration. What if a
> region
> > > with the same name, but different type exists on different servers? the
> > xml
> > > returned by different server might be different.
> > >
> > > New behavior:
> > > when user execute "create index --region=/regionA ...." command using
> > gfsh,
> > > the index creation is successful on the server. We failed to find the
> > > region in the existing cluster configuration, so cluster configuration
> > will
> > > NOT be updated.
> > >
> > > I would also suggest that this would not apply to index alone, any
> > element
> > > inside region would have the same behavior change if we approve this.
> > >
> > > Thanks!
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
>
>
>
> --
> Cheers
>
> Jinmei
>
Re: [Proposal]: behavior change when region doesn't exist in cluster configuration
Posted by Jinmei Liao <ji...@pivotal.io>.
but this proposed change is one of the effort toward "deprecating
cache.xml". I think we've got to take the leap at one point.....
On Thu, Apr 19, 2018 at 3:14 PM, Michael Stolz <ms...@pivotal.io> wrote:
> Hmmm...I think I liked the old behavior better. It was a kind of bridge to
> cluster config.
>
> I still think we need to be putting much more effort into deprecating
> cache.xml and much less effort into fixing the (possibly) hundreds of bugs
> related to using both cache.xml and cluster configuration at the same time.
> If we can make cluster config complete enough, and deprecate cache.xml,
> people will stop using cache.xml.
>
>
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Lead
> Mobile: +1-631-835-4771
> Download the GemFire book here.
> <https://content.pivotal.io/ebooks/scaling-data-services-
> with-pivotal-gemfire>
>
> On Thu, Apr 19, 2018 at 5:58 PM, Jinmei Liao <ji...@pivotal.io> wrote:
>
> > Scenario:
> > a locator with cluster configuration enabled and a server started with a
> > cache.xml that has /regionA defined and connected to this locator. So the
> > initial state is the locator has an empty cluster configuration for the
> > cluster, but the server has a region defined in it's cache.
> >
> > Old behavior:
> > when user execute "create index --region=/regionA ...." command using
> gfsh,
> > the index creation is successful on the server, and the server returns a
> > xml section that contains both <region> and <index> elements, CC is
> updated
> > with this xml, so the end result is: both region and index end up in the
> > cluster configuration.
> >
> > Problem with old behavior:
> > Not sure if the region is a cluster wide configuration. What if a region
> > with the same name, but different type exists on different servers? the
> xml
> > returned by different server might be different.
> >
> > New behavior:
> > when user execute "create index --region=/regionA ...." command using
> gfsh,
> > the index creation is successful on the server. We failed to find the
> > region in the existing cluster configuration, so cluster configuration
> will
> > NOT be updated.
> >
> > I would also suggest that this would not apply to index alone, any
> element
> > inside region would have the same behavior change if we approve this.
> >
> > Thanks!
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>
--
Cheers
Jinmei
Re: [Proposal]: behavior change when region doesn't exist in cluster configuration
Posted by Michael Stolz <ms...@pivotal.io>.
Hmmm...I think I liked the old behavior better. It was a kind of bridge to
cluster config.
I still think we need to be putting much more effort into deprecating
cache.xml and much less effort into fixing the (possibly) hundreds of bugs
related to using both cache.xml and cluster configuration at the same time.
If we can make cluster config complete enough, and deprecate cache.xml,
people will stop using cache.xml.
--
Mike Stolz
Principal Engineer, GemFire Product Lead
Mobile: +1-631-835-4771
Download the GemFire book here.
<https://content.pivotal.io/ebooks/scaling-data-services-with-pivotal-gemfire>
On Thu, Apr 19, 2018 at 5:58 PM, Jinmei Liao <ji...@pivotal.io> wrote:
> Scenario:
> a locator with cluster configuration enabled and a server started with a
> cache.xml that has /regionA defined and connected to this locator. So the
> initial state is the locator has an empty cluster configuration for the
> cluster, but the server has a region defined in it's cache.
>
> Old behavior:
> when user execute "create index --region=/regionA ...." command using gfsh,
> the index creation is successful on the server, and the server returns a
> xml section that contains both <region> and <index> elements, CC is updated
> with this xml, so the end result is: both region and index end up in the
> cluster configuration.
>
> Problem with old behavior:
> Not sure if the region is a cluster wide configuration. What if a region
> with the same name, but different type exists on different servers? the xml
> returned by different server might be different.
>
> New behavior:
> when user execute "create index --region=/regionA ...." command using gfsh,
> the index creation is successful on the server. We failed to find the
> region in the existing cluster configuration, so cluster configuration will
> NOT be updated.
>
> I would also suggest that this would not apply to index alone, any element
> inside region would have the same behavior change if we approve this.
>
> Thanks!
>
> --
> Cheers
>
> Jinmei
>