RE: Geode Native Client date format

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:

Re: Geode Native Client date format

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:

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

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

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

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 or

[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

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

--- 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., Ja

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

--- 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., J

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

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 re

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

--- 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

Build failed in Jenkins: Geode-release #85

See Changes: [bschuchardt] GEODE-3249 Validate internal client/server messages -- [...truncated 52.28 KB...] :extensions/geode-modules-session:signArchives SKIPPED :extensions/

Re: Geode Native Client date format

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 som

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

> 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

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

> 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

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

> 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

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

--- 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

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

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

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

--- 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.,

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

+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

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

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 th

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

See

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

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 underst

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

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

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

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 a

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

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 obje

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

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

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

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 c

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

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:

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

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

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

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::chr

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

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 develope

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

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

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

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 t

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

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 expor

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

--- 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 P

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

--- 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 Pat

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

--- 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.,

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

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.

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

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 b

Build failed in Jenkins: Geode-nightly #940

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

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

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

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

--- 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

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

--- Spring Data GemFire > Nightly-ApacheGeode > #664 was successful. --- Scheduled 2029 tests in total. https://build.spring.io/browse/SGF-NAG-664/ -- This

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

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-det

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

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 c

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

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 requ

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

See Changes: [jstewart] GEODE-3525: Dockerize AcceptanceTests -- [...truncated 111.60 KB...] :geode-lucene:javadocJar :geode-lucene:sourcesJar :geode-lucene:signArchives

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

--- 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 S

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

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 l

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

See