Off-heap support deactivation
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
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 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: [DISCUSS] GEODE-7241 - make Jar not War?
I am unclear on the consensus of this thread. On Wed, Sep 25, 2019 at 12:55 PM John Blum wrote: > @Jake - Ah, indeed it was https://en.wikipedia.org/wiki/Gwar. I never > heard of them until now. Gotta love the 80s Rock/Heavy Metal Era. > > On Wed, Sep 25, 2019 at 12:22 PM Jacob Barrett > wrote: > > > Udo, > > > > I didn’t say we shouldn’t fix it for the future. I said I don’t believe > it > > warrants a backport and a patch release. > > > > -Jake > > > > > > -- > -John > john.blum10101 (skype) >
Re: [DISCUSS] GEODE-7241 - make Jar not War?
@Robert, I think the consensus is that WAR is the correct option. So unless someone objects, GEODE-7241 is a GO! --Udo On 9/30/19 10:58 AM, Robert Houghton wrote: I am unclear on the consensus of this thread. On Wed, Sep 25, 2019 at 12:55 PM John Blum wrote: @Jake - Ah, indeed it was https://en.wikipedia.org/wiki/Gwar. I never heard of them until now. Gotta love the 80s Rock/Heavy Metal Era. On Wed, Sep 25, 2019 at 12:22 PM Jacob Barrett wrote: Udo, I didn’t say we shouldn’t fix it for the future. I said I don’t believe it warrants a backport and a patch release. -Jake -- -John john.blum10101 (skype)
[DISCUSS] Support For LTS Version Of Geode
Hi All, It has come up a few times in recent weeks about the possibility of an LTS version of Geode. Is this something the community would be interested in? There are advantages and disadvantages to supporting an LTS. Some advantages may include: - Stable release for downstream projects - Include security and other maintenance related patches Disadvantages: - Additional support for multiple distributions/versions - Release management overhead Thoughts/Comments/Concerns? --Mark
Re: [DISCUSS] Support For LTS Version Of Geode
Put simply, from my perspective, I would like to see LTS versions of Apache Geode align with the *Spring Data* (*Release Trains*) support for Apache Geode. For example: SDG Lovelace/2.1 is based on Apache Geode 1.6.x. SDG Moore/2.2 is based on Apache Geode 1.9.x. Therefore, both Apache Geode 1.6 and 1.9 would be LTS versions, with patch releases. The upcoming SD Neuman/2.3 (now in development given Moore has just went GA (i.e. 2.2.0.RELEASE) as of today), is currently based on 1.10, but is likely to move Apache Geode versions (e.g. 1.11, 1.12, or even 1.13) before SD Neuman reaches RC1. SD has longer lifecycles between release trains (1 to 1.5 years per SD Release Train) than Apache Geode's support cycle, on a particular major.minor version (e.g. 1.9), which always puts us in a precarious position. $0.02 -John On Mon, Sep 30, 2019 at 3:55 PM Mark Bretl wrote: > Hi All, > > It has come up a few times in recent weeks about the possibility of an LTS > version of Geode. Is this something the community would be interested in? > > There are advantages and disadvantages to supporting an LTS. Some > advantages may include: > - Stable release for downstream projects > - Include security and other maintenance related patches > > Disadvantages: > - Additional support for multiple distributions/versions > - Release management overhead > > Thoughts/Comments/Concerns? > > --Mark > -- -John john.blum10101 (skype)
Re: [DISCUSS] Support For LTS Version Of Geode
I am curious, what is the primary reason for such a long release cycle for Spring Data Geode? Also curious, what kinds of fixes is SDG expecting to “keep out” by locking in a particular minor release? Perhaps a good question for Geode is, why do we increment the minor version on every quarterly release, when most releases consist of mostly just bug fixes? If we were to create an LTS branch, would we end up back-porting virtually every commit? Is there any good reason why 1.10.0 couldn’t have been released as a 1.9.x? Just trying to understand what constitutes a patch release and what constitutes a minor, both from Geode’s perspective and from SDG’s perspective. The AEQ-pause feature requested for 1.9.2 casts doubt on the presumption that both Geode and SDG adhere strictly to semantic versioning... -Owen > On Sep 30, 2019, at 5:09 PM, John Blum wrote: > > Put simply, from my perspective, I would like to see LTS versions of Apache > Geode align with the *Spring Data* (*Release Trains*) support for Apache > Geode. > > For example: > > SDG Lovelace/2.1 is based on Apache Geode 1.6.x. > SDG Moore/2.2 is based on Apache Geode 1.9.x. > > Therefore, both Apache Geode 1.6 and 1.9 would be LTS versions, with patch > releases. > > The upcoming SD Neuman/2.3 (now in development given Moore has just went GA > (i.e. 2.2.0.RELEASE) as of today), is currently based on 1.10, but is > likely to move Apache Geode versions (e.g. 1.11, 1.12, or even 1.13) before > SD Neuman reaches RC1. > > SD has longer lifecycles between release trains (1 to 1.5 years per SD > Release Train) than Apache Geode's support cycle, on a particular > major.minor version (e.g. 1.9), which always puts us in a > precarious position. > > $0.02 > -John > > > > On Mon, Sep 30, 2019 at 3:55 PM Mark Bretl wrote: > >> Hi All, >> >> It has come up a few times in recent weeks about the possibility of an LTS >> version of Geode. Is this something the community would be interested in? >> >> There are advantages and disadvantages to supporting an LTS. Some >> advantages may include: >> - Stable release for downstream projects >> - Include security and other maintenance related patches >> >> Disadvantages: >> - Additional support for multiple distributions/versions >> - Release management overhead >> >> Thoughts/Comments/Concerns? >> >> --Mark >> > > > -- > -John > john.blum10101 (skype)
Re: [DISCUSS] Support For LTS Version Of Geode
I agree. This is the most sensible way to achieve release alignment. -- Mike Stolz Principal Engineer, Pivotal Cloud Cache Mobile: +1-631-835-4771 On Mon, Sep 30, 2019, 8:09 PM John Blum wrote: > Put simply, from my perspective, I would like to see LTS versions of Apache > Geode align with the *Spring Data* (*Release Trains*) support for Apache > Geode. > > For example: > > SDG Lovelace/2.1 is based on Apache Geode 1.6.x. > SDG Moore/2.2 is based on Apache Geode 1.9.x. > > Therefore, both Apache Geode 1.6 and 1.9 would be LTS versions, with patch > releases. > > The upcoming SD Neuman/2.3 (now in development given Moore has just went GA > (i.e. 2.2.0.RELEASE) as of today), is currently based on 1.10, but is > likely to move Apache Geode versions (e.g. 1.11, 1.12, or even 1.13) before > SD Neuman reaches RC1. > > SD has longer lifecycles between release trains (1 to 1.5 years per SD > Release Train) than Apache Geode's support cycle, on a particular > major.minor version (e.g. 1.9), which always puts us in a > precarious position. > > $0.02 > -John > > > > On Mon, Sep 30, 2019 at 3:55 PM Mark Bretl wrote: > > > Hi All, > > > > It has come up a few times in recent weeks about the possibility of an > LTS > > version of Geode. Is this something the community would be interested in? > > > > There are advantages and disadvantages to supporting an LTS. Some > > advantages may include: > > - Stable release for downstream projects > > - Include security and other maintenance related patches > > > > Disadvantages: > > - Additional support for multiple distributions/versions > > - Release management overhead > > > > Thoughts/Comments/Concerns? > > > > --Mark > > > > > -- > -John > john.blum10101 (skype) >
Re: [DISCUSS] Support For LTS Version Of Geode
Well, release durations are subjective to begin with. What makes a 3 month cycle any better than a 6 month cycle or vice versa? For one, I think it is very project dependent. Rather, SD strives to achieve a predictable release cycle (i.e. fixed duration over X amount of scope, e.g. every 6 months, from M1 to final GA where we might have any number of Milestones and Release Candidates between M1 and final GA). Also, there is a commitment to our customers, so the 1 year cycle is not arbitrary. The entire SD Release Train also encompass 14 different modules (GemFire/Geode, JPA, MongoDB, Redis, Cassandra, etc) so there are a lot more moving parts to coordinate with different intended feature sets per module (some of it aligning with SD Commons while other bits are very store specific) over the course of arriving at the final GA. Finally, I'd say that what is the point of having a patch version (i.e. in major.minor.patch) if the only intent to use is to fix CVEs. You could simply force users to the new minor version containing the fixes. However, I am very much in favor having patch releases, particularly for data products where upgrading is not a trivial task, and not simply a technical one, either. Again, $0.02, -John On Mon, Sep 30, 2019 at 5:48 PM Michael Stolz wrote: > I agree. > > This is the most sensible way to achieve release alignment. > > > -- > Mike Stolz > Principal Engineer, Pivotal Cloud Cache > Mobile: +1-631-835-4771 > > On Mon, Sep 30, 2019, 8:09 PM John Blum wrote: > > > Put simply, from my perspective, I would like to see LTS versions of > Apache > > Geode align with the *Spring Data* (*Release Trains*) support for Apache > > Geode. > > > > For example: > > > > SDG Lovelace/2.1 is based on Apache Geode 1.6.x. > > SDG Moore/2.2 is based on Apache Geode 1.9.x. > > > > Therefore, both Apache Geode 1.6 and 1.9 would be LTS versions, with > patch > > releases. > > > > The upcoming SD Neuman/2.3 (now in development given Moore has just went > GA > > (i.e. 2.2.0.RELEASE) as of today), is currently based on 1.10, but is > > likely to move Apache Geode versions (e.g. 1.11, 1.12, or even 1.13) > before > > SD Neuman reaches RC1. > > > > SD has longer lifecycles between release trains (1 to 1.5 years per SD > > Release Train) than Apache Geode's support cycle, on a particular > > major.minor version (e.g. 1.9), which always puts us in a > > precarious position. > > > > $0.02 > > -John > > > > > > > > On Mon, Sep 30, 2019 at 3:55 PM Mark Bretl wrote: > > > > > Hi All, > > > > > > It has come up a few times in recent weeks about the possibility of an > > LTS > > > version of Geode. Is this something the community would be interested > in? > > > > > > There are advantages and disadvantages to supporting an LTS. Some > > > advantages may include: > > > - Stable release for downstream projects > > > - Include security and other maintenance related patches > > > > > > Disadvantages: > > > - Additional support for multiple distributions/versions > > > - Release management overhead > > > > > > Thoughts/Comments/Concerns? > > > > > > --Mark > > > > > > > > > -- > > -John > > john.blum10101 (skype) > > > -- -John john.blum10101 (skype)
Re: [DISCUSS] Support For LTS Version Of Geode
1 more thing... I am also not saying all Apache Geode LTS versions (e.g. 1.9) need to perfectly align with the SD Release Train for which the SD Release Train is based (e.g. SD Moore/2.2 <-> 1.9), release by release, especially given we have quite a few service/patch releases per SD Release Train (e.g. SD Lovelace is already at SR10/2.1.10.RELEASE or 10 service/patch releases beyond the 2.1 GA version, i.e. 2.1.0.RELEASE). Just that, enhancements, important bug fixes, and CVEs (patches) are back ported to an LTS version of Apache Geode from time to time up to, say, 1 year (or 3 or 4 patches). This may have the effect that Apache Geode users might not upgrade until a new LTS version becomes available. However, for those that want to stay ion the cutting edge, they are free to do so. It also allows the Apache Geode product to take more risk between LTS versions and really stabilize for an LTS version. To Owen's point, I am also wondering why it is so important that users always pick up the latest bits? I think this is much more problematic to do on the server-side, plus newer clients cannot talk to older servers, so... And, of course, there is no reason why Apache Geode needs to do any of what I am suggesting just for the Spring Data bits. But, it would make our lives simpler overall, which is why I am advocating for it. Final $0.02, -j On Mon, Sep 30, 2019 at 6:13 PM John Blum wrote: > Well, release durations are subjective to begin with. What makes a 3 > month cycle any better than a 6 month cycle or vice versa? > > For one, I think it is very project dependent. Rather, SD strives to > achieve a predictable release cycle (i.e. fixed duration over X amount of > scope, e.g. every 6 months, from M1 to final GA where we might have any > number of Milestones and Release Candidates between M1 and final GA). > Also, there is a commitment to our customers, so the 1 year cycle is not > arbitrary. > > The entire SD Release Train also encompass 14 different modules > (GemFire/Geode, JPA, MongoDB, Redis, Cassandra, etc) so there are a lot > more moving parts to coordinate with different intended feature sets per > module (some of it aligning with SD Commons while other bits are very store > specific) over the course of arriving at the final GA. > > Finally, I'd say that what is the point of having a patch version (i.e. in > major.minor.patch) if the only intent to use is to fix CVEs. You could > simply force users to the new minor version containing the fixes. > > However, I am very much in favor having patch releases, particularly for > data products where upgrading is not a trivial task, and not simply a > technical one, either. > > Again, $0.02, > > -John > > > On Mon, Sep 30, 2019 at 5:48 PM Michael Stolz wrote: > >> I agree. >> >> This is the most sensible way to achieve release alignment. >> >> >> -- >> Mike Stolz >> Principal Engineer, Pivotal Cloud Cache >> Mobile: +1-631-835-4771 >> >> On Mon, Sep 30, 2019, 8:09 PM John Blum wrote: >> >> > Put simply, from my perspective, I would like to see LTS versions of >> Apache >> > Geode align with the *Spring Data* (*Release Trains*) support for Apache >> > Geode. >> > >> > For example: >> > >> > SDG Lovelace/2.1 is based on Apache Geode 1.6.x. >> > SDG Moore/2.2 is based on Apache Geode 1.9.x. >> > >> > Therefore, both Apache Geode 1.6 and 1.9 would be LTS versions, with >> patch >> > releases. >> > >> > The upcoming SD Neuman/2.3 (now in development given Moore has just >> went GA >> > (i.e. 2.2.0.RELEASE) as of today), is currently based on 1.10, but is >> > likely to move Apache Geode versions (e.g. 1.11, 1.12, or even 1.13) >> before >> > SD Neuman reaches RC1. >> > >> > SD has longer lifecycles between release trains (1 to 1.5 years per SD >> > Release Train) than Apache Geode's support cycle, on a particular >> > major.minor version (e.g. 1.9), which always puts us in a >> > precarious position. >> > >> > $0.02 >> > -John >> > >> > >> > >> > On Mon, Sep 30, 2019 at 3:55 PM Mark Bretl wrote: >> > >> > > Hi All, >> > > >> > > It has come up a few times in recent weeks about the possibility of an >> > LTS >> > > version of Geode. Is this something the community would be interested >> in? >> > > >> > > There are advantages and disadvantages to supporting an LTS. Some >> > > advantages may include: >> > > - Stable release for downstream projects >> > > - Include security and other maintenance related patches >> > > >> > > Disadvantages: >> > > - Additional support for multiple distributions/versions >> > > - Release management overhead >> > > >> > > Thoughts/Comments/Concerns? >> > > >> > > --Mark >> > > >> > >> > >> > -- >> > -John >> > john.blum10101 (skype) >> > >> > > > -- > -John > john.blum10101 (skype) > -- -John john.blum10101 (skype)
