geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jinmei Liao <jil...@pivotal.io>
Subject Re: [Proposal]: behavior change when region doesn't exist in cluster configuration
Date Fri, 27 Apr 2018 23:30:34 GMT
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 <jhuynh@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 <jhuynh@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 <jiliao@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 <nnag@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 <jiliao@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 <jiliao@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message