Re: [VOTE] Apache Geode 1.10.0.RC1

[Owen Nichols]

+1 for catching the correct grgit exception so Geode can compile from src.tgz 
distribution.  I might have gone further and just changed it to catch 
Exception, but it looks like the GrGit project has been stable for the last 2 
years 

 on throwing IllegalStateException, so this fix should be solid.  I tested 
locally and confirmed it solves the problem.

> On Sep 6, 2019, at 2:24 PM, Robert Houghton  wrote:
> 
> +1  to bringing the build-from-source name to 1.10
> -1 to RC1 until then
> 
> On Fri, Sep 6, 2019, 14:21 Owen Nichols  wrote:
> 
>> Hi Anthony, thank you for bringing your concern.
>> 
>> If there is consensus from the Geode community that your proposed fix
>> satisfies the “critical fixes” rule, I will be happy to bring it to the
>> release/1.10.0 release branch.
>> 
>> Regards
>> Dick & Owen
>> 
>>> On Sep 6, 2019, at 2:18 PM, Anthony Baker  wrote:
>>> 
>>> Please pull aaa1378472ce0a8a05e0afabfdfc874e14fe13e6 into the release
>> branch to fix the build problem.
>>> 
>>> Anthony
>>> 
>>> 
 On Sep 6, 2019, at 11:29 AM, Dick Cavender 
>> wrote:
 
 The 1.10.0 voting has been extended until Monday, September 9th at 3pm.
 
 To all- please update your 1.10.0 vote if/when your issue(s) have been
 resolved. There are still no -1 votes at this time.
 
 On Fri, Sep 6, 2019 at 9:32 AM Nabarun Nag  wrote:
 
> Hi Anthony,
> 
> I had faced this issue in the current develop too. One way to get
>> around it
> is to run ./gradlew spotlessApply independently before the build.
> 
> Regards
> Naba
> 
> 
> On Fri, Sep 6, 2019 at 8:53 AM Anthony Baker 
>> wrote:
> 
>> This seems to be a simple change to catch IllegalStateException
>> instead
> of
>> IllegalArgumentException in build.gradle.
>> 
>> But I’m also getting a ton of spotless errors like:
>> 
>>> Task :geode-cq:spotlessJava FAILED
>> Step 'removeUnusedImports' found problem in
>> 
> 
>> 'geode-cq/src/test/java/org/apache/geode/cache/query/internal/cq/CqServiceUnitTest.java':
>> null
>> java.lang.reflect.InvocationTargetException
>>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>  at
>> 
> 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>  at
>> 
> 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>  at java.lang.reflect.Method.invoke(Method.java:498)
>>  at
>> 
> 
>> com.diffplug.spotless.java.GoogleJavaFormatStep$State.lambda$createRemoveUnusedImportsOnly$1(GoogleJavaFormatStep.java:153)
>>  at
> com.diffplug.spotless.FormatterFunc.apply(FormatterFunc.java:31)
>>  at
>> 
> 
>> com.diffplug.spotless.FormatterStepImpl$Standard.format(FormatterStepImpl.java:78)
>>  at
>> 
>> com.diffplug.spotless.FormatterStep$Strict.format(FormatterStep.java:76)
>>  at com.diffplug.spotless.Formatter.compute(Formatter.java:230)
>>  at com.diffplug.spotless.Formatter.isClean(Formatter.java:167)
>>  at
>> com.diffplug.gradle.spotless.SpotlessTask.check(SpotlessTask.java:297)
>>  at
>> 
> 
>> com.diffplug.gradle.spotless.SpotlessTask.performAction(SpotlessTask.java:238)
>>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>  at
>> 
> 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>  at
>> 
> 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>  at java.lang.reflect.Method.invoke(Method.java:498)
>>  at
>> org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:103)
>>  at
>> 
> 
>> org.gradle.api.internal.project.taskfactory.IncrementalTaskInputsTaskAction.doExecute(IncrementalTaskInputsTaskAction.java:46)
>>  at
>> 
> 
>> org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:41)
>>  at
>> 
> 
>> org.gradle.api.internal.project.taskfactory.AbstractIncrementalTaskAction.execute(AbstractIncrementalTaskAction.java:25)
>>  at
>> 
> 
>> org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:28)
>>  at
>> 
> 
>> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$5.run(ExecuteActionsTaskExecuter.java:404)
>>  at
>> 
> 
>> org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:402)
>>  at
>> 
> 
>> org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:394)
>>  at
>> 
> 
>> 

Re: [VOTE] Apache Geode 1.10.0.RC1

[Robert Houghton]

+1  to bringing the build-from-source name to 1.10
-1 to RC1 until then

On Fri, Sep 6, 2019, 14:21 Owen Nichols  wrote:

> Hi Anthony, thank you for bringing your concern.
>
> If there is consensus from the Geode community that your proposed fix
> satisfies the “critical fixes” rule, I will be happy to bring it to the
> release/1.10.0 release branch.
>
> Regards
> Dick & Owen
>
> > On Sep 6, 2019, at 2:18 PM, Anthony Baker  wrote:
> >
> > Please pull aaa1378472ce0a8a05e0afabfdfc874e14fe13e6 into the release
> branch to fix the build problem.
> >
> > Anthony
> >
> >
> >> On Sep 6, 2019, at 11:29 AM, Dick Cavender 
> wrote:
> >>
> >> The 1.10.0 voting has been extended until Monday, September 9th at 3pm.
> >>
> >> To all- please update your 1.10.0 vote if/when your issue(s) have been
> >> resolved. There are still no -1 votes at this time.
> >>
> >> On Fri, Sep 6, 2019 at 9:32 AM Nabarun Nag  wrote:
> >>
> >>> Hi Anthony,
> >>>
> >>> I had faced this issue in the current develop too. One way to get
> around it
> >>> is to run ./gradlew spotlessApply independently before the build.
> >>>
> >>> Regards
> >>> Naba
> >>>
> >>>
> >>> On Fri, Sep 6, 2019 at 8:53 AM Anthony Baker 
> wrote:
> >>>
>  This seems to be a simple change to catch IllegalStateException
> instead
> >>> of
>  IllegalArgumentException in build.gradle.
> 
>  But I’m also getting a ton of spotless errors like:
> 
> > Task :geode-cq:spotlessJava FAILED
>  Step 'removeUnusedImports' found problem in
> 
> >>>
> 'geode-cq/src/test/java/org/apache/geode/cache/query/internal/cq/CqServiceUnitTest.java':
>  null
>  java.lang.reflect.InvocationTargetException
>    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>    at
> 
> >>>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>    at
> 
> >>>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>    at java.lang.reflect.Method.invoke(Method.java:498)
>    at
> 
> >>>
> com.diffplug.spotless.java.GoogleJavaFormatStep$State.lambda$createRemoveUnusedImportsOnly$1(GoogleJavaFormatStep.java:153)
>    at
> >>> com.diffplug.spotless.FormatterFunc.apply(FormatterFunc.java:31)
>    at
> 
> >>>
> com.diffplug.spotless.FormatterStepImpl$Standard.format(FormatterStepImpl.java:78)
>    at
> 
> com.diffplug.spotless.FormatterStep$Strict.format(FormatterStep.java:76)
>    at com.diffplug.spotless.Formatter.compute(Formatter.java:230)
>    at com.diffplug.spotless.Formatter.isClean(Formatter.java:167)
>    at
>  com.diffplug.gradle.spotless.SpotlessTask.check(SpotlessTask.java:297)
>    at
> 
> >>>
> com.diffplug.gradle.spotless.SpotlessTask.performAction(SpotlessTask.java:238)
>    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>    at
> 
> >>>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>    at
> 
> >>>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>    at java.lang.reflect.Method.invoke(Method.java:498)
>    at
>  org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:103)
>    at
> 
> >>>
> org.gradle.api.internal.project.taskfactory.IncrementalTaskInputsTaskAction.doExecute(IncrementalTaskInputsTaskAction.java:46)
>    at
> 
> >>>
> org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:41)
>    at
> 
> >>>
> org.gradle.api.internal.project.taskfactory.AbstractIncrementalTaskAction.execute(AbstractIncrementalTaskAction.java:25)
>    at
> 
> >>>
> org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:28)
>    at
> 
> >>>
> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$5.run(ExecuteActionsTaskExecuter.java:404)
>    at
> 
> >>>
> org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:402)
>    at
> 
> >>>
> org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:394)
>    at
> 
> >>>
> org.gradle.internal.operations.DefaultBuildOperationExecutor$1.execute(DefaultBuildOperationExecutor.java:165)
>    at
> 
> >>>
> org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:250)
>    at
> 
> >>>
> org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:158)
>    at
> 
> >>>
> org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:92)
>    at
> 
> >>>
> 

Re: [VOTE] Apache Geode 1.10.0.RC1

[Owen Nichols]

Hi Anthony, thank you for bringing your concern.

If there is consensus from the Geode community that your proposed fix satisfies 
the “critical fixes” rule, I will be happy to bring it to the release/1.10.0 
release branch.

Regards
Dick & Owen

> On Sep 6, 2019, at 2:18 PM, Anthony Baker  wrote:
> 
> Please pull aaa1378472ce0a8a05e0afabfdfc874e14fe13e6 into the release branch 
> to fix the build problem.
> 
> Anthony
> 
> 
>> On Sep 6, 2019, at 11:29 AM, Dick Cavender  wrote:
>> 
>> The 1.10.0 voting has been extended until Monday, September 9th at 3pm.
>> 
>> To all- please update your 1.10.0 vote if/when your issue(s) have been
>> resolved. There are still no -1 votes at this time.
>> 
>> On Fri, Sep 6, 2019 at 9:32 AM Nabarun Nag  wrote:
>> 
>>> Hi Anthony,
>>> 
>>> I had faced this issue in the current develop too. One way to get around it
>>> is to run ./gradlew spotlessApply independently before the build.
>>> 
>>> Regards
>>> Naba
>>> 
>>> 
>>> On Fri, Sep 6, 2019 at 8:53 AM Anthony Baker  wrote:
>>> 
 This seems to be a simple change to catch IllegalStateException instead
>>> of
 IllegalArgumentException in build.gradle.
 
 But I’m also getting a ton of spotless errors like:
 
> Task :geode-cq:spotlessJava FAILED
 Step 'removeUnusedImports' found problem in
 
>>> 'geode-cq/src/test/java/org/apache/geode/cache/query/internal/cq/CqServiceUnitTest.java':
 null
 java.lang.reflect.InvocationTargetException
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at
 
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   at
 
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:498)
   at
 
>>> com.diffplug.spotless.java.GoogleJavaFormatStep$State.lambda$createRemoveUnusedImportsOnly$1(GoogleJavaFormatStep.java:153)
   at
>>> com.diffplug.spotless.FormatterFunc.apply(FormatterFunc.java:31)
   at
 
>>> com.diffplug.spotless.FormatterStepImpl$Standard.format(FormatterStepImpl.java:78)
   at
 com.diffplug.spotless.FormatterStep$Strict.format(FormatterStep.java:76)
   at com.diffplug.spotless.Formatter.compute(Formatter.java:230)
   at com.diffplug.spotless.Formatter.isClean(Formatter.java:167)
   at
 com.diffplug.gradle.spotless.SpotlessTask.check(SpotlessTask.java:297)
   at
 
>>> com.diffplug.gradle.spotless.SpotlessTask.performAction(SpotlessTask.java:238)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at
 
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   at
 
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:498)
   at
 org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:103)
   at
 
>>> org.gradle.api.internal.project.taskfactory.IncrementalTaskInputsTaskAction.doExecute(IncrementalTaskInputsTaskAction.java:46)
   at
 
>>> org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:41)
   at
 
>>> org.gradle.api.internal.project.taskfactory.AbstractIncrementalTaskAction.execute(AbstractIncrementalTaskAction.java:25)
   at
 
>>> org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:28)
   at
 
>>> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$5.run(ExecuteActionsTaskExecuter.java:404)
   at
 
>>> org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:402)
   at
 
>>> org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:394)
   at
 
>>> org.gradle.internal.operations.DefaultBuildOperationExecutor$1.execute(DefaultBuildOperationExecutor.java:165)
   at
 
>>> org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:250)
   at
 
>>> org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:158)
   at
 
>>> org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:92)
   at
 
>>> org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
   at
 
>>> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:393)
   at
 
>>> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:376)
   at
 

Re: [VOTE] Apache Geode 1.10.0.RC1

[Anthony Baker]

Please pull aaa1378472ce0a8a05e0afabfdfc874e14fe13e6 into the release branch to 
fix the build problem.

Anthony


> On Sep 6, 2019, at 11:29 AM, Dick Cavender  wrote:
> 
> The 1.10.0 voting has been extended until Monday, September 9th at 3pm.
> 
> To all- please update your 1.10.0 vote if/when your issue(s) have been
> resolved. There are still no -1 votes at this time.
> 
> On Fri, Sep 6, 2019 at 9:32 AM Nabarun Nag  wrote:
> 
>> Hi Anthony,
>> 
>> I had faced this issue in the current develop too. One way to get around it
>> is to run ./gradlew spotlessApply independently before the build.
>> 
>> Regards
>> Naba
>> 
>> 
>> On Fri, Sep 6, 2019 at 8:53 AM Anthony Baker  wrote:
>> 
>>> This seems to be a simple change to catch IllegalStateException instead
>> of
>>> IllegalArgumentException in build.gradle.
>>> 
>>> But I’m also getting a ton of spotless errors like:
>>> 
 Task :geode-cq:spotlessJava FAILED
>>> Step 'removeUnusedImports' found problem in
>>> 
>> 'geode-cq/src/test/java/org/apache/geode/cache/query/internal/cq/CqServiceUnitTest.java':
>>> null
>>> java.lang.reflect.InvocationTargetException
>>>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>at
>>> 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>at
>>> 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>at java.lang.reflect.Method.invoke(Method.java:498)
>>>at
>>> 
>> com.diffplug.spotless.java.GoogleJavaFormatStep$State.lambda$createRemoveUnusedImportsOnly$1(GoogleJavaFormatStep.java:153)
>>>at
>> com.diffplug.spotless.FormatterFunc.apply(FormatterFunc.java:31)
>>>at
>>> 
>> com.diffplug.spotless.FormatterStepImpl$Standard.format(FormatterStepImpl.java:78)
>>>at
>>> com.diffplug.spotless.FormatterStep$Strict.format(FormatterStep.java:76)
>>>at com.diffplug.spotless.Formatter.compute(Formatter.java:230)
>>>at com.diffplug.spotless.Formatter.isClean(Formatter.java:167)
>>>at
>>> com.diffplug.gradle.spotless.SpotlessTask.check(SpotlessTask.java:297)
>>>at
>>> 
>> com.diffplug.gradle.spotless.SpotlessTask.performAction(SpotlessTask.java:238)
>>>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>at
>>> 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>at
>>> 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>at java.lang.reflect.Method.invoke(Method.java:498)
>>>at
>>> org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:103)
>>>at
>>> 
>> org.gradle.api.internal.project.taskfactory.IncrementalTaskInputsTaskAction.doExecute(IncrementalTaskInputsTaskAction.java:46)
>>>at
>>> 
>> org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:41)
>>>at
>>> 
>> org.gradle.api.internal.project.taskfactory.AbstractIncrementalTaskAction.execute(AbstractIncrementalTaskAction.java:25)
>>>at
>>> 
>> org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:28)
>>>at
>>> 
>> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$5.run(ExecuteActionsTaskExecuter.java:404)
>>>at
>>> 
>> org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:402)
>>>at
>>> 
>> org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:394)
>>>at
>>> 
>> org.gradle.internal.operations.DefaultBuildOperationExecutor$1.execute(DefaultBuildOperationExecutor.java:165)
>>>at
>>> 
>> org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:250)
>>>at
>>> 
>> org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:158)
>>>at
>>> 
>> org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:92)
>>>at
>>> 
>> org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
>>>at
>>> 
>> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:393)
>>>at
>>> 
>> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:376)
>>>at
>>> 
>> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.access$200(ExecuteActionsTaskExecuter.java:80)
>>>at
>>> 
>> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$TaskExecution.execute(ExecuteActionsTaskExecuter.java:213)
>>>at
>>> 
>> org.gradle.internal.execution.steps.ExecuteStep.lambda$execute$0(ExecuteStep.java:32)
>>>at 

Re: [ANNOUNCE] Apache Geode 1.9.1

[Lyndon Adams]

+1 great to see you pushing forwards!!


> On 6 Sep 2019, at 20:17, John Blum  wrote:
> 
> Congrats Geode Community!
> 
> On Fri, Sep 6, 2019 at 11:04 AM Owen Nichols  > wrote:
> The Apache Geode community is pleased to announce the availability of
> Apache Geode 1.9.1.
> 
> Apache Geode is a data management platform that provides a database-like
> consistency model, reliable transaction processing and a shared-nothing
> architecture to maintain very low latency performance with high concurrency
> processing.
> 
> Geode 1.9.1 improves compatibility with the Spring Data project and fixes a
> performance issue when SSL is enabled.  Users are encouraged to upgrade to
> the latest release.  For the full list of changes please review the release
> notes:
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.1
>  
> 
> 
> The release artifacts can be downloaded from the project website:
> http://geode.apache.org/releases/ 
> 
> The release documentation is available at:
> http://geode.apache.org/docs/guide/19/about_geode.html 
> 
> 
> We would like to thank all the contributors that made the release possible.
> Regards,
> Owen Nichols and Kirk Lund on behalf of the Apache Geode team
> 
> 
> -- 
> -John
> john.blum10101 (skype)

Re: [ANNOUNCE] Apache Geode 1.9.1

[John Blum]

Congrats Geode Community!

On Fri, Sep 6, 2019 at 11:04 AM Owen Nichols  wrote:

> The Apache Geode community is pleased to announce the availability of
> Apache Geode 1.9.1.
>
> Apache Geode is a data management platform that provides a database-like
> consistency model, reliable transaction processing and a shared-nothing
> architecture to maintain very low latency performance with high concurrency
> processing.
>
> Geode 1.9.1 improves compatibility with the Spring Data project and fixes a
> performance issue when SSL is enabled.  Users are encouraged to upgrade to
> the latest release.  For the full list of changes please review the release
> notes:
>
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.1
>
> The release artifacts can be downloaded from the project website:
> http://geode.apache.org/releases/
>
> The release documentation is available at:
> http://geode.apache.org/docs/guide/19/about_geode.html
>
> We would like to thank all the contributors that made the release possible.
> Regards,
> Owen Nichols and Kirk Lund on behalf of the Apache Geode team
>


-- 
-John
john.blum10101 (skype)

Re: [VOTE] Apache Geode 1.10.0.RC1

[Dick Cavender]

The 1.10.0 voting has been extended until Monday, September 9th at 3pm.

To all- please update your 1.10.0 vote if/when your issue(s) have been
resolved. There are still no -1 votes at this time.

On Fri, Sep 6, 2019 at 9:32 AM Nabarun Nag  wrote:

> Hi Anthony,
>
> I had faced this issue in the current develop too. One way to get around it
> is to run ./gradlew spotlessApply independently before the build.
>
> Regards
> Naba
>
>
> On Fri, Sep 6, 2019 at 8:53 AM Anthony Baker  wrote:
>
> > This seems to be a simple change to catch IllegalStateException instead
> of
> > IllegalArgumentException in build.gradle.
> >
> > But I’m also getting a ton of spotless errors like:
> >
> > > Task :geode-cq:spotlessJava FAILED
> > Step 'removeUnusedImports' found problem in
> >
> 'geode-cq/src/test/java/org/apache/geode/cache/query/internal/cq/CqServiceUnitTest.java':
> > null
> > java.lang.reflect.InvocationTargetException
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > at
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:498)
> > at
> >
> com.diffplug.spotless.java.GoogleJavaFormatStep$State.lambda$createRemoveUnusedImportsOnly$1(GoogleJavaFormatStep.java:153)
> > at
> com.diffplug.spotless.FormatterFunc.apply(FormatterFunc.java:31)
> > at
> >
> com.diffplug.spotless.FormatterStepImpl$Standard.format(FormatterStepImpl.java:78)
> > at
> > com.diffplug.spotless.FormatterStep$Strict.format(FormatterStep.java:76)
> > at com.diffplug.spotless.Formatter.compute(Formatter.java:230)
> > at com.diffplug.spotless.Formatter.isClean(Formatter.java:167)
> > at
> > com.diffplug.gradle.spotless.SpotlessTask.check(SpotlessTask.java:297)
> > at
> >
> com.diffplug.gradle.spotless.SpotlessTask.performAction(SpotlessTask.java:238)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > at
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:498)
> > at
> > org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:103)
> > at
> >
> org.gradle.api.internal.project.taskfactory.IncrementalTaskInputsTaskAction.doExecute(IncrementalTaskInputsTaskAction.java:46)
> > at
> >
> org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:41)
> > at
> >
> org.gradle.api.internal.project.taskfactory.AbstractIncrementalTaskAction.execute(AbstractIncrementalTaskAction.java:25)
> > at
> >
> org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:28)
> > at
> >
> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$5.run(ExecuteActionsTaskExecuter.java:404)
> > at
> >
> org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:402)
> > at
> >
> org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:394)
> > at
> >
> org.gradle.internal.operations.DefaultBuildOperationExecutor$1.execute(DefaultBuildOperationExecutor.java:165)
> > at
> >
> org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:250)
> > at
> >
> org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:158)
> > at
> >
> org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:92)
> > at
> >
> org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
> > at
> >
> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:393)
> > at
> >
> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:376)
> > at
> >
> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.access$200(ExecuteActionsTaskExecuter.java:80)
> > at
> >
> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$TaskExecution.execute(ExecuteActionsTaskExecuter.java:213)
> > at
> >
> org.gradle.internal.execution.steps.ExecuteStep.lambda$execute$0(ExecuteStep.java:32)
> > at java.util.Optional.map(Optional.java:215)
> > at
> >
> org.gradle.internal.execution.steps.ExecuteStep.execute(ExecuteStep.java:32)
> > at
> >
> 

Re: [VOTE] Apache Geode 1.9.1.RC3

[Ivan Godwin]

I know that 1.9.1 has already been release, but I'm working to verify the
native client, now.

Ivan

On Fri, Sep 6, 2019 at 8:42 AM Nabarun Nag  wrote:

> Can anyone confirm that the native client test failure happening in 1.10 RC
> does not occur in this candidate.
> I can test it if someone can point me to the instructions to do that.
>
>
> Regards
> Naba
>
>
> On Fri, Sep 6, 2019 at 8:38 AM Robert Houghton 
> wrote:
>
> > +1 given the pre-existence of threw class path bug, and it's fix in 1.10
> >
> > On Wed, Sep 4, 2019, 11:26 Jens Deppe  wrote:
> >
> > > No, It's fixed in 1.10.x.
> > >
> > > On Wed, Sep 4, 2019 at 10:16 AM Robert Houghton 
> > > wrote:
> > >
> > > > Hi Jens,
> > > >
> > > > Does this issue appear in 1.10.0.RC1?
> > > >
> > > > On Tue, Sep 3, 2019, 13:03 Jens Deppe  wrote:
> > > >
> > > > > TL;DR: +0
> > > > >
> > > > > When using gfsh over http, the following exception occurs:
> > > > >
> > > > > (1) Executing - connect --url=https://localhost:7070/geode-mgmt/v1
> > > > >
> > > > >
> > > >
> > >
> >
> --security-properties-file=/Users/jdeppe/workspace/gemfire-develop/open/security.properties
> > > > > <
> > > >
> > >
> >
> https://localhost:7070/geode-mgmt/v1--security-properties-file=/Users/jdeppe/workspace/gemfire-develop/open/security.properties
> > > > >
> > > > >
> > > > > Exception in thread "main" java.lang.NoClassDefFoundError:
> > > > > org/apache/geode/management/internal/web/shell/HttpOperationInvoker
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.commands.ConnectCommand.httpConnect(ConnectCommand.java:284)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.commands.ConnectCommand.connect(ConnectCommand.java:153)
> > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > > > > at java.lang.reflect.Method.invoke(Method.java:498)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:216)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.remote.CommandExecutor.callInvokeMethod(CommandExecutor.java:111)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.remote.CommandExecutor.invokeCommand(CommandExecutor.java:121)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:63)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:57)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.shell.GfshExecutionStrategy.execute(GfshExecutionStrategy.java:84)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.springframework.shell.core.AbstractShell.executeCommand(AbstractShell.java:134)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.shell.Gfsh.executeCommand(Gfsh.java:584)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.springframework.shell.core.AbstractShell.executeScriptLine(AbstractShell.java:74)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.shell.Gfsh.executeScriptLine(Gfsh.java:615)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.Launcher.parseOptions(Launcher.java:232)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.Launcher.parseCommandLine(Launcher.java:250)
> > > > > at
> > > > >
> > >
> org.apache.geode.management.internal.cli.Launcher.main(Launcher.java:135)
> > > > > Caused by: java.lang.ClassNotFoundException:
> > > > > org.apache.geode.management.internal.web.shell.HttpOperationInvoker
> > > > > at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> > > > > at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> > > > > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
> > > > > at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> > > > > ... 19 more
> > > > >
> > > > > The problem is that the geode-web.jar is not included in
> > > > > gfsh-dependencies.jar as part of the build.
> > > > >
> > > > > Since this issue appears to also exist on 1.9.0 I'm going to +0
> > > (instead
> > > > of
> > > > > -1). Others may feel differently. A workaround exists simply by
> > adding
> > > > the
> > > > > missing jar when running gfsh.
> > > > >
> > > > > --Jens
> > > > >
> > > > > On Tue, Sep 3, 2019 at 10:45 AM John Blum 
> wrote:
> > > > >
> > > > > > 1 more thing...
> > > > > >
> > > > > > I would 

Re: [DISCUSS] RFC - Move membership code to a separate gradle sub-project

[Udo Kohlmeyer]

I've reviewed and commented on the RFC.

+1 on the thought / notion of extracting modules.

I'm less convinced on the initial extraction of the geode-serialization 
module and believe some attention is to be given to this, once a 
decision to convert the serialization to a stand alone module.


--Udo

On 8/30/19 3:50 PM, Dan Smith wrote:

Hi all,

We added the following RFC to the wiki about moving Geode's membership
system to a separate gradle sub-project. Please review and comment by
9/6/2019.

https://cwiki.apache.org/confluence/x/WRB4Bw

Thanks!
-Dan

[ANNOUNCE] Apache Geode 1.9.1

[Owen Nichols]

The Apache Geode community is pleased to announce the availability of
Apache Geode 1.9.1.

Apache Geode is a data management platform that provides a database-like
consistency model, reliable transaction processing and a shared-nothing
architecture to maintain very low latency performance with high concurrency
processing.

Geode 1.9.1 improves compatibility with the Spring Data project and fixes a
performance issue when SSL is enabled.  Users are encouraged to upgrade to
the latest release.  For the full list of changes please review the release
notes:
https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.1

The release artifacts can be downloaded from the project website:
http://geode.apache.org/releases/

The release documentation is available at:
http://geode.apache.org/docs/guide/19/about_geode.html

We would like to thank all the contributors that made the release possible.
Regards,
Owen Nichols and Kirk Lund on behalf of the Apache Geode team

Re: [VOTE] Apache Geode 1.10.0.RC1

[Nabarun Nag]

Hi Anthony,

I had faced this issue in the current develop too. One way to get around it
is to run ./gradlew spotlessApply independently before the build.

Regards
Naba


On Fri, Sep 6, 2019 at 8:53 AM Anthony Baker  wrote:

> This seems to be a simple change to catch IllegalStateException instead of
> IllegalArgumentException in build.gradle.
>
> But I’m also getting a ton of spotless errors like:
>
> > Task :geode-cq:spotlessJava FAILED
> Step 'removeUnusedImports' found problem in
> 'geode-cq/src/test/java/org/apache/geode/cache/query/internal/cq/CqServiceUnitTest.java':
> null
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> com.diffplug.spotless.java.GoogleJavaFormatStep$State.lambda$createRemoveUnusedImportsOnly$1(GoogleJavaFormatStep.java:153)
> at com.diffplug.spotless.FormatterFunc.apply(FormatterFunc.java:31)
> at
> com.diffplug.spotless.FormatterStepImpl$Standard.format(FormatterStepImpl.java:78)
> at
> com.diffplug.spotless.FormatterStep$Strict.format(FormatterStep.java:76)
> at com.diffplug.spotless.Formatter.compute(Formatter.java:230)
> at com.diffplug.spotless.Formatter.isClean(Formatter.java:167)
> at
> com.diffplug.gradle.spotless.SpotlessTask.check(SpotlessTask.java:297)
> at
> com.diffplug.gradle.spotless.SpotlessTask.performAction(SpotlessTask.java:238)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:103)
> at
> org.gradle.api.internal.project.taskfactory.IncrementalTaskInputsTaskAction.doExecute(IncrementalTaskInputsTaskAction.java:46)
> at
> org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:41)
> at
> org.gradle.api.internal.project.taskfactory.AbstractIncrementalTaskAction.execute(AbstractIncrementalTaskAction.java:25)
> at
> org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:28)
> at
> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$5.run(ExecuteActionsTaskExecuter.java:404)
> at
> org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:402)
> at
> org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:394)
> at
> org.gradle.internal.operations.DefaultBuildOperationExecutor$1.execute(DefaultBuildOperationExecutor.java:165)
> at
> org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:250)
> at
> org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:158)
> at
> org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:92)
> at
> org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
> at
> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:393)
> at
> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:376)
> at
> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.access$200(ExecuteActionsTaskExecuter.java:80)
> at
> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$TaskExecution.execute(ExecuteActionsTaskExecuter.java:213)
> at
> org.gradle.internal.execution.steps.ExecuteStep.lambda$execute$0(ExecuteStep.java:32)
> at java.util.Optional.map(Optional.java:215)
> at
> org.gradle.internal.execution.steps.ExecuteStep.execute(ExecuteStep.java:32)
> at
> org.gradle.internal.execution.steps.ExecuteStep.execute(ExecuteStep.java:26)
> at
> org.gradle.internal.execution.steps.CleanupOutputsStep.execute(CleanupOutputsStep.java:58)
> at
> org.gradle.internal.execution.steps.CleanupOutputsStep.execute(CleanupOutputsStep.java:35)
> at
> org.gradle.internal.execution.steps.ResolveInputChangesStep.execute(ResolveInputChangesStep.java:48)
> at
> org.gradle.internal.execution.steps.ResolveInputChangesStep.execute(ResolveInputChangesStep.java:33)
> at
> 

Re: [VOTE] Apache Geode 1.10.0.RC1

[Anthony Baker]

This seems to be a simple change to catch IllegalStateException instead of 
IllegalArgumentException in build.gradle.

But I’m also getting a ton of spotless errors like:

> Task :geode-cq:spotlessJava FAILED
Step 'removeUnusedImports' found problem in 
'geode-cq/src/test/java/org/apache/geode/cache/query/internal/cq/CqServiceUnitTest.java':
null
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.diffplug.spotless.java.GoogleJavaFormatStep$State.lambda$createRemoveUnusedImportsOnly$1(GoogleJavaFormatStep.java:153)
at com.diffplug.spotless.FormatterFunc.apply(FormatterFunc.java:31)
at 
com.diffplug.spotless.FormatterStepImpl$Standard.format(FormatterStepImpl.java:78)
at 
com.diffplug.spotless.FormatterStep$Strict.format(FormatterStep.java:76)
at com.diffplug.spotless.Formatter.compute(Formatter.java:230)
at com.diffplug.spotless.Formatter.isClean(Formatter.java:167)
at 
com.diffplug.gradle.spotless.SpotlessTask.check(SpotlessTask.java:297)
at 
com.diffplug.gradle.spotless.SpotlessTask.performAction(SpotlessTask.java:238)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:103)
at 
org.gradle.api.internal.project.taskfactory.IncrementalTaskInputsTaskAction.doExecute(IncrementalTaskInputsTaskAction.java:46)
at 
org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:41)
at 
org.gradle.api.internal.project.taskfactory.AbstractIncrementalTaskAction.execute(AbstractIncrementalTaskAction.java:25)
at 
org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:28)
at 
org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$5.run(ExecuteActionsTaskExecuter.java:404)
at 
org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:402)
at 
org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:394)
at 
org.gradle.internal.operations.DefaultBuildOperationExecutor$1.execute(DefaultBuildOperationExecutor.java:165)
at 
org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:250)
at 
org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:158)
at 
org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:92)
at 
org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
at 
org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:393)
at 
org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:376)
at 
org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.access$200(ExecuteActionsTaskExecuter.java:80)
at 
org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$TaskExecution.execute(ExecuteActionsTaskExecuter.java:213)
at 
org.gradle.internal.execution.steps.ExecuteStep.lambda$execute$0(ExecuteStep.java:32)
at java.util.Optional.map(Optional.java:215)
at 
org.gradle.internal.execution.steps.ExecuteStep.execute(ExecuteStep.java:32)
at 
org.gradle.internal.execution.steps.ExecuteStep.execute(ExecuteStep.java:26)
at 
org.gradle.internal.execution.steps.CleanupOutputsStep.execute(CleanupOutputsStep.java:58)
at 
org.gradle.internal.execution.steps.CleanupOutputsStep.execute(CleanupOutputsStep.java:35)
at 
org.gradle.internal.execution.steps.ResolveInputChangesStep.execute(ResolveInputChangesStep.java:48)
at 
org.gradle.internal.execution.steps.ResolveInputChangesStep.execute(ResolveInputChangesStep.java:33)
at 
org.gradle.internal.execution.steps.CancelExecutionStep.execute(CancelExecutionStep.java:39)
at 
org.gradle.internal.execution.steps.TimeoutStep.executeWithoutTimeout(TimeoutStep.java:73)
at 
org.gradle.internal.execution.steps.TimeoutStep.execute(TimeoutStep.java:54)
at 

Re: [VOTE] Apache Geode 1.10.0.RC1

[Anthony Baker]

I ran into a problem while checking the release candidate.  When I try to build 
from source I get this error:

A problem occurred evaluating project ':geode-core'.
> Could not create task ':writeBuildInfo'.
   > No .git directory found!

The .buildinfo file looks correct, but the gradle scripts that use the git 
plugin aren’t catch that exception like they used to do (works on 1.9.1).

Since the source archive is the official release and I can’t build it, I”m 
voting -1.  I would change my vote if we can fix this.

Anthony


> On Sep 6, 2019, at 8:19 AM, Anthony Baker  wrote:
> 
> I think we should extend the vote in order to understand this issue better.
> 
> Anthony
> 
> 
>> On Sep 6, 2019, at 12:41 AM, Ivan Godwin  wrote:
>> 
>> Hello,
>> 
>> I don't know that this will be cause to hold anything up, but geode-native
>> has two integration tests failing when trying to perform Region::remove().
>> This is the case for all platforms supported by native client. The two
>> tests are testThinClientCallbackArg and
>> testThinClientListenerCallbackArgTest.
>> 
>> Here's the stacktrace, and I will continue investigating in the morning.
>> 
>> Region::remove: An exception (java.lang.ClassCastException:
>> java.lang.Byte cannot be cast to org.apache.geode.cache.Operation
>> 
>>  at 
>> org.apache.geode.internal.cache.tier.sockets.BaseCommand.getOperation(BaseCommand.java:1466)
>> 
>>  at 
>> org.apache.geode.internal.cache.tier.sockets.command.Destroy65.cmdExecute(Destroy65.java:114)
>> 
>>  at 
>> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:183)
>> 
>>  at 
>> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
>> 
>>  at 
>> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
>> 
>>  at 
>> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
>> 
>>  at 
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>> 
>>  at 
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>> 
>>  at 
>> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:666)
>> 
>>  at 
>> org.apache.geode.internal.logging.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:121)
>> 
>>  at java.lang.Thread.run(Thread.java:748)
>> 
>> ) happened at remote server.
>> 
>> 
>> On Thu, Sep 5, 2019 at 9:00 PM Nabarun Nag  wrote:
>> 
>>> Thank you Dan for the explanation.
>>> 
>>> Regards
>>> Naba
>>> 
>>> 
>>> On Thu, Sep 5, 2019 at 4:34 PM Dan Smith  wrote:
>>> 
 Hi Naba,
 
 This sanctioned-serializable stuff is not an issue.
 
 When you removed those files from sanctioned-geode-core-serializables,
>>> they
 get rejected by the serialization filter. Look at the error message you
>>> see
 when you remove them - it is failing to serialize a class that has a
 *nested* EvictionAttributes.
 
 Those classes need to be in the sanctioned file, if they are embedded in
 another serialized object. They are probably not showing up in the
 actualSerializables file because they are DataSerializable.
 
 -Dan
 
 On Thu, Sep 5, 2019 at 3:49 PM Kirk Lund  wrote:
 
> Ah, ok. I think I see what you're asking about. I don't have an answer,
 but
> someone else such as Bruce could explain it.
> 
> /Users/klund/dev/geode3 [610]$ diff
> 
> 
 
>>> geode-core/src/main/resources/org/apache/geode/internal/sanctioned-geode-core-serializables.txt
> geode-core/build/integrationTest/actualSerializables.dat
> 69d68
> < org/apache/geode/cache/EvictionAttributes,false
> 71d69
> < org/apache/geode/cache/ExpirationAttributes,false
> 79d76
> < org/apache/geode/cache/MembershipAttributes,false
> 99d95
> < org/apache/geode/cache/SubscriptionAttributes,false
> 262d257
> < org/apache/geode/internal/cache/EvictionAttributesImpl,false
> 276d270
> < org/apache/geode/internal/cache/PartitionAttributesImpl,false
> 517d510
> <
> 
> 
 
>>> org/apache/geode/management/internal/cli/functions/CacheRealizationFunction,false
> 
> On Thu, Sep 5, 2019 at 3:44 PM Nabarun Nag  wrote:
> 
>> Hi Kirk,
>> 
>> The test does not fail.
>> When you run the test (testSerializable) it creates a list of
> serializable
>> classes and puts it in the actualSerializables.dat file and them
 compares
>> if all the classes listed are present in the
>> sanctioned-geode-core-serializables.txt.
>> If we did not change any serializabale classes then these two files
>> remain the same. However now in this release, there are classes in
>> sanctioned-geode-core-serializables.txt which are not present in
>> 

Re: [VOTE] Apache Geode 1.9.1.RC3

[Nabarun Nag]

Can anyone confirm that the native client test failure happening in 1.10 RC
does not occur in this candidate.
I can test it if someone can point me to the instructions to do that.


Regards
Naba


On Fri, Sep 6, 2019 at 8:38 AM Robert Houghton  wrote:

> +1 given the pre-existence of threw class path bug, and it's fix in 1.10
>
> On Wed, Sep 4, 2019, 11:26 Jens Deppe  wrote:
>
> > No, It's fixed in 1.10.x.
> >
> > On Wed, Sep 4, 2019 at 10:16 AM Robert Houghton 
> > wrote:
> >
> > > Hi Jens,
> > >
> > > Does this issue appear in 1.10.0.RC1?
> > >
> > > On Tue, Sep 3, 2019, 13:03 Jens Deppe  wrote:
> > >
> > > > TL;DR: +0
> > > >
> > > > When using gfsh over http, the following exception occurs:
> > > >
> > > > (1) Executing - connect --url=https://localhost:7070/geode-mgmt/v1
> > > >
> > > >
> > >
> >
> --security-properties-file=/Users/jdeppe/workspace/gemfire-develop/open/security.properties
> > > > <
> > >
> >
> https://localhost:7070/geode-mgmt/v1--security-properties-file=/Users/jdeppe/workspace/gemfire-develop/open/security.properties
> > > >
> > > >
> > > > Exception in thread "main" java.lang.NoClassDefFoundError:
> > > > org/apache/geode/management/internal/web/shell/HttpOperationInvoker
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.commands.ConnectCommand.httpConnect(ConnectCommand.java:284)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.commands.ConnectCommand.connect(ConnectCommand.java:153)
> > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > at
> > > >
> > > >
> > >
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > > > at
> > > >
> > > >
> > >
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > > > at java.lang.reflect.Method.invoke(Method.java:498)
> > > > at
> > > >
> > > >
> > >
> >
> org.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:216)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.remote.CommandExecutor.callInvokeMethod(CommandExecutor.java:111)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.remote.CommandExecutor.invokeCommand(CommandExecutor.java:121)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:63)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:57)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.shell.GfshExecutionStrategy.execute(GfshExecutionStrategy.java:84)
> > > > at
> > > >
> > > >
> > >
> >
> org.springframework.shell.core.AbstractShell.executeCommand(AbstractShell.java:134)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.shell.Gfsh.executeCommand(Gfsh.java:584)
> > > > at
> > > >
> > > >
> > >
> >
> org.springframework.shell.core.AbstractShell.executeScriptLine(AbstractShell.java:74)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.shell.Gfsh.executeScriptLine(Gfsh.java:615)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.Launcher.parseOptions(Launcher.java:232)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.Launcher.parseCommandLine(Launcher.java:250)
> > > > at
> > > >
> > org.apache.geode.management.internal.cli.Launcher.main(Launcher.java:135)
> > > > Caused by: java.lang.ClassNotFoundException:
> > > > org.apache.geode.management.internal.web.shell.HttpOperationInvoker
> > > > at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> > > > at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> > > > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
> > > > at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> > > > ... 19 more
> > > >
> > > > The problem is that the geode-web.jar is not included in
> > > > gfsh-dependencies.jar as part of the build.
> > > >
> > > > Since this issue appears to also exist on 1.9.0 I'm going to +0
> > (instead
> > > of
> > > > -1). Others may feel differently. A workaround exists simply by
> adding
> > > the
> > > > missing jar when running gfsh.
> > > >
> > > > --Jens
> > > >
> > > > On Tue, Sep 3, 2019 at 10:45 AM John Blum  wrote:
> > > >
> > > > > 1 more thing...
> > > > >
> > > > > I would additionally advise rewording the sentence...
> > > > >
> > > > > *> Please add log4j-core to the classpath.*
> > > > >
> > > > > To read...
> > > > >
> > > > > "*Please consider adding log4j-core, or another Logging provider
> > (e.g.
> > > > > Logback), to your classpath.  Apache Geode works best with Log4j.*"
> > > > >
> > > > > Food for thought.
> > > > >
> > > > > -John
> > > > >
> > > > >
> > > > > On Tue, Sep 3, 2019 at 10:40 AM John Blum 
> wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > Ran SDG build against Apache 

Re: [VOTE] Apache Geode 1.9.1.RC3

[Robert Houghton]

+1 given the pre-existence of threw class path bug, and it's fix in 1.10

On Wed, Sep 4, 2019, 11:26 Jens Deppe  wrote:

> No, It's fixed in 1.10.x.
>
> On Wed, Sep 4, 2019 at 10:16 AM Robert Houghton 
> wrote:
>
> > Hi Jens,
> >
> > Does this issue appear in 1.10.0.RC1?
> >
> > On Tue, Sep 3, 2019, 13:03 Jens Deppe  wrote:
> >
> > > TL;DR: +0
> > >
> > > When using gfsh over http, the following exception occurs:
> > >
> > > (1) Executing - connect --url=https://localhost:7070/geode-mgmt/v1
> > >
> > >
> >
> --security-properties-file=/Users/jdeppe/workspace/gemfire-develop/open/security.properties
> > > <
> >
> https://localhost:7070/geode-mgmt/v1--security-properties-file=/Users/jdeppe/workspace/gemfire-develop/open/security.properties
> > >
> > >
> > > Exception in thread "main" java.lang.NoClassDefFoundError:
> > > org/apache/geode/management/internal/web/shell/HttpOperationInvoker
> > > at
> > >
> > >
> >
> org.apache.geode.management.internal.cli.commands.ConnectCommand.httpConnect(ConnectCommand.java:284)
> > > at
> > >
> > >
> >
> org.apache.geode.management.internal.cli.commands.ConnectCommand.connect(ConnectCommand.java:153)
> > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > at
> > >
> > >
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > > at
> > >
> > >
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > > at java.lang.reflect.Method.invoke(Method.java:498)
> > > at
> > >
> > >
> >
> org.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:216)
> > > at
> > >
> > >
> >
> org.apache.geode.management.internal.cli.remote.CommandExecutor.callInvokeMethod(CommandExecutor.java:111)
> > > at
> > >
> > >
> >
> org.apache.geode.management.internal.cli.remote.CommandExecutor.invokeCommand(CommandExecutor.java:121)
> > > at
> > >
> > >
> >
> org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:63)
> > > at
> > >
> > >
> >
> org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:57)
> > > at
> > >
> > >
> >
> org.apache.geode.management.internal.cli.shell.GfshExecutionStrategy.execute(GfshExecutionStrategy.java:84)
> > > at
> > >
> > >
> >
> org.springframework.shell.core.AbstractShell.executeCommand(AbstractShell.java:134)
> > > at
> > >
> > >
> >
> org.apache.geode.management.internal.cli.shell.Gfsh.executeCommand(Gfsh.java:584)
> > > at
> > >
> > >
> >
> org.springframework.shell.core.AbstractShell.executeScriptLine(AbstractShell.java:74)
> > > at
> > >
> > >
> >
> org.apache.geode.management.internal.cli.shell.Gfsh.executeScriptLine(Gfsh.java:615)
> > > at
> > >
> > >
> >
> org.apache.geode.management.internal.cli.Launcher.parseOptions(Launcher.java:232)
> > > at
> > >
> > >
> >
> org.apache.geode.management.internal.cli.Launcher.parseCommandLine(Launcher.java:250)
> > > at
> > >
> org.apache.geode.management.internal.cli.Launcher.main(Launcher.java:135)
> > > Caused by: java.lang.ClassNotFoundException:
> > > org.apache.geode.management.internal.web.shell.HttpOperationInvoker
> > > at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> > > at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> > > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
> > > at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> > > ... 19 more
> > >
> > > The problem is that the geode-web.jar is not included in
> > > gfsh-dependencies.jar as part of the build.
> > >
> > > Since this issue appears to also exist on 1.9.0 I'm going to +0
> (instead
> > of
> > > -1). Others may feel differently. A workaround exists simply by adding
> > the
> > > missing jar when running gfsh.
> > >
> > > --Jens
> > >
> > > On Tue, Sep 3, 2019 at 10:45 AM John Blum  wrote:
> > >
> > > > 1 more thing...
> > > >
> > > > I would additionally advise rewording the sentence...
> > > >
> > > > *> Please add log4j-core to the classpath.*
> > > >
> > > > To read...
> > > >
> > > > "*Please consider adding log4j-core, or another Logging provider
> (e.g.
> > > > Logback), to your classpath.  Apache Geode works best with Log4j.*"
> > > >
> > > > Food for thought.
> > > >
> > > > -John
> > > >
> > > >
> > > > On Tue, Sep 3, 2019 at 10:40 AM John Blum  wrote:
> > > >
> > > > > +1
> > > > >
> > > > > Ran SDG build against Apache Geode 1.9.1 build snapshots (for RC3).
> > > > >
> > > > > However, can we seriously reconsider logging the follow message at
> > > ERROR?
> > > > > Ugh!
> > > > >
> > > > > ERROR StatusLogger Log4j2 could not find a logging implementation.
> > > Please
> > > > > add log4j-core to the classpath. Using SimpleLogger to log to the
> > > > console...
> > > > >
> > > > > WARN is more than sufficient.  If no logging provider is on the
> > > > CLASSPATH,
> > > > > it creates a lot of noise!
> > > > >
> > > > > -John
> > > > >
> > > > >
> > > > > On Fri, Aug 30, 2019 at 12:27 PM Dave Barnes 
> > > wrote:
> > > > 

Re: [VOTE] Apache Geode 1.10.0.RC1

[Anthony Baker]

I think we should extend the vote in order to understand this issue better.

Anthony


> On Sep 6, 2019, at 12:41 AM, Ivan Godwin  wrote:
> 
> Hello,
> 
> I don't know that this will be cause to hold anything up, but geode-native
> has two integration tests failing when trying to perform Region::remove().
> This is the case for all platforms supported by native client. The two
> tests are testThinClientCallbackArg and
> testThinClientListenerCallbackArgTest.
> 
> Here's the stacktrace, and I will continue investigating in the morning.
> 
> Region::remove: An exception (java.lang.ClassCastException:
> java.lang.Byte cannot be cast to org.apache.geode.cache.Operation
> 
>   at 
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.getOperation(BaseCommand.java:1466)
> 
>   at 
> org.apache.geode.internal.cache.tier.sockets.command.Destroy65.cmdExecute(Destroy65.java:114)
> 
>   at 
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:183)
> 
>   at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> 
>   at 
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> 
>   at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> 
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 
>   at 
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:666)
> 
>   at 
> org.apache.geode.internal.logging.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:121)
> 
>   at java.lang.Thread.run(Thread.java:748)
> 
> ) happened at remote server.
> 
> 
> On Thu, Sep 5, 2019 at 9:00 PM Nabarun Nag  wrote:
> 
>> Thank you Dan for the explanation.
>> 
>> Regards
>> Naba
>> 
>> 
>> On Thu, Sep 5, 2019 at 4:34 PM Dan Smith  wrote:
>> 
>>> Hi Naba,
>>> 
>>> This sanctioned-serializable stuff is not an issue.
>>> 
>>> When you removed those files from sanctioned-geode-core-serializables,
>> they
>>> get rejected by the serialization filter. Look at the error message you
>> see
>>> when you remove them - it is failing to serialize a class that has a
>>> *nested* EvictionAttributes.
>>> 
>>> Those classes need to be in the sanctioned file, if they are embedded in
>>> another serialized object. They are probably not showing up in the
>>> actualSerializables file because they are DataSerializable.
>>> 
>>> -Dan
>>> 
>>> On Thu, Sep 5, 2019 at 3:49 PM Kirk Lund  wrote:
>>> 
 Ah, ok. I think I see what you're asking about. I don't have an answer,
>>> but
 someone else such as Bruce could explain it.
 
 /Users/klund/dev/geode3 [610]$ diff
 
 
>>> 
>> geode-core/src/main/resources/org/apache/geode/internal/sanctioned-geode-core-serializables.txt
 geode-core/build/integrationTest/actualSerializables.dat
 69d68
 < org/apache/geode/cache/EvictionAttributes,false
 71d69
 < org/apache/geode/cache/ExpirationAttributes,false
 79d76
 < org/apache/geode/cache/MembershipAttributes,false
 99d95
 < org/apache/geode/cache/SubscriptionAttributes,false
 262d257
 < org/apache/geode/internal/cache/EvictionAttributesImpl,false
 276d270
 < org/apache/geode/internal/cache/PartitionAttributesImpl,false
 517d510
 <
 
 
>>> 
>> org/apache/geode/management/internal/cli/functions/CacheRealizationFunction,false
 
 On Thu, Sep 5, 2019 at 3:44 PM Nabarun Nag  wrote:
 
> Hi Kirk,
> 
> The test does not fail.
> When you run the test (testSerializable) it creates a list of
 serializable
> classes and puts it in the actualSerializables.dat file and them
>>> compares
> if all the classes listed are present in the
> sanctioned-geode-core-serializables.txt.
> If we did not change any serializabale classes then these two files
> remain the same. However now in this release, there are classes in
> sanctioned-geode-core-serializables.txt which are not present in
> actualSerializables.dat.
> 
> I wanted to know why are those classes are not listed in
> actualSerializables.dat
> and if you remove them from sanctioned-geode-core-serializables.txt
> testSerializables passes but
>> testSanctionedClassesExistAndDoDeserialize
> fails.
> 
> Regards
> Naba
> 
> 
> On Thu, Sep 5, 2019 at 3:21 PM Kirk Lund  wrote:
> 
>> Hi Naba,
>> 
>> I failed to reproduce the problem you reported on Mac OS, and our
> pipeline
>> didn't fail this test. What OS are you running integrationTest on?
 Here's
>> the steps I followed:
>> 
>> 1) checkout tag rel/v1.10.0.RC1
>> 
>> $ git checkout tags/rel/v1.10.0.RC1

Passed: apache/geode-site#131 (master - 1a08528)

[Travis CI]

Build Update for apache/geode-site
-

Build: #131
Status: Passed

Duration: 1 min and 0 secs
Commit: 1a08528 (master)
Author: Dave Barnes
Message: Use openjdk for travis checks

View the changeset: 
https://github.com/apache/geode-site/compare/361ff4405105...1a08528e8445

View the full build log and details: 
https://travis-ci.org/apache/geode-site/builds/581716451?utm_medium=notification_source=email

--

You can unsubscribe from build emails from the apache/geode-site repository 
going to 
https://travis-ci.org/account/preferences/unsubscribe?repository=12216150_medium=notification_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.

Re: [DISCUSS] RFC - Move membership code to a separate gradle sub-project

[Joris Melchior]

+1

On Thu, Sep 5, 2019 at 2:57 PM Darrel Schneider 
wrote:

> +1 I added some comments on the wiki
>
> On Thu, Sep 5, 2019 at 9:34 AM Kirk Lund  wrote:
>
> > *interfaces -> was supposed to be "implementations"
> >
> > On Thu, Sep 5, 2019 at 9:33 AM Kirk Lund  wrote:
> >
> > > +1 The planned subprojects look good. Thanks for clarifying the
> > > goals/anti-goals in the RPC, especially the anti-goal to not make it
> > > pluggable with different interfaces.
> > >
> > > On Thu, Sep 5, 2019 at 8:52 AM Aaron Lindsey 
> > wrote:
> > >
> > >> +1 — I'm happy to see us move toward better testability for the
> > membership
> > >> code!
> > >>
> > >> I also left my "+1" on the wiki page comments. I noticed that the
> > >> "Lightweight RFC Process" document states that we're supposed to have
> > >> discussions on the [DISCUSS] thread:
> > >>
> > >> In addition a [DISCUSS] email should be send to the dev mailing list.
> > >> > Discussion will take place in the email thread.
> > >> >
> > >>
> > >> Can we clarify how to have discussions on proposals? Personally, I
> don't
> > >> care either way as long as it's clear how the process is supposed to
> > work.
> > >>
> > >> - Aaron
> > >>
> > >>
> > >> On Wed, Sep 4, 2019 at 4:04 PM Bruce Schuchardt <
> bschucha...@pivotal.io
> > >
> > >> wrote:
> > >>
> > >> > Thanks to folks who put in review comments today.  We're shooting
> for
> > >> > closing this RFC this week.
> > >> >
> > >> >
> > >> > On 8/30/19 3:50 PM, Dan Smith wrote:
> > >> > > Hi all,
> > >> > >
> > >> > > We added the following RFC to the wiki about moving Geode's
> > membership
> > >> > > system to a separate gradle sub-project. Please review and comment
> > by
> > >> > > 9/6/2019.
> > >> > >
> > >> > > https://cwiki.apache.org/confluence/x/WRB4Bw
> > >> > >
> > >> > > Thanks!
> > >> > > -Dan
> > >> > >
> > >> >
> > >>
> > >
> >
>


-- 
*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] Apache Geode 1.10.0.RC1

[Ivan Godwin]

Hello,

I don't know that this will be cause to hold anything up, but geode-native
has two integration tests failing when trying to perform Region::remove().
This is the case for all platforms supported by native client. The two
tests are testThinClientCallbackArg and
testThinClientListenerCallbackArgTest.

Here's the stacktrace, and I will continue investigating in the morning.

Region::remove: An exception (java.lang.ClassCastException:
java.lang.Byte cannot be cast to org.apache.geode.cache.Operation

at 
org.apache.geode.internal.cache.tier.sockets.BaseCommand.getOperation(BaseCommand.java:1466)

at 
org.apache.geode.internal.cache.tier.sockets.command.Destroy65.cmdExecute(Destroy65.java:114)

at 
org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:183)

at 
org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)

at 
org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)

at 
org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)

at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)

at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)

at 
org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:666)

at 
org.apache.geode.internal.logging.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:121)

at java.lang.Thread.run(Thread.java:748)

) happened at remote server.


On Thu, Sep 5, 2019 at 9:00 PM Nabarun Nag  wrote:

> Thank you Dan for the explanation.
>
> Regards
> Naba
>
>
> On Thu, Sep 5, 2019 at 4:34 PM Dan Smith  wrote:
>
> > Hi Naba,
> >
> > This sanctioned-serializable stuff is not an issue.
> >
> > When you removed those files from sanctioned-geode-core-serializables,
> they
> > get rejected by the serialization filter. Look at the error message you
> see
> > when you remove them - it is failing to serialize a class that has a
> > *nested* EvictionAttributes.
> >
> > Those classes need to be in the sanctioned file, if they are embedded in
> > another serialized object. They are probably not showing up in the
> > actualSerializables file because they are DataSerializable.
> >
> > -Dan
> >
> > On Thu, Sep 5, 2019 at 3:49 PM Kirk Lund  wrote:
> >
> > > Ah, ok. I think I see what you're asking about. I don't have an answer,
> > but
> > > someone else such as Bruce could explain it.
> > >
> > > /Users/klund/dev/geode3 [610]$ diff
> > >
> > >
> >
> geode-core/src/main/resources/org/apache/geode/internal/sanctioned-geode-core-serializables.txt
> > > geode-core/build/integrationTest/actualSerializables.dat
> > > 69d68
> > > < org/apache/geode/cache/EvictionAttributes,false
> > > 71d69
> > > < org/apache/geode/cache/ExpirationAttributes,false
> > > 79d76
> > > < org/apache/geode/cache/MembershipAttributes,false
> > > 99d95
> > > < org/apache/geode/cache/SubscriptionAttributes,false
> > > 262d257
> > > < org/apache/geode/internal/cache/EvictionAttributesImpl,false
> > > 276d270
> > > < org/apache/geode/internal/cache/PartitionAttributesImpl,false
> > > 517d510
> > > <
> > >
> > >
> >
> org/apache/geode/management/internal/cli/functions/CacheRealizationFunction,false
> > >
> > > On Thu, Sep 5, 2019 at 3:44 PM Nabarun Nag  wrote:
> > >
> > > > Hi Kirk,
> > > >
> > > > The test does not fail.
> > > > When you run the test (testSerializable) it creates a list of
> > > serializable
> > > > classes and puts it in the actualSerializables.dat file and them
> > compares
> > > > if all the classes listed are present in the
> > > > sanctioned-geode-core-serializables.txt.
> > > > If we did not change any serializabale classes then these two files
> > > > remain the same. However now in this release, there are classes in
> > > > sanctioned-geode-core-serializables.txt which are not present in
> > > > actualSerializables.dat.
> > > >
> > > > I wanted to know why are those classes are not listed in
> > > > actualSerializables.dat
> > > > and if you remove them from sanctioned-geode-core-serializables.txt
> > > > testSerializables passes but
> testSanctionedClassesExistAndDoDeserialize
> > > > fails.
> > > >
> > > > Regards
> > > > Naba
> > > >
> > > >
> > > > On Thu, Sep 5, 2019 at 3:21 PM Kirk Lund  wrote:
> > > >
> > > > > Hi Naba,
> > > > >
> > > > > I failed to reproduce the problem you reported on Mac OS, and our
> > > > pipeline
> > > > > didn't fail this test. What OS are you running integrationTest on?
> > > Here's
> > > > > the steps I followed:
> > > > >
> > > > > 1) checkout tag rel/v1.10.0.RC1
> > > > >
> > > > > $ git checkout tags/rel/v1.10.0.RC1
> > > > >
> > > > > 2) clean, then build with unit tests
> > > > >
> > > > > $ ./gradlew clean
> > > > > $ ./gradlew build
> > > > >
> > > > > 3) run