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

2017-10-12 Thread Apache Jenkins Server 
See

Build failed in Jenkins: Geode-release #92

2017-10-12 Thread Apache Jenkins Server 
See 

--
[...truncated 371.77 KB...]
at 
org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:202)
at 
org.apache.geode.cache.client.internal.LocatorTestBase.startLocator(LocatorTestBase.java:131)
at 
org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.lambda$startInfraWithSSL$447082cb$1(RestAPIsWithSSLDUnitTest.java:225)
at org.apache.geode.test.dunit.NamedRunnable.run(NamedRunnable.java:31)
at sun.reflect.GeneratedMethodAccessor1363.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at hydra.MethExecutor.executeObject(MethExecutor.java:245)
at 
org.apache.geode.test.dunit.standalone.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:70)
at sun.reflect.GeneratedMethodAccessor259.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
at sun.rmi.transport.Transport$1.run(Transport.java:200)
at sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at 
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
at java.security.AccessController.doPrivileged(Native Method)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)

org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest > 
testSSLWithTLSv12Protocol[1] FAILED
java.lang.AssertionError: Suspicious strings were written to the log during 
this run.
Fix the strings or use IgnoredException.addIgnoredException to ignore.
---
Found suspect string in log4j at line 256

[error 2017/10/12 09:20:16.932 UTC  
tid=4066] failed setting interface to /127.0.1.1: java.net.SocketException: bad 
argument for IP_MULTICAST_IF: address not bound to any interface
java.net.SocketException: bad argument for IP_MULTICAST_IF: address not 
bound to any interface
at java.net.PlainDatagramSocketImpl.socketSetOption0(Native Method)
at 
java.net.PlainDatagramSocketImpl.socketSetOption(PlainDatagramSocketImpl.java:74)
at 
java.net.AbstractPlainDatagramSocketImpl.setOption(AbstractPlainDatagramSocketImpl.java:309)
at java.net.MulticastSocket.setInterface(MulticastSocket.java:471)
at org.jgroups.protocols.UDP.setInterface(UDP.java:443)
at org.jgroups.protocols.UDP.createMulticastSocket(UDP.java:511)
at 
org.jgroups.protocols.UDP.createMulticastSocketWithBindPort(UDP.java:494)
at org.jgroups.protocols.UDP.createSockets(UDP.java:348)
at org.jgroups.protocols.UDP.start(UDP.java:266)
at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966)
at org.jgroups.JChannel.startStack(JChannel.java:889)
at org.jgroups.JChannel._preConnect(JChannel.java:553)
at org.jgroups.JChannel.connect(JChannel.java:288)
at org.jgroups.JChannel.connect(JChannel.java:279)
at 
org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.start(JGroupsMessenger.java:344)
at 
org.apache.geode.distributed.internal.membership.gms.Services.start(Services.java:156)
at 
org.apache.geode.distributed.internal.membership.gms.GMSMemberFactory.newMembershipManager(GMSMemberFactory.java:107)
at 
org.apache.geode.distributed.internal.membership.MemberFactory.newMembershipManager(MemberFactory.java:91)
at 
org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1156)
at 
org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1205)
at 
org.apache.geode.distributed.internal.DistributionManager.create(DistributionManager.java:574)
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:740)
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:350)
at 
org.apache.geode.dis

Failed: jinmeiliao/geode#42 (destroyRegion - b9fb167)

2017-10-12 Thread Travis CI 
Build Update for jinmeiliao/geode
-

Build: #42
Status: Failed

Duration: 12 minutes and 52 seconds
Commit: b9fb167 (destroyRegion)
Author: Jinmei Liao
Message: GEODE-2563: destroy region should be idempotent

* added the if-exists option for destroy region
* refactor the RegionPathConverter for better validation of regionPath
* cleaned up commands that uses the RegionPathConverter to not do unnecessary 
validation
* reworked DestroyRegionCommandDUnitTest
* added more tests

View the changeset: 
https://github.com/jinmeiliao/geode/compare/d2a942e8e502^...b9fb16722b97

View the full build log and details: 
https://travis-ci.org/jinmeiliao/geode/builds/287293026?utm_source=email&utm_medium=notification

--

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

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

2017-10-12 Thread Spring CI 

---
Spring Data GemFire > Nightly-ApacheGeode > #707 was successful.
---
Scheduled
2184 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

Re: ClientProtocolService failures in geode-core dunit

2017-10-12 Thread Kirk Lund 
I'd recommend "geode-api" (keep the module names and jar names all lower
case).

On Thu, Oct 12, 2017 at 3:12 PM, Galen O'Sullivan 
wrote:

> Yeah, it probably shouldn't be logging the whole stacktrace. I think we
> should log a message at debug level, and log a warning if a new client
> tries to connect when the new client protocol isn't available.
>
> If we made a "geode-public-API" module, we could avoid the cyclic
> dependency and do away with the ServiceLoader stuff, but as it is now we
> can't.
>
> On Thu, Oct 12, 2017 at 1:36 PM, Kirk Lund  wrote:
>
> > After updating to latest develop, whenever I run a dunit test in
> > geode-core, the dunit locator is now throwing
> > ServiceLoadingFailureException because ClientProtocolServiceLoader can't
> > find a ClientProtocolService provider.
> >
> > It doesn't result in dunit failures (unless the dunit uses the dunit
> > locator) but it is generating stack traces in the output of the test.
> >
> > I'm assuming this was a mistake?
> >
> > [locator] [warn 2017/10/12 13:31:53.736 PDT  > Connection(1)-10.118.33.237> tid=20] Could not load client protocol
> > [locator]
> > org.apache.geode.internal.cache.tier.sockets.
> > ServiceLoadingFailureException:
> > There is no ClientProtocolService implementation found in JVM
> > [locator] at
> > org.apache.geode.internal.cache.tier.sockets.
> ClientProtocolServiceLoader.
> > loadService(ClientProtocolServiceLoader.java:27)
> > [locator] at
> > org.apache.geode.internal.cache.tier.sockets.TcpServerFactory.(
> > TcpServerFactory.java:38)
> > [locator] at
> > org.apache.geode.distributed.internal.InternalLocator.<
> > init>(InternalLocator.java:503)
> > [locator] at
> > org.apache.geode.distributed.internal.InternalLocator.
> > createLocator(InternalLocator.java:272)
> > [locator] at
> > org.apache.geode.distributed.internal.InternalLocator.
> > startLocator(InternalLocator.java:315)
> > [locator] at
> > org.apache.geode.distributed.Locator.startLocator(Locator.java:253)
> > [locator] at
> > org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:140)
> > [locator] at
> > org.apache.geode.test.dunit.standalone.DUnitLauncher$2.
> > call(DUnitLauncher.java:307)
> > [locator] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > [locator] at
> > sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:
> > 62)
> > [locator] at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(
> > DelegatingMethodAccessorImpl.java:43)
> > [locator] at java.lang.reflect.Method.invoke(Method.java:497)
> > [locator] at hydra.MethExecutor.executeObject(MethExecutor.java:245)
> > [locator] at hydra.MethExecutor.executeObject(MethExecutor.java:213)
> > [locator] at
> > org.apache.geode.test.dunit.standalone.RemoteDUnitVM.
> > executeMethodOnObject(RemoteDUnitVM.java:47)
> > [locator] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > [locator] at
> > sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:
> > 62)
> > [locator] at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(
> > DelegatingMethodAccessorImpl.java:43)
> > [locator] at java.lang.reflect.Method.invoke(Method.java:497)
> > [locator] at
> > sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323)
> > [locator] at sun.rmi.transport.Transport$1.run(Transport.java:200)
> > [locator] at sun.rmi.transport.Transport$1.run(Transport.java:197)
> > [locator] at java.security.AccessController.doPrivileged(Native Method)
> > [locator] at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> > [locator] at
> > sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
> > [locator] at
> > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(
> > TCPTransport.java:826)
> > [locator] at
> > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$
> > 256(TCPTransport.java:683)
> > [locator] at java.security.AccessController.doPrivileged(Native Method)
> > [locator] at
> > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(
> > TCPTransport.java:682)
> > [locator] at
> > java.util.concurrent.ThreadPoolExecutor.runWorker(
> > ThreadPoolExecutor.java:1142)
> > [locator] at
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(
> > ThreadPoolExecutor.java:617)
> > [locator] at java.lang.Thread.run(Thread.java:745)
> >
>

Re: ClientProtocolService failures in geode-core dunit

2017-10-12 Thread Udo Kohlmeyer 
Currently there is a PR awaiting review, that will address this issue.
https://github.com/apache/geode/pull/920

On Thu, Oct 12, 2017 at 3:12 PM, Galen O'Sullivan 
wrote:

> Yeah, it probably shouldn't be logging the whole stacktrace. I think we
> should log a message at debug level, and log a warning if a new client
> tries to connect when the new client protocol isn't available.
>
> If we made a "geode-public-API" module, we could avoid the cyclic
> dependency and do away with the ServiceLoader stuff, but as it is now we
> can't.
>
> On Thu, Oct 12, 2017 at 1:36 PM, Kirk Lund  wrote:
>
> > After updating to latest develop, whenever I run a dunit test in
> > geode-core, the dunit locator is now throwing
> > ServiceLoadingFailureException because ClientProtocolServiceLoader can't
> > find a ClientProtocolService provider.
> >
> > It doesn't result in dunit failures (unless the dunit uses the dunit
> > locator) but it is generating stack traces in the output of the test.
> >
> > I'm assuming this was a mistake?
> >
> > [locator] [warn 2017/10/12 13:31:53.736 PDT  > Connection(1)-10.118.33.237> tid=20] Could not load client protocol
> > [locator]
> > org.apache.geode.internal.cache.tier.sockets.
> > ServiceLoadingFailureException:
> > There is no ClientProtocolService implementation found in JVM
> > [locator] at
> > org.apache.geode.internal.cache.tier.sockets.
> ClientProtocolServiceLoader.
> > loadService(ClientProtocolServiceLoader.java:27)
> > [locator] at
> > org.apache.geode.internal.cache.tier.sockets.TcpServerFactory.(
> > TcpServerFactory.java:38)
> > [locator] at
> > org.apache.geode.distributed.internal.InternalLocator.<
> > init>(InternalLocator.java:503)
> > [locator] at
> > org.apache.geode.distributed.internal.InternalLocator.
> > createLocator(InternalLocator.java:272)
> > [locator] at
> > org.apache.geode.distributed.internal.InternalLocator.
> > startLocator(InternalLocator.java:315)
> > [locator] at
> > org.apache.geode.distributed.Locator.startLocator(Locator.java:253)
> > [locator] at
> > org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:140)
> > [locator] at
> > org.apache.geode.test.dunit.standalone.DUnitLauncher$2.
> > call(DUnitLauncher.java:307)
> > [locator] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > [locator] at
> > sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:
> > 62)
> > [locator] at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(
> > DelegatingMethodAccessorImpl.java:43)
> > [locator] at java.lang.reflect.Method.invoke(Method.java:497)
> > [locator] at hydra.MethExecutor.executeObject(MethExecutor.java:245)
> > [locator] at hydra.MethExecutor.executeObject(MethExecutor.java:213)
> > [locator] at
> > org.apache.geode.test.dunit.standalone.RemoteDUnitVM.
> > executeMethodOnObject(RemoteDUnitVM.java:47)
> > [locator] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > [locator] at
> > sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:
> > 62)
> > [locator] at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(
> > DelegatingMethodAccessorImpl.java:43)
> > [locator] at java.lang.reflect.Method.invoke(Method.java:497)
> > [locator] at
> > sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323)
> > [locator] at sun.rmi.transport.Transport$1.run(Transport.java:200)
> > [locator] at sun.rmi.transport.Transport$1.run(Transport.java:197)
> > [locator] at java.security.AccessController.doPrivileged(Native Method)
> > [locator] at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> > [locator] at
> > sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
> > [locator] at
> > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(
> > TCPTransport.java:826)
> > [locator] at
> > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$
> > 256(TCPTransport.java:683)
> > [locator] at java.security.AccessController.doPrivileged(Native Method)
> > [locator] at
> > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(
> > TCPTransport.java:682)
> > [locator] at
> > java.util.concurrent.ThreadPoolExecutor.runWorker(
> > ThreadPoolExecutor.java:1142)
> > [locator] at
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(
> > ThreadPoolExecutor.java:617)
> > [locator] at java.lang.Thread.run(Thread.java:745)
> >
>



-- 
Kindest Regards
-
*Udo Kohlmeyer* | *Pivotal*
ukohlme...@pivotal.io

www.pivotal.io

Re: ClientProtocolService failures in geode-core dunit

2017-10-12 Thread Galen O'Sullivan 
Yeah, it probably shouldn't be logging the whole stacktrace. I think we
should log a message at debug level, and log a warning if a new client
tries to connect when the new client protocol isn't available.

If we made a "geode-public-API" module, we could avoid the cyclic
dependency and do away with the ServiceLoader stuff, but as it is now we
can't.

On Thu, Oct 12, 2017 at 1:36 PM, Kirk Lund  wrote:

> After updating to latest develop, whenever I run a dunit test in
> geode-core, the dunit locator is now throwing
> ServiceLoadingFailureException because ClientProtocolServiceLoader can't
> find a ClientProtocolService provider.
>
> It doesn't result in dunit failures (unless the dunit uses the dunit
> locator) but it is generating stack traces in the output of the test.
>
> I'm assuming this was a mistake?
>
> [locator] [warn 2017/10/12 13:31:53.736 PDT  Connection(1)-10.118.33.237> tid=20] Could not load client protocol
> [locator]
> org.apache.geode.internal.cache.tier.sockets.
> ServiceLoadingFailureException:
> There is no ClientProtocolService implementation found in JVM
> [locator] at
> org.apache.geode.internal.cache.tier.sockets.ClientProtocolServiceLoader.
> loadService(ClientProtocolServiceLoader.java:27)
> [locator] at
> org.apache.geode.internal.cache.tier.sockets.TcpServerFactory.(
> TcpServerFactory.java:38)
> [locator] at
> org.apache.geode.distributed.internal.InternalLocator.<
> init>(InternalLocator.java:503)
> [locator] at
> org.apache.geode.distributed.internal.InternalLocator.
> createLocator(InternalLocator.java:272)
> [locator] at
> org.apache.geode.distributed.internal.InternalLocator.
> startLocator(InternalLocator.java:315)
> [locator] at
> org.apache.geode.distributed.Locator.startLocator(Locator.java:253)
> [locator] at
> org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:140)
> [locator] at
> org.apache.geode.test.dunit.standalone.DUnitLauncher$2.
> call(DUnitLauncher.java:307)
> [locator] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [locator] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
> 62)
> [locator] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> [locator] at java.lang.reflect.Method.invoke(Method.java:497)
> [locator] at hydra.MethExecutor.executeObject(MethExecutor.java:245)
> [locator] at hydra.MethExecutor.executeObject(MethExecutor.java:213)
> [locator] at
> org.apache.geode.test.dunit.standalone.RemoteDUnitVM.
> executeMethodOnObject(RemoteDUnitVM.java:47)
> [locator] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [locator] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
> 62)
> [locator] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> [locator] at java.lang.reflect.Method.invoke(Method.java:497)
> [locator] at
> sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323)
> [locator] at sun.rmi.transport.Transport$1.run(Transport.java:200)
> [locator] at sun.rmi.transport.Transport$1.run(Transport.java:197)
> [locator] at java.security.AccessController.doPrivileged(Native Method)
> [locator] at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> [locator] at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
> [locator] at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(
> TCPTransport.java:826)
> [locator] at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$
> 256(TCPTransport.java:683)
> [locator] at java.security.AccessController.doPrivileged(Native Method)
> [locator] at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(
> TCPTransport.java:682)
> [locator] at
> java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)
> [locator] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617)
> [locator] at java.lang.Thread.run(Thread.java:745)
>

ClientProtocolService failures in geode-core dunit

2017-10-12 Thread Kirk Lund 
After updating to latest develop, whenever I run a dunit test in
geode-core, the dunit locator is now throwing
ServiceLoadingFailureException because ClientProtocolServiceLoader can't
find a ClientProtocolService provider.

It doesn't result in dunit failures (unless the dunit uses the dunit
locator) but it is generating stack traces in the output of the test.

I'm assuming this was a mistake?

[locator] [warn 2017/10/12 13:31:53.736 PDT  tid=20] Could not load client protocol
[locator]
org.apache.geode.internal.cache.tier.sockets.ServiceLoadingFailureException:
There is no ClientProtocolService implementation found in JVM
[locator] at
org.apache.geode.internal.cache.tier.sockets.ClientProtocolServiceLoader.loadService(ClientProtocolServiceLoader.java:27)
[locator] at
org.apache.geode.internal.cache.tier.sockets.TcpServerFactory.(TcpServerFactory.java:38)
[locator] at
org.apache.geode.distributed.internal.InternalLocator.(InternalLocator.java:503)
[locator] at
org.apache.geode.distributed.internal.InternalLocator.createLocator(InternalLocator.java:272)
[locator] at
org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:315)
[locator] at
org.apache.geode.distributed.Locator.startLocator(Locator.java:253)
[locator] at
org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:140)
[locator] at
org.apache.geode.test.dunit.standalone.DUnitLauncher$2.call(DUnitLauncher.java:307)
[locator] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[locator] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[locator] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[locator] at java.lang.reflect.Method.invoke(Method.java:497)
[locator] at hydra.MethExecutor.executeObject(MethExecutor.java:245)
[locator] at hydra.MethExecutor.executeObject(MethExecutor.java:213)
[locator] at
org.apache.geode.test.dunit.standalone.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:47)
[locator] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[locator] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[locator] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[locator] at java.lang.reflect.Method.invoke(Method.java:497)
[locator] at
sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323)
[locator] at sun.rmi.transport.Transport$1.run(Transport.java:200)
[locator] at sun.rmi.transport.Transport$1.run(Transport.java:197)
[locator] at java.security.AccessController.doPrivileged(Native Method)
[locator] at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
[locator] at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
[locator] at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
[locator] at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$256(TCPTransport.java:683)
[locator] at java.security.AccessController.doPrivileged(Native Method)
[locator] at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
[locator] at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[locator] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[locator] at java.lang.Thread.run(Thread.java:745)

Re: [Discuss] Geode gradle plugin

2017-10-12 Thread Jared Stewart 
Yeah, the Plugin Portal is great!  Not only is it easy to publish to, it also 
makes the plugin easier to add for users. If you publish to the Portal, a user 
only needs to add a plugins block: 

plugins {
id 'com.jfrog.bintray' version '0.4.1'
}

Whereas if you publish to Bintray, JCenter, Maven Central, etc, a user must 
also add a build script dependency: 

buildscript {
repositories {
jcenter()
}
dependencies {
classpath "com.jfrog.bintray.gradle:gradle-bintray-plugin:0.4.1"
}
}

apply plugin: "com.jfrog.bintray"

I haven’t registered yet, since I wasn’t sure what email address to use for 
registration or where to store our API key.  How do we manage the API key for 
publishing Geode releases to Maven Central?

Thanks,
Jared

> On Oct 12, 2017, at 9:31 AM, Anthony Baker  wrote:
> 
> Have you looked at https://plugins.gradle.org/docs/submit 
>  
>  > ?
> 
> Anthony
> 
> 
>> On Oct 11, 2017, at 7:56 PM, Jared Stewart > > wrote:
>> 
>> Hi all,
>> 
>> I've been working on a Gradle plugin to make it easier to write integration 
>> tests for applications that use Apache Geode, and would like to discuss 
>> where it should reside.  
>> 
>> To give some background, we have a JUnit Rule called GfshRule that lets you 
>> write tests that execute gfsh commands. The rule is exported in geode-junit, 
>> so developers of Geode applications can use the rule to start up a transient 
>> cluster for their own integration testing, among other things.  
>> However, the rule relies on having the GEODE_HOME environment variable set 
>> to an existing installation of Geode, which can be problematic for CI 
>> environments or tests running inside of containers.
>> 
>> The Gradle plugin will add a task that downloads a distribution of Geode via 
>> Maven, unzips it into build/install/apache-geode, and sets the proper 
>> environment variable for any tests that are run through Gradle. 
>> 
>> It would be nice to avoid having the releases of Geode and the plugin tied 
>> together, so I thought I would suggest having a separate repository for the 
>> plugin (similar to geode-examples).  Does anyone have thoughts on whether 
>> that's the correct place for the plugin to live, or on what it should be 
>> called?  geode-integration-gradle-plugin?
>> 
>> Any feedback is appreciated,
>> - Jared
>> 
>> P.S. If you want to take a look at the work in progress, it's been pushed 
>> here for now: https://github.com/jaredjstewart/geode-integration-plugin 
>> >  >

Re: [Discuss] Geode gradle plugin

2017-10-12 Thread Anthony Baker 
Have you looked at https://plugins.gradle.org/docs/submit 
 ?

Anthony


> On Oct 11, 2017, at 7:56 PM, Jared Stewart  wrote:
> 
> Hi all,
> 
> I've been working on a Gradle plugin to make it easier to write integration 
> tests for applications that use Apache Geode, and would like to discuss where 
> it should reside.  
> 
> To give some background, we have a JUnit Rule called GfshRule that lets you 
> write tests that execute gfsh commands. The rule is exported in geode-junit, 
> so developers of Geode applications can use the rule to start up a transient 
> cluster for their own integration testing, among other things.  
> However, the rule relies on having the GEODE_HOME environment variable set to 
> an existing installation of Geode, which can be problematic for CI 
> environments or tests running inside of containers.
> 
> The Gradle plugin will add a task that downloads a distribution of Geode via 
> Maven, unzips it into build/install/apache-geode, and sets the proper 
> environment variable for any tests that are run through Gradle. 
> 
> It would be nice to avoid having the releases of Geode and the plugin tied 
> together, so I thought I would suggest having a separate repository for the 
> plugin (similar to geode-examples).  Does anyone have thoughts on whether 
> that's the correct place for the plugin to live, or on what it should be 
> called?  geode-integration-gradle-plugin?
> 
> Any feedback is appreciated,
> - Jared
> 
> P.S. If you want to take a look at the work in progress, it's been pushed 
> here for now: https://github.com/jaredjstewart/geode-integration-plugin 
>

Re: Mailing list subscription request

2017-10-12 Thread Anthony Baker 
Welcome!  Please see [1] for how to subscribe.

Anthony

[1] http://apache.org/foundation/mailinglists.html 


> On Oct 12, 2017, at 3:43 AM, Arun Yadav  wrote:
> 
> Regards
> Arun
> 
> Sent from ProtonMail mobile

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

2017-10-12 Thread Apache Jenkins Server 
See 


Changes:

[khowe] GEODE_3299: Refactor Gfsh functions to acquire Cache from FunctionContex

[kohlmu-pivotal] GEODE-3802: Amending package renaming issues

[github] GEODE-3539: consolidate IndexType for better option verification (#910)

[kmiller] GEODE-3445 Document new gfsh connect option

[github] GEODE-3247 Document query method invocation changes (#909)

[jstewart] GEODE-3685: Fix test failure

[bschuchardt] GEODE-1176 CI failure: 
FixedPRSinglehopDUnitTest.test_MetadataContents

[bschuchardt] GEODE-3808 LonerDMJUnitTest.testMemberID fails if hostname lookup 
isn't

[dbarnes] User Guide: Clarified a passage in the Authentication section.

[khowe] GEODE_3299: Refactor Gfsh functions to acquire Cache from FunctionContex

[kmiller] GEODE-3445 Revise doc to specify 1-way authentication

[kirk.lund] GEODE-3791: add new tests for CacheListener on PartionedRegion

[kirk.lund] GEODE-3805: Use correct timestamplto check last modified time

--
[...truncated 109.02 KB...]
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-swagger-common/2.6.1/springfox-swagger-common-2.6.1.pom
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-spring-web/2.6.1/springfox-spring-web-2.6.1.pom
Download 
https://repo1.maven.org/maven2/com/fasterxml/classmate/1.3.1/classmate-1.3.1.pom
Download 
https://repo1.maven.org/maven2/org/springframework/plugin/spring-plugin-core/1.2.0.RELEASE/spring-plugin-core-1.2.0.RELEASE.pom
Download 
https://repo1.maven.org/maven2/org/springframework/plugin/spring-plugin/1.2.0.RELEASE/spring-plugin-1.2.0.RELEASE.pom
Download 
https://repo1.maven.org/maven2/org/springframework/plugin/spring-plugin-metadata/1.2.0.RELEASE/spring-plugin-metadata-1.2.0.RELEASE.pom
Download 
https://repo1.maven.org/maven2/org/mapstruct/mapstruct/1.0.0.Final/mapstruct-1.0.0.Final.pom
Download 
https://repo1.maven.org/maven2/org/mapstruct/mapstruct-parent/1.0.0.Final/mapstruct-parent-1.0.0.Final.pom
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-core/2.6.1/springfox-core-2.6.1.pom
Download 
https://repo1.maven.org/maven2/com/fasterxml/jackson/module/jackson-module-scala_2.10/2.8.6/jackson-module-scala_2.10-2.8.6.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-swagger2/2.6.1/springfox-swagger2-2.6.1.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-swagger-ui/2.6.1/springfox-swagger-ui-2.6.1.jar
Download 
https://repo1.maven.org/maven2/org/springframework/hateoas/spring-hateoas/0.23.0.RELEASE/spring-hateoas-0.23.0.RELEASE.jar
Download 
https://repo1.maven.org/maven2/com/fasterxml/jackson/module/jackson-module-paranamer/2.8.6/jackson-module-paranamer-2.8.6.jar
Download 
https://repo1.maven.org/maven2/io/swagger/swagger-annotations/1.5.10/swagger-annotations-1.5.10.jar
Download 
https://repo1.maven.org/maven2/io/swagger/swagger-models/1.5.10/swagger-models-1.5.10.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-spi/2.6.1/springfox-spi-2.6.1.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-schema/2.6.1/springfox-schema-2.6.1.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-swagger-common/2.6.1/springfox-swagger-common-2.6.1.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-spring-web/2.6.1/springfox-spring-web-2.6.1.jar
Download 
https://repo1.maven.org/maven2/org/springframework/plugin/spring-plugin-core/1.2.0.RELEASE/spring-plugin-core-1.2.0.RELEASE.jar
Download 
https://repo1.maven.org/maven2/org/springframework/plugin/spring-plugin-metadata/1.2.0.RELEASE/spring-plugin-metadata-1.2.0.RELEASE.jar
Download 
https://repo1.maven.org/maven2/org/mapstruct/mapstruct/1.0.0.Final/mapstruct-1.0.0.Final.jar
Download 
https://repo1.maven.org/maven2/com/thoughtworks/paranamer/paranamer/2.8/paranamer-2.8.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-core/2.6.1/springfox-core-2.6.1.jar
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
:geode-web-api:processResources
:geode-web-api:classes
:geode-assembly:docs
:geode-assembly:gfshDepsJar
:geode-common:javadocJar
:geode-common:sourcesJar
:geode-common:signArchives SKIPPED
:geode-core:javadocJar
:geode-core:raJar
:geode-core:jcaJar
:geode-core:sourcesJar
:geode-core:signArchives SKIPPED
:geode-core:webJar
:geode-cq:jar
:geode-cq:javadoc
:geode-cq:javadocJar
:geode-cq:sourcesJar
:geode-cq:signArchives SKIPPED
:geode-json:javadocJar
:geode-json:sourcesJar
:geode-json:signArchives SKIPPED
:geode-lucene:jar
:geode-lucene:javadoc
:geode-lucene:javadocJar
:geode-lucene:sourcesJar
:geode-lucene:signArchives SKIPPED
:geode-old-client-support:jar
:geode-old-client-support:javadoc
:geode-old-client-support:javadocJar
:geode-old-client-support:sourcesJar
:geode-old-client-support:signArchives SKIPPED
:geode-protobuf:jar
:geode-protobuf:javadoc
:g

Mailing list subscription request

2017-10-12 Thread Arun Yadav 
Regards
Arun

Sent from ProtonMail mobile

Jenkins build is back to normal : Geode-nightly #982

2017-10-12 Thread Apache Jenkins Server 
See

Re: 1.3.0 release

2017-10-12 Thread Jacob Barrett 
All those Geode Native issues you resolved for 1.3 shouldn’t be. I don’t 
believe we intend to include any native in this release of Geode.

> On Oct 11, 2017, at 10:40 PM, Swapnil Bawaskar  wrote:
> 
> All issues targeted for 1.3.0 have been resolved. I will cut a release
> candidate shortly.
> 
> On Sat, Oct 7, 2017 at 11:18 AM Swapnil Bawaskar 
> wrote:
> 
>> Hi All,
>> Thanks for all your efforts in resolving a whopping 51 issues in the past
>> week! Since I did not hear any concerns, I removed 1.3 label from some of
>> the issues mentioned below, along with some CI failure issues. This now
>> brings us down to only 2:
>> GEODE-3247: Improve OQL expression execution
>> GEODE-3743: Deprecate option for manual restart of Gateway senders
>> 
>> For GEODE-3247 the implementation is complete, documentation pending. I
>> hope to cut the release branch and have a release candidate early next week.
>> 
>> Thanks!
>> Swapnil.
>> 
>> 
>> On Sun, Oct 1, 2017 at 9:31 AM Swapnil Bawaskar 
>> wrote:
>> 
>>> Hi All,
>>> We actually have gone up from 11 to 15 issues tagged for release with
>>> 1.3. Based on recent activity (or lack there of) and features not related
>>> to Security, I think we should not wait for the following issues for 1.3:
>>> (I will remove 1.3 labels for these if there are no concerns in 72 hours)
>>> GEODE-3563  SSL socket
>>> handling problems in TCPConduit run
>>> GEODE-3521  Allow
>>> region set op to bootstrap JTA
>>> GEODE-3622  The first
>>> HeapLRU evictions on large region can consume high amounts of CPU
>>> GEODE-3705  New client
>>> protocol: Implement handshake
>>> GEODE-3682  Trace
>>> displaying incorrect indexes being used
>>> GEODE-3637  
>>> configureClientSSLSocket
>>> call can block Acceptor thread
>>> 
>>> Which brings us down to the following 8:
>>> GEODE-2817  Have the
>>> function author determine what permissions the function execution requires
>>> GEODE-2919  Provide
>>> finer grained security
>>> GEODE-3190  CI
>>> failure:
>>> org.apache.geode.internal.cache.Bug48182JUnitTest.test48182WithRegionDestroy
>>> GEODE-3495  Review and
>>> update dependencies for 1.3.0
>>> GEODE-3621  Revert
>>> breaking changes in SecurityManager
>>> GEODE-3628  fix
>>> required permission for lucene query
>>> GEODE-3685  MBean
>>> wrappers are not always applied correctly
>>> GEODE-3723  Reconsider
>>> using Optional as the parameter for getRequiredPermissions
>>> 
>>> 
>>> 
>>> On Fri, Sep 15, 2017 at 1:11 PM Swapnil Bawaskar 
>>> wrote:
>>> 
 I took preliminary look and tagged some issues for 1.3.0.
 Looks like we have 11 issues remaining:
 
 https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=92&projectKey=GEODE&view=planning&selectedIssue=GEODE-2788&versions=visible&selectedVersion=12340669
 
 Please take a look at these issues to see which are not critical to fix
 in 1.3 and also look at issues assigned to you/reported by you to see if
 they must be tagged for 1.3.
 
 Thanks!
 
 
 
 On Fri, Sep 15, 2017 at 10:36 AM Anthony Baker 
 wrote:
 
> Excellent!  Can you review the open issues currently tagged for 1.3.0
> (I think it’s probably not accurate) and gather consensus on any remaining
> changes needed?
> 
> Anthony
> 
>> On Sep 12, 2017, at 2:40 PM, Swapnil Bawaskar 
> wrote:
>> 
>> Sound good.
>> 
>> I would like to volunteer to be the release manager.
>> 
>> Thanks!
>> 
>> 
>> On Tue, Sep 12, 2017 at 2:24 PM Anthony Baker 
> wrote:
>> 
>>> Hi all,
>>> 
>>> I think we should begin discussing scope and timeline for the 1.3.0
>>> release.  I know we’re still finalizing 1.2.1, but we released 1.2.0
> almost
>>> two months ago and we’ve fixed almost 200 issues in that time.  IMO,
> we
>>> should complete 1.2.1 and then immediately turn around 1.3.0.
>>> 
>>> Thoughts?  Any volunteers for release manager?
>>> 
>>> Anthony
>>> 
>>> 
> 
>

Re: [VOTE] Apache Geode release - 1.3.0 RC1

2017-10-12 Thread Swapnil Bawaskar 
I am cancelling this vote because uploading the archives to maven staging
repo failed.
The error was: Missing Signature:
'/org/apache/geode/apache-geode/1.3.0/apache-geode-1.3.0.tar.gz.asc' does
not exist for 'apache-geode-1.3.0.tar.gz' even though that file was created
locally. I will dig into it tomorrow.

On Thu, Oct 12, 2017 at 12:43 AM Swapnil Bawaskar 
wrote:

> This is the first release candidate for Apache Geode, version 1.3.0. I
> will send out a separate vote thread for geode-examples.
> Thanks to all the community members for their contributions to this
> release!
>
> *** Please download, test and vote by Monday, October 16, 0800 hrs
> US Pacific. ***
>
> It fixes 477 issues. release notes can be found at:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318420&version=12340669
>
> Note that we are voting upon the source tags:  rel/v1.3.0.RC1
> https://github.com/apache/geode/tree/rel/v1.3.0.RC1
>
> Commit ID:
> 95bc7b6eaaff9cc5a200497eb3d0db5019a06bc2 (geode)
>
> Source and binary files:
>  https://dist.apache.org/repos/dist/dev/geode/1.3.0.RC1
>
> Maven staging repo:
>  https://repository.apache.org/content/repositories/orgapachegeode-1028
>
> Geode's KEYS file containing PGP keys we use to sign the release:
>  https://github.com/apache/geode/blob/develop/KEYS
>
> Release Signed with Key: pub 4096R/18F902DB 2016-04-07
> Fingerprint: E1B1 ABE3 4753 E7BA 8097 4285 8F8F 2BCC 18F9 02DB
>

[VOTE] Apache Geode release - 1.3.0 RC1

2017-10-12 Thread Swapnil Bawaskar 
This is the first release candidate for Apache Geode, version 1.3.0. I will
send out a separate vote thread for geode-examples.
Thanks to all the community members for their contributions to this
release!

*** Please download, test and vote by Monday, October 16, 0800 hrs
US Pacific. ***

It fixes 477 issues. release notes can be found at:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318420&version=12340669

Note that we are voting upon the source tags:  rel/v1.3.0.RC1
https://github.com/apache/geode/tree/rel/v1.3.0.RC1

Commit ID:
95bc7b6eaaff9cc5a200497eb3d0db5019a06bc2 (geode)

Source and binary files:
 https://dist.apache.org/repos/dist/dev/geode/1.3.0.RC1

Maven staging repo:
 https://repository.apache.org/content/repositories/orgapachegeode-1028

Geode's KEYS file containing PGP keys we use to sign the release:
 https://github.com/apache/geode/blob/develop/KEYS

Release Signed with Key: pub 4096R/18F902DB 2016-04-07
Fingerprint: E1B1 ABE3 4753 E7BA 8097 4285 8F8F 2BCC 18F9 02DB