Jenkins build is back to normal : Geode-release #86

[Apache Jenkins Server]

See 

RE: [DISCUSS] Bug while parsing the JSON "key which having short data type" in locate command "https://github.com/apache/geode/pull/752"

[Dinesh Akhand]

Hi Team,

Please reply over below mail chain.

Need you focus on the issue.

Thanks,
Dinesh Akhand

-Original Message-
From: Dinesh Akhand 
Sent: Thursday, August 31, 2017 7:04 PM
To: dev@geode.apache.org
Subject: [DISCUSS] Bug while parsing the JSON "key which having short data 
type" in locate command "https://github.com/apache/geode/pull/752";

Hi,



I have created the pull request for the same .

https://github.com/apache/geode/pull/752



Jira ticket GEODE-3544.



Case 1)



Short data type is getting converted into integer &  geode is looking for set 
method  with integer

And it throws the exception.



So I am converting the value with parameterType  using ConvertUtils.convert 
which solve the problem for all primitive/wrapper type

Example 2)

 If key data type in short i =5

  It will look for method  seti(integer )

Case 2) If key having the base class it check only key class set method .



So I change getDeclaredMethods to getMethods()





Thanks,

Dinesh Akhand



-Original Message-
From: Dinesh Akhand
Sent: Monday, August 28, 2017 5:46 PM
To: dev@geode.apache.org
Subject: Bug while parsing the JSON "key which having short data type" in 
locate command



Hi Team,



I have found one bug in geode 1.2 .



If in the key we having the short data type



Example:



public class EmpData  implements Serializable{ private short empid;



public short getEmpid() {

   return empid;

}



public void setEmpid(short empid) {

   this.empid = empid;

}





EmpData d1 = new EmpData();

D1. setEmpid((short)1);



Region.put(d1,"value1");



Now try locate command on this .





Problem in code: file JSONTokener.java. it always return short to int value



try {

long longValue = Long.parseLong(number, base);

if(longValue <= Short.MAX_VALUE && longValue >= Short.MIN_VALUE)

{

 return (short) longValue;

}

else if (longValue <= Integer.MAX_VALUE && longValue >= 
Integer.MIN_VALUE) {

  return (int) longValue;

} else {

  return longValue;

}



Later it cause the problem of java.lang.IllegalArgumentException: argument type 
mismatch.

locate entry --key=--key=('empid ':1) --region=CUSTOMER_1



alternate way :  changes the  DataCommandFunctionJUnitTest.java changes the 
testLocateKeyIsObject method



due to same problem, we are facing problem with all commands where we usage the 
key.



Thanks,

Dinesh Akhand





This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,



you may review at https://www.amdocs.com/about/email-disclaimer 

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 

Re: Review Request 62022: GEODE-3549: fix the constantly failing flaky tests

[Jinmei Liao]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/62022/
---

(Updated Sept. 1, 2017, 3:39 a.m.)


Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
Patrick Rhomberg.


Repository: geode


Description
---

GEODE-3549: fix the constantly failing flaky tests


Diffs
-

  
geode-core/src/main/java/org/apache/geode/management/internal/cli/GfshParseResult.java
 e91e3657e28bdbba2016eb5b6a84dfa434af85e9 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExecuteFunctionCommand.java
 46ad6e5e2eb31cc2cfdb8b48c7d514efceb865ae 
  
geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/DataCommandsController.java
 8a16aa4a76cc98d4911b90b79527970bfaaf3510 
  
geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/FunctionCommandsController.java
 da3fc65db0b5098890237ac4bdcd35b15b929398 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/GfshParserParsingTest.java
 961cdf87f883957532a1d1abded8320df96edb3d 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/GemfireDataCommandsDUnitTest.java
 0247c79badef9d9929f3dd5ba1cc88d90d23c7c7 


Diff: https://reviews.apache.org/r/62022/diff/1/


Testing (updated)
---

precheckin successful


Thanks,

Jinmei Liao

Build failed in Jenkins: Geode-nightly-flaky #108

[Apache Jenkins Server]

See 


Changes:

[jstewart] GEODE-3525: Dockerize AcceptanceTests

--
[...truncated 111.60 KB...]
:geode-lucene:javadocJar
:geode-lucene:sourcesJar
:geode-lucene:signArchives SKIPPED
:geode-old-client-support:jar
:geode-old-client-support:javadoc
:geode-old-client-support:javadocJar
:geode-old-client-support:sourcesJar
:geode-old-client-support:signArchives SKIPPED
:geode-protobuf:jar
:geode-protobuf:javadoc
:geode-protobuf:javadocJar
:geode-protobuf:sourcesJar
:geode-protobuf:signArchives SKIPPED
:geode-pulse:javadoc
:geode-pulse:javadocJar
:geode-pulse:sourcesJar
:geode-pulse:war
:geode-pulse:signArchives SKIPPED
:geode-rebalancer:jar
:geode-rebalancer:javadoc
:geode-rebalancer:javadocJar
:geode-rebalancer:sourcesJar
:geode-rebalancer:signArchives SKIPPED
:geode-wan:jar
:geode-wan:javadoc
:geode-wan:javadocJar
:geode-wan:sourcesJar
:geode-wan:signArchives SKIPPED
:geode-web:javadoc NO-SOURCE
:geode-web:javadocJar
:geode-web:sourcesJar
:geode-web:war
:geode-web:signArchives SKIPPED
:geode-web-api:javadoc
:geode-web-api:javadocJar
:geode-web-api:sourcesJar
:geode-web-api:war
:geode-web-api:signArchives SKIPPED
:geode-assembly:installDist
:geode-pulse:jar
:geode-assembly:compileTestJava
Download 
https://repo1.maven.org/maven2/org/codehaus/cargo/cargo-core-uberjar/1.6.3/cargo-core-uberjar-1.6.3.pom
Download 
https://repo1.maven.org/maven2/org/codehaus/cargo/cargo-core/1.6.3/cargo-core-1.6.3.pom
Download 
https://repo1.maven.org/maven2/org/codehaus/cargo/codehaus-cargo/1.6.3/codehaus-cargo-1.6.3.pom
Download 
https://repo1.maven.org/maven2/org/codehaus/cargo/cargo-core-uberjar/1.6.3/cargo-core-uberjar-1.6.3.jar
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
:geode-assembly:processTestResources
:geode-assembly:testClasses
:geode-assembly:flakyTest
:geode-benchmarks:compileTestJava NO-SOURCE
:geode-benchmarks:processTestResources NO-SOURCE
:geode-benchmarks:testClasses UP-TO-DATE
:geode-benchmarks:flakyTest NO-SOURCE
:geode-common:compileTestJava
:geode-common:processTestResources NO-SOURCE
:geode-common:testClasses
:geode-common:flakyTest
:geode-core:flakyTest

org.apache.geode.management.RegionManagementDUnitTest > testNavigationAPIS 
FAILED
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.test.dunit.NamedRunnable.run in VM 0 running on Host 
asf914.gq1.ygridcore.net with 4 VMs
at org.apache.geode.test.dunit.VM.invoke(VM.java:387)
at org.apache.geode.test.dunit.VM.invoke(VM.java:357)
at org.apache.geode.test.dunit.VM.invoke(VM.java:290)
at 
org.apache.geode.management.RegionManagementDUnitTest.verifyNavigationApis(RegionManagementDUnitTest.java:422)
at 
org.apache.geode.management.RegionManagementDUnitTest.testNavigationAPIS(RegionManagementDUnitTest.java:285)

Caused by:
org.awaitility.core.ConditionTimeoutException: Condition defined as a 
lambda expression in org.apache.geode.management.RegionManagementDUnitTest that 
uses org.apache.geode.management.DistributedSystemMXBean, 
org.apache.geode.management.DistributedSystemMXBeanint expected:<[4]> but 
was:<[5]> within 2 minutes.
at 
org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:104)
at 
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:117)
at 
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
at 
org.awaitility.core.ConditionFactory.until(ConditionFactory.java:809)
at 
org.awaitility.core.ConditionFactory.until(ConditionFactory.java:648)
at 
org.apache.geode.management.RegionManagementDUnitTest.awaitMemberCount(RegionManagementDUnitTest.java:1065)
at 
org.apache.geode.management.RegionManagementDUnitTest.lambda$verifyNavigationApis$8ec4a763$1(RegionManagementDUnitTest.java:426)

339 tests completed, 1 failed, 9 skipped
:geode-core:flakyTest FAILED
:geode-cq:compileTestJavaNote: Some input files use or override a deprecated 
API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-cq:processTestResources
:geode-cq:testClasses
:geode-cq:flakyTest
:geode-json:compileTestJava NO-SOURCE
:geode-json:processTestResources
:geode-json:testClasses
:geode-json:flakyTest NO-SOURCE
:geode-junit:compileTestJavaNote: 

 uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: 

[GitHub] geode pull request #754: GEODE-3550: Improve snapshot filter testing

[nreich]

GitHub user nreich opened a pull request:

https://github.com/apache/geode/pull/754

GEODE-3550: Improve snapshot filter testing

Make more explicit testing that filters work on both imports and exports 
and improve test speed by decreasing data size used.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/nreich/geode feature/GEODE-3550

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/754.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #754


commit 9451d2117005802ebacf2b0dfd0bdf401a607cd3
Author: Nick Reich 
Date:   2017-08-31T23:29:23Z

GEODE-3550: Improve snapshot filter testing




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: DISCUSS : Monitor the neighbour JVM using neihbour's member-timeout (GEODE-3411)

[Brian Baynes]

Hi, Aravind.

Can you help me understand why this might be a useful feature for Geode?  I
see that your needs require it, but why would users in general want to
allow longer timeouts for some members?  This is a significant change with
backward-compatibility implications, so would be good for the community to
understand the potential benefit.

Thanks!
Brian

On Mon, Aug 28, 2017 at 12:20 AM, Aravind Musigumpula <
aravind.musigump...@amdocs.com> wrote:

> Hi Team,
>
> We have a requirement to configure  different member timeout for different
> members as we need some members to survive in the view for longer time than
> the other the members before being kicked out of the view in case they
> aren't responding.
>
>
> 1.   Now with the current monitoring system it is not possible to
> determine when the member will be kicked out of the view if we configure
> different member-timeout's for some required members.
>
> 2.   Because if a member is not responding to any heartbeat requests,
> the member who is monitoring the non-responding member will initiate check
> member request.
>
> 3.   In this check member request monitoring member pings the
> non-responding member and waits for member-timeout of monitoring member for
> a response.
>
> 4.   If still there is no response, it will initiate a final suspect
> request to coordinator where the coordinator does the final check waiting
> for coordinators member-timeout.
>
> 5.   If coordinator did not get any response, it will remove the
> non-responding member from the view and publishes it.
>
> 6.   So, Here the time period for removing a member depends on its
> monitoring member's and coordinator's timeout. But the monitoring member
> depends on the view but it may change from time to time.
>
> So, now when a monitoring-member doing the check on a member, if we wait
> for the non-responding member's timeout instead of the monitoring
> member-timeout, then the time when the non-responding member will be
> removed from the view depends on its own member-timeout and the
> coordinators member-timeout.
> Hence we can configure different member-timeout for the required members.
>
> I created a pull request based on the above scenario:
> https://github.com/apache/geode/pull/717
>
> Is the above approach correct? Do we have any concerns around this area?
> Please give your insights on this issue.
>
> Thanks,
> Aravind Musigumpula
>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
>
> you may review at https://www.amdocs.com/about/email-disclaimer <
> https://www.amdocs.com/about/email-disclaimer>
>

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

[Jacob Barrett]

None of the time spent performing the request is deterministic that’s why there 
are timeouts. I don’t follow your rational for claiming it complicated to code.

> On Aug 31, 2017, at 3:27 PM, Mark Hanson  wrote:
> 
> The only problem with that is the time to connect to another server is 
> non-deterministic. So,  the code one would have to write to enable this would 
> involve a select and a bit of not fun code, but in general could be not very 
> useful as an API.
> 
> I would say the lowest common denominator approach or the server based 
> approach is better.
> 
> Just two cents.
> 
> Thanks,
> Mark
>> On Aug 31, 2017, at 1:41 PM, Jacob Barrett  wrote:
>> 
>> I believe what Bruce was saying is that the behavior should be covered by
>> timeouts not iteration attempts. If the client is able to successfully send
>> the command to a server but a failure occurs waiting for a reply we would
>> not retry. If the client is unable to send the request to a sever because
>> the connection closes then we would try the next server, and the next, up
>> to the timeout value.
>> 
>>> On Thu, Aug 31, 2017 at 1:31 PM Mark Hanson  wrote:
>>> 
>>> I can also see why the user doing the retries themselves has value. As a
>>> lowest common denominator approach, pulling the API is sound.
>>> 
 On Thu, Aug 31, 2017 at 1:26 PM, Mark Hanson  wrote:
 
 I think the setRetryAttempts really harks back to the case that Bruce was
 alluding to in which the server goes down. Which is the one valid case
>>> for
 this kind of API in theory. Are we say that in that case we don't retry?
 Seems like we are making the API a little less nice for people.
 As a developer using an API, I want to do as little as possible and get
 the most robust solution possible. This seems to go the wrong direction
>>> of
 that kind of intent in a way. I want the client to automatically try
>>> every
 server. I don't ever want to configure the value. I could limit with this
 API and force it to never retry or I could cause it to retry more times
 than I care for it to.  If we are going to get rid of this API in
 particular, I would favor having it automatically try some number of
 servers or all, but not retrying at all would not be my choice.
 
 On Thu, Aug 31, 2017 at 1:08 PM, Jacob Barrett 
 wrote:
 
>> On Thu, Aug 31, 2017 at 1:00 PM Mark Hanson  wrote:
>> 
>> I would have to go looking, but the key concept is that this is a
>>> bigger
>> problem.
>> 
>> interval such as the time between retries
>> wait as in how long to wait for a response...
>> 
> 
> All time intervals should be expressed in terms of std::chrono::duration
> values. A value of std::chrono::duration::zero means don't wait. I would
> suggest that a negative time not be allowed and that some very large,
> MAXINT, value could take the place of "forever". There is a ticket
>>> already
> open and in progress to replace all time based values with std::chrono.
> 
> 
>> retry as how many times to retry after a failure
>> attempts as in how many times to do a thing before giving up
>> Set of objects as in the setRetryAttempts code which , will try a
> number of
>> servers before giving up. where n is the number, -1 equals all, and 0
> means
>> (1 server, no retries).
>> 
> 
> If there are other examples of "iteration" then we should consider them
> based on what they iterate. I think the consensus on setRetryAttempts is
> to
> abolish it.
> 
> -Jake
> 
 
 
>>> 
> 

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #664 was SUCCESSFUL (with 2027 tests)

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #664 was successful.
---
Scheduled
2029 tests in total.

https://build.spring.io/browse/SGF-NAG-664/





--
This message is automatically generated by Atlassian Bamboo

Re: Review Request 62022: GEODE-3549: fix the constantly failing flaky tests

[Jared Stewart]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/62022/#review184320
---


Ship it!




Ship It!

- Jared Stewart


On Aug. 31, 2017, 9:22 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62022/
> ---
> 
> (Updated Aug. 31, 2017, 9:22 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-3549: fix the constantly failing flaky tests
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/GfshParseResult.java
>  e91e3657e28bdbba2016eb5b6a84dfa434af85e9 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExecuteFunctionCommand.java
>  46ad6e5e2eb31cc2cfdb8b48c7d514efceb865ae 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/DataCommandsController.java
>  8a16aa4a76cc98d4911b90b79527970bfaaf3510 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/FunctionCommandsController.java
>  da3fc65db0b5098890237ac4bdcd35b15b929398 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/GfshParserParsingTest.java
>  961cdf87f883957532a1d1abded8320df96edb3d 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/GemfireDataCommandsDUnitTest.java
>  0247c79badef9d9929f3dd5ba1cc88d90d23c7c7 
> 
> 
> Diff: https://reviews.apache.org/r/62022/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin running
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

[Mark Hanson]

The only problem with that is the time to connect to another server is 
non-deterministic. So,  the code one would have to write to enable this would 
involve a select and a bit of not fun code, but in general could be not very 
useful as an API.

I would say the lowest common denominator approach or the server based approach 
is better.

Just two cents.

Thanks,
Mark
> On Aug 31, 2017, at 1:41 PM, Jacob Barrett  wrote:
> 
> I believe what Bruce was saying is that the behavior should be covered by
> timeouts not iteration attempts. If the client is able to successfully send
> the command to a server but a failure occurs waiting for a reply we would
> not retry. If the client is unable to send the request to a sever because
> the connection closes then we would try the next server, and the next, up
> to the timeout value.
> 
> On Thu, Aug 31, 2017 at 1:31 PM Mark Hanson  wrote:
> 
>> I can also see why the user doing the retries themselves has value. As a
>> lowest common denominator approach, pulling the API is sound.
>> 
>> On Thu, Aug 31, 2017 at 1:26 PM, Mark Hanson  wrote:
>> 
>>> I think the setRetryAttempts really harks back to the case that Bruce was
>>> alluding to in which the server goes down. Which is the one valid case
>> for
>>> this kind of API in theory. Are we say that in that case we don't retry?
>>> Seems like we are making the API a little less nice for people.
>>> As a developer using an API, I want to do as little as possible and get
>>> the most robust solution possible. This seems to go the wrong direction
>> of
>>> that kind of intent in a way. I want the client to automatically try
>> every
>>> server. I don't ever want to configure the value. I could limit with this
>>> API and force it to never retry or I could cause it to retry more times
>>> than I care for it to.  If we are going to get rid of this API in
>>> particular, I would favor having it automatically try some number of
>>> servers or all, but not retrying at all would not be my choice.
>>> 
>>> On Thu, Aug 31, 2017 at 1:08 PM, Jacob Barrett 
>>> wrote:
>>> 
 On Thu, Aug 31, 2017 at 1:00 PM Mark Hanson  wrote:
 
> I would have to go looking, but the key concept is that this is a
>> bigger
> problem.
> 
> interval such as the time between retries
> wait as in how long to wait for a response...
> 
 
 All time intervals should be expressed in terms of std::chrono::duration
 values. A value of std::chrono::duration::zero means don't wait. I would
 suggest that a negative time not be allowed and that some very large,
 MAXINT, value could take the place of "forever". There is a ticket
>> already
 open and in progress to replace all time based values with std::chrono.
 
 
> retry as how many times to retry after a failure
> attempts as in how many times to do a thing before giving up
> Set of objects as in the setRetryAttempts code which , will try a
 number of
> servers before giving up. where n is the number, -1 equals all, and 0
 means
> (1 server, no retries).
> 
 
 If there are other examples of "iteration" then we should consider them
 based on what they iterate. I think the consensus on setRetryAttempts is
 to
 abolish it.
 
 -Jake
 
>>> 
>>> 
>> 

Build failed in Jenkins: Geode-nightly #940

[Apache Jenkins Server]

See 


Changes:

[jiliao] GEODE-3472: Remove a great deal of commented-out code.

[jstewart] GEODE-2859: Fix race condition in ShowDeadlockDUnitTest

[jiliao] GEODE-3539: add test for invalid command

[bschuchardt] GEODE-3249 Validate internal client/server messages

[kmiller] GEODE-3330 Document modified CQ authorization permissions

[kmiller] GEODE-3330 Correct doc of CQ authorization permissions

--
[...truncated 226.09 KB...]
---
* What went wrong:
Execution failed for task ':geode-assembly:integrationTest'.
> There were failing tests. See the report at: 
> file://

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output.
==

4: Task failed with an exception.
---
* What went wrong:
Execution failed for task ':geode-core:distributedTest'.
> There were failing tests. See the report at: 
> file://

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output.
==

5: Task failed with an exception.
---
* Where:
Script ' 
line: 116

* What went wrong:
Execution failed for task ':extensions/geode-modules-assembly:uploadArchives'.
> Could not find which method repositories() to invoke from this list:
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(groovy.lang.Closure)
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(org.gradle.api.Action)

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output.
==

6: Task failed with an exception.
---
* Where:
Script ' 
line: 116

* What went wrong:
Execution failed for task ':geode-common:uploadArchives'.
> Could not find which method repositories() to invoke from this list:
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(groovy.lang.Closure)
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(org.gradle.api.Action)

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output.
==

7: Task failed with an exception.
---
* Where:
Script ' 
line: 116

* What went wrong:
Execution failed for task ':geode-core:uploadArchives'.
> Could not find which method repositories() to invoke from this list:
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(groovy.lang.Closure)
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(org.gradle.api.Action)

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output.
==

8: Task failed with an exception.
---
* Where:
Script ' 
line: 116

* What went wrong:
Execution failed for task ':geode-cq:uploadArchives'.
> Could not find which method repositories() to invoke from this list:
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(groovy.lang.Closure)
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(org.gradle.api.Action)

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output.
==

9: Task failed with an exception.
---
* Where:
Script ' 
line: 116

* What went wrong:
Execution failed for task ':geode-json:uploadArchives'.
> Could not find which method repositories() to invoke from this list:
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(groovy.lang.Closure)
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(org.gradle.api.Action)

* T

[GitHub] geode issue #753: GEODE-3283: Expose parallel import and export in gfsh

[nreich]

Github user nreich commented on the issue:

https://github.com/apache/geode/pull/753
  
@jinmeiliao Region is still required, so this would still not work (there 
is a test in my commit that confirms this):
gfsh> export data --member=abc --dir=xxx

Your observation about --dir being able to implicitly mean --parallel is 
correct. When I opened this up to the community to discuss, my read of the 
conversation was that since non-parallel export/import can work with a 
directory, it would be better to have it available to both. In addition, while 
we have not added the ability yet to export all regions at once, that is 
possible to do and could be added as a feature and would require a directory to 
be provided instead of a file, for both parallel and non-parallel export. How 
to implement the options was definitely an area of mixed opinions on multiple 
options, so still an area worth discussing to make sure we get to the best 
solution.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode issue #753: GEODE-3283: Expose parallel import and export in gfsh

[jinmeiliao]

Github user jinmeiliao commented on the issue:

https://github.com/apache/geode/pull/753
  
I would like to get a better understanding of the new feature first. So 
before the "export data" is export data of a specific region on a specific 
member to a file. All three options are mandatory. Now it seems I can export 
data of all regions on a specific member, so I should be able to do this:
gfsh> export data --member=abc --dir=xxx

Would the existence of --dir option implicitly mean "--parallel" already? 
do we need --parallel at all?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Review Request 62021: GEODE-3547: Simplify behavior for non-writable deploy directory

[Jinmei Liao]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/62021/#review184316
---


Ship it!




Ship It!

- Jinmei Liao


On Aug. 31, 2017, 9:13 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62021/
> ---
> 
> (Updated Aug. 31, 2017, 9:13 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, Kirk Lund, 
> and Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-3547: Simplify behavior for non-writable deploy directory
>  - Also fixes the flaky JarDeployerIntegrationTest
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/internal/JarDeployer.java 
> c21fb9dd1ad1ff5f64a6bee447905c8636d93c83 
>   
> geode-core/src/test/java/org/apache/geode/internal/JarDeployerIntegrationTest.java
>  b81e3e9d095b03fc24287808e9df06c46900fa81 
> 
> 
> Diff: https://reviews.apache.org/r/62021/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin running
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

Review Request 62022: GEODE-3549: fix the constantly failing flaky tests

[Jinmei Liao]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/62022/
---

Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
Patrick Rhomberg.


Repository: geode


Description
---

GEODE-3549: fix the constantly failing flaky tests


Diffs
-

  
geode-core/src/main/java/org/apache/geode/management/internal/cli/GfshParseResult.java
 e91e3657e28bdbba2016eb5b6a84dfa434af85e9 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExecuteFunctionCommand.java
 46ad6e5e2eb31cc2cfdb8b48c7d514efceb865ae 
  
geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/DataCommandsController.java
 8a16aa4a76cc98d4911b90b79527970bfaaf3510 
  
geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/FunctionCommandsController.java
 da3fc65db0b5098890237ac4bdcd35b15b929398 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/GfshParserParsingTest.java
 961cdf87f883957532a1d1abded8320df96edb3d 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/GemfireDataCommandsDUnitTest.java
 0247c79badef9d9929f3dd5ba1cc88d90d23c7c7 


Diff: https://reviews.apache.org/r/62022/diff/1/


Testing
---

precheckin running


Thanks,

Jinmei Liao

Review Request 62021: GEODE-3547: Simplify behavior for non-writable deploy directory

[Jared Stewart]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/62021/
---

Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, Kirk Lund, and 
Patrick Rhomberg.


Repository: geode


Description
---

GEODE-3547: Simplify behavior for non-writable deploy directory
 - Also fixes the flaky JarDeployerIntegrationTest


Diffs
-

  geode-core/src/main/java/org/apache/geode/internal/JarDeployer.java 
c21fb9dd1ad1ff5f64a6bee447905c8636d93c83 
  
geode-core/src/test/java/org/apache/geode/internal/JarDeployerIntegrationTest.java
 b81e3e9d095b03fc24287808e9df06c46900fa81 


Diff: https://reviews.apache.org/r/62021/diff/1/


Testing
---

Precheckin running


Thanks,

Jared Stewart

[GitHub] geode pull request #753: GEODE-3283: Expose parallel import and export in gf...

[jaredjstewart]

Github user jaredjstewart commented on a diff in the pull request:

https://github.com/apache/geode/pull/753#discussion_r136444815
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportDataCommand.java
 ---
@@ -41,44 +44,34 @@ public Result exportData(
   @CliOption(key = CliStrings.EXPORT_DATA__REGION, mandatory = true,
   optionContext = ConverterHint.REGION_PATH,
   help = CliStrings.EXPORT_DATA__REGION__HELP) String regionName,
-  @CliOption(key = CliStrings.EXPORT_DATA__FILE, mandatory = true,
+  @CliOption(key = CliStrings.EXPORT_DATA__FILE,
   help = CliStrings.EXPORT_DATA__FILE__HELP) String filePath,
+  @CliOption(key = CliStrings.EXPORT_DATA__DIR,
+  help = CliStrings.EXPORT_DATA__DIR__HELP) String dirPath,
   @CliOption(key = CliStrings.MEMBER, optionContext = 
ConverterHint.MEMBERIDNAME,
-  mandatory = true, help = CliStrings.EXPORT_DATA__MEMBER__HELP) 
String memberNameOrId) {
+  mandatory = true, help = CliStrings.EXPORT_DATA__MEMBER__HELP) 
String memberNameOrId,
+  @CliOption(key = CliStrings.EXPORT_DATA__PARALLEL, 
unspecifiedDefaultValue = "false",
--- End diff --

I think it would be convenient to the user for us to add `, 
specifiedDefaultValue = "true" here.  That would make it so that one could 
simply enter `export data --parallel` to get the behavior of `export data 
--parallel=true`.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

[Jacob Barrett]

I believe what Bruce was saying is that the behavior should be covered by
timeouts not iteration attempts. If the client is able to successfully send
the command to a server but a failure occurs waiting for a reply we would
not retry. If the client is unable to send the request to a sever because
the connection closes then we would try the next server, and the next, up
to the timeout value.

On Thu, Aug 31, 2017 at 1:31 PM Mark Hanson  wrote:

> I can also see why the user doing the retries themselves has value. As a
> lowest common denominator approach, pulling the API is sound.
>
> On Thu, Aug 31, 2017 at 1:26 PM, Mark Hanson  wrote:
>
> > I think the setRetryAttempts really harks back to the case that Bruce was
> > alluding to in which the server goes down. Which is the one valid case
> for
> > this kind of API in theory. Are we say that in that case we don't retry?
> > Seems like we are making the API a little less nice for people.
> > As a developer using an API, I want to do as little as possible and get
> > the most robust solution possible. This seems to go the wrong direction
> of
> > that kind of intent in a way. I want the client to automatically try
> every
> > server. I don't ever want to configure the value. I could limit with this
> > API and force it to never retry or I could cause it to retry more times
> > than I care for it to.  If we are going to get rid of this API in
> > particular, I would favor having it automatically try some number of
> > servers or all, but not retrying at all would not be my choice.
> >
> > On Thu, Aug 31, 2017 at 1:08 PM, Jacob Barrett 
> > wrote:
> >
> >> On Thu, Aug 31, 2017 at 1:00 PM Mark Hanson  wrote:
> >>
> >> > I would have to go looking, but the key concept is that this is a
> bigger
> >> > problem.
> >> >
> >> > interval such as the time between retries
> >> > wait as in how long to wait for a response...
> >> >
> >>
> >> All time intervals should be expressed in terms of std::chrono::duration
> >> values. A value of std::chrono::duration::zero means don't wait. I would
> >> suggest that a negative time not be allowed and that some very large,
> >> MAXINT, value could take the place of "forever". There is a ticket
> already
> >> open and in progress to replace all time based values with std::chrono.
> >>
> >>
> >> > retry as how many times to retry after a failure
> >> > attempts as in how many times to do a thing before giving up
> >> > Set of objects as in the setRetryAttempts code which , will try a
> >> number of
> >> > servers before giving up. where n is the number, -1 equals all, and 0
> >> means
> >> > (1 server, no retries).
> >> >
> >>
> >> If there are other examples of "iteration" then we should consider them
> >> based on what they iterate. I think the consensus on setRetryAttempts is
> >> to
> >> abolish it.
> >>
> >> -Jake
> >>
> >
> >
>

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

[Mark Hanson]

I can also see why the user doing the retries themselves has value. As a
lowest common denominator approach, pulling the API is sound.

On Thu, Aug 31, 2017 at 1:26 PM, Mark Hanson  wrote:

> I think the setRetryAttempts really harks back to the case that Bruce was
> alluding to in which the server goes down. Which is the one valid case for
> this kind of API in theory. Are we say that in that case we don't retry?
> Seems like we are making the API a little less nice for people.
> As a developer using an API, I want to do as little as possible and get
> the most robust solution possible. This seems to go the wrong direction of
> that kind of intent in a way. I want the client to automatically try every
> server. I don't ever want to configure the value. I could limit with this
> API and force it to never retry or I could cause it to retry more times
> than I care for it to.  If we are going to get rid of this API in
> particular, I would favor having it automatically try some number of
> servers or all, but not retrying at all would not be my choice.
>
> On Thu, Aug 31, 2017 at 1:08 PM, Jacob Barrett 
> wrote:
>
>> On Thu, Aug 31, 2017 at 1:00 PM Mark Hanson  wrote:
>>
>> > I would have to go looking, but the key concept is that this is a bigger
>> > problem.
>> >
>> > interval such as the time between retries
>> > wait as in how long to wait for a response...
>> >
>>
>> All time intervals should be expressed in terms of std::chrono::duration
>> values. A value of std::chrono::duration::zero means don't wait. I would
>> suggest that a negative time not be allowed and that some very large,
>> MAXINT, value could take the place of "forever". There is a ticket already
>> open and in progress to replace all time based values with std::chrono.
>>
>>
>> > retry as how many times to retry after a failure
>> > attempts as in how many times to do a thing before giving up
>> > Set of objects as in the setRetryAttempts code which , will try a
>> number of
>> > servers before giving up. where n is the number, -1 equals all, and 0
>> means
>> > (1 server, no retries).
>> >
>>
>> If there are other examples of "iteration" then we should consider them
>> based on what they iterate. I think the consensus on setRetryAttempts is
>> to
>> abolish it.
>>
>> -Jake
>>
>
>

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

[Mark Hanson]

I think the setRetryAttempts really harks back to the case that Bruce was
alluding to in which the server goes down. Which is the one valid case for
this kind of API in theory. Are we say that in that case we don't retry?
Seems like we are making the API a little less nice for people.
As a developer using an API, I want to do as little as possible and get the
most robust solution possible. This seems to go the wrong direction of that
kind of intent in a way. I want the client to automatically try every
server. I don't ever want to configure the value. I could limit with this
API and force it to never retry or I could cause it to retry more times
than I care for it to.  If we are going to get rid of this API in
particular, I would favor having it automatically try some number of
servers or all, but not retrying at all would not be my choice.

On Thu, Aug 31, 2017 at 1:08 PM, Jacob Barrett  wrote:

> On Thu, Aug 31, 2017 at 1:00 PM Mark Hanson  wrote:
>
> > I would have to go looking, but the key concept is that this is a bigger
> > problem.
> >
> > interval such as the time between retries
> > wait as in how long to wait for a response...
> >
>
> All time intervals should be expressed in terms of std::chrono::duration
> values. A value of std::chrono::duration::zero means don't wait. I would
> suggest that a negative time not be allowed and that some very large,
> MAXINT, value could take the place of "forever". There is a ticket already
> open and in progress to replace all time based values with std::chrono.
>
>
> > retry as how many times to retry after a failure
> > attempts as in how many times to do a thing before giving up
> > Set of objects as in the setRetryAttempts code which , will try a number
> of
> > servers before giving up. where n is the number, -1 equals all, and 0
> means
> > (1 server, no retries).
> >
>
> If there are other examples of "iteration" then we should consider them
> based on what they iterate. I think the consensus on setRetryAttempts is to
> abolish it.
>
> -Jake
>

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

[Jacob Barrett]

On Thu, Aug 31, 2017 at 1:00 PM Mark Hanson  wrote:

> I would have to go looking, but the key concept is that this is a bigger
> problem.
>
> interval such as the time between retries
> wait as in how long to wait for a response...
>

All time intervals should be expressed in terms of std::chrono::duration
values. A value of std::chrono::duration::zero means don't wait. I would
suggest that a negative time not be allowed and that some very large,
MAXINT, value could take the place of "forever". There is a ticket already
open and in progress to replace all time based values with std::chrono.


> retry as how many times to retry after a failure
> attempts as in how many times to do a thing before giving up
> Set of objects as in the setRetryAttempts code which , will try a number of
> servers before giving up. where n is the number, -1 equals all, and 0 means
> (1 server, no retries).
>

If there are other examples of "iteration" then we should consider them
based on what they iterate. I think the consensus on setRetryAttempts is to
abolish it.

-Jake

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

[Mark Hanson]

I would have to go looking, but the key concept is that this is a bigger
problem.

interval such as the time between retries
wait as in how long to wait for a response...
retry as how many times to retry after a failure
attempts as in how many times to do a thing before giving up
Set of objects as in the setRetryAttempts code which , will try a number of
servers before giving up. where n is the number, -1 equals all, and 0 means
(1 server, no retries).

On Thu, Aug 31, 2017 at 11:17 AM, Jacob Barrett  wrote:

> Mark,
>
> Can you give concrete examples in the API?
>
> On Thu, Aug 31, 2017 at 11:11 AM Mark Hanson  wrote:
>
> > This basic problem exists with the following cases.
> > Interval: to do something at an interval
> > Wait: to wait a certain length of time
> > Retry: to retry a certain number of times
> > Attempts: to make a certain number of attempts (similar to retry)
> > Sets of objects: to iterate through an unscoped set of objects.
> >
> > On Thu, Aug 31, 2017 at 11:04 AM, Jacob Barrett 
> > wrote:
> >
> > > I should have scoped it to the native API.
> > >
> > > > On Aug 31, 2017, at 10:30 AM, Bruce Schuchardt <
> bschucha...@pivotal.io
> > >
> > > wrote:
> > > >
> > > > The DistributedLockService uses -1/0/n
> > > >
> > > >
> > > >> On 8/31/17 10:21 AM, Jacob Barrett wrote:
> > > >> In relation to this particular example you provided the discussion
> of
> > > removing it is valid as an alternative to fixing it.
> > > >>
> > > >> Are there other examples of this -1/0/n parameter style we should
> > > discuss?
> > > >>
> > > >> -Jake
> > > >>
> > > >>
> > > >> Sent from my iPhone
> > > >>
> > > >>> On Aug 31, 2017, at 10:15 AM, Mark Hanson 
> > wrote:
> > > >>>
> > > >>> As I understand it here, the question is when the first server is
> no
> > > longer
> > > >>> available, do we retry on another server. I would say the answer is
> > > clearly
> > > >>> yes and we in the name of controlling load want to have an API that
> > > >>> controls the timing of how that is done. The customer can say no
> > > retries
> > > >>> and they can right their own
> > > >>>
> > > >>> This is a little bit off the topic of the much larger topic though.
> > The
> > > >>> reason I was told to send this email was to broach the larger
> > > discussion of
> > > >>> iteration and the overloading to use -1 to mean infinite. At least
> > > that is
> > > >>> my understanding...
> > > >>>
> > > >>>
> > > >>> On Thu, Aug 31, 2017 at 9:32 AM, Udo Kohlmeyer <
> > ukohlme...@pivotal.io>
> > > >>> wrote:
> > > >>>
> > >  +1 to removing retry,
> > > 
> > >  Imo, the retry should made the responsibility of the submitting
> > >  application. When an operation fails, the user should have to
> decide
> > > if
> > >  they should retry or not. It should not be default behavior of a
> > > connection
> > >  pool.
> > > 
> > >  --Udo
> > > 
> > > 
> > > 
> > > > On 8/31/17 09:26, Dan Smith wrote:
> > > >
> > > > The java client does still have a retry-attempts setting - it's
> > > pretty
> > > > much
> > > > the same as the C++ API.
> > > >
> > > > I agree with Bruce though, I think the current retry behavior is
> > not
> > > > ideal.
> > > > I think it only really makes sense for the client to retry an
> > > operation
> > > > that it actually sent to the server if the server stops
> responding
> > to
> > > > pings. The believe the current retry behavior just waits the
> > > read-timeout
> > > > and then retries the operation on a new server.
> > > >
> > > > -Dan
> > > >
> > > > On Thu, Aug 31, 2017 at 8:08 AM, Bruce Schuchardt <
> > > bschucha...@pivotal.io
> > > > wrote:
> > > >
> > > > Does anyone have a good argument for clients retrying operations?
> > I
> > > can
> > > >> see doing that if the server has died but otherwise it just
> > > overloads the
> > > >> servers.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> On 8/30/17 8:36 PM, Dan Smith wrote:
> > > >>
> > > >> In general, I think we need making the configuration of geode
> less
> > > >>> complex,
> > > >>> not more.
> > > >>>
> > > >>> As far as retry-attempts goes, maybe the best thing to do is to
> > > get rid
> > > >>> of
> > > >>> it. The P2P layer has no such concept. I don't think users
> should
> > > really
> > > >>> have to care about how many servers an operation is attempted
> > > against. A
> > > >>> user may want to specify how long an operation is allowed to
> > take,
> > > but
> > > >>> that
> > > >>> could be better specified with an operation timeout rather than
> > the
> > > >>> current
> > > >>> read-timeout + retry-attempts.
> > > >>>
> > > >>> -Dan
> > > >>>
> > > >>>
> > > >>>
> > > >>> On Wed, Aug 30, 2017 at 2:08 PM, Patrick Rhomberg <
> > > prhomb...@pivotal.io
> > > >>> wrote:
> > > >>>
> > > >>> Personally,

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

[Jacob Barrett]

Mark,

Can you give concrete examples in the API?

On Thu, Aug 31, 2017 at 11:11 AM Mark Hanson  wrote:

> This basic problem exists with the following cases.
> Interval: to do something at an interval
> Wait: to wait a certain length of time
> Retry: to retry a certain number of times
> Attempts: to make a certain number of attempts (similar to retry)
> Sets of objects: to iterate through an unscoped set of objects.
>
> On Thu, Aug 31, 2017 at 11:04 AM, Jacob Barrett 
> wrote:
>
> > I should have scoped it to the native API.
> >
> > > On Aug 31, 2017, at 10:30 AM, Bruce Schuchardt  >
> > wrote:
> > >
> > > The DistributedLockService uses -1/0/n
> > >
> > >
> > >> On 8/31/17 10:21 AM, Jacob Barrett wrote:
> > >> In relation to this particular example you provided the discussion of
> > removing it is valid as an alternative to fixing it.
> > >>
> > >> Are there other examples of this -1/0/n parameter style we should
> > discuss?
> > >>
> > >> -Jake
> > >>
> > >>
> > >> Sent from my iPhone
> > >>
> > >>> On Aug 31, 2017, at 10:15 AM, Mark Hanson 
> wrote:
> > >>>
> > >>> As I understand it here, the question is when the first server is no
> > longer
> > >>> available, do we retry on another server. I would say the answer is
> > clearly
> > >>> yes and we in the name of controlling load want to have an API that
> > >>> controls the timing of how that is done. The customer can say no
> > retries
> > >>> and they can right their own
> > >>>
> > >>> This is a little bit off the topic of the much larger topic though.
> The
> > >>> reason I was told to send this email was to broach the larger
> > discussion of
> > >>> iteration and the overloading to use -1 to mean infinite. At least
> > that is
> > >>> my understanding...
> > >>>
> > >>>
> > >>> On Thu, Aug 31, 2017 at 9:32 AM, Udo Kohlmeyer <
> ukohlme...@pivotal.io>
> > >>> wrote:
> > >>>
> >  +1 to removing retry,
> > 
> >  Imo, the retry should made the responsibility of the submitting
> >  application. When an operation fails, the user should have to decide
> > if
> >  they should retry or not. It should not be default behavior of a
> > connection
> >  pool.
> > 
> >  --Udo
> > 
> > 
> > 
> > > On 8/31/17 09:26, Dan Smith wrote:
> > >
> > > The java client does still have a retry-attempts setting - it's
> > pretty
> > > much
> > > the same as the C++ API.
> > >
> > > I agree with Bruce though, I think the current retry behavior is
> not
> > > ideal.
> > > I think it only really makes sense for the client to retry an
> > operation
> > > that it actually sent to the server if the server stops responding
> to
> > > pings. The believe the current retry behavior just waits the
> > read-timeout
> > > and then retries the operation on a new server.
> > >
> > > -Dan
> > >
> > > On Thu, Aug 31, 2017 at 8:08 AM, Bruce Schuchardt <
> > bschucha...@pivotal.io
> > > wrote:
> > >
> > > Does anyone have a good argument for clients retrying operations?
> I
> > can
> > >> see doing that if the server has died but otherwise it just
> > overloads the
> > >> servers.
> > >>
> > >>
> > >>
> > >>
> > >> On 8/30/17 8:36 PM, Dan Smith wrote:
> > >>
> > >> In general, I think we need making the configuration of geode less
> > >>> complex,
> > >>> not more.
> > >>>
> > >>> As far as retry-attempts goes, maybe the best thing to do is to
> > get rid
> > >>> of
> > >>> it. The P2P layer has no such concept. I don't think users should
> > really
> > >>> have to care about how many servers an operation is attempted
> > against. A
> > >>> user may want to specify how long an operation is allowed to
> take,
> > but
> > >>> that
> > >>> could be better specified with an operation timeout rather than
> the
> > >>> current
> > >>> read-timeout + retry-attempts.
> > >>>
> > >>> -Dan
> > >>>
> > >>>
> > >>>
> > >>> On Wed, Aug 30, 2017 at 2:08 PM, Patrick Rhomberg <
> > prhomb...@pivotal.io
> > >>> wrote:
> > >>>
> > >>> Personally, I don't much like sentinel values, even if they have
> > their
> > >>>
> >  occasional use.
> > 
> >  Do we need to provide an authentic infinite value?  64-bit
> MAXINT
> > is
> >  nearly
> >  10 quintillion.  At 10GHz, that still takes almost three years.
> > If
> >  each
> >  retry takes as much as 10ms, we're still looking at "retry for
> as
> > long
> >  as
> >  the earth has existed."  32-bit's is much more attainable, of
> > course,
> >  but I
> >  think the point stands -- if you need to retry that much,
> > something
> >  else
> >  is
> >  very wrong.
> > 
> >  In the more general sense, I struggle to think of a context
> where
> > an
> >  authentic infinity is meaningfully dis

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

[Udo Kohlmeyer]

I think with the retry one has to distinguish between:

1. currently running tasks that have not yet completed (current timeout
   behavior)
2. tasks that have failed because the server died.

In case #1, we currently have the ability to compound any load error, by 
forwarding the request to the cluster again, thus just adding 
unnecessary load. In this case we should NEVER just randomly retry.


In case #2, the client should retry another server because the original 
request might have been lost, never completed, or completed but not yet 
notified on result.  THIS would be the ONLY case were an auto retry 
makes sense


--Udo


On 8/31/17 11:10, Mark Hanson wrote:

This basic problem exists with the following cases.
Interval: to do something at an interval
Wait: to wait a certain length of time
Retry: to retry a certain number of times
Attempts: to make a certain number of attempts (similar to retry)
Sets of objects: to iterate through an unscoped set of objects.

On Thu, Aug 31, 2017 at 11:04 AM, Jacob Barrett  wrote:


I should have scoped it to the native API.


On Aug 31, 2017, at 10:30 AM, Bruce Schuchardt 

wrote:

The DistributedLockService uses -1/0/n



On 8/31/17 10:21 AM, Jacob Barrett wrote:
In relation to this particular example you provided the discussion of

removing it is valid as an alternative to fixing it.

Are there other examples of this -1/0/n parameter style we should

discuss?

-Jake


Sent from my iPhone


On Aug 31, 2017, at 10:15 AM, Mark Hanson  wrote:

As I understand it here, the question is when the first server is no

longer

available, do we retry on another server. I would say the answer is

clearly

yes and we in the name of controlling load want to have an API that
controls the timing of how that is done. The customer can say no

retries

and they can right their own

This is a little bit off the topic of the much larger topic though. The
reason I was told to send this email was to broach the larger

discussion of

iteration and the overloading to use -1 to mean infinite. At least

that is

my understanding...


On Thu, Aug 31, 2017 at 9:32 AM, Udo Kohlmeyer 
wrote:


+1 to removing retry,

Imo, the retry should made the responsibility of the submitting
application. When an operation fails, the user should have to decide

if

they should retry or not. It should not be default behavior of a

connection

pool.

--Udo




On 8/31/17 09:26, Dan Smith wrote:

The java client does still have a retry-attempts setting - it's

pretty

much
the same as the C++ API.

I agree with Bruce though, I think the current retry behavior is not
ideal.
I think it only really makes sense for the client to retry an

operation

that it actually sent to the server if the server stops responding to
pings. The believe the current retry behavior just waits the

read-timeout

and then retries the operation on a new server.

-Dan

On Thu, Aug 31, 2017 at 8:08 AM, Bruce Schuchardt <

bschucha...@pivotal.io

wrote:

Does anyone have a good argument for clients retrying operations?  I

can

see doing that if the server has died but otherwise it just

overloads the

servers.




On 8/30/17 8:36 PM, Dan Smith wrote:

In general, I think we need making the configuration of geode less

complex,
not more.

As far as retry-attempts goes, maybe the best thing to do is to

get rid

of
it. The P2P layer has no such concept. I don't think users should

really

have to care about how many servers an operation is attempted

against. A

user may want to specify how long an operation is allowed to take,

but

that
could be better specified with an operation timeout rather than the
current
read-timeout + retry-attempts.

-Dan



On Wed, Aug 30, 2017 at 2:08 PM, Patrick Rhomberg <

prhomb...@pivotal.io

wrote:

Personally, I don't much like sentinel values, even if they have

their

occasional use.

Do we need to provide an authentic infinite value?  64-bit MAXINT

is

nearly
10 quintillion.  At 10GHz, that still takes almost three years.

If

each
retry takes as much as 10ms, we're still looking at "retry for as

long

as
the earth has existed."  32-bit's is much more attainable, of

course,

but I
think the point stands -- if you need to retry that much,

something

else
is
very wrong.

In the more general sense, I struggle to think of a context where

an

authentic infinity is meaningfully distinct in application from a
massive
finite like MAXINT.  But I could be wrong and would love to hear

what

other
people think.

On Wed, Aug 30, 2017 at 1:26 PM, Mark Hanson 
wrote:

Hi All,


*Question: how should we deal in a very forward and clean

fashion with

the

implicit ambiguity of -1 or all, or infinite, or forever?*

*Background:*


We are looking to get some feedback on the subject of

infinite/all/forever

in the geode/geode-native code.

In looking at the code, we see an example function,


setRetryAttempts

[GitHub] geode pull request #753: GEODE-3283: Expose parallel import and export in gf...

[nreich]

GitHub user nreich opened a pull request:

https://github.com/apache/geode/pull/753

GEODE-3283: Expose parallel import and export in gfsh

This pull request allows users to conduct parallel import and export of 
snapshots through gfsh. Because multiple snapshot files may be present on a 
given member for import, a "directory" option needed to be added to import, to 
import all snapshot files in that location (this is required for parallel 
import: the "file" parameter is ignored when "parallel" is true). For export, 
the same use of "directory" is needed, so that saving all snapshot files to a 
shared network storage device is possible. The "directory" parameter can also 
be used when "parallel" is false, but only files from the specified member will 
be imported (export will still be a single file). Note: parallel is only 
supported in partitioned regions, if "parallel" is set to true on other types 
of regions, it will be ignored.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/nreich/geode feature/GEODE-3283

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/753.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #753


commit e251ef073f434545d1359cc6f3b8f6f6f7eb72d6
Author: Nick Reich 
Date:   2017-08-31T17:24:39Z

GEODE-3283: Expose parallel import and export in gfsh

  * Allow users to make use of parallel import and export of snapshots
  * in gfsh




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

[Mark Hanson]

This basic problem exists with the following cases.
Interval: to do something at an interval
Wait: to wait a certain length of time
Retry: to retry a certain number of times
Attempts: to make a certain number of attempts (similar to retry)
Sets of objects: to iterate through an unscoped set of objects.

On Thu, Aug 31, 2017 at 11:04 AM, Jacob Barrett  wrote:

> I should have scoped it to the native API.
>
> > On Aug 31, 2017, at 10:30 AM, Bruce Schuchardt 
> wrote:
> >
> > The DistributedLockService uses -1/0/n
> >
> >
> >> On 8/31/17 10:21 AM, Jacob Barrett wrote:
> >> In relation to this particular example you provided the discussion of
> removing it is valid as an alternative to fixing it.
> >>
> >> Are there other examples of this -1/0/n parameter style we should
> discuss?
> >>
> >> -Jake
> >>
> >>
> >> Sent from my iPhone
> >>
> >>> On Aug 31, 2017, at 10:15 AM, Mark Hanson  wrote:
> >>>
> >>> As I understand it here, the question is when the first server is no
> longer
> >>> available, do we retry on another server. I would say the answer is
> clearly
> >>> yes and we in the name of controlling load want to have an API that
> >>> controls the timing of how that is done. The customer can say no
> retries
> >>> and they can right their own
> >>>
> >>> This is a little bit off the topic of the much larger topic though. The
> >>> reason I was told to send this email was to broach the larger
> discussion of
> >>> iteration and the overloading to use -1 to mean infinite. At least
> that is
> >>> my understanding...
> >>>
> >>>
> >>> On Thu, Aug 31, 2017 at 9:32 AM, Udo Kohlmeyer 
> >>> wrote:
> >>>
>  +1 to removing retry,
> 
>  Imo, the retry should made the responsibility of the submitting
>  application. When an operation fails, the user should have to decide
> if
>  they should retry or not. It should not be default behavior of a
> connection
>  pool.
> 
>  --Udo
> 
> 
> 
> > On 8/31/17 09:26, Dan Smith wrote:
> >
> > The java client does still have a retry-attempts setting - it's
> pretty
> > much
> > the same as the C++ API.
> >
> > I agree with Bruce though, I think the current retry behavior is not
> > ideal.
> > I think it only really makes sense for the client to retry an
> operation
> > that it actually sent to the server if the server stops responding to
> > pings. The believe the current retry behavior just waits the
> read-timeout
> > and then retries the operation on a new server.
> >
> > -Dan
> >
> > On Thu, Aug 31, 2017 at 8:08 AM, Bruce Schuchardt <
> bschucha...@pivotal.io
> > wrote:
> >
> > Does anyone have a good argument for clients retrying operations?  I
> can
> >> see doing that if the server has died but otherwise it just
> overloads the
> >> servers.
> >>
> >>
> >>
> >>
> >> On 8/30/17 8:36 PM, Dan Smith wrote:
> >>
> >> In general, I think we need making the configuration of geode less
> >>> complex,
> >>> not more.
> >>>
> >>> As far as retry-attempts goes, maybe the best thing to do is to
> get rid
> >>> of
> >>> it. The P2P layer has no such concept. I don't think users should
> really
> >>> have to care about how many servers an operation is attempted
> against. A
> >>> user may want to specify how long an operation is allowed to take,
> but
> >>> that
> >>> could be better specified with an operation timeout rather than the
> >>> current
> >>> read-timeout + retry-attempts.
> >>>
> >>> -Dan
> >>>
> >>>
> >>>
> >>> On Wed, Aug 30, 2017 at 2:08 PM, Patrick Rhomberg <
> prhomb...@pivotal.io
> >>> wrote:
> >>>
> >>> Personally, I don't much like sentinel values, even if they have
> their
> >>>
>  occasional use.
> 
>  Do we need to provide an authentic infinite value?  64-bit MAXINT
> is
>  nearly
>  10 quintillion.  At 10GHz, that still takes almost three years.
> If
>  each
>  retry takes as much as 10ms, we're still looking at "retry for as
> long
>  as
>  the earth has existed."  32-bit's is much more attainable, of
> course,
>  but I
>  think the point stands -- if you need to retry that much,
> something
>  else
>  is
>  very wrong.
> 
>  In the more general sense, I struggle to think of a context where
> an
>  authentic infinity is meaningfully distinct in application from a
>  massive
>  finite like MAXINT.  But I could be wrong and would love to hear
> what
>  other
>  people think.
> 
>  On Wed, Aug 30, 2017 at 1:26 PM, Mark Hanson 
>  wrote:
> 
>  Hi All,
> 
> > *Question: how should we deal in a very forward and clean
> fashion with
> >
> > the
>  implicit ambiguity of -1 or

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

[Jacob Barrett]

I should have scoped it to the native API. 

> On Aug 31, 2017, at 10:30 AM, Bruce Schuchardt  wrote:
> 
> The DistributedLockService uses -1/0/n
> 
> 
>> On 8/31/17 10:21 AM, Jacob Barrett wrote:
>> In relation to this particular example you provided the discussion of 
>> removing it is valid as an alternative to fixing it.
>> 
>> Are there other examples of this -1/0/n parameter style we should discuss?
>> 
>> -Jake
>> 
>> 
>> Sent from my iPhone
>> 
>>> On Aug 31, 2017, at 10:15 AM, Mark Hanson  wrote:
>>> 
>>> As I understand it here, the question is when the first server is no longer
>>> available, do we retry on another server. I would say the answer is clearly
>>> yes and we in the name of controlling load want to have an API that
>>> controls the timing of how that is done. The customer can say no retries
>>> and they can right their own
>>> 
>>> This is a little bit off the topic of the much larger topic though. The
>>> reason I was told to send this email was to broach the larger discussion of
>>> iteration and the overloading to use -1 to mean infinite. At least that is
>>> my understanding...
>>> 
>>> 
>>> On Thu, Aug 31, 2017 at 9:32 AM, Udo Kohlmeyer 
>>> wrote:
>>> 
 +1 to removing retry,
 
 Imo, the retry should made the responsibility of the submitting
 application. When an operation fails, the user should have to decide if
 they should retry or not. It should not be default behavior of a connection
 pool.
 
 --Udo
 
 
 
> On 8/31/17 09:26, Dan Smith wrote:
> 
> The java client does still have a retry-attempts setting - it's pretty
> much
> the same as the C++ API.
> 
> I agree with Bruce though, I think the current retry behavior is not
> ideal.
> I think it only really makes sense for the client to retry an operation
> that it actually sent to the server if the server stops responding to
> pings. The believe the current retry behavior just waits the read-timeout
> and then retries the operation on a new server.
> 
> -Dan
> 
> On Thu, Aug 31, 2017 at 8:08 AM, Bruce Schuchardt  wrote:
> 
> Does anyone have a good argument for clients retrying operations?  I can
>> see doing that if the server has died but otherwise it just overloads the
>> servers.
>> 
>> 
>> 
>> 
>> On 8/30/17 8:36 PM, Dan Smith wrote:
>> 
>> In general, I think we need making the configuration of geode less
>>> complex,
>>> not more.
>>> 
>>> As far as retry-attempts goes, maybe the best thing to do is to get rid
>>> of
>>> it. The P2P layer has no such concept. I don't think users should really
>>> have to care about how many servers an operation is attempted against. A
>>> user may want to specify how long an operation is allowed to take, but
>>> that
>>> could be better specified with an operation timeout rather than the
>>> current
>>> read-timeout + retry-attempts.
>>> 
>>> -Dan
>>> 
>>> 
>>> 
>>> On Wed, Aug 30, 2017 at 2:08 PM, Patrick Rhomberg >> wrote:
>>> 
>>> Personally, I don't much like sentinel values, even if they have their
>>> 
 occasional use.
 
 Do we need to provide an authentic infinite value?  64-bit MAXINT is
 nearly
 10 quintillion.  At 10GHz, that still takes almost three years.  If
 each
 retry takes as much as 10ms, we're still looking at "retry for as long
 as
 the earth has existed."  32-bit's is much more attainable, of course,
 but I
 think the point stands -- if you need to retry that much, something
 else
 is
 very wrong.
 
 In the more general sense, I struggle to think of a context where an
 authentic infinity is meaningfully distinct in application from a
 massive
 finite like MAXINT.  But I could be wrong and would love to hear what
 other
 people think.
 
 On Wed, Aug 30, 2017 at 1:26 PM, Mark Hanson 
 wrote:
 
 Hi All,
 
> *Question: how should we deal in a very forward and clean fashion with
> 
> the
 implicit ambiguity of -1 or all, or infinite, or forever?*
> 
> *Background:*
> 
> 
> We are looking to get some feedback on the subject of
> 
> infinite/all/forever
 in the geode/geode-native code.
> 
> In looking at the code, we see an example function,
> 
> 
> setRetryAttempts
>  006df0e70eeb481ef5e9e821dba0050dee9c6893/cppcache/include/
> geode/PoolFactory.hpp#L327>()
> [1] currently -1 means try all servers before failing. 0 means try 1
> 
> server
 before failing, and a number greater 

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

[Bruce Schuchardt]

The DistributedLockService uses -1/0/n


On 8/31/17 10:21 AM, Jacob Barrett wrote:

In relation to this particular example you provided the discussion of removing 
it is valid as an alternative to fixing it.

Are there other examples of this -1/0/n parameter style we should discuss?

-Jake


Sent from my iPhone


On Aug 31, 2017, at 10:15 AM, Mark Hanson  wrote:

As I understand it here, the question is when the first server is no longer
available, do we retry on another server. I would say the answer is clearly
yes and we in the name of controlling load want to have an API that
controls the timing of how that is done. The customer can say no retries
and they can right their own

This is a little bit off the topic of the much larger topic though. The
reason I was told to send this email was to broach the larger discussion of
iteration and the overloading to use -1 to mean infinite. At least that is
my understanding...


On Thu, Aug 31, 2017 at 9:32 AM, Udo Kohlmeyer 
wrote:


+1 to removing retry,

Imo, the retry should made the responsibility of the submitting
application. When an operation fails, the user should have to decide if
they should retry or not. It should not be default behavior of a connection
pool.

--Udo




On 8/31/17 09:26, Dan Smith wrote:

The java client does still have a retry-attempts setting - it's pretty
much
the same as the C++ API.

I agree with Bruce though, I think the current retry behavior is not
ideal.
I think it only really makes sense for the client to retry an operation
that it actually sent to the server if the server stops responding to
pings. The believe the current retry behavior just waits the read-timeout
and then retries the operation on a new server.

-Dan

On Thu, Aug 31, 2017 at 8:08 AM, Bruce Schuchardt 
see doing that if the server has died but otherwise it just overloads the
servers.




On 8/30/17 8:36 PM, Dan Smith wrote:

In general, I think we need making the configuration of geode less

complex,
not more.

As far as retry-attempts goes, maybe the best thing to do is to get rid
of
it. The P2P layer has no such concept. I don't think users should really
have to care about how many servers an operation is attempted against. A
user may want to specify how long an operation is allowed to take, but
that
could be better specified with an operation timeout rather than the
current
read-timeout + retry-attempts.

-Dan



On Wed, Aug 30, 2017 at 2:08 PM, Patrick Rhomberg 
occasional use.

Do we need to provide an authentic infinite value?  64-bit MAXINT is
nearly
10 quintillion.  At 10GHz, that still takes almost three years.  If
each
retry takes as much as 10ms, we're still looking at "retry for as long
as
the earth has existed."  32-bit's is much more attainable, of course,
but I
think the point stands -- if you need to retry that much, something
else
is
very wrong.

In the more general sense, I struggle to think of a context where an
authentic infinity is meaningfully distinct in application from a
massive
finite like MAXINT.  But I could be wrong and would love to hear what
other
people think.

On Wed, Aug 30, 2017 at 1:26 PM, Mark Hanson 
wrote:

Hi All,


*Question: how should we deal in a very forward and clean fashion with

the

implicit ambiguity of -1 or all, or infinite, or forever?*


*Background:*


We are looking to get some feedback on the subject of

infinite/all/forever

in the geode/geode-native code.


In looking at the code, we see an example function,


setRetryAttempts
()
[1] currently -1 means try all servers before failing. 0 means try 1

server

before failing, and a number greater than 0 means try number of servers

+1

before failing. In the case of setRetryAttempts, we don’t know how many

servers there are. This means that -1 for "All" servers has no
relation

to

the actual number of servers that we have. Perhaps setRetryAttempts

could
be renamed to setNumberOfAttempts to clarify as well, but the problem

still

stands...


*Discussion:*


In an attempt to provide the best code possible to the geode
community,
there has been some discussion of the use of infinite/all/forever as
an
overload of a count. Often -1 indicates infinite, while 0 indicates

never,

and 1 to MAXINT, inclusive, indicates a count.


There are three obvious approaches to solve the problem of the

overloading

of -1. The first approach is do nothing… Status quo.


The second approach to clarify things would be to create an
enumeration
that would be passed in as well as the number or an object..


struct Retries

{

typedef enum { eINFINITE, eCOUNT, eNONE} eCount;

eCount approach;

unsigned int count;

};



The third approach would be to pass a continue object of some sort
such
that it tells you if it is ok to continue through the use of an

algorithm.

An example would be


class Continue

{

virtual bool Continue

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

[Jacob Barrett]

In relation to this particular example you provided the discussion of removing 
it is valid as an alternative to fixing it.

Are there other examples of this -1/0/n parameter style we should discuss?

-Jake


Sent from my iPhone

> On Aug 31, 2017, at 10:15 AM, Mark Hanson  wrote:
> 
> As I understand it here, the question is when the first server is no longer
> available, do we retry on another server. I would say the answer is clearly
> yes and we in the name of controlling load want to have an API that
> controls the timing of how that is done. The customer can say no retries
> and they can right their own
> 
> This is a little bit off the topic of the much larger topic though. The
> reason I was told to send this email was to broach the larger discussion of
> iteration and the overloading to use -1 to mean infinite. At least that is
> my understanding...
> 
> 
> On Thu, Aug 31, 2017 at 9:32 AM, Udo Kohlmeyer 
> wrote:
> 
>> +1 to removing retry,
>> 
>> Imo, the retry should made the responsibility of the submitting
>> application. When an operation fails, the user should have to decide if
>> they should retry or not. It should not be default behavior of a connection
>> pool.
>> 
>> --Udo
>> 
>> 
>> 
>>> On 8/31/17 09:26, Dan Smith wrote:
>>> 
>>> The java client does still have a retry-attempts setting - it's pretty
>>> much
>>> the same as the C++ API.
>>> 
>>> I agree with Bruce though, I think the current retry behavior is not
>>> ideal.
>>> I think it only really makes sense for the client to retry an operation
>>> that it actually sent to the server if the server stops responding to
>>> pings. The believe the current retry behavior just waits the read-timeout
>>> and then retries the operation on a new server.
>>> 
>>> -Dan
>>> 
>>> On Thu, Aug 31, 2017 at 8:08 AM, Bruce Schuchardt >>> 
>>> wrote:
>>> 
>>> Does anyone have a good argument for clients retrying operations?  I can
 see doing that if the server has died but otherwise it just overloads the
 servers.
 
 
 
 
 On 8/30/17 8:36 PM, Dan Smith wrote:
 
 In general, I think we need making the configuration of geode less
> complex,
> not more.
> 
> As far as retry-attempts goes, maybe the best thing to do is to get rid
> of
> it. The P2P layer has no such concept. I don't think users should really
> have to care about how many servers an operation is attempted against. A
> user may want to specify how long an operation is allowed to take, but
> that
> could be better specified with an operation timeout rather than the
> current
> read-timeout + retry-attempts.
> 
> -Dan
> 
> 
> 
> On Wed, Aug 30, 2017 at 2:08 PM, Patrick Rhomberg > 
> wrote:
> 
> Personally, I don't much like sentinel values, even if they have their
> 
>> occasional use.
>> 
>> Do we need to provide an authentic infinite value?  64-bit MAXINT is
>> nearly
>> 10 quintillion.  At 10GHz, that still takes almost three years.  If
>> each
>> retry takes as much as 10ms, we're still looking at "retry for as long
>> as
>> the earth has existed."  32-bit's is much more attainable, of course,
>> but I
>> think the point stands -- if you need to retry that much, something
>> else
>> is
>> very wrong.
>> 
>> In the more general sense, I struggle to think of a context where an
>> authentic infinity is meaningfully distinct in application from a
>> massive
>> finite like MAXINT.  But I could be wrong and would love to hear what
>> other
>> people think.
>> 
>> On Wed, Aug 30, 2017 at 1:26 PM, Mark Hanson 
>> wrote:
>> 
>> Hi All,
>> 
>>> 
>>> *Question: how should we deal in a very forward and clean fashion with
>>> 
>>> the
>> 
>> implicit ambiguity of -1 or all, or infinite, or forever?*
>>> 
>>> 
>>> *Background:*
>>> 
>>> 
>>> We are looking to get some feedback on the subject of
>>> 
>>> infinite/all/forever
>> 
>> in the geode/geode-native code.
>>> 
>>> 
>>> In looking at the code, we see an example function,
>>> 
>>> 
>>> setRetryAttempts
>>> >> 006df0e70eeb481ef5e9e821dba0050dee9c6893/cppcache/include/
>>> geode/PoolFactory.hpp#L327>()
>>> [1] currently -1 means try all servers before failing. 0 means try 1
>>> 
>>> server
>> 
>> before failing, and a number greater than 0 means try number of servers
>>> 
>>> +1
>> 
>> before failing. In the case of setRetryAttempts, we don’t know how many
>>> servers there are. This means that -1 for "All" servers has no
>>> relation
>>> 
>>> to
>> 
>> the actual number of servers that we have. Perhaps setRetryAttempts
>>> could
>>> be renamed to setNumberOfAttempts to clarify as well, but the pro

Jenkins build is back to normal : Geode-release-flaky #34

[Apache Jenkins Server]

See 

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

[Mark Hanson]

As I understand it here, the question is when the first server is no longer
available, do we retry on another server. I would say the answer is clearly
yes and we in the name of controlling load want to have an API that
controls the timing of how that is done. The customer can say no retries
and they can right their own

This is a little bit off the topic of the much larger topic though. The
reason I was told to send this email was to broach the larger discussion of
iteration and the overloading to use -1 to mean infinite. At least that is
my understanding...


On Thu, Aug 31, 2017 at 9:32 AM, Udo Kohlmeyer 
wrote:

> +1 to removing retry,
>
> Imo, the retry should made the responsibility of the submitting
> application. When an operation fails, the user should have to decide if
> they should retry or not. It should not be default behavior of a connection
> pool.
>
> --Udo
>
>
>
> On 8/31/17 09:26, Dan Smith wrote:
>
>> The java client does still have a retry-attempts setting - it's pretty
>> much
>> the same as the C++ API.
>>
>> I agree with Bruce though, I think the current retry behavior is not
>> ideal.
>> I think it only really makes sense for the client to retry an operation
>> that it actually sent to the server if the server stops responding to
>> pings. The believe the current retry behavior just waits the read-timeout
>> and then retries the operation on a new server.
>>
>> -Dan
>>
>> On Thu, Aug 31, 2017 at 8:08 AM, Bruce Schuchardt > >
>> wrote:
>>
>> Does anyone have a good argument for clients retrying operations?  I can
>>> see doing that if the server has died but otherwise it just overloads the
>>> servers.
>>>
>>>
>>>
>>>
>>> On 8/30/17 8:36 PM, Dan Smith wrote:
>>>
>>> In general, I think we need making the configuration of geode less
 complex,
 not more.

 As far as retry-attempts goes, maybe the best thing to do is to get rid
 of
 it. The P2P layer has no such concept. I don't think users should really
 have to care about how many servers an operation is attempted against. A
 user may want to specify how long an operation is allowed to take, but
 that
 could be better specified with an operation timeout rather than the
 current
 read-timeout + retry-attempts.

 -Dan



 On Wed, Aug 30, 2017 at 2:08 PM, Patrick Rhomberg >>> >
 wrote:

 Personally, I don't much like sentinel values, even if they have their

> occasional use.
>
> Do we need to provide an authentic infinite value?  64-bit MAXINT is
> nearly
> 10 quintillion.  At 10GHz, that still takes almost three years.  If
> each
> retry takes as much as 10ms, we're still looking at "retry for as long
> as
> the earth has existed."  32-bit's is much more attainable, of course,
> but I
> think the point stands -- if you need to retry that much, something
> else
> is
> very wrong.
>
> In the more general sense, I struggle to think of a context where an
> authentic infinity is meaningfully distinct in application from a
> massive
> finite like MAXINT.  But I could be wrong and would love to hear what
> other
> people think.
>
> On Wed, Aug 30, 2017 at 1:26 PM, Mark Hanson 
> wrote:
>
> Hi All,
>
>>
>> *Question: how should we deal in a very forward and clean fashion with
>>
>> the
>
> implicit ambiguity of -1 or all, or infinite, or forever?*
>>
>>
>> *Background:*
>>
>>
>> We are looking to get some feedback on the subject of
>>
>> infinite/all/forever
>
> in the geode/geode-native code.
>>
>>
>> In looking at the code, we see an example function,
>>
>>
>> setRetryAttempts
>> > 006df0e70eeb481ef5e9e821dba0050dee9c6893/cppcache/include/
>> geode/PoolFactory.hpp#L327>()
>> [1] currently -1 means try all servers before failing. 0 means try 1
>>
>> server
>
> before failing, and a number greater than 0 means try number of servers
>>
>> +1
>
> before failing. In the case of setRetryAttempts, we don’t know how many
>> servers there are. This means that -1 for "All" servers has no
>> relation
>>
>> to
>
> the actual number of servers that we have. Perhaps setRetryAttempts
>> could
>> be renamed to setNumberOfAttempts to clarify as well, but the problem
>>
>> still
>
> stands...
>>
>>
>> *Discussion:*
>>
>>
>> In an attempt to provide the best code possible to the geode
>> community,
>> there has been some discussion of the use of infinite/all/forever as
>> an
>> overload of a count. Often -1 indicates infinite, while 0 indicates
>>
>> never,
>
> and 1 to MAXINT, inclusive, indicates a count.
>>
>>
>> There are three obvious approaches to solve the pro

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

[Udo Kohlmeyer]

+1 to removing retry,

Imo, the retry should made the responsibility of the submitting 
application. When an operation fails, the user should have to decide if 
they should retry or not. It should not be default behavior of a 
connection pool.


--Udo


On 8/31/17 09:26, Dan Smith wrote:

The java client does still have a retry-attempts setting - it's pretty much
the same as the C++ API.

I agree with Bruce though, I think the current retry behavior is not ideal.
I think it only really makes sense for the client to retry an operation
that it actually sent to the server if the server stops responding to
pings. The believe the current retry behavior just waits the read-timeout
and then retries the operation on a new server.

-Dan

On Thu, Aug 31, 2017 at 8:08 AM, Bruce Schuchardt 
wrote:


Does anyone have a good argument for clients retrying operations?  I can
see doing that if the server has died but otherwise it just overloads the
servers.




On 8/30/17 8:36 PM, Dan Smith wrote:


In general, I think we need making the configuration of geode less
complex,
not more.

As far as retry-attempts goes, maybe the best thing to do is to get rid of
it. The P2P layer has no such concept. I don't think users should really
have to care about how many servers an operation is attempted against. A
user may want to specify how long an operation is allowed to take, but
that
could be better specified with an operation timeout rather than the
current
read-timeout + retry-attempts.

-Dan



On Wed, Aug 30, 2017 at 2:08 PM, Patrick Rhomberg 
wrote:

Personally, I don't much like sentinel values, even if they have their

occasional use.

Do we need to provide an authentic infinite value?  64-bit MAXINT is
nearly
10 quintillion.  At 10GHz, that still takes almost three years.  If each
retry takes as much as 10ms, we're still looking at "retry for as long as
the earth has existed."  32-bit's is much more attainable, of course,
but I
think the point stands -- if you need to retry that much, something else
is
very wrong.

In the more general sense, I struggle to think of a context where an
authentic infinity is meaningfully distinct in application from a massive
finite like MAXINT.  But I could be wrong and would love to hear what
other
people think.

On Wed, Aug 30, 2017 at 1:26 PM, Mark Hanson  wrote:

Hi All,


*Question: how should we deal in a very forward and clean fashion with


the


implicit ambiguity of -1 or all, or infinite, or forever?*


*Background:*


We are looking to get some feedback on the subject of


infinite/all/forever


in the geode/geode-native code.


In looking at the code, we see an example function,


setRetryAttempts
()
[1] currently -1 means try all servers before failing. 0 means try 1


server


before failing, and a number greater than 0 means try number of servers


+1


before failing. In the case of setRetryAttempts, we don’t know how many
servers there are. This means that -1 for "All" servers has no relation


to


the actual number of servers that we have. Perhaps setRetryAttempts
could
be renamed to setNumberOfAttempts to clarify as well, but the problem


still


stands...


*Discussion:*


In an attempt to provide the best code possible to the geode community,
there has been some discussion of the use of infinite/all/forever as an
overload of a count. Often -1 indicates infinite, while 0 indicates


never,


and 1 to MAXINT, inclusive, indicates a count.


There are three obvious approaches to solve the problem of the


overloading


of -1. The first approach is do nothing… Status quo.


The second approach to clarify things would be to create an enumeration
that would be passed in as well as the number or an object..


struct Retries

{

typedef enum { eINFINITE, eCOUNT, eNONE} eCount;

eCount approach;

unsigned int count;

};



The third approach would be to pass a continue object of some sort such
that it tells you if it is ok to continue through the use of an


algorithm.


An example would be


class Continue

{

virtual bool Continue() = 0;

}


class InfiniteContinue : public Continue

{

bool Continue()

{

return true;

}

}


Continue co = InfiniteContinue;


while( co.Continue() )

{

//do a thing

}


Another example would be a Continue limited to 5 let’s say,


class CountContinue : public Continue

{

private:

int count;


public:

CountContinue(int count)

{

this.count = count;

}

bool Continue()

{

return count— > 0;

}

}


In both of these cases what is happening is that the algorithm is being
outsourced.


*Conclusion:*


We are putting this out, to start a discussion on the best way to move


this


forward… *What do people think? What direction would be the best going
forward?*


[1]
https://github.com/apache/geode-native/blob/


006df0e70eeb481ef5e9e821dba005


0dee9c6893/cppcache/include/geode/PoolFactory.hpp#L3

Re: Review Request 62002: GEODE-3539: Add tests for List Members and Describe Member

[Jinmei Liao]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/62002/#review184289
---


Ship it!




Ship It!

- Jinmei Liao


On Aug. 31, 2017, 4:20 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62002/
> ---
> 
> (Updated Aug. 31, 2017, 4:20 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, Kirk Lund, 
> and Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-3539: Add tests for List Members and Describe Member
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ListMemberCommand.java
>  ea88c69 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/MemberCommandsController.java
>  ba5c788 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DescribeMembersCommandDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ListMembersCommandDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/MemberCommandsDUnitTest.java
>  fe6bc40 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/TestCommand.java
>  17719be 
> 
> 
> Diff: https://reviews.apache.org/r/62002/diff/2/
> 
> 
> Testing
> ---
> 
> Precheckin running
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

[Dan Smith]

The java client does still have a retry-attempts setting - it's pretty much
the same as the C++ API.

I agree with Bruce though, I think the current retry behavior is not ideal.
I think it only really makes sense for the client to retry an operation
that it actually sent to the server if the server stops responding to
pings. The believe the current retry behavior just waits the read-timeout
and then retries the operation on a new server.

-Dan

On Thu, Aug 31, 2017 at 8:08 AM, Bruce Schuchardt 
wrote:

> Does anyone have a good argument for clients retrying operations?  I can
> see doing that if the server has died but otherwise it just overloads the
> servers.
>
>
>
>
> On 8/30/17 8:36 PM, Dan Smith wrote:
>
>> In general, I think we need making the configuration of geode less
>> complex,
>> not more.
>>
>> As far as retry-attempts goes, maybe the best thing to do is to get rid of
>> it. The P2P layer has no such concept. I don't think users should really
>> have to care about how many servers an operation is attempted against. A
>> user may want to specify how long an operation is allowed to take, but
>> that
>> could be better specified with an operation timeout rather than the
>> current
>> read-timeout + retry-attempts.
>>
>> -Dan
>>
>>
>>
>> On Wed, Aug 30, 2017 at 2:08 PM, Patrick Rhomberg 
>> wrote:
>>
>> Personally, I don't much like sentinel values, even if they have their
>>> occasional use.
>>>
>>> Do we need to provide an authentic infinite value?  64-bit MAXINT is
>>> nearly
>>> 10 quintillion.  At 10GHz, that still takes almost three years.  If each
>>> retry takes as much as 10ms, we're still looking at "retry for as long as
>>> the earth has existed."  32-bit's is much more attainable, of course,
>>> but I
>>> think the point stands -- if you need to retry that much, something else
>>> is
>>> very wrong.
>>>
>>> In the more general sense, I struggle to think of a context where an
>>> authentic infinity is meaningfully distinct in application from a massive
>>> finite like MAXINT.  But I could be wrong and would love to hear what
>>> other
>>> people think.
>>>
>>> On Wed, Aug 30, 2017 at 1:26 PM, Mark Hanson  wrote:
>>>
>>> Hi All,


 *Question: how should we deal in a very forward and clean fashion with

>>> the
>>>
 implicit ambiguity of -1 or all, or infinite, or forever?*


 *Background:*


 We are looking to get some feedback on the subject of

>>> infinite/all/forever
>>>
 in the geode/geode-native code.


 In looking at the code, we see an example function,


 setRetryAttempts
 ()
 [1] currently -1 means try all servers before failing. 0 means try 1

>>> server
>>>
 before failing, and a number greater than 0 means try number of servers

>>> +1
>>>
 before failing. In the case of setRetryAttempts, we don’t know how many
 servers there are. This means that -1 for "All" servers has no relation

>>> to
>>>
 the actual number of servers that we have. Perhaps setRetryAttempts
 could
 be renamed to setNumberOfAttempts to clarify as well, but the problem

>>> still
>>>
 stands...


 *Discussion:*


 In an attempt to provide the best code possible to the geode community,
 there has been some discussion of the use of infinite/all/forever as an
 overload of a count. Often -1 indicates infinite, while 0 indicates

>>> never,
>>>
 and 1 to MAXINT, inclusive, indicates a count.


 There are three obvious approaches to solve the problem of the

>>> overloading
>>>
 of -1. The first approach is do nothing… Status quo.


 The second approach to clarify things would be to create an enumeration
 that would be passed in as well as the number or an object..


 struct Retries

 {

typedef enum { eINFINITE, eCOUNT, eNONE} eCount;

eCount approach;

unsigned int count;

 };



 The third approach would be to pass a continue object of some sort such
 that it tells you if it is ok to continue through the use of an

>>> algorithm.
>>>

 An example would be


 class Continue

 {

 virtual bool Continue() = 0;

 }


 class InfiniteContinue : public Continue

 {

 bool Continue()

 {

 return true;

 }

 }


 Continue co = InfiniteContinue;


 while( co.Continue() )

 {

 //do a thing

 }


 Another example would be a Continue limited to 5 let’s say,


 class CountContinue : public Continue

 {

 private:

 int count;


 public:

 CountContinue(int count)

 {
>>

Re: Review Request 62002: GEODE-3539: Add tests for List Members and Describe Member

[Jared Stewart]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/62002/
---

(Updated Aug. 31, 2017, 4:20 p.m.)


Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, Kirk Lund, and 
Patrick Rhomberg.


Repository: geode


Description
---

GEODE-3539: Add tests for List Members and Describe Member


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ListMemberCommand.java
 ea88c69 
  
geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/MemberCommandsController.java
 ba5c788 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DescribeMembersCommandDUnitTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ListMembersCommandDUnitTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/MemberCommandsDUnitTest.java
 fe6bc40 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/TestCommand.java
 17719be 


Diff: https://reviews.apache.org/r/62002/diff/2/

Changes: https://reviews.apache.org/r/62002/diff/1-2/


Testing
---

Precheckin running


Thanks,

Jared Stewart

Re: Review Request 62002: GEODE-3539: Add tests for List Members and Describe Member

[Jared Stewart]

> On Aug. 31, 2017, 3:25 p.m., Jinmei Liao wrote:
> > geode-core/src/main/java/org/apache/geode/management/internal/cli/result/CommandResult.java
> > Lines 632 (patched)
> > 
> >
> > See Gfsh.handleExecutionResult
> > 
> > any chance this could be called before gfsh gets the result for 
> > display? If so, then gfsh will display nothing, since hasNextLine() will 
> > return false from now on. Maybe for now just add a comment there saying 
> > only call this after gfsh displays the result already. The whole gfsh 
> > result displayer is a mess for now.
> 
> Jared Stewart wrote:
> I only intended to use this method from tests and I think in that case 
> there should always be a result.  I thought about adding it to some sort of 
> helper/utility class (currently it resides in CliCommandTestBase), but it 
> seems like it makes sense for it to live in CommandResult.  I'll add a 
> comment with some explanation of how it should be used.
> 
> Jinmei Liao wrote:
> Currently, without this function, I get the command result string using 
> gfshRule.getoutputString method

Oh, I hadn't noticed that method.  I will use that for now instead.


- Jared


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/62002/#review184275
---


On Aug. 30, 2017, 10:13 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62002/
> ---
> 
> (Updated Aug. 30, 2017, 10:13 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, Kirk Lund, 
> and Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-3539: Add tests for List Members and Describe Member
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ListMemberCommand.java
>  ea88c69ebdd2ce5ffbab486fcb7a4dda71935586 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/result/CommandResult.java
>  bbb59d0755ffd2cf405f78c89b420a5279844e29 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/MemberCommandsController.java
>  ba5c788f90ef68dc8ac338a4619646b4f3608293 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DescribeMembersCommandDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ListMembersCommandDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/MemberCommandsDUnitTest.java
>  fe6bc404d33b48e5384348241c17ccf924f4627c 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/TestCommand.java
>  17719be16338ab9894878660054b75ff9cc6c3ec 
> 
> 
> Diff: https://reviews.apache.org/r/62002/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin running
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

Re: Review Request 62002: GEODE-3539: Add tests for List Members and Describe Member

[Jinmei Liao]

> On Aug. 31, 2017, 3:25 p.m., Jinmei Liao wrote:
> > geode-core/src/main/java/org/apache/geode/management/internal/cli/result/CommandResult.java
> > Lines 632 (patched)
> > 
> >
> > See Gfsh.handleExecutionResult
> > 
> > any chance this could be called before gfsh gets the result for 
> > display? If so, then gfsh will display nothing, since hasNextLine() will 
> > return false from now on. Maybe for now just add a comment there saying 
> > only call this after gfsh displays the result already. The whole gfsh 
> > result displayer is a mess for now.
> 
> Jared Stewart wrote:
> I only intended to use this method from tests and I think in that case 
> there should always be a result.  I thought about adding it to some sort of 
> helper/utility class (currently it resides in CliCommandTestBase), but it 
> seems like it makes sense for it to live in CommandResult.  I'll add a 
> comment with some explanation of how it should be used.

Currently, without this function, I get the command result string using 
gfshRule.getoutputString method


- Jinmei


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/62002/#review184275
---


On Aug. 30, 2017, 10:13 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62002/
> ---
> 
> (Updated Aug. 30, 2017, 10:13 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, Kirk Lund, 
> and Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-3539: Add tests for List Members and Describe Member
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ListMemberCommand.java
>  ea88c69ebdd2ce5ffbab486fcb7a4dda71935586 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/result/CommandResult.java
>  bbb59d0755ffd2cf405f78c89b420a5279844e29 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/MemberCommandsController.java
>  ba5c788f90ef68dc8ac338a4619646b4f3608293 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DescribeMembersCommandDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ListMembersCommandDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/MemberCommandsDUnitTest.java
>  fe6bc404d33b48e5384348241c17ccf924f4627c 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/TestCommand.java
>  17719be16338ab9894878660054b75ff9cc6c3ec 
> 
> 
> Diff: https://reviews.apache.org/r/62002/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin running
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

Re: Review Request 62002: GEODE-3539: Add tests for List Members and Describe Member

[Jared Stewart]

> On Aug. 31, 2017, 3:25 p.m., Jinmei Liao wrote:
> > geode-core/src/main/java/org/apache/geode/management/internal/cli/result/CommandResult.java
> > Lines 632 (patched)
> > 
> >
> > See Gfsh.handleExecutionResult
> > 
> > any chance this could be called before gfsh gets the result for 
> > display? If so, then gfsh will display nothing, since hasNextLine() will 
> > return false from now on. Maybe for now just add a comment there saying 
> > only call this after gfsh displays the result already. The whole gfsh 
> > result displayer is a mess for now.

I only intended to use this method from tests and I think in that case there 
should always be a result.  I thought about adding it to some sort of 
helper/utility class (currently it resides in CliCommandTestBase), but it seems 
like it makes sense for it to live in CommandResult.  I'll add a comment with 
some explanation of how it should be used.


- Jared


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/62002/#review184275
---


On Aug. 30, 2017, 10:13 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62002/
> ---
> 
> (Updated Aug. 30, 2017, 10:13 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, Kirk Lund, 
> and Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-3539: Add tests for List Members and Describe Member
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ListMemberCommand.java
>  ea88c69ebdd2ce5ffbab486fcb7a4dda71935586 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/result/CommandResult.java
>  bbb59d0755ffd2cf405f78c89b420a5279844e29 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/MemberCommandsController.java
>  ba5c788f90ef68dc8ac338a4619646b4f3608293 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DescribeMembersCommandDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ListMembersCommandDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/MemberCommandsDUnitTest.java
>  fe6bc404d33b48e5384348241c17ccf924f4627c 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/TestCommand.java
>  17719be16338ab9894878660054b75ff9cc6c3ec 
> 
> 
> Diff: https://reviews.apache.org/r/62002/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin running
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

Re: Geode Native Client date format

[Udo Kohlmeyer]

Hi there Robert,

As  Juan has indicated, the JSONFormatter is responsible for the 
conversion. Unfortunately, the current behavior is an all-or-nothing 
approach. Meaning if we change the formatter to convert data string with 
Date + Time, then all date fields have to contain time.


Which in some cases, is not the expected behavior.

We are thinking about ways to improve this behavior and make the 
conversion more adaptive and maybe configurable per JSON message. But 
this still has some way to go.


In the mean time, you could maybe try and convert the date into a long. 
That way you hold on to the time accuracy.


--Udo

On 8/31/17 01:39, Juan José Ramos wrote:

Hello Robert,

The *JSONFormatter* class, used internally in Geode to handle REST
requests/responses, supports only "MM/DD/" dates, with no HH:MM:SS;
while PDX supports all date fields, that's the reason why you see the
difference in the output.
There's already a GEODE ticket created for this: GEODE-226. You might want
to add yourself as watcher to get updates about the progress.
Hope this helps.
Best regards.


On Thu, Aug 31, 2017 at 9:33 AM, Rupert St John Webster <
rup...@impress-solutions.com> wrote:


Sorry, I can now see in Pulse that a dateTime format is stored as for
example: Thu Aug 31 09:29:25 BST 2017

The problem is when the REST API does a GET for the value stored, it is
being returned as DD/MM/ only

Any ideas? Thanks 😊

From: Rupert St John Webster
Sent: 31 August 2017 09:23
To: dev@geode.apache.org
Subject: Geode Native Client date format

Hi,

The PDX writer has a writeDate method. This results in a PDX date in
DD/MM/ format. I’m looking for HH.MM.SS.fff as well but can’t find a
way to do that?

Kind regards,

Build failed in Jenkins: Geode-release #85

[Apache Jenkins Server]

See 


Changes:

[bschuchardt] GEODE-3249 Validate internal client/server messages

--
[...truncated 52.28 KB...]
:extensions/geode-modules-session:signArchives SKIPPED
:extensions/geode-modules-session:assemble
:extensions/geode-modules-assembly:distAppServer
:extensions/geode-modules-tomcat7:compileJava
:extensions/geode-modules-tomcat7:processResources UP-TO-DATE
:extensions/geode-modules-tomcat7:classes
:extensions/geode-modules-tomcat7:jar
:extensions/geode-modules-tomcat7:javadoc
:extensions/geode-modules-tomcat7:javadocJar
:extensions/geode-modules-tomcat7:sourcesJar
:extensions/geode-modules-tomcat7:signArchives SKIPPED
:extensions/geode-modules-tomcat7:assemble
:extensions/geode-modules-tomcat8:compileJava
:extensions/geode-modules-tomcat8:processResources UP-TO-DATE
:extensions/geode-modules-tomcat8:classes
:extensions/geode-modules-tomcat8:jar
:extensions/geode-modules-tomcat8:javadoc
:extensions/geode-modules-tomcat8:javadocJar
:extensions/geode-modules-tomcat8:sourcesJar
:extensions/geode-modules-tomcat8:signArchives SKIPPED
:extensions/geode-modules-tomcat8:assemble
:extensions/geode-modules-assembly:distTcServer
:extensions/geode-modules-assembly:distTcServer30
:extensions/geode-modules-assembly:distTomcat
:extensions/geode-modules-assembly:dist
:extensions/geode-modules-assembly:build
:extensions/geode-modules-assembly:distributedTest UP-TO-DATE
:extensions/geode-modules-assembly:integrationTest UP-TO-DATE
:extensions/geode-modules-session:compileTestJavaNote: 

 uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.

:extensions/geode-modules-session:processTestResources
:extensions/geode-modules-session:testClasses
:extensions/geode-modules-session:checkMissedTests
:extensions/geode-modules-session:spotlessJavaCheck
:extensions/geode-modules-session:spotlessCheck
:extensions/geode-modules-session:test
:extensions/geode-modules-session:check
:extensions/geode-modules-session:build
:extensions/geode-modules-session:distributedTest
:extensions/geode-modules-session:integrationTest
:extensions/geode-modules-session-internal:javadocJar
:extensions/geode-modules-session-internal:sourcesJar
:extensions/geode-modules-session-internal:signArchives SKIPPED
:extensions/geode-modules-session-internal:assemble
:extensions/geode-modules-session-internal:compileTestJava UP-TO-DATE
:extensions/geode-modules-session-internal:processTestResources UP-TO-DATE
:extensions/geode-modules-session-internal:testClasses UP-TO-DATE
:extensions/geode-modules-session-internal:checkMissedTests UP-TO-DATE
:extensions/geode-modules-session-internal:spotlessJavaCheck
:extensions/geode-modules-session-internal:spotlessCheck
:extensions/geode-modules-session-internal:test UP-TO-DATE
:extensions/geode-modules-session-internal:check
:extensions/geode-modules-session-internal:build
:extensions/geode-modules-session-internal:distributedTest UP-TO-DATE
:extensions/geode-modules-session-internal:integrationTest UP-TO-DATE
:extensions/geode-modules-tomcat7:compileTestJava
:extensions/geode-modules-tomcat7:processTestResources
:extensions/geode-modules-tomcat7:testClasses
:extensions/geode-modules-tomcat7:checkMissedTests
:extensions/geode-modules-tomcat7:spotlessJavaCheck
:extensions/geode-modules-tomcat7:spotlessCheck
:extensions/geode-modules-tomcat7:test
:extensions/geode-modules-tomcat7:check
:extensions/geode-modules-tomcat7:build
:extensions/geode-modules-tomcat7:distributedTest
:extensions/geode-modules-tomcat7:integrationTest
:extensions/geode-modules-tomcat8:compileTestJavaNote: 

 uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.

:extensions/geode-modules-tomcat8:processTestResources
:extensions/geode-modules-tomcat8:testClasses
:extensions/geode-modules-tomcat8:checkMissedTests
:extensions/geode-modules-tomcat8:spotlessJavaCheck
:extensions/geode-modules-tomcat8:spotlessCheck
:extensions/geode-modules-tomcat8:test
:extensions/geode-modules-tomcat8:check
:extensions/geode-modules-tomcat8:build
:extensions/geode-modules-tomcat8:distributedTest
:extensions/geode-modules-tomcat8:integrationTest
:geode-assembly:compileJava UP-TO-DATE
:geode-assembly:processResources UP-TO-DATE
:geode-assembly:classes UP-TO-DATE
:geode-assembly:defaultCacheConfig
:geode-assembly:defaultDistributionConfig
:geode-assembly:depsJar
:geode-benchmarks:compileJava UP-TO-DATE
:geode-benchmarks:processResources UP-TO-DATE
:geode-benchmarks:classes UP-TO-DATE
:geode-cq:compileJavaNote: Some input files use or override a deprecated API.
Note: Recompile with -X

Re: Review Request 62002: GEODE-3539: Add tests for List Members and Describe Member

[Jinmei Liao]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/62002/#review184275
---




geode-core/src/main/java/org/apache/geode/management/internal/cli/result/CommandResult.java
Lines 632 (patched)


See Gfsh.handleExecutionResult

any chance this could be called before gfsh gets the result for display? If 
so, then gfsh will display nothing, since hasNextLine() will return false from 
now on. Maybe for now just add a comment there saying only call this after gfsh 
displays the result already. The whole gfsh result displayer is a mess for now.


- Jinmei Liao


On Aug. 30, 2017, 10:13 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62002/
> ---
> 
> (Updated Aug. 30, 2017, 10:13 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, Kirk Lund, 
> and Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-3539: Add tests for List Members and Describe Member
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ListMemberCommand.java
>  ea88c69ebdd2ce5ffbab486fcb7a4dda71935586 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/result/CommandResult.java
>  bbb59d0755ffd2cf405f78c89b420a5279844e29 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/MemberCommandsController.java
>  ba5c788f90ef68dc8ac338a4619646b4f3608293 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DescribeMembersCommandDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ListMembersCommandDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/MemberCommandsDUnitTest.java
>  fe6bc404d33b48e5384348241c17ccf924f4627c 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/TestCommand.java
>  17719be16338ab9894878660054b75ff9cc6c3ec 
> 
> 
> Diff: https://reviews.apache.org/r/62002/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin running
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

[Bruce Schuchardt]

Does anyone have a good argument for clients retrying operations?  I can 
see doing that if the server has died but otherwise it just overloads 
the servers.




On 8/30/17 8:36 PM, Dan Smith wrote:

In general, I think we need making the configuration of geode less complex,
not more.

As far as retry-attempts goes, maybe the best thing to do is to get rid of
it. The P2P layer has no such concept. I don't think users should really
have to care about how many servers an operation is attempted against. A
user may want to specify how long an operation is allowed to take, but that
could be better specified with an operation timeout rather than the current
read-timeout + retry-attempts.

-Dan



On Wed, Aug 30, 2017 at 2:08 PM, Patrick Rhomberg 
wrote:


Personally, I don't much like sentinel values, even if they have their
occasional use.

Do we need to provide an authentic infinite value?  64-bit MAXINT is nearly
10 quintillion.  At 10GHz, that still takes almost three years.  If each
retry takes as much as 10ms, we're still looking at "retry for as long as
the earth has existed."  32-bit's is much more attainable, of course, but I
think the point stands -- if you need to retry that much, something else is
very wrong.

In the more general sense, I struggle to think of a context where an
authentic infinity is meaningfully distinct in application from a massive
finite like MAXINT.  But I could be wrong and would love to hear what other
people think.

On Wed, Aug 30, 2017 at 1:26 PM, Mark Hanson  wrote:


Hi All,


*Question: how should we deal in a very forward and clean fashion with

the

implicit ambiguity of -1 or all, or infinite, or forever?*


*Background:*


We are looking to get some feedback on the subject of

infinite/all/forever

in the geode/geode-native code.


In looking at the code, we see an example function,


setRetryAttempts
()
[1] currently -1 means try all servers before failing. 0 means try 1

server

before failing, and a number greater than 0 means try number of servers

+1

before failing. In the case of setRetryAttempts, we don’t know how many
servers there are. This means that -1 for "All" servers has no relation

to

the actual number of servers that we have. Perhaps setRetryAttempts could
be renamed to setNumberOfAttempts to clarify as well, but the problem

still

stands...


*Discussion:*


In an attempt to provide the best code possible to the geode community,
there has been some discussion of the use of infinite/all/forever as an
overload of a count. Often -1 indicates infinite, while 0 indicates

never,

and 1 to MAXINT, inclusive, indicates a count.


There are three obvious approaches to solve the problem of the

overloading

of -1. The first approach is do nothing… Status quo.


The second approach to clarify things would be to create an enumeration
that would be passed in as well as the number or an object..


struct Retries

{

   typedef enum { eINFINITE, eCOUNT, eNONE} eCount;

   eCount approach;

   unsigned int count;

};



The third approach would be to pass a continue object of some sort such
that it tells you if it is ok to continue through the use of an

algorithm.


An example would be


class Continue

{

virtual bool Continue() = 0;

}


class InfiniteContinue : public Continue

{

bool Continue()

{

return true;

}

}


Continue co = InfiniteContinue;


while( co.Continue() )

{

//do a thing

}


Another example would be a Continue limited to 5 let’s say,


class CountContinue : public Continue

{

private:

int count;


public:

CountContinue(int count)

{

this.count = count;

}

bool Continue()

{

   return count— > 0;

}

}


In both of these cases what is happening is that the algorithm is being
outsourced.


*Conclusion:*


We are putting this out, to start a discussion on the best way to move

this

forward… *What do people think? What direction would be the best going
forward?*


[1]
https://github.com/apache/geode-native/blob/

006df0e70eeb481ef5e9e821dba005

0dee9c6893/cppcache/include/geode/PoolFactory.hpp#L327

Re: Review Request 62001: GEODE-3525: Dockerize AcceptanceTests

[Jinmei Liao]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/62001/#review184274
---


Ship it!




Ship It!

- Jinmei Liao


On Aug. 30, 2017, 10 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62001/
> ---
> 
> (Updated Aug. 30, 2017, 10 p.m.)
> 
> 
> Review request for geode, Anthony Baker, Jens Deppe, Jinmei Liao, Jared 
> Stewart, Ken Howe, Kirk Lund, and Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-3525: Dockerize AcceptanceTests
> 
> 
> Diffs
> -
> 
>   gradle/docker.gradle b5a356f6222848f672261cf0050c02044b3c112e 
> 
> 
> Diff: https://reviews.apache.org/r/62001/diff/1/
> 
> 
> Testing
> ---
> 
> Passed precheckin, both with and without the -PparallelDUnit flag set.
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

Re: Review Request 62001: GEODE-3525: Dockerize AcceptanceTests

[Jens Deppe]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/62001/#review184271
---


Ship it!




Ship It!

- Jens Deppe


On Aug. 30, 2017, 10 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62001/
> ---
> 
> (Updated Aug. 30, 2017, 10 p.m.)
> 
> 
> Review request for geode, Anthony Baker, Jens Deppe, Jinmei Liao, Jared 
> Stewart, Ken Howe, Kirk Lund, and Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-3525: Dockerize AcceptanceTests
> 
> 
> Diffs
> -
> 
>   gradle/docker.gradle b5a356f6222848f672261cf0050c02044b3c112e 
> 
> 
> Diff: https://reviews.apache.org/r/62001/diff/1/
> 
> 
> Testing
> ---
> 
> Passed precheckin, both with and without the -PparallelDUnit flag set.
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

[DISCUSS] Bug while parsing the JSON "key which having short data type" in locate command "https://github.com/apache/geode/pull/752"

[Dinesh Akhand]

Hi,



I have created the pull request for the same .

https://github.com/apache/geode/pull/752



Jira ticket GEODE-3544.



Case 1)



Short data type is getting converted into integer &  geode is looking for set 
method  with integer

And it throws the exception.



So I am converting the value with parameterType  using ConvertUtils.convert 
which solve the problem for all primitive/wrapper type

Example 2)

 If key data type in short i =5

  It will look for method  seti(integer )

Case 2) If key having the base class it check only key class set method .



So I change getDeclaredMethods to getMethods()





Thanks,

Dinesh Akhand



-Original Message-
From: Dinesh Akhand
Sent: Monday, August 28, 2017 5:46 PM
To: dev@geode.apache.org
Subject: Bug while parsing the JSON "key which having short data type" in 
locate command



Hi Team,



I have found one bug in geode 1.2 .



If in the key we having the short data type



Example:



public class EmpData  implements Serializable{ private short empid;



public short getEmpid() {

   return empid;

}



public void setEmpid(short empid) {

   this.empid = empid;

}





EmpData d1 = new EmpData();

D1. setEmpid((short)1);



Region.put(d1,"value1");



Now try locate command on this .





Problem in code: file JSONTokener.java. it always return short to int value



try {

long longValue = Long.parseLong(number, base);

if(longValue <= Short.MAX_VALUE && longValue >= Short.MIN_VALUE)

{

 return (short) longValue;

}

else if (longValue <= Integer.MAX_VALUE && longValue >= 
Integer.MIN_VALUE) {

  return (int) longValue;

} else {

  return longValue;

}



Later it cause the problem of java.lang.IllegalArgumentException: argument type 
mismatch.

locate entry --key=--key=('empid ':1) --region=CUSTOMER_1



alternate way :  changes the  DataCommandFunctionJUnitTest.java changes the 
testLocateKeyIsObject method



due to same problem, we are facing problem with all commands where we usage the 
key.



Thanks,

Dinesh Akhand





This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,



you may review at https://www.amdocs.com/about/email-disclaimer 

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 

[GitHub] geode pull request #752: GEODE-3544

[dineshakhand]

GitHub user dineshakhand opened a pull request:

https://github.com/apache/geode/pull/752

GEODE-3544

JSON parsing failed for short data type & base class setting is not used
when key having base class

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ X] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [ X] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [ X] Is your initial contribution a single, squashed commit?

- [ X] Does `gradlew build` run cleanly?

- [ X] Have you written or updated unit tests to verify your changes?

- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to dev@geode.apache.org.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dineshakhand/geode feature/GEODE-3544

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/752.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #752


commit 2874f5f3f0429a9e40f4baa41727d14f74034844
Author: dineshpune2006 
Date:   2017-08-31T13:18:36Z

GEODE-3544

JSON parsing failed for short data type & base class setting is not used
when key having base class




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode pull request #751: GEODE-2719 : Deprecated setTotalMaxMemory and getTo...

[ameybarve15]

GitHub user ameybarve15 opened a pull request:

https://github.com/apache/geode/pull/751

GEODE-2719 : Deprecated setTotalMaxMemory and getTotalMaxMemory and updated 
their javadocs.

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [X] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [X] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [ ] Is your initial contribution a single, squashed commit?

- [X] Does `gradlew build` run cleanly?

- [ ] Have you written or updated unit tests to verify your changes?

- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to dev@geode.apache.org.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ameybarve15/incubator-geode feature/GEODE-2719

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/751.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #751


commit f605e26aaf3d3d667dcc2911c5bd944c41d4512f
Author: Amey Barve 
Date:   2017-08-31T10:08:08Z

GEODE-2719: Deprecated setTotalMaxMemory and getTotalMaxMemory and
updated their javadocs.

commit 303bb99a2af9e72f91be0163f8f3dce0ec2dffde
Author: Amey Barve 
Date:   2017-08-31T12:06:54Z

GEODE-2719: corrected GEODE versions to 1.3.0 instead of 1.2.2 for the
respective deprecated API javadocs.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Geode Native Client date format

[Juan José Ramos]

Hello Robert,

The *JSONFormatter* class, used internally in Geode to handle REST
requests/responses, supports only "MM/DD/" dates, with no HH:MM:SS;
while PDX supports all date fields, that's the reason why you see the
difference in the output.
There's already a GEODE ticket created for this: GEODE-226. You might want
to add yourself as watcher to get updates about the progress.
Hope this helps.
Best regards.


On Thu, Aug 31, 2017 at 9:33 AM, Rupert St John Webster <
rup...@impress-solutions.com> wrote:

> Sorry, I can now see in Pulse that a dateTime format is stored as for
> example: Thu Aug 31 09:29:25 BST 2017
>
> The problem is when the REST API does a GET for the value stored, it is
> being returned as DD/MM/ only
>
> Any ideas? Thanks 😊
>
> From: Rupert St John Webster
> Sent: 31 August 2017 09:23
> To: dev@geode.apache.org
> Subject: Geode Native Client date format
>
> Hi,
>
> The PDX writer has a writeDate method. This results in a PDX date in
> DD/MM/ format. I’m looking for HH.MM.SS.fff as well but can’t find a
> way to do that?
>
> Kind regards,
>



-- 
Juan José Ramos Cassella
Senior Technical Support Engineer
Email: jra...@pivotal.io
Office#: +353 21 4238611
Mobile#: +353 87 2074066
After Hours Contact#: +1 877 477 2269
Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
How to upload artifacts:
https://support.pivotal.io/hc/en-us/articles/204369073
How to escalate a ticket:
https://support.pivotal.io/hc/en-us/articles/203809556

[image: support]  [image: twitter]
 [image: linkedin]
 [image: facebook]
 [image: google plus]
 [image: youtube]

RE: Geode Native Client date format

[Rupert St John Webster]

Sorry, I can now see in Pulse that a dateTime format is stored as for example: 
Thu Aug 31 09:29:25 BST 2017

The problem is when the REST API does a GET for the value stored, it is being 
returned as DD/MM/ only

Any ideas? Thanks 😊

From: Rupert St John Webster
Sent: 31 August 2017 09:23
To: dev@geode.apache.org
Subject: Geode Native Client date format

Hi,

The PDX writer has a writeDate method. This results in a PDX date in DD/MM/ 
format. I’m looking for HH.MM.SS.fff as well but can’t find a way to do that?

Kind regards,