Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

[Owen Nichols]

+1 for a short-term solution in 1.11 while we discuss a more complete
proposal for 1.12

On Wed, Dec 4, 2019 at 10:09 PM Jacob Barrett  wrote:

> I think we can tone down the inflammatory statements. It is well
> established that, like any legacy code base, Geode has issues. One of them
> is a less than ideal set of APIs for certain tasks. Whatever the issues
> were in the past with getting APIs adjusted to suit the SDG project should
> be left in the past and we can work forward on a new strategy.
>
> The term public API is redundant, if its designated API then it is public.
> Let’s also be clear that "internal API” is not a thing, if it is internal
> it is not an API. The language semantics of public/private are not what
> defines and API. As such, relying on internal classes tor work around
> deficiencies in a API is dangerous and should only be done as a stopgap
> measure while addressing the API’s deficiency. Java, up until 9, lacked any
> clear distinction of internals vs API so, like many projects, Geode chose
> the “internal” package name to denote things that are not to be consume as
> API. As we go forward with Java 9 modules support these will be enforced by
> the runtime and compilers.
>
> A JIRA should be opened to address the API deficiency. When the API is
> enhanced then the internal class usage should be replaced immediately with
> the API. It is unreasonable to expect an upstream project to maintain
> internal classes as though they are API or expect them to address
> deficiencies in the API if they are not communicated. It is also
> unreasonable for the upstream project to ignore obvious deficiencies in its
> APIs and should use these issues raised by downstream projects to
> prioritize improvements. Work needs to be done on both these projects to
> make improvements.
>
> To resolve the issues raised below let’s get some JIRAs and/or RFCs opened
> to address the APIs the SDG needs to work. Let’s work to burn down this
> debt of internal class usage in SDG to avoid issues like this in the
> future. I am sure we can figure out a short term solution to address the
> immediate compile issues, whether that’s making a unit test into an
> integration test, refactoring the internals to not blindly cast, or
> whatever. We can then work out a strategy to address this the correct way
> in the develop branch for 1.12.
>
> -Jake
>
>
>
> > On Dec 4, 2019, at 6:20 PM, John Blum  wrote:
> >
> > If you must know, there are important test cases in both SBDG and SSDG to
> > be able to register (and subsequently unregister) the "mock" Pool with
> the
> > PoolManager, which unfortunately is a consequence of the SDG
> > PoolFactoryBean's design being reliant on the PoolManager (to resolve the
> > Pool), and to some extent, the PoolFactory API (to create the Pool)  in
> the
> > first place.  Of course, there is no other way to "resolve" a reference
> to
> > a Pool from Geode (other than ClientCache.geDefaultPool()), AFAIK.
> >
> > Unfortunately, STDG (or SDG) would not need to import "internal" APIs if
> > Apache Geode's public API was properly maintained and evolved to address
> a
> > new use cases.  For example (and again), see GEODE-7532
> >  [1].
> >
> > It turns out, there are many, many cases like GEODE-7532
> >  [1], with classes and
> > methods containing useful functions buried deep down inside Geode
> > "internal" packages.  The o.a.g.distributed.internal.MemberListener
> > interface comes to mind.  It is not difficult to see how his interface
> > would be useful in both frameworks & tooling (e.g. for management &
> > monitoring).
> >
> > Or, how about the poor resource management/cleanup Apache Geode fails to
> do
> > properly w.r.t. SSL Sockets, that STDG now needs to account for
> > <
> https://github.com/spring-projects/spring-test-data-geode/blob/master/spring-data-geode-test/src/main/java/org/springframework/data/gemfire/tests/integration/IntegrationTestsSupport.java#L119-L139
> >
> > [2]
> > when running automated integration tests.
> >
> > I think there was another example
> >  [3] recently, which STDG
> > must account for  [4] as
> > well.
> >
> > Serializer registration/unregistration is yet another area.  The laundry
> > list is quite long!
> >
> > The whole notion of Apache Geode's "internal" API is horribly broken,
> > especially when the public API often comes up short.
> >
> > What troubles me is that we see the recommended changes in GEODE-7532 as
> a
> > "bandaid".  Really?
> >
> > It does not matter whether these classes are "internal" or not, nor
> whether
> > they are used (externally) or not, so long as they are used properly.  If
> > they are "public" there is simply no guarantee they won't be used, and
> you
> > cannot expect "internal" problems to not have external consequences.
> >
> 

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

[Jacob Barrett]

I think we can tone down the inflammatory statements. It is well established 
that, like any legacy code base, Geode has issues. One of them is a less than 
ideal set of APIs for certain tasks. Whatever the issues were in the past with 
getting APIs adjusted to suit the SDG project should be left in the past and we 
can work forward on a new strategy. 

The term public API is redundant, if its designated API then it is public. 
Let’s also be clear that "internal API” is not a thing, if it is internal it is 
not an API. The language semantics of public/private are not what defines and 
API. As such, relying on internal classes tor work around deficiencies in a API 
is dangerous and should only be done as a stopgap measure while addressing the 
API’s deficiency. Java, up until 9, lacked any clear distinction of internals 
vs API so, like many projects, Geode chose the “internal” package name to 
denote things that are not to be consume as API. As we go forward with Java 9 
modules support these will be enforced by the runtime and compilers.

A JIRA should be opened to address the API deficiency. When the API is enhanced 
then the internal class usage should be replaced immediately with the API. It 
is unreasonable to expect an upstream project to maintain internal classes as 
though they are API or expect them to address deficiencies in the API if they 
are not communicated. It is also unreasonable for the upstream project to 
ignore obvious deficiencies in its APIs and should use these issues raised by 
downstream projects to prioritize improvements. Work needs to be done on both 
these projects to make improvements.

To resolve the issues raised below let’s get some JIRAs and/or RFCs opened to 
address the APIs the SDG needs to work. Let’s work to burn down this debt of 
internal class usage in SDG to avoid issues like this in the future. I am sure 
we can figure out a short term solution to address the immediate compile 
issues, whether that’s making a unit test into an integration test, refactoring 
the internals to not blindly cast, or whatever. We can then work out a strategy 
to address this the correct way in the develop branch for 1.12.

-Jake



> On Dec 4, 2019, at 6:20 PM, John Blum  wrote:
> 
> If you must know, there are important test cases in both SBDG and SSDG to
> be able to register (and subsequently unregister) the "mock" Pool with the
> PoolManager, which unfortunately is a consequence of the SDG
> PoolFactoryBean's design being reliant on the PoolManager (to resolve the
> Pool), and to some extent, the PoolFactory API (to create the Pool)  in the
> first place.  Of course, there is no other way to "resolve" a reference to
> a Pool from Geode (other than ClientCache.geDefaultPool()), AFAIK.
> 
> Unfortunately, STDG (or SDG) would not need to import "internal" APIs if
> Apache Geode's public API was properly maintained and evolved to address a
> new use cases.  For example (and again), see GEODE-7532
>  [1].
> 
> It turns out, there are many, many cases like GEODE-7532
>  [1], with classes and
> methods containing useful functions buried deep down inside Geode
> "internal" packages.  The o.a.g.distributed.internal.MemberListener
> interface comes to mind.  It is not difficult to see how his interface
> would be useful in both frameworks & tooling (e.g. for management &
> monitoring).
> 
> Or, how about the poor resource management/cleanup Apache Geode fails to do
> properly w.r.t. SSL Sockets, that STDG now needs to account for
> 
> [2]
> when running automated integration tests.
> 
> I think there was another example
>  [3] recently, which STDG
> must account for  [4] as
> well.
> 
> Serializer registration/unregistration is yet another area.  The laundry
> list is quite long!
> 
> The whole notion of Apache Geode's "internal" API is horribly broken,
> especially when the public API often comes up short.
> 
> What troubles me is that we see the recommended changes in GEODE-7532 as a
> "bandaid".  Really?
> 
> It does not matter whether these classes are "internal" or not, nor whether
> they are used (externally) or not, so long as they are used properly.  If
> they are "public" there is simply no guarantee they won't be used, and you
> cannot expect "internal" problems to not have external consequences.
> 
> SIDE NOTE: Of course, this is further predicated on the fact those
> "internal" classes were designed/implemented correctly in the first place,
> which they also, were not!
> 
> I down voted for several reasons:
> 
> 1. First, YES, because this blocks SBDG from moving to Apache Geode 1.11,
> and 

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

[John Blum]

If you must know, there are important test cases in both SBDG and SSDG to
be able to register (and subsequently unregister) the "mock" Pool with the
PoolManager, which unfortunately is a consequence of the SDG
PoolFactoryBean's design being reliant on the PoolManager (to resolve the
Pool), and to some extent, the PoolFactory API (to create the Pool)  in the
first place.  Of course, there is no other way to "resolve" a reference to
a Pool from Geode (other than ClientCache.geDefaultPool()), AFAIK.

Unfortunately, STDG (or SDG) would not need to import "internal" APIs if
Apache Geode's public API was properly maintained and evolved to address a
new use cases.  For example (and again), see GEODE-7532
 [1].

It turns out, there are many, many cases like GEODE-7532
 [1], with classes and
methods containing useful functions buried deep down inside Geode
"internal" packages.  The o.a.g.distributed.internal.MemberListener
interface comes to mind.  It is not difficult to see how his interface
would be useful in both frameworks & tooling (e.g. for management &
monitoring).

Or, how about the poor resource management/cleanup Apache Geode fails to do
properly w.r.t. SSL Sockets, that STDG now needs to account for

[2]
when running automated integration tests.

I think there was another example
 [3] recently, which STDG
must account for  [4] as
well.

Serializer registration/unregistration is yet another area.  The laundry
list is quite long!

The whole notion of Apache Geode's "internal" API is horribly broken,
especially when the public API often comes up short.

What troubles me is that we see the recommended changes in GEODE-7532 as a
"bandaid".  Really?

It does not matter whether these classes are "internal" or not, nor whether
they are used (externally) or not, so long as they are used properly.  If
they are "public" there is simply no guarantee they won't be used, and you
cannot expect "internal" problems to not have external consequences.

SIDE NOTE: Of course, this is further predicated on the fact those
"internal" classes were designed/implemented correctly in the first place,
which they also, were not!

I down voted for several reasons:

1. First, YES, because this blocks SBDG from moving to Apache Geode 1.11,
and perhaps, more importantly...
2. Because the Pool management in PoolManagerImpl A) refers to the Pool as
PoolImpl despite taking a reference to Pool, and B) exposes the
implementation of the usage tracking logic (which is a clear violation of
"encapsulation" and a series code smell)
3. And because the IllegalStateException message is not accurate nor was it
very informative (e.g. "what Regions").
4. Or because 2A by (along with GEODE-7159
 [5]) will most
definitely cause problems for us later, especially since these problems
will be time delayed (invoked during resource cleanup) making them hard to
pinpoint and very confusing to users.

Also, imagine a scenario where Geode offers different Pool implementations,
beyond PoolImpl.  Why else would Geode provide a PoolFactory interface if
not to encapsulate creation, configuration and initialization of different
types of Pools part of that *Open/Closed* principle.  There is no point
to have a PoolFactory otherwise since the PoolManager could have simply
created Pools.  Ironically, the PoolFactory is not something that is used
in this way and therefore became an unnecessary layer of indirection.  #sigh

In addition, the recommended changes in GEODE-7531 are not invasive
what-so-ever, and will not adversely affect Geode 1 way or another.

In closing, anytime the overall code quality of Geode comes into question
(and there is a lot to question with this codebase), which can, and most
likely will affect our end-users experience, and it HAS and DOES, you
better believe and I am going to call this out.

-j


[1] https://issues.apache.org/jira/browse/GEODE-7532
[2]
https://github.com/spring-projects/spring-test-data-geode/blob/master/spring-data-geode-test/src/main/java/org/springframework/data/gemfire/tests/integration/IntegrationTestsSupport.java#L119-L139
[3] https://markmail.org/message/5juxxnkttzjndidg
[4] https://markmail.org/message/5juxxnkttzjndidg
[5] https://issues.apache.org/jira/browse/GEODE-7159

On Wed, Dec 4, 2019 at 6:12 PM Robert Houghton  wrote:

> @udo, if one needs to use a strong word like 'offender', then the offender
> is the one using an internal API. Geode is under no obligation to maintain
> or "fix" these for any project.
>
> Is there a Jira, github issue, or pull-request to promote the internal

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

[Robert Houghton]

@udo, if one needs to use a strong word like 'offender', then the offender
is the one using an internal API. Geode is under no obligation to maintain
or "fix" these for any project.

Is there a Jira, github issue, or pull-request to promote the internal
class to the public space? Is there a feature request to uncouple this
class you want to use in Spring?

Is Spring the tail wagging the dog for Geode releases?


On Wed, Dec 4, 2019, 17:59 Udo Kohlmeyer  wrote:

> @Dan,
>
> I will add my -1 to this.
>
> I understand your argument of "let's solve the problem by removing  the
> offender".
>
> But in reality who is the offender? Is it the one class that is using an
> "internal" api OR is it the implementation itself that is to tightly
> coupled that extending it is impossible?
>
> STDG right now is trying to create a test, to test functionality that
> requires it to inject/mock a Pool. The smallest piece of the code, not
> the WHOLE PoolManager. But the system does not allow for the injection
> of a `Pool` (which btw all the methods on the `PoolManagerImpl` has as
> arguments). It casts every generic `Pool` to its implementation. This is
> a very limiting factor.
>
> I understand that delaying a release is not optimal, but how much effort
> to we believe it to be to clean up the code that so tightly couples
> implementations together.
>
> I think we also must not forget that  John, like many of us, is a
> committer and PMC member on Geode. He also happens to be the main
> committer on SDG, SBDG, SSDG, STDG. But if he feels that a release
> should not go out without fixing a limiting feature to the Geode
> project, then he may do so.
>
> I also feel that this is a limiting factor.
>
> The only difference is that I am not the main committer on the Spring
> data projects for Geode. John is merely trying to get the best outcome
> for both projects.
>
> --Udo
>
> On 12/4/19 4:39 PM, Dan Smith wrote:
> >> Quite frankly the reasons STDG (or dependent projects downstream like
> SDG,
> >> SBDG, SSDG) are doing what it is (they are) doing is irrelevant to point
> >> articulated in the description of GEODE-753.
> >>
> > What bothers me here is not your suggestions in GEODE-1753, but the fact
> > that you are vetoing a Geode release because STDG is using an internal
> > Geode method and had a problem.
> >
> > How hard is it to remove the use of PoolManagerImpl from STDG? If we can
> > fix the issue there, that seems better than putting bandaids into the
> > release branch so STDG can continue to use internal APIs.
> >
> > -Dan
> >
>

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

[Udo Kohlmeyer]

@Dan,

I will add my -1 to this.

I understand your argument of "let's solve the problem by removing  the 
offender".


But in reality who is the offender? Is it the one class that is using an 
"internal" api OR is it the implementation itself that is to tightly 
coupled that extending it is impossible?


STDG right now is trying to create a test, to test functionality that 
requires it to inject/mock a Pool. The smallest piece of the code, not 
the WHOLE PoolManager. But the system does not allow for the injection 
of a `Pool` (which btw all the methods on the `PoolManagerImpl` has as 
arguments). It casts every generic `Pool` to its implementation. This is 
a very limiting factor.


I understand that delaying a release is not optimal, but how much effort 
to we believe it to be to clean up the code that so tightly couples 
implementations together.


I think we also must not forget that  John, like many of us, is a 
committer and PMC member on Geode. He also happens to be the main 
committer on SDG, SBDG, SSDG, STDG. But if he feels that a release 
should not go out without fixing a limiting feature to the Geode 
project, then he may do so.


I also feel that this is a limiting factor.

The only difference is that I am not the main committer on the Spring 
data projects for Geode. John is merely trying to get the best outcome 
for both projects.


--Udo

On 12/4/19 4:39 PM, Dan Smith wrote:

Quite frankly the reasons STDG (or dependent projects downstream like SDG,
SBDG, SSDG) are doing what it is (they are) doing is irrelevant to point
articulated in the description of GEODE-753.


What bothers me here is not your suggestions in GEODE-1753, but the fact
that you are vetoing a Geode release because STDG is using an internal
Geode method and had a problem.

How hard is it to remove the use of PoolManagerImpl from STDG? If we can
fix the issue there, that seems better than putting bandaids into the
release branch so STDG can continue to use internal APIs.

-Dan

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

[Dan Smith]

>
> Quite frankly the reasons STDG (or dependent projects downstream like SDG,
> SBDG, SSDG) are doing what it is (they are) doing is irrelevant to point
> articulated in the description of GEODE-753.
>

What bothers me here is not your suggestions in GEODE-1753, but the fact
that you are vetoing a Geode release because STDG is using an internal
Geode method and had a problem.

How hard is it to remove the use of PoolManagerImpl from STDG? If we can
fix the issue there, that seems better than putting bandaids into the
release branch so STDG can continue to use internal APIs.

-Dan

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

[John Blum]

See comment

[1]
on ticket, GEODE-7531 
 [2].

Quite frankly the reasons STDG (or dependent projects downstream like SDG,
SBDG, SSDG) are doing what it is (they are) doing is irrelevant to point
articulated in the description of GEODE-753.

[1]
https://issues.apache.org/jira/browse/GEODE-7531?focusedCommentId=16988282=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16988282
[2] https://issues.apache.org/jira/browse/GEODE-7531

On Wed, Dec 4, 2019 at 4:06 PM Dan Smith  wrote:

> On Wed, Dec 4, 2019 at 2:11 PM John Blum  wrote:
>
> > This is not a test failure in SDG.  SDG builds fine with Apache Geode
> 1.11
> > (and all tests pass), as I indicated above in my origin +0 vote.
> >
> > This is a definitive problem for SBDG when using STDG to mock Apache
> Geode
> > resources/objects, which is caused by GEODE-7531.
> >
>
> Hmm, looks like STDG is also using an internal API to inject a mock into
> the PoolManager singleton:
>
> https://github.com/spring-projects/spring-test-data-geode/blob/9a091376528cd79c978bc5b3019d30256fcf3fd5/spring-data-geode-test/src/main/java/org/springframework/data/gemfire/tests/mock/GemFireMockObjectsSupport.java#L1750
>
> Maybe it would be better to fix that? I don't think injecting anything into
> Geode singletons is a good approach - it will likely lead to mysterious
> errors in future tests. And using internal APIs tends to result in breakage
> while upgrading, as evidenced here.
>
> A more complete fix to Geode might be deprecate the static PoolManager
> entirely and move the pool management functionality to ClientCache. That
> might make it easier for you to mock the whole system? In the short term
> perhaps SDG, STDG, etc. can wrap the PoolManager in something that can have
> a mock injected into it, without using internal APIs?
>
> -Dan
>


-- 
-John
Spring Data Team

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

[Dan Smith]

On Wed, Dec 4, 2019 at 2:11 PM John Blum  wrote:

> This is not a test failure in SDG.  SDG builds fine with Apache Geode 1.11
> (and all tests pass), as I indicated above in my origin +0 vote.
>
> This is a definitive problem for SBDG when using STDG to mock Apache Geode
> resources/objects, which is caused by GEODE-7531.
>

Hmm, looks like STDG is also using an internal API to inject a mock into
the PoolManager singleton:
https://github.com/spring-projects/spring-test-data-geode/blob/9a091376528cd79c978bc5b3019d30256fcf3fd5/spring-data-geode-test/src/main/java/org/springframework/data/gemfire/tests/mock/GemFireMockObjectsSupport.java#L1750

Maybe it would be better to fix that? I don't think injecting anything into
Geode singletons is a good approach - it will likely lead to mysterious
errors in future tests. And using internal APIs tends to result in breakage
while upgrading, as evidenced here.

A more complete fix to Geode might be deprecate the static PoolManager
entirely and move the pool management functionality to ClientCache. That
might make it easier for you to mock the whole system? In the short term
perhaps SDG, STDG, etc. can wrap the PoolManager in something that can have
a mock injected into it, without using internal APIs?

-Dan

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

[Mark Hanson]

So, outstanding issues that I see right now are 

GEODE-7531
GEODE-7537
GEODE-7538

Thanks,
Mark

> On Dec 4, 2019, at 2:11 PM, John Blum  wrote:
> 
> This is not a test failure in SDG.  SDG builds fine with Apache Geode 1.11
> (and all tests pass), as I indicated above in my origin +0 vote.
> 
> This is a definitive problem for SBDG when using STDG to mock Apache Geode
> resources/objects, which is caused by GEODE-7531.
> 
> Either way, the design/code changes made in GEODE-6759 were poor and should
> be fixed regardless which GEODE-7531 describes.
> 
> -j
> 
> 
> On Wed, Dec 4, 2019 at 2:04 PM Dan Smith  wrote:
> 
>> On Wed, Dec 4, 2019 at 11:16 AM John Blum  wrote:
>> 
>>> I am changing my vote to -1!
>>> 
>>> I have filed GEODE-7531 <
>> https://issues.apache.org/jira/browse/GEODE-7531>
>>> [1],
>>> which is a serious blocking issue for all things *Spring* for Apache
>>> Geode.  This issue alone is currently preventing me from upgrading
>> *Spring
>>> Boot for Apache Geode* (SBDG) to Apache Geode 1.10, which I plan to do in
>>> SBDG 1.3, which is based on *Spring Data for Apache Geode* (SDG)
>>> Neumann/2.3, which is currently already pulling in Apache Geode 1.10,
>> soon
>>> to be upgraded to 1.11 once this issue is resolved and 1.11 is available.
>>> 
>> 
>> 
>> I commented on the above JIRA. While we definitely don't want to break
>> spring data geode, it looks like maybe the issue is just with one unit test
>> in Spring Data Geode using an internal geode API to inject something into a
>> singleton? If that's the case, I think it would be better to fix that one
>> test in SDG.
>> 
>> -Dan
>> 
> 
> 
> -- 
> -John
> Spring Data Team

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

[John Blum]

This is not a test failure in SDG.  SDG builds fine with Apache Geode 1.11
(and all tests pass), as I indicated above in my origin +0 vote.

This is a definitive problem for SBDG when using STDG to mock Apache Geode
resources/objects, which is caused by GEODE-7531.

Either way, the design/code changes made in GEODE-6759 were poor and should
be fixed regardless which GEODE-7531 describes.

-j


On Wed, Dec 4, 2019 at 2:04 PM Dan Smith  wrote:

> On Wed, Dec 4, 2019 at 11:16 AM John Blum  wrote:
>
> > I am changing my vote to -1!
> >
> > I have filed GEODE-7531 <
> https://issues.apache.org/jira/browse/GEODE-7531>
> > [1],
> > which is a serious blocking issue for all things *Spring* for Apache
> > Geode.  This issue alone is currently preventing me from upgrading
> *Spring
> > Boot for Apache Geode* (SBDG) to Apache Geode 1.10, which I plan to do in
> > SBDG 1.3, which is based on *Spring Data for Apache Geode* (SDG)
> > Neumann/2.3, which is currently already pulling in Apache Geode 1.10,
> soon
> > to be upgraded to 1.11 once this issue is resolved and 1.11 is available.
> >
>
>
> I commented on the above JIRA. While we definitely don't want to break
> spring data geode, it looks like maybe the issue is just with one unit test
> in Spring Data Geode using an internal geode API to inject something into a
> singleton? If that's the case, I think it would be better to fix that one
> test in SDG.
>
> -Dan
>


-- 
-John
Spring Data Team

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

[Dan Smith]

On Wed, Dec 4, 2019 at 11:16 AM John Blum  wrote:

> I am changing my vote to -1!
>
> I have filed GEODE-7531 
> [1],
> which is a serious blocking issue for all things *Spring* for Apache
> Geode.  This issue alone is currently preventing me from upgrading *Spring
> Boot for Apache Geode* (SBDG) to Apache Geode 1.10, which I plan to do in
> SBDG 1.3, which is based on *Spring Data for Apache Geode* (SDG)
> Neumann/2.3, which is currently already pulling in Apache Geode 1.10, soon
> to be upgraded to 1.11 once this issue is resolved and 1.11 is available.
>


I commented on the above JIRA. While we definitely don't want to break
spring data geode, it looks like maybe the issue is just with one unit test
in Spring Data Geode using an internal geode API to inject something into a
singleton? If that's the case, I think it would be better to fix that one
test in SDG.

-Dan

Re: Request for addition to 1.11 RC: GEODE-7454: Docs for Cluster Management Service

[Owen Nichols]

Go for it

> On Dec 4, 2019, at 11:32 AM, Dave Barnes  wrote:
> 
> Following up: Thanks for incorporating this docs-only change into the
> release candidate.
> When testing, I realized I need to add a template variable to the config
> file to make this work.
> Anyone object to me submitting a 1-line change in each of the 2 affected
> files?
> Again, docs only, no code change.
> (The corresponding change has already been incorporated on the 'develop'
> branch.)
> 
> On Tue, Dec 3, 2019 at 2:49 PM Mark Hanson  wrote:
> 
>> Done.
>> 
>>> On Dec 3, 2019, at 9:24 AM, Dave Barnes  wrote:
>>> 
>>> Docs for a feature that's already implemented - no code changes.
>>> Can be cherry-picked from the develop branch as-is with no modifications.
>>> 
>> https://github.com/apache/geode/commit/e48f34048c574440ed7e0640f42e9c82d789becb
>> 
>> 

Re: Request for addition to 1.11 RC: GEODE-7454: Docs for Cluster Management Service

[Dave Barnes]

Following up: Thanks for incorporating this docs-only change into the
release candidate.
When testing, I realized I need to add a template variable to the config
file to make this work.
Anyone object to me submitting a 1-line change in each of the 2 affected
files?
Again, docs only, no code change.
(The corresponding change has already been incorporated on the 'develop'
branch.)

On Tue, Dec 3, 2019 at 2:49 PM Mark Hanson  wrote:

> Done.
>
> > On Dec 3, 2019, at 9:24 AM, Dave Barnes  wrote:
> >
> > Docs for a feature that's already implemented - no code changes.
> > Can be cherry-picked from the develop branch as-is with no modifications.
> >
> https://github.com/apache/geode/commit/e48f34048c574440ed7e0640f42e9c82d789becb
>
>

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

[Mark Hanson]

Just an update…

1.11.0.RC3 is not going out. We are in a holding pattern on RC4 due to the 
issue that Lynn mentioned and other issues found.

This is another strike against that RC3 release. 

If the contributors deem the fix necessary ( I assume they would ), we will put 
in a fix for that as well.

I will provide the full list of outstanding issues shortly.

Thanks,
Mark 

> On Dec 4, 2019, at 11:16 AM, John Blum  wrote:
> 
> I am changing my vote to -1!
> 
> I have filed GEODE-7531  
> [1],
> which is a serious blocking issue for all things *Spring* for Apache
> Geode.  This issue alone is currently preventing me from upgrading *Spring
> Boot for Apache Geode* (SBDG) to Apache Geode 1.10, which I plan to do in
> SBDG 1.3, which is based on *Spring Data for Apache Geode* (SDG)
> Neumann/2.3, which is currently already pulling in Apache Geode 1.10, soon
> to be upgraded to 1.11 once this issue is resolved and 1.11 is available.
> 
> If you need further explanation, you don't need to look any further than
> the description as well as my comment
> 
> [2].
> 
> -j
> 
> [1] https://issues.apache.org/jira/browse/GEODE-7531
> [2]
> https://issues.apache.org/jira/browse/GEODE-7531?focusedCommentId=16988096=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16988096
> 
> 
> On Wed, Dec 4, 2019 at 9:24 AM John Blum  wrote:
> 
>> Indeed, both dependencies (geode-logging & geode-serialization) are
>> listed as runtime dependencies.
>> 
>> *> Is SDG creating its dependencies manually?*
>> 
>> I am not quite following your thinking on this question.  Of course SDG
>> uses transitive dependencies. SDG must declare direct dependencies on
>> geode-core, geode-cq, geode-lucene and geode-wan., as it is using those
>> features API to implement the functionality provided by SDG.
>> 
>> Anyway, it because Apache Geode's public API is broken/incomplete
>> (especially from a framework/tooling perspective, but even an application
>> perspective in many cases) that SDG must rely on certain (non-protected)
>> "internal" APIs.  It turns out that those "internal" classes have hard
>> (i.e. compile-time) dependencies on geode-logging & geode-serialization
>> to even build a project (application, framework or otherwise) using those
>> classes with Apache Geode.
>> 
>> I am currently exploring whether I can alter the use of the "internal"
>> class(es) to avoid forcing a compile-time dependency.
>> 
>> -j
>> 
>> 
>> On Mon, Dec 2, 2019 at 12:42 PM Jacob Barrett  wrote:
>> 
>>> 
>>> 
 On Dec 1, 2019, at 2:40 PM, John Blum  wrote:
 
 After some modifications to Spring Data for Apache Geode (Spring Data
 Geode; SDG), I was finally able to build SDG with Apache Geode 1.11.
 
 While I support the modularization effort, I would make it very clear
>>> (in
 documentation) now that both geode-logging and geode-serialization are
 required on the application classpath when using Apache Geode.
 
 Technically, I am not entirely certain about geode-serialization (yet),
>>> but
 geode-logging is strictly required to use Apache Geode.  I need to run
>>> some
 more tests.
>>> 
>>> Both are properly listed as runtime scope in the geode-core POM. Is SDG
>>> creating its dependencies manually or using the transitive dependencies
>>> from the Geode POMs?
>>> 
>>> -Jake
>>> 
>>> 
>>> 
>>> 
>> 
>> --
>> -John
>> john.blum10101 (skype)
>> 
> 
> 
> -- 
> -John
> Spring Data Team

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

[Jacob Barrett]

> On Dec 4, 2019, at 9:24 AM, John Blum  wrote:
> 
> Anyway, it because Apache Geode's public API is broken/incomplete
> (especially from a framework/tooling perspective, but even an application
> perspective in many cases) that SDG must rely on certain (non-protected)
> "internal" APIs.  It turns out that those "internal" classes have hard
> (i.e. compile-time) dependencies on geode-logging & geode-serialization to
> even build a project (application, framework or otherwise) using those
> classes with Apache Geode.

For those internal classes you use perhaps you can provide an RFC to move them 
to or augment the public API? If external things need them we should find a 
more elegant way to do this than chasing changing internals.

-Jake

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

[John Blum]

I am changing my vote to -1!

I have filed GEODE-7531  [1],
which is a serious blocking issue for all things *Spring* for Apache
Geode.  This issue alone is currently preventing me from upgrading *Spring
Boot for Apache Geode* (SBDG) to Apache Geode 1.10, which I plan to do in
SBDG 1.3, which is based on *Spring Data for Apache Geode* (SDG)
Neumann/2.3, which is currently already pulling in Apache Geode 1.10, soon
to be upgraded to 1.11 once this issue is resolved and 1.11 is available.

If you need further explanation, you don't need to look any further than
the description as well as my comment

 [2].

-j

[1] https://issues.apache.org/jira/browse/GEODE-7531
[2]
https://issues.apache.org/jira/browse/GEODE-7531?focusedCommentId=16988096=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16988096


On Wed, Dec 4, 2019 at 9:24 AM John Blum  wrote:

> Indeed, both dependencies (geode-logging & geode-serialization) are
> listed as runtime dependencies.
>
> *> Is SDG creating its dependencies manually?*
>
> I am not quite following your thinking on this question.  Of course SDG
> uses transitive dependencies. SDG must declare direct dependencies on
> geode-core, geode-cq, geode-lucene and geode-wan., as it is using those
> features API to implement the functionality provided by SDG.
>
> Anyway, it because Apache Geode's public API is broken/incomplete
> (especially from a framework/tooling perspective, but even an application
> perspective in many cases) that SDG must rely on certain (non-protected)
> "internal" APIs.  It turns out that those "internal" classes have hard
> (i.e. compile-time) dependencies on geode-logging & geode-serialization
> to even build a project (application, framework or otherwise) using those
> classes with Apache Geode.
>
> I am currently exploring whether I can alter the use of the "internal"
> class(es) to avoid forcing a compile-time dependency.
>
> -j
>
>
> On Mon, Dec 2, 2019 at 12:42 PM Jacob Barrett  wrote:
>
>>
>>
>> > On Dec 1, 2019, at 2:40 PM, John Blum  wrote:
>> >
>> > After some modifications to Spring Data for Apache Geode (Spring Data
>> > Geode; SDG), I was finally able to build SDG with Apache Geode 1.11.
>> >
>> > While I support the modularization effort, I would make it very clear
>> (in
>> > documentation) now that both geode-logging and geode-serialization are
>> > required on the application classpath when using Apache Geode.
>> >
>> > Technically, I am not entirely certain about geode-serialization (yet),
>> but
>> > geode-logging is strictly required to use Apache Geode.  I need to run
>> some
>> > more tests.
>>
>> Both are properly listed as runtime scope in the geode-core POM. Is SDG
>> creating its dependencies manually or using the transitive dependencies
>> from the Geode POMs?
>>
>> -Jake
>>
>>
>>
>>
>
> --
> -John
> john.blum10101 (skype)
>


-- 
-John
Spring Data Team

Re: [DISCUSSION] De/un-deprecate IndexType ENUM

[Bruce Schuchardt]

This proposal seems reasonable to me

On 12/3/19 10:19 AM, Joris Melchior wrote:

Ah, that makes sense. I will update!


On Tue, Dec 3, 2019 at 12:41 PM Alexander Murmann 
wrote:


Joris, the "to be reviewed by" field is for a target date by which to wrap
up the discussion. Do you mind updating the field and letting the mailing
list know what timeframe you envision?

Thanks!

On Mon, Dec 2, 2019 at 1:41 PM Joris Melchior 
wrote:


Hi All,

Looking for feedback on the proposal to [un/de]deprecate the IndexType

ENUM

on Geode.



https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=135863477

Thanks, Joris.

--
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

[John Blum]

Indeed, both dependencies (geode-logging & geode-serialization) are listed
as runtime dependencies.

*> Is SDG creating its dependencies manually?*

I am not quite following your thinking on this question.  Of course SDG
uses transitive dependencies. SDG must declare direct dependencies on
geode-core, geode-cq, geode-lucene and geode-wan., as it is using those
features API to implement the functionality provided by SDG.

Anyway, it because Apache Geode's public API is broken/incomplete
(especially from a framework/tooling perspective, but even an application
perspective in many cases) that SDG must rely on certain (non-protected)
"internal" APIs.  It turns out that those "internal" classes have hard
(i.e. compile-time) dependencies on geode-logging & geode-serialization to
even build a project (application, framework or otherwise) using those
classes with Apache Geode.

I am currently exploring whether I can alter the use of the "internal"
class(es) to avoid forcing a compile-time dependency.

-j


On Mon, Dec 2, 2019 at 12:42 PM Jacob Barrett  wrote:

>
>
> > On Dec 1, 2019, at 2:40 PM, John Blum  wrote:
> >
> > After some modifications to Spring Data for Apache Geode (Spring Data
> > Geode; SDG), I was finally able to build SDG with Apache Geode 1.11.
> >
> > While I support the modularization effort, I would make it very clear (in
> > documentation) now that both geode-logging and geode-serialization are
> > required on the application classpath when using Apache Geode.
> >
> > Technically, I am not entirely certain about geode-serialization (yet),
> but
> > geode-logging is strictly required to use Apache Geode.  I need to run
> some
> > more tests.
>
> Both are properly listed as runtime scope in the geode-core POM. Is SDG
> creating its dependencies manually or using the transitive dependencies
> from the Geode POMs?
>
> -Jake
>
>
>
>

-- 
-John
john.blum10101 (skype)

Re: WAN replication issue in cloud native environments

[Charlie Black]

Alberto,

Something else to think about SNI based routing.   I believe Mario might be
working on adding SNI to Geode - he at least had a proposal that he
e-mailed out.

Basics are the destination host is in the SNI field and the proxy can
inspect and route the request to the right service instance. Plus we
have the option to not terminate the SSL at the proxy.

Full disclosure - I haven't tried out SNI based routing myself and it is
something that I thought could work as I was reading about it.   From the
whiteboard I have done I think this will do ingress and egress just fine.
Potentially easier then port mapping and `hostname for clients` playing
around.

Just something to think about.

Charlie


On Wed, Dec 4, 2019 at 3:19 AM Alberto Bustamante Reyes
 wrote:

> Hi Jacob,
>
> Yes,we are using LoadBalancer service type. But note the problem is not
> the transport layer but on Geode as GW senders are complaining
> “sender-2-parallel : Could not connect due to: There are no active
> servers.” when one of the servers in the receiving cluster is killed.
>
> So, there is still one server alive in the receiving cluster but GW sender
> does not know it and the locator is not able to inform about its existence.
> Looking at the code it seems internal data structures (maps) holding the
> profiles use object whose equality check relies only on hostname and port.
> This makes it impossible to differentiate servers when the same
> “hostname-for-senders” and port are used. When the killed server comes back
> up, the locator profiles are updated (internal map back to size()=1
> although 2+ servers are there) and GW senders happily reconnect.
>
> The solution with the Geode as-is would be to expose each GW receiver on a
> different port outside of k8s cluster, this includes creating N Kubernetes
> services for N GW receivers in addition to updating the service mesh
> configuration (if it is used, firewalls etc…). Declarative nature of
> kubernetes means we must know the ports in advance hence start-port and
> end-port when creating each GW receiver must be equal and we should have
> some well-known
> algorithm when creating GW receivers across servers. For example: server-0
> port 5000, server-1 port 5001, server-2 port 5002 etc…. So, all GW
> receivers must be wired individually and we must turn off Geode’s random
> port allocation.
>
> But we are exploring the possibility for Geode to handle this cloud-native
> configuration a bit better. Locators should be capable of holding GW
> receiver information although they are hidden behind same hostname and port.
> This is a code change in Geode and we would like to have community opinion
> on it.
>
> Some obvious impacts with the legacy behavior would be when locator picks
> a server on behalf of the client (GW sender in this case) it does so based
>  on the server load. When sender connects and considering all servers are
> using same VIP:PORT it is load balancer that will decide where the
> connection will end up, but likely not on the one selected by locator. So
> here we ignore the locator instructions. Since GW senders normally do not
> create huge number of connections this probably shall not unbalance cluster
> too much. But this is an impact worth considering. Custom load metrics
> would also be ignored by GW senders. Opinions?
>
> Additional impact that comes to mind is GW sender load-balance command and
> how it’s execution would be affected.
>
> Thanks!
>
> Alberto B.
>
> 
> De: Jacob Barrett 
> Enviado: viernes, 29 de noviembre de 2019 13:06
> Para: dev@geode.apache.org 
> Asunto: Re: WAN replication issue in cloud native environments
>
>
>
> > On Nov 29, 2019, at 3:14 AM, Alberto Bustamante Reyes
>  wrote:
> >
> > The reason for such a setup is deploying Geode cluster on a Kubernetes
> cluster where all GW receivers are reachable from the outside world on the
> same VIP and port.
>
> Are you using LoadBalancer Service type?
>
> > Other kinds of configuration (different hostname and/or different port
> for each GW receiver) are not cheap from OAM and resources perspective in
> cloud native environments and also limit some important use-cases (like
> scaling).
>
> If you could somehow configure host and port for sender (code modification
> required) would exposing each port through the LoadBalancer be too
> expensive too?
>
> > The problem experienced is that shutting down one server is stopping
> replication to this cluster until the server is up again. We suspect this
> is because Geode incorrectly assumes there are no more alive servers when
> just one of them is down (since they share hostname-for-senders and port).
>
> Sees like at the worst case when it tries to reconnect the LB should give
> it a live server and it think the single server is back up.
>
> -Jake
>
>

-- 
Charlie Black | cbl...@pivotal.io

Re: Wiki access

[Dan Smith]

Done. You should have access now.

Thanks!
-Dan

On Wed, Dec 4, 2019 at 4:05 AM Mario Kevo  wrote:

> Hi All,
>
> Can I have access to edit the Geode Wiki?
> My username is "mario.kevo".
>
> Thanks,
> Mario
>

Wiki access

[Mario Kevo]

Hi All,

Can I have access to edit the Geode Wiki?
My username is "mario.kevo".

Thanks,
Mario

RE: WAN replication issue in cloud native environments

[Alberto Bustamante Reyes]

Hi Jacob,

Yes,we are using LoadBalancer service type. But note the problem is not the 
transport layer but on Geode as GW senders are complaining “sender-2-parallel : 
Could not connect due to: There are no active servers.” when one of the servers 
in the receiving cluster is killed.

So, there is still one server alive in the receiving cluster but GW sender does 
not know it and the locator is not able to inform about its existence. Looking 
at the code it seems internal data structures (maps) holding the profiles use 
object whose equality check relies only on hostname and port. This makes it 
impossible to differentiate servers when the same “hostname-for-senders” and 
port are used. When the killed server comes back up, the locator profiles are 
updated (internal map back to size()=1 although 2+ servers are there) and GW 
senders happily reconnect.

The solution with the Geode as-is would be to expose each GW receiver on a 
different port outside of k8s cluster, this includes creating N Kubernetes 
services for N GW receivers in addition to updating the service mesh 
configuration (if it is used, firewalls etc…). Declarative nature of kubernetes 
means we must know the ports in advance hence start-port and end-port when 
creating each GW receiver must be equal and we should have some well-known
algorithm when creating GW receivers across servers. For example: server-0 port 
5000, server-1 port 5001, server-2 port 5002 etc…. So, all GW receivers must be 
wired individually and we must turn off Geode’s random port allocation.

But we are exploring the possibility for Geode to handle this cloud-native 
configuration a bit better. Locators should be capable of holding GW receiver 
information although they are hidden behind same hostname and port.
This is a code change in Geode and we would like to have community opinion on 
it.

Some obvious impacts with the legacy behavior would be when locator picks a 
server on behalf of the client (GW sender in this case) it does so based
 on the server load. When sender connects and considering all servers are using 
same VIP:PORT it is load balancer that will decide where the connection will 
end up, but likely not on the one selected by locator. So here we ignore the 
locator instructions. Since GW senders normally do not create huge number of 
connections this probably shall not unbalance cluster too much. But this is an 
impact worth considering. Custom load metrics would also be ignored by GW 
senders. Opinions?

Additional impact that comes to mind is GW sender load-balance command and how 
it’s execution would be affected.

Thanks!

Alberto B.


De: Jacob Barrett 
Enviado: viernes, 29 de noviembre de 2019 13:06
Para: dev@geode.apache.org 
Asunto: Re: WAN replication issue in cloud native environments



> On Nov 29, 2019, at 3:14 AM, Alberto Bustamante Reyes 
>  wrote:
>
> The reason for such a setup is deploying Geode cluster on a Kubernetes 
> cluster where all GW receivers are reachable from the outside world on the 
> same VIP and port.

Are you using LoadBalancer Service type?

> Other kinds of configuration (different hostname and/or different port for 
> each GW receiver) are not cheap from OAM and resources perspective in cloud 
> native environments and also limit some important use-cases (like scaling).

If you could somehow configure host and port for sender (code modification 
required) would exposing each port through the LoadBalancer be too expensive 
too?

> The problem experienced is that shutting down one server is stopping 
> replication to this cluster until the server is up again. We suspect this is 
> because Geode incorrectly assumes there are no more alive servers when just 
> one of them is down (since they share hostname-for-senders and port).

Sees like at the worst case when it tries to reconnect the LB should give it a 
live server and it think the single server is back up.

-Jake