Build failed in Jenkins: Geode-nightly #981

2017-10-11 Thread Apache Jenkins Server 
See 


Changes:

[github] GEODE-1290: AbstractRegionEntry.prepareValueForCache cache the new

[github] GEODE-3785: correctly update the schema version, namespace and lcoati…

[browe] GEODE-3751: a single place for client protocol loading, logic.

[huynhja] GEODE-3714: Removed repetitive looping code when evaluating

[kohlmu-pivotal] GEODE-3802: moved Authenticator and Authorization classes to 
internal

[github] GEODE-3722 Revise one more instance of queryStrings (#901)

[github] GEODE-3740 Document diskTasksWaiting CachePerfStats statistic (#900)

[nabarunnag] GEODE-3131: Awaitility clause added to reference count 
verification.

[github] GEODE-3803: Added additional string methods to whitelist (#907)

[agingade] GEODE-3796 Changes are made to validate region version after the 
region

[agingade] GEODE-3796 Changes are made to validate region version after the 
region

--
[...truncated 142.56 KB...]
at java.net.SocketInputStream.read(SocketInputStream.java:224)
at 
com.google.protobuf.AbstractParser.parsePartialDelimitedFrom(AbstractParser.java:253)
at 
com.google.protobuf.AbstractParser.parseDelimitedFrom(AbstractParser.java:275)
at 
com.google.protobuf.AbstractParser.parseDelimitedFrom(AbstractParser.java:280)
at 
com.google.protobuf.AbstractParser.parseDelimitedFrom(AbstractParser.java:49)
at 
com.google.protobuf.GeneratedMessageV3.parseDelimitedWithIOException(GeneratedMessageV3.java:329)
at 
org.apache.geode.internal.protocol.protobuf.AuthenticationAPI$SimpleAuthenticationResponse.parseDelimitedFrom(AuthenticationAPI.java:841)
at 
org.apache.geode.internal.protocol.AuthorizationIntegrationTest.setUp(AuthorizationIntegrationTest.java:124)

org.apache.geode.internal.protocol.AuthenticationIntegrationTest > 
noopAuthenticationSucceeds FAILED

org.apache.geode.internal.protocol.exception.InvalidProtocolMessageException: 
Failed to parse Protobuf Message
at 
org.apache.geode.internal.protocol.protobuf.serializer.ProtobufProtocolSerializer.deserialize(ProtobufProtocolSerializer.java:34)
at 
org.apache.geode.internal.protocol.AuthenticationIntegrationTest.noopAuthenticationSucceeds(AuthenticationIntegrationTest.java:119)

Caused by:
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at java.net.SocketInputStream.read(SocketInputStream.java:224)
at 
com.google.protobuf.AbstractParser.parsePartialDelimitedFrom(AbstractParser.java:253)
at 
com.google.protobuf.AbstractParser.parseDelimitedFrom(AbstractParser.java:275)
at 
com.google.protobuf.AbstractParser.parseDelimitedFrom(AbstractParser.java:280)
at 
com.google.protobuf.AbstractParser.parseDelimitedFrom(AbstractParser.java:49)
at 
com.google.protobuf.GeneratedMessageV3.parseDelimitedWithIOException(GeneratedMessageV3.java:329)
at 
org.apache.geode.internal.protocol.protobuf.ClientProtocol$Message.parseDelimitedFrom(ClientProtocol.java:399)
at 
org.apache.geode.internal.protocol.protobuf.serializer.ProtobufProtocolSerializer.deserialize(ProtobufProtocolSerializer.java:32)
... 1 more

org.apache.geode.internal.protocol.AuthenticationIntegrationTest > 
simpleAuthenticationSucceeds FAILED
java.lang.NullPointerException
at 
org.apache.geode.internal.protocol.AuthenticationIntegrationTest.simpleAuthenticationSucceeds(AuthenticationIntegrationTest.java:134)

org.apache.geode.internal.protocol.acceptance.CacheOperationsJUnitTest > 
testResponseToGetWithNoData FAILED
java.net.SocketException: Broken pipe (Write failed)
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:111)
at java.net.SocketOutputStream.write(SocketOutputStream.java:155)
at 
com.google.protobuf.CodedOutputStream$OutputStreamEncoder.doFlush(CodedOutputStream.java:2997)
at 
com.google.protobuf.CodedOutputStream$OutputStreamEncoder.flush(CodedOutputStream.java:2908)
at 
com.google.protobuf.AbstractMessageLite.writeDelimitedTo(AbstractMessageLite.java:97)
at 
org.apache.geode.internal.protocol.protobuf.serializer.ProtobufProtocolSerializer.serialize(ProtobufProtocolSerializer.java:41)
at 
org.apache.geode.internal.protocol.acceptance.CacheOperationsJUnitTest.testResponseToGetWithNoData(CacheOperationsJUnitTest.java:246)

org.apache.geode.internal.protocol.acceptance.CacheOperationsJUnitTest > 
multiKeyOperationErrorsWithClasscastException FAILED
java.net.SocketException: Broken pipe (Write failed)
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.Sock

Re: [DISCUSS] C++ Returning null values

2017-10-11 Thread Michael William Dodge 
To me the question of a no-op region comes down to whether customers would need 
to do logic based on whether a region has a parent. If they do, perhaps a bool 
hasParent() along with getParent() returning a no-op region would be an elegant 
solution. If they do not, then shared_ptr is probably sufficient.

Sarge

> On 10 Oct, 2017, at 12:45, David Kimura  wrote:
> 
> Yes, but I wouldn't expect to ever need to do a type check. Admittedly, I'm
> not sure what one does with parent region, but if we no-op, return sensible
> empty values, or throw when appropriate then maybe we don't care?
> 
> I would expect it to be used something like this:
> 
> auto parent = region.getParent();
> 
> // if region didn't have parent region, this could always return false.
> // else if it did have a parent region it would behave as expected.
> parent.containsKey("a_key");
> 
> 
> If this works, I like that we don't have to special case for calling
> getParent on root region and we could return by value.
> 
> Thanks,
> David
> 
> On Tue, Oct 10, 2017 at 12:29 PM, Jacob Barrett  wrote:
> 
>> Are you thinking something like?
>> 
>> class NoRegion : public Region {...};
>> 
>> auto parent = region.getParent();
>> if (NoRegion == parent) {
>>  // no parent region
>> }
>> 
>> 
>> On Tue, Oct 10, 2017 at 11:08 AM David Kimura  wrote:
>> 
>>> I'm not sure if this is the same as the sentinel value you mentioned, but
>>> what about introducing a no-op region type and returning that?  I'm
>>> thinking a null object pattern which would no-op and then nobody should
>>> need to check if nullptr.
>>> 
>>> Thanks,
>>> David
>>> 
>>> On Tue, Oct 10, 2017 at 10:27 AM, Jacob Barrett 
>>> wrote:
>>> 
 Looking at a class like Region (Region.cpp) there are calls to get the
 parent region and sub regions, there are instances where a Region will
>>> not
 have a parent or subs. The current API returns shared_ptr that may be
 nullptr or a Region.
 
 Since we are trying to make an effort towards values over pointers
>> should
 be considered some changes here? Obviously a reference is out of the
 question because it can't be null. A value is really out of the
>> question
 too since it can't be null and making a sentinel value is not a great
 solution. Raw pointers are fine since they can be nullptr but make
 ownership ambiguous. Using shared_ptr is good since it can be nullptr
>> and
 solves the ownership problem. Another option is to embrace the
>>> forthcoming
 std::optional available as boost::optional in C++11.
 
 I am leaning towards keeping it shared_ptr since using boost::optional
 would require users compile with boost. I don't think we should have
 anything on our API that is not ours of C++11. Requiring third party
 libraries to compile against our API doesn't fly right by me.
 
 Thoughts?
 
>>> 
>>

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

2017-10-11 Thread Apache Jenkins Server 
See 


Changes:

[browe] GEODE-3751: a single place for client protocol loading, logic.

[huynhja] GEODE-3714: Removed repetitive looping code when evaluating

[kohlmu-pivotal] GEODE-3802: moved Authenticator and Authorization classes to 
internal

[github] GEODE-3722 Revise one more instance of queryStrings (#901)

[github] GEODE-3740 Document diskTasksWaiting CachePerfStats statistic (#900)

[nabarunnag] GEODE-3131: Awaitility clause added to reference count 
verification.

[github] GEODE-3803: Added additional string methods to whitelist (#907)

[agingade] GEODE-3796 Changes are made to validate region version after the 
region

[agingade] GEODE-3796 Changes are made to validate region version after the 
region

--
[...truncated 117.01 KB...]
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/org/springframework/spring-expression/4.3.5.RELEASE/spring-expression-4.3.5.RELEASE.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/org/scala-lang/scala-reflect/2.10.6/scala-reflect-2.10.6.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/com/fasterxml/classmate/1.3.1/classmate-1.3.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/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
:geode-protobuf:javadocJar
:geode-protobuf:sourcesJar
:geode-protobuf:signArchives SKIPPED
:geode-pulse:javadoc
:geode-pulse:javadocJar
:geode-pulse:sourcesJar
:geode-pulse:war
:geode-pulse:signArchives SKIPPED
:geode-rebalancer:jar
:geode-rebalancer:javadoc
:geode-rebalancer:javadocJar
:geode-rebalancer:sourcesJar
:geode-rebalancer:signArchives SKIPPED
:geode-wan:jar
:geode-wan:javadoc
:geode-wan:javadocJar
:geode-wan:sourcesJar
:geode-wan:signArchives SKIPPED
:geode

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

2017-10-11 Thread Spring CI 

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

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





--
This message is automatically generated by Atlassian Bamboo

Thinking about a "Public API" module

2017-10-11 Thread Galen O'Sullivan 
Hi all,

I'm thinking about the possibility of making a "Geode public API" module,
mostly containing interfaces that Geode implements.

Why would one do this, you may ask? Here are some reasons.

* It makes clear what is our public API (as opposed to "internal" type
packages).
* Users only have to compile against the API package.
* Avoiding cyclic dependencies for modules that are internal parts of Geode.

For cyclic dependencies, consider the case of the geode-protobuf module. It
needs to be able to perform operations on the Cache and Locator, which
means it needs to depend on geode-core. We can't have cyclic dependencies,
so we have to use a ServiceLoader to get the service in core, which feels
like a bit of a hack. If geode-core could depend on the geode-protobuf
module, we could have a tighter connection, and not have to worry (as we
currently do) that anything we expose must be visible from core.[1]

Using ServiceLoader this way feels like a hack, because it's not really
something that we would expect a user to provide a service for, and we
can't handle the presence of more than one service. [2]

Maybe there's a better way to do this. Maybe Java 9 packages can make it
nicer. Maybe the ServiceLoader can be done better.

I'd like to solicit comment from the devs. What are your thoughts? What's
the best way to handle this? There are (AFAIK big, unanswered) questions
about how to handle varying levels of public vs. internal API [3]. Do you
have any answers?

Thanks,
Galen


[1] as an aside, it's actually kind of nice to have everything hidden from
core. It's resulted in an interface that creates an opaque object to manage
connection state, with a single `processMessage` method on it.
Nevertheless, other modules may with to expose more, and using
ServiceLoader feels like a hack.

[2] Actually, we do have to handle this case, and it's hard to do right,
because we have to blow up (abort the caller, throw a RuntimeException) or
ignore it and try to carry on (by closing connections made with the new
protocol). Blowing up breaks tests in geode-core, so we log a message, but
this maybe makes it easier to start up an incomplete cache

[3] Maybe we could have multiple packages, one stable for public API, one
internal (and potentially unstable) for things that are shared between
modules?

Re: Thinking about a "Public API" module

2017-10-11 Thread Jacob Barrett 
Yes! Do it! Even if it can’t be complete at this time because of strange 
dependencies we should start the effort. 

You might just start with some common use APIs like listeners and functions. At 
least in that case if all your hat is going to reference is functions and 
listeners you don’t have to pull in Geode-core.

-Jake



> On Oct 11, 2017, at 5:49 PM, Galen O'Sullivan  wrote:
> 
> Hi all,
> 
> I'm thinking about the possibility of making a "Geode public API" module,
> mostly containing interfaces that Geode implements.
> 
> Why would one do this, you may ask? Here are some reasons.
> 
> * It makes clear what is our public API (as opposed to "internal" type
> packages).
> * Users only have to compile against the API package.
> * Avoiding cyclic dependencies for modules that are internal parts of Geode.
> 
> For cyclic dependencies, consider the case of the geode-protobuf module. It
> needs to be able to perform operations on the Cache and Locator, which
> means it needs to depend on geode-core. We can't have cyclic dependencies,
> so we have to use a ServiceLoader to get the service in core, which feels
> like a bit of a hack. If geode-core could depend on the geode-protobuf
> module, we could have a tighter connection, and not have to worry (as we
> currently do) that anything we expose must be visible from core.[1]
> 
> Using ServiceLoader this way feels like a hack, because it's not really
> something that we would expect a user to provide a service for, and we
> can't handle the presence of more than one service. [2]
> 
> Maybe there's a better way to do this. Maybe Java 9 packages can make it
> nicer. Maybe the ServiceLoader can be done better.
> 
> I'd like to solicit comment from the devs. What are your thoughts? What's
> the best way to handle this? There are (AFAIK big, unanswered) questions
> about how to handle varying levels of public vs. internal API [3]. Do you
> have any answers?
> 
> Thanks,
> Galen
> 
> 
> [1] as an aside, it's actually kind of nice to have everything hidden from
> core. It's resulted in an interface that creates an opaque object to manage
> connection state, with a single `processMessage` method on it.
> Nevertheless, other modules may with to expose more, and using
> ServiceLoader feels like a hack.
> 
> [2] Actually, we do have to handle this case, and it's hard to do right,
> because we have to blow up (abort the caller, throw a RuntimeException) or
> ignore it and try to carry on (by closing connections made with the new
> protocol). Blowing up breaks tests in geode-core, so we log a message, but
> this maybe makes it easier to start up an incomplete cache
> 
> [3] Maybe we could have multiple packages, one stable for public API, one
> internal (and potentially unstable) for things that are shared between
> modules?

[Discuss] Geode gradle plugin

2017-10-11 Thread Jared Stewart 
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: 1.3.0 release

2017-10-11 Thread Swapnil Bawaskar 
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
 >>
 >>