Re: Review Request 56242: GEODE-2206: Add junit-quickcheck to geode-core; add a test that uses it.

[Bruce Schuchardt]

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


Ship it!




Ship It!

- Bruce Schuchardt


On Feb. 2, 2017, 9:35 p.m., Galen O'Sullivan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56242/
> ---
> 
> (Updated Feb. 2, 2017, 9:35 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt, Hitesh Khamesra, Kirk Lund, and 
> Udo Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This adds a test dependency on `junit-quickcheck` (and 
> `junit-quickcheck-generators` and `junit-quickcheck-guava`) to geode-core. 
> I've included an example test of one of the cases in which property-based 
> testing is particularly nice: when you have two operations that should 
> reverse each other and want to test them with as much garbage as possible.
> 
> Property-based testing means basically that you write a function that tests 
> some code and checks some conditions you expect to hold true for all inputs, 
> and then have a computer program test all sorts of weird inputs to try prove 
> you wrong.
> 
> Because the test data is randomly generated, you get to test against more 
> inputs than you might even think of, and because the seed is saved, the test 
> is reproducible. If `junit-quickcheck` finds one failure, it will even try to 
> narrow down to a smallest example of a test failure.
> 
> I'm about to send an email to the dev list soliciting feedback.
> 
> 
> Diffs
> -
> 
>   geode-core/build.gradle 3c2a2abf5 
>   
> geode-core/src/test/java/org/apache/geode/internal/InternalDataSerializerQuickcheckStringTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/internal/InternalDataSerializerRandomizedJUnitTest.java
>  f361de4a2 
>   gradle/dependency-versions.properties fbc76e012 
> 
> Diff: https://reviews.apache.org/r/56242/diff/
> 
> 
> Testing
> ---
> 
> The test passes on my machine. This is mostly just adding a dependency, so 
> there's not a lot here to test.
> 
> I've read some of the source of junit-quickcheck and looked into the data it 
> generates: integral numbers seem pretty reasonable. Strings tend to be 
> short-ish (length up to hundreds with hundreds of iterations, thousands with 
> thousands), but are made up of random codepoints, which is nice.
> 
> 
> Thanks,
> 
> Galen O'Sullivan
> 
>

Re: [VOTE] RC1: Apache Geode release - v1.1.0

[Anthony Baker]

-1 (binding)

`gradle rat` shows these binary files are included in the src distribution:

 + 
/Users/abaker/working/apache-geode-src-1.1.0/geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster.jar
 
 + 
/Users/abaker/working/apache-geode-src-1.1.0/geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config.zip
 
 + 
/Users/abaker/working/apache-geode-src-1.1.0/geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config_security.zip
 
 + 
/Users/abaker/working/apache-geode-src-1.1.0/geode-core/src/test/resources/org/apache/geode/management/internal/configuration/group1.jar
 
 + 
/Users/abaker/working/apache-geode-src-1.1.0/geode-core/src/test/resources/org/apache/geode/management/internal/configuration/group2.jar


If tests require binary files, those files should be generated from source 
during the build.

Anthony

> On Feb 3, 2017, at 4:11 PM, Hitesh Khamesra  
> wrote:
> 
> All,
> 
> This is the first release candidate of the first release for Apache Geode, 
> version 1.1.0.
> Thanks to all the community members.
> 
> It fixes the following issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318420&version=12338352
> 
> 
> *** Please download, test and vote by Wednesday, February 08, 0800 hrs US 
> Pacific.
> 
> Note that we are voting upon the source (tag):
>rel/v1.1.0.RC1
>
> https://git-wip-us.apache.org/repos/asf?p=geode.git;a=tag;h=refs/tags/rel/v1.1.0.RC1
> 
> Commit ID: 90760d334f912cef49ad32f275aed9cd9f1f2688
>
> Source and binary files:
>https://dist.apache.org/repos/dist/dev/geode/1.1.0.RC1/
> 
> Maven staging repo:
>https://repository.apache.org/content/repositories/orgapachegeode-1015/
> 
> Geode's KEYS file containing PGP keys we use to sign the release:
>https://github.com/apache/geode/blob/release/1.1.0/KEYS
> 
> pub   4096R/AC6AB8ED 2017-01-18
>   Key fingerprint = 048F B40F AD7D 9C15 54AD  D447 2CA9 90A2 AC6A B8ED
> 
> Thanks,
> Dan & Hitesh (on behalf of the Geode team)

Re: [VOTE] RC1: Apache Geode release - v1.1.0

[Jinmei Liao]

Oh, these are used by the tests, and the classes they contain are only test
classes as well. So we need to programmatically produce these jars and zips
during build time?

On Mon, Feb 6, 2017 at 8:05 AM, Anthony Baker  wrote:

> -1 (binding)
>
> `gradle rat` shows these binary files are included in the src distribution:
>
>  + /Users/abaker/working/apache-geode-src-1.1.0/geode-core/
> src/test/resources/org/apache/geode/management/internal/
> configuration/cluster.jar
>
>  + /Users/abaker/working/apache-geode-src-1.1.0/geode-core/
> src/test/resources/org/apache/geode/management/internal/
> configuration/cluster_config.zip
>
>  + /Users/abaker/working/apache-geode-src-1.1.0/geode-core/
> src/test/resources/org/apache/geode/management/internal/
> configuration/cluster_config_security.zip
>
>  + /Users/abaker/working/apache-geode-src-1.1.0/geode-core/
> src/test/resources/org/apache/geode/management/internal/
> configuration/group1.jar
>
>  + /Users/abaker/working/apache-geode-src-1.1.0/geode-core/
> src/test/resources/org/apache/geode/management/internal/
> configuration/group2.jar
>
>
> If tests require binary files, those files should be generated from source
> during the build.
>
> Anthony
>
> > On Feb 3, 2017, at 4:11 PM, Hitesh Khamesra 
> wrote:
> >
> > All,
> >
> > This is the first release candidate of the first release for Apache
> Geode, version 1.1.0.
> > Thanks to all the community members.
> >
> > It fixes the following issues:
> >https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12318420&version=12338352
> >
> >
> > *** Please download, test and vote by Wednesday, February 08, 0800 hrs
> US Pacific.
> >
> > Note that we are voting upon the source (tag):
> >rel/v1.1.0.RC1
> >https://git-wip-us.apache.org/repos/asf?p=geode.git;a=tag;h=
> refs/tags/rel/v1.1.0.RC1
> >
> > Commit ID: 90760d334f912cef49ad32f275aed9cd9f1f2688
> >
> > Source and binary files:
> >https://dist.apache.org/repos/dist/dev/geode/1.1.0.RC1/
> >
> > Maven staging repo:
> >https://repository.apache.org/content/repositories/
> orgapachegeode-1015/
> >
> > Geode's KEYS file containing PGP keys we use to sign the release:
> >https://github.com/apache/geode/blob/release/1.1.0/KEYS
> >
> > pub   4096R/AC6AB8ED 2017-01-18
> >   Key fingerprint = 048F B40F AD7D 9C15 54AD  D447 2CA9 90A2 AC6A
> B8ED
> >
> > Thanks,
> > Dan & Hitesh (on behalf of the Geode team)
>
>


-- 
Cheers

Jinmei

Re: [VOTE] RC1: Apache Geode release - v1.1.0

[Anthony Baker]

Correct.  Let me know if you need help converting these files to gradle tasks.

Anthony


> On Feb 6, 2017, at 8:10 AM, Jinmei Liao  wrote:
> 
> Oh, these are used by the tests, and the classes they contain are only test
> classes as well. So we need to programmatically produce these jars and zips
> during build time?
> 
> On Mon, Feb 6, 2017 at 8:05 AM, Anthony Baker  wrote:
> 
>> -1 (binding)
>> 
>> `gradle rat` shows these binary files are included in the src distribution:
>> 
>> + /Users/abaker/working/apache-geode-src-1.1.0/geode-core/
>> src/test/resources/org/apache/geode/management/internal/
>> configuration/cluster.jar
>> 
>> + /Users/abaker/working/apache-geode-src-1.1.0/geode-core/
>> src/test/resources/org/apache/geode/management/internal/
>> configuration/cluster_config.zip
>> 
>> + /Users/abaker/working/apache-geode-src-1.1.0/geode-core/
>> src/test/resources/org/apache/geode/management/internal/
>> configuration/cluster_config_security.zip
>> 
>> + /Users/abaker/working/apache-geode-src-1.1.0/geode-core/
>> src/test/resources/org/apache/geode/management/internal/
>> configuration/group1.jar
>> 
>> + /Users/abaker/working/apache-geode-src-1.1.0/geode-core/
>> src/test/resources/org/apache/geode/management/internal/
>> configuration/group2.jar
>> 
>> 
>> If tests require binary files, those files should be generated from source
>> during the build.
>> 
>> Anthony
>> 
>>> On Feb 3, 2017, at 4:11 PM, Hitesh Khamesra 
>> wrote:
>>> 
>>> All,
>>> 
>>> This is the first release candidate of the first release for Apache
>> Geode, version 1.1.0.
>>> Thanks to all the community members.
>>> 
>>> It fixes the following issues:
>>>   https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>> projectId=12318420&version=12338352
>>> 
>>> 
>>> *** Please download, test and vote by Wednesday, February 08, 0800 hrs
>> US Pacific.
>>> 
>>> Note that we are voting upon the source (tag):
>>>   rel/v1.1.0.RC1
>>>   https://git-wip-us.apache.org/repos/asf?p=geode.git;a=tag;h=
>> refs/tags/rel/v1.1.0.RC1
>>> 
>>> Commit ID: 90760d334f912cef49ad32f275aed9cd9f1f2688
>>> 
>>> Source and binary files:
>>>   https://dist.apache.org/repos/dist/dev/geode/1.1.0.RC1/
>>> 
>>> Maven staging repo:
>>>   https://repository.apache.org/content/repositories/
>> orgapachegeode-1015/
>>> 
>>> Geode's KEYS file containing PGP keys we use to sign the release:
>>>   https://github.com/apache/geode/blob/release/1.1.0/KEYS
>>> 
>>> pub   4096R/AC6AB8ED 2017-01-18
>>>  Key fingerprint = 048F B40F AD7D 9C15 54AD  D447 2CA9 90A2 AC6A
>> B8ED
>>> 
>>> Thanks,
>>> Dan & Hitesh (on behalf of the Geode team)
>> 
>> 
> 
> 
> -- 
> Cheers
> 
> Jinmei

[jira] [Created] (GEODE-2429) NPE in JtaAfterCompletionMessage.operateOnTx()

[Eric Shu (JIRA)]

Eric Shu created GEODE-2429:
---

 Summary: NPE in JtaAfterCompletionMessage.operateOnTx() 
 Key: GEODE-2429
 URL: https://issues.apache.org/jira/browse/GEODE-2429
 Project: Geode
  Issue Type: Bug
  Components: transactions
Reporter: Eric Shu


There is a race could cause a NullPointerException:
Exception in notify after completion due to java.lang.NullPointerException
org.apache.geode.cache.TransactionException: java.lang.NullPointerException, 
caused by java.lang.NullPointerException
at 
org.apache.geode.internal.cache.PeerTXStateStub.afterCompletion(PeerTXStateStub.java:206)
at 
org.apache.geode.internal.cache.TXStateProxyImpl.afterCompletion(TXStateProxyImpl.java:615)
at 
org.apache.geode.internal.cache.tier.sockets.command.TXSynchronizationCommand$2.run(TXSynchronizationCommand.java:160)
at 
org.apache.geode.internal.cache.tier.sockets.command.TXSynchronizationCommand.cmdExecute(TXSynchronizationCommand.java:211)
at 
org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:141)
at 
org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:783)
at 
org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:914)
at 
org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1171)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at 
org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$1$1.run(AcceptorImpl.java:519)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NullPointerException
at Remote Member 
'rs-TheLynns-client-1(bridgegemfire1_rs-TheLynns-client-1_13760:13760):1025'
 in 
org.apache.geode.internal.cache.JtaAfterCompletionMessage.operateOnTx(JtaAfterCompletionMessage.java:94)
at Remote Member 
'rs-TheLynns-client-1(bridgegemfire1_rs-TheLynns-client-1_13760:13760):1025'
 in org.apache.geode.internal.cache.TXMessage.process(TXMessage.java:88)
at Remote Member 
'rs-TheLynns-client-1(bridgegemfire1_rs-TheLynns-client-1_13760:13760):1025'
 in 
org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
at Remote Member 
'rs-TheLynns-client-1(bridgegemfire1_rs-TheLynns-client-1_13760:13760):1025'
 in 
org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:442)
at Remote Member 
'rs-TheLynns-client-1(bridgegemfire1_rs-TheLynns-client-1_13760:13760):1025'
 in 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at Remote Member 
'rs-TheLynns-client-1(bridgegemfire1_rs-TheLynns-client-1_13760:13760):1025'
 in 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at Remote Member 
'rs-TheLynns-client-1(bridgegemfire1_rs-TheLynns-client-1_13760:13760):1025'
 in 
org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:621)
at Remote Member 
'rs-TheLynns-client-1(bridgegemfire1_rs-TheLynns-client-1_13760:13760):1025'
 in 
org.apache.geode.distributed.internal.DistributionManager$5$1.run(DistributionManager.java:917)
at Remote Member 
'rs-TheLynns-client-1(bridgegemfire1_rs-TheLynns-client-1_13760:13760):1025'
 in java.lang.Thread.run(Thread.java:745)
at 
org.apache.geode.distributed.internal.ReplyException.handleAsUnexpected(ReplyException.java:85)
at 
org.apache.geode.internal.cache.RemoteOperationMessage$RemoteOperationResponse.waitForCacheException(RemoteOperationMessage.java:652)
at 
org.apache.geode.internal.cache.TXRemoteCommitMessage$RemoteCommitResponse.waitForResponse(TXRemoteCommitMessage.java:273)
at 
org.apache.geode.internal.cache.PeerTXStateStub.afterCompletion(PeerTXStateStub.java:200)
... 11 more




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2429) NPE in JtaAfterCompletionMessage.operateOnTx()

[Eric Shu (JIRA)]

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

Eric Shu reassigned GEODE-2429:
---

Assignee: Eric Shu

> NPE in JtaAfterCompletionMessage.operateOnTx() 
> ---
>
> Key: GEODE-2429
> URL: https://issues.apache.org/jira/browse/GEODE-2429
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Eric Shu
>Assignee: Eric Shu
>
> There is a race could cause a NullPointerException:
> Exception in notify after completion due to java.lang.NullPointerException
> org.apache.geode.cache.TransactionException: java.lang.NullPointerException, 
> caused by java.lang.NullPointerException
> at 
> org.apache.geode.internal.cache.PeerTXStateStub.afterCompletion(PeerTXStateStub.java:206)
> at 
> org.apache.geode.internal.cache.TXStateProxyImpl.afterCompletion(TXStateProxyImpl.java:615)
> at 
> org.apache.geode.internal.cache.tier.sockets.command.TXSynchronizationCommand$2.run(TXSynchronizationCommand.java:160)
> at 
> org.apache.geode.internal.cache.tier.sockets.command.TXSynchronizationCommand.cmdExecute(TXSynchronizationCommand.java:211)
> at 
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:141)
> at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:783)
> at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:914)
> at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1171)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at 
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$1$1.run(AcceptorImpl.java:519)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
> at Remote Member 
> 'rs-TheLynns-client-1(bridgegemfire1_rs-TheLynns-client-1_13760:13760):1025'
>  in 
> org.apache.geode.internal.cache.JtaAfterCompletionMessage.operateOnTx(JtaAfterCompletionMessage.java:94)
> at Remote Member 
> 'rs-TheLynns-client-1(bridgegemfire1_rs-TheLynns-client-1_13760:13760):1025'
>  in org.apache.geode.internal.cache.TXMessage.process(TXMessage.java:88)
> at Remote Member 
> 'rs-TheLynns-client-1(bridgegemfire1_rs-TheLynns-client-1_13760:13760):1025'
>  in 
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> at Remote Member 
> 'rs-TheLynns-client-1(bridgegemfire1_rs-TheLynns-client-1_13760:13760):1025'
>  in 
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:442)
> at Remote Member 
> 'rs-TheLynns-client-1(bridgegemfire1_rs-TheLynns-client-1_13760:13760):1025'
>  in 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at Remote Member 
> 'rs-TheLynns-client-1(bridgegemfire1_rs-TheLynns-client-1_13760:13760):1025'
>  in 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at Remote Member 
> 'rs-TheLynns-client-1(bridgegemfire1_rs-TheLynns-client-1_13760:13760):1025'
>  in 
> org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:621)
> at Remote Member 
> 'rs-TheLynns-client-1(bridgegemfire1_rs-TheLynns-client-1_13760:13760):1025'
>  in 
> org.apache.geode.distributed.internal.DistributionManager$5$1.run(DistributionManager.java:917)
> at Remote Member 
> 'rs-TheLynns-client-1(bridgegemfire1_rs-TheLynns-client-1_13760:13760):1025'
>  in java.lang.Thread.run(Thread.java:745)
> at 
> org.apache.geode.distributed.internal.ReplyException.handleAsUnexpected(ReplyException.java:85)
> at 
> org.apache.geode.internal.cache.RemoteOperationMessage$RemoteOperationResponse.waitForCacheException(RemoteOperationMessage.java:652)
> at 
> org.apache.geode.internal.cache.TXRemoteCommitMessage$RemoteCommitResponse.waitForResponse(TXRemoteCommitMessage.java:273)
> at 
> org.apache.geode.internal.cache.PeerTXStateStub.afterCompletion(PeerTXStateStub.java:200)
> ... 11 more



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Fwd: Build failed in Jenkins: Geode-nightly #738

[Kirk Lund]

Can someone please do one of the following (I don't have build job
permissions)?

a) disable FlakyTest in the nightly build

or

b) add FlakyTest results to the test results

Also, I think we need to either fix
testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator or disable it. It's
failing frequently in the nightly build.

:geode-core:flakyTest

org.apache.geode.distributed.LocatorDUnitTest >
testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.distributed.LocatorDUnitTest$$Lambda$26/981119691.run in
VM 2 running on Host asf920.gq1.ygridcore.net with 4 VMs
at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
at org.apache.geode.test.dunit.VM.invoke(VM.java:292)
at
org.apache.geode.distributed.LocatorDUnitTest.testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator(LocatorDUnitTest.java:535)

Caused by:
com.jayway.awaitility.core.ConditionTimeoutException: Condition
with alias 'locator2 dies' didn't complete within 30 seconds because
condition with org.apache.geode.distributed.LocatorDUnitTest was not
fulfilled.
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.distributed.LocatorDUnitTest.lambda$testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator$bb17a952$1(LocatorDUnitTest.java:536)

org.apache.geode.distributed.LocatorUDPSecurityDUnitTest >
testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.distributed.LocatorDUnitTest$$Lambda$17/407365607.run in
VM 2 running on Host asf920.gq1.ygridcore.net with 4 VMs

Caused by:
com.jayway.awaitility.core.ConditionTimeoutException: Condition
with alias 'locator2 dies' didn't complete within 30 seconds because
condition with org.apache.geode.distributed.LocatorDUnitTest was not
fulfilled.

268 tests completed, 2 failed, 6 skipped
:geode-core:flakyTest FAILED
-- Forwarded message --
From: Apache Jenkins Server 
Date: Sun, Feb 5, 2017 at 8:10 AM
Subject: Build failed in Jenkins: Geode-nightly #738
To: dev@geode.apache.org, dbar...@pivotal.io, gz...@pivotal.io,
aba...@pivotal.io, e...@pivotal.io, huyn...@gmail.com, aging...@pivotal.io,
kdul...@pivotal.io, upthewatersp...@apache.org, bogle...@pivotal.io,
n...@pivotal.io, bschucha...@pivotal.io, hkhame...@pivotal.io,
kl...@pivotal.io, ukohlme...@pivotal.io, hitesh...@yahoo.com


See 

--
[...truncated 549 lines...]
at com.jayway.awaitility.core.ConditionFactory.until(
ConditionFactory.java:741)
at org.apache.geode.distributed.LocatorDUnitTest.lambda$
testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator$
bb17a952$1(LocatorDUnitTest.java:536)

org.apache.geode.distributed.LocatorUDPSecurityDUnitTest >
testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.distributed.LocatorDUnitTest$$Lambda$17/407365607.run in
VM 2 running on Host asf920.gq1.ygridcore.net with 4 VMs

Caused by:
com.jayway.awaitility.core.ConditionTimeoutException: Condition
with alias 'locator2 dies' didn't complete within 30 seconds because
condition with org.apache.geode.distributed.LocatorDUnitTest was not
fulfilled.

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

:geode-cq:processTestResources
:geode-cq:testClasses
:geode-cq:checkMissedTests
:geode-cq:spotlessJavaCheck
:geode-cq:spotlessCheck
:geode-cq:test
:geode-cq:check
:geode-cq:build
:geode-cq:distributedTest
:geode-cq:flakyTest
:geode-cq:integrationTest
:geode-json:assemble
:geode-json:compileTestJava UP-TO-DATE
:geode-json:processTestResources UP-TO-DATE
:geode-json:testClasses UP-TO-DATE
:geode-json:checkMissedTests UP-TO-DATE
:geode-json:spotlessJavaCheck
:geode-json:spotlessCheck
:geode-json:test UP-TO-DATE
:geode-json:check
:geode-json:build
:geode-json:distributedTest UP-TO-DATE
:geode-json:flakyTest UP-TO-DATE
:geode-json:integrationTest UP-TO-DATE
:geode-junit:javadoc
:geode-junit:javadocJar
:geode-junit:sourcesJar
:geode-j

Re: Fwd: Build failed in Jenkins: Geode-nightly #738

[Hitesh Khamesra]

Will disable it  testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator test.
-Hitesh


  From: Kirk Lund 
 To: geode  
 Sent: Monday, February 6, 2017 9:05 AM
 Subject: Fwd: Build failed in Jenkins: Geode-nightly #738
   
Can someone please do one of the following (I don't have build job
permissions)?

a) disable FlakyTest in the nightly build

or

b) add FlakyTest results to the test results

Also, I think we need to either fix
testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator or disable it. It's
failing frequently in the nightly build.

:geode-core:flakyTest

org.apache.geode.distributed.LocatorDUnitTest >
testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator FAILED
    org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.distributed.LocatorDUnitTest$$Lambda$26/981119691.run in
VM 2 running on Host asf920.gq1.ygridcore.net with 4 VMs
        at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
        at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
        at org.apache.geode.test.dunit.VM.invoke(VM.java:292)
        at
org.apache.geode.distributed.LocatorDUnitTest.testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator(LocatorDUnitTest.java:535)

        Caused by:
        com.jayway.awaitility.core.ConditionTimeoutException: Condition
with alias 'locator2 dies' didn't complete within 30 seconds because
condition with org.apache.geode.distributed.LocatorDUnitTest was not
fulfilled.
            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.distributed.LocatorDUnitTest.lambda$testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator$bb17a952$1(LocatorDUnitTest.java:536)

org.apache.geode.distributed.LocatorUDPSecurityDUnitTest >
testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator FAILED
    org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.distributed.LocatorDUnitTest$$Lambda$17/407365607.run in
VM 2 running on Host asf920.gq1.ygridcore.net with 4 VMs

        Caused by:
        com.jayway.awaitility.core.ConditionTimeoutException: Condition
with alias 'locator2 dies' didn't complete within 30 seconds because
condition with org.apache.geode.distributed.LocatorDUnitTest was not
fulfilled.

268 tests completed, 2 failed, 6 skipped
:geode-core:flakyTest FAILED
-- Forwarded message --
From: Apache Jenkins Server 
Date: Sun, Feb 5, 2017 at 8:10 AM
Subject: Build failed in Jenkins: Geode-nightly #738
To: dev@geode.apache.org, dbar...@pivotal.io, gz...@pivotal.io,
aba...@pivotal.io, e...@pivotal.io, huyn...@gmail.com, aging...@pivotal.io,
kdul...@pivotal.io, upthewatersp...@apache.org, bogle...@pivotal.io,
n...@pivotal.io, bschucha...@pivotal.io, hkhame...@pivotal.io,
kl...@pivotal.io, ukohlme...@pivotal.io, hitesh...@yahoo.com


See 

--
[...truncated 549 lines...]
            at com.jayway.awaitility.core.ConditionFactory.until(
ConditionFactory.java:741)
            at org.apache.geode.distributed.LocatorDUnitTest.lambda$
testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator$
bb17a952$1(LocatorDUnitTest.java:536)

org.apache.geode.distributed.LocatorUDPSecurityDUnitTest >
testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator FAILED
    org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.distributed.LocatorDUnitTest$$Lambda$17/407365607.run in
VM 2 running on Host asf920.gq1.ygridcore.net with 4 VMs

        Caused by:
        com.jayway.awaitility.core.ConditionTimeoutException: Condition
with alias 'locator2 dies' didn't complete within 30 seconds because
condition with org.apache.geode.distributed.LocatorDUnitTest was not
fulfilled.

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

:geode-cq:processTestResources
:geode-cq:testClasses
:geode-cq:checkMissedTests
:geode-cq:spotlessJavaCheck
:geode-cq:spotlessCheck
:geode-cq:test
:geode-cq:check
:geode-cq:build
:geode-cq:distributedTest
:geode-cq:flakyTest
:geode-cq:integrationTest
:geode-json:assemble
:geode-json:compileTestJava UP-TO-DATE
:geode-json:processTestResources UP-TO-DATE
:geode-json:testClasses UP-TO-DATE
:geode-json:checkMissedTests UP-TO-DATE
:geode-json:spotlessJavaCheck
:geode-json:spotlessCheck
:geode-json:test UP-TO-DA

Re: PR Buckets are created during Get call for non-existing key

[Dan Smith]

Hi Avinash,

Any time you try to use a bucket it will get created. It doesn't matter if
you are trying to put or get values.

-Dan

On Sat, Feb 4, 2017 at 9:32 PM, Avinash Dongre  wrote:

> Hi,
> In the following test, I have one PR, No buckets will be created initially.
> But when I call get on non-existing-key, I see 1 bucket is created.
>
> Why bucket is getting created during get call when the Region is empty.
>
> @Test
> public void testBucketCreatedDuringGet() {
>   Properties props = new Properties();
>   props.put("mcast-port", "0");
>   props.put("locators", "");
>
>   Cache cache = new CacheFactory(props).create();
>   PartitionedRegion pr = (PartitionedRegion)
> cache.createRegionFactory(RegionShortcut.PARTITION).create("PR");
>
>   org.junit.Assert.assertEquals(0,
> pr.getDataStore().getAllLocalBucketIds().size());
>
>   Object notExist = pr.get("NonExistingKey");
>   org.junit.Assert.assertNull(notExist);
>
>   org.junit.Assert.assertEquals(0,
> pr.getDataStore().getAllLocalBucketIds().size());
>
>   pr.destroyRegion();
>   cache.close();
>
> }
>
> Thanks
>
> Avinash
>

[jira] [Assigned] (GEODE-2430) Remove binary files from test resources

[Jared Stewart (JIRA)]

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

Jared Stewart reassigned GEODE-2430:


Assignee: Jared Stewart

> Remove binary files from test resources
> ---
>
> Key: GEODE-2430
> URL: https://issues.apache.org/jira/browse/GEODE-2430
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> We have some tests which rely on the following binary files:
> {code}
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster.jar
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config.zip
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config_security.zip
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/group1.jar
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/group2.jar
> {code}
> We need to convert our tests to generate these files dynamically instead so 
> that we don't have binary files checked into our repository.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2430) Remove binary files from test resources

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-2430:


 Summary: Remove binary files from test resources
 Key: GEODE-2430
 URL: https://issues.apache.org/jira/browse/GEODE-2430
 Project: Geode
  Issue Type: Improvement
  Components: management
Reporter: Jared Stewart


We have some tests which rely on the following binary files:
{code}
+ 
geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster.jar
+ 
geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config.zip
+ 
geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config_security.zip
+ 
geode-core/src/test/resources/org/apache/geode/management/internal/configuration/group1.jar
+ 
geode-core/src/test/resources/org/apache/geode/management/internal/configuration/group2.jar
{code}

We need to convert our tests to generate these files dynamically instead so 
that we don't have binary files checked into our repository.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Apache policy on files types allowed in source code

[Kirk Lund]

[bump]

I want to see a definitive reference on what's allowed to be in the src of
an Apache project before we take actions to change any tests that use
binary resources.

We have unit tests and regression tests that are using binaries (including
stat files, diskstore files, class files). Jumping through hoops to execute
a test that requires an old binary that was generated by old geode src
prior to a bug fix (stats, diskstores, etc) or that needs to compile
against old geode src (backwards compatibility of user callbacks) seems
like a huge waste of time and energy.

Please provide more info on list if anyone has issues with what's in geode
src code.

Thanks,
Kirk


On Wed, Nov 2, 2016 at 1:46 PM, Kirk Lund  wrote:

> I do have a particular case in mind involving stats files that geode
> creates and reads. The StatArchiveWriter.java class writes out statistic
> archive files for geode, while StatArchiveReader.java reads them in.
>
> There have been a few bugs causing the stats files to be corrupted in some
> way. My goal has been to fix the StatArchiveWriter to prevent any
> corruption, but also fix the StatArchiveReader to self-correct where
> possible or provide better error handling if self-correction is not
> possible.
>
> The result is that we have a couple regression tests under
> geode-core/src/test/java with corresponding corrupted statistic archive
> files under geode-core/src/test/resources.
>
> Example: I currently have a review posted for GEODE-2013 https://reviews.
> apache.org/r/53402 with these files:
>
> geode-core/src/main/java/org/apache/geode/internal/
> statistics/StatArchiveReader.java
> geode-core/src/test/java/org/apache/geode/internal/statistics/
> StatArchiveWithMissingResourceTypeRegressionTest.java
> geode-core/src/test/resources/org/apache/geode/internal/statistics/
> StatArchiveWithMissingResourceTypeRegressionTest.gfs
>
> The above file StatArchiveWithMissingResourceTypeRegressionTest.gfs is
> small (253 bytes on Mac). After fixing the source of the problem in
> StatArchiveWriter (GEODE-2012), GEODE-2013 involves providing better error
> messaging to the user if they try to read an older stats file that was
> written before GEODE-2012 was fixed.
>
> Thanks,
> Kirk
>
> On Wed, Nov 2, 2016 at 1:19 PM, Roman Shaposhnik 
> wrote:
>
>> On Wed, Nov 2, 2016 at 1:16 PM, Kirk Lund  wrote:
>> > I'd like to read up on what's allowed and disallowed regarding file
>> types
>> > in Apache source code. Does anyone have any links to get me started?
>>
>> The only distinction that ASF makes is binaries vs. source files. The
>> source
>> code that ASF releases has to be comprised of files that can be called
>> source (under a reasonable definition of source). The only requirement
>> for source files is that they MUST be usable without leveraging commercial
>> tools. Other than that -- anything goes.
>>
>> Are you asking with a particular example in mind or just asking a
>> hypothetical?
>>
>> Thanks,
>> Roman.
>>
>
>

[jira] [Created] (GEODE-2431) Upgrade use of Awaitility from 1.7.0 to 2.0.0

[Kirk Lund (JIRA)]

Kirk Lund created GEODE-2431:


 Summary: Upgrade use of Awaitility from 1.7.0 to 2.0.0
 Key: GEODE-2431
 URL: https://issues.apache.org/jira/browse/GEODE-2431
 Project: Geode
  Issue Type: Bug
  Components: tests
Reporter: Kirk Lund


Upgrade use of Awaitility from 1.7.0 to 2.0.0

See: https://github.com/awaitility/awaitility




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2431) Upgrade use of Awaitility from 1.7.0 to 2.0.0

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-2431:
-
Issue Type: Test  (was: Bug)

> Upgrade use of Awaitility from 1.7.0 to 2.0.0
> -
>
> Key: GEODE-2431
> URL: https://issues.apache.org/jira/browse/GEODE-2431
> Project: Geode
>  Issue Type: Test
>  Components: tests
>Reporter: Kirk Lund
>
> Upgrade use of Awaitility from 1.7.0 to 2.0.0
> See: https://github.com/awaitility/awaitility



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2431) Upgrade use of Awaitility from 1.7.0 to 2.0.0

[Kirk Lund (JIRA)]

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

Kirk Lund reassigned GEODE-2431:


Assignee: Kirk Lund

> Upgrade use of Awaitility from 1.7.0 to 2.0.0
> -
>
> Key: GEODE-2431
> URL: https://issues.apache.org/jira/browse/GEODE-2431
> Project: Geode
>  Issue Type: Test
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> Upgrade use of Awaitility from 1.7.0 to 2.0.0
> See: https://github.com/awaitility/awaitility



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Review Request 56332: GEODE-2431: Upgrade use of Awaitility from 1.7.0 to 2.0.0

[Kirk Lund]

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

Review request for geode, Anthony Baker, Bruce Schuchardt, Darrel Schneider, 
Jacob Barrett, Jinmei Liao, Jared Stewart, and Dan Smith.


Bugs: GEODE-2431
https://issues.apache.org/jira/browse/GEODE-2431


Repository: geode


Description
---

GEODE-2431: Upgrade use of Awaitility from 1.7.0 to 2.0.0


Diffs
-

  
geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseDataExportTest.java
 3c4fe7099fba4c574a01f98c36e4d9a5fa15c573 
  geode-core/src/test/java/org/apache/geode/SystemFailureJUnitTest.java 
279d8ddff2620677f3c6a9dc89945b05c7631385 
  
geode-core/src/test/java/org/apache/geode/cache/asyncqueue/AsyncEventQueueEvictionAndExpirationJUnitTest.java
 bafb499f7f6894ebada8e105bed72650b24e3ab6 
  
geode-core/src/test/java/org/apache/geode/cache/client/internal/AutoConnectionSourceImplJUnitTest.java
 2f9f867a0e5854e566cb445b24067a915d9c78f1 
  
geode-core/src/test/java/org/apache/geode/cache/client/internal/LocatorLoadBalancingDUnitTest.java
 bd8143ee23d36b5317b76797ee3f18640abc0873 
  
geode-core/src/test/java/org/apache/geode/cache/client/internal/SingleHopClientExecutorSubmitTaskWithExceptionTest.java
 3a9ece91da5bbbe98404a72b32b4f72e05596dd2 
  
geode-core/src/test/java/org/apache/geode/cache/query/cq/dunit/CqQueryTestListener.java
 79209ef9c9f4a74df7991bcaf123515270d041b5 
  
geode-core/src/test/java/org/apache/geode/cache/query/dunit/QueryUsingPoolDUnitTest.java
 5a0d3fc5513dea36b6a816cbb20b73c92879c3e9 
  geode-core/src/test/java/org/apache/geode/cache30/Bug44418JUnitTest.java 
abb4a9f04456cc75677fa67306fa74c9353c92f3 
  
geode-core/src/test/java/org/apache/geode/cache30/ClientMembershipDUnitTest.java
 37561630b089b2fc6dd23689f524be967f17a2e0 
  
geode-core/src/test/java/org/apache/geode/cache30/ClientServerCCEDUnitTest.java 
978056327237df86662dc9174239b9b22714e926 
  geode-core/src/test/java/org/apache/geode/cache30/ReconnectDUnitTest.java 
03ce0b81b946a268e6edd91b57bd834d9647ff1a 
  geode-core/src/test/java/org/apache/geode/distributed/LocatorDUnitTest.java 
2e80107b2f38652ac2457eb892f7967c97a0fe0a 
  geode-core/src/test/java/org/apache/geode/distributed/LocatorJUnitTest.java 
fb412563fc30278e80a7102eb67bd434ab90988c 
  
geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionManagerDUnitTest.java
 3b8da03299baa832c12a3e9f2ef833d3a6a4e8b6 
  
geode-core/src/test/java/org/apache/geode/distributed/internal/deadlock/GemFireDeadlockDetectorDUnitTest.java
 9b68b23d0fe2b6a6c5f96283d46e79b5a4a0602e 
  
geode-core/src/test/java/org/apache/geode/distributed/internal/membership/gms/fd/GMSHealthMonitorJUnitTest.java
 792a1fdabd4b3433cb16a93c89c30169eb227bc6 
  
geode-core/src/test/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeaveJUnitTest.java
 14fedc61e3a9f55444e0df86add6fd54a4a153bc 
  
geode-core/src/test/java/org/apache/geode/internal/ScheduledThreadPoolExecutorWithKeepAliveJUnitTest.java
 c354c98219083b62d5f4ab5547eda47c41c3d389 
  
geode-core/src/test/java/org/apache/geode/internal/cache/ClientServerTransactionDUnitTest.java
 a37aebd9e03ff40502d6807f2029c4cd86fce4a9 
  
geode-core/src/test/java/org/apache/geode/internal/cache/DiskRegRecoveryJUnitTest.java
 d6ee1ea89063bef174e2515ac341c7aa24d3cea0 
  
geode-core/src/test/java/org/apache/geode/internal/cache/EntryEventImplTest.java
 07d7f4dd14c11559e507d4b5d8bdb68f075aacc3 
  
geode-core/src/test/java/org/apache/geode/internal/cache/FireAndForgetFunctionOnAllServersDUnitTest.java
 d733ae0407edab6ee4ff60c9cba4ff64feb5144f 
  
geode-core/src/test/java/org/apache/geode/internal/cache/FixedPRSinglehopDUnitTest.java
 8c6d8b2e6fdc84562168d4d44d6a59436b0891f7 
  
geode-core/src/test/java/org/apache/geode/internal/cache/GemFireCacheImplTest.java
 5f550e2fc14a8b86bbb93c70079e5a1ee137a9af 
  
geode-core/src/test/java/org/apache/geode/internal/cache/MultipleOplogsRollingFeatureJUnitTest.java
 85d19af7f0edd810b463795428408a47025839ee 
  geode-core/src/test/java/org/apache/geode/internal/cache/OplogJUnitTest.java 
7df8982fd9c9ab57d78438469a84721c387b5379 
  
geode-core/src/test/java/org/apache/geode/internal/cache/PartitionedRegionSingleHopDUnitTest.java
 43096d6ee36997fb70014e8ae4bdac5f591fab0a 
  
geode-core/src/test/java/org/apache/geode/internal/cache/SingleHopStatsDUnitTest.java
 0d57155aceea26623ec2a43764e8c4a8e8a474ad 
  
geode-core/src/test/java/org/apache/geode/internal/cache/TXManagerImplTest.java 
3a5de2f63646793223098e1ad0289a5253d6af43 
  
geode-core/src/test/java/org/apache/geode/internal/cache/ha/BlockingHARegionQueueJUnitTest.java
 ee1cd6d6e8c845af03a95ee4d8ec442fa94168a3 
  
geode-core/src/test/java/org/apache/geode/internal/cache/ha/HARegionQueueJUnitTest.java
 43f1ac72bd2991d202762ea2aaa6a25340af66b0 
  
geode-core/src/test/java/org/apache/geode/internal/cache/lock

Review Request 56333: GEODE-2429 Fix a race that causes NPE in JtaAfterCompletionMessage.operateOnTx()

[Eric Shu]

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

Review request for geode, anilkumar gingade and Darrel Schneider.


Bugs: GEODE-2429
https://issues.apache.org/jira/browse/GEODE-2429


Repository: geode


Description
---

Do not run JTA afterCompletion on server if beforeCompletion is failed.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/internal/cache/tx/ClientTXStateStub.java
 e79324d 

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


Testing
---

precheckin.


Thanks,

Eric Shu

[jira] [Commented] (GEODE-2386) Unable to launch dunit VMs in nightly builds

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2386:


Commit 3a12d61197877b55b882ebb69caf760b699c785b in geode's branch 
refs/heads/feature/GEODE-1930-2 from [~upthewaterspout]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=3a12d61 ]

GEODE-2386 Don't call System.setProperties(null) when rule is used twice

Fixing DistributedRestoreSystemProperties rule so that if the rule is
included twice within a test, it does not end up calling
System.setProperties(null). That will prevent us from losing the value
of java.class.path set by gradle.

Reverting the workaround that didn't actually work.


> Unable to launch dunit VMs in nightly builds
> 
>
> Key: GEODE-2386
> URL: https://issues.apache.org/jira/browse/GEODE-2386
> Project: Geode
>  Issue Type: Bug
>  Components: build, tests
>Reporter: Dan Smith
>Assignee: Dan Smith
> Fix For: 1.1.0
>
> Attachments: reproduce.patch
>
>
> The recent apache nightly builds for the release branch and develop are 
> seeing lucene tests fail with "java.lang.RuntimeException: Unable to launch 
> dunit VMs". In the logs we see this error message:
> "[locator] Error: Could not find or load main class 
> org.apache.geode.test.dunit.standalone.ChildVM"
> We need to figure out what's going on.
> https://builds.apache.org/job/Geode-release/40/#showFailuresLink
> https://builds.apache.org/job/Geode-nightly/731/
> {noformat}
> Stacktrace
> java.lang.RuntimeException: Unable to launch dunit VMs
>   at 
> org.apache.geode.test.dunit.standalone.DUnitLauncher.launchIfNeeded(DUnitLauncher.java:144)
>   at 
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.initializeDistributedTestCase(JUnit4DistributedTestCase.java:131)
>   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.RunBefores.evaluate(RunBefores.java:24)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:377)
>   at 
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
>   at 
> org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
>   at 
> java.util.concurrent.Thre

[jira] [Commented] (GEODE-1672) When amount of overflowed persisted data exceeds heap size startup may run out of memory

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1672:


Commit 086df14b0dce92c5dd0678f36879533d310d9a37 in geode's branch 
refs/heads/feature/GEODE-1930-2 from [~agingade]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=086df14 ]

GEODE-1672: Added recovery wait for all the regions created to
address race condition in the test.


> When amount of overflowed persisted data exceeds heap size startup may run 
> out of memory
> 
>
> Key: GEODE-1672
> URL: https://issues.apache.org/jira/browse/GEODE-1672
> Project: Geode
>  Issue Type: Bug
>  Components: docs, persistence
>Reporter: Darrel Schneider
>
> Basically, when the amount of data overflowed approaches the heap size, ,such 
> that the total amount of data is very close to or actually surpasses your 
> total tenured heap, it is possible that you will not be able to restart.
> The algorithm during recovery of oplogs/buckets is such that we don't "evict" 
> in the normal sense as data fills the heap during early stages of recovery 
> prior to creating the regions. When the data is first created in the heap, 
> it's not yet official in the region.
> At any rate, if during this early phase of recovery, or during subsequent 
> phase where eviction is working as usual, it is possible that the total data 
> or an early imbalance of buckets prior to the opportunity to rebalance causes 
> us to surpass the critical threshold which will kill us before successful 
> startup.
> To reproduce, you could have 1 region with tons of data that evicts and 
> overflows with persistence. Call it R1. Then another region with persistence 
> that does not evict. Call it R2.
> List R1 fist in the cache.xml file. Start running the system and add data 
> over time until you have overflowed tons of data approaching the heap size in 
> the evicted region, and also have enough data in the R2 region.
> Once you fill these regions with enough data and have overflowed enough to 
> disk and persisted the other region, then shutdown, and then attempt to 
> restart. If you put enough data in, you will hit the critical threshold 
> before being able to complete startup.
> You can work around this issue by configuring geode to not recovery values by 
> setting this system property: -Dgemfire.disk.recoverValues=false
> Values will not be faulted into memory until a read operation is done on that 
> value's key.
> If you have regions that do not use overflow and some that do then another 
> work around is the create the regions that do not use overflow first. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2430) Remove binary files from test resources

[Jared Stewart (JIRA)]

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

Jared Stewart commented on GEODE-2430:
--

Cluster.jar is used by: 
ClusterConfigDeployJarDUnitTest
ClusterConfigBaseTest.java

cluster_config.zip is used by:
ClusterConfigBaseTest.java

cluster_config_security.zip is used by:
ClusterConfigWithSecurityDUnitTest

group1.jar and group2.jar are used by:
ClusterConfigDeployJarDUnitTest.java

> Remove binary files from test resources
> ---
>
> Key: GEODE-2430
> URL: https://issues.apache.org/jira/browse/GEODE-2430
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> We have some tests which rely on the following binary files:
> {code}
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster.jar
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config.zip
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config_security.zip
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/group1.jar
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/group2.jar
> {code}
> We need to convert our tests to generate these files dynamically instead so 
> that we don't have binary files checked into our repository.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 56332: GEODE-2431: Upgrade use of Awaitility from 1.7.0 to 2.0.0

[Kirk Lund]

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

(Updated Feb. 6, 2017, 6:18 p.m.)


Review request for geode, Anthony Baker, Bruce Schuchardt, Darrel Schneider, 
Jacob Barrett, Jinmei Liao, Jared Stewart, and Dan Smith.


Changes
---

All of the Flaky tests pass when rerun: LocatorDUnitTest, 
LocatorUDPSecurityDUnitTest, LuceneQueriesPeerPRRedundancyDUnitTest


Bugs: GEODE-2431
https://issues.apache.org/jira/browse/GEODE-2431


Repository: geode


Description
---

GEODE-2431: Upgrade use of Awaitility from 1.7.0 to 2.0.0


Diffs
-

  
geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseDataExportTest.java
 3c4fe7099fba4c574a01f98c36e4d9a5fa15c573 
  geode-core/src/test/java/org/apache/geode/SystemFailureJUnitTest.java 
279d8ddff2620677f3c6a9dc89945b05c7631385 
  
geode-core/src/test/java/org/apache/geode/cache/asyncqueue/AsyncEventQueueEvictionAndExpirationJUnitTest.java
 bafb499f7f6894ebada8e105bed72650b24e3ab6 
  
geode-core/src/test/java/org/apache/geode/cache/client/internal/AutoConnectionSourceImplJUnitTest.java
 2f9f867a0e5854e566cb445b24067a915d9c78f1 
  
geode-core/src/test/java/org/apache/geode/cache/client/internal/LocatorLoadBalancingDUnitTest.java
 bd8143ee23d36b5317b76797ee3f18640abc0873 
  
geode-core/src/test/java/org/apache/geode/cache/client/internal/SingleHopClientExecutorSubmitTaskWithExceptionTest.java
 3a9ece91da5bbbe98404a72b32b4f72e05596dd2 
  
geode-core/src/test/java/org/apache/geode/cache/query/cq/dunit/CqQueryTestListener.java
 79209ef9c9f4a74df7991bcaf123515270d041b5 
  
geode-core/src/test/java/org/apache/geode/cache/query/dunit/QueryUsingPoolDUnitTest.java
 5a0d3fc5513dea36b6a816cbb20b73c92879c3e9 
  geode-core/src/test/java/org/apache/geode/cache30/Bug44418JUnitTest.java 
abb4a9f04456cc75677fa67306fa74c9353c92f3 
  
geode-core/src/test/java/org/apache/geode/cache30/ClientMembershipDUnitTest.java
 37561630b089b2fc6dd23689f524be967f17a2e0 
  
geode-core/src/test/java/org/apache/geode/cache30/ClientServerCCEDUnitTest.java 
978056327237df86662dc9174239b9b22714e926 
  geode-core/src/test/java/org/apache/geode/cache30/ReconnectDUnitTest.java 
03ce0b81b946a268e6edd91b57bd834d9647ff1a 
  geode-core/src/test/java/org/apache/geode/distributed/LocatorDUnitTest.java 
2e80107b2f38652ac2457eb892f7967c97a0fe0a 
  geode-core/src/test/java/org/apache/geode/distributed/LocatorJUnitTest.java 
fb412563fc30278e80a7102eb67bd434ab90988c 
  
geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionManagerDUnitTest.java
 3b8da03299baa832c12a3e9f2ef833d3a6a4e8b6 
  
geode-core/src/test/java/org/apache/geode/distributed/internal/deadlock/GemFireDeadlockDetectorDUnitTest.java
 9b68b23d0fe2b6a6c5f96283d46e79b5a4a0602e 
  
geode-core/src/test/java/org/apache/geode/distributed/internal/membership/gms/fd/GMSHealthMonitorJUnitTest.java
 792a1fdabd4b3433cb16a93c89c30169eb227bc6 
  
geode-core/src/test/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeaveJUnitTest.java
 14fedc61e3a9f55444e0df86add6fd54a4a153bc 
  
geode-core/src/test/java/org/apache/geode/internal/ScheduledThreadPoolExecutorWithKeepAliveJUnitTest.java
 c354c98219083b62d5f4ab5547eda47c41c3d389 
  
geode-core/src/test/java/org/apache/geode/internal/cache/ClientServerTransactionDUnitTest.java
 a37aebd9e03ff40502d6807f2029c4cd86fce4a9 
  
geode-core/src/test/java/org/apache/geode/internal/cache/DiskRegRecoveryJUnitTest.java
 d6ee1ea89063bef174e2515ac341c7aa24d3cea0 
  
geode-core/src/test/java/org/apache/geode/internal/cache/EntryEventImplTest.java
 07d7f4dd14c11559e507d4b5d8bdb68f075aacc3 
  
geode-core/src/test/java/org/apache/geode/internal/cache/FireAndForgetFunctionOnAllServersDUnitTest.java
 d733ae0407edab6ee4ff60c9cba4ff64feb5144f 
  
geode-core/src/test/java/org/apache/geode/internal/cache/FixedPRSinglehopDUnitTest.java
 8c6d8b2e6fdc84562168d4d44d6a59436b0891f7 
  
geode-core/src/test/java/org/apache/geode/internal/cache/GemFireCacheImplTest.java
 5f550e2fc14a8b86bbb93c70079e5a1ee137a9af 
  
geode-core/src/test/java/org/apache/geode/internal/cache/MultipleOplogsRollingFeatureJUnitTest.java
 85d19af7f0edd810b463795428408a47025839ee 
  geode-core/src/test/java/org/apache/geode/internal/cache/OplogJUnitTest.java 
7df8982fd9c9ab57d78438469a84721c387b5379 
  
geode-core/src/test/java/org/apache/geode/internal/cache/PartitionedRegionSingleHopDUnitTest.java
 43096d6ee36997fb70014e8ae4bdac5f591fab0a 
  
geode-core/src/test/java/org/apache/geode/internal/cache/SingleHopStatsDUnitTest.java
 0d57155aceea26623ec2a43764e8c4a8e8a474ad 
  
geode-core/src/test/java/org/apache/geode/internal/cache/TXManagerImplTest.java 
3a5de2f63646793223098e1ad0289a5253d6af43 
  
geode-core/src/test/java/org/apache/geode/internal/cache/ha/BlockingHARegionQueueJUnitTest.java
 ee1cd6d6e8c845af03a95ee4d8ec442fa94168a3 
  
geode-core/sr

Re: Review Request 56332: GEODE-2431: Upgrade use of Awaitility from 1.7.0 to 2.0.0

[Jinmei Liao]

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



Looks like nothing changes except import statement and the version? Are these 
tests failing constantly when run together with other flaky?

- Jinmei Liao


On Feb. 6, 2017, 6:18 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56332/
> ---
> 
> (Updated Feb. 6, 2017, 6:18 p.m.)
> 
> 
> Review request for geode, Anthony Baker, Bruce Schuchardt, Darrel Schneider, 
> Jacob Barrett, Jinmei Liao, Jared Stewart, and Dan Smith.
> 
> 
> Bugs: GEODE-2431
> https://issues.apache.org/jira/browse/GEODE-2431
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2431: Upgrade use of Awaitility from 1.7.0 to 2.0.0
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseDataExportTest.java
>  3c4fe7099fba4c574a01f98c36e4d9a5fa15c573 
>   geode-core/src/test/java/org/apache/geode/SystemFailureJUnitTest.java 
> 279d8ddff2620677f3c6a9dc89945b05c7631385 
>   
> geode-core/src/test/java/org/apache/geode/cache/asyncqueue/AsyncEventQueueEvictionAndExpirationJUnitTest.java
>  bafb499f7f6894ebada8e105bed72650b24e3ab6 
>   
> geode-core/src/test/java/org/apache/geode/cache/client/internal/AutoConnectionSourceImplJUnitTest.java
>  2f9f867a0e5854e566cb445b24067a915d9c78f1 
>   
> geode-core/src/test/java/org/apache/geode/cache/client/internal/LocatorLoadBalancingDUnitTest.java
>  bd8143ee23d36b5317b76797ee3f18640abc0873 
>   
> geode-core/src/test/java/org/apache/geode/cache/client/internal/SingleHopClientExecutorSubmitTaskWithExceptionTest.java
>  3a9ece91da5bbbe98404a72b32b4f72e05596dd2 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/cq/dunit/CqQueryTestListener.java
>  79209ef9c9f4a74df7991bcaf123515270d041b5 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/QueryUsingPoolDUnitTest.java
>  5a0d3fc5513dea36b6a816cbb20b73c92879c3e9 
>   geode-core/src/test/java/org/apache/geode/cache30/Bug44418JUnitTest.java 
> abb4a9f04456cc75677fa67306fa74c9353c92f3 
>   
> geode-core/src/test/java/org/apache/geode/cache30/ClientMembershipDUnitTest.java
>  37561630b089b2fc6dd23689f524be967f17a2e0 
>   
> geode-core/src/test/java/org/apache/geode/cache30/ClientServerCCEDUnitTest.java
>  978056327237df86662dc9174239b9b22714e926 
>   geode-core/src/test/java/org/apache/geode/cache30/ReconnectDUnitTest.java 
> 03ce0b81b946a268e6edd91b57bd834d9647ff1a 
>   geode-core/src/test/java/org/apache/geode/distributed/LocatorDUnitTest.java 
> 2e80107b2f38652ac2457eb892f7967c97a0fe0a 
>   geode-core/src/test/java/org/apache/geode/distributed/LocatorJUnitTest.java 
> fb412563fc30278e80a7102eb67bd434ab90988c 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionManagerDUnitTest.java
>  3b8da03299baa832c12a3e9f2ef833d3a6a4e8b6 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/deadlock/GemFireDeadlockDetectorDUnitTest.java
>  9b68b23d0fe2b6a6c5f96283d46e79b5a4a0602e 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/membership/gms/fd/GMSHealthMonitorJUnitTest.java
>  792a1fdabd4b3433cb16a93c89c30169eb227bc6 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeaveJUnitTest.java
>  14fedc61e3a9f55444e0df86add6fd54a4a153bc 
>   
> geode-core/src/test/java/org/apache/geode/internal/ScheduledThreadPoolExecutorWithKeepAliveJUnitTest.java
>  c354c98219083b62d5f4ab5547eda47c41c3d389 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/ClientServerTransactionDUnitTest.java
>  a37aebd9e03ff40502d6807f2029c4cd86fce4a9 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/DiskRegRecoveryJUnitTest.java
>  d6ee1ea89063bef174e2515ac341c7aa24d3cea0 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/EntryEventImplTest.java
>  07d7f4dd14c11559e507d4b5d8bdb68f075aacc3 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/FireAndForgetFunctionOnAllServersDUnitTest.java
>  d733ae0407edab6ee4ff60c9cba4ff64feb5144f 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/FixedPRSinglehopDUnitTest.java
>  8c6d8b2e6fdc84562168d4d44d6a59436b0891f7 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/GemFireCacheImplTest.java
>  5f550e2fc14a8b86bbb93c70079e5a1ee137a9af 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/MultipleOplogsRollingFeatureJUnitTest.java
>  85d19af7f0edd810b463795428408a47025839ee 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/OplogJUnitTest.java 
> 7df8982fd9c9ab57d78438469a84721c387b5379 
>   
> geode-core/src/test/java/org/apache/geode/internal/ca

Re: Apache policy on files types allowed in source code

[Dan Smith]

I don't know about apache policy, but I think anything that can't be easily
modified is probably a bad thing to have in the source code. If there is a
binary jar, but there's no way to update the jar to modify the test that
seems like a problem.

Since we have a framework to run tests with old versions and new versions
of geode, I don't see why there should be any reason to check in artifacts
generated by old versions of geode either.

Can you describe the specific tests? I saw Anthony's downvote on the
release, but it's not clear what tests use those artifacts or what they are
for.

-Dan

On Mon, Feb 6, 2017 at 9:28 AM, Kirk Lund  wrote:

> [bump]
>
> I want to see a definitive reference on what's allowed to be in the src of
> an Apache project before we take actions to change any tests that use
> binary resources.
>
> We have unit tests and regression tests that are using binaries (including
> stat files, diskstore files, class files). Jumping through hoops to execute
> a test that requires an old binary that was generated by old geode src
> prior to a bug fix (stats, diskstores, etc) or that needs to compile
> against old geode src (backwards compatibility of user callbacks) seems
> like a huge waste of time and energy.
>
> Please provide more info on list if anyone has issues with what's in geode
> src code.
>
> Thanks,
> Kirk
>
>
> On Wed, Nov 2, 2016 at 1:46 PM, Kirk Lund  wrote:
>
> > I do have a particular case in mind involving stats files that geode
> > creates and reads. The StatArchiveWriter.java class writes out statistic
> > archive files for geode, while StatArchiveReader.java reads them in.
> >
> > There have been a few bugs causing the stats files to be corrupted in
> some
> > way. My goal has been to fix the StatArchiveWriter to prevent any
> > corruption, but also fix the StatArchiveReader to self-correct where
> > possible or provide better error handling if self-correction is not
> > possible.
> >
> > The result is that we have a couple regression tests under
> > geode-core/src/test/java with corresponding corrupted statistic archive
> > files under geode-core/src/test/resources.
> >
> > Example: I currently have a review posted for GEODE-2013 https://reviews
> .
> > apache.org/r/53402 with these files:
> >
> > geode-core/src/main/java/org/apache/geode/internal/
> > statistics/StatArchiveReader.java
> > geode-core/src/test/java/org/apache/geode/internal/statistics/
> > StatArchiveWithMissingResourceTypeRegressionTest.java
> > geode-core/src/test/resources/org/apache/geode/internal/statistics/
> > StatArchiveWithMissingResourceTypeRegressionTest.gfs
> >
> > The above file StatArchiveWithMissingResourceTypeRegressionTest.gfs is
> > small (253 bytes on Mac). After fixing the source of the problem in
> > StatArchiveWriter (GEODE-2012), GEODE-2013 involves providing better
> error
> > messaging to the user if they try to read an older stats file that was
> > written before GEODE-2012 was fixed.
> >
> > Thanks,
> > Kirk
> >
> > On Wed, Nov 2, 2016 at 1:19 PM, Roman Shaposhnik 
> > wrote:
> >
> >> On Wed, Nov 2, 2016 at 1:16 PM, Kirk Lund  wrote:
> >> > I'd like to read up on what's allowed and disallowed regarding file
> >> types
> >> > in Apache source code. Does anyone have any links to get me started?
> >>
> >> The only distinction that ASF makes is binaries vs. source files. The
> >> source
> >> code that ASF releases has to be comprised of files that can be called
> >> source (under a reasonable definition of source). The only requirement
> >> for source files is that they MUST be usable without leveraging
> commercial
> >> tools. Other than that -- anything goes.
> >>
> >> Are you asking with a particular example in mind or just asking a
> >> hypothetical?
> >>
> >> Thanks,
> >> Roman.
> >>
> >
> >
>

Re: Apache policy on files types allowed in source code

[Anthony Baker]

Well, here’s a rule of thumb:  if the file was generated by a compiler it’s 
probably not source :-)

Binary files such as images, diskstores, stats, etc should ok.  There are lots 
of discussions on this topic, see [1] for example.  Take a look at our current 
list of rat excludes in ‘gradle/rat.gradle’.

Anthony

[1] 
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201701.mbox/%3ccaoqetn_sqqv8z3td+xtgibnbxgemogubju-2afasoqbsrow...@mail.gmail.com%3e


> On Feb 6, 2017, at 9:28 AM, Kirk Lund  wrote:
> 
> [bump]
> 
> I want to see a definitive reference on what's allowed to be in the src of
> an Apache project before we take actions to change any tests that use
> binary resources.
> 
> We have unit tests and regression tests that are using binaries (including
> stat files, diskstore files, class files). Jumping through hoops to execute
> a test that requires an old binary that was generated by old geode src
> prior to a bug fix (stats, diskstores, etc) or that needs to compile
> against old geode src (backwards compatibility of user callbacks) seems
> like a huge waste of time and energy.
> 
> Please provide more info on list if anyone has issues with what's in geode
> src code.
> 
> Thanks,
> Kirk
> 
> 
> On Wed, Nov 2, 2016 at 1:46 PM, Kirk Lund  wrote:
> 
>> I do have a particular case in mind involving stats files that geode
>> creates and reads. The StatArchiveWriter.java class writes out statistic
>> archive files for geode, while StatArchiveReader.java reads them in.
>> 
>> There have been a few bugs causing the stats files to be corrupted in some
>> way. My goal has been to fix the StatArchiveWriter to prevent any
>> corruption, but also fix the StatArchiveReader to self-correct where
>> possible or provide better error handling if self-correction is not
>> possible.
>> 
>> The result is that we have a couple regression tests under
>> geode-core/src/test/java with corresponding corrupted statistic archive
>> files under geode-core/src/test/resources.
>> 
>> Example: I currently have a review posted for GEODE-2013 https://reviews.
>> apache.org/r/53402 with these files:
>> 
>> geode-core/src/main/java/org/apache/geode/internal/
>> statistics/StatArchiveReader.java
>> geode-core/src/test/java/org/apache/geode/internal/statistics/
>> StatArchiveWithMissingResourceTypeRegressionTest.java
>> geode-core/src/test/resources/org/apache/geode/internal/statistics/
>> StatArchiveWithMissingResourceTypeRegressionTest.gfs
>> 
>> The above file StatArchiveWithMissingResourceTypeRegressionTest.gfs is
>> small (253 bytes on Mac). After fixing the source of the problem in
>> StatArchiveWriter (GEODE-2012), GEODE-2013 involves providing better error
>> messaging to the user if they try to read an older stats file that was
>> written before GEODE-2012 was fixed.
>> 
>> Thanks,
>> Kirk
>> 
>> On Wed, Nov 2, 2016 at 1:19 PM, Roman Shaposhnik 
>> wrote:
>> 
>>> On Wed, Nov 2, 2016 at 1:16 PM, Kirk Lund  wrote:
 I'd like to read up on what's allowed and disallowed regarding file
>>> types
 in Apache source code. Does anyone have any links to get me started?
>>> 
>>> The only distinction that ASF makes is binaries vs. source files. The
>>> source
>>> code that ASF releases has to be comprised of files that can be called
>>> source (under a reasonable definition of source). The only requirement
>>> for source files is that they MUST be usable without leveraging commercial
>>> tools. Other than that -- anything goes.
>>> 
>>> Are you asking with a particular example in mind or just asking a
>>> hypothetical?
>>> 
>>> Thanks,
>>> Roman.
>>> 
>> 
>> 

Re: geode-old-versions subproject?

[Anthony Baker]

It looks like it was an incomplete removal:

geode-core/build.gradle:  testCompile project(':geode-old-versions')
geode-core/src/test/java/org/apache/geode/test/dunit/standalone/VersionManager.java:
File propFile = new 
File("../../../geode-old-versions/build/geodeOldVersionClasspaths.txt");
geode-core/src/test/java/org/apache/geode/test/dunit/standalone/VersionManager.java:
  propFile = new 
File("../geode-old-versions/build/geodeOldVersionClasspaths.txt");
settings.gradle:include 'geode-old-versions'

I noticed the geode-old-versions showed up in the src release as an empty dir, 
which is probably not a good thing.

Anthony

> On Feb 3, 2017, at 4:24 PM, Dan Smith  wrote:
> 
> One thing Hitesh and I noticed is that when you do a build, it creates a
> directory called geode-old-versions because there is a line in
> settings.gradle for a geode-old-versions project.
> 
> Is this leftover cruft, or is it actually supposed to be there? I see a
> couple of references to geode-old-versions in the source as well.
> 
> -Dan

[jira] [Created] (GEODE-2432) Don't create and upload empty maven artifacts for geode-benchmarks, geode-old-versions

[Dan Smith (JIRA)]

Dan Smith created GEODE-2432:


 Summary: Don't create and upload empty maven artifacts for 
geode-benchmarks, geode-old-versions
 Key: GEODE-2432
 URL: https://issues.apache.org/jira/browse/GEODE-2432
 Project: Geode
  Issue Type: Bug
  Components: build
Reporter: Dan Smith


The 1.1.0.RC1 maven site shows that we're creating and uploading empty maven 
artifacts for these sub projects.

geode-benchmarks - this project contains only jmh tests
geode-old-versions - this project seems to be completely empty?

We should probably disable uploading maven archives for these projects.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Apache policy on files types allowed in source code

[Dave Barnes]

The docs directories contain binary files in various graphic formats: svg,
png, gif, jpg and the like.
I haven't made a practice of checking in the 'sources' for these, because
they're nearly always created with proprietary tools, such as Visio or
OmniGraffle. The workflow for graphics is different from that of compiled
code, as contributors in the community can update these graphics by
starting with the binaries and using their own tools, then push their
binary output to the repo. No original source required, even though the
file in the repo is in some sense a binary 'artifact'.

On Mon, Feb 6, 2017 at 10:33 AM, Anthony Baker  wrote:

> Well, here’s a rule of thumb:  if the file was generated by a compiler
> it’s probably not source :-)
>
> Binary files such as images, diskstores, stats, etc should ok.  There are
> lots of discussions on this topic, see [1] for example.  Take a look at our
> current list of rat excludes in ‘gradle/rat.gradle’.
>
> Anthony
>
> [1] http://mail-archives.apache.org/mod_mbox/www-legal-
> discuss/201701.mbox/%3cCAOqetn_SQQV8z3tD+XtGiBNBXGEmogUbju-
> 2afasoqbsrow...@mail.gmail.com%3e
>
>
> > On Feb 6, 2017, at 9:28 AM, Kirk Lund  wrote:
> >
> > [bump]
> >
> > I want to see a definitive reference on what's allowed to be in the src
> of
> > an Apache project before we take actions to change any tests that use
> > binary resources.
> >
> > We have unit tests and regression tests that are using binaries
> (including
> > stat files, diskstore files, class files). Jumping through hoops to
> execute
> > a test that requires an old binary that was generated by old geode src
> > prior to a bug fix (stats, diskstores, etc) or that needs to compile
> > against old geode src (backwards compatibility of user callbacks) seems
> > like a huge waste of time and energy.
> >
> > Please provide more info on list if anyone has issues with what's in
> geode
> > src code.
> >
> > Thanks,
> > Kirk
> >
> >
> > On Wed, Nov 2, 2016 at 1:46 PM, Kirk Lund  wrote:
> >
> >> I do have a particular case in mind involving stats files that geode
> >> creates and reads. The StatArchiveWriter.java class writes out statistic
> >> archive files for geode, while StatArchiveReader.java reads them in.
> >>
> >> There have been a few bugs causing the stats files to be corrupted in
> some
> >> way. My goal has been to fix the StatArchiveWriter to prevent any
> >> corruption, but also fix the StatArchiveReader to self-correct where
> >> possible or provide better error handling if self-correction is not
> >> possible.
> >>
> >> The result is that we have a couple regression tests under
> >> geode-core/src/test/java with corresponding corrupted statistic archive
> >> files under geode-core/src/test/resources.
> >>
> >> Example: I currently have a review posted for GEODE-2013
> https://reviews.
> >> apache.org/r/53402 with these files:
> >>
> >> geode-core/src/main/java/org/apache/geode/internal/
> >> statistics/StatArchiveReader.java
> >> geode-core/src/test/java/org/apache/geode/internal/statistics/
> >> StatArchiveWithMissingResourceTypeRegressionTest.java
> >> geode-core/src/test/resources/org/apache/geode/internal/statistics/
> >> StatArchiveWithMissingResourceTypeRegressionTest.gfs
> >>
> >> The above file StatArchiveWithMissingResourceTypeRegressionTest.gfs is
> >> small (253 bytes on Mac). After fixing the source of the problem in
> >> StatArchiveWriter (GEODE-2012), GEODE-2013 involves providing better
> error
> >> messaging to the user if they try to read an older stats file that was
> >> written before GEODE-2012 was fixed.
> >>
> >> Thanks,
> >> Kirk
> >>
> >> On Wed, Nov 2, 2016 at 1:19 PM, Roman Shaposhnik 
> >> wrote:
> >>
> >>> On Wed, Nov 2, 2016 at 1:16 PM, Kirk Lund  wrote:
>  I'd like to read up on what's allowed and disallowed regarding file
> >>> types
>  in Apache source code. Does anyone have any links to get me started?
> >>>
> >>> The only distinction that ASF makes is binaries vs. source files. The
> >>> source
> >>> code that ASF releases has to be comprised of files that can be called
> >>> source (under a reasonable definition of source). The only requirement
> >>> for source files is that they MUST be usable without leveraging
> commercial
> >>> tools. Other than that -- anything goes.
> >>>
> >>> Are you asking with a particular example in mind or just asking a
> >>> hypothetical?
> >>>
> >>> Thanks,
> >>> Roman.
> >>>
> >>
> >>
>
>

Passed: apache/geode#1971 (awaitility - 0bfe4d1)

[Travis CI]

Build Update for apache/geode
-

Build: #1971
Status: Passed

Duration: 8 minutes and 57 seconds
Commit: 0bfe4d1 (awaitility)
Author: Kirk Lund
Message: Update to Awaitility 2.0

View the changeset: https://github.com/apache/geode/commit/0bfe4d15723a

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

--

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

Re: Review Request 56332: GEODE-2431: Upgrade use of Awaitility from 1.7.0 to 2.0.0

[Kirk Lund]

> On Feb. 6, 2017, 6:31 p.m., Jinmei Liao wrote:
> > Looks like nothing changes except import statement and the version? Are 
> > these tests failing constantly when run together with other flaky?

Those tests are failing pretty consistently in nightly builds and in my own 
personal precheckins. They are already categorized as FlakyTest so they are 
failing frequently even when run under the flakyTest task although they pass 
consistently when run by themselves. The failures have nothing to do with 
upgrading Awaitility though. 

I only point it out because FlakyTests that fail this frequently should get 
fixed or deleted.


- Kirk


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


On Feb. 6, 2017, 6:18 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56332/
> ---
> 
> (Updated Feb. 6, 2017, 6:18 p.m.)
> 
> 
> Review request for geode, Anthony Baker, Bruce Schuchardt, Darrel Schneider, 
> Jacob Barrett, Jinmei Liao, Jared Stewart, and Dan Smith.
> 
> 
> Bugs: GEODE-2431
> https://issues.apache.org/jira/browse/GEODE-2431
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2431: Upgrade use of Awaitility from 1.7.0 to 2.0.0
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseDataExportTest.java
>  3c4fe7099fba4c574a01f98c36e4d9a5fa15c573 
>   geode-core/src/test/java/org/apache/geode/SystemFailureJUnitTest.java 
> 279d8ddff2620677f3c6a9dc89945b05c7631385 
>   
> geode-core/src/test/java/org/apache/geode/cache/asyncqueue/AsyncEventQueueEvictionAndExpirationJUnitTest.java
>  bafb499f7f6894ebada8e105bed72650b24e3ab6 
>   
> geode-core/src/test/java/org/apache/geode/cache/client/internal/AutoConnectionSourceImplJUnitTest.java
>  2f9f867a0e5854e566cb445b24067a915d9c78f1 
>   
> geode-core/src/test/java/org/apache/geode/cache/client/internal/LocatorLoadBalancingDUnitTest.java
>  bd8143ee23d36b5317b76797ee3f18640abc0873 
>   
> geode-core/src/test/java/org/apache/geode/cache/client/internal/SingleHopClientExecutorSubmitTaskWithExceptionTest.java
>  3a9ece91da5bbbe98404a72b32b4f72e05596dd2 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/cq/dunit/CqQueryTestListener.java
>  79209ef9c9f4a74df7991bcaf123515270d041b5 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/QueryUsingPoolDUnitTest.java
>  5a0d3fc5513dea36b6a816cbb20b73c92879c3e9 
>   geode-core/src/test/java/org/apache/geode/cache30/Bug44418JUnitTest.java 
> abb4a9f04456cc75677fa67306fa74c9353c92f3 
>   
> geode-core/src/test/java/org/apache/geode/cache30/ClientMembershipDUnitTest.java
>  37561630b089b2fc6dd23689f524be967f17a2e0 
>   
> geode-core/src/test/java/org/apache/geode/cache30/ClientServerCCEDUnitTest.java
>  978056327237df86662dc9174239b9b22714e926 
>   geode-core/src/test/java/org/apache/geode/cache30/ReconnectDUnitTest.java 
> 03ce0b81b946a268e6edd91b57bd834d9647ff1a 
>   geode-core/src/test/java/org/apache/geode/distributed/LocatorDUnitTest.java 
> 2e80107b2f38652ac2457eb892f7967c97a0fe0a 
>   geode-core/src/test/java/org/apache/geode/distributed/LocatorJUnitTest.java 
> fb412563fc30278e80a7102eb67bd434ab90988c 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionManagerDUnitTest.java
>  3b8da03299baa832c12a3e9f2ef833d3a6a4e8b6 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/deadlock/GemFireDeadlockDetectorDUnitTest.java
>  9b68b23d0fe2b6a6c5f96283d46e79b5a4a0602e 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/membership/gms/fd/GMSHealthMonitorJUnitTest.java
>  792a1fdabd4b3433cb16a93c89c30169eb227bc6 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeaveJUnitTest.java
>  14fedc61e3a9f55444e0df86add6fd54a4a153bc 
>   
> geode-core/src/test/java/org/apache/geode/internal/ScheduledThreadPoolExecutorWithKeepAliveJUnitTest.java
>  c354c98219083b62d5f4ab5547eda47c41c3d389 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/ClientServerTransactionDUnitTest.java
>  a37aebd9e03ff40502d6807f2029c4cd86fce4a9 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/DiskRegRecoveryJUnitTest.java
>  d6ee1ea89063bef174e2515ac341c7aa24d3cea0 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/EntryEventImplTest.java
>  07d7f4dd14c11559e507d4b5d8bdb68f075aacc3 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/FireAndForgetFunctionOnAllServersDUnitTest.java
>  d733ae0407edab6ee4ff60c9cba4ff64feb5144f 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/FixedPRSinglehopDUnitTest.java
>  8c6d8b2e6fdc84562168d4d44d6a59436

[GitHub] geode issue #326: Feature/geode 2103 : Adding --http-service-port and --http...

[metatype]

Github user metatype commented on the issue:

https://github.com/apache/geode/pull/326
  
@jinmeiliao any thoughts on this change?


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

Re: Review Request 56332: GEODE-2431: Upgrade use of Awaitility from 1.7.0 to 2.0.0

[Jinmei Liao]

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


Ship it!




Ship It!

- Jinmei Liao


On Feb. 6, 2017, 6:18 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56332/
> ---
> 
> (Updated Feb. 6, 2017, 6:18 p.m.)
> 
> 
> Review request for geode, Anthony Baker, Bruce Schuchardt, Darrel Schneider, 
> Jacob Barrett, Jinmei Liao, Jared Stewart, and Dan Smith.
> 
> 
> Bugs: GEODE-2431
> https://issues.apache.org/jira/browse/GEODE-2431
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2431: Upgrade use of Awaitility from 1.7.0 to 2.0.0
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseDataExportTest.java
>  3c4fe7099fba4c574a01f98c36e4d9a5fa15c573 
>   geode-core/src/test/java/org/apache/geode/SystemFailureJUnitTest.java 
> 279d8ddff2620677f3c6a9dc89945b05c7631385 
>   
> geode-core/src/test/java/org/apache/geode/cache/asyncqueue/AsyncEventQueueEvictionAndExpirationJUnitTest.java
>  bafb499f7f6894ebada8e105bed72650b24e3ab6 
>   
> geode-core/src/test/java/org/apache/geode/cache/client/internal/AutoConnectionSourceImplJUnitTest.java
>  2f9f867a0e5854e566cb445b24067a915d9c78f1 
>   
> geode-core/src/test/java/org/apache/geode/cache/client/internal/LocatorLoadBalancingDUnitTest.java
>  bd8143ee23d36b5317b76797ee3f18640abc0873 
>   
> geode-core/src/test/java/org/apache/geode/cache/client/internal/SingleHopClientExecutorSubmitTaskWithExceptionTest.java
>  3a9ece91da5bbbe98404a72b32b4f72e05596dd2 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/cq/dunit/CqQueryTestListener.java
>  79209ef9c9f4a74df7991bcaf123515270d041b5 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/QueryUsingPoolDUnitTest.java
>  5a0d3fc5513dea36b6a816cbb20b73c92879c3e9 
>   geode-core/src/test/java/org/apache/geode/cache30/Bug44418JUnitTest.java 
> abb4a9f04456cc75677fa67306fa74c9353c92f3 
>   
> geode-core/src/test/java/org/apache/geode/cache30/ClientMembershipDUnitTest.java
>  37561630b089b2fc6dd23689f524be967f17a2e0 
>   
> geode-core/src/test/java/org/apache/geode/cache30/ClientServerCCEDUnitTest.java
>  978056327237df86662dc9174239b9b22714e926 
>   geode-core/src/test/java/org/apache/geode/cache30/ReconnectDUnitTest.java 
> 03ce0b81b946a268e6edd91b57bd834d9647ff1a 
>   geode-core/src/test/java/org/apache/geode/distributed/LocatorDUnitTest.java 
> 2e80107b2f38652ac2457eb892f7967c97a0fe0a 
>   geode-core/src/test/java/org/apache/geode/distributed/LocatorJUnitTest.java 
> fb412563fc30278e80a7102eb67bd434ab90988c 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionManagerDUnitTest.java
>  3b8da03299baa832c12a3e9f2ef833d3a6a4e8b6 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/deadlock/GemFireDeadlockDetectorDUnitTest.java
>  9b68b23d0fe2b6a6c5f96283d46e79b5a4a0602e 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/membership/gms/fd/GMSHealthMonitorJUnitTest.java
>  792a1fdabd4b3433cb16a93c89c30169eb227bc6 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeaveJUnitTest.java
>  14fedc61e3a9f55444e0df86add6fd54a4a153bc 
>   
> geode-core/src/test/java/org/apache/geode/internal/ScheduledThreadPoolExecutorWithKeepAliveJUnitTest.java
>  c354c98219083b62d5f4ab5547eda47c41c3d389 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/ClientServerTransactionDUnitTest.java
>  a37aebd9e03ff40502d6807f2029c4cd86fce4a9 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/DiskRegRecoveryJUnitTest.java
>  d6ee1ea89063bef174e2515ac341c7aa24d3cea0 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/EntryEventImplTest.java
>  07d7f4dd14c11559e507d4b5d8bdb68f075aacc3 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/FireAndForgetFunctionOnAllServersDUnitTest.java
>  d733ae0407edab6ee4ff60c9cba4ff64feb5144f 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/FixedPRSinglehopDUnitTest.java
>  8c6d8b2e6fdc84562168d4d44d6a59436b0891f7 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/GemFireCacheImplTest.java
>  5f550e2fc14a8b86bbb93c70079e5a1ee137a9af 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/MultipleOplogsRollingFeatureJUnitTest.java
>  85d19af7f0edd810b463795428408a47025839ee 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/OplogJUnitTest.java 
> 7df8982fd9c9ab57d78438469a84721c387b5379 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/PartitionedRegionSingleHopDUnitTest.java
>  43096d6ee36997fb70014e8ae4bdac5f591fab0a 
>   
> geode-core/src/test/ja

[GitHub] geode issue #326: Feature/geode 2103 : Adding --http-service-port and --http...

[jinmeiliao]

Github user jinmeiliao commented on the issue:

https://github.com/apache/geode/pull/326
  
the changes look good to me. Running all tests now. Will pull this in if no 
test failures.


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

Re: geode-old-versions subproject?

[Dan Smith]

Or maybe an incomplete implementation? Looking into the code for
VersionManager, I don't see it getting old versions of geode from any other
location. And it looks like the code just logs a warning if it can't find
the file and carries on!

The tests that use this are using a parameterized runner that returns the
list of other versions. But when I try to run those tests it doesn't seem
to find any tests to run. I also don't see this test getting run as part of
CI.

./gradlew geode-core:distributedTest --tests '*ClientServerMiscBCDUnitTest*'
> No tests found for given includes: [*ClientServerMiscBCDUnitTest*]

It looks to me like we're not actually running backwards compatibility
tests at all.

-Dan

On Mon, Feb 6, 2017 at 10:34 AM, Anthony Baker  wrote:

> It looks like it was an incomplete removal:
>
> geode-core/build.gradle:  testCompile project(':geode-old-versions')
> geode-core/src/test/java/org/apache/geode/test/dunit/
> standalone/VersionManager.java:File propFile = new
> File("../../../geode-old-versions/build/geodeOldVersionClasspaths.txt");
> geode-core/src/test/java/org/apache/geode/test/dunit/
> standalone/VersionManager.java:  propFile = new
> File("../geode-old-versions/build/geodeOldVersionClasspaths.txt");
> settings.gradle:include 'geode-old-versions'
>
> I noticed the geode-old-versions showed up in the src release as an empty
> dir, which is probably not a good thing.
>
> Anthony
>
> > On Feb 3, 2017, at 4:24 PM, Dan Smith  wrote:
> >
> > One thing Hitesh and I noticed is that when you do a build, it creates a
> > directory called geode-old-versions because there is a line in
> > settings.gradle for a geode-old-versions project.
> >
> > Is this leftover cruft, or is it actually supposed to be there? I see a
> > couple of references to geode-old-versions in the source as well.
> >
> > -Dan
>
>

[jira] [Created] (GEODE-2433) Backwards compatibility tests are not actually running

[Dan Smith (JIRA)]

Dan Smith created GEODE-2433:


 Summary: Backwards compatibility tests are not actually running
 Key: GEODE-2433
 URL: https://issues.apache.org/jira/browse/GEODE-2433
 Project: Geode
  Issue Type: Bug
  Components: tests
Reporter: Dan Smith
 Fix For: 1.1.0


We have several backwards compatibility tests checked in -
RollingUpgradeDUnitTest
RollingUpgrade2DUnitTest
ClientServerMiscBCDUnitTest

These tests are all parametered by the list of old versions to run against.

However, it looks like the code to get the list of old versions incorrectly 
just logs a message and continues on if it can't find a file called 
geodeOldVersionClasspaths.txt. That file does not exist and is not being 
generated as far is I can tell. The entire project - geode-old-versions, is 
completely empty.

The net effect is these tests don't actually run, because the list of 
parameters is an empty list.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2432) Don't create and upload empty maven artifacts for geode-benchmarks, geode-old-versions

[Dan Smith (JIRA)]

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

Dan Smith reassigned GEODE-2432:


Assignee: Dan Smith

> Don't create and upload empty maven artifacts for geode-benchmarks, 
> geode-old-versions
> --
>
> Key: GEODE-2432
> URL: https://issues.apache.org/jira/browse/GEODE-2432
> Project: Geode
>  Issue Type: Bug
>  Components: build
>Reporter: Dan Smith
>Assignee: Dan Smith
>
> The 1.1.0.RC1 maven site shows that we're creating and uploading empty maven 
> artifacts for these sub projects.
> geode-benchmarks - this project contains only jmh tests
> geode-old-versions - this project seems to be completely empty?
> We should probably disable uploading maven archives for these projects.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2433) Backwards compatibility tests are not actually running

[Dan Smith (JIRA)]

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

Dan Smith reassigned GEODE-2433:


Assignee: Bruce Schuchardt

> Backwards compatibility tests are not actually running
> --
>
> Key: GEODE-2433
> URL: https://issues.apache.org/jira/browse/GEODE-2433
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Dan Smith
>Assignee: Bruce Schuchardt
> Fix For: 1.1.0
>
>
> We have several backwards compatibility tests checked in -
> RollingUpgradeDUnitTest
> RollingUpgrade2DUnitTest
> ClientServerMiscBCDUnitTest
> These tests are all parametered by the list of old versions to run against.
> However, it looks like the code to get the list of old versions incorrectly 
> just logs a message and continues on if it can't find a file called 
> geodeOldVersionClasspaths.txt. That file does not exist and is not being 
> generated as far is I can tell. The entire project - geode-old-versions, is 
> completely empty.
> The net effect is these tests don't actually run, because the list of 
> parameters is an empty list.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode issue #387: GEODE-2411: Remove references to Gemfire from include guar...

[PivotalSarge]

Github user PivotalSarge commented on the issue:

https://github.com/apache/geode/pull/387
  
They've been googlified.


---
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-2411) Remove references to Gemfire from include guards

[ASF GitHub Bot (JIRA)]

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

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

Github user PivotalSarge commented on the issue:

https://github.com/apache/geode/pull/387
  
They've been googlified.


> Remove references to Gemfire from include guards
> 
>
> Key: GEODE-2411
> URL: https://issues.apache.org/jira/browse/GEODE-2411
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Dodge
>Assignee: Michael Dodge
>
> Many of the macro definitions used as include guards in the C++ header files 
> refer to Gemfire. These references should be replaced at least with 
> references to Geode but preferably using pragmas instead of defines.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: geode-old-versions subproject?

[Kirk Lund]

For me, the "--tests" option seems to only work with the "test" task (not
"integrationTest" or "distributedTest" which I've brought up before).

Are you sure the BC tests aren't run during the "precheckin" task despite
not running with the "--tests" option?


On Mon, Feb 6, 2017 at 11:12 AM, Dan Smith  wrote:

> Or maybe an incomplete implementation? Looking into the code for
> VersionManager, I don't see it getting old versions of geode from any other
> location. And it looks like the code just logs a warning if it can't find
> the file and carries on!
>
> The tests that use this are using a parameterized runner that returns the
> list of other versions. But when I try to run those tests it doesn't seem
> to find any tests to run. I also don't see this test getting run as part of
> CI.
>
> ./gradlew geode-core:distributedTest --tests '*ClientServerMiscBCDUnitTest*
> '
> > No tests found for given includes: [*ClientServerMiscBCDUnitTest*]
>
> It looks to me like we're not actually running backwards compatibility
> tests at all.
>
> -Dan
>
> On Mon, Feb 6, 2017 at 10:34 AM, Anthony Baker  wrote:
>
> > It looks like it was an incomplete removal:
> >
> > geode-core/build.gradle:  testCompile project(':geode-old-versions')
> > geode-core/src/test/java/org/apache/geode/test/dunit/
> > standalone/VersionManager.java:File propFile = new
> > File("../../../geode-old-versions/build/geodeOldVersionClasspaths.txt");
> > geode-core/src/test/java/org/apache/geode/test/dunit/
> > standalone/VersionManager.java:  propFile = new
> > File("../geode-old-versions/build/geodeOldVersionClasspaths.txt");
> > settings.gradle:include 'geode-old-versions'
> >
> > I noticed the geode-old-versions showed up in the src release as an empty
> > dir, which is probably not a good thing.
> >
> > Anthony
> >
> > > On Feb 3, 2017, at 4:24 PM, Dan Smith  wrote:
> > >
> > > One thing Hitesh and I noticed is that when you do a build, it creates
> a
> > > directory called geode-old-versions because there is a line in
> > > settings.gradle for a geode-old-versions project.
> > >
> > > Is this leftover cruft, or is it actually supposed to be there? I see a
> > > couple of references to geode-old-versions in the source as well.
> > >
> > > -Dan
> >
> >
>

[jira] [Commented] (GEODE-2433) Backwards compatibility tests are not actually running

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt commented on GEODE-2433:
-

Yes, I discovered this morning that the geode-old-versions/build.gradle file 
wasn't included in the commit for some reason.  That's weird because I added it 
to the index and it was included in my RB review.

> Backwards compatibility tests are not actually running
> --
>
> Key: GEODE-2433
> URL: https://issues.apache.org/jira/browse/GEODE-2433
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Dan Smith
>Assignee: Bruce Schuchardt
> Fix For: 1.1.0
>
>
> We have several backwards compatibility tests checked in -
> RollingUpgradeDUnitTest
> RollingUpgrade2DUnitTest
> ClientServerMiscBCDUnitTest
> These tests are all parametered by the list of old versions to run against.
> However, it looks like the code to get the list of old versions incorrectly 
> just logs a message and continues on if it can't find a file called 
> geodeOldVersionClasspaths.txt. That file does not exist and is not being 
> generated as far is I can tell. The entire project - geode-old-versions, is 
> completely empty.
> The net effect is these tests don't actually run, because the list of 
> parameters is an empty list.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [VOTE] RC1: Apache Geode release - v1.1.0

[Dan Smith]

-1 (binding)

I dug into the geode-old-versions project some more. It looks like we may
not be running the backwards compatibility tests. I filed this bug, which I
think we should fix before shipping:

GEODE-2433 - Backwards compatibility tests are not actually running

If we're spinning another RC, it would be nice to also fix this issue I
just noticed. I can pick up this one:

GEODE-2432 - Don't create and upload empty maven artifacts for
geode-benchmarks, geode-old-versions

I also think we should get the jars Anthony mentioned out of the source.
I'm still trying to dig up the emails, but we had to remove
gradle-wrapper.jar from the source distro because it violated policy. If we
can't include that, I doubt we can include these other jars either.

-Dan

On Mon, Feb 6, 2017 at 8:52 AM, Anthony Baker  wrote:

> Correct.  Let me know if you need help converting these files to gradle
> tasks.
>
> Anthony
>
>
> > On Feb 6, 2017, at 8:10 AM, Jinmei Liao  wrote:
> >
> > Oh, these are used by the tests, and the classes they contain are only
> test
> > classes as well. So we need to programmatically produce these jars and
> zips
> > during build time?
> >
> > On Mon, Feb 6, 2017 at 8:05 AM, Anthony Baker  wrote:
> >
> >> -1 (binding)
> >>
> >> `gradle rat` shows these binary files are included in the src
> distribution:
> >>
> >> + /Users/abaker/working/apache-geode-src-1.1.0/geode-core/
> >> src/test/resources/org/apache/geode/management/internal/
> >> configuration/cluster.jar
> >>
> >> + /Users/abaker/working/apache-geode-src-1.1.0/geode-core/
> >> src/test/resources/org/apache/geode/management/internal/
> >> configuration/cluster_config.zip
> >>
> >> + /Users/abaker/working/apache-geode-src-1.1.0/geode-core/
> >> src/test/resources/org/apache/geode/management/internal/
> >> configuration/cluster_config_security.zip
> >>
> >> + /Users/abaker/working/apache-geode-src-1.1.0/geode-core/
> >> src/test/resources/org/apache/geode/management/internal/
> >> configuration/group1.jar
> >>
> >> + /Users/abaker/working/apache-geode-src-1.1.0/geode-core/
> >> src/test/resources/org/apache/geode/management/internal/
> >> configuration/group2.jar
> >>
> >>
> >> If tests require binary files, those files should be generated from
> source
> >> during the build.
> >>
> >> Anthony
> >>
> >>> On Feb 3, 2017, at 4:11 PM, Hitesh Khamesra
> 
> >> wrote:
> >>>
> >>> All,
> >>>
> >>> This is the first release candidate of the first release for Apache
> >> Geode, version 1.1.0.
> >>> Thanks to all the community members.
> >>>
> >>> It fixes the following issues:
> >>>   https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> >> projectId=12318420&version=12338352
> >>>
> >>>
> >>> *** Please download, test and vote by Wednesday, February 08, 0800 hrs
> >> US Pacific.
> >>>
> >>> Note that we are voting upon the source (tag):
> >>>   rel/v1.1.0.RC1
> >>>   https://git-wip-us.apache.org/repos/asf?p=geode.git;a=tag;h=
> >> refs/tags/rel/v1.1.0.RC1
> >>>
> >>> Commit ID: 90760d334f912cef49ad32f275aed9cd9f1f2688
> >>>
> >>> Source and binary files:
> >>>   https://dist.apache.org/repos/dist/dev/geode/1.1.0.RC1/
> >>>
> >>> Maven staging repo:
> >>>   https://repository.apache.org/content/repositories/
> >> orgapachegeode-1015/
> >>>
> >>> Geode's KEYS file containing PGP keys we use to sign the release:
> >>>   https://github.com/apache/geode/blob/release/1.1.0/KEYS
> >>>
> >>> pub   4096R/AC6AB8ED 2017-01-18
> >>>  Key fingerprint = 048F B40F AD7D 9C15 54AD  D447 2CA9 90A2 AC6A
> >> B8ED
> >>>
> >>> Thanks,
> >>> Dan & Hitesh (on behalf of the Geode team)
> >>
> >>
> >
> >
> > --
> > Cheers
> >
> > Jinmei
>
>

[jira] [Commented] (GEODE-2433) Backwards compatibility tests are not actually running

[Dan Smith (JIRA)]

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

Dan Smith commented on GEODE-2433:
--

[~bschuchardt] - It looks like the build.gradle file for geode-old-versions was 
never checked in? I see it back in this old review request - 
https://reviews.apache.org/r/55688/diff/1#13.

We should also make sure the tests fail if we can't load the old versions.

> Backwards compatibility tests are not actually running
> --
>
> Key: GEODE-2433
> URL: https://issues.apache.org/jira/browse/GEODE-2433
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Dan Smith
>Assignee: Bruce Schuchardt
> Fix For: 1.1.0
>
>
> We have several backwards compatibility tests checked in -
> RollingUpgradeDUnitTest
> RollingUpgrade2DUnitTest
> ClientServerMiscBCDUnitTest
> These tests are all parametered by the list of old versions to run against.
> However, it looks like the code to get the list of old versions incorrectly 
> just logs a message and continues on if it can't find a file called 
> geodeOldVersionClasspaths.txt. That file does not exist and is not being 
> generated as far is I can tell. The entire project - geode-old-versions, is 
> completely empty.
> The net effect is these tests don't actually run, because the list of 
> parameters is an empty list.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: geode-old-versions subproject?

[Dan Smith]

> For me, the "--tests" option seems to only work with the "test" task (not
> "integrationTest" or "distributedTest" which I've brought up before).
>

It does work with the syntax I sent. For example if you take the BC out of
the name of the test and run the command from my last email, it will find
the normal version of that test and run it.

Are you sure the BC tests aren't run during the "precheckin" task despite
> not running with the "--tests" option?
>
> I don't see them in the nightly build either. There's no
ClientServerMiscDUnitTest in the test report -
https://builds.apache.org/job/Geode-nightly/738/testReport/org.apache.geode.internal.cache.tier.sockets/

I filed GEODE-2433 for this issue.

[jira] [Commented] (GEODE-2433) Backwards compatibility tests are not actually running

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2433:


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

GEODE-2433  Backwards compatibility tests are not actually running

The geode-old-versions/build.gradle file was not included in the original
commit for backward-compatibility testing.  It's needed to establish
the old-version source sets and generate the classpaths file used by
VersionManager.


> Backwards compatibility tests are not actually running
> --
>
> Key: GEODE-2433
> URL: https://issues.apache.org/jira/browse/GEODE-2433
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Dan Smith
>Assignee: Bruce Schuchardt
> Fix For: 1.1.0
>
>
> We have several backwards compatibility tests checked in -
> RollingUpgradeDUnitTest
> RollingUpgrade2DUnitTest
> ClientServerMiscBCDUnitTest
> These tests are all parametered by the list of old versions to run against.
> However, it looks like the code to get the list of old versions incorrectly 
> just logs a message and continues on if it can't find a file called 
> geodeOldVersionClasspaths.txt. That file does not exist and is not being 
> generated as far is I can tell. The entire project - geode-old-versions, is 
> completely empty.
> The net effect is these tests don't actually run, because the list of 
> parameters is an empty list.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2430) Remove binary files from test resources

[Anthony Baker (JIRA)]

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

Anthony Baker updated GEODE-2430:
-
Fix Version/s: 1.1.0

> Remove binary files from test resources
> ---
>
> Key: GEODE-2430
> URL: https://issues.apache.org/jira/browse/GEODE-2430
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.1.0
>
>
> We have some tests which rely on the following binary files:
> {code}
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster.jar
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config.zip
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config_security.zip
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/group1.jar
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/group2.jar
> {code}
> We need to convert our tests to generate these files dynamically instead so 
> that we don't have binary files checked into our repository.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2325) Improve tests for JarDeployer

[Jared Stewart (JIRA)]

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

Jared Stewart resolved GEODE-2325.
--
   Resolution: Fixed
Fix Version/s: 1.2.0

> Improve tests for JarDeployer
> -
>
> Key: GEODE-2325
> URL: https://issues.apache.org/jira/browse/GEODE-2325
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.2.0
>
>
> org.apache.geode.internal.JarDeployer only has a DUnit test right now.  Many 
> of those test methods are really just unit tests, and should be extracted to 
> run as such.  The tests can also be cleaned up a lot with AssertJ.  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2433) Backwards compatibility tests are not actually running

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2433:


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

GEODE-2433 Backwards compatibility tests are not actually running

Tests will now fail of there are no older versions of Geode to test
against.


> Backwards compatibility tests are not actually running
> --
>
> Key: GEODE-2433
> URL: https://issues.apache.org/jira/browse/GEODE-2433
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Dan Smith
>Assignee: Bruce Schuchardt
> Fix For: 1.1.0
>
>
> We have several backwards compatibility tests checked in -
> RollingUpgradeDUnitTest
> RollingUpgrade2DUnitTest
> ClientServerMiscBCDUnitTest
> These tests are all parametered by the list of old versions to run against.
> However, it looks like the code to get the list of old versions incorrectly 
> just logs a message and continues on if it can't find a file called 
> geodeOldVersionClasspaths.txt. That file does not exist and is not being 
> generated as far is I can tell. The entire project - geode-old-versions, is 
> completely empty.
> The net effect is these tests don't actually run, because the list of 
> parameters is an empty list.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2431) Upgrade use of Awaitility from 1.7.0 to 2.0.0

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2431:


Commit ca5c7088a9609a162d3e291963d461cd60343c98 in geode's branch 
refs/heads/awaitility from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=ca5c708 ]

GEODE-2431: Update to Awaitility 2.0


> Upgrade use of Awaitility from 1.7.0 to 2.0.0
> -
>
> Key: GEODE-2431
> URL: https://issues.apache.org/jira/browse/GEODE-2431
> Project: Geode
>  Issue Type: Test
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> Upgrade use of Awaitility from 1.7.0 to 2.0.0
> See: https://github.com/awaitility/awaitility



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2433) Backwards compatibility tests are not actually running

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2433:


Commit 3ce2a127c94515a8a57d8589d91e497fec7f2544 in geode's branch 
refs/heads/awaitility from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=3ce2a12 ]

GEODE-2433  Backwards compatibility tests are not actually running

The geode-old-versions/build.gradle file was not included in the original
commit for backward-compatibility testing.  It's needed to establish
the old-version source sets and generate the classpaths file used by
VersionManager.


> Backwards compatibility tests are not actually running
> --
>
> Key: GEODE-2433
> URL: https://issues.apache.org/jira/browse/GEODE-2433
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Dan Smith
>Assignee: Bruce Schuchardt
> Fix For: 1.1.0
>
>
> We have several backwards compatibility tests checked in -
> RollingUpgradeDUnitTest
> RollingUpgrade2DUnitTest
> ClientServerMiscBCDUnitTest
> These tests are all parametered by the list of old versions to run against.
> However, it looks like the code to get the list of old versions incorrectly 
> just logs a message and continues on if it can't find a file called 
> geodeOldVersionClasspaths.txt. That file does not exist and is not being 
> generated as far is I can tell. The entire project - geode-old-versions, is 
> completely empty.
> The net effect is these tests don't actually run, because the list of 
> parameters is an empty list.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: geode-old-versions subproject?

[Bruce Schuchardt]

Somehow when I committed the backward-compat testing code the 
geode-old-versions/build.gradle file didn't make it.  I had other new 
files in the commit and everything showed up on reviewboard okay.


Le 2/6/2017 à 10:34 AM, Anthony Baker a écrit :

It looks like it was an incomplete removal:

geode-core/build.gradle:  testCompile project(':geode-old-versions')
geode-core/src/test/java/org/apache/geode/test/dunit/standalone/VersionManager.java:
File propFile = new 
File("../../../geode-old-versions/build/geodeOldVersionClasspaths.txt");
geode-core/src/test/java/org/apache/geode/test/dunit/standalone/VersionManager.java:  
propFile = new 
File("../geode-old-versions/build/geodeOldVersionClasspaths.txt");
settings.gradle:include 'geode-old-versions'

I noticed the geode-old-versions showed up in the src release as an empty dir, 
which is probably not a good thing.

Anthony


On Feb 3, 2017, at 4:24 PM, Dan Smith  wrote:

One thing Hitesh and I noticed is that when you do a build, it creates a
directory called geode-old-versions because there is a line in
settings.gradle for a geode-old-versions project.

Is this leftover cruft, or is it actually supposed to be there? I see a
couple of references to geode-old-versions in the source as well.

-Dan

Regarding maximum connections/threads

[Goutam Tadi]

Hi,

I have a couple of questions regarding max-connections attribute in
cache.xml.

1. If max-connections is set to 800 by default, does that mean if I have
800+ region.put() methods from multiple clients in parallel, Will this
cause issue to some of the inserts or requests from server ?

2. If I would like to try multi threading (inserts/puts) by buffering rows
to some size of 1MB and use putAll() to insert batch of rows into a region
with max-connections set to 800 by default, will this cause issue to the
client, if the client launches 800+ threads of batch inserts ?


Thanks,
Goutam Tadi.
-- 
Regards,
*Goutam Tadi.*

[jira] [Commented] (GEODE-2431) Upgrade use of Awaitility from 1.7.0 to 2.0.0

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2431:


Commit bc6db4a6301607a352def097a96ddd72d13d42fd in geode's branch 
refs/heads/develop from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=bc6db4a ]

GEODE-2431: Update to Awaitility 2.0


> Upgrade use of Awaitility from 1.7.0 to 2.0.0
> -
>
> Key: GEODE-2431
> URL: https://issues.apache.org/jira/browse/GEODE-2431
> Project: Geode
>  Issue Type: Test
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> Upgrade use of Awaitility from 1.7.0 to 2.0.0
> See: https://github.com/awaitility/awaitility



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 56242: GEODE-2206: Add junit-quickcheck to geode-core; add a test that uses it.

[Udo Kohlmeyer]

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


Ship it!




Ship It!

- Udo Kohlmeyer


On Feb. 2, 2017, 9:35 p.m., Galen O'Sullivan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56242/
> ---
> 
> (Updated Feb. 2, 2017, 9:35 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt, Hitesh Khamesra, Kirk Lund, and 
> Udo Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This adds a test dependency on `junit-quickcheck` (and 
> `junit-quickcheck-generators` and `junit-quickcheck-guava`) to geode-core. 
> I've included an example test of one of the cases in which property-based 
> testing is particularly nice: when you have two operations that should 
> reverse each other and want to test them with as much garbage as possible.
> 
> Property-based testing means basically that you write a function that tests 
> some code and checks some conditions you expect to hold true for all inputs, 
> and then have a computer program test all sorts of weird inputs to try prove 
> you wrong.
> 
> Because the test data is randomly generated, you get to test against more 
> inputs than you might even think of, and because the seed is saved, the test 
> is reproducible. If `junit-quickcheck` finds one failure, it will even try to 
> narrow down to a smallest example of a test failure.
> 
> I'm about to send an email to the dev list soliciting feedback.
> 
> 
> Diffs
> -
> 
>   geode-core/build.gradle 3c2a2abf5 
>   
> geode-core/src/test/java/org/apache/geode/internal/InternalDataSerializerQuickcheckStringTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/internal/InternalDataSerializerRandomizedJUnitTest.java
>  f361de4a2 
>   gradle/dependency-versions.properties fbc76e012 
> 
> Diff: https://reviews.apache.org/r/56242/diff/
> 
> 
> Testing
> ---
> 
> The test passes on my machine. This is mostly just adding a dependency, so 
> there's not a lot here to test.
> 
> I've read some of the source of junit-quickcheck and looked into the data it 
> generates: integral numbers seem pretty reasonable. Strings tend to be 
> short-ish (length up to hundreds with hundreds of iterations, thousands with 
> thousands), but are made up of random codepoints, which is nice.
> 
> 
> Thanks,
> 
> Galen O'Sullivan
> 
>

[jira] [Commented] (GEODE-2414) Determine a mechanism to stream a zip file from server to locator

[Galen O'Sullivan (JIRA)]

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

Galen O'Sullivan commented on GEODE-2414:
-

Sorry, I typoed the JIRA number on that commit.

> Determine a mechanism to stream a zip file from server to locator
> -
>
> Key: GEODE-2414
> URL: https://issues.apache.org/jira/browse/GEODE-2414
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, gfsh
>Reporter: Jared Stewart
>
> Our export command will execute a function on servers (one at a time) to 
> build up a zip file of the artifacts for that server.  Then, the zip file 
> needs to be sent back to the locator, so that the locator can aggregate 
> together the files from all servers.  However, we need to make sure to 
> chunk/stream the data that we send from server to locator so that neither 
> member will run out of memory if the file is very large.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode pull request #392: [GEODE-2414] Ignore a consistently failing test.

[galen-pivotal]

GitHub user galen-pivotal opened a pull request:

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

[GEODE-2414] Ignore a consistently failing test.

This test only seems to be failing on Linux. I haven't figured out the
cause yet. Ignore it until I have time to fix it properly.

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

$ git pull https://github.com/galen-pivotal/incubator-geode 
feature/GEODE-2412

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

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


commit c8056cae6c599ff08a6e2c968f76a95ca0fac58b
Author: Galen O'Sullivan 
Date:   2017-02-06T20:28:56Z

[GEODE-2414] Ignore a consistently failing test.

This test only seems to be failing on Linux. I haven't figured out the
cause yet. Ignore it until I have time to fix it properly.




---
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-2414) Determine a mechanism to stream a zip file from server to locator

[ASF GitHub Bot (JIRA)]

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

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

GitHub user galen-pivotal opened a pull request:

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

[GEODE-2414] Ignore a consistently failing test.

This test only seems to be failing on Linux. I haven't figured out the
cause yet. Ignore it until I have time to fix it properly.

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

$ git pull https://github.com/galen-pivotal/incubator-geode 
feature/GEODE-2412

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

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


commit c8056cae6c599ff08a6e2c968f76a95ca0fac58b
Author: Galen O'Sullivan 
Date:   2017-02-06T20:28:56Z

[GEODE-2414] Ignore a consistently failing test.

This test only seems to be failing on Linux. I haven't figured out the
cause yet. Ignore it until I have time to fix it properly.




> Determine a mechanism to stream a zip file from server to locator
> -
>
> Key: GEODE-2414
> URL: https://issues.apache.org/jira/browse/GEODE-2414
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, gfsh
>Reporter: Jared Stewart
>
> Our export command will execute a function on servers (one at a time) to 
> build up a zip file of the artifacts for that server.  Then, the zip file 
> needs to be sent back to the locator, so that the locator can aggregate 
> together the files from all servers.  However, we need to make sure to 
> chunk/stream the data that we send from server to locator so that neither 
> member will run out of memory if the file is very large.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode issue #392: [GEODE-2414] Ignore a consistently failing test.

[galen-pivotal]

Github user galen-pivotal commented on the issue:

https://github.com/apache/geode/pull/392
  
@kirklund I'm not a committer; you're welcome to commit this.


---
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-2414) Determine a mechanism to stream a zip file from server to locator

[ASF GitHub Bot (JIRA)]

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

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

Github user galen-pivotal commented on the issue:

https://github.com/apache/geode/pull/392
  
@kirklund I'm not a committer; you're welcome to commit this.


> Determine a mechanism to stream a zip file from server to locator
> -
>
> Key: GEODE-2414
> URL: https://issues.apache.org/jira/browse/GEODE-2414
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, gfsh
>Reporter: Jared Stewart
>
> Our export command will execute a function on servers (one at a time) to 
> build up a zip file of the artifacts for that server.  Then, the zip file 
> needs to be sent back to the locator, so that the locator can aggregate 
> together the files from all servers.  However, we need to make sure to 
> chunk/stream the data that we send from server to locator so that neither 
> member will run out of memory if the file is very large.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Broken: apache/geode#1977 (develop - 3ce2a12)

[Travis CI]

Build Update for apache/geode
-

Build: #1977
Status: Broken

Duration: 11 minutes and 7 seconds
Commit: 3ce2a12 (develop)
Author: Bruce Schuchardt
Message: GEODE-2433  Backwards compatibility tests are not actually running

The geode-old-versions/build.gradle file was not included in the original
commit for backward-compatibility testing.  It's needed to establish
the old-version source sets and generate the classpaths file used by
VersionManager.

View the changeset: 
https://github.com/apache/geode/compare/086df14b0dce...3ce2a127c945

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

--

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

Re: Volunteer For Creating February Board Report

[Mark Bretl]

Thanks Dave!

--Mark

On Thu, Feb 2, 2017 at 2:11 PM, Dave Barnes  wrote:

> I'll volunteer for February.
>
> On Thu, Feb 2, 2017 at 10:50 AM, Mark Bretl  wrote:
>
> > Hi,
> >
> > Its that time again for us to create a board report for the February, the
> > 15th, board meeting, are there any volunteers for creating a draft?
> >
> > Initial report should be submitted next wednesday, February 8th. We can
> > edit the report until Friday the 10th, which then it is customary for
> board
> > members to start reviewing reports.
> >
> > Template report can be found at:
> > https://cwiki.apache.org/confluence/display/GEODE/ASF+
> > Board+Report+Template
> >
> > Best Regards,
> >
> > --Mark
> >
>

[GitHub] geode issue #392: [GEODE-2414] Ignore a consistently failing test.

[kirklund]

Github user kirklund commented on the issue:

https://github.com/apache/geode/pull/392
  
I'll merge it in.


---
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-2414) Determine a mechanism to stream a zip file from server to locator

[ASF GitHub Bot (JIRA)]

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

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

Github user kirklund commented on the issue:

https://github.com/apache/geode/pull/392
  
I'll merge it in.


> Determine a mechanism to stream a zip file from server to locator
> -
>
> Key: GEODE-2414
> URL: https://issues.apache.org/jira/browse/GEODE-2414
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, gfsh
>Reporter: Jared Stewart
>
> Our export command will execute a function on servers (one at a time) to 
> build up a zip file of the artifacts for that server.  Then, the zip file 
> needs to be sent back to the locator, so that the locator can aggregate 
> together the files from all servers.  However, we need to make sure to 
> chunk/stream the data that we send from server to locator so that neither 
> member will run out of memory if the file is very large.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode pull request #392: [GEODE-2414] Ignore a consistently failing test.

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-2414) Determine a mechanism to stream a zip file from server to locator

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> Determine a mechanism to stream a zip file from server to locator
> -
>
> Key: GEODE-2414
> URL: https://issues.apache.org/jira/browse/GEODE-2414
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, gfsh
>Reporter: Jared Stewart
>
> Our export command will execute a function on servers (one at a time) to 
> build up a zip file of the artifacts for that server.  Then, the zip file 
> needs to be sent back to the locator, so that the locator can aggregate 
> together the files from all servers.  However, we need to make sure to 
> chunk/stream the data that we send from server to locator so that neither 
> member will run out of memory if the file is very large.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2412) Builds are failing in pipeline due to SSL locator tests failing.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2412:


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

[GEODE-2412] Ignore a consistently failing test.

This test only seems to be failing on Linux. I haven't figured out the
cause yet. Ignore it until I have time to fix it properly.

This closes #392


> Builds are failing in pipeline due to SSL locator tests failing.
> 
>
> Key: GEODE-2412
> URL: https://issues.apache.org/jira/browse/GEODE-2412
> Project: Geode
>  Issue Type: Bug
>  Components: locator, tests
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
>
> https://builds.apache.org/job/Geode-nightly/734/testReport/junit/org.apache.geode.distributed/LocatorUDPSecurityDUnitTest/testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator/
> We're getting failures in both 
> {LocatorUDPSecurityDUnitTest.testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator}
>  and {LocatorDUnitTest.testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator}
> This looks related to [GEODE-1793].



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2433) Backwards compatibility tests are not actually running

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt resolved GEODE-2433.
-
Resolution: Fixed

> Backwards compatibility tests are not actually running
> --
>
> Key: GEODE-2433
> URL: https://issues.apache.org/jira/browse/GEODE-2433
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Dan Smith
>Assignee: Bruce Schuchardt
> Fix For: 1.1.0
>
>
> We have several backwards compatibility tests checked in -
> RollingUpgradeDUnitTest
> RollingUpgrade2DUnitTest
> ClientServerMiscBCDUnitTest
> These tests are all parametered by the list of old versions to run against.
> However, it looks like the code to get the list of old versions incorrectly 
> just logs a message and continues on if it can't find a file called 
> geodeOldVersionClasspaths.txt. That file does not exist and is not being 
> generated as far is I can tell. The entire project - geode-old-versions, is 
> completely empty.
> The net effect is these tests don't actually run, because the list of 
> parameters is an empty list.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2433) Backwards compatibility tests are not actually running

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2433:


Commit 5e6f67346c75a92084bbb1e46f7f0c016353eb97 in geode's branch 
refs/heads/release/1.1.0 from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=5e6f673 ]

GEODE-2433 Backwards compatibility tests are not actually running

Tests will now fail of there are no older versions of Geode to test
against.


> Backwards compatibility tests are not actually running
> --
>
> Key: GEODE-2433
> URL: https://issues.apache.org/jira/browse/GEODE-2433
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Dan Smith
>Assignee: Bruce Schuchardt
> Fix For: 1.1.0
>
>
> We have several backwards compatibility tests checked in -
> RollingUpgradeDUnitTest
> RollingUpgrade2DUnitTest
> ClientServerMiscBCDUnitTest
> These tests are all parametered by the list of old versions to run against.
> However, it looks like the code to get the list of old versions incorrectly 
> just logs a message and continues on if it can't find a file called 
> geodeOldVersionClasspaths.txt. That file does not exist and is not being 
> generated as far is I can tell. The entire project - geode-old-versions, is 
> completely empty.
> The net effect is these tests don't actually run, because the list of 
> parameters is an empty list.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2433) Backwards compatibility tests are not actually running

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2433:


Commit 5554dd24a3932900b28956cac357f0e4bbe9d6e0 in geode's branch 
refs/heads/release/1.1.0 from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=5554dd2 ]

GEODE-2433  Backwards compatibility tests are not actually running

The geode-old-versions/build.gradle file was not included in the original
commit for backward-compatibility testing.  It's needed to establish
the old-version source sets and generate the classpaths file used by
VersionManager.


> Backwards compatibility tests are not actually running
> --
>
> Key: GEODE-2433
> URL: https://issues.apache.org/jira/browse/GEODE-2433
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Dan Smith
>Assignee: Bruce Schuchardt
> Fix For: 1.1.0
>
>
> We have several backwards compatibility tests checked in -
> RollingUpgradeDUnitTest
> RollingUpgrade2DUnitTest
> ClientServerMiscBCDUnitTest
> These tests are all parametered by the list of old versions to run against.
> However, it looks like the code to get the list of old versions incorrectly 
> just logs a message and continues on if it can't find a file called 
> geodeOldVersionClasspaths.txt. That file does not exist and is not being 
> generated as far is I can tell. The entire project - geode-old-versions, is 
> completely empty.
> The net effect is these tests don't actually run, because the list of 
> parameters is an empty list.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (GEODE-2433) Backwards compatibility tests are not actually running

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt closed GEODE-2433.
---

> Backwards compatibility tests are not actually running
> --
>
> Key: GEODE-2433
> URL: https://issues.apache.org/jira/browse/GEODE-2433
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Dan Smith
>Assignee: Bruce Schuchardt
> Fix For: 1.1.0
>
>
> We have several backwards compatibility tests checked in -
> RollingUpgradeDUnitTest
> RollingUpgrade2DUnitTest
> ClientServerMiscBCDUnitTest
> These tests are all parametered by the list of old versions to run against.
> However, it looks like the code to get the list of old versions incorrectly 
> just logs a message and continues on if it can't find a file called 
> geodeOldVersionClasspaths.txt. That file does not exist and is not being 
> generated as far is I can tell. The entire project - geode-old-versions, is 
> completely empty.
> The net effect is these tests don't actually run, because the list of 
> parameters is an empty list.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-1965) Create backward-compatibility unit test framework

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt commented on GEODE-1965:
-

One file wasn't checked in with the infrastructure - 
geode-old-versions/build.gradle.  See GEODE-2433

> Create backward-compatibility unit test framework
> -
>
> Key: GEODE-1965
> URL: https://issues.apache.org/jira/browse/GEODE-1965
> Project: Geode
>  Issue Type: Test
>  Components: tests
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
> Fix For: 1.1.0
>
>
> We need a framework for integration testing clients/WAN from old versions 
> with new versions to ensure that we haven't broken anything.
> The framework should fit in with our existing unit test framework, if 
> possible.  For example, it should be possible to create a cluster of 
> current-version servers and then have another JVM running an older version 
> interact with those servers.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode issue #389: GEODE-1434: Add ASF headers

[kirklund]

Github user kirklund commented on the issue:

https://github.com/apache/geode/pull/389
  
Travis failed due to rake (I'm not sure what that even is).

rake aborted!
No Rakefile found (looking for: rakefile, Rakefile, rakefile.rb, 
Rakefile.rb)



---
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-1434) Update native client source headers

[ASF GitHub Bot (JIRA)]

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

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

Github user kirklund commented on the issue:

https://github.com/apache/geode/pull/389
  
Travis failed due to rake (I'm not sure what that even is).

rake aborted!
No Rakefile found (looking for: rakefile, Rakefile, rakefile.rb, 
Rakefile.rb)



> Update native client source headers
> ---
>
> Key: GEODE-1434
> URL: https://issues.apache.org/jira/browse/GEODE-1434
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Anthony Baker
>Assignee: Anthony Baker
> Attachments: rat.out.gz
>
>
> The existing native client source code headers contain { pivotal | vmware | 
> gemstone } copyrights and should be replaced with ASF headers.  See 
> https://cwiki.apache.org/confluence/display/GEODE/License+Guide+for+Contributors.
> Files without a source header probably need the ASF header added.  Only in 
> exceptional circumstances should a file not have a source header.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Review Request 56346: GEODE-2432: Disable maven artifacts for geode-benchmarks

[Dan Smith]

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

Review request for geode, Anthony Baker and Hitesh Khamesra.


Repository: geode


Description
---

GEODE-2432: Disable maven artifacts for geode-benchmarks


Diffs
-

  geode-benchmarks/build.gradle b6f09bcff645aaee7bcc1de8acaf3025d239b978 

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


Testing
---


Thanks,

Dan Smith

[GitHub] geode issue #389: GEODE-1434: Add ASF headers

[metatype]

Github user metatype commented on the issue:

https://github.com/apache/geode/pull/389
  
`rake` is a ruby thing.  We need a .travis.yml file to build and run unit 
tests.


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

Re: Review Request 56346: GEODE-2432: Disable maven artifacts for geode-benchmarks

[Anthony Baker]

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


Ship it!




LGTM.  Do you want to do this for geode-old-versions also?

- Anthony Baker


On Feb. 6, 2017, 9:53 p.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56346/
> ---
> 
> (Updated Feb. 6, 2017, 9:53 p.m.)
> 
> 
> Review request for geode, Anthony Baker and Hitesh Khamesra.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2432: Disable maven artifacts for geode-benchmarks
> 
> 
> Diffs
> -
> 
>   geode-benchmarks/build.gradle b6f09bcff645aaee7bcc1de8acaf3025d239b978 
> 
> Diff: https://reviews.apache.org/r/56346/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

[jira] [Commented] (GEODE-1434) Update native client source headers

[ASF GitHub Bot (JIRA)]

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

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

Github user metatype commented on the issue:

https://github.com/apache/geode/pull/389
  
`rake` is a ruby thing.  We need a .travis.yml file to build and run unit 
tests.


> Update native client source headers
> ---
>
> Key: GEODE-1434
> URL: https://issues.apache.org/jira/browse/GEODE-1434
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Anthony Baker
>Assignee: Anthony Baker
> Attachments: rat.out.gz
>
>
> The existing native client source code headers contain { pivotal | vmware | 
> gemstone } copyrights and should be replaced with ASF headers.  See 
> https://cwiki.apache.org/confluence/display/GEODE/License+Guide+for+Contributors.
> Files without a source header probably need the ASF header added.  Only in 
> exceptional circumstances should a file not have a source header.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2432) Don't create and upload empty maven artifacts for geode-benchmarks, geode-old-versions

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2432:


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

GEODE-2432: Disable maven artifacts for geode-benchmarks


> Don't create and upload empty maven artifacts for geode-benchmarks, 
> geode-old-versions
> --
>
> Key: GEODE-2432
> URL: https://issues.apache.org/jira/browse/GEODE-2432
> Project: Geode
>  Issue Type: Bug
>  Components: build
>Reporter: Dan Smith
>Assignee: Dan Smith
>
> The 1.1.0.RC1 maven site shows that we're creating and uploading empty maven 
> artifacts for these sub projects.
> geode-benchmarks - this project contains only jmh tests
> geode-old-versions - this project seems to be completely empty?
> We should probably disable uploading maven archives for these projects.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Regarding maximum connections/threads

[Barry Oglesby]

The max-connections property configures the maximum number of client
connections that can be created on a server.

If a set of clients is attempting to create >800 connections to the same
server either during an operation or while prefilling its pool of
connections, a warning like this is logged on the server:

[warning 2017/02/06 13:12:34.846 PST server-1  tid=0x3c] Rejected connection from /x
because current connection count of 800 is greater than or equal to the
configured max of 800

And a warning like this is logged on the client:

[warning 2017/02/06 13:29:35.048 PST client-feeder  tid=0x1e]
Could not create a new connection to server:
x(server-1:8657):21156 refused connection: exceeded
max-connections 800

And an exception like one of these is thrown on that client:

During an operation:

com.gemstone.gemfire.cache.client.NoAvailableServersException:
com.gemstone.gemfire.cache.client.ServerRefusedConnectionException:
x(server-1:8657):21156 refused connection: exceeded
max-connections 800
  ...
at
com.gemstone.gemfire.internal.cache.LocalRegion.put(LocalRegion.java:1580)
at
com.gemstone.gemfire.internal.cache.AbstractRegion.put(AbstractRegion.java:327)
at TestClient$1.run(TestClient.java:74)
at java.lang.Thread.run(Thread.java:745)
Caused by:
com.gemstone.gemfire.cache.client.ServerRefusedConnectionException:
x(server-1:8657):21156 refused connection: exceeded
max-connections 800
at
com.gemstone.gemfire.internal.cache.tier.sockets.HandShake.readMessage(HandShake.java:1466)
at
com.gemstone.gemfire.internal.cache.tier.sockets.HandShake.greet(HandShake.java:1317)
at
com.gemstone.gemfire.cache.client.internal.ConnectionImpl.connect(ConnectionImpl.java:112)
at
com.gemstone.gemfire.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:134)
at
com.gemstone.gemfire.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:252)
at
com.gemstone.gemfire.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:214)

During prefill:

[info 2017/02/06 13:48:46.772 PST client-feeder 
tid=0x16] Error prefilling connections :
com.gemstone.gemfire.cache.client.ServerRefusedConnectionException:
x(server-1:8796):9152 refused connection: exceeded max-connections
800
com.gemstone.gemfire.cache.client.ServerRefusedConnectionException:
x(server-1:8796):9152 refused connection: exceeded max-connections
16
at
com.gemstone.gemfire.internal.cache.tier.sockets.HandShake.readMessage(HandShake.java:1466)
at
com.gemstone.gemfire.internal.cache.tier.sockets.HandShake.greet(HandShake.java:1317)
at
com.gemstone.gemfire.cache.client.internal.ConnectionImpl.connect(ConnectionImpl.java:112)
at
com.gemstone.gemfire.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:134)
at
com.gemstone.gemfire.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:252)
at
com.gemstone.gemfire.cache.client.internal.pooling.ConnectionManagerImpl.prefillConnection(ConnectionManagerImpl.java:794)
at
com.gemstone.gemfire.cache.client.internal.pooling.ConnectionManagerImpl.prefill(ConnectionManagerImpl.java:737)
at
com.gemstone.gemfire.cache.client.internal.pooling.ConnectionManagerImpl$PrefillConnectionsTask.run2(ConnectionManagerImpl.java:888)

Either way, the server won't allow additional connections to it, and the
client operation will fail.

There are a few things you can do:

- increase max-connections to accomodate all the client connections
- handle the NoAvailableServersException by retrying. The hope is that the
retry will find an available connection rather than having to create a new
one
- limit the number of client connections with the max-connections pool
attribute. If max-connections is set and all client connections are in use,
a thread will wait for an available connection (for up to 1 ms by
default controlled by the free-connection-timeout pool attribute) before
throwing an exception.

Also, just because there are 800 threads doing operations doesn't
necessarily mean there are 800 connections. Each client has a pool of
connections that its threads can use. In the extreme case, if there are 800
threads on a single client, its pretty unlikely that there will be 800
connections. Instead, its likely that a thread will find an available
existing connection rather than having to create a new one.


Thanks,
Barry Oglesby


On Mon, Feb 6, 2017 at 12:20 PM, Goutam Tadi  wrote:

> Hi,
>
> I have a couple of questions regarding max-connections attribute in
> cache.xml.
>
> 1. If max-connections is set to 800 by default, does that mean if I have
> 800+ region.put() methods from multiple clients in parallel, Will this
> cause issue to some of the inserts or requests from server ?
>
> 2. If I would like to try multi threading (inserts/puts) by buffering rows
> to some size of 1MB and use putAll() to inser

[GitHub] geode issue #391: GEODE-2422: Switch remaining GemFire strings to Geode.

[mmartell]

Github user mmartell commented on the issue:

https://github.com/apache/geode/pull/391
  
Good catch that must not be used. So we should remove it. Please create a 
new ticket for that.


---
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-2422) Finish converting from GemFire to Geode in cppcache src

[ASF GitHub Bot (JIRA)]

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

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

Github user mmartell commented on the issue:

https://github.com/apache/geode/pull/391
  
Good catch that must not be used. So we should remove it. Please create a 
new ticket for that.


> Finish converting from GemFire to Geode in cppcache src
> ---
>
> Key: GEODE-2422
> URL: https://issues.apache.org/jira/browse/GEODE-2422
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Michael Martell
>
> There are still some classes in the cppcache src that were not converted to 
> Geode from GemFire. For example, GemFireException.
> Also, change corresponding clicache source that uses these.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #464 was successful.
---
Scheduled
1674 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

[GitHub] geode issue #393: GEODE-2430: Remove jar and zip files from test resources

[jaredjstewart]

Github user jaredjstewart commented on the issue:

https://github.com/apache/geode/pull/393
  
Precheckin started


---
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-2430) Remove binary files from test resources

[ASF GitHub Bot (JIRA)]

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

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

Github user jaredjstewart commented on the issue:

https://github.com/apache/geode/pull/393
  
Precheckin started


> Remove binary files from test resources
> ---
>
> Key: GEODE-2430
> URL: https://issues.apache.org/jira/browse/GEODE-2430
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.1.0
>
>
> We have some tests which rely on the following binary files:
> {code}
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster.jar
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config.zip
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config_security.zip
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/group1.jar
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/group2.jar
> {code}
> We need to convert our tests to generate these files dynamically instead so 
> that we don't have binary files checked into our repository.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Regarding maximum connections/threads

[Goutam Tadi]

Thank you for the info.

On Mon, Feb 6, 2017 at 2:05 PM Barry Oglesby  wrote:

> The max-connections property configures the maximum number of client
> connections that can be created on a server.
>
> If a set of clients is attempting to create >800 connections to the same
> server either during an operation or while prefilling its pool of
> connections, a warning like this is logged on the server:
>
> [warning 2017/02/06 13:12:34.846 PST server-1  0.0.0.0/0.0.0.0:50780 Thread 0> tid=0x3c] Rejected connection from /x
> because current connection count of 800 is greater than or equal to the
> configured max of 800
>
> And a warning like this is logged on the client:
>
> [warning 2017/02/06 13:29:35.048 PST client-feeder  tid=0x1e]
> Could not create a new connection to server:
> x(server-1:8657):21156 refused connection: exceeded
> max-connections 800
>
> And an exception like one of these is thrown on that client:
>
> During an operation:
>
> com.gemstone.gemfire.cache.client.NoAvailableServersException:
> com.gemstone.gemfire.cache.client.ServerRefusedConnectionException:
> x(server-1:8657):21156 refused connection: exceeded
> max-connections 800
>   ...
> at
> com.gemstone.gemfire.internal.cache.LocalRegion.put(LocalRegion.java:1580)
> at
>
> com.gemstone.gemfire.internal.cache.AbstractRegion.put(AbstractRegion.java:327)
> at TestClient$1.run(TestClient.java:74)
> at java.lang.Thread.run(Thread.java:745)
> Caused by:
> com.gemstone.gemfire.cache.client.ServerRefusedConnectionException:
> x(server-1:8657):21156 refused connection: exceeded
> max-connections 800
> at
>
> com.gemstone.gemfire.internal.cache.tier.sockets.HandShake.readMessage(HandShake.java:1466)
> at
>
> com.gemstone.gemfire.internal.cache.tier.sockets.HandShake.greet(HandShake.java:1317)
> at
>
> com.gemstone.gemfire.cache.client.internal.ConnectionImpl.connect(ConnectionImpl.java:112)
> at
>
> com.gemstone.gemfire.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:134)
> at
>
> com.gemstone.gemfire.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:252)
> at
>
> com.gemstone.gemfire.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:214)
>
> During prefill:
>
> [info 2017/02/06 13:48:46.772 PST client-feeder 
> tid=0x16] Error prefilling connections :
> com.gemstone.gemfire.cache.client.ServerRefusedConnectionException:
> x(server-1:8796):9152 refused connection: exceeded max-connections
> 800
> com.gemstone.gemfire.cache.client.ServerRefusedConnectionException:
> x(server-1:8796):9152 refused connection: exceeded max-connections
> 16
> at
>
> com.gemstone.gemfire.internal.cache.tier.sockets.HandShake.readMessage(HandShake.java:1466)
> at
>
> com.gemstone.gemfire.internal.cache.tier.sockets.HandShake.greet(HandShake.java:1317)
> at
>
> com.gemstone.gemfire.cache.client.internal.ConnectionImpl.connect(ConnectionImpl.java:112)
> at
>
> com.gemstone.gemfire.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:134)
> at
>
> com.gemstone.gemfire.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:252)
> at
>
> com.gemstone.gemfire.cache.client.internal.pooling.ConnectionManagerImpl.prefillConnection(ConnectionManagerImpl.java:794)
> at
>
> com.gemstone.gemfire.cache.client.internal.pooling.ConnectionManagerImpl.prefill(ConnectionManagerImpl.java:737)
> at
>
> com.gemstone.gemfire.cache.client.internal.pooling.ConnectionManagerImpl$PrefillConnectionsTask.run2(ConnectionManagerImpl.java:888)
>
> Either way, the server won't allow additional connections to it, and the
> client operation will fail.
>
> There are a few things you can do:
>
> - increase max-connections to accomodate all the client connections
> - handle the NoAvailableServersException by retrying. The hope is that the
> retry will find an available connection rather than having to create a new
> one
> - limit the number of client connections with the max-connections pool
> attribute. If max-connections is set and all client connections are in use,
> a thread will wait for an available connection (for up to 1 ms by
> default controlled by the free-connection-timeout pool attribute) before
> throwing an exception.
>
> Also, just because there are 800 threads doing operations doesn't
> necessarily mean there are 800 connections. Each client has a pool of
> connections that its threads can use. In the extreme case, if there are 800
> threads on a single client, its pretty unlikely that there will be 800
> connections. Instead, its likely that a thread will find an available
> existing connection rather than having to create a new one.
>
>
> Thanks,
> Barry Oglesby
>
>
> On Mon, Feb 6, 2017 at 12:20 PM, Goutam Tadi  wrote:
>
> > Hi,
> >
> > I have a couple of questions regarding max-connections attribute in
> > cache.x

[jira] [Created] (GEODE-2434) geodeOldVersionClasspaths.txt is generated every time build is parsed

[Dan Smith (JIRA)]

Dan Smith created GEODE-2434:


 Summary: geodeOldVersionClasspaths.txt is generated every time 
build is parsed
 Key: GEODE-2434
 URL: https://issues.apache.org/jira/browse/GEODE-2434
 Project: Geode
  Issue Type: Bug
  Components: build
Reporter: Dan Smith


geode-old-versions/build.gradle regenerates geodeOldVersionClasspaths.txt 
during the configuration phase of the task createGeodeClasspathsFile. This is a 
performance issue with the build because every time someone types ./gradlew it 
will regenerate this file while configuring the build.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode pull request #383: GEODE-2206: Add junit-quickcheck to geode-core.

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-2206) Add junit-quickcheck to Gradle test dependencies.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2206:


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

GEODE-2206: Add junit-quickcheck to geode-core.

* Rewrite a data serialization test to use junit-quickcheck.
* Move junit-quickcheck version to gradle/dependency-versions.properties

This closes #383


> Add junit-quickcheck to Gradle test dependencies.
> -
>
> Key: GEODE-2206
> URL: https://issues.apache.org/jira/browse/GEODE-2206
> Project: Geode
>  Issue Type: Improvement
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
>
> Unit tests allow us to test cases we know about and have thought of. 
> Property-based testing allows us to test those, and some cases we haven't 
> thought of -- you're essentially fuzzing a limited subset of the code. 
> {{junit-quickcheck}} makes it easy to write "property-based" tests with 
> generators for the builtin types. You can also constrain input or build 
> custom generators for constrained data.
> I think this would be especially helpful for testing areas like PDX 
> serialization, which should be able to accept any serializable object a user 
> creates.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2206) Add junit-quickcheck to Gradle test dependencies.

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> Add junit-quickcheck to Gradle test dependencies.
> -
>
> Key: GEODE-2206
> URL: https://issues.apache.org/jira/browse/GEODE-2206
> Project: Geode
>  Issue Type: Improvement
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
>
> Unit tests allow us to test cases we know about and have thought of. 
> Property-based testing allows us to test those, and some cases we haven't 
> thought of -- you're essentially fuzzing a limited subset of the code. 
> {{junit-quickcheck}} makes it easy to write "property-based" tests with 
> generators for the builtin types. You can also constrain input or build 
> custom generators for constrained data.
> I think this would be especially helpful for testing areas like PDX 
> serialization, which should be able to accept any serializable object a user 
> creates.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2430) Remove binary files from test resources

[ASF GitHub Bot (JIRA)]

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

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

GitHub user jaredjstewart opened a pull request:

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

GEODE-2430: Remove jar and zip files from test resources



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

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

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

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


commit 9070ea43b93311d3c14d856663d7db3363d57264
Author: Jared Stewart 
Date:   2017-02-03T20:53:38Z

GEODE-2430: Refactor ZipUtils

commit 7ba28e3052b72d5b000e52dc350dedd4d6e36a44
Author: Jared Stewart 
Date:   2017-02-06T22:54:49Z

GEODE-2430: Remove jar and zip files from test resources




> Remove binary files from test resources
> ---
>
> Key: GEODE-2430
> URL: https://issues.apache.org/jira/browse/GEODE-2430
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.1.0
>
>
> We have some tests which rely on the following binary files:
> {code}
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster.jar
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config.zip
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config_security.zip
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/group1.jar
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/group2.jar
> {code}
> We need to convert our tests to generate these files dynamically instead so 
> that we don't have binary files checked into our repository.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [VOTE] RC1: Apache Geode release - v1.1.0

[Kenneth Howe]

Dan,

Wasn’t it back on the first Geode release (1.0.0-incubating.M1) when we 
replaced the original grade-wrapper.jar.
There’s some discussion on GEODE-826, but I didn’t see any l specific links to 
discussion on why the .jar couldn’t be included.

Ken

> On Feb 6, 2017, at 11:29 AM, Dan Smith  wrote:
> 
> -1 (binding)
> 
> I dug into the geode-old-versions project some more. It looks like we may
> not be running the backwards compatibility tests. I filed this bug, which I
> think we should fix before shipping:
> 
> GEODE-2433 - Backwards compatibility tests are not actually running
> 
> If we're spinning another RC, it would be nice to also fix this issue I
> just noticed. I can pick up this one:
> 
> GEODE-2432 - Don't create and upload empty maven artifacts for
> geode-benchmarks, geode-old-versions
> 
> I also think we should get the jars Anthony mentioned out of the source.
> I'm still trying to dig up the emails, but we had to remove
> gradle-wrapper.jar from the source distro because it violated policy. If we
> can't include that, I doubt we can include these other jars either.
> 
> -Dan
> 
> On Mon, Feb 6, 2017 at 8:52 AM, Anthony Baker  wrote:
> 
>> Correct.  Let me know if you need help converting these files to gradle
>> tasks.
>> 
>> Anthony
>> 
>> 
>>> On Feb 6, 2017, at 8:10 AM, Jinmei Liao  wrote:
>>> 
>>> Oh, these are used by the tests, and the classes they contain are only
>> test
>>> classes as well. So we need to programmatically produce these jars and
>> zips
>>> during build time?
>>> 
>>> On Mon, Feb 6, 2017 at 8:05 AM, Anthony Baker  wrote:
>>> 
 -1 (binding)
 
 `gradle rat` shows these binary files are included in the src
>> distribution:
 
 + /Users/abaker/working/apache-geode-src-1.1.0/geode-core/
 src/test/resources/org/apache/geode/management/internal/
 configuration/cluster.jar
 
 + /Users/abaker/working/apache-geode-src-1.1.0/geode-core/
 src/test/resources/org/apache/geode/management/internal/
 configuration/cluster_config.zip
 
 + /Users/abaker/working/apache-geode-src-1.1.0/geode-core/
 src/test/resources/org/apache/geode/management/internal/
 configuration/cluster_config_security.zip
 
 + /Users/abaker/working/apache-geode-src-1.1.0/geode-core/
 src/test/resources/org/apache/geode/management/internal/
 configuration/group1.jar
 
 + /Users/abaker/working/apache-geode-src-1.1.0/geode-core/
 src/test/resources/org/apache/geode/management/internal/
 configuration/group2.jar
 
 
 If tests require binary files, those files should be generated from
>> source
 during the build.
 
 Anthony
 
> On Feb 3, 2017, at 4:11 PM, Hitesh Khamesra
>> 
 wrote:
> 
> All,
> 
> This is the first release candidate of the first release for Apache
 Geode, version 1.1.0.
> Thanks to all the community members.
> 
> It fixes the following issues:
>  https://issues.apache.org/jira/secure/ReleaseNote.jspa?
 projectId=12318420&version=12338352
> 
> 
> *** Please download, test and vote by Wednesday, February 08, 0800 hrs
 US Pacific.
> 
> Note that we are voting upon the source (tag):
>  rel/v1.1.0.RC1
>  https://git-wip-us.apache.org/repos/asf?p=geode.git;a=tag;h=
 refs/tags/rel/v1.1.0.RC1
> 
> Commit ID: 90760d334f912cef49ad32f275aed9cd9f1f2688
> 
> Source and binary files:
>  https://dist.apache.org/repos/dist/dev/geode/1.1.0.RC1/
> 
> Maven staging repo:
>  https://repository.apache.org/content/repositories/
 orgapachegeode-1015/
> 
> Geode's KEYS file containing PGP keys we use to sign the release:
>  https://github.com/apache/geode/blob/release/1.1.0/KEYS
> 
> pub   4096R/AC6AB8ED 2017-01-18
> Key fingerprint = 048F B40F AD7D 9C15 54AD  D447 2CA9 90A2 AC6A
 B8ED
> 
> Thanks,
> Dan & Hitesh (on behalf of the Geode team)
 
 
>>> 
>>> 
>>> --
>>> Cheers
>>> 
>>> Jinmei
>> 
>> 

[jira] [Assigned] (GEODE-2434) geodeOldVersionClasspaths.txt is generated every time build is parsed

[Dan Smith (JIRA)]

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

Dan Smith reassigned GEODE-2434:


Assignee: Dan Smith

> geodeOldVersionClasspaths.txt is generated every time build is parsed
> -
>
> Key: GEODE-2434
> URL: https://issues.apache.org/jira/browse/GEODE-2434
> Project: Geode
>  Issue Type: Bug
>  Components: build
>Reporter: Dan Smith
>Assignee: Dan Smith
>
> geode-old-versions/build.gradle regenerates geodeOldVersionClasspaths.txt 
> during the configuration phase of the task createGeodeClasspathsFile. This is 
> a performance issue with the build because every time someone types ./gradlew 
> it will regenerate this file while configuring the build.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2369) Exporting cluster-config with just a filename throws an NPE

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2369:


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

GEODE-2369: Remove --dir option from export cluster-config

This closes #374


> Exporting cluster-config with just a filename throws an NPE
> ---
>
> Key: GEODE-2369
> URL: https://issues.apache.org/jira/browse/GEODE-2369
> Project: Geode
>  Issue Type: Bug
>  Components: docs, gfsh, management
>Reporter: Kevin Duling
>Assignee: Jared Stewart
>  Labels: ClusterConfig, ExportClusterConfigurationCommand, 
> export, gfsh
>
> When running export cluster-configuration from gfsh and providing just a 
> filename rather than an absolute path, or a filename and the --dir parameter, 
> an exception is thrown.
> The {{--dir}} option appears to be unused.
> {noformat}
> [info 2017/01/25 13:10:08.436 PST locator1  Connection(3)-192.168.1.45> tid=0x46] (tid=70 msgId=67) Could not execute 
> "export
>  cluster-configuration --zip-file-name=cluster.zip --dir=/tmp".
> java.lang.NullPointerException
> at 
> org.apache.geode.management.internal.cli.commands.ExportImportClusterConfigurationCommands.exportSharedConfig(ExportImport
> ClusterConfigurationCommands.java:85)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:216)
> at 
> org.apache.geode.management.internal.cli.remote.RemoteExecutionStrategy.execute(RemoteExecutionStrategy.java:91)
> at 
> org.apache.geode.management.internal.cli.remote.CommandProcessor.executeCommand(CommandProcessor.java:117)
> at 
> org.apache.geode.management.internal.cli.remote.CommandStatementImpl.process(CommandStatementImpl.java:71)
> at 
> org.apache.geode.management.internal.cli.remote.MemberCommandService.processCommand(MemberCommandService.java:52)
> at 
> org.apache.geode.management.internal.beans.MemberMBeanBridge.processCommand(MemberMBeanBridge.java:1639)
> at 
> org.apache.geode.management.internal.beans.MemberMBean.processCommand(MemberMBean.java:404)
> at 
> org.apache.geode.management.internal.beans.MemberMBean.processCommand(MemberMBean.java:397)
> 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 sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> at 
> com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:193)
> at 
> com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:175)
> at 
> com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:117)
> at 
> com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:54)
> at 
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1468)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
> at 
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1309)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1401)
> at 
> javax.management.remote.rmi.RM

Review Request 56348: GEODE-2434: Generate old version classpaths in doLast

[Dan Smith]

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

Review request for geode, Bruce Schuchardt and Mark Bretl.


Repository: geode


Description
---

The geode-old-versions/build.gradle was generating the classpath
properties file during the build configuration phase, rather than the
execution phase.

Also converting the file to an actual properties file so that it will
handle special characters properly.


Diffs
-

  
geode-core/src/test/java/org/apache/geode/test/dunit/standalone/VersionManager.java
 7bda9481275d3801e347ae6dfd66520e3f123a3a 
  geode-old-versions/build.gradle a09b2d71c4ae9ab393b2d6e9cd44d94155e760f9 

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


Testing
---


Thanks,

Dan Smith

[GitHub] geode pull request #393: GEODE-2430: Remove jar and zip files from test reso...

[jaredjstewart]

GitHub user jaredjstewart opened a pull request:

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

GEODE-2430: Remove jar and zip files from test resources



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

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

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

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


commit 9070ea43b93311d3c14d856663d7db3363d57264
Author: Jared Stewart 
Date:   2017-02-03T20:53:38Z

GEODE-2430: Refactor ZipUtils

commit 7ba28e3052b72d5b000e52dc350dedd4d6e36a44
Author: Jared Stewart 
Date:   2017-02-06T22:54:49Z

GEODE-2430: Remove jar and zip files from test resources




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

[GitHub] geode pull request #393: GEODE-2430: Remove jar and zip files from test reso...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-2433) Backwards compatibility tests are not actually running

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2433:


Commit 3ce2a127c94515a8a57d8589d91e497fec7f2544 in geode's branch 
refs/heads/feature/GEODE-1930-2 from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=3ce2a12 ]

GEODE-2433  Backwards compatibility tests are not actually running

The geode-old-versions/build.gradle file was not included in the original
commit for backward-compatibility testing.  It's needed to establish
the old-version source sets and generate the classpaths file used by
VersionManager.


> Backwards compatibility tests are not actually running
> --
>
> Key: GEODE-2433
> URL: https://issues.apache.org/jira/browse/GEODE-2433
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Dan Smith
>Assignee: Bruce Schuchardt
> Fix For: 1.1.0
>
>
> We have several backwards compatibility tests checked in -
> RollingUpgradeDUnitTest
> RollingUpgrade2DUnitTest
> ClientServerMiscBCDUnitTest
> These tests are all parametered by the list of old versions to run against.
> However, it looks like the code to get the list of old versions incorrectly 
> just logs a message and continues on if it can't find a file called 
> geodeOldVersionClasspaths.txt. That file does not exist and is not being 
> generated as far is I can tell. The entire project - geode-old-versions, is 
> completely empty.
> The net effect is these tests don't actually run, because the list of 
> parameters is an empty list.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2430) Remove binary files from test resources

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2430:


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

GEODE-2430: Remove jar and zip files from test resources

This closes #393


> Remove binary files from test resources
> ---
>
> Key: GEODE-2430
> URL: https://issues.apache.org/jira/browse/GEODE-2430
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.1.0
>
>
> We have some tests which rely on the following binary files:
> {code}
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster.jar
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config.zip
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config_security.zip
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/group1.jar
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/group2.jar
> {code}
> We need to convert our tests to generate these files dynamically instead so 
> that we don't have binary files checked into our repository.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2430) Remove binary files from test resources

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2430:


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

GEODE-2430: Refactor ZipUtils


> Remove binary files from test resources
> ---
>
> Key: GEODE-2430
> URL: https://issues.apache.org/jira/browse/GEODE-2430
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.1.0
>
>
> We have some tests which rely on the following binary files:
> {code}
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster.jar
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config.zip
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config_security.zip
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/group1.jar
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/group2.jar
> {code}
> We need to convert our tests to generate these files dynamically instead so 
> that we don't have binary files checked into our repository.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2431) Upgrade use of Awaitility from 1.7.0 to 2.0.0

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2431:


Commit bc6db4a6301607a352def097a96ddd72d13d42fd in geode's branch 
refs/heads/feature/GEODE-1930-2 from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=bc6db4a ]

GEODE-2431: Update to Awaitility 2.0


> Upgrade use of Awaitility from 1.7.0 to 2.0.0
> -
>
> Key: GEODE-2431
> URL: https://issues.apache.org/jira/browse/GEODE-2431
> Project: Geode
>  Issue Type: Test
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> Upgrade use of Awaitility from 1.7.0 to 2.0.0
> See: https://github.com/awaitility/awaitility



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2433) Backwards compatibility tests are not actually running

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2433:


Commit c8d216654ac436797fc703faf63de36b300bf116 in geode's branch 
refs/heads/feature/GEODE-1930-2 from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=c8d2166 ]

GEODE-2433 Backwards compatibility tests are not actually running

Tests will now fail of there are no older versions of Geode to test
against.


> Backwards compatibility tests are not actually running
> --
>
> Key: GEODE-2433
> URL: https://issues.apache.org/jira/browse/GEODE-2433
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Dan Smith
>Assignee: Bruce Schuchardt
> Fix For: 1.1.0
>
>
> We have several backwards compatibility tests checked in -
> RollingUpgradeDUnitTest
> RollingUpgrade2DUnitTest
> ClientServerMiscBCDUnitTest
> These tests are all parametered by the list of old versions to run against.
> However, it looks like the code to get the list of old versions incorrectly 
> just logs a message and continues on if it can't find a file called 
> geodeOldVersionClasspaths.txt. That file does not exist and is not being 
> generated as far is I can tell. The entire project - geode-old-versions, is 
> completely empty.
> The net effect is these tests don't actually run, because the list of 
> parameters is an empty list.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)