RE: Off-heap support deactivation

[Alberto Bustamante Reyes <al...@est.tech>]

thanks for the detailed explanation Darrel.

There is something I did not get: "alter disk-store" is used to align the region info the disk store has when a region attribute is changed. But off-heap support is an attribute that cannot be changed on a region after it is created. So then, what is the utility of being able to run "alter disk-store" with "--off-heap" parameter if that is something that will not change in the region?

________________________________
De: Darrel Schneider <ds...@pivotal.io>
Enviado: lunes, 30 de septiembre de 2019 17:51
Para: dev@geode.apache.org <de...@geode.apache.org>
Asunto: Re: Off-heap support deactivation

You can specify this setting at the time you create the region. Geode does
not have support for changing it on a region that already exists. Only a
few region attributes can be changed on a region that currently exists (see
the AttributesMutator API). So how is your region getting created? I think
it is probably from cluster configuration. So what you would need to do is
get the definition stored in cluster configuration. I don't think the gfsh
alter region command will let you change this attribute (alter region uses
AttributesMutator). So you either need to delete the current definition and
then create it again or you need to edit the current definition manually.
Using gfsh to destroy and create is the cleanest solution, but that will
also blow away the data you currently have persisted.
To change it manually you can use gfsh export to get your cluster config as
xml, edit the xml to change the offheap boolean property on the region, and
then use gfsh import to load the xml you edited. This requires that the
server are restarted.
If you are not using cluster config (I think you should be) then this is
actually easier. You either just edit your cache.xml file and restart the
server that is using it or you just change your code's use of RegionFactory
to create the region differently.

The whole alter disk-store thing is just an optimization. The region
attributes stored in the disk-store for a persistent region do not
determine how the region is configured. The cluster-config/xml/apis that
create the region do that. When a disk-store is initially loaded it does
not yet know how the regions are configured. But it creates some temporary
maps that are used later once the region is created. If the attributes
stored in the disk-store match those on the region configuration then the
region initialization will be faster and use less memory. So basically if
you do have a persistent region and then change how it is configured, if
you also then alter how it is configured on the disk-store you next restart
will recover faster. If you don't do the alter disk-store the first
recovery will be slower but the actual region config will be stored again
in the disk-store and subsequent recoveries will be fast.

On Mon, Sep 30, 2019 at 8:28 AM Alberto Bustamante Reyes
<al...@est.tech> wrote:

> Hi all,
>
> Is it possible to change the off-heap support of a region once it is
> created? The idea I got from documentation is that it is possible to do it
> if the region is persistent, as the off-heap flag of the region can be
> changed using "alter disk-store".
>
> I have run the following example to check it: with two servers, I created
> a partition persistent region, with off-heap set to true. Then I
> deactivated the off-heap support by using alter disk-store, as described in
> documentation. But I have observed that if I run "describe region", the
> off-heap flag is still set to true. And if I populate entries, the values
> are stored in the off-heap memory.
>
> Did I misunderstood the documentation or I did something wrong?
>
> Thanks in advance,
>
> Alberto B.
>
>
> PD: I wrote down the steps I followed in the following gist:
> https://gist.github.com/alb3rtobr/e1fcf4148fe46f2e7b9e02a2e458624c
>

Re: Off-heap support deactivation

[Darrel Schneider <ds...@pivotal.io>]

You can change it but only while the servers hosting that region are
stopped. In the pre-cluster-config world, users did this by stopping the
servers, editing their cache.xml (and altering the disk-store) and then
starting the servers. But as my previous email said, it can be hard to do
with gfsh.

On Wed, Oct 2, 2019 at 1:44 AM Alberto Bustamante Reyes
<al...@est.tech> wrote:

> thanks for the detailed explanation Darrel.
>
> There is something I did not get: "alter disk-store" is used to align the
> region info the disk store has when a region attribute is changed. But
> off-heap support is an attribute that cannot be changed on a region after
> it is created. So then, what is the utility of being able to run "alter
> disk-store" with "--off-heap" parameter if that is something that will not
> change in the region?
>
> ________________________________
> De: Darrel Schneider <ds...@pivotal.io>
> Enviado: lunes, 30 de septiembre de 2019 17:51
> Para: dev@geode.apache.org <de...@geode.apache.org>
> Asunto: Re: Off-heap support deactivation
>
> You can specify this setting at the time you create the region. Geode does
> not have support for changing it on a region that already exists. Only a
> few region attributes can be changed on a region that currently exists (see
> the AttributesMutator API). So how is your region getting created? I think
> it is probably from cluster configuration. So what you would need to do is
> get the definition stored in cluster configuration. I don't think the gfsh
> alter region command will let you change this attribute (alter region uses
> AttributesMutator). So you either need to delete the current definition and
> then create it again or you need to edit the current definition manually.
> Using gfsh to destroy and create is the cleanest solution, but that will
> also blow away the data you currently have persisted.
> To change it manually you can use gfsh export to get your cluster config as
> xml, edit the xml to change the offheap boolean property on the region, and
> then use gfsh import to load the xml you edited. This requires that the
> server are restarted.
> If you are not using cluster config (I think you should be) then this is
> actually easier. You either just edit your cache.xml file and restart the
> server that is using it or you just change your code's use of RegionFactory
> to create the region differently.
>
> The whole alter disk-store thing is just an optimization. The region
> attributes stored in the disk-store for a persistent region do not
> determine how the region is configured. The cluster-config/xml/apis that
> create the region do that. When a disk-store is initially loaded it does
> not yet know how the regions are configured. But it creates some temporary
> maps that are used later once the region is created. If the attributes
> stored in the disk-store match those on the region configuration then the
> region initialization will be faster and use less memory. So basically if
> you do have a persistent region and then change how it is configured, if
> you also then alter how it is configured on the disk-store you next restart
> will recover faster. If you don't do the alter disk-store the first
> recovery will be slower but the actual region config will be stored again
> in the disk-store and subsequent recoveries will be fast.
>
> On Mon, Sep 30, 2019 at 8:28 AM Alberto Bustamante Reyes
> <al...@est.tech> wrote:
>
> > Hi all,
> >
> > Is it possible to change the off-heap support of a region once it is
> > created? The idea I got from documentation is that it is possible to do
> it
> > if the region is persistent, as the off-heap flag of the region can be
> > changed using "alter disk-store".
> >
> > I have run the following example to check it: with two servers, I created
> > a partition persistent region, with off-heap set to true. Then I
> > deactivated the off-heap support by using alter disk-store, as described
> in
> > documentation. But I have observed that if I run "describe region", the
> > off-heap flag is still set to true. And if I populate entries, the values
> > are stored in the off-heap memory.
> >
> > Did I misunderstood the documentation or I did something wrong?
> >
> > Thanks in advance,
> >
> > Alberto B.
> >
> >
> > PD: I wrote down the steps I followed in the following gist:
> > https://gist.github.com/alb3rtobr/e1fcf4148fe46f2e7b9e02a2e458624c
> >
>