[jira] [Created] (GEODE-2246) Invalid class cast in function execution

[Michael Dodge (JIRA)]

Michael Dodge created GEODE-2246:


 Summary: Invalid class cast in function execution
 Key: GEODE-2246
 URL: https://issues.apache.org/jira/browse/GEODE-2246
 Project: Geode
  Issue Type: Bug
  Components: functions
Reporter: Michael Dodge


In some situations (e.g., running a certain version of the native client 
quickstarts) a ClassCastException is thrown inside ExecuteFunction66.run() at 
line 391 of ExecuteFunction66.java:
final DistributionManager newDM = (DistributionManager) dm;

The variable dm is an instance of the interface 
org.apache.geode.distributed.internal.DM. The class 
org.apache.geode.distributed.internal.DistributionManager implements DM but not 
all implementers of DM extend DistributionManager, e.g., 
org.apache.geode.distributed.internal.LonerDistributionManager.



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

Build failed in Jenkins: Geode-nightly #698

[Apache Jenkins Server]

See 

--
[...truncated 587 lines...]
: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-junit:signArchives SKIPPED
:geode-junit:assemble
:geode-junit:compileTestJava
:geode-junit:processTestResources UP-TO-DATE
:geode-junit:testClasses
:geode-junit:checkMissedTests
:geode-junit:spotlessJavaCheck
:geode-junit:spotlessCheck
:geode-junit:test
:geode-junit:check
:geode-junit:build
:geode-junit:distributedTest
:geode-junit:flakyTest
:geode-junit:integrationTest
:geode-lucene:assemble
:geode-lucene: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-lucene:processTestResources
:geode-lucene:testClasses
:geode-lucene:checkMissedTests
:geode-lucene:spotlessJavaCheck
:geode-lucene:spotlessCheck
:geode-lucene:test
:geode-lucene:check
:geode-lucene:build
:geode-lucene:distributedTest
:geode-lucene:flakyTest
:geode-lucene:integrationTest
:geode-old-client-support:assemble
:geode-old-client-support:compileTestJava
:geode-old-client-support:processTestResources UP-TO-DATE
:geode-old-client-support:testClasses
:geode-old-client-support:checkMissedTests
:geode-old-client-support:spotlessJavaCheck
:geode-old-client-support:spotlessCheck
:geode-old-client-support:test
:geode-old-client-support:check
:geode-old-client-support:build
:geode-old-client-support:distributedTest
:geode-old-client-support:flakyTest
:geode-old-client-support:integrationTest
:geode-pulse:assemble
:geode-pulse:compileTestJavaNote: 

 uses or overrides 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-pulse:processTestResources
:geode-pulse:testClasses
:geode-pulse:checkMissedTests
:geode-pulse:spotlessJavaCheck
:geode-pulse:spotlessCheck
:geode-pulse:test
:geode-pulse:check
:geode-pulse:build
:geode-pulse:distributedTest
:geode-pulse:flakyTest
:geode-pulse:integrationTest
:geode-rebalancer:assemble
:geode-rebalancer:compileTestJava
:geode-rebalancer:processTestResources UP-TO-DATE
:geode-rebalancer:testClasses
:geode-rebalancer:checkMissedTests
:geode-rebalancer:spotlessJavaCheck
:geode-rebalancer:spotlessCheck
:geode-rebalancer:test
:geode-rebalancer:check
:geode-rebalancer:build
:geode-rebalancer:distributedTest
:geode-rebalancer:flakyTest
:geode-rebalancer:integrationTest
:geode-wan:assemble
:geode-wan: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-wan:processTestResources
:geode-wan:testClasses
:geode-wan:checkMissedTests
:geode-wan:spotlessJavaCheck
:geode-wan:spotlessCheck
:geode-wan:test
:geode-wan:check
:geode-wan:build
:geode-wan:distributedTest
:geode-wan:flakyTest
:geode-wan:integrationTest
:geode-web:assemble
:geode-web: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-web:processTestResources UP-TO-DATE
:geode-web:testClasses
:geode-web:checkMissedTests
:geode-web:spotlessJavaCheck
:geode-web:spotlessCheck
:geode-web:test
:geode-web:check
:geode-web:build
:geode-web:distributedTest
:geode-web:flakyTest
:geode-web:integrationTest
:geode-web-api:assemble
:geode-web-api:compileTestJava UP-TO-DATE
:geode-web-api:processTestResources UP-TO-DATE
:geode-web-api:testClasses UP-TO-DATE
:geode-web-api:checkMissedTests UP-TO-DATE
:geode-web-api:spotlessJavaCheck
:geode-web-api:spotlessCheck
:geode-web-api:test UP-

Re: Review Request 55017: cleaning up code in a few places

[Bruce Schuchardt]

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



bump - please review this diff

- Bruce Schuchardt


On Dec. 23, 2016, 6:10 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55017/
> ---
> 
> (Updated Dec. 23, 2016, 6:10 p.m.)
> 
> 
> Review request for geode, Galen O'Sullivan, Hitesh Khamesra, and Udo 
> Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> While investigating a couple of failures I ran across a few things that 
> needed to be fixed.
> 
> 1. EndpointManagerImpl was skipping notification of listeners if there was no 
> member ID in an endpoint but the member ID is no longer used.  I removed the 
> check.
> 2. During a Forced Disconnect CacheClientProxy was skipping a lot of clean-up 
> because it was expecting a CacheClosedException instead of a CancelException. 
>  We should never catch CacheClosedException - always catch CancelException.
> 3. When SSL is being used the P2P Reader Threads were not setting connection 
> attributes in the thread's name like we do with non-SSL reader threads.  This 
> made debugging an SSL failure a bit more difficult.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/internal/EndpointManagerImpl.java
>  6d5d9d689bab90895e8035b3055a2fb543b29f54 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/CacheClientProxy.java
>  6e31fe5488b64f9c5b4a4c867e72fc2c60e40591 
>   geode-core/src/main/java/org/apache/geode/internal/tcp/Connection.java 
> d44476f2f6f9387b390ea7e3758a057e43edef5a 
> 
> Diff: https://reviews.apache.org/r/55017/diff/
> 
> 
> Testing
> ---
> 
> precheckin, integration testing
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

[jira] [Created] (GEODE-2247) GFSH over HTTP succeeds without authentication

[Ben Moss (JIRA)]

Ben Moss created GEODE-2247:
---

 Summary: GFSH over HTTP succeeds without authentication
 Key: GEODE-2247
 URL: https://issues.apache.org/jira/browse/GEODE-2247
 Project: Geode
  Issue Type: Bug
  Components: gfsh
Reporter: Ben Moss


With a SecurityManager configured and using GFSH over http, issuing a 
{{connect}} command without {{--user}} or {{--password}} will appear to 
succeed, responding with {{Successfully connected to: GemFire Manager HTTP 
service}}. However if you then try to do anything in this session you will get 
an error {{Could not process command due to GemFire error. Error while 
processing command  Reason : Error: Anonymous User}}.

It seems like it should fail on the {{connect}}.



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

[jira] [Created] (GEODE-2248) DLock unit test code coverage is poor

[Bruce Schuchardt (JIRA)]

Bruce Schuchardt created GEODE-2248:
---

 Summary: DLock unit test code coverage is poor
 Key: GEODE-2248
 URL: https://issues.apache.org/jira/browse/GEODE-2248
 Project: Geode
  Issue Type: Bug
  Components: distributed lock service
Reporter: Bruce Schuchardt


Distributed Lock Service unit test code coverage needs to be improved.  While 
some classes have decent coverage others have little or no coverage.  
DLockQueryProcessor, for instance, has 0% coverage along with 
DeposeGrantorProcessor DistributedMemberLock and DLockRemoteToken.



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

[jira] [Updated] (GEODE-2248) DLock unit test code coverage is poor

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt updated GEODE-2248:

Attachment: dlockCodeCoverage.jpg

Here is an IntelliJ report of code coverage from the distributedLockTests unit 
test category.

> DLock unit test code coverage is poor
> -
>
> Key: GEODE-2248
> URL: https://issues.apache.org/jira/browse/GEODE-2248
> Project: Geode
>  Issue Type: Bug
>  Components: distributed lock service
>Reporter: Bruce Schuchardt
> Attachments: dlockCodeCoverage.jpg
>
>
> Distributed Lock Service unit test code coverage needs to be improved.  While 
> some classes have decent coverage others have little or no coverage.  
> DLockQueryProcessor, for instance, has 0% coverage along with 
> DeposeGrantorProcessor DistributedMemberLock and DLockRemoteToken.



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

[jira] [Created] (GEODE-2249) GFSH should validate arguments

[Ben Moss (JIRA)]

Ben Moss created GEODE-2249:
---

 Summary: GFSH should validate arguments
 Key: GEODE-2249
 URL: https://issues.apache.org/jira/browse/GEODE-2249
 Project: Geode
  Issue Type: Improvement
  Components: gfsh
Reporter: Ben Moss


gfsh will right now happily let you use invalid arguments and just ignore them. 
It would be helpful if it would error when a user provides an unsupported 
argument, since the user probably thinks that these arguments are supposed to 
do something. 

Just as an example I encountered, if you try to use {{connect}} with 
{{--username}} instead of {{--user}}, it will apparently succeed because of 
GEODE-2247, but actually will be using anonymous authentication since you did 
not pass a {{--user}} argument.



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

[jira] [Created] (GEODE-2250) gfsh -e connect will throw java.lang.StackOverflowError rather than prompt for username/password

[Ben Moss (JIRA)]

Ben Moss created GEODE-2250:
---

 Summary: gfsh -e connect will throw java.lang.StackOverflowError 
rather than prompt for username/password
 Key: GEODE-2250
 URL: https://issues.apache.org/jira/browse/GEODE-2250
 Project: Geode
  Issue Type: Bug
  Components: gfsh
Reporter: Ben Moss


If I try to connect to my distributed system using gfsh via the {{-e}} flag, 
but fail to provide the username and password required since my cluster is 
configured to use a SecurityManager, I get a java.lang.StackOverflowError.

It seems that 
{{org.apache.geode.management.internal.cli.commands.ShellCommands.jmxConnect}} 
calls itself recursively and eventually blows through the stack.



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

Re: Strategy for Updating Public API Changes

[Anthony Baker]

I agree with Darrel.  I’m not a big fan of the current Fn API for a variety of 
reasons, not least of which is the annoyingly inconsistent use of generics that 
Ayssa was trying to fix.  

I think a newer take on this API should include support for lambdas and Stream 
/ Reactive patterns.

Anthony

> On Dec 23, 2016, at 11:37 AM, Darrel Schneider  wrote:
> 
> If changing an external API would break existing applications I think it
> would be better to introduce a new API that has the improved behavior.
> Deprecate the old external API with a comment saying that you should use
> the new one instead. Then in the next release we can remove the old
> external deprecated API since users had a release to switch to the new one.
> 
> 
> On Thu, Dec 22, 2016 at 6:57 PM, Alyssa Kim  wrote:
> 
>> Hi,
>> 
>> Related Jira : https://issues.apache.org/jira/browse/GEODE-1577
>> 
>> Summary : Replacing wildcards with generic types requires changes in
>> applications that use this method. Probably there are other jiras that
>> update public APIs too. How do we to handle this?
>> 1. Just update the API whenever it's completed.
>> 2. Wait until a significant number of API changes are made and update at
>> once.
>> 3. Other ideas
>> 
>> Description:
>> 
>> We have GEODE-1577 in which we replaced wildcard return types of execute
>> method with generic types. This will break the existing applications that
>> use this method at the compilation level which is what happens every time
>> we update a public API. So, it is suggested that "we might want to tackle
>> all the function API improvements at once" to minimize complexity of
>> updates.
>> 
>>  If we do want to update all the function APIs at once, I believe we need
>> a list of all APIs that are expected to be updated and put on hold for
>> dev-completed jiras related to public API chenages until most of them are
>> ready to be updated. (probably somebody has to keep the track of those
>> issues via jira tag or label)
>> 
>> Alternatively, if anyone has a good strategy to handle this (or if there
>> is already one), please let me know.
>> 
>> 
>> Best Regards,
>> Alyssa Kim
>> 

Re: Strategy for Updating Public API Changes

[Anthony Baker]

I agree with Darrel.  I’m not a big fan of the current Fn API for a variety
of reasons, not least of which is the annoyingly inconsistent use of
generics that Ayssa was trying to fix.

I think a newer take on this API should include support for lambdas and
Stream / Reactive patterns.

Anthony

On Dec 23, 2016, at 11:37 AM, Darrel Schneider 
wrote:

If changing an external API would break existing applications I think it
would be better to introduce a new API that has the improved behavior.
Deprecate the old external API with a comment saying that you should use
the new one instead. Then in the next release we can remove the old
external deprecated API since users had a release to switch to the new one.


On Thu, Dec 22, 2016 at 6:57 PM, Alyssa Kim  wrote:

Hi,

Related Jira : https://issues.apache.org/jira/browse/GEODE-1577

Summary : Replacing wildcards with generic types requires changes in
applications that use this method. Probably there are other jiras that
update public APIs too. How do we to handle this?
1. Just update the API whenever it's completed.
2. Wait until a significant number of API changes are made and update at
once.
3. Other ideas

Description:

We have GEODE-1577 in which we replaced wildcard return types of execute
method with generic types. This will break the existing applications that
use this method at the compilation level which is what happens every time
we update a public API. So, it is suggested that "we might want to tackle
all the function API improvements at once" to minimize complexity of
updates.

 If we do want to update all the function APIs at once, I believe we need
a list of all APIs that are expected to be updated and put on hold for
dev-completed jiras related to public API chenages until most of them are
ready to be updated. (probably somebody has to keep the track of those
issues via jira tag or label)

Alternatively, if anyone has a good strategy to handle this (or if there
is already one), please let me know.


Best Regards,
Alyssa Kim

[jira] [Commented] (GEODE-165) Add build support for generating antlr classes from grammar

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt commented on GEODE-165:


IntelliJ Idea 2016.3.1 builds are broken by this change.  A workaround is to do 
a command-line build to have the generated-source files be created.

> Add build support for generating antlr classes from grammar
> ---
>
> Key: GEODE-165
> URL: https://issues.apache.org/jira/browse/GEODE-165
> Project: Geode
>  Issue Type: Bug
>  Components: build
>Reporter: Dan Smith
>Assignee: Avinash Dongre
>
> The OQL engine currently uses antlr to generate some parsing classes from 
> gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/parse/oql.g
> These are the generated classes. They are currently checked into the source.
> OQLLexer.java
> OQLLexerTokenTypes.java
> OQLLexerTokenTypes.txt
> OQLParser.java
> They can be generated manually by running antlr.Tool on the provided grammar.
> cd gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/parse/
> java -cp antlr.jar antlr.Tool oql.g
> We should add support to the gradle build to generate these classes.
> In my opinion we should also remove the checked in classes. With gradle we 
> can configure things so that the gradle eclipse target will generate these 
> classes and make them available to the IDE as well. Look at 
> gemfire-core/build.gradle for how we do this with the version properties file:
> sourceSets {
>   main {
> output.dir(generatedResources, builtBy: 'createVersionPropertiesFile')
>   }
> }



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

[jira] [Comment Edited] (GEODE-165) Add build support for generating antlr classes from grammar

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt edited comment on GEODE-165 at 12/27/16 7:24 PM:
--

IntelliJ Idea 2016.3.1 builds are broken by this change.  You must close your 
project and re-import the gradle build to fix the problem.  A workaround is to 
generate the absent source files with gradle.


was (Author: bschuchardt):
IntelliJ Idea 2016.3.1 builds are broken by this change.  A workaround is to do 
a command-line build to have the generated-source files be created.

> Add build support for generating antlr classes from grammar
> ---
>
> Key: GEODE-165
> URL: https://issues.apache.org/jira/browse/GEODE-165
> Project: Geode
>  Issue Type: Bug
>  Components: build
>Reporter: Dan Smith
>Assignee: Avinash Dongre
>
> The OQL engine currently uses antlr to generate some parsing classes from 
> gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/parse/oql.g
> These are the generated classes. They are currently checked into the source.
> OQLLexer.java
> OQLLexerTokenTypes.java
> OQLLexerTokenTypes.txt
> OQLParser.java
> They can be generated manually by running antlr.Tool on the provided grammar.
> cd gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/parse/
> java -cp antlr.jar antlr.Tool oql.g
> We should add support to the gradle build to generate these classes.
> In my opinion we should also remove the checked in classes. With gradle we 
> can configure things so that the gradle eclipse target will generate these 
> classes and make them available to the IDE as well. Look at 
> gemfire-core/build.gradle for how we do this with the version properties file:
> sourceSets {
>   main {
> output.dir(generatedResources, builtBy: 'createVersionPropertiesFile')
>   }
> }



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

IntelliJ builds broken looking for OQLLexerTokenTypes.java

[Bruce Schuchardt]

I did a pull today on my Windows 7 laptop and my IntelliJ build started 
failing with compilation errors looking for "OQLLexerTokenTypes".  This 
comes from the fix for GEODE-165. Refreshing the IntelliJ build 
structure picked up the antlr tasks needed to generate this and other 
OQL source files but IntelliJ would not execute them.


You either need to do a command-line build or close your IntelliJ 
project and import the gradle build into a new IntelliJ project.

Re: IntelliJ builds broken looking for OQLLexerTokenTypes.java

[Dan Smith]

Refreshing your project from gradle ought to work to. Eclipse users will
probably need to run ./gradlew eclipse and refresh their eclipse project.
There is a new generated-src directory that needs to be on the source path.

-Dan

On Tue, Dec 27, 2016 at 11:28 AM, Bruce Schuchardt 
wrote:

> I did a pull today on my Windows 7 laptop and my IntelliJ build started
> failing with compilation errors looking for "OQLLexerTokenTypes".  This
> comes from the fix for GEODE-165. Refreshing the IntelliJ build structure
> picked up the antlr tasks needed to generate this and other OQL source
> files but IntelliJ would not execute them.
>
> You either need to do a command-line build or close your IntelliJ project
> and import the gradle build into a new IntelliJ project.
>

Re: Review Request 55017: cleaning up code in a few places

[Udo Kohlmeyer]

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


Ship it!




Ship It!

- Udo Kohlmeyer


On Dec. 23, 2016, 6:10 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55017/
> ---
> 
> (Updated Dec. 23, 2016, 6:10 p.m.)
> 
> 
> Review request for geode, Galen O'Sullivan, Hitesh Khamesra, and Udo 
> Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> While investigating a couple of failures I ran across a few things that 
> needed to be fixed.
> 
> 1. EndpointManagerImpl was skipping notification of listeners if there was no 
> member ID in an endpoint but the member ID is no longer used.  I removed the 
> check.
> 2. During a Forced Disconnect CacheClientProxy was skipping a lot of clean-up 
> because it was expecting a CacheClosedException instead of a CancelException. 
>  We should never catch CacheClosedException - always catch CancelException.
> 3. When SSL is being used the P2P Reader Threads were not setting connection 
> attributes in the thread's name like we do with non-SSL reader threads.  This 
> made debugging an SSL failure a bit more difficult.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/internal/EndpointManagerImpl.java
>  6d5d9d689bab90895e8035b3055a2fb543b29f54 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/CacheClientProxy.java
>  6e31fe5488b64f9c5b4a4c867e72fc2c60e40591 
>   geode-core/src/main/java/org/apache/geode/internal/tcp/Connection.java 
> d44476f2f6f9387b390ea7e3758a057e43edef5a 
> 
> Diff: https://reviews.apache.org/r/55017/diff/
> 
> 
> Testing
> ---
> 
> precheckin, integration testing
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

Re: IntelliJ builds broken looking for OQLLexerTokenTypes.java

[Bruce Schuchardt]

Actually neither refreshing from gradle nor creating a new Intellij 
project worked.  I had to go to the "other" tasks under geode-core in 
the Gradle window and set "generateGrammarSource" to run before building.


Le 12/27/2016 à 11:54 AM, Dan Smith a écrit :

Refreshing your project from gradle ought to work to. Eclipse users will
probably need to run ./gradlew eclipse and refresh their eclipse project.
There is a new generated-src directory that needs to be on the source path.

-Dan

On Tue, Dec 27, 2016 at 11:28 AM, Bruce Schuchardt 
wrote:


I did a pull today on my Windows 7 laptop and my IntelliJ build started
failing with compilation errors looking for "OQLLexerTokenTypes".  This
comes from the fix for GEODE-165. Refreshing the IntelliJ build structure
picked up the antlr tasks needed to generate this and other OQL source
files but IntelliJ would not execute them.

You either need to do a command-line build or close your IntelliJ project
and import the gradle build into a new IntelliJ project.

Re: IntelliJ builds broken looking for OQLLexerTokenTypes.java

[Udo Kohlmeyer]

I had the same problem. gradle clean build did the trick for me


On 12/27/16 13:45, Bruce Schuchardt wrote:
Actually neither refreshing from gradle nor creating a new Intellij 
project worked.  I had to go to the "other" tasks under geode-core in 
the Gradle window and set "generateGrammarSource" to run before building.


Le 12/27/2016 à 11:54 AM, Dan Smith a écrit :

Refreshing your project from gradle ought to work to. Eclipse users will
probably need to run ./gradlew eclipse and refresh their eclipse 
project.
There is a new generated-src directory that needs to be on the source 
path.


-Dan

On Tue, Dec 27, 2016 at 11:28 AM, Bruce Schuchardt 


wrote:


I did a pull today on my Windows 7 laptop and my IntelliJ build started
failing with compilation errors looking for "OQLLexerTokenTypes".  This
comes from the fix for GEODE-165. Refreshing the IntelliJ build 
structure

picked up the antlr tasks needed to generate this and other OQL source
files but IntelliJ would not execute them.

You either need to do a command-line build or close your IntelliJ 
project

and import the gradle build into a new IntelliJ project.

[jira] [Comment Edited] (GEODE-165) Add build support for generating antlr classes from grammar

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt edited comment on GEODE-165 at 12/27/16 10:11 PM:
---

IntelliJ Idea 2016.3.1 builds are broken by this change.  After refreshing your 
project structure from Gradle you must set the 
geode-core:other:generateGrammarSources task to run before building.

A workaround is to generate the absent source files with gradle.


was (Author: bschuchardt):
IntelliJ Idea 2016.3.1 builds are broken by this change.  You must close your 
project and re-import the gradle build to fix the problem.  A workaround is to 
generate the absent source files with gradle.

> Add build support for generating antlr classes from grammar
> ---
>
> Key: GEODE-165
> URL: https://issues.apache.org/jira/browse/GEODE-165
> Project: Geode
>  Issue Type: Bug
>  Components: build
>Reporter: Dan Smith
>Assignee: Avinash Dongre
>
> The OQL engine currently uses antlr to generate some parsing classes from 
> gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/parse/oql.g
> These are the generated classes. They are currently checked into the source.
> OQLLexer.java
> OQLLexerTokenTypes.java
> OQLLexerTokenTypes.txt
> OQLParser.java
> They can be generated manually by running antlr.Tool on the provided grammar.
> cd gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/parse/
> java -cp antlr.jar antlr.Tool oql.g
> We should add support to the gradle build to generate these classes.
> In my opinion we should also remove the checked in classes. With gradle we 
> can configure things so that the gradle eclipse target will generate these 
> classes and make them available to the IDE as well. Look at 
> gemfire-core/build.gradle for how we do this with the version properties file:
> sourceSets {
>   main {
> output.dir(generatedResources, builtBy: 'createVersionPropertiesFile')
>   }
> }



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

[jira] [Resolved] (GEODE-2212) gfsh http authentication fails when routed through a proxy

[Anthony Baker (JIRA)]

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

Anthony Baker resolved GEODE-2212.
--
   Resolution: Fixed
Fix Version/s: 1.1.0

> gfsh http authentication fails when routed through a proxy
> --
>
> Key: GEODE-2212
> URL: https://issues.apache.org/jira/browse/GEODE-2212
> Project: Geode
>  Issue Type: Bug
>  Components: core, gfsh
>Reporter: Ben Moss
> Fix For: 1.1.0
>
>
> We encountered a bug with Geode that only reveals itself when routing 
> requests through the a proxy that modifies HTTP headers to standardize them 
> in title case format.
> gfsh uses the security-username and security-password headers to pass 
> authentication credentials to the locator, but what we saw is that when these 
> go through our proxy and are turned into Security-Username / 
> Security-Password, we can no longer authenticate.
> This request emulates what gfsh executes when you run "list members" with an 
> HTTP connection:
> {code:none}
> curl http://$LOCATOR_IP/gemfire/v1/members -H "security-username: admin" -H 
> "security-password: admin"
> {code}
> This request emulates what gets sent when going through our proxy. This 
> should be the same but will fail:
> {code:none}
> curl http://$LOCATOR_IP/gemfire/v1/members -H "Security-Username: admin" -H 
> "Security-Password: admin"
> {code}
> We narrowed the bug down to [these 
> lines|https://github.com/apache/geode/blob/bd229d7681376a11ba2e37747e48844ffe65584c/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/support/LoginHandlerInterceptor.java#L99-L111].
>  The HTTP spec specifies that headers should treated as case-insensitive but 
> it looks like Geode is only capable of working with lower-case versions of 
> these headers.



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

[jira] [Resolved] (GEODE-2209) Only 16 GatewaySenders are supported

[Anthony Baker (JIRA)]

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

Anthony Baker resolved GEODE-2209.
--
   Resolution: Fixed
Fix Version/s: 1.1.0

> Only 16 GatewaySenders are supported
> 
>
> Key: GEODE-2209
> URL: https://issues.apache.org/jira/browse/GEODE-2209
> Project: Geode
>  Issue Type: Improvement
>  Components: wan
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
> Fix For: 1.1.0
>
>
> If java assertions are enabled, attempting to use a 17th {{GatewaySender}}, 
> throws this {{AssertionError}}:
> {noformat}
> [severe 2016/12/13 15:58:08.456 PST gateway-ln-1  60712 Thread 0> tid=0x440] Server connection from 
> [identity(192.168.2.10(client:39966:loner):61377:e4369ffa:client,connection=2;
>  port=61377] : Unexpected Error on server
> java.lang.AssertionError
>   at 
> org.apache.geode.internal.cache.ha.ThreadIdentifier$Bits.shift(ThreadIdentifier.java:126)
>   at 
> org.apache.geode.internal.cache.ha.ThreadIdentifier$WanType.generateWanId(ThreadIdentifier.java:74)
>   at 
> org.apache.geode.internal.cache.ha.ThreadIdentifier.createFakeThreadIDForParallelGSPrimaryBucket(ThreadIdentifier.java:284)
>   at 
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderImpl.setModifiedEventId(SerialGatewaySenderImpl.java:248)
>   at 
> org.apache.geode.internal.cache.wan.AbstractGatewaySender.distribute(AbstractGatewaySender.java:849)
>   at 
> org.apache.geode.internal.cache.LocalRegion.notifyGatewaySender(LocalRegion.java:6367)
>   at 
> org.apache.geode.internal.cache.LocalRegion.basicPutPart2(LocalRegion.java:5909)
>   at 
> org.apache.geode.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:2800)
>   at 
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5750)
>   at 
> org.apache.geode.internal.cache.DistributedRegion.virtualPut(DistributedRegion.java:337)
>   at 
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:151)
>   at 
> org.apache.geode.internal.cache.LocalRegion.basicUpdate(LocalRegion.java:5730)
>   at 
> org.apache.geode.internal.cache.LocalRegion.basicBridgePut(LocalRegion.java:5374)
>   at 
> org.apache.geode.internal.cache.tier.sockets.command.Put65.cmdExecute(Put65.java:381)
>   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:777)
>   at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:908)
>   at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1165)
>   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)
> {noformat}



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

[jira] [Created] (GEODE-2251) Statistics Interface/Implementation graphic needs improvement

[Dave Barnes (JIRA)]

Dave Barnes created GEODE-2251:
--

 Summary: Statistics Interface/Implementation graphic needs 
improvement
 Key: GEODE-2251
 URL: https://issues.apache.org/jira/browse/GEODE-2251
 Project: Geode
  Issue Type: Improvement
  Components: docs
Reporter: Dave Barnes


Graphic 'statistics-1.gif' in 
http://geode.apache.org/docs/guide/managing/statistics/application_defined_statistics.html
 contains two diagrams and explanatory text for each. Graphic resolution is 
poor and type is difficult to read.
Redraw diagrams and move explanations to body text.



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

[jira] [Updated] (GEODE-2251) Statistics Interface/Implementation graphic needs improvement

[Dave Barnes (JIRA)]

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

Dave Barnes updated GEODE-2251:
---
Priority: Minor  (was: Major)

> Statistics Interface/Implementation graphic needs improvement
> -
>
> Key: GEODE-2251
> URL: https://issues.apache.org/jira/browse/GEODE-2251
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Priority: Minor
>
> Graphic 'statistics-1.gif' in 
> http://geode.apache.org/docs/guide/managing/statistics/application_defined_statistics.html
>  contains two diagrams and explanatory text for each. Graphic resolution is 
> poor and type is difficult to read.
> Redraw diagrams and move explanations to body text.



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

[jira] [Assigned] (GEODE-2251) Statistics Interface/Implementation graphic needs improvement

[Dave Barnes (JIRA)]

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

Dave Barnes reassigned GEODE-2251:
--

Assignee: Dave Barnes

> Statistics Interface/Implementation graphic needs improvement
> -
>
> Key: GEODE-2251
> URL: https://issues.apache.org/jira/browse/GEODE-2251
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Minor
>
> Graphic 'statistics-1.gif' in 
> http://geode.apache.org/docs/guide/managing/statistics/application_defined_statistics.html
>  contains two diagrams and explanatory text for each. Graphic resolution is 
> poor and type is difficult to read.
> Redraw diagrams and move explanations to body text.



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

[jira] [Resolved] (GEODE-2192) NPE in GMSLocator

[Anthony Baker (JIRA)]

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

Anthony Baker resolved GEODE-2192.
--
   Resolution: Fixed
Fix Version/s: 1.1.0

> NPE in GMSLocator
> -
>
> Key: GEODE-2192
> URL: https://issues.apache.org/jira/browse/GEODE-2192
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Hitesh Khamesra
> Fix For: 1.1.0
>
>
> 22999-1: [severe 2016/12/07 16:36:20.976 EST 
> locatorgemfire2_rs-intTest-rhel7-20
> 16-12-07-21-14-10-client-2_22999  tid=0x18] 
> Exception
>  in processing request from 10.32.111.110
> java.lang.NullPointerException
> at 
> java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1011)
> at 
> java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1006)
> at 
> org.apache.geode.distributed.internal.membership.gms.locator.GMSLocator.processRequest(GMSLocator.java:192)
> at 
> org.apache.geode.distributed.internal.InternalLocator$PrimaryHandler.processRequest(InternalLocator.java:1328)
> at 
> org.apache.geode.distributed.internal.tcpserver.TcpServer$3.run(TcpServer.java:411)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)



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

[jira] [Created] (GEODE-2252) Remove doc reference to too-old vmware guide

[Karen Smoler Miller (JIRA)]

Karen Smoler Miller created GEODE-2252:
--

 Summary: Remove doc reference to too-old vmware guide
 Key: GEODE-2252
 URL: https://issues.apache.org/jira/browse/GEODE-2252
 Project: Geode
  Issue Type: Improvement
  Components: docs
Reporter: Karen Smoler Miller


The docs section on Performance Tuning discusses running on vSphere. That 
documentation may still be relevant, but the end of the section has a link to 
very old and no-longer-relevant documentation. So, remove the link.

At the same time, update the Geode book subnav to not reference subsections  
distinguished by anchors, as this causes the subnav to misbehave.



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

[jira] [Commented] (GEODE-2153) PostProcessor security

[Anthony Baker (JIRA)]

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

Anthony Baker commented on GEODE-2153:
--

Can this ticket be closed?  I don't think that we can expect the 
{{PostProcessor}} to be used for field-level security.

> PostProcessor security
> --
>
> Key: GEODE-2153
> URL: https://issues.apache.org/jira/browse/GEODE-2153
> Project: Geode
>  Issue Type: Improvement
>  Components: security
>Reporter: Jared Stewart
>
> I have started a server and locator using the sample RedactingPostProcessor 
> implementation.  I created a /customers region and inserted a Customer: 
> {code}
>  Region region = connectToRegion("customers");
> Customer customer = new Customer(1L, "FirstName", "LastName", "123-456-7890");
> region.put("galen", customer);
> {code}
> The following query and get operation show our customer's SSN getting 
> redacted as expected:
> {code}
> Customer customerFromGet = region.get("galen"); 
> //{ type = com.jaredjstewart.Customer, customerId = 1, firstName = FirstName, 
> lastName = LastName, ssn = ** }
> Object customerFromQuery = queryService.newQuery("select * from 
> /customers").execute();
> //{ type = com.jaredjstewart.Customer, customerId = 1, firstName = FirstName, 
> lastName = LastName, ssn = ** }
> {code}
> However, it is possible to leak information by accessing the field which is 
> supposed to be redacted in a where clause:
> {code}
>  Object customer = queryService.newQuery("select c from /customers c 
> where c.socialSecurityNumber='123-456-7890'").execute();
>  //this redacts but still leaks the vital information
> {code}
> It is also possible to query the field directly:
> {code}
> Object customerSSN = queryService.newQuery("select c.socialSecurityNumber 
> from /customers c").execute();
> //[123-456-7890]
> {code}



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

[jira] [Updated] (GEODE-2150) Gfsh error output is invisible on Windows powershell

[Anthony Baker (JIRA)]

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

Anthony Baker updated GEODE-2150:
-
Summary: Gfsh error output is invisible on Windows powershell  (was: Gfsh 
error output is invisible on Windows)

> Gfsh error output is invisible on Windows powershell
> 
>
> Key: GEODE-2150
> URL: https://issues.apache.org/jira/browse/GEODE-2150
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Jared Stewart
>
> In Windows server 2012 powershell, gfsh error output is invisible under the 
> default color scheme.  You have to select the apparently blank lines of 
> output and copy-paste them into a text editor in order to read the error 
> messages.  If you change the font color in powershell, it affects the normal 
> gfsh output but the error output is still invisible.



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

[jira] [Closed] (GEODE-2140) Docs: Remove 'incubator' references from website

[Anthony Baker (JIRA)]

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

Anthony Baker closed GEODE-2140.


> Docs: Remove 'incubator' references from website
> 
>
> Key: GEODE-2140
> URL: https://issues.apache.org/jira/browse/GEODE-2140
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> Remove 'incubator' references from website



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

[jira] [Resolved] (GEODE-2140) Docs: Remove 'incubator' references from website

[Anthony Baker (JIRA)]

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

Anthony Baker resolved GEODE-2140.
--
Resolution: Not A Problem

> Docs: Remove 'incubator' references from website
> 
>
> Key: GEODE-2140
> URL: https://issues.apache.org/jira/browse/GEODE-2140
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> Remove 'incubator' references from website



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

[jira] [Commented] (GEODE-2140) Docs: Remove 'incubator' references from website

[Anthony Baker (JIRA)]

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

Anthony Baker commented on GEODE-2140:
--

This has already been done.

> Docs: Remove 'incubator' references from website
> 
>
> Key: GEODE-2140
> URL: https://issues.apache.org/jira/browse/GEODE-2140
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> Remove 'incubator' references from website



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

[jira] [Updated] (GEODE-2252) Remove doc reference to too-old vmware guide

[Karen Smoler Miller (JIRA)]

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

Karen Smoler Miller updated GEODE-2252:
---
Description: 
The docs section on Performance Tuning discusses running on vSphere. That 
documentation may still be relevant, but the end of the section has a link to 
very old and no-longer-relevant documentation. So, remove the link.

At the same time, update the Geode book subnav to not reference subsections 
(within this performance tuning subsection) distinguished by anchors, as this 
causes the subnav to misbehave.

  was:
The docs section on Performance Tuning discusses running on vSphere. That 
documentation may still be relevant, but the end of the section has a link to 
very old and no-longer-relevant documentation. So, remove the link.

At the same time, update the Geode book subnav to not reference subsections  
distinguished by anchors, as this causes the subnav to misbehave.


> Remove doc reference to too-old vmware guide
> 
>
> Key: GEODE-2252
> URL: https://issues.apache.org/jira/browse/GEODE-2252
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Karen Smoler Miller
>
> The docs section on Performance Tuning discusses running on vSphere. That 
> documentation may still be relevant, but the end of the section has a link to 
> very old and no-longer-relevant documentation. So, remove the link.
> At the same time, update the Geode book subnav to not reference subsections 
> (within this performance tuning subsection) distinguished by anchors, as this 
> causes the subnav to misbehave.



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

[jira] [Resolved] (GEODE-1909) A user with no privilege can start a server

[Anthony Baker (JIRA)]

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

Anthony Baker resolved GEODE-1909.
--
   Resolution: Fixed
Fix Version/s: 1.0.0-incubating

> A user with no privilege can start a server
> ---
>
> Key: GEODE-1909
> URL: https://issues.apache.org/jira/browse/GEODE-1909
> Project: Geode
>  Issue Type: Bug
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>  Labels: management
> Fix For: 1.0.0-incubating
>
> Attachments: security.json, security.properties, 
> serverSecurity.properties
>
>
> 1) Start the locator with a security-manager:
> start locator --name=loc1 --security-properties-file=security.properties 
> --classpath=/Users/jiliao/my_gemfire/security
> 2) connect to the locator using: guest/guest
> 3), try start a server as guest:
> start server --name=server1 
> --security-properties-file=serverSecurity.properties 
> --locators=localhost[10334]
> The server will be started.
> We should allow only user with CLUSTER:MANAGE permission to start a server.



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

[jira] [Closed] (GEODE-1909) A user with no privilege can start a server

[Anthony Baker (JIRA)]

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

Anthony Baker closed GEODE-1909.


> A user with no privilege can start a server
> ---
>
> Key: GEODE-1909
> URL: https://issues.apache.org/jira/browse/GEODE-1909
> Project: Geode
>  Issue Type: Bug
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>  Labels: management
> Fix For: 1.0.0-incubating
>
> Attachments: security.json, security.properties, 
> serverSecurity.properties
>
>
> 1) Start the locator with a security-manager:
> start locator --name=loc1 --security-properties-file=security.properties 
> --classpath=/Users/jiliao/my_gemfire/security
> 2) connect to the locator using: guest/guest
> 3), try start a server as guest:
> start server --name=server1 
> --security-properties-file=serverSecurity.properties 
> --locators=localhost[10334]
> The server will be started.
> We should allow only user with CLUSTER:MANAGE permission to start a server.



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

[jira] [Closed] (GEODE-1903) Update Website Community > Events

[Anthony Baker (JIRA)]

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

Anthony Baker closed GEODE-1903.


> Update Website Community > Events
> -
>
> Key: GEODE-1903
> URL: https://issues.apache.org/jira/browse/GEODE-1903
> Project: Geode
>  Issue Type: Task
>  Components: general
>Reporter: Joey McAllister
>
> Remove outdated entries; add:
> Geode Clubhouse: DDD, Reactor Programming and Apache Geode Panel wth Vaughn
> Vernon
> Virtual | Calendar entry
> 
> 9/21 - 9AM Pacific
> Geode Clubhouse: Update on Geode's New Security Infrastructure with Jinmei
> Liao
> Virtual | Calendar entry
> 
> 10/19 - 9AM Pacific



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

[jira] [Resolved] (GEODE-1903) Update Website Community > Events

[Anthony Baker (JIRA)]

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

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

> Update Website Community > Events
> -
>
> Key: GEODE-1903
> URL: https://issues.apache.org/jira/browse/GEODE-1903
> Project: Geode
>  Issue Type: Task
>  Components: general
>Reporter: Joey McAllister
>
> Remove outdated entries; add:
> Geode Clubhouse: DDD, Reactor Programming and Apache Geode Panel wth Vaughn
> Vernon
> Virtual | Calendar entry
> 
> 9/21 - 9AM Pacific
> Geode Clubhouse: Update on Geode's New Security Infrastructure with Jinmei
> Liao
> Virtual | Calendar entry
> 
> 10/19 - 9AM Pacific



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

[jira] [Commented] (GEODE-419) javax.net.ssl.* gemfire properties ignored if ssl-enabled is false

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-419:
---

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

GEODE-419: Added test to test that for ssl it fails over to javax properties.


> javax.net.ssl.* gemfire properties ignored if ssl-enabled is false
> --
>
> Key: GEODE-419
> URL: https://issues.apache.org/jira/browse/GEODE-419
> Project: Geode
>  Issue Type: Bug
>  Components: client/server, configuration, security
>Reporter: Darrel Schneider
>Assignee: Udo Kohlmeyer
>Priority: Minor
>
> You are supposed to be able to put javax.net.ssl.* system property 
> definitions in your gemfire.properties and have them be used to configure ssl.
> They work ok if ssl-enabled is true and cluster-ssl-enabled is not set. But 
> if you set cluster-ssl-enabled (to true or false) then the javax.net.ssl.* 
> properties are ignored. The same is also true for http-service-ssl-enabled.
> This can be worked around by using the new cluster-ssl-keystore* and 
> cluster-ssl-truststore* gemfire properties instead of javax.net.ssl.*.



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

Review Request 55059: GEODE-2252 Update docs on vSphere performance tuning

[Karen Miller]

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

Review request for geode, Dave Barnes and Joey McAllister.


Repository: geode


Description
---

GEODE-2252 Update docs on vSphere performance tuning


Diffs
-

  geode-book/master_middleman/source/subnavs/geode-subnav.erb 
cb77952e6ad54f9aa1d5acd9bcad74e522cace0d 
  geode-docs/managing/monitor_tune/chapter_overview.html.md.erb 
db099459c5ef98b8dd7a86f1cb1434611ef51aa1 
  geode-docs/managing/monitor_tune/gemfire_performance_on_vsphere.html.md.erb 
2be5502a4e10cc5aed25c99bfc16808fb450bd0c 
  
geode-docs/managing/monitor_tune/gemfire_performance_on_vsphere_guidelines.html.md.erb
 b5cb8a2af5857640cf653bc798d9b9ec4d1f26c9 

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


Testing
---

gradle rat check passes


Thanks,

Karen Miller

[jira] [Closed] (GEODE-1817) Disable artifact signing by default

[Anthony Baker (JIRA)]

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

Anthony Baker closed GEODE-1817.


> Disable artifact signing by default
> ---
>
> Key: GEODE-1817
> URL: https://issues.apache.org/jira/browse/GEODE-1817
> Project: Geode
>  Issue Type: Improvement
>  Components: build
>Reporter: Jens Deppe
> Fix For: 1.0.0-incubating
>
>
> Currently our CI pipeline is generating -SNAPSHOT releases. The nexus build 
> plugin, we are using, automatically detects `SNAPSHOT` in the version string 
> and does not attempt to sign those artifacts.
> We intend to change the pipeline to always be building 'release candidate' 
> versions and so signing would be required. As signing is currently a manual 
> process, this will be disabled by default.
> As an aside, the CI pipeline will still produce `SNAPSHOT` releases for each 
> successful build, however this step will be a rebuild with a `-SNAPSHOT` 
> version string against the SHA of the code passing the build.



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

[jira] [Resolved] (GEODE-1817) Disable artifact signing by default

[Anthony Baker (JIRA)]

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

Anthony Baker resolved GEODE-1817.
--
   Resolution: Fixed
Fix Version/s: 1.0.0-incubating

> Disable artifact signing by default
> ---
>
> Key: GEODE-1817
> URL: https://issues.apache.org/jira/browse/GEODE-1817
> Project: Geode
>  Issue Type: Improvement
>  Components: build
>Reporter: Jens Deppe
> Fix For: 1.0.0-incubating
>
>
> Currently our CI pipeline is generating -SNAPSHOT releases. The nexus build 
> plugin, we are using, automatically detects `SNAPSHOT` in the version string 
> and does not attempt to sign those artifacts.
> We intend to change the pipeline to always be building 'release candidate' 
> versions and so signing would be required. As signing is currently a manual 
> process, this will be disabled by default.
> As an aside, the CI pipeline will still produce `SNAPSHOT` releases for each 
> successful build, however this step will be a rebuild with a `-SNAPSHOT` 
> version string against the SHA of the code passing the build.



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

[jira] [Created] (GEODE-2253) Locator may fail to respond to a valid request

[Bruce Schuchardt (JIRA)]

Bruce Schuchardt created GEODE-2253:
---

 Summary: Locator may fail to respond to a valid request
 Key: GEODE-2253
 URL: https://issues.apache.org/jira/browse/GEODE-2253
 Project: Geode
  Issue Type: Bug
  Components: membership
Reporter: Bruce Schuchardt


When a locator is spinning up it may get a request from a peer process or a 
client process that it isn't ready to handle.  In some cases it will log a 
warning that it received a request of class C but is only configured to handle 
requests of classes X, Y or Z.   It ought to wait and retry for a little while 
for the service associated with class C to finish initializing.



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

[jira] [Commented] (GEODE-2253) Locator may fail to respond to a valid request

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt commented on GEODE-2253:
-

It should also _always_ respond to a request asking if it has a cluster 
configuration service.  It currently only installs a handler for such a request 
if it has a cluster configuration service.

> Locator may fail to respond to a valid request
> --
>
> Key: GEODE-2253
> URL: https://issues.apache.org/jira/browse/GEODE-2253
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
>
> When a locator is spinning up it may get a request from a peer process or a 
> client process that it isn't ready to handle.  In some cases it will log a 
> warning that it received a request of class C but is only configured to 
> handle requests of classes X, Y or Z.   It ought to wait and retry for a 
> little while for the service associated with class C to finish initializing.



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

[jira] [Resolved] (GEODE-1799) Javadocs should refer to CacheServer instead of BridgeServer

[Anthony Baker (JIRA)]

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

Anthony Baker resolved GEODE-1799.
--
   Resolution: Fixed
Fix Version/s: 1.1.0

> Javadocs should refer to CacheServer instead of BridgeServer
> 
>
> Key: GEODE-1799
> URL: https://issues.apache.org/jira/browse/GEODE-1799
> Project: Geode
>  Issue Type: Bug
>  Components: client/server, docs
>Reporter: Kirk Lund
>Priority: Trivial
>  Labels: javadocs
> Fix For: 1.1.0
>
>
> Javadocs should refer to CacheServer instead of BridgeServer.
> Example: Javadocs for CacheServerStats currently say "Bridge Server statistic 
> definitions"
> Update: Please leave this open until all instances of "bridge" are found and 
> replaced.



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

[jira] [Commented] (GEODE-1799) Javadocs should refer to CacheServer instead of BridgeServer

[Anthony Baker (JIRA)]

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

Anthony Baker commented on GEODE-1799:
--

I didn't find any remaining references to "Bridge Server", closing.

> Javadocs should refer to CacheServer instead of BridgeServer
> 
>
> Key: GEODE-1799
> URL: https://issues.apache.org/jira/browse/GEODE-1799
> Project: Geode
>  Issue Type: Bug
>  Components: client/server, docs
>Reporter: Kirk Lund
>Priority: Trivial
>  Labels: javadocs
> Fix For: 1.1.0
>
>
> Javadocs should refer to CacheServer instead of BridgeServer.
> Example: Javadocs for CacheServerStats currently say "Bridge Server statistic 
> definitions"
> Update: Please leave this open until all instances of "bridge" are found and 
> replaced.



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

[jira] [Commented] (GEODE-2251) Statistics Interface/Implementation graphic needs improvement

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2251:


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

GEODE-2251: Improve Statistics Interface/Implementation graphics


> Statistics Interface/Implementation graphic needs improvement
> -
>
> Key: GEODE-2251
> URL: https://issues.apache.org/jira/browse/GEODE-2251
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Minor
>
> Graphic 'statistics-1.gif' in 
> http://geode.apache.org/docs/guide/managing/statistics/application_defined_statistics.html
>  contains two diagrams and explanatory text for each. Graphic resolution is 
> poor and type is difficult to read.
> Redraw diagrams and move explanations to body text.



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

[jira] [Resolved] (GEODE-419) javax.net.ssl.* gemfire properties ignored if ssl-enabled is false

[Udo Kohlmeyer (JIRA)]

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

Udo Kohlmeyer resolved GEODE-419.
-
Resolution: Fixed

> javax.net.ssl.* gemfire properties ignored if ssl-enabled is false
> --
>
> Key: GEODE-419
> URL: https://issues.apache.org/jira/browse/GEODE-419
> Project: Geode
>  Issue Type: Bug
>  Components: client/server, configuration, security
>Reporter: Darrel Schneider
>Assignee: Udo Kohlmeyer
>Priority: Minor
>
> You are supposed to be able to put javax.net.ssl.* system property 
> definitions in your gemfire.properties and have them be used to configure ssl.
> They work ok if ssl-enabled is true and cluster-ssl-enabled is not set. But 
> if you set cluster-ssl-enabled (to true or false) then the javax.net.ssl.* 
> properties are ignored. The same is also true for http-service-ssl-enabled.
> This can be worked around by using the new cluster-ssl-keystore* and 
> cluster-ssl-truststore* gemfire properties instead of javax.net.ssl.*.



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

[jira] [Commented] (GEODE-1294) Overriding cluster-ssl properties does not work for http-service-ssl

[Anthony Baker (JIRA)]

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

Anthony Baker commented on GEODE-1294:
--

[~ukohlmeyer] Is this issue still valid?

> Overriding cluster-ssl properties does not work for http-service-ssl
> 
>
> Key: GEODE-1294
> URL: https://issues.apache.org/jira/browse/GEODE-1294
> Project: Geode
>  Issue Type: Bug
>  Components: security
>Reporter: Jens Deppe
>
> when {{cluster-ssl-require-authentication=true}} the following properties are 
> set:
> {noformat}
> cluster-ssl-require-authentication=true
> gateway-ssl-require-authentication=true
> http-service-ssl-require-authentication=true
> jmx-manager-ssl-require-authentication=true
> server-ssl-require-authentication=true
> {noformat}
> When that property is not set (i.e. just defaulted) and 
> {{cluster-ssl-enabled=true}} then only 
> {{http-service-ssl-require-authentication=false}} is set and all the other 
> {{require-authentication}} properties are {{true}}. With these settings, we 
> require mutual auth for all connections except Pulse and gfsh over http.
> However, if I set the following which should really be mimicking the default 
> settings for {{cluster-ssl-enabled=true}}:
> {noformat}
> cluster-ssl-require-authentication=true
> http-service-ssl-require-authentication=false
> {noformat}
> Then I am unable to access Pulse as it still appears to require mutual auth.



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

[jira] [Resolved] (GEODE-1151) Add new Geode committer Dave Barnes to web page

[Anthony Baker (JIRA)]

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

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

> Add new Geode committer Dave Barnes to web page
> ---
>
> Key: GEODE-1151
> URL: https://issues.apache.org/jira/browse/GEODE-1151
> Project: Geode
>  Issue Type: Task
>  Components: web-content
>Reporter: Karen Smoler Miller
>
> The community web page contains a list of committers. Dave Barnes is a new 
> committer, so it is time to add his name to the list.



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

[jira] [Closed] (GEODE-1151) Add new Geode committer Dave Barnes to web page

[Anthony Baker (JIRA)]

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

Anthony Baker closed GEODE-1151.


> Add new Geode committer Dave Barnes to web page
> ---
>
> Key: GEODE-1151
> URL: https://issues.apache.org/jira/browse/GEODE-1151
> Project: Geode
>  Issue Type: Task
>  Components: web-content
>Reporter: Karen Smoler Miller
>
> The community web page contains a list of committers. Dave Barnes is a new 
> committer, so it is time to add his name to the list.



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

[jira] [Closed] (GEODE-1132) Add a rat task to check @author tags.

[Anthony Baker (JIRA)]

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

Anthony Baker closed GEODE-1132.


> Add a rat task to check @author tags.
> -
>
> Key: GEODE-1132
> URL: https://issues.apache.org/jira/browse/GEODE-1132
> Project: Geode
>  Issue Type: Improvement
>  Components: build
>Reporter: Sai Boorlagadda
>
> This can help if IDE settings automatically adds author tags for any new or 
> modified files.



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

[jira] [Resolved] (GEODE-1132) Add a rat task to check @author tags.

[Anthony Baker (JIRA)]

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

Anthony Baker resolved GEODE-1132.
--
Resolution: Won't Fix

> Add a rat task to check @author tags.
> -
>
> Key: GEODE-1132
> URL: https://issues.apache.org/jira/browse/GEODE-1132
> Project: Geode
>  Issue Type: Improvement
>  Components: build
>Reporter: Sai Boorlagadda
>
> This can help if IDE settings automatically adds author tags for any new or 
> modified files.



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

[jira] [Resolved] (GEODE-993) Remove CRLF line endings from Pulse files

[Anthony Baker (JIRA)]

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

Anthony Baker resolved GEODE-993.
-
Resolution: Duplicate

> Remove CRLF line endings from Pulse files
> -
>
> Key: GEODE-993
> URL: https://issues.apache.org/jira/browse/GEODE-993
> Project: Geode
>  Issue Type: Improvement
>  Components: pulse
>Reporter: Jens Deppe
>
> Get rid of all of those ^Ms



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

[jira] [Closed] (GEODE-993) Remove CRLF line endings from Pulse files

[Anthony Baker (JIRA)]

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

Anthony Baker closed GEODE-993.
---

> Remove CRLF line endings from Pulse files
> -
>
> Key: GEODE-993
> URL: https://issues.apache.org/jira/browse/GEODE-993
> Project: Geode
>  Issue Type: Improvement
>  Components: pulse
>Reporter: Jens Deppe
>
> Get rid of all of those ^Ms



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

[jira] [Commented] (GEODE-880) Remove unused classes

[Anthony Baker (JIRA)]

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

Anthony Baker commented on GEODE-880:
-

Can this ticket be closed?

> Remove unused classes
> -
>
> Key: GEODE-880
> URL: https://issues.apache.org/jira/browse/GEODE-880
> Project: Geode
>  Issue Type: Wish
>  Components: general
>Reporter: Kirk Lund
>
> We would typically only keep unused classes if they were part of the user API 
> in a previous release.
> If an unused class is not required for backwards compatibility then it should 
> be deleted. This jira ticket lists unused classes that should be removed. If 
> you delete any of these classes, please add an appropriate comment and then 
> remove the class name from the ticket description.
> * geode-core/src/test/java/com/gemstone/gemfire/internal/JavaExec.java
> * geode-core/src/test/java/com/gemstone/gemfire/internal/LongBuffer.java



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

[jira] [Commented] (GEODE-1294) Overriding cluster-ssl properties does not work for http-service-ssl

[Udo Kohlmeyer (JIRA)]

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

Udo Kohlmeyer commented on GEODE-1294:
--

[~amb] Most likely not... but let me write a test to prove it.

> Overriding cluster-ssl properties does not work for http-service-ssl
> 
>
> Key: GEODE-1294
> URL: https://issues.apache.org/jira/browse/GEODE-1294
> Project: Geode
>  Issue Type: Bug
>  Components: security
>Reporter: Jens Deppe
>
> when {{cluster-ssl-require-authentication=true}} the following properties are 
> set:
> {noformat}
> cluster-ssl-require-authentication=true
> gateway-ssl-require-authentication=true
> http-service-ssl-require-authentication=true
> jmx-manager-ssl-require-authentication=true
> server-ssl-require-authentication=true
> {noformat}
> When that property is not set (i.e. just defaulted) and 
> {{cluster-ssl-enabled=true}} then only 
> {{http-service-ssl-require-authentication=false}} is set and all the other 
> {{require-authentication}} properties are {{true}}. With these settings, we 
> require mutual auth for all connections except Pulse and gfsh over http.
> However, if I set the following which should really be mimicking the default 
> settings for {{cluster-ssl-enabled=true}}:
> {noformat}
> cluster-ssl-require-authentication=true
> http-service-ssl-require-authentication=false
> {noformat}
> Then I am unable to access Pulse as it still appears to require mutual auth.



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

[jira] [Assigned] (GEODE-1294) Overriding cluster-ssl properties does not work for http-service-ssl

[Udo Kohlmeyer (JIRA)]

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

Udo Kohlmeyer reassigned GEODE-1294:


Assignee: Udo Kohlmeyer

> Overriding cluster-ssl properties does not work for http-service-ssl
> 
>
> Key: GEODE-1294
> URL: https://issues.apache.org/jira/browse/GEODE-1294
> Project: Geode
>  Issue Type: Bug
>  Components: security
>Reporter: Jens Deppe
>Assignee: Udo Kohlmeyer
>
> when {{cluster-ssl-require-authentication=true}} the following properties are 
> set:
> {noformat}
> cluster-ssl-require-authentication=true
> gateway-ssl-require-authentication=true
> http-service-ssl-require-authentication=true
> jmx-manager-ssl-require-authentication=true
> server-ssl-require-authentication=true
> {noformat}
> When that property is not set (i.e. just defaulted) and 
> {{cluster-ssl-enabled=true}} then only 
> {{http-service-ssl-require-authentication=false}} is set and all the other 
> {{require-authentication}} properties are {{true}}. With these settings, we 
> require mutual auth for all connections except Pulse and gfsh over http.
> However, if I set the following which should really be mimicking the default 
> settings for {{cluster-ssl-enabled=true}}:
> {noformat}
> cluster-ssl-require-authentication=true
> http-service-ssl-require-authentication=false
> {noformat}
> Then I am unable to access Pulse as it still appears to require mutual auth.



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

[jira] [Updated] (GEODE-1294) Overriding cluster-ssl properties does not work for http-service-ssl

[Udo Kohlmeyer (JIRA)]

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

Udo Kohlmeyer updated GEODE-1294:
-
Component/s: configuration
 client/server

> Overriding cluster-ssl properties does not work for http-service-ssl
> 
>
> Key: GEODE-1294
> URL: https://issues.apache.org/jira/browse/GEODE-1294
> Project: Geode
>  Issue Type: Bug
>  Components: client/server, configuration, security
>Reporter: Jens Deppe
>Assignee: Udo Kohlmeyer
>
> when {{cluster-ssl-require-authentication=true}} the following properties are 
> set:
> {noformat}
> cluster-ssl-require-authentication=true
> gateway-ssl-require-authentication=true
> http-service-ssl-require-authentication=true
> jmx-manager-ssl-require-authentication=true
> server-ssl-require-authentication=true
> {noformat}
> When that property is not set (i.e. just defaulted) and 
> {{cluster-ssl-enabled=true}} then only 
> {{http-service-ssl-require-authentication=false}} is set and all the other 
> {{require-authentication}} properties are {{true}}. With these settings, we 
> require mutual auth for all connections except Pulse and gfsh over http.
> However, if I set the following which should really be mimicking the default 
> settings for {{cluster-ssl-enabled=true}}:
> {noformat}
> cluster-ssl-require-authentication=true
> http-service-ssl-require-authentication=false
> {noformat}
> Then I am unable to access Pulse as it still appears to require mutual auth.



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

[jira] [Closed] (GEODE-118) Gradle dependencies do not follow repositories transitively

[Anthony Baker (JIRA)]

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

Anthony Baker closed GEODE-118.
---

> Gradle dependencies do not follow repositories transitively
> ---
>
> Key: GEODE-118
> URL: https://issues.apache.org/jira/browse/GEODE-118
> Project: Geode
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.0.0-incubating
> Environment: Gradle 2.2.1
> OS:   Mac OS X 10.9.5 x86_64
> JVM:  1.8.0_40 (Oracle Corporation 25.40-b25)
>Reporter: Joao Peixoto
>
> Using a very basic Gradle setup with dependency on 
> "org.springframework.data:spring-data-gemfire:1.7.0.APACHE-GEODE-EA-SNAPSHOT" 
> throw an exception:
> "java.lang.ClassNotFoundException: 
> com.gemstone.gemfire.internal.GemFireVersion"
> Note from [~jblum] on the mailing list: if using Gradle, know that Gradle has 
> some bizarre bug (bug #?) where "repos" are not transitively used to resolve 
> dependencies of dependencies. This is not an issue for Maven.
> https://gist.github.com/Hartimer/196b4fde7a00a05d7188



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

[jira] [Resolved] (GEODE-118) Gradle dependencies do not follow repositories transitively

[Anthony Baker (JIRA)]

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

Anthony Baker resolved GEODE-118.
-
Resolution: Works for Me

> Gradle dependencies do not follow repositories transitively
> ---
>
> Key: GEODE-118
> URL: https://issues.apache.org/jira/browse/GEODE-118
> Project: Geode
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.0.0-incubating
> Environment: Gradle 2.2.1
> OS:   Mac OS X 10.9.5 x86_64
> JVM:  1.8.0_40 (Oracle Corporation 25.40-b25)
>Reporter: Joao Peixoto
>
> Using a very basic Gradle setup with dependency on 
> "org.springframework.data:spring-data-gemfire:1.7.0.APACHE-GEODE-EA-SNAPSHOT" 
> throw an exception:
> "java.lang.ClassNotFoundException: 
> com.gemstone.gemfire.internal.GemFireVersion"
> Note from [~jblum] on the mailing list: if using Gradle, know that Gradle has 
> some bizarre bug (bug #?) where "repos" are not transitively used to resolve 
> dependencies of dependencies. This is not an issue for Maven.
> https://gist.github.com/Hartimer/196b4fde7a00a05d7188



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

[jira] [Updated] (GEODE-2175) CI failure from TopEntriesFunctionCollectorJUnitTest.expectErrorAfterWaitTime

[Anthony Baker (JIRA)]

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

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

> CI failure from TopEntriesFunctionCollectorJUnitTest.expectErrorAfterWaitTime
> -
>
> Key: GEODE-2175
> URL: https://issues.apache.org/jira/browse/GEODE-2175
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Dan Smith
>Assignee: xiaojian zhou
> Fix For: 1.1.0
>
>
> {noformat}
> org.apache.geode.cache.lucene.internal.distributed.TopEntriesFunctionCollectorJUnitTest
>  > expectErrorAfterWaitTime FAILED
> java.lang.Exception: Unexpected exception, 
> expected but 
> was
> Caused by:
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at 
> org.apache.geode.cache.lucene.internal.distributed.TopEntriesFunctionCollectorJUnitTest.expectErrorAfterWaitTime(TopEntriesFunctionCollectorJUnitTest.java:195)
> {noformat}
> Looking at this test, it looks like it's a race condition waiting to happen 
> because it does a bunch of 1 second awaits.
> I'm also suspicious of the functionality that is being tested here in the 
> first place. A user's result collector shouldn't have to contain logic to 
> wait for all of the results to be gather, that's handled by the function 
> execution framework. So the real fix may be to remove these tests and the 
> logic in TopEntriesFunctionCollector that waits for the results to be 
> gathered.



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

[jira] [Updated] (GEODE-2210) Session module class loader should check the thread context class loader

[Anthony Baker (JIRA)]

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

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

> Session module class loader should check the thread context class loader
> 
>
> Key: GEODE-2210
> URL: https://issues.apache.org/jira/browse/GEODE-2210
> Project: Geode
>  Issue Type: Bug
>  Components: http session
>Reporter: Jason Huynh
>Assignee: Jason Huynh
> Fix For: 1.1.0
>
>
> The current behavior uses Class.forName() to load classes.  There are cases 
> where the context class loader contains the class and are hidden from the top 
> level class loader.



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

[jira] [Updated] (GEODE-2228) FutureResult.get() does not check for cancellation prior to waiting for a result

[Anthony Baker (JIRA)]

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

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

> FutureResult.get()  does not check for cancellation prior to waiting for a 
> result
> -
>
> Key: GEODE-2228
> URL: https://issues.apache.org/jira/browse/GEODE-2228
> Project: Geode
>  Issue Type: Bug
>  Components: distributed lock service
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
> Fix For: 1.1.0
>
>
> A system was found hung with a thread in this state:
> {noformat}
> vm_0_bridge1_w1-gst-dev23_17330:ServerConnection on port 21566 Thread 352 
> ID=861 state=TIMED_WAITING
>   waiting to lock 
>   at sun.misc.Unsafe.park(Native Method)
>   at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1033)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1326)
>   at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:282)
>   at 
> com.gemstone.gemfire.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:55)
>   at 
> com.gemstone.gemfire.internal.util.concurrent.FutureResult.get(FutureResult.java:54)
>   at 
> com.gemstone.gemfire.distributed.internal.locks.DLockService.waitForLockGrantorFutureResult(DLockService.java:774)
>   at 
> com.gemstone.gemfire.distributed.internal.locks.DLockService.notLockGrantorId(DLockService.java:837)
>   at 
> com.gemstone.gemfire.distributed.internal.locks.DLockService.releaseTryLocks(DLockService.java:2216)
>   at 
> com.gemstone.gemfire.internal.cache.locks.TXLockServiceImpl.release(TXLockServiceImpl.java:222)
>   locked 
>   at 
> com.gemstone.gemfire.internal.cache.TXLockRequest.releaseDistributed(TXLockRequest.java:91)
>   at 
> com.gemstone.gemfire.internal.cache.TXLockRequest.cleanup(TXLockRequest.java:120)
>   at com.gemstone.gemfire.internal.cache.TXState.cleanup(TXState.java:730)
>   at com.gemstone.gemfire.internal.cache.TXState.commit(TXState.java:447)
>   at 
> com.gemstone.gemfire.internal.cache.TXStateProxyImpl.commit(TXStateProxyImpl.java:234)
>   at 
> com.gemstone.gemfire.internal.cache.TXManagerImpl.commit(TXManagerImpl.java:325)
> {noformat}
> No other threads were trying to find the lock grantor and further testing 
> showed that the FutureResult that this thread was using must have been 
> cancelled by another thread.  I wrote a unit test and found that FutureResult 
> is not respecting its cancelled state in its get() methods.



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

[jira] [Updated] (GEODE-2178) Docs: Update HTTP session management version numbers

[Anthony Baker (JIRA)]

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

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

> Docs: Update HTTP session management version numbers
> 
>
> Key: GEODE-2178
> URL: https://issues.apache.org/jira/browse/GEODE-2178
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Minor
> Fix For: 1.1.0
>
>
> User Manual section Tools andModules -> HTTP Session Management contains 
> outdated information regarding supported application servers and their 
> version numbers. Bring these up to date.



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

[jira] [Updated] (GEODE-2161) FilterRoutingInfo.FilterInfo.toData does unneeded copying

[Anthony Baker (JIRA)]

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

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

> FilterRoutingInfo.FilterInfo.toData does unneeded copying
> -
>
> Key: GEODE-2161
> URL: https://issues.apache.org/jira/browse/GEODE-2161
> Project: Geode
>  Issue Type: Bug
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
> Fix For: 1.1.0
>
>
> This is #52614
> FilterInfo.toData (that was being optimized for murex) does this:
> // create a hdos
> // write a bunch of stuff to it
> byte[] myData = hdos.toByteArray();
> DataSerializer.writeByteArray(myData, out);
> he toByteArray allocates a new byte array and copies all the data in the hdos 
> to it.
> Then writeByteArray writes it all to "out".
> We can do this instead:
>   if (out instanceof HeapDataOutputStream) {
> out.writeAsSerializedByteArray(hdos);
>   } else {
> .. do it the old way
>   }



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

[jira] [Closed] (GEODE-1) Graduate from Apache Incubator and achieve the status of the TLP project

[Anthony Baker (JIRA)]

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

Anthony Baker closed GEODE-1.
-

> Graduate from Apache Incubator and achieve the status of the TLP project
> 
>
> Key: GEODE-1
> URL: https://issues.apache.org/jira/browse/GEODE-1
> Project: Geode
>  Issue Type: Wish
>  Components: general
>Affects Versions: 1.0.0-incubating
>Reporter: Roman Shaposhnik
>Assignee: William Markito Oliveira
>   Original Estimate: 8,736h
>  Remaining Estimate: 8,736h
>
> While achieving the level of maturity required to graduate to the status of 
> the TLP project we might as well take care of world domination while we are 
> at it. After all, it may be possible to do to RAM what HDFS has done to disk 
> and Geode may very well be the thing that does it!



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

[jira] [Updated] (GEODE-977) CI Failure: ParallelWANStatsDUnitTest.testParallePropagationWithRemoteRegionDestroy failed with AssertionFailedError

[Anthony Baker (JIRA)]

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

Anthony Baker updated GEODE-977:

Fix Version/s: 1.1.0

> CI Failure: 
> ParallelWANStatsDUnitTest.testParallePropagationWithRemoteRegionDestroy 
> failed with AssertionFailedError
> 
>
> Key: GEODE-977
> URL: https://issues.apache.org/jira/browse/GEODE-977
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Barry Oglesby
>  Labels: CI, Flaky
> Fix For: 1.1.0
>
>
> Geode_develop_DistributedTests
> Private Build #1613 (Feb 14, 2016 7:09:43 AM)
> Revision: 28ee7c15426c3cc6b43204d28ccf9ff17cafdab4
> Error Message
> {noformat}
> junit.framework.AssertionFailedError
> {noformat}
> Stacktrace
> {noformat}
> junit.framework.AssertionFailedError
>   at junit.framework.Assert.fail(Assert.java:55)
>   at junit.framework.Assert.assertTrue(Assert.java:22)
>   at junit.framework.Assert.assertTrue(Assert.java:31)
>   at junit.framework.TestCase.assertTrue(TestCase.java:201)
>   at 
> com.gemstone.gemfire.internal.cache.wan.parallel.ParallelWANStatsDUnitTest.testParallePropagationWithRemoteRegionDestroy(ParallelWANStatsDUnitTest.java:320)
>   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:497)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at junit.framework.TestCase.runBare(TestCase.java:141)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:252)
>   at junit.framework.TestSuite.run(TestSuite.java:247)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
>   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:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.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:106)
>   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:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
>   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.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



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

[jira] [Updated] (GEODE-1448) CI Failure: com.gemstone.gemfire.internal.cache.wan.wancommand.WanCommandGatewayReceiverStartDUnitTest.testStartGatewayReceiver

[Anthony Baker (JIRA)]

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

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

> CI Failure: 
> com.gemstone.gemfire.internal.cache.wan.wancommand.WanCommandGatewayReceiverStartDUnitTest.testStartGatewayReceiver
> ---
>
> Key: GEODE-1448
> URL: https://issues.apache.org/jira/browse/GEODE-1448
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Udo Kohlmeyer
>  Labels: CI
> Fix For: 1.1.0
>
>
> Build #2693 (May 23, 2016 5:11:54 PM)
> Revision: 45a4ef29f3c8174281aad667265a0764b0b912a3
> https://brazil.gemstone.com:8080/job/Geode_develop_DistributedTests/2693/testReport/com.gemstone.gemfire.internal.cache.wan.wancommand/WanCommandGatewayReceiverStartDUnitTest/testStartGatewayReceiver/
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.test.dunit.NamedCallable.call in VM 0 running on Host 
> cc2-ub.gemstone.com with 8 VMs
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:389)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:355)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:308)
>   at 
> com.gemstone.gemfire.management.internal.cli.commands.CliCommandTestBase.setUpJMXManagerOnVM(CliCommandTestBase.java:111)
>   at 
> com.gemstone.gemfire.management.internal.cli.commands.CliCommandTestBase.setUpJmxManagerOnVm0ThenConnect(CliCommandTestBase.java:105)
>   at 
> com.gemstone.gemfire.internal.cache.wan.wancommand.WanCommandGatewayReceiverStartDUnitTest.testStartGatewayReceiver(WanCommandGatewayReceiverStartDUnitTest.java:90)
>   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:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:112)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   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.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:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.dispa

[jira] [Updated] (GEODE-17) Provide Integrated Security

[Anthony Baker (JIRA)]

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

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

> Provide Integrated Security
> ---
>
> Key: GEODE-17
> URL: https://issues.apache.org/jira/browse/GEODE-17
> Project: Geode
>  Issue Type: New Feature
>  Components: client/server, docs, security
>Reporter: Tushar Khairnar
>Assignee: Jens Deppe
>  Labels: security
> Fix For: 1.1.0
>
>
> Integrated Security: Purpose of integrated security feature is to provide 
> uniform authentication and authorization capabilities for all Geode clients. 
> Geode distributed systems has different clients, some perform cache/region 
> operations, some perform management operations. In order to authenticate and 
> authorize these actions we need single consistent framework or interface. 
> Such interface should allow configuration of access levels from single place 
> and/or repository. 
> The key requirements being met here are
>  - Authentication of all clients from single plugin
>  - Authorization of cache/data operations (through cache-client and REST) and 
> managements (GFSH/JMX) operations from single plugin
>  - Extend existing Client-Server security framework



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

[jira] [Updated] (GEODE-2107) There's thread leak if stopped a secondary sender

[Anthony Baker (JIRA)]

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

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

> There's thread leak if stopped a secondary sender
> -
>
> Key: GEODE-2107
> URL: https://issues.apache.org/jira/browse/GEODE-2107
> Project: Geode
>  Issue Type: Bug
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
> Fix For: 1.1.0
>
>
> In GEM-933, we found the thread leak when a secondary sender is stopped, 
> following thread will stay:
> "Event Processor for GatewaySender_sender_bridgeds_4_to_bridgeds_1" #186 
> daemon prio=5 os_prio=0 tid=0x7f55fc007800 nid=0xb95 in Object.wait() 
> [0x7f55c2a2f000]
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at java.lang.Object.wait(Object.java:502)
> at 
> org.apache.geode.internal.cache.wan.GatewaySenderAdvisor.waitToBecomePrimary(GatewaySenderAdvisor.java:486)
> - locked <0xf66b8390> (a java.lang.Object)
> at 
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderEventProcessor.waitForPrimary(SerialGatewaySenderEventProcessor.java:154)
> at 
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderEventProcessor.run(SerialGatewaySenderEventProcessor.java:203)



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

[jira] [Updated] (GEODE-1478) CI Failure: SerialWANPropogationOffHeapDUnitTest.testReplicatedSerialPropagationToTwoWanSites

[Anthony Baker (JIRA)]

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

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

> CI Failure: 
> SerialWANPropogationOffHeapDUnitTest.testReplicatedSerialPropagationToTwoWanSites
> -
>
> Key: GEODE-1478
> URL: https://issues.apache.org/jira/browse/GEODE-1478
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Udo Kohlmeyer
>  Labels: CI
> Fix For: 1.1.0
>
>
> Build #2711 (May 27, 2016 5:09:17 PM)
> Revision: 3e8fe7af0ced64d2a15b6c3ce52eb9560a83d097
> https://brazil.gemstone.com:8080/job/Geode_develop_DistributedTests/2711/testReport/com.gemstone.gemfire.internal.cache.wan.offheap/SerialWANPropogationOffHeapDUnitTest/testReplicatedSerialPropagationToTwoWanSites/
> java.lang.AssertionError: An exception occurred during asynchronous 
> invocation.
>   at 
> com.gemstone.gemfire.test.dunit.AsyncInvocation.checkException(AsyncInvocation.java:155)
>   at 
> com.gemstone.gemfire.internal.cache.wan.WANTestBase.preTearDown(WANTestBase.java:3697)
>   at 
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.preTearDown(JUnit4DistributedTestCase.java:503)
>   at 
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDown(JUnit4DistributedTestCase.java:477)
>   at 
> com.gemstone.gemfire.test.dunit.internal.JUnit3DistributedTestCase.tearDown(JUnit3DistributedTestCase.java:206)
>   at junit.framework.TestCase.runBare(TestCase.java:146)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:252)
>   at junit.framework.TestSuite.run(TestSuite.java:247)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:112)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   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.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:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.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.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:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
>   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.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
>   at 
> com.gemstone.gemfire.internal.cache.wan.GatewaySenderEventRemoteDispatcher$AckReaderThread.shutdown(GatewaySenderEventRemoteDispatcher.java:727)
>   at 
> com.gemstone.gemfire.int

[jira] [Updated] (GEODE-1963) Add lucene xsd to geode website

[Anthony Baker (JIRA)]

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

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

> Add lucene xsd to geode website
> ---
>
> Key: GEODE-1963
> URL: https://issues.apache.org/jira/browse/GEODE-1963
> Project: Geode
>  Issue Type: Task
>Reporter: Jason Huynh
>Assignee: Jason Huynh
> Fix For: 1.1.0
>
>
> Any active dtd's or schema’s should be hosted at 
> http://geode.apache.org/schema/cache/



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

[jira] [Updated] (GEODE-2021) Goede transaction failed to throw TransactionDataNotColocatedException when a get operation gets on a non colocated key.

[Anthony Baker (JIRA)]

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

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

> Goede transaction failed to throw TransactionDataNotColocatedException when a 
> get operation gets on a non colocated key.
> 
>
> Key: GEODE-2021
> URL: https://issues.apache.org/jira/browse/GEODE-2021
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Eric Shu
>Assignee: Eric Shu
> Fix For: 1.1.0
>
>
> If a transaction first get operation touches a remote node entry, a 
> TXStateStub is created on the remote node. The subsequent get on another 
> remote node will correctly cause the transaction to fail with 
> TransactionDataNotColocatedException.
> However, if a transaction first get is touches a key on a local node, a 
> TXState is created to track the transaction. Currently a subsequent get on 
> non colocated data does not cause the transaction to fail with 
> TransactionDataNotColocatedException.



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

[jira] [Updated] (GEODE-2058) reorganize security examples

[Anthony Baker (JIRA)]

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

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

> reorganize security examples
> 
>
> Key: GEODE-2058
> URL: https://issues.apache.org/jira/browse/GEODE-2058
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Jinmei Liao
> Fix For: 1.1.0
>
>




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

[jira] [Updated] (GEODE-1530) geode-examples setEnv.sh script needs to export path

[Anthony Baker (JIRA)]

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

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

> geode-examples setEnv.sh script needs to export path
> 
>
> Key: GEODE-1530
> URL: https://issues.apache.org/jira/browse/GEODE-1530
> Project: Geode
>  Issue Type: Bug
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>  Labels: bug-hunt
> Fix For: 1.1.0
>
>
> Work currently on the feature/GEODE-33 branch.
> In the replicated example, the {{scripts/setEnv.sh}} script should to prepend 
> the {{GEODE_HOME}} environment variable it finds to the PATH, so that the 
> {{startAll.sh}} uses that path.
> Append this line to the {{scripts/setEnv.sh}} script:
> {{export PATH=$GEODE_HOME/bin:$PATH}}



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

[jira] [Updated] (GEODE-1523) geode-examples README.md markdown improvement

[Anthony Baker (JIRA)]

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

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

> geode-examples README.md markdown improvement
> -
>
> Key: GEODE-1523
> URL: https://issues.apache.org/jira/browse/GEODE-1523
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>  Labels: bug-hunt
> Fix For: 1.1.0
>
>
> The markdown in the feature/GEODE-33 branch file {{geode-examples/README.md}} 
> is not yet right.
> There are problems with the references and with the bulleted list.
> (A separate ticket will address the content of the file.  This ticket is only 
> to fix the markdown, so it displays correctly.)



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

[jira] [Updated] (GEODE-419) javax.net.ssl.* gemfire properties ignored if ssl-enabled is false

[Anthony Baker (JIRA)]

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

Anthony Baker updated GEODE-419:

Fix Version/s: 1.1.0

> javax.net.ssl.* gemfire properties ignored if ssl-enabled is false
> --
>
> Key: GEODE-419
> URL: https://issues.apache.org/jira/browse/GEODE-419
> Project: Geode
>  Issue Type: Bug
>  Components: client/server, configuration, security
>Reporter: Darrel Schneider
>Assignee: Udo Kohlmeyer
>Priority: Minor
> Fix For: 1.1.0
>
>
> You are supposed to be able to put javax.net.ssl.* system property 
> definitions in your gemfire.properties and have them be used to configure ssl.
> They work ok if ssl-enabled is true and cluster-ssl-enabled is not set. But 
> if you set cluster-ssl-enabled (to true or false) then the javax.net.ssl.* 
> properties are ignored. The same is also true for http-service-ssl-enabled.
> This can be worked around by using the new cluster-ssl-keystore* and 
> cluster-ssl-truststore* gemfire properties instead of javax.net.ssl.*.



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

[jira] [Updated] (GEODE-1984) Make GatewaySender destroy a public API

[Anthony Baker (JIRA)]

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

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

> Make GatewaySender destroy a public API
> ---
>
> Key: GEODE-1984
> URL: https://issues.apache.org/jira/browse/GEODE-1984
> Project: Geode
>  Issue Type: New Feature
>  Components: docs, wan
>Reporter: Barry Oglesby
>Assignee: Avinash Dongre
> Fix For: 1.1.0
>
>
> The internal {{AbstractGatewaySender}} class has a {{destroy}} API to destroy 
> a {{GatewaySender}}. This is currently an internal API. It would be nice to 
> make this public by:
> - adding destroy to the {{GatewaySender}} interface
> - provide {{gfsh}} support



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

[jira] [Updated] (GEODE-1653) Executing a fire-and-forget function on all servers doesn't actually execute on all servers

[Anthony Baker (JIRA)]

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

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

> Executing a fire-and-forget function on all servers doesn't actually execute 
> on all servers
> ---
>
> Key: GEODE-1653
> URL: https://issues.apache.org/jira/browse/GEODE-1653
> Project: Geode
>  Issue Type: Bug
>  Components: functions
>Reporter: Barry Oglesby
>Assignee: Amey Barve
> Fix For: 1.1.0
>
>
> Executing a fire-and-forget function on all servers only executes on the ones 
> the client is currently connected to.
> The two {{ExecuteFunctionNoAckOp execute}} methods get the servers to execute 
> against using code like:
> {noformat}
> pool.getCurrentServers();
> {noformat}
> This method just gets all the {{EndpointManager's endpointMap's 
> ServerLocations}}.
> What should be done is more like what the {{ExecuteFunctionOp execute}} 
> methods do:
> {noformat}
> private static List getAllServers(PoolImpl pool) {
>   List servers = null;
>   if (pool.getLocators() == null || pool.getLocators().isEmpty()) {
> servers = ((ExplicitConnectionSourceImpl) 
> pool.getConnectionSource()).getAllServers();
>   } else {
> servers = ((AutoConnectionSourceImpl) 
> pool.getConnectionSource()).findAllServers(); // n/w call on locator
>   }
>   return servers;
> }
> {noformat}



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

[jira] [Updated] (GEODE-1148) CI failure: SerialWANPropagationLoopBackDUnitTest.testReplicatedSerialPropagationLoopBack3SitesLoop

[Anthony Baker (JIRA)]

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

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

> CI failure: 
> SerialWANPropagationLoopBackDUnitTest.testReplicatedSerialPropagationLoopBack3SitesLoop
> ---
>
> Key: GEODE-1148
> URL: https://issues.apache.org/jira/browse/GEODE-1148
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Jianxia Chen
>  Labels: CI, Flaky
> Fix For: 1.1.0
>
>
> https://brazil.gemstone.com:8080/job/Geode_develop_DistributedTests/2074/testReport/com.gemstone.gemfire.internal.cache.wan.serial/SerialWANPropagationLoopBackDUnitTest/testReplicatedSerialPropagationLoopBack3SitesLoop/
> Stacktrace
> junit.framework.AssertionFailedError
>   at junit.framework.Assert.fail(Assert.java:55)
>   at junit.framework.Assert.assertTrue(Assert.java:22)
>   at junit.framework.Assert.assertFalse(Assert.java:39)
>   at junit.framework.Assert.assertFalse(Assert.java:47)
>   at junit.framework.TestCase.assertFalse(TestCase.java:219)
>   at 
> com.gemstone.gemfire.internal.cache.wan.WANTestBase.preTearDown(WANTestBase.java:5063)
>   at 
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.preTearDown(JUnit4DistributedTestCase.java:506)
>   at 
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDown(JUnit4DistributedTestCase.java:480)
>   at 
> com.gemstone.gemfire.test.dunit.internal.JUnit3DistributedTestCase.tearDown(JUnit3DistributedTestCase.java:205)
>   at junit.framework.TestCase.runBare(TestCase.java:146)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:252)
>   at junit.framework.TestSuite.run(TestSuite.java:247)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
>   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:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.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:106)
>   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:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
>   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.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)



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

[jira] [Updated] (GEODE-933) CI failure: ParallelGatewaySenderOperationsDUnitTest.testParallelPropagationSenderStartAfterStop

[Anthony Baker (JIRA)]

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

Anthony Baker updated GEODE-933:

Fix Version/s: 1.1.0

> CI failure: 
> ParallelGatewaySenderOperationsDUnitTest.testParallelPropagationSenderStartAfterStop
> 
>
> Key: GEODE-933
> URL: https://issues.apache.org/jira/browse/GEODE-933
> Project: Geode
>  Issue Type: Bug
>Reporter: Sai Boorlagadda
>Assignee: Dan Smith
>  Labels: CI, Flaky
> Fix For: 1.1.0
>
>
> {noformat}
> Error Message
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.internal.cache.wan.WANTestBase.validateRegionSize in VM 
> 2 running on Host zambia.gemstone.com with 8 VMs
> Stacktrace
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.internal.cache.wan.WANTestBase.validateRegionSize in VM 
> 2 running on Host zambia.gemstone.com with 8 VMs
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:171)
>   at 
> com.gemstone.gemfire.internal.cache.wan.parallel.ParallelGatewaySenderOperationsDUnitTest.testParallelPropagationSenderStartAfterStop(ParallelGatewaySenderOperationsDUnitTest.java:293)
>   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:497)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at junit.framework.TestCase.runBare(TestCase.java:141)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:252)
>   at junit.framework.TestSuite.run(TestSuite.java:247)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
>   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:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.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:106)
>   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:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
>   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.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: junit.framework.AssertionFailedError: Event never occurred after 
> 24 ms: Expected region entries: 1000 

[jira] [Updated] (GEODE-1804) CI Failure : SerialWANPropagationOffHeapDUnitTest.testReplicatedSerialPropagationWithRemoteRegionDestroy3

[Anthony Baker (JIRA)]

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

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

> CI Failure : 
> SerialWANPropagationOffHeapDUnitTest.testReplicatedSerialPropagationWithRemoteRegionDestroy3
> -
>
> Key: GEODE-1804
> URL: https://issues.apache.org/jira/browse/GEODE-1804
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: nabarun
>  Labels: CI
> Fix For: 1.1.0
>
>
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.internal.cache.wan.serial.SerialWANPropagationDUnitTest$$Lambda$337/36821477.run
>  in VM 2 running on Host venezuela.gemstone.com with 8 VMs
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:389)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:355)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:293)
>   at 
> com.gemstone.gemfire.internal.cache.wan.serial.SerialWANPropagationDUnitTest.testReplicatedSerialPropagationWithRemoteRegionDestroy3(SerialWANPropagationDUnitTest.java:601)
>   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:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   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.GeneratedMethodAccessor163.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   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.GeneratedMethodAccessor162.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   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.intern

[jira] [Updated] (GEODE-1938) Big Snapshot File Read Exception via SnapshotReader API

[Anthony Baker (JIRA)]

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

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

> Big Snapshot File Read Exception via SnapshotReader API
> ---
>
> Key: GEODE-1938
> URL: https://issues.apache.org/jira/browse/GEODE-1938
> Project: Geode
>  Issue Type: Bug
>  Components: client/server, snapshot
>Reporter: Udo Kohlmeyer
>Assignee: Udo Kohlmeyer
> Fix For: 1.1.0
>
>
> A utility was created to read data from snapshot(*.gfd) via SnapshotReader 
> API to convert into csv format. They met a strange issue that this utility 
> will crash with snapshotreader exception when snapshot file is 20GB+.



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

[jira] [Updated] (GEODE-2061) Remove PdxInstanceInputStream

[Anthony Baker (JIRA)]

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

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

> Remove PdxInstanceInputStream
> -
>
> Key: GEODE-2061
> URL: https://issues.apache.org/jira/browse/GEODE-2061
> Project: Geode
>  Issue Type: Improvement
>  Components: serialization
>Reporter: Bruce Schuchardt
>Assignee: Avinash Dongre
> Fix For: 1.1.0
>
>
> This class should be removed and its uses replaced with its superclass 
> PdxInputStream.  None of the methods it contains differs from the superclass 
> implementation.



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

[jira] [Updated] (GEODE-2141) StatisticsMonitor and StatMonitorHandler should use ConcurrentHashSet to store monitors, listeners and statisticIds

[Anthony Baker (JIRA)]

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

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

> StatisticsMonitor and StatMonitorHandler should use ConcurrentHashSet to 
> store monitors, listeners and statisticIds
> ---
>
> Key: GEODE-2141
> URL: https://issues.apache.org/jira/browse/GEODE-2141
> Project: Geode
>  Issue Type: Improvement
>Reporter: Avinash Dongre
>Assignee: Avinash Dongre
> Fix For: 1.1.0
>
>
> In StatisticsMonitor and StatMonitorHandler List is used to store monitors, 
> listeners and statisticIds.
> We should be using ConcurrentHashSet for performance Reason.
> In my local testing  When I replace the List to 
> com.gemstone.gemfire.internal.concurrent.
> ConcurrentHashSet
> I see significant improvement in creating large number of region creation.
> ( from ~7hrs to ~26 minutes)
> More details about the same is on dev list.
> Refer : http://markmail.org/message/o7td3fczylx4uaet



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

[jira] [Updated] (GEODE-1122) Dependency on environment variable GEMFIRE needs to be removed

[Anthony Baker (JIRA)]

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

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

> Dependency on environment variable GEMFIRE needs to be removed
> --
>
> Key: GEODE-1122
> URL: https://issues.apache.org/jira/browse/GEODE-1122
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Udo Kohlmeyer
>Assignee: Avinash Dongre
> Fix For: 1.1.0
>
>
> There is still a strong dependency on the environment variable GEMFIRE within 
> GEODE. This should be replaced with GEODE_HOME or removed completely from the 
> system.



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

[jira] [Updated] (GEODE-1008) CI Failure: ParallelWANPropagationDUnitTest.testPartitionedParallelPropagationHA

[Anthony Baker (JIRA)]

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

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

> CI Failure: 
> ParallelWANPropagationDUnitTest.testPartitionedParallelPropagationHA
> 
>
> Key: GEODE-1008
> URL: https://issues.apache.org/jira/browse/GEODE-1008
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Dan Smith
>  Labels: CI, Flaky
> Fix For: 1.1.0
>
>
> {noformat}
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.internal.cache.wan.parallel.ParallelWANPropagationDUnitTest$$Lambda$2596/51958.run
>  in VM 6 running on Host venezuela.gemstone.com with 8 VMs
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:379)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:321)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:272)
>   at 
> com.gemstone.gemfire.internal.cache.wan.parallel.ParallelWANPropagationDUnitTest.testPartitionedParallelPropagationHA(ParallelWANPropagationDUnitTest.java:856)
>   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:497)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at junit.framework.TestCase.runBare(TestCase.java:141)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:252)
>   at junit.framework.TestSuite.run(TestSuite.java:247)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
>   at sun.reflect.GeneratedMethodAccessor155.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.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:106)
>   at sun.reflect.GeneratedMethodAccessor154.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
>   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.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.AssertionError: Event never occurred after 18 ms: 
> Expected bucket entries for bucket: 30 is: 0 but actual entries: 1 This 
> bucket isPrimary: true KEYSET: []
>   at org.junit.Assert.fail(Assert.java:88)
>   at com.gemstone.gemfire.test.dunit.Wait.waitForCriterion(Wait.java:119)
>   at 
> com.gemstone.gemfire.internal.cache.wan.WANTestBase.validateParallelSenderQueueAllBuck

[jira] [Updated] (GEODE-1956) CI failure: LuceneQueriesPeerPRRedundancyDUnitTest.returnCorrectResultsWhenCloseCacheHappensOnIndexUpdate

[Anthony Baker (JIRA)]

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

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

> CI failure: 
> LuceneQueriesPeerPRRedundancyDUnitTest.returnCorrectResultsWhenCloseCacheHappensOnIndexUpdate
> -
>
> Key: GEODE-1956
> URL: https://issues.apache.org/jira/browse/GEODE-1956
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Bruce Schuchardt
>Assignee: xiaojian zhou
>  Labels: CI
> Fix For: 1.1.0
>
>
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.cache.lucene.LuceneQueriesPeerPRRedundancyDUnitTest$$Lambda$50/1718051859.run
>  in VM 0 running on Host cc2-rh6.gemstone.com with 4 VMs
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:389)
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:355)
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:293)
>   at 
> org.apache.geode.cache.lucene.LuceneQueriesPeerPRRedundancyDUnitTest.returnCorrectResultsWhenCloseCacheHappensOnIndexUpdate(LuceneQueriesPeerPRRedundancyDUnitTest.java:80)
>   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:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   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.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:497)
>   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.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:497)
>   at 
> org.gradle.internal.dispatch

[jira] [Updated] (GEODE-2121) add DLockTest, MembershipTest, ClientServerTest, ClientSubscriptionTest and RestAPITest categories

[Anthony Baker (JIRA)]

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

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

> add DLockTest, MembershipTest, ClientServerTest, ClientSubscriptionTest and 
> RestAPITest categories
> --
>
> Key: GEODE-2121
> URL: https://issues.apache.org/jira/browse/GEODE-2121
> Project: Geode
>  Issue Type: Test
>  Components: client queues, client/server, distributed lock service, 
> membership, rest (dev), serialization
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
> Fix For: 1.1.0
>
>
> I need these test categories in order to run code-coverage analysis for the 
> components I usually work with.  The categories should be added to the 
> appropriate unit tests.



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

[jira] [Updated] (GEODE-1509) Reduce the memory usage of GatewayEventCallbackArgument

[Anthony Baker (JIRA)]

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

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

> Reduce the memory usage of GatewayEventCallbackArgument
> ---
>
> Key: GEODE-1509
> URL: https://issues.apache.org/jira/browse/GEODE-1509
> Project: Geode
>  Issue Type: Improvement
>  Components: wan
>Reporter: Dan Smith
>Assignee: Amey Barve
> Fix For: 1.1.0
>
>
> GatewayEventCallbackArgument has a HashSet of recipient gateways. 
> Because we create a ton of these things, these sets end up consuming a lot of 
> memory.
> It should probably use IntOpenHashSet initialized with a small size, eg new 
> IntOpenHashSet(2).



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

[jira] [Updated] (GEODE-2077) getFromBucket() in PartitionedRegion with transaction sometimes returns null when it failed with certain e

[Anthony Baker (JIRA)]

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

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

> getFromBucket() in PartitionedRegion with transaction sometimes returns null 
> when it failed with certain e
> --
>
> Key: GEODE-2077
> URL: https://issues.apache.org/jira/browse/GEODE-2077
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Eric Shu
>Assignee: Eric Shu
> Fix For: 1.1.0
>
>
> getFromBucket() in PartitionedRegion with transaction should throw exception 
> back to indicate region.get() call failed. Transaction could then be retried 
> if necessary.



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

[jira] [Updated] (GEODE-1364) CI failure: SerialWANPropogationDUnitTest.testReplicatedSerialPropagationToTwoWanSites

[Anthony Baker (JIRA)]

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

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

> CI failure: 
> SerialWANPropogationDUnitTest.testReplicatedSerialPropagationToTwoWanSites
> --
>
> Key: GEODE-1364
> URL: https://issues.apache.org/jira/browse/GEODE-1364
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Hitesh Khamesra
>  Labels: CI
> Fix For: 1.1.0
>
>
> java.lang.AssertionError: An exception occurred during asynchronous 
> invocation.
>   at 
> com.gemstone.gemfire.test.dunit.AsyncInvocation.checkException(AsyncInvocation.java:155)
>   at 
> com.gemstone.gemfire.internal.cache.wan.WANTestBase.preTearDown(WANTestBase.java:3697)
>   at 
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.preTearDown(JUnit4DistributedTestCase.java:503)
>   at 
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDown(JUnit4DistributedTestCase.java:477)
>   at 
> com.gemstone.gemfire.test.dunit.internal.JUnit3DistributedTestCase.tearDown(JUnit3DistributedTestCase.java:206)
>   at junit.framework.TestCase.runBare(TestCase.java:146)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:252)
>   at junit.framework.TestSuite.run(TestSuite.java:247)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:112)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   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.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:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.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.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:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
>   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.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
>   at 
> com.gemstone.gemfire.internal.cache.wan.GatewaySenderEventRemoteDispatcher$AckReaderThread.shutdown(GatewaySenderEventRemoteDispatcher.java:726)
>   at 
> com.gemstone.gemfire.internal.cache.wan.GatewaySenderEventRemoteDispatcher.stopAckReaderThread(GatewaySenderEventRemoteDispatcher.java:750)
>   at 
> com.gemstone.gemfire.internal.cache.wan.GatewaySenderEventRemoteDispatcher.stop(GatewaySenderEventRemoteDispatcher.java:765)
>   at 
> com.gemstone.gemfire.internal.cache.wan.AbstractGatew

[jira] [Updated] (GEODE-1835) A message logged by the configure pdx command is incorrect

[Anthony Baker (JIRA)]

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

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

> A message logged by the configure pdx command is incorrect
> --
>
> Key: GEODE-1835
> URL: https://issues.apache.org/jira/browse/GEODE-1835
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Barry Oglesby
>Assignee: Amey Barve
> Fix For: 1.1.0
>
>
> The message below is only logged when there are no members. Instead, it 
> should be logged when there are members.
> {noformat}
> The command would only take effect on new data members joining the 
> distributed system. It won't affect the existing data members
> {noformat}
> The condition in {{PDXCommands.configurePDX}} is:
> {noformat}
> if (CliUtil.getAllNormalMembers(CliUtil.getCacheIfExists()).isEmpty()) {
>   ird.addLine(CliStrings.CONFIGURE_PDX__NORMAL__MEMBERS__WARNING);
> }
> {noformat}
> It should test for {{!isEmpty}}.



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

[jira] [Updated] (GEODE-1531) geode-examples: add final step to run stop script

[Anthony Baker (JIRA)]

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

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

> geode-examples:  add final step to run stop script
> --
>
> Key: GEODE-1531
> URL: https://issues.apache.org/jira/browse/GEODE-1531
> Project: Geode
>  Issue Type: Bug
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>  Labels: bug-hunt
> Fix For: 1.1.0
>
>
> {{replicated/README.md}} steps 1-5 of the replicated example in 
> geode-examples on the feature/GEODE-33 branch are fine.  (Well, step 4 to 
> kill a *server* needs to be specified.)
> A Step 6 needs to be added to the {{replicated/README.md}} file to run 
> {{$ scripts/stopAll.sh}}
> Without this, novice users will not realize that they still have servers and 
> a locator running.



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

[jira] [Updated] (GEODE-1242) HARegionQueue.addDispatchedMessage fails with assertion

[Anthony Baker (JIRA)]

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

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

> HARegionQueue.addDispatchedMessage fails with assertion
> ---
>
> Key: GEODE-1242
> URL: https://issues.apache.org/jira/browse/GEODE-1242
> Project: Geode
>  Issue Type: Bug
>  Components: client queues
>Reporter: Darrel Schneider
>Assignee: xiaojian zhou
> Fix For: 1.1.0
>
>
> CacheClientNotifierDUnitTest.testMultipleCacheServer failed with this suspect 
> string which is caused by a failed assertion in the product code:
> Object old = ((ConcurrentMap)tempDispatchedMessagesMap).putIfAbsent(
> this.regionName, this.threadIdToSeqId);
> if (isUsedByTest) {
>   testMarkerMessageRecieved = true;
>   if (logger.isDebugEnabled()) {
> logger.debug("testIsAckRecieved: {}", testMarkerMessageRecieved);
>   }
> }
> Assert.assertTrue(old == null);
> Here is the suspect string stack:Found suspect string in log4j at line 2564
> [fatal 2016/04/16 02:52:53.399 UTC  
> tid=0x71] Server connection from 
> [identity(ip-10-32-36-249(14674:loner):50509:c338fc1c,connection=1; 
> port=50568] : Unexpected Error on server
> com.gemstone.gemfire.InternalGemFireError
>   at com.gemstone.gemfire.internal.Assert.throwError(Assert.java:93)
>   at com.gemstone.gemfire.internal.Assert.assertTrue(Assert.java:57)
>   at 
> com.gemstone.gemfire.internal.cache.ha.HARegionQueue.addDispatchedMessage(HARegionQueue.java:1758)
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.CacheClientNotifier.processDispatchedMessage(CacheClientNotifier.java:733)
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.command.PeriodicAck.cmdExecute(PeriodicAck.java:56)
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:175)
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:805)
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:932)
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1181)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.AcceptorImpl$1$1.run(AcceptorImpl.java:560)
>   at java.lang.Thread.run(Thread.java:745)
>   at org.junit.Assert.fail(Assert.java:88)
>   at 
> com.gemstone.gemfire.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:354)
>   at 
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:543)
>   at ...



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

[jira] [Updated] (GEODE-2120) MultipleOplogsRollingFeatureJUnitTest sometimes failed in CI

[Anthony Baker (JIRA)]

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

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

> MultipleOplogsRollingFeatureJUnitTest sometimes failed in CI
> 
>
> Key: GEODE-2120
> URL: https://issues.apache.org/jira/browse/GEODE-2120
> Project: Geode
>  Issue Type: Bug
>  Components: core
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>  Labels: CI
> Fix For: 1.1.0
>
>
> In Integration Tests Build #276: 
>classname="org.apache.geode.internal.cache.MultipleOplogsRollingFeatureJUnitTest"
>  time="7.264">
> 

[jira] [Updated] (GEODE-165) Add build support for generating antlr classes from grammar

[Anthony Baker (JIRA)]

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

Anthony Baker updated GEODE-165:

Fix Version/s: 1.1.0

> Add build support for generating antlr classes from grammar
> ---
>
> Key: GEODE-165
> URL: https://issues.apache.org/jira/browse/GEODE-165
> Project: Geode
>  Issue Type: Bug
>  Components: build
>Reporter: Dan Smith
>Assignee: Avinash Dongre
> Fix For: 1.1.0
>
>
> The OQL engine currently uses antlr to generate some parsing classes from 
> gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/parse/oql.g
> These are the generated classes. They are currently checked into the source.
> OQLLexer.java
> OQLLexerTokenTypes.java
> OQLLexerTokenTypes.txt
> OQLParser.java
> They can be generated manually by running antlr.Tool on the provided grammar.
> cd gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/parse/
> java -cp antlr.jar antlr.Tool oql.g
> We should add support to the gradle build to generate these classes.
> In my opinion we should also remove the checked in classes. With gradle we 
> can configure things so that the gradle eclipse target will generate these 
> classes and make them available to the IDE as well. Look at 
> gemfire-core/build.gradle for how we do this with the version properties file:
> sourceSets {
>   main {
> output.dir(generatedResources, builtBy: 'createVersionPropertiesFile')
>   }
> }



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

[jira] [Updated] (GEODE-2088) A get in transaction may get incorrect TransactionDataNotColocatedException when bucket is not hosted locally

[Anthony Baker (JIRA)]

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

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

> A get in transaction may get incorrect TransactionDataNotColocatedException 
> when bucket is not hosted locally
> -
>
> Key: GEODE-2088
> URL: https://issues.apache.org/jira/browse/GEODE-2088
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Eric Shu
>Assignee: Eric Shu
> Fix For: 1.1.0
>
>
> Currently a get of a PR in transaction on a data node with TXState will first 
> check if the bucket is hosted locally by following code. 
> {noformat}
>   public Object getLocally(int bucketId, final Object key, final Object 
> aCallbackArgument,
>   boolean disableCopyOnRead, boolean preferCD, ClientProxyMembershipID 
> requestingClient,
>   EntryEventImpl clientEvent, boolean returnTombstones, boolean 
> opScopeIsLocal)
>   throws PrimaryBucketException, ForceReattemptException, 
> PRLocallyDestroyedException {
> final BucketRegion bucketRegion = getInitializedBucketForId(key, 
> Integer.valueOf(bucketId));
> {noformat}
> The BucketNotFoundException is thrown if the node does not host the bucket:
> {noformat}
>   public BucketRegion getInitializedBucketForId(Object key, Integer bucketId)
>   throws ForceReattemptException {
> final BucketRegion bucketRegion = 
> this.localBucket2RegionMap.get(bucketId);
> if (null == bucketRegion) {
>   this.partitionedRegion.checkReadiness();
>   if (logger.isDebugEnabled()) {
> logger.debug("Got null bucket region for bucketId={}{}{} for 
> PartitionedRegion = {}",
> this.partitionedRegion.getPRId(), 
> PartitionedRegion.BUCKET_ID_SEPARATOR, bucketId,
> this.partitionedRegion);
>   }
>   ForceReattemptException fre = new BucketNotFoundException(
>   
> LocalizedStrings.PartitionedRegionDataStore_BUCKET_ID_0_NOT_FOUND_ON_VM_1
>   .toLocalizedString(
>   new Object[] 
> {this.partitionedRegion.bucketStringForLogs(bucketId.intValue()),
>   this.partitionedRegion.getMyId()}));
>   if (key != null) {
> fre.setHash(key.hashCode());
>   }
>   throw fre;
> }
> {noformat}
> Currently, transaction would fail with the 
> TransactionDataNotColocatedException if bucket is not on local data store 
> {noformat}
>   if (prce instanceof BucketNotFoundException) {
> TransactionException ex = new 
> TransactionDataNotColocatedException(
> 
> LocalizedStrings.PartitionedRegion_KEY_0_NOT_COLOCATED_WITH_TRANSACTION
> .toLocalizedString(key));
> ex.initCause(prce);
> throw ex;
>   }
> {noformat}
> This TransactionDataNotColocatedException is fine if the node never hosts 
> bucket, or only previous operations within the transaction touches replicate 
> regions earlier. However, if a bucket is moved to another node due to 
> rebalance, and previous entry operations within the transaction only touches 
> colocated regions, the transaction should fail with 
> TransactionDataRebalancedException.
> We do not have a good way currently to throw the correct exception. One idea 
> is to iterate through the existing TXRegions in the TXState to see whether we 
> should throw TransactionDataRebalancedException. 



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

[jira] [Updated] (GEODE-2129) Need to generate pdx type id random(or avoid sequential)

[Anthony Baker (JIRA)]

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

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

> Need to generate pdx type id random(or avoid sequential)
> 
>
> Key: GEODE-2129
> URL: https://issues.apache.org/jira/browse/GEODE-2129
> Project: Geode
>  Issue Type: Bug
>  Components: serialization
>Reporter: Hitesh Khamesra
>Assignee: Hitesh Khamesra
> Fix For: 1.1.0
>
>
> Right now pdxtype id has 4 bytes.  Out of those 4 bytes, one byte reserved 
> for distributed-system-id, this make sure type id generated from different 
> cluster has different id. For rest of the three bytes we just increment 
> counter to create new pdxtype id.  In the field, we have observed that 
> sometimes this pdxType Id collides.  One reason could be they end up having 
> same distributed-system-id for the different cluster.  
> Thus to avoid a collision, we will be using hashcode of pdxType for three 
> bytes of pdxType id. That will reduce the possibility of collision.



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

[jira] [Updated] (GEODE-1967) CompactMapRangeIndex loses track when the same entry is deleted and added. Old key are not removed from the removedKeyValuesEntries after it was removed from Compact Rang

[Anthony Baker (JIRA)]

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

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

> CompactMapRangeIndex loses track when the same entry is deleted and added. 
> Old key are not removed from the removedKeyValuesEntries after it was removed 
> from Compact Range Indexes
> ---
>
> Key: GEODE-1967
> URL: https://issues.apache.org/jira/browse/GEODE-1967
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: nabarun
> Fix For: 1.1.0
>
>
> After the keys are removed from a region and the compact range index was was 
> updated, the old keys were not removed from removedKeyValuesEntries



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

[jira] [Updated] (GEODE-1931) CI Failure: LocatorUDPSecurityDUnitTest.testStartTwoLocators

[Anthony Baker (JIRA)]

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

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

> CI Failure: LocatorUDPSecurityDUnitTest.testStartTwoLocators
> 
>
> Key: GEODE-1931
> URL: https://issues.apache.org/jira/browse/GEODE-1931
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Eric Shu
>Assignee: Udo Kohlmeyer
>  Labels: ci, flaky
> Fix For: 1.1.0
>
>
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.NamedCallable.call in VM 2 running on Host 
> cc2-rh6.gemstone.com with 5 VMs
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:389)
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:355)
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:308)
>   at 
> org.apache.geode.distributed.LocatorDUnitTest.testStartTwoLocators(LocatorDUnitTest.java:307)
>   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:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   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.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:497)
>   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.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:497)
>   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.Messag

[jira] [Updated] (GEODE-1180) CI failure: ParallelWANPropogationOffHeapDUnitTest.testPartitionedParallelPropagationHA

[Anthony Baker (JIRA)]

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

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

> CI failure: 
> ParallelWANPropogationOffHeapDUnitTest.testPartitionedParallelPropagationHA
> ---
>
> Key: GEODE-1180
> URL: https://issues.apache.org/jira/browse/GEODE-1180
> Project: Geode
>  Issue Type: Bug
>Reporter: Jinmei Liao
>  Labels: CI, Flaky
> Fix For: 1.1.0
>
>
> Geode_develop_DistributedTests/2154
> Revision: 49e3f523d16389f5e84847c6dcfd6ab45427f8c2
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.internal.cache.wan.parallel.ParallelWANPropagationDUnitTest$$Lambda$2213/647282888.run
>  in VM 6 running on Host venezuela.gemstone.com with 8 VMs
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:439)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:381)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:317)
>   at 
> com.gemstone.gemfire.internal.cache.wan.parallel.ParallelWANPropagationDUnitTest.testPartitionedParallelPropagationHA(ParallelWANPropagationDUnitTest.java:739)
>   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:497)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at junit.framework.TestCase.runBare(TestCase.java:141)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:252)
>   at junit.framework.TestSuite.run(TestSuite.java:247)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
>   at sun.reflect.GeneratedMethodAccessor155.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.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:106)
>   at sun.reflect.GeneratedMethodAccessor154.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
>   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.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.AssertionError: Event never occurred after 18 ms: 
> Expected bucket entries for bucket: 27 is: 0 but actual entries: 1 This 
> bucket isPrimary: true KEYSET: []
>   at org.junit.Assert.fail(Assert.java:88)
>   at com.gemstone.gemfire.test.dunit.Wait.waitForCriterion(Wait.java:185)
>   at 
> com.gemstone.gemfir