[GitHub] geode issue #344: Fix the Native Client Build on Ubuntu

[davinash]

Github user davinash commented on the issue:

https://github.com/apache/geode/pull/344
  
Thanks @pivotal-jbarrett , I have handled review comments, tested on Ubuntu 
and CentOS.


---
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: New PMC Member: Ken Howe

[Michael Stolz]

Welcome Ken. Thanks for joining us.

--
Mike Stolz
Principal Engineer - Gemfire Product Manager
Mobile: 631-835-4771
On Jan 18, 2017 9:52 PM, "Mark Bretl"  wrote:

> The Apache Geode Project Management Committee has invited Ken Howe to join
> the Geode PMC. We are pleased to announce he has accepted.
>
> Please join me in welcoming Ken!
>
> Sincerely,
>
> Mark Bretl
> On behalf of the Apache Geode PMC
>

[GitHub] geode-examples pull request #2: Build updates for examples

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/geode-examples/pull/2


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

[jira] [Resolved] (GEODE-2318) Improve geode-examples build

[Anthony Baker (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anthony Baker resolved GEODE-2318.
--
Resolution: Fixed

> Improve geode-examples build
> 
>
> Key: GEODE-2318
> URL: https://issues.apache.org/jira/browse/GEODE-2318
> Project: Geode
>  Issue Type: Bug
>  Components: build
>Reporter: Anthony Baker
>
> Since the geode-examples have been moved to a new repo, the source tree and 
> build need some enhancements:
> - LICENSE, NOTICE, and KEYS files
> - {{.gitignore}} stuff
> - travis CI configuration
> - build enhancements for releasing source artfifacts
> - build enhancements to automatically download a geode distribution for 
> testing



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

JIRA versions and multiple repos

[Anthony Baker]

Currently our JIRA versions look like this:

1.0.0-incubating.M1
1.0.0-incubating.M2
1.0.0-incubating.M3
1.1.0

That works great for the geode repo.  However, what about the geode-examples 
repo?  I would like to set a ‘Fix version’ that matches the version in [1].  
Since the repos can release independently of each other, I think we need a way 
to completely disambiguate versions like ‘geode-examples-0.1’.  We could also 
ask for a JIRA project for each repo.  Thoughts?

More stuff:

- GEODE-2318 didn’t get updated with commit logs from geode-examples.  Anyone 
know how to fix this?
- Travis-CI is now running on geode-examples.  If you notice problems with PR’s 
or email notifications let me know.

Anthony

[1] https://github.com/apache/geode-examples/blob/develop/gradle.properties#L17

Re: backward-compatibility testing

[Anthony Baker]

> On Jan 18, 2017, at 3:11 PM, Bruce Schuchardt  wrote:
> 
> I've extended the distributedTest framework to let us do 
> backward-compatibility testing.  Once it is reviewed and committed people 
> will be needed to modify existing tests to run against multiple versions of 
> Geode.
> 
> Here is the RB review: https://reviews.apache.org/r/55688/
> 
> The diff in this review includes a client/server test modified to run against 
> multiple versions.  Basically you just need to parameterize an existing 
> distributedTest case to run against multiple versions using 
> Host.getHost(0).getVM(testVersion, vmNumber).  That give you a JVM that's set 
> up to use the requested version.  You can then use the normal method/lambda 
> invocation methods to run code in that JVM.
> 
> Currently version "100" (1.0.0-incubating) is available for 
> backward-compatibility testing.  Versions to be tested are configured in 
> geode-old-versions/build.gradle as source-sets. Adding a new version is 
> trivial.

Since this was the last issue we called out for releasing geode 1.1.0, I think 
we should move ahead with adding this framework and the current set of tests.  
Over time we can (and should) extend the tests, particularly to validate 
rolling upgrades.

Thanks Bruce!

Anthony

Re: JIRA versions and multiple repos

[John Blum]

On a slightly separate, but related note...

One way of handling differing versions between potentially independently
releasable artifacts/modules is to create a Maven BOM file.

geode-examples are one thing, but when Geode becomes truly modular (in a
sense that naturally bounded modules... Core, Querying/Indexing,
Persistence, Client/Server, Native Client, WAN, etc) with independently
releasable components having separate artifacts and release schedules, then
using a Maven BOM with a "symbolic" version name to coordinate the curated,
harmonized and complete set of versions is the easiest, most convenient and
familiar way to handle this.

These "symbolic" versions could then be used in JIRA as well, which might
actually have more meaning in the sense that it forms unity with other
seemingly unrelated "by version number" components.

A few examples...

[1] https://github.com/spring-projects/spring-data-build/
blob/master/bom/pom.xml
[2] https://github.com/spring-io/platform/blob/master/platform-bom/pom.xml
[3] https://github.com/reactor/reactor

Food for thought...

-j

On Thu, Jan 19, 2017 at 7:55 AM, Anthony Baker  wrote:

> Currently our JIRA versions look like this:
>
> 1.0.0-incubating.M1
> 1.0.0-incubating.M2
> 1.0.0-incubating.M3
> 1.1.0
>
> That works great for the geode repo.  However, what about the
> geode-examples repo?  I would like to set a ‘Fix version’ that matches the
> version in [1].  Since the repos can release independently of each other, I
> think we need a way to completely disambiguate versions like
> ‘geode-examples-0.1’.  We could also ask for a JIRA project for each repo.
> Thoughts?
>
> More stuff:
>
> - GEODE-2318 didn’t get updated with commit logs from geode-examples.
> Anyone know how to fix this?
> - Travis-CI is now running on geode-examples.  If you notice problems with
> PR’s or email notifications let me know.
>
> Anthony
>
> [1] https://github.com/apache/geode-examples/blob/develop/
> gradle.properties#L17
>
>


-- 
-John
john.blum10101 (skype)

Re: backward-compatibility testing

[Dan Smith]

+1 This is great Bruce! I really like this approach of being able to write
tests and have them run with some members with a different version. I think
with this framework we should be able to just extend existing tests with
subclasses that override the version of some of the VMs which I think is a
good way to do the backwards compatibility testing.

One question - you modified the locator to allow old versions to join. Why
was that necessary? I know we broke P2P compatibility between gemfire 8 and
geode 1.0, but are we not allowing P2P compatibility going forward? I was
under the impression that 1.1 was going to be compatible with 1.0. Is that
not the case? Why do the tests need to have peers with different versions
if we are not supporting that? Is there a way we can do these tests without
having the product code behave differently when it is being tested than
when it is being used normally?

-Dan



On Wed, Jan 18, 2017 at 3:11 PM, Bruce Schuchardt 
wrote:

> I've extended the distributedTest framework to let us do
> backward-compatibility testing.  Once it is reviewed and committed people
> will be needed to modify existing tests to run against multiple versions of
> Geode.
>
> Here is the RB review: https://reviews.apache.org/r/55688/
>
> The diff in this review includes a client/server test modified to run
> against multiple versions.  Basically you just need to parameterize an
> existing distributedTest case to run against multiple versions using
> Host.getHost(0).getVM(testVersion, vmNumber).  That give you a JVM that's
> set up to use the requested version.  You can then use the normal
> method/lambda invocation methods to run code in that JVM.
>
> Currently version "100" (1.0.0-incubating) is available for
> backward-compatibility testing.  Versions to be tested are configured in
> geode-old-versions/build.gradle as source-sets. Adding a new version is
> trivial.
>

Re: JIRA versions and multiple repos

[Udo Kohlmeyer]

+1 sounds good


On 1/19/17 09:02, John Blum wrote:

On a slightly separate, but related note...

One way of handling differing versions between potentially independently
releasable artifacts/modules is to create a Maven BOM file.

geode-examples are one thing, but when Geode becomes truly modular (in a
sense that naturally bounded modules... Core, Querying/Indexing,
Persistence, Client/Server, Native Client, WAN, etc) with independently
releasable components having separate artifacts and release schedules, then
using a Maven BOM with a "symbolic" version name to coordinate the curated,
harmonized and complete set of versions is the easiest, most convenient and
familiar way to handle this.

These "symbolic" versions could then be used in JIRA as well, which might
actually have more meaning in the sense that it forms unity with other
seemingly unrelated "by version number" components.

A few examples...

[1] https://github.com/spring-projects/spring-data-build/
blob/master/bom/pom.xml
[2] https://github.com/spring-io/platform/blob/master/platform-bom/pom.xml
[3] https://github.com/reactor/reactor

Food for thought...

-j

On Thu, Jan 19, 2017 at 7:55 AM, Anthony Baker  wrote:


Currently our JIRA versions look like this:

1.0.0-incubating.M1
1.0.0-incubating.M2
1.0.0-incubating.M3
1.1.0

That works great for the geode repo.  However, what about the
geode-examples repo?  I would like to set a ‘Fix version’ that matches the
version in [1].  Since the repos can release independently of each other, I
think we need a way to completely disambiguate versions like
‘geode-examples-0.1’.  We could also ask for a JIRA project for each repo.
Thoughts?

More stuff:

- GEODE-2318 didn’t get updated with commit logs from geode-examples.
Anyone know how to fix this?
- Travis-CI is now running on geode-examples.  If you notice problems with
PR’s or email notifications let me know.

Anthony

[1] https://github.com/apache/geode-examples/blob/develop/
gradle.properties#L17

Re: JIRA versions and multiple repos

[Roman Shaposhnik]

On Thu, Jan 19, 2017 at 7:55 AM, Anthony Baker  wrote:
> Currently our JIRA versions look like this:
>
> 1.0.0-incubating.M1
> 1.0.0-incubating.M2
> 1.0.0-incubating.M3
> 1.1.0
>
> That works great for the geode repo.  However, what about the geode-examples 
> repo?  I would like to set a ‘Fix version’ that matches the version in [1].  
> Since the repos can release independently of each other, I think we need a 
> way to completely disambiguate versions like ‘geode-examples-0.1’.  We could 
> also ask for a JIRA project for each repo.  Thoughts?
>
> More stuff:
>
> - GEODE-2318 didn’t get updated with commit logs from geode-examples.  Anyone 
> know how to fix this?
> - Travis-CI is now running on geode-examples.  If you notice problems with 
> PR’s or email notifications let me know.

This is the slippery slope I was alluding to. If the repos, releases,
etc. are asynchronous
in the eyes of ASF it strongly suggests that communities are
asynchronous as well. Which
means you're really two separate ASF projects. Which may, very well,
be the case I just
wanted to point it out.

Thanks,
Roman.

Re: JIRA versions and multiple repos

[John Blum]

Not sure if ASF has, or uses the same concept, but this could easily be
handled with a GitHub "organization" encompassing 1 or more repos (for
example... https://github.com/reactor).

Of course, you could organize the source, and in particular, the Geode
"modules" anyway you like, for example, as 1 repo.  It's just more
common/natural to use separate repos for independently releasable
artifacts.  In that way, the community does not seem as fragmented, rather
organized into teams around particular concerns (aka modules/features).
Native Client is perhaps the best example of this since it encompasses
different tools and different languages but with a common "purpose".

More food for thought.

-j


On Thu, Jan 19, 2017 at 9:12 AM, Roman Shaposhnik 
wrote:

> On Thu, Jan 19, 2017 at 7:55 AM, Anthony Baker  wrote:
> > Currently our JIRA versions look like this:
> >
> > 1.0.0-incubating.M1
> > 1.0.0-incubating.M2
> > 1.0.0-incubating.M3
> > 1.1.0
> >
> > That works great for the geode repo.  However, what about the
> geode-examples repo?  I would like to set a ‘Fix version’ that matches the
> version in [1].  Since the repos can release independently of each other, I
> think we need a way to completely disambiguate versions like
> ‘geode-examples-0.1’.  We could also ask for a JIRA project for each repo.
> Thoughts?
> >
> > More stuff:
> >
> > - GEODE-2318 didn’t get updated with commit logs from geode-examples.
> Anyone know how to fix this?
> > - Travis-CI is now running on geode-examples.  If you notice problems
> with PR’s or email notifications let me know.
>
> This is the slippery slope I was alluding to. If the repos, releases,
> etc. are asynchronous
> in the eyes of ASF it strongly suggests that communities are
> asynchronous as well. Which
> means you're really two separate ASF projects. Which may, very well,
> be the case I just
> wanted to point it out.
>
> Thanks,
> Roman.
>



-- 
-John
john.blum10101 (skype)

Re: JIRA versions and multiple repos

[Roman Shaposhnik]

What you're talking about makes sense -- but it is mechanics. What
I'm talking about is a community composition. E.g. if we truly believe
that communities of developers around, lets say core Java Geode
and Native Client are non-overlapping (or there's very little overlap)
we need to recognize this fact by running them as separate ASF
projects. The mechanics will flow from the answering the community
composition question.

Thanks,
Roman.

On Thu, Jan 19, 2017 at 9:20 AM, John Blum  wrote:
> Not sure if ASF has, or uses the same concept, but this could easily be
> handled with a GitHub "organization" encompassing 1 or more repos (for
> example... https://github.com/reactor).
>
> Of course, you could organize the source, and in particular, the Geode
> "modules" anyway you like, for example, as 1 repo.  It's just more
> common/natural to use separate repos for independently releasable
> artifacts.  In that way, the community does not seem as fragmented, rather
> organized into teams around particular concerns (aka modules/features).
> Native Client is perhaps the best example of this since it encompasses
> different tools and different languages but with a common "purpose".
>
> More food for thought.
>
> -j
>
>
> On Thu, Jan 19, 2017 at 9:12 AM, Roman Shaposhnik 
> wrote:
>
>> On Thu, Jan 19, 2017 at 7:55 AM, Anthony Baker  wrote:
>> > Currently our JIRA versions look like this:
>> >
>> > 1.0.0-incubating.M1
>> > 1.0.0-incubating.M2
>> > 1.0.0-incubating.M3
>> > 1.1.0
>> >
>> > That works great for the geode repo.  However, what about the
>> geode-examples repo?  I would like to set a ‘Fix version’ that matches the
>> version in [1].  Since the repos can release independently of each other, I
>> think we need a way to completely disambiguate versions like
>> ‘geode-examples-0.1’.  We could also ask for a JIRA project for each repo.
>> Thoughts?
>> >
>> > More stuff:
>> >
>> > - GEODE-2318 didn’t get updated with commit logs from geode-examples.
>> Anyone know how to fix this?
>> > - Travis-CI is now running on geode-examples.  If you notice problems
>> with PR’s or email notifications let me know.
>>
>> This is the slippery slope I was alluding to. If the repos, releases,
>> etc. are asynchronous
>> in the eyes of ASF it strongly suggests that communities are
>> asynchronous as well. Which
>> means you're really two separate ASF projects. Which may, very well,
>> be the case I just
>> wanted to point it out.
>>
>> Thanks,
>> Roman.
>>
>
>
>
> --
> -John
> john.blum10101 (skype)

Re: backward-compatibility testing

[Bruce Schuchardt]

Thanks Dan.  I'm not sure we want to keep the change I made to the 
Locator.  The restriction on letting old-version members join is for 
rolling upgrade and has been in Geode & GemFire for a long time.  It 
gives us some assurance that we can enable new distributed algorithms 
and stop using old algorithms.  We ran into that requirement when we 
altered distributed locking behavior in GemFire.


If I revert that change it will require that any test starting a peer 
cache using an old version of Geode must create its own old-version 
Locator.  That's probably the best thing to do because the way I have it 
right now might make it very hard to implement new algorithms that 
involve the Locator.  If an old-version peer starts up and the Locator 
sends it a message it doesn't comprehend, or the Locator expects it to 
do something and it doesn't, it could be difficult to deal with.


Le 1/19/2017 à 9:07 AM, Dan Smith a écrit :

+1 This is great Bruce! I really like this approach of being able to write
tests and have them run with some members with a different version. I think
with this framework we should be able to just extend existing tests with
subclasses that override the version of some of the VMs which I think is a
good way to do the backwards compatibility testing.

One question - you modified the locator to allow old versions to join. Why
was that necessary? I know we broke P2P compatibility between gemfire 8 and
geode 1.0, but are we not allowing P2P compatibility going forward? I was
under the impression that 1.1 was going to be compatible with 1.0. Is that
not the case? Why do the tests need to have peers with different versions
if we are not supporting that? Is there a way we can do these tests without
having the product code behave differently when it is being tested than
when it is being used normally?

-Dan



On Wed, Jan 18, 2017 at 3:11 PM, Bruce Schuchardt 
wrote:


I've extended the distributedTest framework to let us do
backward-compatibility testing.  Once it is reviewed and committed people
will be needed to modify existing tests to run against multiple versions of
Geode.

Here is the RB review: https://reviews.apache.org/r/55688/

The diff in this review includes a client/server test modified to run
against multiple versions.  Basically you just need to parameterize an
existing distributedTest case to run against multiple versions using
Host.getHost(0).getVM(testVersion, vmNumber).  That give you a JVM that's
set up to use the requested version.  You can then use the normal
method/lambda invocation methods to run code in that JVM.

Currently version "100" (1.0.0-incubating) is available for
backward-compatibility testing.  Versions to be tested are configured in
geode-old-versions/build.gradle as source-sets. Adding a new version is
trivial.

Re: Review Request 55687: GEODE-2199: be able to deploy jars without running servers

[Kevin Duling]

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


Ship it!




Ship It!

- Kevin Duling


On Jan. 18, 2017, 5:35 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55687/
> ---
> 
> (Updated Jan. 18, 2017, 5:35 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * renamed the CliUtils.findAllMatchingServers to findMembersOrThrow to better 
> describe the behavior
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/CliUtil.java
>  5b9a6bd63350dd753c66fd25e6058ddea45f9325 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ConfigCommands.java
>  5154b75e85a42e6d97f5563effe3a7600369126a 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/CreateAlterDestroyRegionCommands.java
>  7df4112950cefcc1ae18bdd88cb752cdec5b7de1 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DeployCommands.java
>  f076cec670a4c787fbe4002edfdacde4b025d1bf 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
>  14114cff2febf0e1ba7ae67427549ad4fd19ed85 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DurableClientCommands.java
>  053f3ebcc74638f992854cdd96d9c586aa33818a 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/FunctionCommands.java
>  9a9ece952110e90b32e65cbff8ea2319779c4aff 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/IndexCommands.java
>  bc436ba40e107b931e8d0d10082e26cf068dd56b 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/MiscellaneousCommands.java
>  88a9919802f3d32822f20d3a1c8cfcc4ffa5a6c4 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/QueueCommands.java
>  095bd68f54d0f06d9f9439fcaffbca72e49083fc 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/RegionCommands.java
>  78a28d68ea7aa75ab2cda0c01b5a567e3d0d9475 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/WanCommands.java
>  cbf589185e94345be6fd64ebd630f76e84cc2a09 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/CliUtilDUnitTest.java
>  d7d59b71cd54ca23c716e72da413bae6a05e75fd 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfig.java
>  c2d511d1c4d34aea434751c2bb5b7e9b924482ad 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigDeployJarDUnitTest.java
>  51a77d2f4454a772251039a465ab00655a9bea98 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
>  13442fd68ce2855561fc724bf73cd8c21d2317af 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/cli/LuceneIndexCommands.java
>  6a5a1e09c03b9a5362e44fd6fe55a6e6181ea17c 
> 
> Diff: https://reviews.apache.org/r/55687/diff/
> 
> 
> Testing
> ---
> 
> precheckin successful
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Re: Review Request 55532: GEODE-2198: close and re-create the cache on a server when importing new cluster configuration

[Kevin Duling]

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


Ship it!




Ship It!

- Kevin Duling


On Jan. 17, 2017, 3:27 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55532/
> ---
> 
> (Updated Jan. 17, 2017, 3:27 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * When importing cluster config first check if there is any non-empty region
> * close and re-create cache if no data exists when importing new cluster 
> configuration
> * put the acquire/release lock inside the ClusterConfigurationService instead 
> of command execution strategy.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/ClusterConfigurationService.java
>  1d4030a8dedd017a0ab096925055f375bb5d3ef0 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
>  795164d7a86f87afb60e800885fb5fb2c540451b 
>   geode-core/src/main/java/org/apache/geode/management/cli/CliMetaData.java 
> 2e272fc083514456f0ef89d4b9824126e86828fa 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/CreateAlterDestroyRegionCommands.java
>  7df4112950cefcc1ae18bdd88cb752cdec5b7de1 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DeployCommands.java
>  f076cec670a4c787fbe4002edfdacde4b025d1bf 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
>  14114cff2febf0e1ba7ae67427549ad4fd19ed85 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportImportSharedConfigurationCommands.java
>  914576b2b24eec670c06510aa5b056c0acd808fc 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/IndexCommands.java
>  bc436ba40e107b931e8d0d10082e26cf068dd56b 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/PDXCommands.java
>  72d5c0fc65090880b95f37868e72ef9dcba6c55f 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/QueueCommands.java
>  095bd68f54d0f06d9f9439fcaffbca72e49083fc 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/WanCommands.java
>  cbf589185e94345be6fd64ebd630f76e84cc2a09 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/RemoteExecutionStrategy.java
>  1e4870f9b48e5cc5e4c7ded2af907f4e63aa2977 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/configuration/functions/RecreateCacheFunction.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/configuration/functions/RegionsWithDataOnServerFunction.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/extension/mock/MockExtensionCommands.java
>  1bd4478538f0e0c9413e95a01e835fa6af3a24ea 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ClusterConfigurationServiceCommandsDUnitTest.java
>  87cac55bc672ed380d3abb8ab69c9499f931e4b3 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfig.java
>  c2d511d1c4d34aea434751c2bb5b7e9b924482ad 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigBaseTest.java
>  506428a48c27435a3c89f97bc4d296853fe99415 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigImportDUnitTest.java
>  b301b80a1268c8ad0954e9abe86711cdfe5ac066 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigStartMemberDUnitTest.java
>  7dd0da67bdb38f027f717bfc96adc5f5ffc0af37 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigWithSecurityDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
>  c94185a3b7f8e82cdab620b79c3cb836d0a7e530 
>   
> geode-core/src/test/resources/org/apache/geode/codeAnalysis/sanctionedSerializables.txt
>  9626be76c35194e07df10d3ad650cb3d2df4d73a 
>   
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config_security.zip
>  PRE-CREATION 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/cli/LuceneIndexCommands.java
>  6a5a1e09c03b9a5362e44fd6fe55a6e6181ea17c 
>   
> geode-web/src/test/java/org/apache/geode/management/internal/cli/commands/CommandOverHttpDUnitTest.java
>  a1810b6eaa7d940ad359d64faab98c7d113165f0 
> 
> Diff: https://reviews.apache.org/r/55532/diff/
> 
> 
> Testing
> ---
> 
> precheckin successf

[GitHub] geode pull request #346: GEODE-2326: Adjust testLogger hardcoded value

[dgkimura]

GitHub user dgkimura opened a pull request:

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

GEODE-2326: Adjust testLogger hardcoded value

Fixes the failing logger integration test.  This was caused when we changed 
the log header to the Apache License.

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

$ git pull https://github.com/dgkimura/geode wip/GEODE-2326

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

https://github.com/apache/geode/pull/346.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 #346


commit 3fd93acf3252f6ec8502a0840e906610f236f509
Author: David Kimura 
Date:   2017-01-19T02:14:26Z

GEODE-2326: Adjust testLogger hardcoded value




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

[jira] [Commented] (GEODE-2326) Fix broken integration test testLogger

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15830310#comment-15830310
 ] 

ASF GitHub Bot commented on GEODE-2326:
---

GitHub user dgkimura opened a pull request:

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

GEODE-2326: Adjust testLogger hardcoded value

Fixes the failing logger integration test.  This was caused when we changed 
the log header to the Apache License.

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

$ git pull https://github.com/dgkimura/geode wip/GEODE-2326

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

https://github.com/apache/geode/pull/346.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 #346


commit 3fd93acf3252f6ec8502a0840e906610f236f509
Author: David Kimura 
Date:   2017-01-19T02:14:26Z

GEODE-2326: Adjust testLogger hardcoded value




> Fix broken integration test testLogger
> --
>
> Key: GEODE-2326
> URL: https://issues.apache.org/jira/browse/GEODE-2326
> Project: Geode
>  Issue Type: Test
>  Components: native client
>Reporter: David Kimura
>
> Banner length is hardcoded in this test.  This led to test broking after 
> changing to banner to Apache License.
> Test can be fixed by adjusting the hardcoded length like so..
> {noformat}
> $ git diff
> diff --git a/src/cppcache/integration-test/testLogger.cpp 
> b/src/cppcache/integration-test/testLogger.cpp
> index 6de4e68..8695bf1 100644
> --- a/src/cppcache/integration-test/testLogger.cpp
> +++ b/src/cppcache/integration-test/testLogger.cpp
> @@ -24,7 +24,7 @@
>  #include 
>  #endif
> -#define LENGTH_OF_BANNER 9
> +#define LENGTH_OF_BANNER 16
>  using namespace gemfire;
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 55603: GEODE-2261: fix the dunit test in nightly build

[Kevin Duling]

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


Ship it!




Ship It!

- Kevin Duling


On Jan. 16, 2017, 9:03 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55603/
> ---
> 
> (Updated Jan. 16, 2017, 9:03 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * separte the failing tests. Put WAN test into WAN's test and another into 
> core's test
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigDistributionDUnitTest.java
>  d72e38633dae1b68136c6bc99bb2620f401ee41a 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
>  718c816fc6d4d35cae0e286078638a5dfdc494ed 
>   
> geode-wan/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigurationExtensionsDUnitTest.java
>  f9786c7f85eedd3eb1a358aae8f3a8fbcb9a61f4 
>   
> geode-wan/src/test/java/org/apache/geode/management/internal/configuration/WanDUnitTest.java
>  c1aeae639b961f7e653d3c7e8c9ed153effeba36 
> 
> Diff: https://reviews.apache.org/r/55603/diff/
> 
> 
> Testing
> ---
> 
> precheckin running
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

New committers added to Geode Site Community page

[Dave Barnes]

Ken Howe and Kevin Duling have been added to the website's Committers list.
Welcome, Ken and Kevin!

[jira] [Commented] (GEODE-2198) import cluster-config should continue if the running servers have no data in their application regions

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15830378#comment-15830378
 ] 

ASF subversion and git services commented on GEODE-2198:


Commit 6f418be119d72704215b73e13de902057b18ad4a in geode's branch 
refs/heads/develop from [~jinmeiliao]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=6f418be ]

GEODE-2198: close and re-create the cache on a server when importing new 
cluster configuration

* When importing cluster config first check if there is any non-empty region
* close and re-create cache if no data exists when importing new cluster 
configuration
* put the acquire/release lock inside the ClusterConfigurationService instead 
of command execution strategy.


> import cluster-config should continue if the running servers have no data in 
> their application regions
> --
>
> Key: GEODE-2198
> URL: https://issues.apache.org/jira/browse/GEODE-2198
> Project: Geode
>  Issue Type: Sub-task
>  Components: management
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: New committers added to Geode Site Community page

[Jared Stewart]

Congrats guys!! 
> On Jan 19, 2017, at 10:24 AM, Dave Barnes  wrote:
> 
> Ken Howe and Kevin Duling have been added to the website's Committers list.
> Welcome, Ken and Kevin!

[jira] [Commented] (GEODE-2199) deploy/undeploy should continue even if there is no running servers in the cluster

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15830392#comment-15830392
 ] 

ASF subversion and git services commented on GEODE-2199:


Commit e06bf2dba95d67061aed8e376d4da6916959d6e4 in geode's branch 
refs/heads/develop from [~jinmeiliao]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=e06bf2d ]

GEODE-2199: be able to deploy jars without running servers

* renamed the CliUtils.findAllMatchingServers to findMembersOrThrow to better 
describe the behavior

(cherry picked from commit 80dd57b)


> deploy/undeploy should continue even if there is no running servers in the 
> cluster
> --
>
> Key: GEODE-2199
> URL: https://issues.apache.org/jira/browse/GEODE-2199
> Project: Geode
>  Issue Type: Sub-task
>  Components: management
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>  Labels: DeployCommand, deploy
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (GEODE-2195) Hot Deploy of cluster configuration without bouncing the servers

[Jinmei Liao (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jinmei Liao resolved GEODE-2195.

   Resolution: Fixed
Fix Version/s: 1.1.0

> Hot Deploy of cluster configuration without bouncing the servers
> 
>
> Key: GEODE-2195
> URL: https://issues.apache.org/jira/browse/GEODE-2195
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>  Labels: DeployCommand, deploy
> Fix For: 1.1.0
>
>
> user should be able to import a new set of cluster configuration without 
> having to shutdown all servers at least in the initial phases of trying out 
> cluster configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (GEODE-2195) Hot Deploy of cluster configuration without bouncing the servers

[Jinmei Liao (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jinmei Liao reopened GEODE-2195:


closed by accident.

> Hot Deploy of cluster configuration without bouncing the servers
> 
>
> Key: GEODE-2195
> URL: https://issues.apache.org/jira/browse/GEODE-2195
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>  Labels: DeployCommand, deploy
> Fix For: 1.1.0
>
>
> user should be able to import a new set of cluster configuration without 
> having to shutdown all servers at least in the initial phases of trying out 
> cluster configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] geode pull request #347: GEODE-2313: Fix PulseDataExportTest

[jaredjstewart]

GitHub user jaredjstewart opened a pull request:

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

GEODE-2313: Fix PulseDataExportTest



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

$ git pull https://github.com/jaredjstewart/geode GEODE-2313

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

https://github.com/apache/geode/pull/347.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 #347


commit 3ab780401e6a9e5557ecc4716a5b616bcb8ad39e
Author: Jared Stewart 
Date:   2017-01-18T22:13:48Z

GEODE-2313: Fix PulseDataExportTest




---
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 #347: GEODE-2313: Fix PulseDataExportTest

[jaredjstewart]

Github user jaredjstewart commented on the issue:

https://github.com/apache/geode/pull/347
  
Precheckin passed



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

[jira] [Assigned] (GEODE-2198) import cluster-config should continue if the running servers have no data in their application regions

[Jinmei Liao (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jinmei Liao reassigned GEODE-2198:
--

Assignee: Jinmei Liao  (was: Kirk Lund)

> import cluster-config should continue if the running servers have no data in 
> their application regions
> --
>
> Key: GEODE-2198
> URL: https://issues.apache.org/jira/browse/GEODE-2198
> Project: Geode
>  Issue Type: Sub-task
>  Components: management
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
> Fix For: 1.1.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (GEODE-2195) Hot Deploy of cluster configuration without bouncing the servers

[Jinmei Liao (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jinmei Liao reassigned GEODE-2195:
--

Assignee: Jinmei Liao  (was: Kirk Lund)

> Hot Deploy of cluster configuration without bouncing the servers
> 
>
> Key: GEODE-2195
> URL: https://issues.apache.org/jira/browse/GEODE-2195
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>  Labels: DeployCommand, deploy
> Fix For: 1.1.0
>
>
> user should be able to import a new set of cluster configuration without 
> having to shutdown all servers at least in the initial phases of trying out 
> cluster configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2313) PulseDataExportTest.dataBrowserExportWorksAsExpected fails with ConditionTimeoutException

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15830395#comment-15830395
 ] 

ASF GitHub Bot commented on GEODE-2313:
---

GitHub user jaredjstewart opened a pull request:

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

GEODE-2313: Fix PulseDataExportTest



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

$ git pull https://github.com/jaredjstewart/geode GEODE-2313

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

https://github.com/apache/geode/pull/347.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 #347


commit 3ab780401e6a9e5557ecc4716a5b616bcb8ad39e
Author: Jared Stewart 
Date:   2017-01-18T22:13:48Z

GEODE-2313: Fix PulseDataExportTest




> PulseDataExportTest.dataBrowserExportWorksAsExpected fails with 
> ConditionTimeoutException
> -
>
> Key: GEODE-2313
> URL: https://issues.apache.org/jira/browse/GEODE-2313
> Project: Geode
>  Issue Type: Bug
>  Components: pulse, tests
>Reporter: Kirk Lund
>Assignee: Jared Stewart
>
> {noformat}
> org.apache.geode.tools.pulse.tests.PulseDataExportTest > 
> dataBrowserExportWorksAsExpected FAILED
> com.jayway.awaitility.core.ConditionTimeoutException: Condition with 
> lambda expression in org.apache.geode.tools.pulse.tests.PulseDataExportTest 
> was not fulfilled within 2 minutes.
> at 
> com.jayway.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:122)
> at 
> com.jayway.awaitility.core.CallableCondition.await(CallableCondition.java:79)
> at 
> com.jayway.awaitility.core.CallableCondition.await(CallableCondition.java:27)
> at 
> com.jayway.awaitility.core.ConditionFactory.until(ConditionFactory.java:764)
> at 
> com.jayway.awaitility.core.ConditionFactory.until(ConditionFactory.java:741)
> at 
> org.apache.geode.tools.pulse.tests.PulseDataExportTest.before(PulseDataExportTest.java:99)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (GEODE-2198) import cluster-config should continue if the running servers have no data in their application regions

[Jinmei Liao (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jinmei Liao resolved GEODE-2198.

   Resolution: Fixed
Fix Version/s: 1.1.0

> import cluster-config should continue if the running servers have no data in 
> their application regions
> --
>
> Key: GEODE-2198
> URL: https://issues.apache.org/jira/browse/GEODE-2198
> Project: Geode
>  Issue Type: Sub-task
>  Components: management
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
> Fix For: 1.1.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2313) PulseDataExportTest.dataBrowserExportWorksAsExpected fails with ConditionTimeoutException

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15830396#comment-15830396
 ] 

ASF GitHub Bot commented on GEODE-2313:
---

Github user jaredjstewart commented on the issue:

https://github.com/apache/geode/pull/347
  
Precheckin passed



> PulseDataExportTest.dataBrowserExportWorksAsExpected fails with 
> ConditionTimeoutException
> -
>
> Key: GEODE-2313
> URL: https://issues.apache.org/jira/browse/GEODE-2313
> Project: Geode
>  Issue Type: Bug
>  Components: pulse, tests
>Reporter: Kirk Lund
>Assignee: Jared Stewart
>
> {noformat}
> org.apache.geode.tools.pulse.tests.PulseDataExportTest > 
> dataBrowserExportWorksAsExpected FAILED
> com.jayway.awaitility.core.ConditionTimeoutException: Condition with 
> lambda expression in org.apache.geode.tools.pulse.tests.PulseDataExportTest 
> was not fulfilled within 2 minutes.
> at 
> com.jayway.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:122)
> at 
> com.jayway.awaitility.core.CallableCondition.await(CallableCondition.java:79)
> at 
> com.jayway.awaitility.core.CallableCondition.await(CallableCondition.java:27)
> at 
> com.jayway.awaitility.core.ConditionFactory.until(ConditionFactory.java:764)
> at 
> com.jayway.awaitility.core.ConditionFactory.until(ConditionFactory.java:741)
> at 
> org.apache.geode.tools.pulse.tests.PulseDataExportTest.before(PulseDataExportTest.java:99)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (GEODE-2199) deploy/undeploy should continue even if there is no running servers in the cluster

[Jinmei Liao (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jinmei Liao resolved GEODE-2199.

   Resolution: Fixed
 Assignee: Jinmei Liao  (was: Kirk Lund)
Fix Version/s: 1.1.0

> deploy/undeploy should continue even if there is no running servers in the 
> cluster
> --
>
> Key: GEODE-2199
> URL: https://issues.apache.org/jira/browse/GEODE-2199
> Project: Geode
>  Issue Type: Sub-task
>  Components: management
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>  Labels: DeployCommand, deploy
> Fix For: 1.1.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (GEODE-2196) Write more tests to cover the current behavior of cluster config

[Jinmei Liao (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jinmei Liao reassigned GEODE-2196:
--

Assignee: Jinmei Liao

> Write more tests to cover the current behavior of cluster config
> 
>
> Key: GEODE-2196
> URL: https://issues.apache.org/jira/browse/GEODE-2196
> Project: Geode
>  Issue Type: Sub-task
>  Components: management
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
> Fix For: 1.1.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 55532: GEODE-2198: close and re-create the cache on a server when importing new cluster configuration

[Jared Stewart]

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


Ship it!




Ship It!

- Jared Stewart


On Jan. 17, 2017, 11:27 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55532/
> ---
> 
> (Updated Jan. 17, 2017, 11:27 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * When importing cluster config first check if there is any non-empty region
> * close and re-create cache if no data exists when importing new cluster 
> configuration
> * put the acquire/release lock inside the ClusterConfigurationService instead 
> of command execution strategy.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/ClusterConfigurationService.java
>  1d4030a8dedd017a0ab096925055f375bb5d3ef0 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
>  795164d7a86f87afb60e800885fb5fb2c540451b 
>   geode-core/src/main/java/org/apache/geode/management/cli/CliMetaData.java 
> 2e272fc083514456f0ef89d4b9824126e86828fa 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/CreateAlterDestroyRegionCommands.java
>  7df4112950cefcc1ae18bdd88cb752cdec5b7de1 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DeployCommands.java
>  f076cec670a4c787fbe4002edfdacde4b025d1bf 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
>  14114cff2febf0e1ba7ae67427549ad4fd19ed85 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportImportSharedConfigurationCommands.java
>  914576b2b24eec670c06510aa5b056c0acd808fc 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/IndexCommands.java
>  bc436ba40e107b931e8d0d10082e26cf068dd56b 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/PDXCommands.java
>  72d5c0fc65090880b95f37868e72ef9dcba6c55f 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/QueueCommands.java
>  095bd68f54d0f06d9f9439fcaffbca72e49083fc 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/WanCommands.java
>  cbf589185e94345be6fd64ebd630f76e84cc2a09 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/RemoteExecutionStrategy.java
>  1e4870f9b48e5cc5e4c7ded2af907f4e63aa2977 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/configuration/functions/RecreateCacheFunction.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/configuration/functions/RegionsWithDataOnServerFunction.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/extension/mock/MockExtensionCommands.java
>  1bd4478538f0e0c9413e95a01e835fa6af3a24ea 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ClusterConfigurationServiceCommandsDUnitTest.java
>  87cac55bc672ed380d3abb8ab69c9499f931e4b3 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfig.java
>  c2d511d1c4d34aea434751c2bb5b7e9b924482ad 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigBaseTest.java
>  506428a48c27435a3c89f97bc4d296853fe99415 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigImportDUnitTest.java
>  b301b80a1268c8ad0954e9abe86711cdfe5ac066 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigStartMemberDUnitTest.java
>  7dd0da67bdb38f027f717bfc96adc5f5ffc0af37 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigWithSecurityDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
>  c94185a3b7f8e82cdab620b79c3cb836d0a7e530 
>   
> geode-core/src/test/resources/org/apache/geode/codeAnalysis/sanctionedSerializables.txt
>  9626be76c35194e07df10d3ad650cb3d2df4d73a 
>   
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config_security.zip
>  PRE-CREATION 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/cli/LuceneIndexCommands.java
>  6a5a1e09c03b9a5362e44fd6fe55a6e6181ea17c 
>   
> geode-web/src/test/java/org/apache/geode/management/internal/cli/commands/CommandOverHttpDUnitTest.java
>  a1810b6eaa7d940ad359d64faab98c7d113165f0 
> 
> Diff: https://reviews.apache.org/r/55532/diff/
> 
> 
> Testing
> ---
> 
> precheckin succe

Re: backward-compatibility testing

[Bruce Schuchardt]

One way to do this would be to have the DUnit Locator run the oldest 
version of Geode that we want to test with.  For now that would be 
1.0.0-incubating.  Any test that needs to exercise newer algorithms 
involving a Locator would need to launch one of its own.


Does that sound acceptable?

Le 1/19/2017 à 9:27 AM, Bruce Schuchardt a écrit :
Thanks Dan.  I'm not sure we want to keep the change I made to the 
Locator.  The restriction on letting old-version members join is for 
rolling upgrade and has been in Geode & GemFire for a long time.  It 
gives us some assurance that we can enable new distributed algorithms 
and stop using old algorithms. We ran into that requirement when we 
altered distributed locking behavior in GemFire.


If I revert that change it will require that any test starting a peer 
cache using an old version of Geode must create its own old-version 
Locator.  That's probably the best thing to do because the way I have 
it right now might make it very hard to implement new algorithms that 
involve the Locator.  If an old-version peer starts up and the Locator 
sends it a message it doesn't comprehend, or the Locator expects it to 
do something and it doesn't, it could be difficult to deal with.


Le 1/19/2017 à 9:07 AM, Dan Smith a écrit :
+1 This is great Bruce! I really like this approach of being able to 
write
tests and have them run with some members with a different version. I 
think

with this framework we should be able to just extend existing tests with
subclasses that override the version of some of the VMs which I think 
is a

good way to do the backwards compatibility testing.

One question - you modified the locator to allow old versions to 
join. Why
was that necessary? I know we broke P2P compatibility between gemfire 
8 and
geode 1.0, but are we not allowing P2P compatibility going forward? I 
was
under the impression that 1.1 was going to be compatible with 1.0. Is 
that
not the case? Why do the tests need to have peers with different 
versions
if we are not supporting that? Is there a way we can do these tests 
without

having the product code behave differently when it is being tested than
when it is being used normally?

-Dan



On Wed, Jan 18, 2017 at 3:11 PM, Bruce Schuchardt 


wrote:


I've extended the distributedTest framework to let us do
backward-compatibility testing.  Once it is reviewed and committed 
people
will be needed to modify existing tests to run against multiple 
versions of

Geode.

Here is the RB review: https://reviews.apache.org/r/55688/

The diff in this review includes a client/server test modified to run
against multiple versions.  Basically you just need to parameterize an
existing distributedTest case to run against multiple versions using
Host.getHost(0).getVM(testVersion, vmNumber).  That give you a JVM 
that's

set up to use the requested version.  You can then use the normal
method/lambda invocation methods to run code in that JVM.

Currently version "100" (1.0.0-incubating) is available for
backward-compatibility testing.  Versions to be tested are 
configured in

geode-old-versions/build.gradle as source-sets. Adding a new version is
trivial.

[jira] [Commented] (GEODE-2282) Provide ability to sort field while creating pdxType for jSON document

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15830423#comment-15830423
 ] 

ASF subversion and git services commented on GEODE-2282:


Commit 8b303e43bce0518f4cd290b688f7ee93ebe2da3e in geode's branch 
refs/heads/develop from [~hitesh.khamesra]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=8b303e4 ]

GEODE-2282 Added ability to sort JSON fields while creating pdxtype.

One can enable this feature by setting java system property(
gemfire.pdx.mapper.sort-json-field-names=true. In this way geode will
not create multiple pdx type ids for JSON document, if different JSON
document has same fields in different order.

Added unit test for it.

updated


> Provide ability to sort field while creating pdxType for jSON document
> --
>
> Key: GEODE-2282
> URL: https://issues.apache.org/jira/browse/GEODE-2282
> Project: Geode
>  Issue Type: Bug
>  Components: serialization
>Reporter: Hitesh Khamesra
>Assignee: Hitesh Khamesra
>
> There is the possibility that same JSON document can create multiple pdxType 
> ids, if different JSON docs contain same fields in different order. Thus sort 
> those field while creating the pdxType id. Introduce system property to 
> enable this feature.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 55687: GEODE-2199: be able to deploy jars without running servers

[Jared Stewart]

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


Ship it!




Ship It!

- Jared Stewart


On Jan. 19, 2017, 1:35 a.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55687/
> ---
> 
> (Updated Jan. 19, 2017, 1:35 a.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * renamed the CliUtils.findAllMatchingServers to findMembersOrThrow to better 
> describe the behavior
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/CliUtil.java
>  5b9a6bd63350dd753c66fd25e6058ddea45f9325 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ConfigCommands.java
>  5154b75e85a42e6d97f5563effe3a7600369126a 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/CreateAlterDestroyRegionCommands.java
>  7df4112950cefcc1ae18bdd88cb752cdec5b7de1 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DeployCommands.java
>  f076cec670a4c787fbe4002edfdacde4b025d1bf 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
>  14114cff2febf0e1ba7ae67427549ad4fd19ed85 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DurableClientCommands.java
>  053f3ebcc74638f992854cdd96d9c586aa33818a 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/FunctionCommands.java
>  9a9ece952110e90b32e65cbff8ea2319779c4aff 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/IndexCommands.java
>  bc436ba40e107b931e8d0d10082e26cf068dd56b 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/MiscellaneousCommands.java
>  88a9919802f3d32822f20d3a1c8cfcc4ffa5a6c4 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/QueueCommands.java
>  095bd68f54d0f06d9f9439fcaffbca72e49083fc 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/RegionCommands.java
>  78a28d68ea7aa75ab2cda0c01b5a567e3d0d9475 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/WanCommands.java
>  cbf589185e94345be6fd64ebd630f76e84cc2a09 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/CliUtilDUnitTest.java
>  d7d59b71cd54ca23c716e72da413bae6a05e75fd 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfig.java
>  c2d511d1c4d34aea434751c2bb5b7e9b924482ad 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigDeployJarDUnitTest.java
>  51a77d2f4454a772251039a465ab00655a9bea98 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
>  13442fd68ce2855561fc724bf73cd8c21d2317af 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/cli/LuceneIndexCommands.java
>  6a5a1e09c03b9a5362e44fd6fe55a6e6181ea17c 
> 
> Diff: https://reviews.apache.org/r/55687/diff/
> 
> 
> Testing
> ---
> 
> precheckin successful
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Fixed: apache/geode-examples#2 (develop - 22c2470)

[Travis CI]

Build Update for apache/geode-examples
-

Build: #2
Status: Fixed

Duration: 2 minutes and 4 seconds
Commit: 22c2470 (develop)
Author: Anthony Baker
Message: GEODE-2318 Add ASF header

View the changeset: 
https://github.com/apache/geode-examples/compare/6f5d21c55f70...22c24703f250

View the full build log and details: 
https://travis-ci.org/apache/geode-examples/builds/193419198

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

Failed: apache/geode-examples#1 (develop - 6f5d21c)

[Travis CI]

Build Update for apache/geode-examples
-

Build: #1
Status: Failed

Duration: 1 minute and 41 seconds
Commit: 6f5d21c (develop)
Author: Anthony Baker
Message: GEODE-2318 Add travis-ci badge to README.md

View the changeset: 
https://github.com/apache/geode-examples/compare/15725b6e5bf2...6f5d21c55f70

View the full build log and details: 
https://travis-ci.org/apache/geode-examples/builds/193408719

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

Broken: apache/geode#1815 (develop - 8b303e4)

[Travis CI]

Build Update for apache/geode
-

Build: #1815
Status: Broken

Duration: 8 minutes and 45 seconds
Commit: 8b303e4 (develop)
Author: Hitesh Khamesra
Message: GEODE-2282 Added ability to sort JSON fields while creating pdxtype.

One can enable this feature by setting java system property(
gemfire.pdx.mapper.sort-json-field-names=true. In this way geode will
not create multiple pdx type ids for JSON document, if different JSON
document has same fields in different order.

Added unit test for it.

updated

View the changeset: 
https://github.com/apache/geode/compare/e06bf2dba95d...8b303e43bce0

View the full build log and details: 
https://travis-ci.org/apache/geode/builds/193487126

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

Re: JIRA versions and multiple repos

[Dan Smith]

I wonder if we're trying to overcomplicate things there. I don't see why
the geode-examples wouldn't use the same release schedule and version
number as geode.

The C++ and .NET clients are also somewhat tied to the version of geode
that they support. As long as we can stick to a regular release cadence, It
seems like those clients couldn't also follow the same release schedule and
version numbers.

-Dan

On Thu, Jan 19, 2017 at 7:55 AM, Anthony Baker  wrote:

> Currently our JIRA versions look like this:
>
> 1.0.0-incubating.M1
> 1.0.0-incubating.M2
> 1.0.0-incubating.M3
> 1.1.0
>
> That works great for the geode repo.  However, what about the
> geode-examples repo?  I would like to set a ‘Fix version’ that matches the
> version in [1].  Since the repos can release independently of each other, I
> think we need a way to completely disambiguate versions like
> ‘geode-examples-0.1’.  We could also ask for a JIRA project for each repo.
> Thoughts?
>
> More stuff:
>
> - GEODE-2318 didn’t get updated with commit logs from geode-examples.
> Anyone know how to fix this?
> - Travis-CI is now running on geode-examples.  If you notice problems with
> PR’s or email notifications let me know.
>
> Anthony
>
> [1] https://github.com/apache/geode-examples/blob/develop/
> gradle.properties#L17
>
>

Build failing the rat check

[Dan Smith]

Unapproved licenses:


geode-core/src/main/java/org/apache/geode/pdx/internal/json/JSONToPdxMapper.java

-Dan

[jira] [Commented] (GEODE-2282) Provide ability to sort field while creating pdxType for jSON document

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15830468#comment-15830468
 ] 

ASF subversion and git services commented on GEODE-2282:


Commit de070b517e25256e9c33f318f343b0219fb8cc66 in geode's branch 
refs/heads/develop from [~hitesh.khamesra]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=de070b5 ]

GEODE-2282 Added license info


> Provide ability to sort field while creating pdxType for jSON document
> --
>
> Key: GEODE-2282
> URL: https://issues.apache.org/jira/browse/GEODE-2282
> Project: Geode
>  Issue Type: Bug
>  Components: serialization
>Reporter: Hitesh Khamesra
>Assignee: Hitesh Khamesra
>
> There is the possibility that same JSON document can create multiple pdxType 
> ids, if different JSON docs contain same fields in different order. Thus sort 
> those field while creating the pdxType id. Introduce system property to 
> enable this feature.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Build failing the rat check

[Hitesh Khamesra]

Just fixed it . 
Thanks.

  From: Dan Smith 
 To: dev@geode.apache.org; Hitesh Khamesra  
 Sent: Thursday, January 19, 2017 11:31 AM
 Subject: Build failing the rat check
   
Unapproved licenses:


geode-core/src/main/java/org/apache/geode/pdx/internal/json/JSONToPdxMapper.java

-Dan


   

[jira] [Updated] (GEODE-2282) Provide ability to sort field while creating pdxType for jSON document

[Hitesh Khamesra (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hitesh Khamesra updated GEODE-2282:
---
Component/s: (was: serialization)
 docs

> Provide ability to sort field while creating pdxType for jSON document
> --
>
> Key: GEODE-2282
> URL: https://issues.apache.org/jira/browse/GEODE-2282
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Hitesh Khamesra
>Assignee: Hitesh Khamesra
> Fix For: 1.1.0
>
>
> There is the possibility that same JSON document can create multiple pdxType 
> ids, if different JSON docs contain same fields in different order. Thus sort 
> those field while creating the pdxType id. Introduce system property to 
> enable this feature.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (GEODE-2282) Provide ability to sort field while creating pdxType for jSON document

[Hitesh Khamesra (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hitesh Khamesra updated GEODE-2282:
---
Assignee: Joey McAllister  (was: Hitesh Khamesra)

> Provide ability to sort field while creating pdxType for jSON document
> --
>
> Key: GEODE-2282
> URL: https://issues.apache.org/jira/browse/GEODE-2282
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Hitesh Khamesra
>Assignee: Joey McAllister
> Fix For: 1.1.0
>
>
> There is the possibility that same JSON document can create multiple pdxType 
> ids, if different JSON docs contain same fields in different order. Thus sort 
> those field while creating the pdxType id. Introduce system property to 
> enable this feature.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (GEODE-2282) Provide ability to sort field while creating pdxType for jSON document

[Hitesh Khamesra (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hitesh Khamesra updated GEODE-2282:
---
Fix Version/s: 1.1.0

> Provide ability to sort field while creating pdxType for jSON document
> --
>
> Key: GEODE-2282
> URL: https://issues.apache.org/jira/browse/GEODE-2282
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Hitesh Khamesra
>Assignee: Hitesh Khamesra
> Fix For: 1.1.0
>
>
> There is the possibility that same JSON document can create multiple pdxType 
> ids, if different JSON docs contain same fields in different order. Thus sort 
> those field while creating the pdxType id. Introduce system property to 
> enable this feature.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2282) Provide ability to sort field while creating pdxType for jSON document

[Hitesh Khamesra (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15830480#comment-15830480
 ] 

Hitesh Khamesra commented on GEODE-2282:


Need to add this sys property in doc

/***
   * By setting "gemfire.pdx.mapper.sort-json-field-names" to true, enables 
serialization of JSON field in JSON
   * document to be sorted. That can help to reduce the number of pdx typeId 
generation if different
   * JSON documents have same fields in the different order.
   */

> Provide ability to sort field while creating pdxType for jSON document
> --
>
> Key: GEODE-2282
> URL: https://issues.apache.org/jira/browse/GEODE-2282
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Hitesh Khamesra
>Assignee: Hitesh Khamesra
> Fix For: 1.1.0
>
>
> There is the possibility that same JSON document can create multiple pdxType 
> ids, if different JSON docs contain same fields in different order. Thus sort 
> those field while creating the pdxType id. Introduce system property to 
> enable this feature.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: JIRA versions and multiple repos

[Roman Shaposhnik]

On Thu, Jan 19, 2017 at 11:21 AM, Dan Smith  wrote:
> I wonder if we're trying to overcomplicate things there. I don't see why
> the geode-examples wouldn't use the same release schedule and version
> number as geode.
>
> The C++ and .NET clients are also somewhat tied to the version of geode
> that they support. As long as we can stick to a regular release cadence, It
> seems like those clients couldn't also follow the same release schedule and
> version numbers.

Huge +1 to the above!

Thanks,
Roman.

Re: JIRA versions and multiple repos

[Jacob Barrett]

I think I agree. We should try the same release cycle for all components
until we find we can't.

-Jake

On Thu, Jan 19, 2017 at 11:21 AM Dan Smith  wrote:

> I wonder if we're trying to overcomplicate things there. I don't see why
> the geode-examples wouldn't use the same release schedule and version
> number as geode.
>
> The C++ and .NET clients are also somewhat tied to the version of geode
> that they support. As long as we can stick to a regular release cadence, It
> seems like those clients couldn't also follow the same release schedule and
> version numbers.
>
> -Dan
>
> On Thu, Jan 19, 2017 at 7:55 AM, Anthony Baker  wrote:
>
> > Currently our JIRA versions look like this:
> >
> > 1.0.0-incubating.M1
> > 1.0.0-incubating.M2
> > 1.0.0-incubating.M3
> > 1.1.0
> >
> > That works great for the geode repo.  However, what about the
> > geode-examples repo?  I would like to set a ‘Fix version’ that matches
> the
> > version in [1].  Since the repos can release independently of each
> other, I
> > think we need a way to completely disambiguate versions like
> > ‘geode-examples-0.1’.  We could also ask for a JIRA project for each
> repo.
> > Thoughts?
> >
> > More stuff:
> >
> > - GEODE-2318 didn’t get updated with commit logs from geode-examples.
> > Anyone know how to fix this?
> > - Travis-CI is now running on geode-examples.  If you notice problems
> with
> > PR’s or email notifications let me know.
> >
> > Anthony
> >
> > [1] https://github.com/apache/geode-examples/blob/develop/
> > gradle.properties#L17
> >
> >
>

Re: JIRA versions and multiple repos

[Swapnil Bawaskar]

+1

On Thu, Jan 19, 2017 at 11:58 AM, Jacob Barrett  wrote:

> I think I agree. We should try the same release cycle for all components
> until we find we can't.
>
> -Jake
>
> On Thu, Jan 19, 2017 at 11:21 AM Dan Smith  wrote:
>
> > I wonder if we're trying to overcomplicate things there. I don't see why
> > the geode-examples wouldn't use the same release schedule and version
> > number as geode.
> >
> > The C++ and .NET clients are also somewhat tied to the version of geode
> > that they support. As long as we can stick to a regular release cadence,
> It
> > seems like those clients couldn't also follow the same release schedule
> and
> > version numbers.
> >
> > -Dan
> >
> > On Thu, Jan 19, 2017 at 7:55 AM, Anthony Baker 
> wrote:
> >
> > > Currently our JIRA versions look like this:
> > >
> > > 1.0.0-incubating.M1
> > > 1.0.0-incubating.M2
> > > 1.0.0-incubating.M3
> > > 1.1.0
> > >
> > > That works great for the geode repo.  However, what about the
> > > geode-examples repo?  I would like to set a ‘Fix version’ that matches
> > the
> > > version in [1].  Since the repos can release independently of each
> > other, I
> > > think we need a way to completely disambiguate versions like
> > > ‘geode-examples-0.1’.  We could also ask for a JIRA project for each
> > repo.
> > > Thoughts?
> > >
> > > More stuff:
> > >
> > > - GEODE-2318 didn’t get updated with commit logs from geode-examples.
> > > Anyone know how to fix this?
> > > - Travis-CI is now running on geode-examples.  If you notice problems
> > with
> > > PR’s or email notifications let me know.
> > >
> > > Anthony
> > >
> > > [1] https://github.com/apache/geode-examples/blob/develop/
> > > gradle.properties#L17
> > >
> > >
> >
>

Fixed: apache/geode#1816 (develop - de070b5)

[Travis CI]

Build Update for apache/geode
-

Build: #1816
Status: Fixed

Duration: 8 minutes and 6 seconds
Commit: de070b5 (develop)
Author: Hitesh Khamesra
Message: GEODE-2282 Added license info

View the changeset: 
https://github.com/apache/geode/compare/8b303e43bce0...de070b517e25

View the full build log and details: 
https://travis-ci.org/apache/geode/builds/193494174

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

Re: backward-compatibility testing

[Anilkumar Gingade]

>> any test starting a peer cache using an old version of Geode must create
its own old-version Locator
Bruce, we don't allow/recommend starting old versions of locator or peers
when the rolling upgrade is started, right?

-Anil.

On Thu, Jan 19, 2017 at 11:06 AM, Bruce Schuchardt 
wrote:

> One way to do this would be to have the DUnit Locator run the oldest
> version of Geode that we want to test with.  For now that would be
> 1.0.0-incubating.  Any test that needs to exercise newer algorithms
> involving a Locator would need to launch one of its own.
>
> Does that sound acceptable?
>
> Le 1/19/2017 à 9:27 AM, Bruce Schuchardt a écrit :
>
>> Thanks Dan.  I'm not sure we want to keep the change I made to the
>> Locator.  The restriction on letting old-version members join is for
>> rolling upgrade and has been in Geode & GemFire for a long time.  It gives
>> us some assurance that we can enable new distributed algorithms and stop
>> using old algorithms. We ran into that requirement when we altered
>> distributed locking behavior in GemFire.
>>
>> If I revert that change it will require that any test starting a peer
>> cache using an old version of Geode must create its own old-version
>> Locator.  That's probably the best thing to do because the way I have it
>> right now might make it very hard to implement new algorithms that involve
>> the Locator.  If an old-version peer starts up and the Locator sends it a
>> message it doesn't comprehend, or the Locator expects it to do something
>> and it doesn't, it could be difficult to deal with.
>>
>> Le 1/19/2017 à 9:07 AM, Dan Smith a écrit :
>>
>>> +1 This is great Bruce! I really like this approach of being able to
>>> write
>>> tests and have them run with some members with a different version. I
>>> think
>>> with this framework we should be able to just extend existing tests with
>>> subclasses that override the version of some of the VMs which I think is
>>> a
>>> good way to do the backwards compatibility testing.
>>>
>>> One question - you modified the locator to allow old versions to join.
>>> Why
>>> was that necessary? I know we broke P2P compatibility between gemfire 8
>>> and
>>> geode 1.0, but are we not allowing P2P compatibility going forward? I was
>>> under the impression that 1.1 was going to be compatible with 1.0. Is
>>> that
>>> not the case? Why do the tests need to have peers with different versions
>>> if we are not supporting that? Is there a way we can do these tests
>>> without
>>> having the product code behave differently when it is being tested than
>>> when it is being used normally?
>>>
>>> -Dan
>>>
>>>
>>>
>>> On Wed, Jan 18, 2017 at 3:11 PM, Bruce Schuchardt <
>>> bschucha...@pivotal.io>
>>> wrote:
>>>
>>> I've extended the distributedTest framework to let us do
 backward-compatibility testing.  Once it is reviewed and committed
 people
 will be needed to modify existing tests to run against multiple
 versions of
 Geode.

 Here is the RB review: https://reviews.apache.org/r/55688/

 The diff in this review includes a client/server test modified to run
 against multiple versions.  Basically you just need to parameterize an
 existing distributedTest case to run against multiple versions using
 Host.getHost(0).getVM(testVersion, vmNumber).  That give you a JVM
 that's
 set up to use the requested version.  You can then use the normal
 method/lambda invocation methods to run code in that JVM.

 Currently version "100" (1.0.0-incubating) is available for
 backward-compatibility testing.  Versions to be tested are configured in
 geode-old-versions/build.gradle as source-sets. Adding a new version is
 trivial.


>>
>

Re: JIRA versions and multiple repos

[Michael William Dodge]

Do any of the users of what we call the C++ and .NET clients view them as 
libraries that provide an API? (As opposed to standalone applications.) If so, 
it would seem that they would expect the API libraries to move in step with the 
server releases. If the majority of the functionality in the C++ and .NET 
libraries is dependent on functionality in the server, having a divergence in 
versions amongst them might be a bit surprising. To put it another way, will 
the C++ or .NET clients be releasing significant functionality without support 
for that functionality in the server? 

Sarge

> On 19 Jan, 2017, at 11:58, Jacob Barrett  wrote:
> 
> I think I agree. We should try the same release cycle for all components
> until we find we can't.
> 
> -Jake
> 
> On Thu, Jan 19, 2017 at 11:21 AM Dan Smith  wrote:
> 
>> I wonder if we're trying to overcomplicate things there. I don't see why
>> the geode-examples wouldn't use the same release schedule and version
>> number as geode.
>> 
>> The C++ and .NET clients are also somewhat tied to the version of geode
>> that they support. As long as we can stick to a regular release cadence, It
>> seems like those clients couldn't also follow the same release schedule and
>> version numbers.
>> 
>> -Dan
>> 
>> On Thu, Jan 19, 2017 at 7:55 AM, Anthony Baker  wrote:
>> 
>>> Currently our JIRA versions look like this:
>>> 
>>> 1.0.0-incubating.M1
>>> 1.0.0-incubating.M2
>>> 1.0.0-incubating.M3
>>> 1.1.0
>>> 
>>> That works great for the geode repo.  However, what about the
>>> geode-examples repo?  I would like to set a ‘Fix version’ that matches
>> the
>>> version in [1].  Since the repos can release independently of each
>> other, I
>>> think we need a way to completely disambiguate versions like
>>> ‘geode-examples-0.1’.  We could also ask for a JIRA project for each
>> repo.
>>> Thoughts?
>>> 
>>> More stuff:
>>> 
>>> - GEODE-2318 didn’t get updated with commit logs from geode-examples.
>>> Anyone know how to fix this?
>>> - Travis-CI is now running on geode-examples.  If you notice problems
>> with
>>> PR’s or email notifications let me know.
>>> 
>>> Anthony
>>> 
>>> [1] https://github.com/apache/geode-examples/blob/develop/
>>> gradle.properties#L17
>>> 
>>> 
>> 

Re: JIRA versions and multiple repos

[Ernest Burghardt]

+1 for keeping it Simple

On Thu, Jan 19, 2017 at 11:59 AM, Swapnil Bawaskar 
wrote:

> +1
>
> On Thu, Jan 19, 2017 at 11:58 AM, Jacob Barrett 
> wrote:
>
> > I think I agree. We should try the same release cycle for all components
> > until we find we can't.
> >
> > -Jake
> >
> > On Thu, Jan 19, 2017 at 11:21 AM Dan Smith  wrote:
> >
> > > I wonder if we're trying to overcomplicate things there. I don't see
> why
> > > the geode-examples wouldn't use the same release schedule and version
> > > number as geode.
> > >
> > > The C++ and .NET clients are also somewhat tied to the version of geode
> > > that they support. As long as we can stick to a regular release
> cadence,
> > It
> > > seems like those clients couldn't also follow the same release schedule
> > and
> > > version numbers.
> > >
> > > -Dan
> > >
> > > On Thu, Jan 19, 2017 at 7:55 AM, Anthony Baker 
> > wrote:
> > >
> > > > Currently our JIRA versions look like this:
> > > >
> > > > 1.0.0-incubating.M1
> > > > 1.0.0-incubating.M2
> > > > 1.0.0-incubating.M3
> > > > 1.1.0
> > > >
> > > > That works great for the geode repo.  However, what about the
> > > > geode-examples repo?  I would like to set a ‘Fix version’ that
> matches
> > > the
> > > > version in [1].  Since the repos can release independently of each
> > > other, I
> > > > think we need a way to completely disambiguate versions like
> > > > ‘geode-examples-0.1’.  We could also ask for a JIRA project for each
> > > repo.
> > > > Thoughts?
> > > >
> > > > More stuff:
> > > >
> > > > - GEODE-2318 didn’t get updated with commit logs from geode-examples.
> > > > Anyone know how to fix this?
> > > > - Travis-CI is now running on geode-examples.  If you notice problems
> > > with
> > > > PR’s or email notifications let me know.
> > > >
> > > > Anthony
> > > >
> > > > [1] https://github.com/apache/geode-examples/blob/develop/
> > > > gradle.properties#L17
> > > >
> > > >
> > >
> >
>

Re: backward-compatibility testing

[Bruce Schuchardt]

Right, we don't allow it.  That's what this email thread is about, Anil.

Le 1/19/2017 à 12:16 PM, Anilkumar Gingade a écrit :

any test starting a peer cache using an old version of Geode must create

its own old-version Locator
Bruce, we don't allow/recommend starting old versions of locator or peers
when the rolling upgrade is started, right?

-Anil.

On Thu, Jan 19, 2017 at 11:06 AM, Bruce Schuchardt 
wrote:


One way to do this would be to have the DUnit Locator run the oldest
version of Geode that we want to test with.  For now that would be
1.0.0-incubating.  Any test that needs to exercise newer algorithms
involving a Locator would need to launch one of its own.

Does that sound acceptable?

Le 1/19/2017 à 9:27 AM, Bruce Schuchardt a écrit :


Thanks Dan.  I'm not sure we want to keep the change I made to the
Locator.  The restriction on letting old-version members join is for
rolling upgrade and has been in Geode & GemFire for a long time.  It gives
us some assurance that we can enable new distributed algorithms and stop
using old algorithms. We ran into that requirement when we altered
distributed locking behavior in GemFire.

If I revert that change it will require that any test starting a peer
cache using an old version of Geode must create its own old-version
Locator.  That's probably the best thing to do because the way I have it
right now might make it very hard to implement new algorithms that involve
the Locator.  If an old-version peer starts up and the Locator sends it a
message it doesn't comprehend, or the Locator expects it to do something
and it doesn't, it could be difficult to deal with.

Le 1/19/2017 à 9:07 AM, Dan Smith a écrit :


+1 This is great Bruce! I really like this approach of being able to
write
tests and have them run with some members with a different version. I
think
with this framework we should be able to just extend existing tests with
subclasses that override the version of some of the VMs which I think is
a
good way to do the backwards compatibility testing.

One question - you modified the locator to allow old versions to join.
Why
was that necessary? I know we broke P2P compatibility between gemfire 8
and
geode 1.0, but are we not allowing P2P compatibility going forward? I was
under the impression that 1.1 was going to be compatible with 1.0. Is
that
not the case? Why do the tests need to have peers with different versions
if we are not supporting that? Is there a way we can do these tests
without
having the product code behave differently when it is being tested than
when it is being used normally?

-Dan



On Wed, Jan 18, 2017 at 3:11 PM, Bruce Schuchardt <
bschucha...@pivotal.io>
wrote:

I've extended the distributedTest framework to let us do

backward-compatibility testing.  Once it is reviewed and committed
people
will be needed to modify existing tests to run against multiple
versions of
Geode.

Here is the RB review: https://reviews.apache.org/r/55688/

The diff in this review includes a client/server test modified to run
against multiple versions.  Basically you just need to parameterize an
existing distributedTest case to run against multiple versions using
Host.getHost(0).getVM(testVersion, vmNumber).  That give you a JVM
that's
set up to use the requested version.  You can then use the normal
method/lambda invocation methods to run code in that JVM.

Currently version "100" (1.0.0-incubating) is available for
backward-compatibility testing.  Versions to be tested are configured in
geode-old-versions/build.gradle as source-sets. Adding a new version is
trivial.

Re: JIRA versions and multiple repos

[Anthony Baker]

> On Jan 19, 2017, at 11:53 AM, Roman Shaposhnik  wrote:
> 
> On Thu, Jan 19, 2017 at 11:21 AM, Dan Smith  wrote:
>> I wonder if we're trying to overcomplicate things there. I don't see why
>> the geode-examples wouldn't use the same release schedule and version
>> number as geode.
>> 
>> The C++ and .NET clients are also somewhat tied to the version of geode
>> that they support. As long as we can stick to a regular release cadence, It
>> seems like those clients couldn't also follow the same release schedule and
>> version numbers.
> 
> Huge +1 to the above!
> 
> Thanks,
> Roman.


Here’s a few examples of ASF projects with multiple repos for reference:

- ActiveMQ
https://github.com/apache?utf8=✓&q=activemq&type=&language=
https://issues.apache.org/jira/secure/BrowseProjects.jspa#11160
- Nifi
https://github.com/apache?utf8=✓&q=nifi&type=&language=
https://issues.apache.org/jira/secure/BrowseProjects.jspa#13460

I agree that semi-coordinated releases from a single project community make 
sense—these are not independent things.  Using lock-step versioning means we 
release everything together, even for patch releases right?  And I’m assuming 
we would be doing separate release VOTE threads per repo.


Anthony

Re: JIRA versions and multiple repos

[Roman Shaposhnik]

On Thu, Jan 19, 2017 at 12:54 PM, Anthony Baker  wrote:
>
>> On Jan 19, 2017, at 11:53 AM, Roman Shaposhnik  wrote:
>>
>> On Thu, Jan 19, 2017 at 11:21 AM, Dan Smith  wrote:
>>> I wonder if we're trying to overcomplicate things there. I don't see why
>>> the geode-examples wouldn't use the same release schedule and version
>>> number as geode.
>>>
>>> The C++ and .NET clients are also somewhat tied to the version of geode
>>> that they support. As long as we can stick to a regular release cadence, It
>>> seems like those clients couldn't also follow the same release schedule and
>>> version numbers.
>>
>> Huge +1 to the above!
>>
>> Thanks,
>> Roman.
>
>
> Here’s a few examples of ASF projects with multiple repos for reference:
>
> - ActiveMQ
> https://github.com/apache?utf8=✓&q=activemq&type=&language=
> https://issues.apache.org/jira/secure/BrowseProjects.jspa#11160
> - Nifi
> https://github.com/apache?utf8=✓&q=nifi&type=&language=
> https://issues.apache.org/jira/secure/BrowseProjects.jspa#13460
>
> I agree that semi-coordinated releases from a single project community make
> sense—these are not independent things.  Using lock-step versioning means
> we release everything together, even for patch releases right?  And I’m
> assuming we would be doing separate release VOTE threads per repo.

An interesting thing to note is that despite multiple repos they still release
a single source artifact:
   https://www.apache.org/dist/activemq/5.13.5/
   https://www.apache.org/dist/nifi/1.1.1/

Thanks,
Roman.

Re: JIRA versions and multiple repos

[John Blum]

I agree with @Dan on the geode-examples bit, but not for a modular Geode.
So...

It depends on whether you are releasing and publishing separate artifacts
to Maven Central (or Bintray and the like) as features are developed/bugs
are fixed (i.e. CI/CD), then it is necessary to distinguish by version
number to avoid collisions/conflicts and e able to consume the bits (which
is much easier than anything else, to do from MC, when developing).

However, when you start talking about Native Client vs. the geode-examples;
those are 2 different animals!

I would even go so far as to say the geode-examples could (and probably,
should) live outside of the (core) Geode codebase.  They do not need to be
released with the product.  They can, be based on a particular
(curated/harmonized) set of Geode dependencies (using the Maven BOM I
described earlier; Spring Data Examples does this, for instance, but SD
Examples are not part of the SD Release Train).

Or, how about, if I come up with another example, perhaps one based on a
customer UC that highlights Geode is some particular way, addressing a very
common, very important problem, which is independent of the Geode codebase,
why should anyone have to wait for another Geode release for this example
to be pushed?

Like the Native Client, arguably, Spring Data Geode is closely tied to
Apache Geode, yet releases separately and independently, at it's own
cadence. That is also not to say 1 does not affect the other (Apache Geode
most certainly affects SDG), but ironically, even though both are OSS
projects with nearly the same "community" behind them, they are separate.


On Thu, Jan 19, 2017 at 1:01 PM, Roman Shaposhnik 
wrote:

> On Thu, Jan 19, 2017 at 12:54 PM, Anthony Baker  wrote:
> >
> >> On Jan 19, 2017, at 11:53 AM, Roman Shaposhnik 
> wrote:
> >>
> >> On Thu, Jan 19, 2017 at 11:21 AM, Dan Smith  wrote:
> >>> I wonder if we're trying to overcomplicate things there. I don't see
> why
> >>> the geode-examples wouldn't use the same release schedule and version
> >>> number as geode.
> >>>
> >>> The C++ and .NET clients are also somewhat tied to the version of geode
> >>> that they support. As long as we can stick to a regular release
> cadence, It
> >>> seems like those clients couldn't also follow the same release
> schedule and
> >>> version numbers.
> >>
> >> Huge +1 to the above!
> >>
> >> Thanks,
> >> Roman.
> >
> >
> > Here’s a few examples of ASF projects with multiple repos for reference:
> >
> > - ActiveMQ
> > https://github.com/apache?utf8=✓&q=activemq&type=&language=
> > https://issues.apache.org/jira/secure/BrowseProjects.jspa#11160
> > - Nifi
> > https://github.com/apache?utf8=✓&q=nifi&type=&language=
> > https://issues.apache.org/jira/secure/BrowseProjects.jspa#13460
> >
> > I agree that semi-coordinated releases from a single project community
> make
> > sense—these are not independent things.  Using lock-step versioning means
> > we release everything together, even for patch releases right?  And I’m
> > assuming we would be doing separate release VOTE threads per repo.
>
> An interesting thing to note is that despite multiple repos they still
> release
> a single source artifact:
>https://www.apache.org/dist/activemq/5.13.5/
>https://www.apache.org/dist/nifi/1.1.1/
>
> Thanks,
> Roman.
>



-- 
-John
john.blum10101 (skype)

Re: JIRA versions and multiple repos

[Udo Kohlmeyer]

I don't know if I necessarily agree with this "lock-step" simplicity, 
every repo/project has the same version. That would become WAY too hard 
to vote on all the time...


I can see scenarios where geode-server might add functionality and which 
clients don't need. Yes, we could version all the clients to be the same 
version as the server code, but then it is really a "superficial" version.


When we get the client protocols sorted and stabilized, I don't see a 
real reason to keep everybody on the same version. I think all clients 
should have the freedom to be on a different versioning strategy. If we 
were to take the "native" client as an example, when we get a pure .Net 
client impl, does it mean we have now bump all related projects (incl. 
server) to the next major? Because in reality a pure .Net impl should be 
a major version.


In addition to that, what about any new client implementations, do we 
start them on 1.0 or whatever the current versioning strategy is 
currently being used by the rest of the clients?


I think documenting (maybe even tracking) what versions of clients will 
work with a version of the server is acceptable.


As John pointed out Spring is a PRIME example of this... The core is due 
to be on 5 soon, but you don't see any of the related projects keep in 
lock-stead with that. Data, Security, Web Services, Cloud, they are 
all on different versions, but somehow play with one another (were 
not mentioning the versioning hell one does go through to get all 
projects on the same version)


I think that we will soon find that even IF we decide to have all the 
projects/repos be on the same version, they will digress ... and I think 
that is ok..


--Udo


On 1/19/17 13:05, John Blum wrote:

I agree with @Dan on the geode-examples bit, but not for a modular Geode.
So...

It depends on whether you are releasing and publishing separate artifacts
to Maven Central (or Bintray and the like) as features are developed/bugs
are fixed (i.e. CI/CD), then it is necessary to distinguish by version
number to avoid collisions/conflicts and e able to consume the bits (which
is much easier than anything else, to do from MC, when developing).

However, when you start talking about Native Client vs. the geode-examples;
those are 2 different animals!

I would even go so far as to say the geode-examples could (and probably,
should) live outside of the (core) Geode codebase.  They do not need to be
released with the product.  They can, be based on a particular
(curated/harmonized) set of Geode dependencies (using the Maven BOM I
described earlier; Spring Data Examples does this, for instance, but SD
Examples are not part of the SD Release Train).

Or, how about, if I come up with another example, perhaps one based on a
customer UC that highlights Geode is some particular way, addressing a very
common, very important problem, which is independent of the Geode codebase,
why should anyone have to wait for another Geode release for this example
to be pushed?

Like the Native Client, arguably, Spring Data Geode is closely tied to
Apache Geode, yet releases separately and independently, at it's own
cadence. That is also not to say 1 does not affect the other (Apache Geode
most certainly affects SDG), but ironically, even though both are OSS
projects with nearly the same "community" behind them, they are separate.


On Thu, Jan 19, 2017 at 1:01 PM, Roman Shaposhnik 
wrote:


On Thu, Jan 19, 2017 at 12:54 PM, Anthony Baker  wrote:

On Jan 19, 2017, at 11:53 AM, Roman Shaposhnik 

wrote:

On Thu, Jan 19, 2017 at 11:21 AM, Dan Smith  wrote:

I wonder if we're trying to overcomplicate things there. I don't see

why

the geode-examples wouldn't use the same release schedule and version
number as geode.

The C++ and .NET clients are also somewhat tied to the version of geode
that they support. As long as we can stick to a regular release

cadence, It

seems like those clients couldn't also follow the same release

schedule and

version numbers.

Huge +1 to the above!

Thanks,
Roman.


Here’s a few examples of ASF projects with multiple repos for reference:

- ActiveMQ
 https://github.com/apache?utf8=✓&q=activemq&type=&language=
 https://issues.apache.org/jira/secure/BrowseProjects.jspa#11160
- Nifi
 https://github.com/apache?utf8=✓&q=nifi&type=&language=
 https://issues.apache.org/jira/secure/BrowseProjects.jspa#13460

I agree that semi-coordinated releases from a single project community

make

sense—these are not independent things.  Using lock-step versioning means
we release everything together, even for patch releases right?  And I’m
assuming we would be doing separate release VOTE threads per repo.

An interesting thing to note is that despite multiple repos they still
release
a single source artifact:
https://www.apache.org/dist/activemq/5.13.5/
https://www.apache.org/dist/nifi/1.1.1/

Thanks,
Roman.

Re: JIRA versions and multiple repos

[John Blum]

+1 to all the (excellent) points Udo made...

Also to address this concern...

> were not mentioning the versioning hell one does go through to get all
projects on the same version

This is exactly the reason for having a Maven BOM file.  And, is exactly
the reason the Spring IO Platform (http://platform.spring.io/platform/) exists,
give the vast Spring ecosystem and significant number of 3rd party
dependencies.

I want to emphasize one more time... it is not logical to hold up
individual parts of Geode just for other parts to catch up, feature/crucial
bug-fix wise, what-have-you (or worse, superficially bump a version number
because Native Client, for example, had a release).  It is also not logic
for a new client to some in as version 1.1.0 or later.  This is the same
monolithic, glacial pace that plagued GemFire into long release cycles of
the past with very slow time-to-improvements.

1 thing is for certain, you cannot move that many complex pieces at a
predictable and reliably quick pace for long.


On Thu, Jan 19, 2017 at 1:13 PM, Udo Kohlmeyer 
wrote:

> I don't know if I necessarily agree with this "lock-step" simplicity,
> every repo/project has the same version. That would become WAY too hard to
> vote on all the time...
>
> I can see scenarios where geode-server might add functionality and which
> clients don't need. Yes, we could version all the clients to be the same
> version as the server code, but then it is really a "superficial" version.
>
> When we get the client protocols sorted and stabilized, I don't see a real
> reason to keep everybody on the same version. I think all clients should
> have the freedom to be on a different versioning strategy. If we were to
> take the "native" client as an example, when we get a pure .Net client
> impl, does it mean we have now bump all related projects (incl. server) to
> the next major? Because in reality a pure .Net impl should be a major
> version.
>
> In addition to that, what about any new client implementations, do we
> start them on 1.0 or whatever the current versioning strategy is currently
> being used by the rest of the clients?
>
> I think documenting (maybe even tracking) what versions of clients will
> work with a version of the server is acceptable.
>
> As John pointed out Spring is a PRIME example of this... The core is due
> to be on 5 soon, but you don't see any of the related projects keep in
> lock-stead with that. Data, Security, Web Services, Cloud, they are all
> on different versions, but somehow play with one another (were not
> mentioning the versioning hell one does go through to get all projects on
> the same version)
>
> I think that we will soon find that even IF we decide to have all the
> projects/repos be on the same version, they will digress ... and I think
> that is ok..
>
> --Udo
>
>
>
> On 1/19/17 13:05, John Blum wrote:
>
>> I agree with @Dan on the geode-examples bit, but not for a modular Geode.
>> So...
>>
>> It depends on whether you are releasing and publishing separate artifacts
>> to Maven Central (or Bintray and the like) as features are developed/bugs
>> are fixed (i.e. CI/CD), then it is necessary to distinguish by version
>> number to avoid collisions/conflicts and e able to consume the bits (which
>> is much easier than anything else, to do from MC, when developing).
>>
>> However, when you start talking about Native Client vs. the
>> geode-examples;
>> those are 2 different animals!
>>
>> I would even go so far as to say the geode-examples could (and probably,
>> should) live outside of the (core) Geode codebase.  They do not need to be
>> released with the product.  They can, be based on a particular
>> (curated/harmonized) set of Geode dependencies (using the Maven BOM I
>> described earlier; Spring Data Examples does this, for instance, but SD
>> Examples are not part of the SD Release Train).
>>
>> Or, how about, if I come up with another example, perhaps one based on a
>> customer UC that highlights Geode is some particular way, addressing a
>> very
>> common, very important problem, which is independent of the Geode
>> codebase,
>> why should anyone have to wait for another Geode release for this example
>> to be pushed?
>>
>> Like the Native Client, arguably, Spring Data Geode is closely tied to
>> Apache Geode, yet releases separately and independently, at it's own
>> cadence. That is also not to say 1 does not affect the other (Apache Geode
>> most certainly affects SDG), but ironically, even though both are OSS
>> projects with nearly the same "community" behind them, they are separate.
>>
>>
>> On Thu, Jan 19, 2017 at 1:01 PM, Roman Shaposhnik 
>> wrote:
>>
>> On Thu, Jan 19, 2017 at 12:54 PM, Anthony Baker 
>>> wrote:
>>>
 On Jan 19, 2017, at 11:53 AM, Roman Shaposhnik 
>
 wrote:
>>>
 On Thu, Jan 19, 2017 at 11:21 AM, Dan Smith  wrote:
>
>> I wonder if we're trying to overcomplicate things there. I don't see
>>
> why
>>>
 the geode-example

Re: backward-compatibility testing

[Dan Smith]

>
> The restriction on letting old-version members join is for rolling upgrade
> and has been in Geode & GemFire for a long time.  It gives us some
> assurance that we can enable new distributed algorithms and stop using old
> algorithms. We ran into that requirement when we altered distributed
> locking behavior in GemFire.


Ah, I was missing that, that clears things up quite a bit. I do wonder if
we still need this restriction, but maybe it makes sense to keep it.

One way to do this would be to have the DUnit Locator run the oldest
> version of Geode that we want to test with.  For now that would be
> 1.0.0-incubating.  Any test that needs to exercise newer algorithms
> involving a Locator would need to launch one of its own.
>

Does this mean *all* tests would run with an old locator, not just
backwards compatibility tests?  If this is just for backwards compatibility
tests, this sounds pretty reasonable.

-Dan

On Thu, Jan 19, 2017 at 11:06 AM, Bruce Schuchardt 
wrote:

> One way to do this would be to have the DUnit Locator run the oldest
> version of Geode that we want to test with.  For now that would be
> 1.0.0-incubating.  Any test that needs to exercise newer algorithms
> involving a Locator would need to launch one of its own.
>
> Does that sound acceptable?
>
>
> Le 1/19/2017 à 9:27 AM, Bruce Schuchardt a écrit :
>
>> Thanks Dan.  I'm not sure we want to keep the change I made to the
>> Locator.  The restriction on letting old-version members join is for
>> rolling upgrade and has been in Geode & GemFire for a long time.  It gives
>> us some assurance that we can enable new distributed algorithms and stop
>> using old algorithms. We ran into that requirement when we altered
>> distributed locking behavior in GemFire.
>>
>> If I revert that change it will require that any test starting a peer
>> cache using an old version of Geode must create its own old-version
>> Locator.  That's probably the best thing to do because the way I have it
>> right now might make it very hard to implement new algorithms that involve
>> the Locator.  If an old-version peer starts up and the Locator sends it a
>> message it doesn't comprehend, or the Locator expects it to do something
>> and it doesn't, it could be difficult to deal with.
>>
>> Le 1/19/2017 à 9:07 AM, Dan Smith a écrit :
>>
>>> +1 This is great Bruce! I really like this approach of being able to
>>> write
>>> tests and have them run with some members with a different version. I
>>> think
>>> with this framework we should be able to just extend existing tests with
>>> subclasses that override the version of some of the VMs which I think is
>>> a
>>> good way to do the backwards compatibility testing.
>>>
>>> One question - you modified the locator to allow old versions to join.
>>> Why
>>> was that necessary? I know we broke P2P compatibility between gemfire 8
>>> and
>>> geode 1.0, but are we not allowing P2P compatibility going forward? I was
>>> under the impression that 1.1 was going to be compatible with 1.0. Is
>>> that
>>> not the case? Why do the tests need to have peers with different versions
>>> if we are not supporting that? Is there a way we can do these tests
>>> without
>>> having the product code behave differently when it is being tested than
>>> when it is being used normally?
>>>
>>> -Dan
>>>
>>>
>>>
>>> On Wed, Jan 18, 2017 at 3:11 PM, Bruce Schuchardt <
>>> bschucha...@pivotal.io>
>>> wrote:
>>>
>>> I've extended the distributedTest framework to let us do
 backward-compatibility testing.  Once it is reviewed and committed
 people
 will be needed to modify existing tests to run against multiple
 versions of
 Geode.

 Here is the RB review: https://reviews.apache.org/r/55688/

 The diff in this review includes a client/server test modified to run
 against multiple versions.  Basically you just need to parameterize an
 existing distributedTest case to run against multiple versions using
 Host.getHost(0).getVM(testVersion, vmNumber).  That give you a JVM
 that's
 set up to use the requested version.  You can then use the normal
 method/lambda invocation methods to run code in that JVM.

 Currently version "100" (1.0.0-incubating) is available for
 backward-compatibility testing.  Versions to be tested are configured in
 geode-old-versions/build.gradle as source-sets. Adding a new version is
 trivial.


>>
>

[jira] [Created] (GEODE-2327) Query engine doesn't handle bigInteger

[Hitesh Khamesra (JIRA)]

Hitesh Khamesra created GEODE-2327:
--

 Summary: Query engine doesn't handle bigInteger
 Key: GEODE-2327
 URL: https://issues.apache.org/jira/browse/GEODE-2327
 Project: Geode
  Issue Type: Bug
  Components: querying
Reporter: Hitesh Khamesra


org.apache.geode.cache.query.QueryInvalidException: Syntax error in query:  
unable to parse integer:  312473274897238947238741074170984
at 
org.apache.geode.cache.query.internal.QCompiler.compileQuery(QCompiler.java:85)
at 
org.apache.geode.cache.query.internal.DefaultQuery.(DefaultQuery.java:275)
at 
org.apache.geode.cache.query.internal.DefaultQueryService.newQuery(DefaultQueryService.java:106)
at 
org.apache.geode.pdx.JSONFormatterJUnitTest.testJSONDocWithQuery(JSONFormatterJUnitTest.java:372)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
at 
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
Caused by: org.apache.geode.cache.query.QueryInvalidException: unable to parse 
integer:  312473274897238947238741074170984
at 
org.apache.geode.cache.query.internal.parse.ASTLiteral.getInt(ASTLiteral.java:74)
at 
org.apache.geode.cache.query.internal.parse.ASTLiteral.computeValue(ASTLiteral.java:41)
at 
org.apache.geode.cache.query.internal.parse.ASTLiteral.compile(ASTLiteral.java:135)
at 
org.apache.geode.cache.query.internal.parse.GemFireAST.childrenCompile(GemFireAST.java:53)
at 
org.apache.geode.cache.query.internal.parse.GemFireAST.compile(GemFireAST.java:47)
at 
org.apache.geode.cache.query.internal.parse.ASTCompareOp.compile(ASTCompareOp.java:33)
at 
org.apache.geode.cache.query.internal.parse.ASTSelect.compile(ASTSelect.java:56)
at 
org.apache.geode.cache.query.internal.parse.GemFireAST.childrenCompile(GemFireAST.java:53)
at 
org.apache.geode.cache.query.internal.parse.GemFireAST.compile(GemFireAST.java:47)
at 
org.apache.geode.cache.query.internal.QCompiler.compileQuery(QCompiler.java:82)
... 28 more
Caused by: java.lang.NumberFormatException: For input string: 
"312473274897238947238741074170984"
at 
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:583)
at java.lang.Integer.valueOf(Integer.java:766)
at 
org.apache.geode.cache.query.internal.parse.ASTLiteral.getInt(ASTLiteral.java:72)
... 37 more



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-1409) Pulse view does not display cluster and members when in France

[Eitan Suez (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15830657#comment-15830657
 ] 

Eitan Suez commented on GEODE-1409:
---

hello, i reported this issue back in May.  can we get an eta for a fix?  it 
basically renders pulse unusable [i suspect] in most european locales.  i see 
someone else stumbled across this same problem recently in geode-2321 
(duplicate).

> Pulse view does not display cluster and members when in France
> --
>
> Key: GEODE-1409
> URL: https://issues.apache.org/jira/browse/GEODE-1409
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Reporter: Eitan Suez
>
> If you setup your cluster with user.country=FR and user.language=fr (france) 
> when starting your locator and servers, then when you start pulse, log in, 
> you will not see your cluster nor any members.
> the reason is that the http post that the client does to the pulse controller 
> (/pulseUpdate) does not return members.
> we see this in the pulse logs:
> [WARNING 2016/05/17 10:15:56.489 CEST qtp22145019-209 tid=0xd1] (msgTID=209 
> msgSN=29665) [PULSE]
> [com.vmware.gemfire.tools.pulse.internal.log.PulseLogWriter]
> serviceException [for service ClusterMembersRGraph] = For input string: 
> "30,58"
>  
> it looks like the service exception might have some kind of number parsing 
> exception when encountering numeric values formatted according to the french 
> locale.  so it encounters 30,58 and doesn't properly interpret it as 30.58.. 
> that has the side effect of fetching cluster information not returning 
> anything.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2327) Query engine doesn't handle bigInteger

[Hitesh Khamesra (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15830664#comment-15830664
 ] 

Hitesh Khamesra commented on GEODE-2327:


Here is test

 @Test
  public void testJSONDocWithQuery() throws Exception {

try {
Cache c = CacheFactory.getAnyInstance();

  Region region = c.getRegion("primitiveKVStore");
  
  BigInteger bi = new BigInteger("312473274897238947238741074170984");
  
  //long bi = Integer.MAX_VALUE * 1000; 

  String js = "{b:\"b\", age:" + bi.toString() +  ", c:\"c' go\", bb:23}";

  region.put(1, JSONFormatter.fromJSON(js));

  PdxInstance ret = (PdxInstance) region.get(1);
  List fieldNames = ret.getFieldNames();

  String qs = "select * from /primitiveKVStore where age != " + 
bi.longValue();
  
  System.out.println("Return object " + qs);;
  Object ob = c.getQueryService().newQuery(qs).execute();
  System.out.println("Return object " + ob.getClass());;
  System.out.println("Return object " + ob.toString());;
  System.out.println("Return object " + qs);;
  
} finally {
  JSONFormatter.SORT_JSON_FIELD_NAMES = false;
}
  }

> Query engine doesn't handle bigInteger
> --
>
> Key: GEODE-2327
> URL: https://issues.apache.org/jira/browse/GEODE-2327
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: Hitesh Khamesra
>
> org.apache.geode.cache.query.QueryInvalidException: Syntax error in query:  
> unable to parse integer:  312473274897238947238741074170984
>   at 
> org.apache.geode.cache.query.internal.QCompiler.compileQuery(QCompiler.java:85)
>   at 
> org.apache.geode.cache.query.internal.DefaultQuery.(DefaultQuery.java:275)
>   at 
> org.apache.geode.cache.query.internal.DefaultQueryService.newQuery(DefaultQueryService.java:106)
>   at 
> org.apache.geode.pdx.JSONFormatterJUnitTest.testJSONDocWithQuery(JSONFormatterJUnitTest.java:372)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
>   at 
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: org.apache.geode.cache.query.QueryInvalidException: unable to 
> parse integer:  312473274897238947238741074170984
>   at 
> org.apache.geode.cache.query.internal.parse.ASTLiteral.getInt(ASTLiteral.java:74)
>   at 
> org.apache.geode.cache.query.internal.parse.ASTLiteral.computeValue(ASTLiteral.java:41)
>   at 
> org.apache.geode.cache.query.internal.parse.ASTLiteral.compile(ASTLiteral.java:135)
>   at 
> org.apache.geode.cache.query.internal.parse.GemFireAST.childrenCompile(GemFireAST.java:53)
>   at 
> org.apache.geode.cache.query.internal.parse.GemFireAST.compile(GemFireAST.java:47)
>   at 
> 

[jira] [Commented] (GEODE-2327) Query engine doesn't handle bigInteger

[Hitesh Khamesra (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15830668#comment-15830668
 ] 

Hitesh Khamesra commented on GEODE-2327:


Now even parse long

org.apache.geode.cache.query.QueryInvalidException: Syntax error in query:  
unable to parse integer:  37489374897
at 
org.apache.geode.cache.query.internal.QCompiler.compileQuery(QCompiler.java:85)
at 
org.apache.geode.cache.query.internal.DefaultQuery.(DefaultQuery.java:275)
at 
org.apache.geode.cache.query.internal.DefaultQueryService.newQuery(DefaultQueryService.java:106)
at 
org.apache.geode.pdx.JSONFormatterJUnitTest.testJSONDocWithQuery(JSONFormatterJUnitTest.java:378)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
at 
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
Caused by: org.apache.geode.cache.query.QueryInvalidException: unable to parse 
integer:  37489374897
at 
org.apache.geode.cache.query.internal.parse.ASTLiteral.getInt(ASTLiteral.java:74)
at 
org.apache.geode.cache.query.internal.parse.ASTLiteral.computeValue(ASTLiteral.java:41)
at 
org.apache.geode.cache.query.internal.parse.ASTLiteral.compile(ASTLiteral.java:135)
at 
org.apache.geode.cache.query.internal.parse.GemFireAST.childrenCompile(GemFireAST.java:53)
at 
org.apache.geode.cache.query.internal.parse.GemFireAST.compile(GemFireAST.java:47)
at 
org.apache.geode.cache.query.internal.parse.ASTCompareOp.compile(ASTCompareOp.java:33)
at 
org.apache.geode.cache.query.internal.parse.ASTSelect.compile(ASTSelect.java:56)
at 
org.apache.geode.cache.query.internal.parse.GemFireAST.childrenCompile(GemFireAST.java:53)
at 
org.apache.geode.cache.query.internal.parse.GemFireAST.compile(GemFireAST.java:47)
at 
org.apache.geode.cache.query.internal.QCompiler.compileQuery(QCompiler.java:82)
... 28 more
Caused by: java.lang.NumberFormatException: For input string: "37489374897"
at 
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:583)
at java.lang.Integer.valueOf(Integer.java:766)
at 
org.apache.geode.cache.query.internal.parse.ASTLiteral.getInt(ASTLiteral.java:72)
... 37 more



> Query engine doesn't handle bigInteger
> --
>
> Key: GEODE-2327
> URL: https://issues.apache.org/jira/browse/GEODE-2327
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: Hitesh Khamesra
>
> org.apache.geode.cache.query.QueryInvalidException: Syntax error in query:  
> unable to parse integer:  312473274897238947238741074170984
>   at 
> org.apache.geode.cache.query.internal.QCompiler.compileQuery(QComp

[jira] [Commented] (GEODE-2327) Query engine doesn't handle bigInteger

[Hitesh Khamesra (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15830687#comment-15830687
 ] 

Hitesh Khamesra commented on GEODE-2327:


With bind parameter it works...

> Query engine doesn't handle bigInteger
> --
>
> Key: GEODE-2327
> URL: https://issues.apache.org/jira/browse/GEODE-2327
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: Hitesh Khamesra
>
> org.apache.geode.cache.query.QueryInvalidException: Syntax error in query:  
> unable to parse integer:  312473274897238947238741074170984
>   at 
> org.apache.geode.cache.query.internal.QCompiler.compileQuery(QCompiler.java:85)
>   at 
> org.apache.geode.cache.query.internal.DefaultQuery.(DefaultQuery.java:275)
>   at 
> org.apache.geode.cache.query.internal.DefaultQueryService.newQuery(DefaultQueryService.java:106)
>   at 
> org.apache.geode.pdx.JSONFormatterJUnitTest.testJSONDocWithQuery(JSONFormatterJUnitTest.java:372)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
>   at 
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: org.apache.geode.cache.query.QueryInvalidException: unable to 
> parse integer:  312473274897238947238741074170984
>   at 
> org.apache.geode.cache.query.internal.parse.ASTLiteral.getInt(ASTLiteral.java:74)
>   at 
> org.apache.geode.cache.query.internal.parse.ASTLiteral.computeValue(ASTLiteral.java:41)
>   at 
> org.apache.geode.cache.query.internal.parse.ASTLiteral.compile(ASTLiteral.java:135)
>   at 
> org.apache.geode.cache.query.internal.parse.GemFireAST.childrenCompile(GemFireAST.java:53)
>   at 
> org.apache.geode.cache.query.internal.parse.GemFireAST.compile(GemFireAST.java:47)
>   at 
> org.apache.geode.cache.query.internal.parse.ASTCompareOp.compile(ASTCompareOp.java:33)
>   at 
> org.apache.geode.cache.query.internal.parse.ASTSelect.compile(ASTSelect.java:56)
>   at 
> org.apache.geode.cache.query.internal.parse.GemFireAST.childrenCompile(GemFireAST.java:53)
>   at 
> org.apache.geode.cache.query.internal.parse.GemFireAST.compile(GemFireAST.java:47)
>   at 
> org.apache.geode.cache.query.internal.QCompiler.compileQuery(QCompiler.java:82)
>   ... 28 more
> Caused by: java.lang.NumberFormatException: For input string: 
> "312473274897238947238741074170984"
>   at 
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
>   at java.lang.Integer.parseInt(Integer.java:583)
>   at java.lang.Integer.valueOf(Integer.java:766)
>   at 
> org.apache.geode.cache.query.internal.parse.ASTLiteral.getInt(ASTLiteral.java:72)
>   ... 37 more



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2327) Query engine doesn't handle bigInteger

[Jason Huynh (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15830689#comment-15830689
 ] 

Jason Huynh commented on GEODE-2327:


As a temporary work around, passing in the BigInteger as a bind parameter will 
work.

> Query engine doesn't handle bigInteger
> --
>
> Key: GEODE-2327
> URL: https://issues.apache.org/jira/browse/GEODE-2327
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: Hitesh Khamesra
>
> org.apache.geode.cache.query.QueryInvalidException: Syntax error in query:  
> unable to parse integer:  312473274897238947238741074170984
>   at 
> org.apache.geode.cache.query.internal.QCompiler.compileQuery(QCompiler.java:85)
>   at 
> org.apache.geode.cache.query.internal.DefaultQuery.(DefaultQuery.java:275)
>   at 
> org.apache.geode.cache.query.internal.DefaultQueryService.newQuery(DefaultQueryService.java:106)
>   at 
> org.apache.geode.pdx.JSONFormatterJUnitTest.testJSONDocWithQuery(JSONFormatterJUnitTest.java:372)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
>   at 
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: org.apache.geode.cache.query.QueryInvalidException: unable to 
> parse integer:  312473274897238947238741074170984
>   at 
> org.apache.geode.cache.query.internal.parse.ASTLiteral.getInt(ASTLiteral.java:74)
>   at 
> org.apache.geode.cache.query.internal.parse.ASTLiteral.computeValue(ASTLiteral.java:41)
>   at 
> org.apache.geode.cache.query.internal.parse.ASTLiteral.compile(ASTLiteral.java:135)
>   at 
> org.apache.geode.cache.query.internal.parse.GemFireAST.childrenCompile(GemFireAST.java:53)
>   at 
> org.apache.geode.cache.query.internal.parse.GemFireAST.compile(GemFireAST.java:47)
>   at 
> org.apache.geode.cache.query.internal.parse.ASTCompareOp.compile(ASTCompareOp.java:33)
>   at 
> org.apache.geode.cache.query.internal.parse.ASTSelect.compile(ASTSelect.java:56)
>   at 
> org.apache.geode.cache.query.internal.parse.GemFireAST.childrenCompile(GemFireAST.java:53)
>   at 
> org.apache.geode.cache.query.internal.parse.GemFireAST.compile(GemFireAST.java:47)
>   at 
> org.apache.geode.cache.query.internal.QCompiler.compileQuery(QCompiler.java:82)
>   ... 28 more
> Caused by: java.lang.NumberFormatException: For input string: 
> "312473274897238947238741074170984"
>   at 
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
>   at java.lang.Integer.parseInt(Integer.java:583)
>   at java.lang.Integer.valueOf(Integer.java:766)
>   at 
> org.apache.geode.cache.query.internal.parse.ASTLiteral.getInt(ASTLiteral.java:72)
>   ... 37 more



--
This message was 

Re: backward-compatibility testing

[Roman Shaposhnik]

This is very interesting and it reminds me to ask this: how separable
do you think DUnit could be from Geode?

I'm thinking that it could be very useful in other Java-based
distributed projects around ASF.

Thanks,
Roman.

On Wed, Jan 18, 2017 at 3:11 PM, Bruce Schuchardt
 wrote:
> I've extended the distributedTest framework to let us do
> backward-compatibility testing.  Once it is reviewed and committed people
> will be needed to modify existing tests to run against multiple versions of
> Geode.
>
> Here is the RB review: https://reviews.apache.org/r/55688/
>
> The diff in this review includes a client/server test modified to run
> against multiple versions.  Basically you just need to parameterize an
> existing distributedTest case to run against multiple versions using
> Host.getHost(0).getVM(testVersion, vmNumber).  That give you a JVM that's
> set up to use the requested version.  You can then use the normal
> method/lambda invocation methods to run code in that JVM.
>
> Currently version "100" (1.0.0-incubating) is available for
> backward-compatibility testing.  Versions to be tested are configured in
> geode-old-versions/build.gradle as source-sets. Adding a new version is
> trivial.

Re: New committers added to Geode Site Community page

[Roman Shaposhnik]

Congrats indeed! Great to have you onboard!

Roman.

On Thu, Jan 19, 2017 at 10:39 AM, Jared Stewart  wrote:
> Congrats guys!!
>> On Jan 19, 2017, at 10:24 AM, Dave Barnes  wrote:
>>
>> Ken Howe and Kevin Duling have been added to the website's Committers list.
>> Welcome, Ken and Kevin!
>

Re: backward-compatibility testing

[Bruce Schuchardt]

It would be nice to know if a test is going to use an old version. Then 
we could boot the appropriate locator for it.  I don't have anything 
like that implemented yet - there is still only one locator prestarted 
by the DUnit launcher.


Le 1/19/2017 à 1:30 PM, Dan Smith a écrit :

Does this mean*all*  tests would run with an old locator, not just
backwards compatibility tests?  If this is just for backwards compatibility
tests, this sounds pretty reasonable.

Re: JIRA versions and multiple repos

[Anthony Baker]

> On Jan 19, 2017, at 1:01 PM, Roman Shaposhnik  wrote:
> 
> On Thu, Jan 19, 2017 at 12:54 PM, Anthony Baker  > wrote:
>> 
>>> On Jan 19, 2017, at 11:53 AM, Roman Shaposhnik  wrote:
>>> 
>>> On Thu, Jan 19, 2017 at 11:21 AM, Dan Smith  wrote:
 I wonder if we're trying to overcomplicate things there. I don't see why
 the geode-examples wouldn't use the same release schedule and version
 number as geode.
 
 The C++ and .NET clients are also somewhat tied to the version of geode
 that they support. As long as we can stick to a regular release cadence, It
 seems like those clients couldn't also follow the same release schedule and
 version numbers.
>>> 
>>> Huge +1 to the above!
>>> 
>>> Thanks,
>>> Roman.
>> 
>> 
>> Here’s a few examples of ASF projects with multiple repos for reference:
>> 
>> - ActiveMQ
>>https://github.com/apache?utf8=✓&q=activemq&type=&language=
>>https://issues.apache.org/jira/secure/BrowseProjects.jspa#11160
>> - Nifi
>>https://github.com/apache?utf8=✓&q=nifi&type=&language=
>>https://issues.apache.org/jira/secure/BrowseProjects.jspa#13460
>> 
>> I agree that semi-coordinated releases from a single project community make
>> sense—these are not independent things.  Using lock-step versioning means
>> we release everything together, even for patch releases right?  And I’m
>> assuming we would be doing separate release VOTE threads per repo.
> 
> An interesting thing to note is that despite multiple repos they still release
> a single source artifact:
>   https://www.apache.org/dist/activemq/5.13.5/ 
> 
>   https://www.apache.org/dist/nifi/1.1.1/ 
> 
> 
> Thanks,
> Roman.

FWIW, it looks to me like these projects are doing releases from each of their 
repos:

https://www.apache.org/dist/activemq/activemq-apollo/1.7.1/
https://www.apache.org/dist/activemq/activemq-artemis/1.5.1/
https://www.apache.org/dist/activemq/activemq-cpp/3.9.3/
https://www.apache.org/dist/nifi/minifi/0.1.0/
https://www.apache.org/dist/nifi/nifi-minifi-cpp/0.1.0/
https://www.apache.org/dist/nifi/nifi-nar-maven-plugin-1.1.0/

Which is not to say that is how Geode should operate, but I’m just looking for 
precedent and prior art :-)

Anthony

Re: JIRA versions and multiple repos

[Roman Shaposhnik]

On Thu, Jan 19, 2017 at 2:23 PM, Anthony Baker  wrote:
>
>> On Jan 19, 2017, at 1:01 PM, Roman Shaposhnik  wrote:
>>
>> On Thu, Jan 19, 2017 at 12:54 PM, Anthony Baker > > wrote:
>>>
 On Jan 19, 2017, at 11:53 AM, Roman Shaposhnik  
 wrote:

 On Thu, Jan 19, 2017 at 11:21 AM, Dan Smith  wrote:
> I wonder if we're trying to overcomplicate things there. I don't see why
> the geode-examples wouldn't use the same release schedule and version
> number as geode.
>
> The C++ and .NET clients are also somewhat tied to the version of geode
> that they support. As long as we can stick to a regular release cadence, 
> It
> seems like those clients couldn't also follow the same release schedule 
> and
> version numbers.

 Huge +1 to the above!

 Thanks,
 Roman.
>>>
>>>
>>> Here’s a few examples of ASF projects with multiple repos for reference:
>>>
>>> - ActiveMQ
>>>https://github.com/apache?utf8=✓&q=activemq&type=&language=
>>>https://issues.apache.org/jira/secure/BrowseProjects.jspa#11160
>>> - Nifi
>>>https://github.com/apache?utf8=✓&q=nifi&type=&language=
>>>https://issues.apache.org/jira/secure/BrowseProjects.jspa#13460
>>>
>>> I agree that semi-coordinated releases from a single project community make
>>> sense—these are not independent things.  Using lock-step versioning means
>>> we release everything together, even for patch releases right?  And I’m
>>> assuming we would be doing separate release VOTE threads per repo.
>>
>> An interesting thing to note is that despite multiple repos they still 
>> release
>> a single source artifact:
>>   https://www.apache.org/dist/activemq/5.13.5/ 
>> 
>>   https://www.apache.org/dist/nifi/1.1.1/ 
>> 
>>
>> Thanks,
>> Roman.
>
> FWIW, it looks to me like these projects are doing releases from each of 
> their repos:
>
> https://www.apache.org/dist/activemq/activemq-apollo/1.7.1/
> https://www.apache.org/dist/activemq/activemq-artemis/1.5.1/
> https://www.apache.org/dist/activemq/activemq-cpp/3.9.3/

I'm actually not sure what the status of these is sine I can't seem to find
those on the official download page:
http://activemq.apache.org/download.html

> https://www.apache.org/dist/nifi/minifi/0.1.0/
> https://www.apache.org/dist/nifi/nifi-minifi-cpp/0.1.0/
> https://www.apache.org/dist/nifi/nifi-nar-maven-plugin-1.1.0/

Ditt for NiFi. In fact, as far as minifi is concerned -- I'm pretty
sure it is still
considered to be 'do not try this at home'.

> Which is not to say that is how Geode should operate, but I’m just looking 
> for precedent and prior art :-)

But that's my point -- I don't think it constitutes prior art. In fact
the only prior art I'm
aware of would be Apache Commons (which actually does explicitly split
the community).

Thanks,
Roman.

Re: Is Dunit separable?

[Bruce Schuchardt]

Hi Roman,

DUnit is an RMI-based system.  The only ties it has to Geode are that it 
creates a Locator before running tests.


Le 1/19/2017 à 2:07 PM, Roman Shaposhnik a écrit :

This is very interesting and it reminds me to ask this: how separable
do you think DUnit could be from Geode?

I'm thinking that it could be very useful in other Java-based
distributed projects around ASF.

Thanks,
Roman.

On Wed, Jan 18, 2017 at 3:11 PM, Bruce Schuchardt
 wrote:

I've extended the distributedTest framework to let us do
backward-compatibility testing.  Once it is reviewed and committed people
will be needed to modify existing tests to run against multiple versions of
Geode.

Here is the RB review: https://reviews.apache.org/r/55688/

The diff in this review includes a client/server test modified to run
against multiple versions.  Basically you just need to parameterize an
existing distributedTest case to run against multiple versions using
Host.getHost(0).getVM(testVersion, vmNumber).  That give you a JVM that's
set up to use the requested version.  You can then use the normal
method/lambda invocation methods to run code in that JVM.

Currently version "100" (1.0.0-incubating) is available for
backward-compatibility testing.  Versions to be tested are configured in
geode-old-versions/build.gradle as source-sets. Adding a new version is
trivial.

Re: Is Dunit separable?

[Roman Shaposhnik]

On Thu, Jan 19, 2017 at 2:30 PM, Bruce Schuchardt
 wrote:
> Hi Roman,
>
> DUnit is an RMI-based system.  The only ties it has to Geode are that it
> creates a Locator before running tests.

Is there a separate doc for it? Suppose I wanted to use DUnit to test, lets
say, Zookeeper -- where would I start so that I can write my first testcase?

Thanks,
Roman.

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #444 has FAILED (11 tests failed, no failures were new)

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #444 failed.
---
Scheduled
11/1614 tests failed, no failures were new.

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

-
Currently Responsible
-

John Blum 



--
Failing Jobs
--
  - Default Job (Default Stage): 11 of 1614 tests failed.




--
Tests
--
Existing Test Failures (11)
   - ClientSubRegionTest: Org.springframework.data.gemfire.client. client sub 
region test
   - GemFireDataSourceTest: Org.springframework.data.gemfire.client. gem fire 
data source test
   - GemFireDataSourceWithLocalRegionTest: 
Org.springframework.data.gemfire.client. gem fire data source with local region 
test
   - ContinuousQueryListenerContainerNamespaceTest: 
Org.springframework.data.gemfire.config.xml. continuous query listener 
container namespace test
   - ClientCacheFunctionExecutionWithPdxIntegrationTest: 
Org.springframework.data.gemfire.function. client cache function execution with 
pdx integration test
   - FunctionExecutionTests: 
Org.springframework.data.gemfire.function.execution. function execution tests
   - FunctionIntegrationTests: 
Org.springframework.data.gemfire.function.execution. function integration tests
   - GemfireFunctionTemplateTests: 
Org.springframework.data.gemfire.function.execution. gemfire function template 
tests
   - ListenerContainerTests: Org.springframework.data.gemfire.listener. 
listener container tests
   - ContainerXmlSetupTest: Org.springframework.data.gemfire.listener.adapter. 
container xml setup test
   - RepositoryClientRegionTests: 
Org.springframework.data.gemfire.repository.config. repository client region 
tests

--
This message is automatically generated by Atlassian Bamboo

[jira] [Commented] (GEODE-2321) Pulse application works incorrectly in some locales

[Jared Stewart (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15830756#comment-15830756
 ] 

Jared Stewart commented on GEODE-2321:
--

Here is the stack trace: 

```
serviceException [for service ClusterDetails]
java.lang.NumberFormatException: For input string: "7,11"
at 
sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:2043)
at sun.misc.FloatingDecimal.parseDouble(FloatingDecimal.java:110)
at java.lang.Double.parseDouble(Double.java:538)
at java.lang.Double.valueOf(Double.java:502)
at 
org.apache.geode.tools.pulse.internal.service.ClusterDetailsService.execute(ClusterDetailsService.java:90)
at 
org.apache.geode.tools.pulse.internal.controllers.PulseController.getPulseUpdate(PulseController.java:105)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:221)
at 
org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:136)
at 
org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:114)
at 
org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:827)
at 
org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:738)
at 
org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:85)
at 
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:963)
at 
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:897)
at 
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:970)
at 
org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:872)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at 
org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:846)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at 
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:821)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1685)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:317)
at 
org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:127)
at 
org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:91)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
at 
org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:115)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
at 
org.springframework.security.web.session.SessionManagementFilter.doFilter(SessionManagementFilter.java:137)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
at 
org.springframework.security.web.authentication.AnonymousAuthenticationFilter.doFilter(AnonymousAuthenticationFilter.java:111)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
at 
org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:169)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
at 
org.springframework.security.web.savedrequest.RequestCacheAwareFilter.doFilter(RequestCacheAwareFilter.java:63)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
at 
org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilterInternal(BasicAuthenticationFilter.java:158)
at 
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
at 
org.springframewo

[jira] [Comment Edited] (GEODE-2321) Pulse application works incorrectly in some locales

[Jared Stewart (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15830756#comment-15830756
 ] 

Jared Stewart edited comment on GEODE-2321 at 1/19/17 10:53 PM:


Here is the stack trace: 

{code:java}
serviceException [for service ClusterDetails]
java.lang.NumberFormatException: For input string: "7,11"
at 
sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:2043)
at sun.misc.FloatingDecimal.parseDouble(FloatingDecimal.java:110)
at java.lang.Double.parseDouble(Double.java:538)
at java.lang.Double.valueOf(Double.java:502)
at 
org.apache.geode.tools.pulse.internal.service.ClusterDetailsService.execute(ClusterDetailsService.java:90)
at 
org.apache.geode.tools.pulse.internal.controllers.PulseController.getPulseUpdate(PulseController.java:105)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:221)
at 
org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:136)
at 
org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:114)
at 
org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:827)
at 
org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:738)
at 
org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:85)
at 
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:963)
at 
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:897)
at 
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:970)
at 
org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:872)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at 
org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:846)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at 
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:821)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1685)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:317)
at 
org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:127)
at 
org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:91)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
at 
org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:115)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
at 
org.springframework.security.web.session.SessionManagementFilter.doFilter(SessionManagementFilter.java:137)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
at 
org.springframework.security.web.authentication.AnonymousAuthenticationFilter.doFilter(AnonymousAuthenticationFilter.java:111)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
at 
org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:169)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
at 
org.springframework.security.web.savedrequest.RequestCacheAwareFilter.doFilter(RequestCacheAwareFilter.java:63)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
at 
org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilterInternal(BasicAuthenticationFilter.java:158)
at 
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilt

Re: Is Dunit separable?

[Bruce Schuchardt]

Looking at the current code a little more I see that the base class 
JUnit4DistributedTestCase is tied to Geode.  You would need to create an 
equivalent to it that doesn't refer to Geode and then base your test 
case on that.


There is a little documentation here: 
https://cwiki.apache.org/confluence/display/GEODE/Distributed-Unit-Tests
but it wasn't updated when DistributedTestCase/CacheTestCase were 
replaced with JUnit4DistributedTestCase and JUnit4CacheTestCase.


Le 1/19/2017 à 2:32 PM, Roman Shaposhnik a écrit :

On Thu, Jan 19, 2017 at 2:30 PM, Bruce Schuchardt
 wrote:

Hi Roman,

DUnit is an RMI-based system.  The only ties it has to Geode are that it
creates a Locator before running tests.

Is there a separate doc for it? Suppose I wanted to use DUnit to test, lets
say, Zookeeper -- where would I start so that I can write my first testcase?

Thanks,
Roman.

Re: JIRA versions and multiple repos

[Roman Shaposhnik]

Btw, I've just confirmed that NiFi considers those subprojects
(AKA separate communities).

In fact ASF board asked them for that very clarification recently

Thanks,
Roman.

On Thu, Jan 19, 2017 at 2:27 PM, Roman Shaposhnik  wrote:
> On Thu, Jan 19, 2017 at 2:23 PM, Anthony Baker  wrote:
>>
>>> On Jan 19, 2017, at 1:01 PM, Roman Shaposhnik  wrote:
>>>
>>> On Thu, Jan 19, 2017 at 12:54 PM, Anthony Baker >> > wrote:

> On Jan 19, 2017, at 11:53 AM, Roman Shaposhnik  
> wrote:
>
> On Thu, Jan 19, 2017 at 11:21 AM, Dan Smith  wrote:
>> I wonder if we're trying to overcomplicate things there. I don't see why
>> the geode-examples wouldn't use the same release schedule and version
>> number as geode.
>>
>> The C++ and .NET clients are also somewhat tied to the version of geode
>> that they support. As long as we can stick to a regular release cadence, 
>> It
>> seems like those clients couldn't also follow the same release schedule 
>> and
>> version numbers.
>
> Huge +1 to the above!
>
> Thanks,
> Roman.


 Here’s a few examples of ASF projects with multiple repos for reference:

 - ActiveMQ
https://github.com/apache?utf8=✓&q=activemq&type=&language=
https://issues.apache.org/jira/secure/BrowseProjects.jspa#11160
 - Nifi
https://github.com/apache?utf8=✓&q=nifi&type=&language=
https://issues.apache.org/jira/secure/BrowseProjects.jspa#13460

 I agree that semi-coordinated releases from a single project community make
 sense—these are not independent things.  Using lock-step versioning means
 we release everything together, even for patch releases right?  And I’m
 assuming we would be doing separate release VOTE threads per repo.
>>>
>>> An interesting thing to note is that despite multiple repos they still 
>>> release
>>> a single source artifact:
>>>   https://www.apache.org/dist/activemq/5.13.5/ 
>>> 
>>>   https://www.apache.org/dist/nifi/1.1.1/ 
>>> 
>>>
>>> Thanks,
>>> Roman.
>>
>> FWIW, it looks to me like these projects are doing releases from each of 
>> their repos:
>>
>> https://www.apache.org/dist/activemq/activemq-apollo/1.7.1/
>> https://www.apache.org/dist/activemq/activemq-artemis/1.5.1/
>> https://www.apache.org/dist/activemq/activemq-cpp/3.9.3/
>
> I'm actually not sure what the status of these is sine I can't seem to find
> those on the official download page:
> http://activemq.apache.org/download.html
>
>> https://www.apache.org/dist/nifi/minifi/0.1.0/
>> https://www.apache.org/dist/nifi/nifi-minifi-cpp/0.1.0/
>> https://www.apache.org/dist/nifi/nifi-nar-maven-plugin-1.1.0/
>
> Ditt for NiFi. In fact, as far as minifi is concerned -- I'm pretty
> sure it is still
> considered to be 'do not try this at home'.
>
>> Which is not to say that is how Geode should operate, but I’m just looking 
>> for precedent and prior art :-)
>
> But that's my point -- I don't think it constitutes prior art. In fact
> the only prior art I'm
> aware of would be Apache Commons (which actually does explicitly split
> the community).
>
> Thanks,
> Roman.

Re: Is Dunit separable?

[Kirk Lund]

Dan and I have discussed moving dunit from geode-core/src/test to its own
submodule geode-dunit. This way the framework would be usable by Geode
users for their own apps.

Right now dunit refers to DistributedSystem and Locator which are in
geode-core/src/main. We'd have to alter dunit to use a more generic
abstraction for this dependency so it's not a circular dependency.

If we were to make that abstraction general enough to allow for different
plugins then we could open it up for non-Geode uses (someone who wants to
use it for Zookeeper would then have to write a plugin or limit their use
to just the RMI connectivity in the dunit VM API).


On Thu, Jan 19, 2017 at 2:55 PM, Bruce Schuchardt 
wrote:

> Looking at the current code a little more I see that the base class
> JUnit4DistributedTestCase is tied to Geode.  You would need to create an
> equivalent to it that doesn't refer to Geode and then base your test case
> on that.
>
> There is a little documentation here: https://cwiki.apache.org/confl
> uence/display/GEODE/Distributed-Unit-Tests
> but it wasn't updated when DistributedTestCase/CacheTestCase were
> replaced with JUnit4DistributedTestCase and JUnit4CacheTestCase.
>
>
> Le 1/19/2017 à 2:32 PM, Roman Shaposhnik a écrit :
>
>> On Thu, Jan 19, 2017 at 2:30 PM, Bruce Schuchardt
>>  wrote:
>>
>>> Hi Roman,
>>>
>>> DUnit is an RMI-based system.  The only ties it has to Geode are that it
>>> creates a Locator before running tests.
>>>
>> Is there a separate doc for it? Suppose I wanted to use DUnit to test,
>> lets
>> say, Zookeeper -- where would I start so that I can write my first
>> testcase?
>>
>> Thanks,
>> Roman.
>>
>
>

Re: JIRA versions and multiple repos

[Kirk Lund]

Why are we trying to use separate repos for examples and native client? Is
the main driver for this simply to use a different build tool than Gradle
(at least for native client)?

I would think a submodule could be ignored by Gradle and that submodule
could have its own unrelated build too (cmake or whatever). If we really
wanted to, there's probably some way to make Gradle fire off other build
tools as well


On Thu, Jan 19, 2017 at 3:03 PM, Roman Shaposhnik 
wrote:

> Btw, I've just confirmed that NiFi considers those subprojects
> (AKA separate communities).
>
> In fact ASF board asked them for that very clarification recently
>
> Thanks,
> Roman.
>
> On Thu, Jan 19, 2017 at 2:27 PM, Roman Shaposhnik 
> wrote:
> > On Thu, Jan 19, 2017 at 2:23 PM, Anthony Baker 
> wrote:
> >>
> >>> On Jan 19, 2017, at 1:01 PM, Roman Shaposhnik 
> wrote:
> >>>
> >>> On Thu, Jan 19, 2017 at 12:54 PM, Anthony Baker  > wrote:
> 
> > On Jan 19, 2017, at 11:53 AM, Roman Shaposhnik 
> wrote:
> >
> > On Thu, Jan 19, 2017 at 11:21 AM, Dan Smith 
> wrote:
> >> I wonder if we're trying to overcomplicate things there. I don't
> see why
> >> the geode-examples wouldn't use the same release schedule and
> version
> >> number as geode.
> >>
> >> The C++ and .NET clients are also somewhat tied to the version of
> geode
> >> that they support. As long as we can stick to a regular release
> cadence, It
> >> seems like those clients couldn't also follow the same release
> schedule and
> >> version numbers.
> >
> > Huge +1 to the above!
> >
> > Thanks,
> > Roman.
> 
> 
>  Here’s a few examples of ASF projects with multiple repos for
> reference:
> 
>  - ActiveMQ
> https://github.com/apache?utf8=✓&q=activemq&type=&language=
> https://issues.apache.org/jira/secure/BrowseProjects.
> jspa#11160
>  - Nifi
> https://github.com/apache?utf8=✓&q=nifi&type=&language=
> https://issues.apache.org/jira/secure/BrowseProjects.
> jspa#13460
> 
>  I agree that semi-coordinated releases from a single project
> community make
>  sense—these are not independent things.  Using lock-step versioning
> means
>  we release everything together, even for patch releases right?  And
> I’m
>  assuming we would be doing separate release VOTE threads per repo.
> >>>
> >>> An interesting thing to note is that despite multiple repos they still
> release
> >>> a single source artifact:
> >>>   https://www.apache.org/dist/activemq/5.13.5/ <
> https://www.apache.org/dist/activemq/5.13.5/>
> >>>   https://www.apache.org/dist/nifi/1.1.1/ <
> https://www.apache.org/dist/nifi/1.1.1/>
> >>>
> >>> Thanks,
> >>> Roman.
> >>
> >> FWIW, it looks to me like these projects are doing releases from each
> of their repos:
> >>
> >> https://www.apache.org/dist/activemq/activemq-apollo/1.7.1/
> >> https://www.apache.org/dist/activemq/activemq-artemis/1.5.1/
> >> https://www.apache.org/dist/activemq/activemq-cpp/3.9.3/
> >
> > I'm actually not sure what the status of these is sine I can't seem to
> find
> > those on the official download page:
> > http://activemq.apache.org/download.html
> >
> >> https://www.apache.org/dist/nifi/minifi/0.1.0/
> >> https://www.apache.org/dist/nifi/nifi-minifi-cpp/0.1.0/
> >> https://www.apache.org/dist/nifi/nifi-nar-maven-plugin-1.1.0/
> >
> > Ditt for NiFi. In fact, as far as minifi is concerned -- I'm pretty
> > sure it is still
> > considered to be 'do not try this at home'.
> >
> >> Which is not to say that is how Geode should operate, but I’m just
> looking for precedent and prior art :-)
> >
> > But that's my point -- I don't think it constitutes prior art. In fact
> > the only prior art I'm
> > aware of would be Apache Commons (which actually does explicitly split
> > the community).
> >
> > Thanks,
> > Roman.
>

[jira] [Updated] (GEODE-2260) Move geode examples to new repo home

[Karen Smoler Miller (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karen Smoler Miller updated GEODE-2260:
---
Fix Version/s: 1.1.0

> Move geode examples to new repo home
> 
>
> Key: GEODE-2260
> URL: https://issues.apache.org/jira/browse/GEODE-2260
> Project: Geode
>  Issue Type: New Feature
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
> Fix For: 1.1.0
>
>
> Initialize new repository (https://github.com/apache/geode-examples) for 
> geode-examples module.
> Move current geode-examples module to the new repo.
> Revise instructions to work outside the geode repo. Verify the replicated 
> example works once moved.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (GEODE-2260) Move geode examples to new repo home

[Karen Smoler Miller (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karen Smoler Miller resolved GEODE-2260.

Resolution: Fixed

> Move geode examples to new repo home
> 
>
> Key: GEODE-2260
> URL: https://issues.apache.org/jira/browse/GEODE-2260
> Project: Geode
>  Issue Type: New Feature
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
> Fix For: 1.1.0
>
>
> Initialize new repository (https://github.com/apache/geode-examples) for 
> geode-examples module.
> Move current geode-examples module to the new repo.
> Revise instructions to work outside the geode repo. Verify the replicated 
> example works once moved.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (GEODE-2328) Refactor add*Field methods to reduce the duplicates

[Udo Kohlmeyer (JIRA)]

Udo Kohlmeyer created GEODE-2328:


 Summary: Refactor add*Field methods to reduce the duplicates
 Key: GEODE-2328
 URL: https://issues.apache.org/jira/browse/GEODE-2328
 Project: Geode
  Issue Type: Sub-task
  Components: serialization
Reporter: Udo Kohlmeyer
 Fix For: 1.1.0


all the add field methods follow the same pattern. Maybe a single method can be 
extracted to replace all the duplicate code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (GEODE-2329) JSONFormatter.fromJSON method has duplicate behavior

[Udo Kohlmeyer (JIRA)]

Udo Kohlmeyer created GEODE-2329:


 Summary: JSONFormatter.fromJSON method has duplicate behavior
 Key: GEODE-2329
 URL: https://issues.apache.org/jira/browse/GEODE-2329
 Project: Geode
  Issue Type: Sub-task
  Components: serialization
Reporter: Udo Kohlmeyer
 Fix For: 1.1.0


refactor the duplicate code in the fromJSON method.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2328) Refactor add*Field methods to reduce the duplicates

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15830847#comment-15830847
 ] 

ASF subversion and git services commented on GEODE-2328:


Commit b74478dc8dd6b86cdfde40123d9302f010ed6f37 in geode's branch 
refs/heads/feature/GEODE-2328 from [~ukohlmeyer]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=b74478d ]

GEODE-2328: Refactor add field methods to reduce duplicate code


> Refactor add*Field methods to reduce the duplicates
> ---
>
> Key: GEODE-2328
> URL: https://issues.apache.org/jira/browse/GEODE-2328
> Project: Geode
>  Issue Type: Sub-task
>  Components: serialization
>Reporter: Udo Kohlmeyer
> Fix For: 1.1.0
>
>
> all the add field methods follow the same pattern. Maybe a single method can 
> be extracted to replace all the duplicate code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Review Request 55736: GEODE-2328: Refactor add Field methods to reduce the duplicates

[Udo Kohlmeyer]

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

Review request for geode, Bruce Schuchardt, Galen O'Sullivan, and Hitesh 
Khamesra.


Repository: geode


Description
---

the add fields have the same behavior and identical code. Refactored the code 
to use a single method and reduce duplication


Diffs
-

  
geode-core/src/main/java/org/apache/geode/pdx/internal/json/PdxInstanceHelper.java
 39d16a57e 
  
geode-core/src/main/java/org/apache/geode/pdx/internal/json/PdxInstanceSortedHelper.java
 7f510da15 
  
geode-core/src/test/java/org/apache/geode/pdx/JSONPdxClientServerDUnitTest.java 
396eb1d13 

Diff: https://reviews.apache.org/r/55736/diff/


Testing
---

precheckin - running


Thanks,

Udo Kohlmeyer

[jira] [Commented] (GEODE-2329) JSONFormatter.fromJSON method has duplicate behavior

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15830860#comment-15830860
 ] 

ASF subversion and git services commented on GEODE-2329:


Commit 30ad8072c86512e87e8b0bbd010d83f77637d03f in geode's branch 
refs/heads/feature/GEODE-2329 from [~ukohlmeyer]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=30ad807 ]

GEODE-2329: Refactor JSONFormatter fromJSON code to reduce duplicate code


> JSONFormatter.fromJSON method has duplicate behavior
> 
>
> Key: GEODE-2329
> URL: https://issues.apache.org/jira/browse/GEODE-2329
> Project: Geode
>  Issue Type: Sub-task
>  Components: serialization
>Reporter: Udo Kohlmeyer
> Fix For: 1.1.0
>
>
> refactor the duplicate code in the fromJSON method.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Review Request 55738: GEODE-2329: Refactor JSONFormatter.fromJSON method to reduce duplication

[Udo Kohlmeyer]

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

Review request for geode, Bruce Schuchardt, Galen O'Sullivan, and Hitesh 
Khamesra.


Repository: geode


Description
---

Remove duplicate code from the JSONFormatter.fromJSON method


Diffs
-

  geode-core/src/main/java/org/apache/geode/pdx/JSONFormatter.java 9ee32c913 

Diff: https://reviews.apache.org/r/55738/diff/


Testing
---

precheckin - running


Thanks,

Udo Kohlmeyer

[jira] [Updated] (GEODE-2324) If AcceptorImpl is interrupted during shutdown, it does not clean up properly.

[Galen O'Sullivan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Galen O'Sullivan updated GEODE-2324:

Description: 
In {{AcceptorImpl.close()}}, the call to 
{{this.pool.awaitTermination(PoolImpl.SHUTDOWN_TIMEOUT, 
TimeUnit.MILLISECONDS))}} can throw an {{InterruptedException}}, in which case 
neither {pool} nor {{hsPool}} or anything else that comes after is properly 
closed and an error message is logged.

I believe that the thread will be interrupted if a shutdown command is issued 
(for example, through gfsh), though I haven't created a reproduction yet.

  was:
In {{AcceptorImpl,close()}}, the call to 
{{this.pool.awaitTermination(PoolImpl.SHUTDOWN_TIMEOUT, 
TimeUnit.MILLISECONDS))}} can throw an {{InterruptedException}}, in which case 
neither {pool} nor {{hsPool}} or anything else that comes after is properly 
closed and an error message is logged.

I believe that the thread will be interrupted if a shutdown command is issued 
(for example, through gfsh), though I haven't created a reproduction yet.


> If AcceptorImpl is interrupted during shutdown, it does not clean up properly.
> --
>
> Key: GEODE-2324
> URL: https://issues.apache.org/jira/browse/GEODE-2324
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Affects Versions: 1.0.0-incubating
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
>
> In {{AcceptorImpl.close()}}, the call to 
> {{this.pool.awaitTermination(PoolImpl.SHUTDOWN_TIMEOUT, 
> TimeUnit.MILLISECONDS))}} can throw an {{InterruptedException}}, in which 
> case neither {pool} nor {{hsPool}} or anything else that comes after is 
> properly closed and an error message is logged.
> I believe that the thread will be interrupted if a shutdown command is issued 
> (for example, through gfsh), though I haven't created a reproduction yet.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)