[PROPOSAL] Backport GEODE-8423 to support/1.13

[Sarah Abbey]

The documentation for the Redis API for Geode that will currently be published 
for 1.13 is not accurate and needs to be updated so potential users searching 
for information about Redis API for Geode will get accurate information.

Re: [PROPOSAL] Backport GEODE-8423 to support/1.13

[Darrel Schneider]

+1

From: Sarah Abbey 
Sent: Wednesday, August 12, 2020 8:59 AM
To: dev@geode.apache.org 
Subject: [PROPOSAL] Backport GEODE-8423 to support/1.13

The documentation for the Redis API for Geode that will currently be published 
for 1.13 is not accurate and needs to be updated so potential users searching 
for information about Redis API for Geode will get accurate information.

Re: [PROPOSAL] Backport GEODE-8423 to support/1.13

[Dave Barnes]

+1


On Wed, Aug 12, 2020 at 9:10 AM Darrel Schneider  wrote:

> +1
> 
> From: Sarah Abbey 
> Sent: Wednesday, August 12, 2020 8:59 AM
> To: dev@geode.apache.org 
> Subject: [PROPOSAL] Backport GEODE-8423 to support/1.13
>
> The documentation for the Redis API for Geode that will currently be
> published for 1.13 is not accurate and needs to be updated so potential
> users searching for information about Redis API for Geode will get accurate
> information.
>

Re: [PROPOSAL] Backport GEODE-8423 to support/1.13

[Dan Smith]

+1

-Dan

On Aug 12, 2020, at 8:59 AM, Sarah Abbey 
mailto:sab...@vmware.com>> wrote:

get

Re: [PROPOSAL] Backport GEODE-8423 to support/1.13

[Patrick Johnson]

+1

> On Aug 12, 2020, at 8:59 AM, Sarah Abbey  wrote:
> 
> The documentation for the Redis API for Geode that will currently be 
> published for 1.13 is not accurate and needs to be updated so potential users 
> searching for information about Redis API for Geode will get accurate 
> information.

Re: [PROPOSAL] Backport GEODE-8423 to support/1.13

[Dave Barnes]

OK, Sarah, you have the requisite 3 votes -- go ahead and back-port.
Thanks for your contribution!
-Dave

On Wed, Aug 12, 2020 at 9:24 AM Dan Smith  wrote:

> +1
>
> -Dan
>
> On Aug 12, 2020, at 8:59 AM, Sarah Abbey  sab...@vmware.com>> wrote:
>
> get
>
>

Re: [DISCUSS] proposal for WAN support of an ingress proxy

[Aaron Lindsey]

Sounds good to me. I like the idea of using a proxy instead of the 
--hostname-for-clients solution where you cannot specify the particular server 
of which to connect. And it seems good to use the same approach that was used 
for "off platform" clients.

Aaron


From: Bruce Schuchardt 
Sent: Monday, August 3, 2020 9:00 AM
To: dev@geode.apache.org
Subject: [DISCUSS] proposal for WAN support of an ingress proxy

In some environments it’s expensive to provide all server machines with 
externally-resolvable hostnames.  We recently added support for “off platform” 
clients to access servers through an ingress 
proxy
  for this type of environment.  I’m proposing to do the same for inter-cluster 
(“WAN”) communications.

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FWAN%2BConfiguration%2Bfor%2Ban%2BIngress%2BProxy&data=02%7C01%7Calindsey%40vmware.com%7C0b91131a69294c16c85808d837c657c1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637320672304750396&sdata=V839395xkQA3i2UChAUpFpTnvOGVP%2B8xTqZlHQSE69M%3D&reserved=0

This improvement will allow one cluster to forward events to another cluster 
even though the other cluster’s machines do not have resolvable hostnames.  
Communications will go through a Proxy process hosted in the other cluster with 
a resolvable hostname.  The user-visible changes in this proposal are small, 
changing the “remote-locators” setting to allow for a new syntax.

I’m not proposing to implement a Proxy.  There are numerous Proxy products 
available that could fit into this scheme such as HAProxy, Envoy, and NGIX.

I will probably start with an SNI-based implementation and leverage work 
already done for client/server communications.

Please provide feedback by the end of 14 august.  Thanks!

TimeIntegrationTest is flaky

[Kirk Lund]

Since this is a new test, can we please prioritize fixing it?

https://issues.apache.org/jira/browse/GEODE-8379

java.lang.AssertionError:
Expecting:
 <0L>
to be greater than:
 <0L>
at
org.apache.geode.redis.internal.executor.server.TimeIntegrationTest.timeCommandRespondsWIthTwoValues(TimeIntegrationTest.java:57)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at
org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
at
org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
at
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at
org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
at
org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:118)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:175)
at
org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:157)
at
org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:404)
at
org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
at
org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at
org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
at java.lang.Thread.run(Thread.java:834)

[Proposal] Backport GEODE-8422 to support/1.13

[Mark Hanson]

Hi All,

We have found a case where tombstones were being cleared when the region was 
not initialized. This was causing some test failures and potential field 
failures. We would like to put this into support/1.13.

Thanks,
Mark

Re: [Proposal] Backport GEODE-8422 to support/1.13

[Donal Evans]

+1

From: Mark Hanson 
Sent: Wednesday, August 12, 2020 4:40 PM
To: dev@geode.apache.org 
Subject: [Proposal] Backport GEODE-8422 to support/1.13

Hi All,

We have found a case where tombstones were being cleared when the region was 
not initialized. This was causing some test failures and potential field 
failures. We would like to put this into support/1.13.

Thanks,
Mark

Re: [Proposal] Backport GEODE-8422 to support/1.13

[Jianxia Chen]

+1

On Wed, Aug 12, 2020 at 4:41 PM Mark Hanson  wrote:

> Hi All,
>
> We have found a case where tombstones were being cleared when the region
> was not initialized. This was causing some test failures and potential
> field failures. We would like to put this into support/1.13.
>
> Thanks,
> Mark
>

Re: [Proposal] Backport GEODE-8422 to support/1.13

[Dave Barnes]

Has the version on the develop branch completed a test cycle?

On Wed, Aug 12, 2020 at 4:52 PM Jianxia Chen  wrote:

> +1
>
> On Wed, Aug 12, 2020 at 4:41 PM Mark Hanson  wrote:
>
> > Hi All,
> >
> > We have found a case where tombstones were being cleared when the region
> > was not initialized. This was causing some test failures and potential
> > field failures. We would like to put this into support/1.13.
> >
> > Thanks,
> > Mark
> >
>

Re: [Proposal] Backport GEODE-8422 to support/1.13

[Mark Hanson]

Not yet, we will need to wait for that to finish cleanly relative to this 
change. I guess I was just seeking to gain approval for priority of it once it 
does pass. (Maybe I am being a little over zealous).

Thanks,
Mark

On 8/12/20, 5:52 PM, "Dave Barnes"  wrote:

Has the version on the develop branch completed a test cycle?

On Wed, Aug 12, 2020 at 4:52 PM Jianxia Chen  wrote:

> +1
>
> On Wed, Aug 12, 2020 at 4:41 PM Mark Hanson  wrote:
>
> > Hi All,
> >
> > We have found a case where tombstones were being cleared when the region
> > was not initialized. This was causing some test failures and potential
> > field failures. We would like to put this into support/1.13.
> >
> > Thanks,
> > Mark
> >
>