You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Jacob Barrett <jb...@pivotal.io> on 2017/05/04 14:29:24 UTC
Geode Native Release
All,
I want to start the discussion on releasing Geode Native C++ and .NET
clients with the next or near future Geode release.
There are a few house keeping items left in the source release JIRA [1]. It
would be great to get some help completing these tasks.
If we start with a source only release, which Geode release should we
target? Since it is "adding feature" it seems it makes the most sense to do
it as part of a minor release, say 1.2.
To throw a little wrench in it all. There are some serious changes coming
with [2] conversion to std::shared_ptr, [3] removal of all globals, [4]
replacing all non-standard concurrency methods. These changes won't be
compatible with sources written against previous releases of geode-native,
thus suggesting they will need a major rev shortly. My suggestion would be
to cut a release branch now on geode-native for 1.2 and get it ready for
source release. Backport any changes on the release branch to develop. That
leaves develop open for marching forward with what would be a 2.0 set of
sources. Any release of Geode 1.x would just include the geode-native
release/1.x branches until Geode 2.0.
Thoughts and feedback?
[1] https://issues.apache.org/jira/browse/GEODE-1416
[2] https://issues.apache.org/jira/browse/GEODE-2807
[3] https://issues.apache.org/jira/browse/GEODE-2729
[4] https://issues.apache.org/jira/browse/GEODE-2493
-Jake
Re: Geode Native Release
Posted by Anthony Baker <ab...@pivotal.io>.
> On May 4, 2017, at 7:29 AM, Jacob Barrett <jb...@pivotal.io> wrote:
>
> There are a few house keeping items left in the source release JIRA [1]. It
> would be great to get some help completing these tasks.
BTW, I’m happy to help with some of the build issues. I wrote up a gradle script awhile back to create and sign the source artifacts for geode-native. If you’d rather do that via cmake it might be more complicated :-)
Anthony
Re: Geode Native Release
Posted by John Blum <jb...@pivotal.io>.
Jacob - Ah, sorry to hear that.
On Thu, May 4, 2017 at 2:09 PM, Jacob Barrett <jb...@pivotal.io> wrote:
> John, I wish we could do that but Apache would require that geode-native be
> a fully qualified sub-project with all the headache that goes with that to
> "release" separately.
>
>
> On Thu, May 4, 2017 at 11:35 AM John Blum <jb...@pivotal.io> wrote:
>
> > A good reason to use separate repos. Individual components of Geode,
> > especially clear boundaries like Native Client, *Gfsh*, or Pulse, etc,
> > should be separately and independently releasable to provide a smoother
> > release cadence based on velocity and community need.
> >
> > Then, using a Maven "BOM", you can tie all the independent (yet
> compatible)
> > versions together in 1 cohesive collection of artifacts for a particular
> > release of Geode.
> >
> > You think all the SD modules in the "release train" have a same version?
> > No!
> >
> > Case in point...
> >
> >
> > https://github.com/spring-projects/spring-data-build/
> blob/1.9.3.RELEASE/bom/pom.xml#L21-L146
> >
> > They all have the same "symbolic" version though...
> >
> >
> > https://github.com/spring-projects/spring-data-build/
> blob/1.9.3.RELEASE/bom/pom.xml#L6-L7
> >
> > Which is what other projects (e.g. *Spring Boot*) use to pull in the SD
> > train...
> >
> >
> > https://github.com/spring-projects/spring-boot/blob/v1.
> 5.3.RELEASE/spring-boot-dependencies/pom.xml#L158
> >
> >
> > https://github.com/spring-projects/spring-boot/blob/v1.
> 5.3.RELEASE/spring-boot-dependencies/pom.xml#L2088-L2094
> >
> > While we don't typically release individual SD modules (though, it has
> been
> > known to occur [1]), we could. But, we try to keep all modules in sync
> > with the train since all have a common core (*Spring Framework* / *Spring
> > Data Commons*), but they have all different versions. Many other open
> > source projects operate the same way... Reactor.
> >
> > $0.02
> >
> > -John
> >
> >
> > [1]
> >
> > https://github.com/spring-projects/spring-data-gemfire/
> tree/1.8.4.RELEASE-PATCH01
> >
> >
> > On Thu, May 4, 2017 at 11:23 AM, Anthony Baker <ab...@pivotal.io>
> wrote:
> >
> > > Let’s say we release geode-native along with geode 1.2. When it comes
> > > time to release 1.3 (and geode-native is not yet ready) we would be
> > > creating release branches from:
> > >
> > > geode: develop
> > > geode-example: develop
> > > geode-native: release/v1.2.0
> > >
> > > Anthony
> > >
> > > > On May 4, 2017, at 11:16 AM, Jacob Barrett <jb...@pivotal.io>
> > wrote:
> > > >
> > > > I don't see how they are different branches? If geode-Native has
> > > release/1.2 and Geode has release/1.2?
> > > >
> > > > Sent from my iPhone
> > > >
> > > >> On May 4, 2017, at 10:21 AM, Anthony Baker <ab...@pivotal.io>
> wrote:
> > > >>
> > > >> I think it’s confusing to cut a release from different branches for
> > > geode, geode-examples, and geode-native but I don’t have a better idea.
> > > >>
> > > >> +0
> > > >>
> > > >> Anthony
> > > >>
> > > >>> On May 4, 2017, at 7:29 AM, Jacob Barrett <jb...@pivotal.io>
> > wrote:
> > > >>>
> > > >>> All,
> > > >>>
> > > >>> I want to start the discussion on releasing Geode Native C++ and
> .NET
> > > >>> clients with the next or near future Geode release.
> > > >>>
> > > >>> There are a few house keeping items left in the source release JIRA
> > > [1]. It
> > > >>> would be great to get some help completing these tasks.
> > > >>>
> > > >>> If we start with a source only release, which Geode release should
> we
> > > >>> target? Since it is "adding feature" it seems it makes the most
> sense
> > > to do
> > > >>> it as part of a minor release, say 1.2.
> > > >>>
> > > >>> To throw a little wrench in it all. There are some serious changes
> > > coming
> > > >>> with [2] conversion to std::shared_ptr, [3] removal of all globals,
> > [4]
> > > >>> replacing all non-standard concurrency methods. These changes won't
> > be
> > > >>> compatible with sources written against previous releases of
> > > geode-native,
> > > >>> thus suggesting they will need a major rev shortly. My suggestion
> > > would be
> > > >>> to cut a release branch now on geode-native for 1.2 and get it
> ready
> > > for
> > > >>> source release. Backport any changes on the release branch to
> > develop.
> > > That
> > > >>> leaves develop open for marching forward with what would be a 2.0
> set
> > > of
> > > >>> sources. Any release of Geode 1.x would just include the
> geode-native
> > > >>> release/1.x branches until Geode 2.0.
> > > >>>
> > > >>> Thoughts and feedback?
> > > >>>
> > > >>> [1] https://issues.apache.org/jira/browse/GEODE-1416
> > > >>> [2] https://issues.apache.org/jira/browse/GEODE-2807
> > > >>> [3] https://issues.apache.org/jira/browse/GEODE-2729
> > > >>> [4] https://issues.apache.org/jira/browse/GEODE-2493
> > > >>>
> > > >>> -Jake
> > > >>
> > >
> > >
> >
> >
> > --
> > -John
> > john.blum10101 (skype)
> >
>
--
-John
john.blum10101 (skype)
Re: Geode Native Release
Posted by Jacob Barrett <jb...@pivotal.io>.
John, I wish we could do that but Apache would require that geode-native be
a fully qualified sub-project with all the headache that goes with that to
"release" separately.
On Thu, May 4, 2017 at 11:35 AM John Blum <jb...@pivotal.io> wrote:
> A good reason to use separate repos. Individual components of Geode,
> especially clear boundaries like Native Client, *Gfsh*, or Pulse, etc,
> should be separately and independently releasable to provide a smoother
> release cadence based on velocity and community need.
>
> Then, using a Maven "BOM", you can tie all the independent (yet compatible)
> versions together in 1 cohesive collection of artifacts for a particular
> release of Geode.
>
> You think all the SD modules in the "release train" have a same version?
> No!
>
> Case in point...
>
>
> https://github.com/spring-projects/spring-data-build/blob/1.9.3.RELEASE/bom/pom.xml#L21-L146
>
> They all have the same "symbolic" version though...
>
>
> https://github.com/spring-projects/spring-data-build/blob/1.9.3.RELEASE/bom/pom.xml#L6-L7
>
> Which is what other projects (e.g. *Spring Boot*) use to pull in the SD
> train...
>
>
> https://github.com/spring-projects/spring-boot/blob/v1.5.3.RELEASE/spring-boot-dependencies/pom.xml#L158
>
>
> https://github.com/spring-projects/spring-boot/blob/v1.5.3.RELEASE/spring-boot-dependencies/pom.xml#L2088-L2094
>
> While we don't typically release individual SD modules (though, it has been
> known to occur [1]), we could. But, we try to keep all modules in sync
> with the train since all have a common core (*Spring Framework* / *Spring
> Data Commons*), but they have all different versions. Many other open
> source projects operate the same way... Reactor.
>
> $0.02
>
> -John
>
>
> [1]
>
> https://github.com/spring-projects/spring-data-gemfire/tree/1.8.4.RELEASE-PATCH01
>
>
> On Thu, May 4, 2017 at 11:23 AM, Anthony Baker <ab...@pivotal.io> wrote:
>
> > Let’s say we release geode-native along with geode 1.2. When it comes
> > time to release 1.3 (and geode-native is not yet ready) we would be
> > creating release branches from:
> >
> > geode: develop
> > geode-example: develop
> > geode-native: release/v1.2.0
> >
> > Anthony
> >
> > > On May 4, 2017, at 11:16 AM, Jacob Barrett <jb...@pivotal.io>
> wrote:
> > >
> > > I don't see how they are different branches? If geode-Native has
> > release/1.2 and Geode has release/1.2?
> > >
> > > Sent from my iPhone
> > >
> > >> On May 4, 2017, at 10:21 AM, Anthony Baker <ab...@pivotal.io> wrote:
> > >>
> > >> I think it’s confusing to cut a release from different branches for
> > geode, geode-examples, and geode-native but I don’t have a better idea.
> > >>
> > >> +0
> > >>
> > >> Anthony
> > >>
> > >>> On May 4, 2017, at 7:29 AM, Jacob Barrett <jb...@pivotal.io>
> wrote:
> > >>>
> > >>> All,
> > >>>
> > >>> I want to start the discussion on releasing Geode Native C++ and .NET
> > >>> clients with the next or near future Geode release.
> > >>>
> > >>> There are a few house keeping items left in the source release JIRA
> > [1]. It
> > >>> would be great to get some help completing these tasks.
> > >>>
> > >>> If we start with a source only release, which Geode release should we
> > >>> target? Since it is "adding feature" it seems it makes the most sense
> > to do
> > >>> it as part of a minor release, say 1.2.
> > >>>
> > >>> To throw a little wrench in it all. There are some serious changes
> > coming
> > >>> with [2] conversion to std::shared_ptr, [3] removal of all globals,
> [4]
> > >>> replacing all non-standard concurrency methods. These changes won't
> be
> > >>> compatible with sources written against previous releases of
> > geode-native,
> > >>> thus suggesting they will need a major rev shortly. My suggestion
> > would be
> > >>> to cut a release branch now on geode-native for 1.2 and get it ready
> > for
> > >>> source release. Backport any changes on the release branch to
> develop.
> > That
> > >>> leaves develop open for marching forward with what would be a 2.0 set
> > of
> > >>> sources. Any release of Geode 1.x would just include the geode-native
> > >>> release/1.x branches until Geode 2.0.
> > >>>
> > >>> Thoughts and feedback?
> > >>>
> > >>> [1] https://issues.apache.org/jira/browse/GEODE-1416
> > >>> [2] https://issues.apache.org/jira/browse/GEODE-2807
> > >>> [3] https://issues.apache.org/jira/browse/GEODE-2729
> > >>> [4] https://issues.apache.org/jira/browse/GEODE-2493
> > >>>
> > >>> -Jake
> > >>
> >
> >
>
>
> --
> -John
> john.blum10101 (skype)
>
Re: Geode Native Release
Posted by John Blum <jb...@pivotal.io>.
A good reason to use separate repos. Individual components of Geode,
especially clear boundaries like Native Client, *Gfsh*, or Pulse, etc,
should be separately and independently releasable to provide a smoother
release cadence based on velocity and community need.
Then, using a Maven "BOM", you can tie all the independent (yet compatible)
versions together in 1 cohesive collection of artifacts for a particular
release of Geode.
You think all the SD modules in the "release train" have a same version?
No!
Case in point...
https://github.com/spring-projects/spring-data-build/blob/1.9.3.RELEASE/bom/pom.xml#L21-L146
They all have the same "symbolic" version though...
https://github.com/spring-projects/spring-data-build/blob/1.9.3.RELEASE/bom/pom.xml#L6-L7
Which is what other projects (e.g. *Spring Boot*) use to pull in the SD
train...
https://github.com/spring-projects/spring-boot/blob/v1.5.3.RELEASE/spring-boot-dependencies/pom.xml#L158
https://github.com/spring-projects/spring-boot/blob/v1.5.3.RELEASE/spring-boot-dependencies/pom.xml#L2088-L2094
While we don't typically release individual SD modules (though, it has been
known to occur [1]), we could. But, we try to keep all modules in sync
with the train since all have a common core (*Spring Framework* / *Spring
Data Commons*), but they have all different versions. Many other open
source projects operate the same way... Reactor.
$0.02
-John
[1]
https://github.com/spring-projects/spring-data-gemfire/tree/1.8.4.RELEASE-PATCH01
On Thu, May 4, 2017 at 11:23 AM, Anthony Baker <ab...@pivotal.io> wrote:
> Let’s say we release geode-native along with geode 1.2. When it comes
> time to release 1.3 (and geode-native is not yet ready) we would be
> creating release branches from:
>
> geode: develop
> geode-example: develop
> geode-native: release/v1.2.0
>
> Anthony
>
> > On May 4, 2017, at 11:16 AM, Jacob Barrett <jb...@pivotal.io> wrote:
> >
> > I don't see how they are different branches? If geode-Native has
> release/1.2 and Geode has release/1.2?
> >
> > Sent from my iPhone
> >
> >> On May 4, 2017, at 10:21 AM, Anthony Baker <ab...@pivotal.io> wrote:
> >>
> >> I think it’s confusing to cut a release from different branches for
> geode, geode-examples, and geode-native but I don’t have a better idea.
> >>
> >> +0
> >>
> >> Anthony
> >>
> >>> On May 4, 2017, at 7:29 AM, Jacob Barrett <jb...@pivotal.io> wrote:
> >>>
> >>> All,
> >>>
> >>> I want to start the discussion on releasing Geode Native C++ and .NET
> >>> clients with the next or near future Geode release.
> >>>
> >>> There are a few house keeping items left in the source release JIRA
> [1]. It
> >>> would be great to get some help completing these tasks.
> >>>
> >>> If we start with a source only release, which Geode release should we
> >>> target? Since it is "adding feature" it seems it makes the most sense
> to do
> >>> it as part of a minor release, say 1.2.
> >>>
> >>> To throw a little wrench in it all. There are some serious changes
> coming
> >>> with [2] conversion to std::shared_ptr, [3] removal of all globals, [4]
> >>> replacing all non-standard concurrency methods. These changes won't be
> >>> compatible with sources written against previous releases of
> geode-native,
> >>> thus suggesting they will need a major rev shortly. My suggestion
> would be
> >>> to cut a release branch now on geode-native for 1.2 and get it ready
> for
> >>> source release. Backport any changes on the release branch to develop.
> That
> >>> leaves develop open for marching forward with what would be a 2.0 set
> of
> >>> sources. Any release of Geode 1.x would just include the geode-native
> >>> release/1.x branches until Geode 2.0.
> >>>
> >>> Thoughts and feedback?
> >>>
> >>> [1] https://issues.apache.org/jira/browse/GEODE-1416
> >>> [2] https://issues.apache.org/jira/browse/GEODE-2807
> >>> [3] https://issues.apache.org/jira/browse/GEODE-2729
> >>> [4] https://issues.apache.org/jira/browse/GEODE-2493
> >>>
> >>> -Jake
> >>
>
>
--
-John
john.blum10101 (skype)
Re: Geode Native Release
Posted by Jacob Barrett <jb...@pivotal.io>.
It's the problem we are going to have with two distinctly different modules
sharing the same project release cycle. The best we could do is branch
release/v1.3 form the support/v1.2 branch until we are ready to release the
breaking changes in the geode-native/develop branch.
-Jake
On Thu, May 4, 2017 at 11:23 AM Anthony Baker <ab...@pivotal.io> wrote:
> Let’s say we release geode-native along with geode 1.2. When it comes
> time to release 1.3 (and geode-native is not yet ready) we would be
> creating release branches from:
>
> geode: develop
> geode-example: develop
> geode-native: release/v1.2.0
>
> Anthony
>
> > On May 4, 2017, at 11:16 AM, Jacob Barrett <jb...@pivotal.io> wrote:
> >
> > I don't see how they are different branches? If geode-Native has
> release/1.2 and Geode has release/1.2?
> >
> > Sent from my iPhone
> >
> >> On May 4, 2017, at 10:21 AM, Anthony Baker <ab...@pivotal.io> wrote:
> >>
> >> I think it’s confusing to cut a release from different branches for
> geode, geode-examples, and geode-native but I don’t have a better idea.
> >>
> >> +0
> >>
> >> Anthony
> >>
> >>> On May 4, 2017, at 7:29 AM, Jacob Barrett <jb...@pivotal.io> wrote:
> >>>
> >>> All,
> >>>
> >>> I want to start the discussion on releasing Geode Native C++ and .NET
> >>> clients with the next or near future Geode release.
> >>>
> >>> There are a few house keeping items left in the source release JIRA
> [1]. It
> >>> would be great to get some help completing these tasks.
> >>>
> >>> If we start with a source only release, which Geode release should we
> >>> target? Since it is "adding feature" it seems it makes the most sense
> to do
> >>> it as part of a minor release, say 1.2.
> >>>
> >>> To throw a little wrench in it all. There are some serious changes
> coming
> >>> with [2] conversion to std::shared_ptr, [3] removal of all globals, [4]
> >>> replacing all non-standard concurrency methods. These changes won't be
> >>> compatible with sources written against previous releases of
> geode-native,
> >>> thus suggesting they will need a major rev shortly. My suggestion
> would be
> >>> to cut a release branch now on geode-native for 1.2 and get it ready
> for
> >>> source release. Backport any changes on the release branch to develop.
> That
> >>> leaves develop open for marching forward with what would be a 2.0 set
> of
> >>> sources. Any release of Geode 1.x would just include the geode-native
> >>> release/1.x branches until Geode 2.0.
> >>>
> >>> Thoughts and feedback?
> >>>
> >>> [1] https://issues.apache.org/jira/browse/GEODE-1416
> >>> [2] https://issues.apache.org/jira/browse/GEODE-2807
> >>> [3] https://issues.apache.org/jira/browse/GEODE-2729
> >>> [4] https://issues.apache.org/jira/browse/GEODE-2493
> >>>
> >>> -Jake
> >>
>
>
Re: Geode Native Release
Posted by Anthony Baker <ab...@pivotal.io>.
Let’s say we release geode-native along with geode 1.2. When it comes time to release 1.3 (and geode-native is not yet ready) we would be creating release branches from:
geode: develop
geode-example: develop
geode-native: release/v1.2.0
Anthony
> On May 4, 2017, at 11:16 AM, Jacob Barrett <jb...@pivotal.io> wrote:
>
> I don't see how they are different branches? If geode-Native has release/1.2 and Geode has release/1.2?
>
> Sent from my iPhone
>
>> On May 4, 2017, at 10:21 AM, Anthony Baker <ab...@pivotal.io> wrote:
>>
>> I think it’s confusing to cut a release from different branches for geode, geode-examples, and geode-native but I don’t have a better idea.
>>
>> +0
>>
>> Anthony
>>
>>> On May 4, 2017, at 7:29 AM, Jacob Barrett <jb...@pivotal.io> wrote:
>>>
>>> All,
>>>
>>> I want to start the discussion on releasing Geode Native C++ and .NET
>>> clients with the next or near future Geode release.
>>>
>>> There are a few house keeping items left in the source release JIRA [1]. It
>>> would be great to get some help completing these tasks.
>>>
>>> If we start with a source only release, which Geode release should we
>>> target? Since it is "adding feature" it seems it makes the most sense to do
>>> it as part of a minor release, say 1.2.
>>>
>>> To throw a little wrench in it all. There are some serious changes coming
>>> with [2] conversion to std::shared_ptr, [3] removal of all globals, [4]
>>> replacing all non-standard concurrency methods. These changes won't be
>>> compatible with sources written against previous releases of geode-native,
>>> thus suggesting they will need a major rev shortly. My suggestion would be
>>> to cut a release branch now on geode-native for 1.2 and get it ready for
>>> source release. Backport any changes on the release branch to develop. That
>>> leaves develop open for marching forward with what would be a 2.0 set of
>>> sources. Any release of Geode 1.x would just include the geode-native
>>> release/1.x branches until Geode 2.0.
>>>
>>> Thoughts and feedback?
>>>
>>> [1] https://issues.apache.org/jira/browse/GEODE-1416
>>> [2] https://issues.apache.org/jira/browse/GEODE-2807
>>> [3] https://issues.apache.org/jira/browse/GEODE-2729
>>> [4] https://issues.apache.org/jira/browse/GEODE-2493
>>>
>>> -Jake
>>
Re: Geode Native Release
Posted by Jacob Barrett <jb...@pivotal.io>.
I don't see how they are different branches? If geode-Native has release/1.2 and Geode has release/1.2?
Sent from my iPhone
> On May 4, 2017, at 10:21 AM, Anthony Baker <ab...@pivotal.io> wrote:
>
> I think it’s confusing to cut a release from different branches for geode, geode-examples, and geode-native but I don’t have a better idea.
>
> +0
>
> Anthony
>
>> On May 4, 2017, at 7:29 AM, Jacob Barrett <jb...@pivotal.io> wrote:
>>
>> All,
>>
>> I want to start the discussion on releasing Geode Native C++ and .NET
>> clients with the next or near future Geode release.
>>
>> There are a few house keeping items left in the source release JIRA [1]. It
>> would be great to get some help completing these tasks.
>>
>> If we start with a source only release, which Geode release should we
>> target? Since it is "adding feature" it seems it makes the most sense to do
>> it as part of a minor release, say 1.2.
>>
>> To throw a little wrench in it all. There are some serious changes coming
>> with [2] conversion to std::shared_ptr, [3] removal of all globals, [4]
>> replacing all non-standard concurrency methods. These changes won't be
>> compatible with sources written against previous releases of geode-native,
>> thus suggesting they will need a major rev shortly. My suggestion would be
>> to cut a release branch now on geode-native for 1.2 and get it ready for
>> source release. Backport any changes on the release branch to develop. That
>> leaves develop open for marching forward with what would be a 2.0 set of
>> sources. Any release of Geode 1.x would just include the geode-native
>> release/1.x branches until Geode 2.0.
>>
>> Thoughts and feedback?
>>
>> [1] https://issues.apache.org/jira/browse/GEODE-1416
>> [2] https://issues.apache.org/jira/browse/GEODE-2807
>> [3] https://issues.apache.org/jira/browse/GEODE-2729
>> [4] https://issues.apache.org/jira/browse/GEODE-2493
>>
>> -Jake
>
Re: Geode Native Release
Posted by Anthony Baker <ab...@pivotal.io>.
I think it’s confusing to cut a release from different branches for geode, geode-examples, and geode-native but I don’t have a better idea.
+0
Anthony
> On May 4, 2017, at 7:29 AM, Jacob Barrett <jb...@pivotal.io> wrote:
>
> All,
>
> I want to start the discussion on releasing Geode Native C++ and .NET
> clients with the next or near future Geode release.
>
> There are a few house keeping items left in the source release JIRA [1]. It
> would be great to get some help completing these tasks.
>
> If we start with a source only release, which Geode release should we
> target? Since it is "adding feature" it seems it makes the most sense to do
> it as part of a minor release, say 1.2.
>
> To throw a little wrench in it all. There are some serious changes coming
> with [2] conversion to std::shared_ptr, [3] removal of all globals, [4]
> replacing all non-standard concurrency methods. These changes won't be
> compatible with sources written against previous releases of geode-native,
> thus suggesting they will need a major rev shortly. My suggestion would be
> to cut a release branch now on geode-native for 1.2 and get it ready for
> source release. Backport any changes on the release branch to develop. That
> leaves develop open for marching forward with what would be a 2.0 set of
> sources. Any release of Geode 1.x would just include the geode-native
> release/1.x branches until Geode 2.0.
>
> Thoughts and feedback?
>
> [1] https://issues.apache.org/jira/browse/GEODE-1416
> [2] https://issues.apache.org/jira/browse/GEODE-2807
> [3] https://issues.apache.org/jira/browse/GEODE-2729
> [4] https://issues.apache.org/jira/browse/GEODE-2493
>
> -Jake