date:20170307

Storing object in deserialized form in geode cache

2017-03-07 Thread Deepak Dixit

Hello Geode Team,

I am working on a use case where I want to store the java object. I want to
avoid the serialization and deserialization while reading on server
(function execution).
Also while updating I would like to update in-place rather than to create
copy of object, modify and store it again in underlying map.

Based on my current understanding, every object is wrapped in
"VMCachedDeserializable" and serialized / deserialized while doing get/put.

Kindly advice the way with which I can store object in deserialized form in
cache and do in place modifications.

Thanks,
Deepak

Re: Review Request 57206: let LuceneResultStruct to be Serializable, then customer does not have to defined their Serializable class to hold result

2017-03-07 Thread xiaojian zhou


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

(Updated March 8, 2017, 5:49 a.m.)


Review request for geode, Barry Oglesby and Dan Smith.


Changes
---

let LuceneResultStructImpl to implements DataSerializableFixedID


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


Repository: geode


Description
---

If customer call a lucene query in a function, they need to define their own 
Serializable class to collect results. This has been complained by field 
engineer. 

It will not hurt to let LuceneResultStruct to extend Serializable


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/internal/DataSerializableFixedID.java 
63a95a5 
  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/LuceneResultStruct.java
 5d2184e 
  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneResultStructImpl.java
 6c31025 


Diff: https://reviews.apache.org/r/57206/diff/2/

Changes: https://reviews.apache.org/r/57206/diff/1-2/


Testing
---


Thanks,

xiaojian zhou

[jira] [Commented] (GEODE-2578) Query string limited to 64 KiB

2017-03-07 Thread ASF GitHub Bot (JIRA)


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

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

Github user PivotalSarge commented on a diff in the pull request:

https://github.com/apache/geode-native/pull/48#discussion_r104836958
  
--- Diff: src/cppcache/include/geode/DataOutput.hpp ---
@@ -378,9 +378,8 @@ class CPPCACHE_EXPORT DataOutput {
  */
   inline void writeFullUTF(const char* value, uint32_t length = 0) {
--- End diff --

I agree and tried to move it to TcrMessage. However, its implementation 
depends on private members of DataOutput.


> Query string limited to 64 KiB
> --
>
> Key: GEODE-2578
> URL: https://issues.apache.org/jira/browse/GEODE-2578
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Dodge
>Assignee: Michael Dodge
>
> The serialization of query strings uses a 16-bit unsigned integer to 
> represent the length of the query string. Query strings with more than 65535 
> characters are silently truncated. Use of a 32-bit unsigned integer to 
> represent the length would greatly increase the size of query strings that 
> may be used.



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

[GitHub] geode-native pull request #48: GEODE-2578: Remove 64 KiB limit on query stri...

2017-03-07 Thread PivotalSarge

Github user PivotalSarge commented on a diff in the pull request:

https://github.com/apache/geode-native/pull/48#discussion_r104836958
  
--- Diff: src/cppcache/include/geode/DataOutput.hpp ---
@@ -378,9 +378,8 @@ class CPPCACHE_EXPORT DataOutput {
  */
   inline void writeFullUTF(const char* value, uint32_t length = 0) {
--- End diff --

I agree and tried to move it to TcrMessage. However, its implementation 
depends on private members of DataOutput.


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

[jira] [Closed] (GEODE-319) HDFSConfigJUnitTest testHdfsStoreInvalidCompactionConf expected exception logic is incorrect

2017-03-07 Thread Kirk Lund (JIRA)


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

Kirk Lund closed GEODE-319.
---

> HDFSConfigJUnitTest testHdfsStoreInvalidCompactionConf expected exception 
> logic is incorrect
> 
>
> Key: GEODE-319
> URL: https://issues.apache.org/jira/browse/GEODE-319
> Project: Geode
>  Issue Type: Sub-task
>  Components: hdfs
>Affects Versions: 1.0.0-incubating
>Reporter: Kirk Lund
>
> It's common to follow this pattern in JUnit 3.8:
> {noformat}
> try {
>   //do something that will throw expected exception
>   fail("Expected exception was not thrown");
> } catch (ExpectedException e) {
>   //passed because ExpectedException was thrown
> }
> {noformat}
> However, the logic in testHdfsStoreInvalidCompactionConf is clearly goofed 
> up. The test passes on Linux only because NO exception is being thrown but 
> that should cause that this test to fail (according to javadocs). So at best 
> it's a test that is not valid and should be deleted, or at worse it's hiding 
> a real bug.
> {noformat}
> /**
>  * Validates that cache creation fails if a compaction configuration is
>  * provided which is not applicable to the selected compaction strategy
>  */
> public void testHdfsStoreInvalidCompactionConf() {
>   String conf = createStoreConf("123");
>   try {
> this.c.loadCacheXml(new ByteArrayInputStream(conf.getBytes()));
> // expected
>   } catch (CacheXmlException e) {
> fail();
>   }
> }
> {noformat}



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

[jira] [Resolved] (GEODE-319) HDFSConfigJUnitTest testHdfsStoreInvalidCompactionConf expected exception logic is incorrect

2017-03-07 Thread Kirk Lund (JIRA)


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

Kirk Lund resolved GEODE-319.
-
Resolution: Won't Fix

Test no longer exists.

> HDFSConfigJUnitTest testHdfsStoreInvalidCompactionConf expected exception 
> logic is incorrect
> 
>
> Key: GEODE-319
> URL: https://issues.apache.org/jira/browse/GEODE-319
> Project: Geode
>  Issue Type: Sub-task
>  Components: hdfs
>Affects Versions: 1.0.0-incubating
>Reporter: Kirk Lund
>
> It's common to follow this pattern in JUnit 3.8:
> {noformat}
> try {
>   //do something that will throw expected exception
>   fail("Expected exception was not thrown");
> } catch (ExpectedException e) {
>   //passed because ExpectedException was thrown
> }
> {noformat}
> However, the logic in testHdfsStoreInvalidCompactionConf is clearly goofed 
> up. The test passes on Linux only because NO exception is being thrown but 
> that should cause that this test to fail (according to javadocs). So at best 
> it's a test that is not valid and should be deleted, or at worse it's hiding 
> a real bug.
> {noformat}
> /**
>  * Validates that cache creation fails if a compaction configuration is
>  * provided which is not applicable to the selected compaction strategy
>  */
> public void testHdfsStoreInvalidCompactionConf() {
>   String conf = createStoreConf("123");
>   try {
> this.c.loadCacheXml(new ByteArrayInputStream(conf.getBytes()));
> // expected
>   } catch (CacheXmlException e) {
> fail();
>   }
> }
> {noformat}



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

[jira] [Updated] (GEODE-1534) security-username, security-password should be in ConfigurationProperties

2017-03-07 Thread Kirk Lund (JIRA)


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

Kirk Lund updated GEODE-1534:
-
Component/s: configuration

> security-username, security-password should be in ConfigurationProperties
> -
>
> Key: GEODE-1534
> URL: https://issues.apache.org/jira/browse/GEODE-1534
> Project: Geode
>  Issue Type: Improvement
>  Components: configuration, security
>Reporter: Dan Smith
>  Labels: bug-hunt
>
> These two special properties are passed to the users Authorization callback 
> when someone logs in through gfsh. They should probably be documented in the 
> Authenticator javadocs and provided as public constants in 
> ConfigurationProperties.



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

[jira] [Updated] (GEODE-1815) ConfigurationProperties javadocs need to be more descriptive in a number of cases

2017-03-07 Thread Kirk Lund (JIRA)


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

Kirk Lund updated GEODE-1815:
-
Labels: javadocs  (was: )

> ConfigurationProperties javadocs need to be more descriptive in a number of 
> cases
> -
>
> Key: GEODE-1815
> URL: https://issues.apache.org/jira/browse/GEODE-1815
> Project: Geode
>  Issue Type: Bug
>  Components: security
>Reporter: Bruce Schuchardt
>  Labels: javadocs
>
> There are a number of new SECURITY properties in ConfigurationProperties that 
> have a "geode 1.0" tag that have inadequate javadocs.  This is the primary 
> location for documenting distribution config properties, so they need to have 
> a good description like all of the other properties.
> This is one such property:
> {noformat}
>   /**
>* The static String definition of the "security-manager"
>* property
>* @since Geode 1.0
>*/
>   String SECURITY_MANAGER = SECURITY_PREFIX + "manager";
> {noformat}
> this is a properly documented property:
> {noformat}
>   /**
>* The static String definition of the "remote-locators" property
>* 
>* Description: A list of locators (host and port) that a cluster
>* will use in order to connect to a remote site in a multi-site (WAN)
>* configuration. This attribute's value is a possibly comma separated list.
>* For each remote locator, provide a hostname and/or address
>* (separated by '@', if you use both), followed by a port number in 
> brackets.
>* Examples:
>* remote-locators=address1[port1],address2[port2]
>* 
>* remote-locators=hostName1@address1[port1],hostName2@address2[port2]
>* 
>* remote-locators=hostName1[port1],hostName2[port2]
>* 
>* Default: ""
>*/
>   String REMOTE_LOCATORS = "remote-locators";
> {noformat}



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

[jira] [Updated] (GEODE-2614) Build generates javadoc warnings

2017-03-07 Thread Kirk Lund (JIRA)


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

Kirk Lund updated GEODE-2614:
-
Labels: javadocs  (was: )

> Build generates javadoc warnings
> 
>
> Key: GEODE-2614
> URL: https://issues.apache.org/jira/browse/GEODE-2614
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, jmx
>Reporter: Kirk Lund
>  Labels: javadocs
>
> {noformat}
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java:56:
>  warning - @param argument "logFilter:" is not a parameter name.
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java:56:
>  warning - @param argument "baseLogFile:" is not a parameter name.
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java:56:
>  warning - @param argument "baseStatsFile:" is not a parameter name.
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/CliAroundInterceptor.java:45:
>  warning - @param argument "tempFile:" is not a parameter name.
> {noformat}



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

[jira] [Commented] (GEODE-2558) Upgrade mockito dependency

2017-03-07 Thread Kirk Lund (JIRA)


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

Kirk Lund commented on GEODE-2558:
--

@manvsri glad to have to contribute! I've sent details to the dev list about 
how folks can join in on GEODE-2558.

> Upgrade mockito dependency
> --
>
> Key: GEODE-2558
> URL: https://issues.apache.org/jira/browse/GEODE-2558
> Project: Geode
>  Issue Type: Wish
>  Components: build, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> Mockito should be upgrade from 1.x to 2.x.
> 1.10.19 (Dec, 2014) <-- current version
> 2.7.11 (Feb 2017)
> This requires updating Powermock as well.
> Changes to dependency-versions.properties:
> {noformat}
> -mockito-core.version = 1.10.19
> +mockito-core.version = 2.7.11
> ...
> -powermock.version = 1.6.6
> +powermock.version = 1.7.0RC2
> {noformat}
> The upgrade from Mockito 1.x to 2.x includes breaking APIs. Even after 
> updating the APIs to compile, I still see a number of unit tests that use 
> Mockito failing. These tests span all of the components in Geode so it's a 
> non-trivial upgrade.



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

Upgrading to Mockito 2

2017-03-07 Thread Kirk Lund

I've started upgrading to Mockito 2. The branch feature/GEODE-2558 has been
created, and I pushed the initial commit which upgrades to Mockito 2.7.11
and Powermock 1.7.0RC2. There were compilation errors in 34 test classes
which have been fixed already.

GEODE-2558: https://issues.apache.org/jira/browse/GEODE-2558

Here's the initial change-set:
https://git-wip-us.apache.org/repos/asf?p=geode.git;h=ee0ab01

My first pass at precheckin shows 23 failures in geode-core (8 test
classes) and 3 failures in geode-lucene (2 test classes). These are all
unit tests using Mockito.

I'd like to open this up to other contributors to help fix these test
failures.

Here's a really good blog article about upgrading to Mockito 2.1:
https://asolntsev.github.io/en/2016/10/11/mockito-2.1/

Based on reading that article, I suspect we need to fix up the way these 10
test classes are using Mockito.

Each test class which currently has any Mockito 2 related failures now has
a sub-task filed under GEODE-2558.

1) assign the sub-task to yourself
2) click start progress
3) create feature branch for the sub-task
4) when you file the PR be sure to file it against feature/GEODE-2558

Here are examples of creating a feature branch for the sub-task I'm going
to work on (GEODE-2628 StatisticsImplTest):

git:
$ git checkout -b feature/GEODE-2628 feature/GEODE-2558

git-flow:
$ git flow feature start GEODE-2628 feature/GEODE-2558

[jira] [Resolved] (GEODE-2603) Docs: geode-native user guide >> Security >> SSL setup needs update

2017-03-07 Thread Dave Barnes (JIRA)


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

Dave Barnes resolved GEODE-2603.

   Resolution: Fixed
Fix Version/s: 1.2.0

> Docs: geode-native user guide >> Security >> SSL setup needs update
> ---
>
> Key: GEODE-2603
> URL: https://issues.apache.org/jira/browse/GEODE-2603
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
> Fix For: 1.2.0
>
>
> Update SSL setup to refer to OpenSSL's own installation procedures.



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

[jira] [Assigned] (GEODE-2628) Fix failures in StatisticsImplTest caused by upgrading to mockito 2.7.11

2017-03-07 Thread Kirk Lund (JIRA)


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

Kirk Lund reassigned GEODE-2628:


Assignee: Kirk Lund

> Fix failures in StatisticsImplTest caused by upgrading to mockito 2.7.11
> 
>
> Key: GEODE-2628
> URL: https://issues.apache.org/jira/browse/GEODE-2628
> Project: Geode
>  Issue Type: Sub-task
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> These tests fail on branch feature/GEODE-2558:
> * StatisticsImplTest.invokeSuppliersShouldLogErrorOnlyOnce



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

[jira] [Commented] (GEODE-2603) Docs: geode-native user guide >> Security >> SSL setup needs update

2017-03-07 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on GEODE-2603:


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

GEODE-2603 Native client doc: Update SSL page


> Docs: geode-native user guide >> Security >> SSL setup needs update
> ---
>
> Key: GEODE-2603
> URL: https://issues.apache.org/jira/browse/GEODE-2603
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> Update SSL setup to refer to OpenSSL's own installation procedures.



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

[jira] [Created] (GEODE-2631) Fix failures in RegionDirectoryJUnitTest caused by upgrading to mockito 2.7.11

2017-03-07 Thread Kirk Lund (JIRA)

Kirk Lund created GEODE-2631:


 Summary: Fix failures in RegionDirectoryJUnitTest caused by 
upgrading to mockito 2.7.11
 Key: GEODE-2631
 URL: https://issues.apache.org/jira/browse/GEODE-2631
 Project: Geode
  Issue Type: Sub-task
  Components: tests
Reporter: Kirk Lund


These tests fail on branch feature/GEODE-2558:
* RegionDirectoryJUnitTest.testFsyncDoesntCreateNewFiles
* RegionDirectoryJUnitTest.testPendingDeletions



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

[jira] [Created] (GEODE-2628) Fix failures in StatisticsImplTest caused by upgrading to mockito 2.7.11

2017-03-07 Thread Kirk Lund (JIRA)

Kirk Lund created GEODE-2628:


 Summary: Fix failures in StatisticsImplTest caused by upgrading to 
mockito 2.7.11
 Key: GEODE-2628
 URL: https://issues.apache.org/jira/browse/GEODE-2628
 Project: Geode
  Issue Type: Sub-task
  Components: tests
Reporter: Kirk Lund


These tests fail on branch feature/GEODE-2558:
* StatisticsImplTest.invokeSuppliersShouldLogErrorOnlyOnce




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

[jira] [Created] (GEODE-2627) Fix failures in OffHeapRegionEntryHelperJUnitTest caused by upgrading to mockito 2.7.11

2017-03-07 Thread Kirk Lund (JIRA)

Kirk Lund created GEODE-2627:


 Summary: Fix failures in OffHeapRegionEntryHelperJUnitTest caused 
by upgrading to mockito 2.7.11
 Key: GEODE-2627
 URL: https://issues.apache.org/jira/browse/GEODE-2627
 Project: Geode
  Issue Type: Sub-task
Reporter: Kirk Lund


These tests fail on branch feature/GEODE-2558:
* OffHeapRegionEntryHelperJUnitTest.releaseEntryShouldSetValueToRemovePhase2
* 
OffHeapRegionEntryHelperJUnitTest.releaseEntryShouldSetValueToRemovePhase2AndSetsAsyncToFalseForDiskEntry
* 
OffHeapRegionEntryHelperJUnitTest.setValueShouldChangeTheRegionEntryAddressToNewAddressAndDoesNothingIfOldAddressIsATokenAddress
* 
OffHeapRegionEntryHelperJUnitTest.setValueShouldChangeTheRegionEntryAddressToNewAddressAndDoesNothingIfOldAddressIsAnEncodedAddress
* 
OffHeapRegionEntryHelperJUnitTest.setValueShouldChangeTheRegionEntryAddressToNewAddressAndReleaseOldValueIfItsOnOffHeap




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

[jira] [Updated] (GEODE-2627) Fix failures in OffHeapRegionEntryHelperJUnitTest caused by upgrading to mockito 2.7.11

2017-03-07 Thread Kirk Lund (JIRA)


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

Kirk Lund updated GEODE-2627:
-
Component/s: (was: build)

> Fix failures in OffHeapRegionEntryHelperJUnitTest caused by upgrading to 
> mockito 2.7.11
> ---
>
> Key: GEODE-2627
> URL: https://issues.apache.org/jira/browse/GEODE-2627
> Project: Geode
>  Issue Type: Sub-task
>  Components: tests
>Reporter: Kirk Lund
>
> These tests fail on branch feature/GEODE-2558:
> * OffHeapRegionEntryHelperJUnitTest.releaseEntryShouldSetValueToRemovePhase2
> * 
> OffHeapRegionEntryHelperJUnitTest.releaseEntryShouldSetValueToRemovePhase2AndSetsAsyncToFalseForDiskEntry
> * 
> OffHeapRegionEntryHelperJUnitTest.setValueShouldChangeTheRegionEntryAddressToNewAddressAndDoesNothingIfOldAddressIsATokenAddress
> * 
> OffHeapRegionEntryHelperJUnitTest.setValueShouldChangeTheRegionEntryAddressToNewAddressAndDoesNothingIfOldAddressIsAnEncodedAddress
> * 
> OffHeapRegionEntryHelperJUnitTest.setValueShouldChangeTheRegionEntryAddressToNewAddressAndReleaseOldValueIfItsOnOffHeap



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

[jira] [Created] (GEODE-2626) Fix failures in FastLoggerJUnitTest caused by upgrading to mockito 2.7.11

2017-03-07 Thread Kirk Lund (JIRA)

Kirk Lund created GEODE-2626:


 Summary: Fix failures in FastLoggerJUnitTest caused by upgrading 
to mockito 2.7.11
 Key: GEODE-2626
 URL: https://issues.apache.org/jira/browse/GEODE-2626
 Project: Geode
  Issue Type: Sub-task
  Components: tests
Reporter: Kirk Lund


These tests fail on branch feature/GEODE-2558:
* FastLoggerJUnitTest.delegateIsDebugEnabledWhenIsDelegating
* FastLoggerJUnitTest.delegateIsDebugEnabledWhenIsDelegating
* FastLoggerJUnitTest.delegateIsDebugEnabledWhenIsDelegating

The above list is from geode-core/build/reports/test/index.html generated by 
gradle by running the test target. I'm not sure why the same test is listed 3 
times -- this should be investigated as part of this ticket.



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

[jira] [Created] (GEODE-2625) Fix failures in PutTest caused by upgrading to mockito 2.7.11

2017-03-07 Thread Kirk Lund (JIRA)

Kirk Lund created GEODE-2625:


 Summary: Fix failures in PutTest caused by upgrading to mockito 
2.7.11
 Key: GEODE-2625
 URL: https://issues.apache.org/jira/browse/GEODE-2625
 Project: Geode
  Issue Type: Sub-task
  Components: tests
Reporter: Kirk Lund


These tests fail on branch feature/GEODE-2558:
* PutTest.integratedSecurityShouldSucceedIfAuthorized
* PutTest.noSecurityShouldSucceed
* PutTest.oldSecurityShouldSucceedIfAuthorized



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

[jira] [Created] (GEODE-2624) Fix failures in Put65Test caused by upgrading to mockito 2.7.11

2017-03-07 Thread Kirk Lund (JIRA)

Kirk Lund created GEODE-2624:


 Summary: Fix failures in Put65Test caused by upgrading to mockito 
2.7.11
 Key: GEODE-2624
 URL: https://issues.apache.org/jira/browse/GEODE-2624
 Project: Geode
  Issue Type: Sub-task
  Components: tests
Reporter: Kirk Lund


These tests fail on branch feature/GEODE-2558:
* Put65Test.integratedSecurityShouldSucceedIfAuthorized
* Put65Test.noSecurityShouldSucceed
* Put65Test.oldSecurityShouldSucceedIfAuthorized



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

[jira] [Created] (GEODE-2623) Fix failures in Put61Test caused by upgrading to mockito 2.7.11

2017-03-07 Thread Kirk Lund (JIRA)

Kirk Lund created GEODE-2623:


 Summary: Fix failures in Put61Test caused by upgrading to mockito 
2.7.11
 Key: GEODE-2623
 URL: https://issues.apache.org/jira/browse/GEODE-2623
 Project: Geode
  Issue Type: Sub-task
  Components: tests
Reporter: Kirk Lund


These tests fail on branch feature/GEODE-2558:
* Put61Test.integratedSecurityShouldSucceedIfAuthorized
* Put61Test.noSecurityShouldSucceed
* Put61Test.oldSecurityShouldSucceedIfAuthorized



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

[jira] [Created] (GEODE-2622) Fix failures in GMSMembershipManagerJUnitTest caused by upgrading to mockito 2.7.11

2017-03-07 Thread Kirk Lund (JIRA)

Kirk Lund created GEODE-2622:


 Summary: Fix failures in GMSMembershipManagerJUnitTest caused by 
upgrading to mockito 2.7.11
 Key: GEODE-2622
 URL: https://issues.apache.org/jira/browse/GEODE-2622
 Project: Geode
  Issue Type: Sub-task
  Components: tests
Reporter: Kirk Lund


These tests fail on branch feature/GEODE-2558:
* GMSMembershipManagerJUnitTest.testDirectChannelSend
* GMSMembershipManagerJUnitTest.testDirectChannelSendAllRecipients
* 
GMSMembershipManagerJUnitTest.testDirectChannelSendFailureDueToForcedDisconnect
* GMSMembershipManagerJUnitTest.testDirectChannelSendFailureToOneRecipient



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

[jira] [Updated] (GEODE-1608) update javadocs given the new ConfigurationProperties interface

2017-03-07 Thread Kirk Lund (JIRA)


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

Kirk Lund updated GEODE-1608:
-
Labels: javadocs  (was: )

> update javadocs given the new ConfigurationProperties interface
> ---
>
> Key: GEODE-1608
> URL: https://issues.apache.org/jira/browse/GEODE-1608
> Project: Geode
>  Issue Type: Bug
>Reporter: Karen Smoler Miller
>  Labels: javadocs
>
> With the new {{ConfigurationProperties}} interface, any/all javadocs that 
> contain example code that uses a string literal for one of the defined 
> properties, instead of its new static String definition should be changed.
> For example, Example 3 of the javadocs for `CacheFactory`:
> {code:java}
> Cache c = new CacheFactory()
> .set("cache-xml-file", "myCache.xml")
> .create();
> Region r = c.getRegion("myRegion");
> {code}
> should be changed to:
> {code:java}
> Cache c = new CacheFactory()
> .set(CACHE_XML_FILE, "myCache.xml")
> .create();
> Region r = c.getRegion("myRegion");
> {code}



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

[jira] [Issue Comment Deleted] (GEODE-2558) Upgrade mockito dependency

2017-03-07 Thread Kirk Lund (JIRA)


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

Kirk Lund updated GEODE-2558:
-
Comment: was deleted

(was: I just created feature/GEODE-2558 branch with this 1st commit:
{noformat}
commit 1e2f9d6f7dcbcd17aec65cd6e567930d90a8282e
Author: Kirk Lund 
Date:   Fri Feb 24 21:10:50 2017 -0800

Upgrade mockito to 2.7.11 and powermock to 1.7.0RC2

* mockito-core.version = 2.7.11
* powermock.version = 1.7.0RC2
* fix compilation errors
* there are several test failures in geode-core and geode-lucene

geode-core test failures:

* GMSMembershipManagerJUnitTest.testDirectChannelSend
* GMSMembershipManagerJUnitTest.testDirectChannelSendAllRecipients
* 
GMSMembershipManagerJUnitTest.testDirectChannelSendFailureDueToForcedDisconnect
* GMSMembershipManagerJUnitTest.testDirectChannelSendFailureToOneRecipient
* Put61Test.integratedSecurityShouldSucceedIfAuthorized
* Put61Test.noSecurityShouldSucceed
* Put61Test.oldSecurityShouldSucceedIfAuthorized
* Put65Test.integratedSecurityShouldSucceedIfAuthorized
* Put65Test.noSecurityShouldSucceed
* Put65Test.oldSecurityShouldSucceedIfAuthorized
* PutTest.integratedSecurityShouldSucceedIfAuthorized
* PutTest.noSecurityShouldSucceed
* PutTest.oldSecurityShouldSucceedIfAuthorized
* FastLoggerJUnitTest.delegateIsDebugEnabledWhenIsDelegating
* FastLoggerJUnitTest.delegateIsDebugEnabledWhenIsDelegating
* FastLoggerJUnitTest.delegateIsDebugEnabledWhenIsDelegating
* OffHeapRegionEntryHelperJUnitTest.releaseEntryShouldSetValueToRemovePhase2
* 
OffHeapRegionEntryHelperJUnitTest.releaseEntryShouldSetValueToRemovePhase2AndSetsAsyncToFalseForDiskEntry
* 
OffHeapRegionEntryHelperJUnitTest.setValueShouldChangeTheRegionEntryAddressToNewAddressAndDoesNothingIfOldAddressIsATokenAddress
* 
OffHeapRegionEntryHelperJUnitTest.setValueShouldChangeTheRegionEntryAddressToNewAddressAndDoesNothingIfOldAddressIsAnEncodedAddress
* 
OffHeapRegionEntryHelperJUnitTest.setValueShouldChangeTheRegionEntryAddressToNewAddressAndReleaseOldValueIfItsOnOffHeap
* StatisticsImplTest.invokeSuppliersShouldLogErrorOnlyOnce
* ConnectionJUnitTest.testSuspicionRaised

geode-lucene test failures:

* StringQueryProviderJUnitTest.usesCustomAnalyzer
* RegionDirectoryJUnitTest.testFsyncDoesntCreateNewFiles
* RegionDirectoryJUnitTest.testPendingDeletions
{noformat})

> Upgrade mockito dependency
> --
>
> Key: GEODE-2558
> URL: https://issues.apache.org/jira/browse/GEODE-2558
> Project: Geode
>  Issue Type: Wish
>  Components: build, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> Mockito should be upgrade from 1.x to 2.x.
> 1.10.19 (Dec, 2014) <-- current version
> 2.7.11 (Feb 2017)
> This requires updating Powermock as well.
> Changes to dependency-versions.properties:
> {noformat}
> -mockito-core.version = 1.10.19
> +mockito-core.version = 2.7.11
> ...
> -powermock.version = 1.6.6
> +powermock.version = 1.7.0RC2
> {noformat}
> The upgrade from Mockito 1.x to 2.x includes breaking APIs. Even after 
> updating the APIs to compile, I still see a number of unit tests that use 
> Mockito failing. These tests span all of the components in Geode so it's a 
> non-trivial upgrade.



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

[jira] [Commented] (GEODE-2558) Upgrade mockito dependency

2017-03-07 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on GEODE-2558:


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

GEODE-2558: Upgrade mockito to 2.7.11 and powermock to 1.7.0RC2

* mockito-core.version = 2.7.11
* powermock.version = 1.7.0RC2
* fix compilation errors
* there are several test failures in geode-core and geode-lucene

geode-core test failures:

* GMSMembershipManagerJUnitTest.testDirectChannelSend
* GMSMembershipManagerJUnitTest.testDirectChannelSendAllRecipients
* 
GMSMembershipManagerJUnitTest.testDirectChannelSendFailureDueToForcedDisconnect
* GMSMembershipManagerJUnitTest.testDirectChannelSendFailureToOneRecipient
* Put61Test.integratedSecurityShouldSucceedIfAuthorized
* Put61Test.noSecurityShouldSucceed
* Put61Test.oldSecurityShouldSucceedIfAuthorized
* Put65Test.integratedSecurityShouldSucceedIfAuthorized
* Put65Test.noSecurityShouldSucceed
* Put65Test.oldSecurityShouldSucceedIfAuthorized
* PutTest.integratedSecurityShouldSucceedIfAuthorized
* PutTest.noSecurityShouldSucceed
* PutTest.oldSecurityShouldSucceedIfAuthorized
* FastLoggerJUnitTest.delegateIsDebugEnabledWhenIsDelegating
* FastLoggerJUnitTest.delegateIsDebugEnabledWhenIsDelegating
* FastLoggerJUnitTest.delegateIsDebugEnabledWhenIsDelegating
* OffHeapRegionEntryHelperJUnitTest.releaseEntryShouldSetValueToRemovePhase2
* 
OffHeapRegionEntryHelperJUnitTest.releaseEntryShouldSetValueToRemovePhase2AndSetsAsyncToFalseForDiskEntry
* 
OffHeapRegionEntryHelperJUnitTest.setValueShouldChangeTheRegionEntryAddressToNewAddressAndDoesNothingIfOldAddressIsATokenAddress
* 
OffHeapRegionEntryHelperJUnitTest.setValueShouldChangeTheRegionEntryAddressToNewAddressAndDoesNothingIfOldAddressIsAnEncodedAddress
* 
OffHeapRegionEntryHelperJUnitTest.setValueShouldChangeTheRegionEntryAddressToNewAddressAndReleaseOldValueIfItsOnOffHeap
* StatisticsImplTest.invokeSuppliersShouldLogErrorOnlyOnce
* ConnectionJUnitTest.testSuspicionRaised

geode-lucene test failures:

* StringQueryProviderJUnitTest.usesCustomAnalyzer
* RegionDirectoryJUnitTest.testFsyncDoesntCreateNewFiles
* RegionDirectoryJUnitTest.testPendingDeletions


> Upgrade mockito dependency
> --
>
> Key: GEODE-2558
> URL: https://issues.apache.org/jira/browse/GEODE-2558
> Project: Geode
>  Issue Type: Wish
>  Components: build, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> Mockito should be upgrade from 1.x to 2.x.
> 1.10.19 (Dec, 2014) <-- current version
> 2.7.11 (Feb 2017)
> This requires updating Powermock as well.
> Changes to dependency-versions.properties:
> {noformat}
> -mockito-core.version = 1.10.19
> +mockito-core.version = 2.7.11
> ...
> -powermock.version = 1.6.6
> +powermock.version = 1.7.0RC2
> {noformat}
> The upgrade from Mockito 1.x to 2.x includes breaking APIs. Even after 
> updating the APIs to compile, I still see a number of unit tests that use 
> Mockito failing. These tests span all of the components in Geode so it's a 
> non-trivial upgrade.



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

[jira] [Commented] (GEODE-2558) Upgrade mockito dependency

2017-03-07 Thread Kirk Lund (JIRA)


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

Kirk Lund commented on GEODE-2558:
--

I just created feature/GEODE-2558 branch with this 1st commit:
{noformat}
commit 1e2f9d6f7dcbcd17aec65cd6e567930d90a8282e
Author: Kirk Lund 
Date:   Fri Feb 24 21:10:50 2017 -0800

Upgrade mockito to 2.7.11 and powermock to 1.7.0RC2

* mockito-core.version = 2.7.11
* powermock.version = 1.7.0RC2
* fix compilation errors
* there are several test failures in geode-core and geode-lucene

geode-core test failures:

* GMSMembershipManagerJUnitTest.testDirectChannelSend
* GMSMembershipManagerJUnitTest.testDirectChannelSendAllRecipients
* 
GMSMembershipManagerJUnitTest.testDirectChannelSendFailureDueToForcedDisconnect
* GMSMembershipManagerJUnitTest.testDirectChannelSendFailureToOneRecipient
* Put61Test.integratedSecurityShouldSucceedIfAuthorized
* Put61Test.noSecurityShouldSucceed
* Put61Test.oldSecurityShouldSucceedIfAuthorized
* Put65Test.integratedSecurityShouldSucceedIfAuthorized
* Put65Test.noSecurityShouldSucceed
* Put65Test.oldSecurityShouldSucceedIfAuthorized
* PutTest.integratedSecurityShouldSucceedIfAuthorized
* PutTest.noSecurityShouldSucceed
* PutTest.oldSecurityShouldSucceedIfAuthorized
* FastLoggerJUnitTest.delegateIsDebugEnabledWhenIsDelegating
* FastLoggerJUnitTest.delegateIsDebugEnabledWhenIsDelegating
* FastLoggerJUnitTest.delegateIsDebugEnabledWhenIsDelegating
* OffHeapRegionEntryHelperJUnitTest.releaseEntryShouldSetValueToRemovePhase2
* 
OffHeapRegionEntryHelperJUnitTest.releaseEntryShouldSetValueToRemovePhase2AndSetsAsyncToFalseForDiskEntry
* 
OffHeapRegionEntryHelperJUnitTest.setValueShouldChangeTheRegionEntryAddressToNewAddressAndDoesNothingIfOldAddressIsATokenAddress
* 
OffHeapRegionEntryHelperJUnitTest.setValueShouldChangeTheRegionEntryAddressToNewAddressAndDoesNothingIfOldAddressIsAnEncodedAddress
* 
OffHeapRegionEntryHelperJUnitTest.setValueShouldChangeTheRegionEntryAddressToNewAddressAndReleaseOldValueIfItsOnOffHeap
* StatisticsImplTest.invokeSuppliersShouldLogErrorOnlyOnce
* ConnectionJUnitTest.testSuspicionRaised

geode-lucene test failures:

* StringQueryProviderJUnitTest.usesCustomAnalyzer
* RegionDirectoryJUnitTest.testFsyncDoesntCreateNewFiles
* RegionDirectoryJUnitTest.testPendingDeletions
{noformat}

> Upgrade mockito dependency
> --
>
> Key: GEODE-2558
> URL: https://issues.apache.org/jira/browse/GEODE-2558
> Project: Geode
>  Issue Type: Wish
>  Components: build, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> Mockito should be upgrade from 1.x to 2.x.
> 1.10.19 (Dec, 2014) <-- current version
> 2.7.11 (Feb 2017)
> This requires updating Powermock as well.
> Changes to dependency-versions.properties:
> {noformat}
> -mockito-core.version = 1.10.19
> +mockito-core.version = 2.7.11
> ...
> -powermock.version = 1.6.6
> +powermock.version = 1.7.0RC2
> {noformat}
> The upgrade from Mockito 1.x to 2.x includes breaking APIs. Even after 
> updating the APIs to compile, I still see a number of unit tests that use 
> Mockito failing. These tests span all of the components in Geode so it's a 
> non-trivial upgrade.



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

[jira] [Commented] (GEODE-2509) Build failed at openSUSE LEAP 42.2

2017-03-07 Thread ASF GitHub Bot (JIRA)


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

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

Github user asfgit closed the pull request at:

https://github.com/apache/geode-native/pull/47


> Build failed at openSUSE LEAP 42.2
> --
>
> Key: GEODE-2509
> URL: https://issues.apache.org/jira/browse/GEODE-2509
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Danilo Chang
>Priority: Minor
> Attachments: fix_build_opensuse.patch
>
>
> geode-native C++ client build failed at openSUSE LEAP 42.2, because the 
> library folder name is different at 32bit or 64bit environment (lib64 at 
> 64bit environment and lib at 32bit environment). Now 2 components has this 
> issue, libxml2 and xerces-c.
> The attachment file is the solution I try to fix this issue (use --libdir to 
> specify the path). However, I don't know Geode native C++ client prefer to 
> use the same lib folder name or not. So I create this JIRA item.



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

[GitHub] geode-native pull request #47: GEODE-2509: Build failed at openSUSE LEAP 42....

2017-03-07 Thread asfgit

Github user asfgit closed the pull request at:

https://github.com/apache/geode-native/pull/47


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

[jira] [Commented] (GEODE-2509) Build failed at openSUSE LEAP 42.2

2017-03-07 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on GEODE-2509:


Commit 06e8f39a036a0cbbda0898bb87673ed57a5dfa46 in geode-native's branch 
refs/heads/develop from [~ray2501]
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=06e8f39 ]

GEODE-2509: Build failed at openSUSE LEAP 42.2

This issue is when you use configure but does not specify lib
folder name on openSUSE, the default is "lib64" at 64bit
environment (not lib). Use --libdir option to specify the path.

This closes #47.


> Build failed at openSUSE LEAP 42.2
> --
>
> Key: GEODE-2509
> URL: https://issues.apache.org/jira/browse/GEODE-2509
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Danilo Chang
>Priority: Minor
> Attachments: fix_build_opensuse.patch
>
>
> geode-native C++ client build failed at openSUSE LEAP 42.2, because the 
> library folder name is different at 32bit or 64bit environment (lib64 at 
> 64bit environment and lib at 32bit environment). Now 2 components has this 
> issue, libxml2 and xerces-c.
> The attachment file is the solution I try to fix this issue (use --libdir to 
> specify the path). However, I don't know Geode native C++ client prefer to 
> use the same lib folder name or not. So I create this JIRA item.



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

[jira] [Commented] (GEODE-2509) Build failed at openSUSE LEAP 42.2

2017-03-07 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on GEODE-2509:


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

GEODE-2509: Build failed at openSUSE LEAP 42.2

This issue is when you use configure but does not specify lib
folder name on openSUSE, the default is "lib64" at 64bit
environment (not lib). Use --libdir option to specify the path.


> Build failed at openSUSE LEAP 42.2
> --
>
> Key: GEODE-2509
> URL: https://issues.apache.org/jira/browse/GEODE-2509
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Danilo Chang
>Priority: Minor
> Attachments: fix_build_opensuse.patch
>
>
> geode-native C++ client build failed at openSUSE LEAP 42.2, because the 
> library folder name is different at 32bit or 64bit environment (lib64 at 
> 64bit environment and lib at 32bit environment). Now 2 components has this 
> issue, libxml2 and xerces-c.
> The attachment file is the solution I try to fix this issue (use --libdir to 
> specify the path). However, I don't know Geode native C++ client prefer to 
> use the same lib folder name or not. So I create this JIRA item.



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

[jira] [Updated] (GEODE-888) Change build to fail if javadocs generates any warnings

2017-03-07 Thread Kirk Lund (JIRA)


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

Kirk Lund updated GEODE-888:

Labels: javadocs  (was: )

> Change build to fail if javadocs generates any warnings
> ---
>
> Key: GEODE-888
> URL: https://issues.apache.org/jira/browse/GEODE-888
> Project: Geode
>  Issue Type: Improvement
>  Components: build
>Reporter: Kirk Lund
>  Labels: javadocs
>
> See GEODE-805. After javadoc warnings are fixed, the build should be changed 
> to fail if javadocs generates any warnings (for problems such as malformed 
> tags).



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

[jira] [Updated] (GEODE-1611) Region javadocs has misinformation regarding "the root region"

2017-03-07 Thread Kirk Lund (JIRA)


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

Kirk Lund updated GEODE-1611:
-
Labels: javadocs  (was: )

> Region javadocs has misinformation regarding "the root region"
> --
>
> Key: GEODE-1611
> URL: https://issues.apache.org/jira/browse/GEODE-1611
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Darrel Schneider
>Assignee: Sai Boorlagadda
>  Labels: javadocs
>
> The javadocs on the Region interface talks about "the root region". It no 
> longer exists. Now users can create any number of root regions explicitly 
> instead of the product having a single implicit root region.



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

[jira] [Commented] (GEODE-2441) Remove PDXAutoSerializer

2017-03-07 Thread ASF GitHub Bot (JIRA)


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

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

Github user asfgit closed the pull request at:

https://github.com/apache/geode-native/pull/42


> Remove PDXAutoSerializer 
> -
>
> Key: GEODE-2441
> URL: https://issues.apache.org/jira/browse/GEODE-2441
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Ernest Burghardt
>
> Remove PDXAutoSerializer utility that generates PDX serialization C++ source 
> that you can include in your project to (de)serialize your C++ classes.



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

[GitHub] geode-native pull request #42: GEODE-2441: Remove leftover pdx auto serializ...

2017-03-07 Thread asfgit

Github user asfgit closed the pull request at:

https://github.com/apache/geode-native/pull/42


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

[jira] [Commented] (GEODE-2441) Remove PDXAutoSerializer

2017-03-07 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on GEODE-2441:


Commit 7da9d90bdd28619193b044be9ab3a226c50ffd0c in geode-native's branch 
refs/heads/develop from [~dkimura]
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=7da9d90 ]

GEODE-2441: Remove leftover pdx auto serializer references

This closes #42.


> Remove PDXAutoSerializer 
> -
>
> Key: GEODE-2441
> URL: https://issues.apache.org/jira/browse/GEODE-2441
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Ernest Burghardt
>
> Remove PDXAutoSerializer utility that generates PDX serialization C++ source 
> that you can include in your project to (de)serialize your C++ classes.



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

[jira] [Updated] (GEODE-1086) Generate javadocs for non-public API

2017-03-07 Thread Kirk Lund (JIRA)


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

Kirk Lund updated GEODE-1086:
-
Labels: javadocs  (was: )

> Generate javadocs for non-public API
> 
>
> Key: GEODE-1086
> URL: https://issues.apache.org/jira/browse/GEODE-1086
> Project: Geode
>  Issue Type: Improvement
>  Components: build
>Reporter: Swapnil Bawaskar
>  Labels: javadocs
>
> We need a new target to generate javadocs for internal classes, which will be 
> beneficial for new developers.



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

[jira] [Updated] (GEODE-1707) Create missing package javadocs

2017-03-07 Thread Kirk Lund (JIRA)


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

Kirk Lund updated GEODE-1707:
-
Labels: javadocs  (was: )

> Create missing package javadocs
> ---
>
> Key: GEODE-1707
> URL: https://issues.apache.org/jira/browse/GEODE-1707
> Project: Geode
>  Issue Type: Bug
>  Components: general
>Reporter: Bruce Schuchardt
>  Labels: javadocs
>
> When you bring up the Geode javadocs there are a lot of packages that are 
> missing descriptions.  When someone is looking over the packages they need to 
> know what they contain.
> * com.gemstone.gemfire.cache.wan
> * com.gemstone.gemfire.compression
> * com.gemstone.gemfire.i18n
> * com.gemstone.gemfire.lang
> * com.gemstone.gemfire.management.membership
> * com.gemstone.gemfire.memcached
> * com.gemstone.gemfire.modules.gatewaydelta
> * com.gemstone.gemfire.modules.hibernate   
> * com.gemstone.gemfire.modules.session.bootstrap   
> * com.gemstone.gemfire.modules.session.catalina
> * com.gemstone.gemfire.modules.session.catalina.callback   
> * com.gemstone.gemfire.modules.session.filter  
> * com.gemstone.gemfire.modules.session.installer   
> * com.gemstone.gemfire.modules.session.installer.args  
> * com.gemstone.gemfire.modules.util
> * com.gemstone.gemfire.ra
> These directories must have a package.html that has, at a minimum, a 
> paragraph describing the package.  I can't even tell what the 
> com.gemstone.gemfire.ra package is about after looking at the two items it 
> contains.



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

[jira] [Commented] (GEODE-2603) Docs: geode-native user guide >> Security >> SSL setup needs update

2017-03-07 Thread ASF GitHub Bot (JIRA)


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

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

Github user davebarnes97 closed the pull request at:

https://github.com/apache/geode-native/pull/46


> Docs: geode-native user guide >> Security >> SSL setup needs update
> ---
>
> Key: GEODE-2603
> URL: https://issues.apache.org/jira/browse/GEODE-2603
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> Update SSL setup to refer to OpenSSL's own installation procedures.



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

[jira] [Updated] (GEODE-2605) Unable to do a Lucene query without CLUSTER:READ privilege

2017-03-07 Thread Karen Smoler Miller (JIRA)


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

Karen Smoler Miller updated GEODE-2605:
---
Component/s: docs

> Unable to do a Lucene query without CLUSTER:READ privilege
> --
>
> Key: GEODE-2605
> URL: https://issues.apache.org/jira/browse/GEODE-2605
> Project: Geode
>  Issue Type: Bug
>  Components: docs, lucene, security
>Reporter: Diane Hardman
> Attachments: security.json
>
>
> I have configured a small cluster with security and am testing the privileges 
> I need for creating a Lucene index and then executing a query/search using 
> Lucene. 
> I have confirmed that DATA:MANAGE privilege allows me to create a lucene 
> index (similar to creating OQL indexes).
> I assumed I needed DATA:WRITE privilege to execute 'search lucene' because 
> the implementation uses a function. Instead, I am getting an error that I 
> need CLUSTER:READ privilege. I don't know why.
> As an aside, we may want to document that all DATA privileges automatically 
> include CLUSTER:READ as I found I could create indexes with DATA:WRITE, but 
> could not list the indexes I created without CLUSTER:READ... go figure.



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

[GitHub] geode-native pull request #46: GEODE-2603 Docs: geode-native user guide >> S...

2017-03-07 Thread davebarnes97

Github user davebarnes97 closed the pull request at:

https://github.com/apache/geode-native/pull/46


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

[jira] [Commented] (GEODE-2620) Remove rate stats from LuceneIndexMetrices

2017-03-07 Thread ASF GitHub Bot (JIRA)


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

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

GitHub user nabarunnag opened a pull request:

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

GEODE-2620: Rate stats removed from LuceneIndexMetrics

* Commit Rate, update rate and query rate removed from 
LuceneIndexMetrics
* They can be added back again when the getRate method in 
StatsRate.java is fixed

@upthewaterspout @jhuynh1 @ladyVader @gesterzhou @boglesby 

-- Lucene precheckin and spotlessApply passed

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

$ git pull https://github.com/nabarunnag/incubator-geode feature/GEODE-2620

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

https://github.com/apache/geode/pull/418.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #418


commit cecda0015583decaffd0929464a75a578fd4ac55
Author: nabarun 
Date:   2017-03-07T23:05:47Z

GEODE-2620: Rate stats removed from LuceneIndexMetrics

* Commit Rate, update rate and query rate removed from 
LuceneIndexMetrics
* They can be added back again when the getRate method in 
StatsRate.java is fixed




> Remove rate stats from LuceneIndexMetrices
> --
>
> Key: GEODE-2620
> URL: https://issues.apache.org/jira/browse/GEODE-2620
> Project: Geode
>  Issue Type: Bug
>Reporter: nabarun
>
> Remove stats like 
> commitRate
> updateRate
> queryExecutionRate



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

[jira] [Assigned] (GEODE-2558) Upgrade mockito dependency

2017-03-07 Thread Kirk Lund (JIRA)


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

Kirk Lund reassigned GEODE-2558:


Assignee: Kirk Lund

> Upgrade mockito dependency
> --
>
> Key: GEODE-2558
> URL: https://issues.apache.org/jira/browse/GEODE-2558
> Project: Geode
>  Issue Type: Wish
>  Components: build, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> Mockito should be upgrade from 1.x to 2.x.
> 1.10.19 (Dec, 2014) <-- current version
> 2.7.11 (Feb 2017)
> This requires updating Powermock as well.
> Changes to dependency-versions.properties:
> {noformat}
> -mockito-core.version = 1.10.19
> +mockito-core.version = 2.7.11
> ...
> -powermock.version = 1.6.6
> +powermock.version = 1.7.0RC2
> {noformat}
> The upgrade from Mockito 1.x to 2.x includes breaking APIs. Even after 
> updating the APIs to compile, I still see a number of unit tests that use 
> Mockito failing. These tests span all of the components in Geode so it's a 
> non-trivial upgrade.



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

[GitHub] geode pull request #418: GEODE-2620: Rate stats removed from LuceneIndexMetr...

2017-03-07 Thread nabarunnag

GitHub user nabarunnag opened a pull request:

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

GEODE-2620: Rate stats removed from LuceneIndexMetrics

* Commit Rate, update rate and query rate removed from 
LuceneIndexMetrics
* They can be added back again when the getRate method in 
StatsRate.java is fixed

@upthewaterspout @jhuynh1 @ladyVader @gesterzhou @boglesby 

-- Lucene precheckin and spotlessApply passed

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

$ git pull https://github.com/nabarunnag/incubator-geode feature/GEODE-2620

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

https://github.com/apache/geode/pull/418.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #418


commit cecda0015583decaffd0929464a75a578fd4ac55
Author: nabarun 
Date:   2017-03-07T23:05:47Z

GEODE-2620: Rate stats removed from LuceneIndexMetrics

* Commit Rate, update rate and query rate removed from 
LuceneIndexMetrics
* They can be added back again when the getRate method in 
StatsRate.java is fixed




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

[jira] [Commented] (GEODE-2578) Query string limited to 64 KiB

2017-03-07 Thread ASF GitHub Bot (JIRA)


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

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

Github user pivotal-jbarrett commented on a diff in the pull request:

https://github.com/apache/geode-native/pull/48#discussion_r104816808
  
--- Diff: src/cppcache/include/geode/DataOutput.hpp ---
@@ -378,9 +378,8 @@ class CPPCACHE_EXPORT DataOutput {
  */
   inline void writeFullUTF(const char* value, uint32_t length = 0) {
--- End diff --

If we are being sticklers and consistent this method has no business here. 
It is only used by the Message writeStringPart and should really be implemented 
there.


> Query string limited to 64 KiB
> --
>
> Key: GEODE-2578
> URL: https://issues.apache.org/jira/browse/GEODE-2578
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Dodge
>Assignee: Michael Dodge
>
> The serialization of query strings uses a 16-bit unsigned integer to 
> represent the length of the query string. Query strings with more than 65535 
> characters are silently truncated. Use of a 32-bit unsigned integer to 
> represent the length would greatly increase the size of query strings that 
> may be used.



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

[GitHub] geode-native pull request #48: GEODE-2578: Remove 64 KiB limit on query stri...

2017-03-07 Thread pivotal-jbarrett

Github user pivotal-jbarrett commented on a diff in the pull request:

https://github.com/apache/geode-native/pull/48#discussion_r104816808
  
--- Diff: src/cppcache/include/geode/DataOutput.hpp ---
@@ -378,9 +378,8 @@ class CPPCACHE_EXPORT DataOutput {
  */
   inline void writeFullUTF(const char* value, uint32_t length = 0) {
--- End diff --

If we are being sticklers and consistent this method has no business here. 
It is only used by the Message writeStringPart and should really be implemented 
there.


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

[jira] [Commented] (GEODE-1198) CI Failure: DistributedSystemDUnitTest.testConflictingUDPPort

2017-03-07 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on GEODE-1198:


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

GEODE-1198: add todo comment to dubious test


> CI Failure: DistributedSystemDUnitTest.testConflictingUDPPort
> -
>
> Key: GEODE-1198
> URL: https://issues.apache.org/jira/browse/GEODE-1198
> Project: Geode
>  Issue Type: Bug
>  Components: membership, tests
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>  Labels: Flaky
> Fix For: 1.2.0
>
>
> Geode_develop_DistributedTests/2178/
> Revision: 7413804dec6acc1077618d50459e07200ced8336
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.distributed.DistributedSystemDUnitTest$2.run in VM 1 
> running on Host rooktwo.gemstone.com with 4 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.distributed.DistributedSystemDUnitTest.testConflictingUDPPort(DistributedSystemDUnitTest.java:380)
>   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: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 
>

[jira] [Commented] (GEODE-1577) Unhelpful generic types on Execution.execute

2017-03-07 Thread ASF GitHub Bot (JIRA)


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

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

Github user kirklund commented on the issue:

https://github.com/apache/geode/pull/321
  
+1 Dan's latest suggestion sounds good to me.


> Unhelpful generic types on Execution.execute
> 
>
> Key: GEODE-1577
> URL: https://issues.apache.org/jira/browse/GEODE-1577
> Project: Geode
>  Issue Type: Bug
>  Components: functions
>Reporter: Dan Smith
>Assignee: Dan Smith
>
> The execute methods of the function service Execution class returns a 
> ResultCollector with wildcards for the type.
> {code}  
> public ResultCollector execute(
>   Function function) throws FunctionException;
> {code}
> Wildcards are supposed to be used in APIs where the type doesn't matter, for 
> example counting the elements in a list. By returning a ResultCollector with 
> wildcards, we're essentially forcing the user to cast the result collector.
> At a minimum they should be able to pick the type of result collector
> {code}
>   public  ResultCollector execute(
>   Function function) throws FunctionException;
> {code}
> But maybe it would make more sense to parameterize Execution itself. Then the 
> compiler could ensure that the types used by withCollector and the types used 
> by execute match.



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

[GitHub] geode issue #321: [GEODE-1577] Unhelpful generic types on Execution.execute

2017-03-07 Thread kirklund

Github user kirklund commented on the issue:

https://github.com/apache/geode/pull/321
  
+1 Dan's latest suggestion sounds good to me.


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

[jira] [Commented] (GEODE-2621) CI Failure: ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering

2017-03-07 Thread ASF GitHub Bot (JIRA)


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

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

Github user jaredjstewart commented on the issue:

https://github.com/apache/geode/pull/417
  
We’ll see if the nightly build passes in the morning :D
> On Mar 7, 2017, at 4:07 PM, Kenneth Howe  wrote:
> 
> @pdxrunner commented on this pull request.
> 
> Can you remove the Flaky annotation on the test now?
> 
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub 
, or mute 
the thread 
.
> 




> CI Failure: ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering
> --
>
> Key: GEODE-2621
> URL: https://issues.apache.org/jira/browse/GEODE-2621
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Affects Versions: 1.1.0
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>Priority: Minor
>  Labels: CI, Flaky
>
> {code}
> See 
> 
> Changes:
> [jiliao] GEODE-2267: mark local time sensitive tests as flaky
> [khowe] GEODE-2488: Remove test from flaky category
> [nnag] GEODE-2596: Lucene metrics moved to public API
> [nnag] GEODE-2604: Added javadoc comments to LuceneIndexMetrics.java
> [nnag] GEODE-2604: Added measurement units to the javadoc comments
> --
> [...truncated 99.83 KB...]
> :geode-core:flakyTest
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest > 
> testExportWithStartAndEndDateTimeFiltering FAILED
>java.lang.AssertionError: 
>Expected size:<3> but was:<1> in:
><[/tmp/junit3849272601382305906/unzippedLogs/server-2]>
>at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.verifyZipFileContents(ExportLogsDUnitTest.java:227)
>at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering(ExportLogsDUnitTest.java:157)
> {code}



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

[GitHub] geode issue #417: GEODE-2621: Reduce time sensitivity of ExportLogsDUnitTest

2017-03-07 Thread jaredjstewart

Github user jaredjstewart commented on the issue:

https://github.com/apache/geode/pull/417
  
Weâll see if the nightly build passes in the morning :D
> On Mar 7, 2017, at 4:07 PM, Kenneth Howe  wrote:
> 
> @pdxrunner commented on this pull request.
> 
> Can you remove the Flaky annotation on the test now?
> 
> â
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub 
, or mute 
the thread 
.
> 




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

[jira] [Commented] (GEODE-2621) CI Failure: ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering

2017-03-07 Thread ASF GitHub Bot (JIRA)


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

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

Github user asfgit closed the pull request at:

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


> CI Failure: ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering
> --
>
> Key: GEODE-2621
> URL: https://issues.apache.org/jira/browse/GEODE-2621
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Affects Versions: 1.1.0
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>Priority: Minor
>  Labels: CI, Flaky
>
> {code}
> See 
> 
> Changes:
> [jiliao] GEODE-2267: mark local time sensitive tests as flaky
> [khowe] GEODE-2488: Remove test from flaky category
> [nnag] GEODE-2596: Lucene metrics moved to public API
> [nnag] GEODE-2604: Added javadoc comments to LuceneIndexMetrics.java
> [nnag] GEODE-2604: Added measurement units to the javadoc comments
> --
> [...truncated 99.83 KB...]
> :geode-core:flakyTest
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest > 
> testExportWithStartAndEndDateTimeFiltering FAILED
>java.lang.AssertionError: 
>Expected size:<3> but was:<1> in:
><[/tmp/junit3849272601382305906/unzippedLogs/server-2]>
>at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.verifyZipFileContents(ExportLogsDUnitTest.java:227)
>at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering(ExportLogsDUnitTest.java:157)
> {code}



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

[GitHub] geode pull request #417: GEODE-2621: Reduce time sensitivity of ExportLogsDU...

2017-03-07 Thread asfgit

Github user asfgit closed the pull request at:

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


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

[jira] [Comment Edited] (GEODE-2605) Unable to do a Lucene query without CLUSTER:READ privilege

2017-03-07 Thread Diane Hardman (JIRA)


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

Diane Hardman edited comment on GEODE-2605 at 3/7/17 11:40 PM:
---

Here are the gfsh commands to reproduce this behavior:
In first VM using gfsh, start up the cluster with 1 locator and 1 server 
configured with security as ‘super-user’ (all cluster and data privileges):
  start locator --name=loc2 
--J=-Dgemfire.security-manager=org.apache.geode.examples.security.ExampleSecurityManager
 --classpath=.
  start server --name=serv2 --start-rest-api --http-service-port=8080 
--http-service-bind-address=localhost --locators=localhost[10334] --classpath=. 
--user=super-user
  connect
  list members

In second VM using gfsh, connect to running cluster as ‘dataAdmin’ (all data 
privileges):
  connect
  create lucene index --name=testIndex --region=testRegion 
--field=__REGION_VALUE_FIELD
  list lucene indexes --with-stats=true   NOTE: This will fail as it 
needs CLUSTER:READ privilege. I can however execute this command on the first 
VM 
  create region --name=testRegion --type=PARTITION_PERSISTENT
  put --key=1 --value=value1 --region=testRegion
  put --key=2 --value=value2 --region=testRegion
  put --key=3 --value=value3 --region=testRegion
  search lucene --name=testIndex --region=testRegion --queryStrings=value* 
--defaultField=__REGION_VALUE_FIELD
  NOTE: This fails with message that I need CLUSTER:READ privilege 

The Lucene query will execute a function so I assumed that I needed DATA:WRITE 
privilege and am surprised that I need CLUSTER:READ.
Here is a link to the Lucene Integration spec, illustrating the implementation: 
https://cwiki.apache.org/confluence/display/GEODE/Text+Search+With+Lucene


was (Author: dhardman):
Here are the gfsh commands to reproduce this behavior:
In first VM using gfsh, start up the cluster with 1 locator and 1 server 
configured with security as ‘super-user’ (all cluster and data privileges):
  start locator --name=loc2 
--J=-Dgemfire.security-manager=org.apache.geode.examples.security.ExampleSecurityManager
 --classpath=.
  start server --name=serv2 --start-rest-api --http-service-port=8080 
--http-service-bind-address=localhost --locators=localhost[10334] --classpath=. 
--user=super-user
  connect
  list members

In second VM using gfsh, connect to running cluster as ‘dataAdmin’ (all data 
privileges):
  connect
  create lucene index --name=testIndex --region=testRegion 
--field=__REGION_VALUE_FIELD
  list lucene indexes --with-stats=true   NOTE: This will fail as it needs 
CLUSTER:READ privilege. I can however execute this command on the first VM 
  create region --name=testRegion --type=PARTITION_PERSISTENT
  put --key=1 --value=value1 --region=testRegion
  put --key=2 --value=value2 --region=testRegion
  put --key=3 --value=value3 --region=testRegion
  search lucene --name=testIndex --region=testRegion --queryStrings=value* 
--defaultField=__REGION_VALUE_FIELD
  NOTE: This fails with message that I need CLUSTER:READ privilege 

The Lucene query will execute a function so I assumed that I needed DATA:WRITE 
privilege and am surprised that I need CLUSTER:READ.
Here is a link to the Lucene Integration spec, illustrating the implementation: 
https://cwiki.apache.org/confluence/display/GEODE/Text+Search+With+Lucene

> Unable to do a Lucene query without CLUSTER:READ privilege
> --
>
> Key: GEODE-2605
> URL: https://issues.apache.org/jira/browse/GEODE-2605
> Project: Geode
>  Issue Type: Bug
>  Components: lucene, security
>Reporter: Diane Hardman
> Attachments: security.json
>
>
> I have configured a small cluster with security and am testing the privileges 
> I need for creating a Lucene index and then executing a query/search using 
> Lucene. 
> I have confirmed that DATA:MANAGE privilege allows me to create a lucene 
> index (similar to creating OQL indexes).
> I assumed I needed DATA:WRITE privilege to execute 'search lucene' because 
> the implementation uses a function. Instead, I am getting an error that I 
> need CLUSTER:READ privilege. I don't know why.
> As an aside, we may want to document that all DATA privileges automatically 
> include CLUSTER:READ as I found I could create indexes with DATA:WRITE, but 
> could not list the indexes I created without CLUSTER:READ... go figure.



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

[jira] [Updated] (GEODE-2605) Unable to do a Lucene query without CLUSTER:READ privilege

2017-03-07 Thread Diane Hardman (JIRA)


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

Diane Hardman updated GEODE-2605:
-
Attachment: security.json

The attached security.json file contains the roles and users with different 
privileges assigned to use with this test. This file must be placed under 
./loc2 and ./serv2 directories when security is configured.

> Unable to do a Lucene query without CLUSTER:READ privilege
> --
>
> Key: GEODE-2605
> URL: https://issues.apache.org/jira/browse/GEODE-2605
> Project: Geode
>  Issue Type: Bug
>  Components: lucene, security
>Reporter: Diane Hardman
> Attachments: security.json
>
>
> I have configured a small cluster with security and am testing the privileges 
> I need for creating a Lucene index and then executing a query/search using 
> Lucene. 
> I have confirmed that DATA:MANAGE privilege allows me to create a lucene 
> index (similar to creating OQL indexes).
> I assumed I needed DATA:WRITE privilege to execute 'search lucene' because 
> the implementation uses a function. Instead, I am getting an error that I 
> need CLUSTER:READ privilege. I don't know why.
> As an aside, we may want to document that all DATA privileges automatically 
> include CLUSTER:READ as I found I could create indexes with DATA:WRITE, but 
> could not list the indexes I created without CLUSTER:READ... go figure.



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

[jira] [Commented] (GEODE-2605) Unable to do a Lucene query without CLUSTER:READ privilege

2017-03-07 Thread Diane Hardman (JIRA)


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

Diane Hardman commented on GEODE-2605:
--

Here are the gfsh commands to reproduce this behavior:
In first VM using gfsh, start up the cluster with 1 locator and 1 server 
configured with security as ‘super-user’ (all cluster and data privileges):
  start locator --name=loc2 
--J=-Dgemfire.security-manager=org.apache.geode.examples.security.ExampleSecurityManager
 --classpath=.
  start server --name=serv2 --start-rest-api --http-service-port=8080 
--http-service-bind-address=localhost --locators=localhost[10334] --classpath=. 
--user=super-user
  connect
  list members

In second VM using gfsh, connect to running cluster as ‘dataAdmin’ (all data 
privileges):
  connect
  create lucene index --name=testIndex --region=testRegion 
--field=__REGION_VALUE_FIELD
  list lucene indexes --with-stats=true   NOTE: This will fail as it needs 
CLUSTER:READ privilege. I can however execute this command on the first VM 
  create region --name=testRegion --type=PARTITION_PERSISTENT
  put --key=1 --value=value1 --region=testRegion
  put --key=2 --value=value2 --region=testRegion
  put --key=3 --value=value3 --region=testRegion
  search lucene --name=testIndex --region=testRegion --queryStrings=value* 
--defaultField=__REGION_VALUE_FIELD
  NOTE: This fails with message that I need CLUSTER:READ privilege 

The Lucene query will execute a function so I assumed that I needed DATA:WRITE 
privilege and am surprised that I need CLUSTER:READ.
Here is a link to the Lucene Integration spec, illustrating the implementation: 
https://cwiki.apache.org/confluence/display/GEODE/Text+Search+With+Lucene

> Unable to do a Lucene query without CLUSTER:READ privilege
> --
>
> Key: GEODE-2605
> URL: https://issues.apache.org/jira/browse/GEODE-2605
> Project: Geode
>  Issue Type: Bug
>  Components: lucene, security
>Reporter: Diane Hardman
>
> I have configured a small cluster with security and am testing the privileges 
> I need for creating a Lucene index and then executing a query/search using 
> Lucene. 
> I have confirmed that DATA:MANAGE privilege allows me to create a lucene 
> index (similar to creating OQL indexes).
> I assumed I needed DATA:WRITE privilege to execute 'search lucene' because 
> the implementation uses a function. Instead, I am getting an error that I 
> need CLUSTER:READ privilege. I don't know why.
> As an aside, we may want to document that all DATA privileges automatically 
> include CLUSTER:READ as I found I could create indexes with DATA:WRITE, but 
> could not list the indexes I created without CLUSTER:READ... go figure.



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

[jira] [Commented] (GEODE-2621) CI Failure: ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering

2017-03-07 Thread ASF GitHub Bot (JIRA)


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

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

GitHub user jaredjstewart opened a pull request:

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

GEODE-2621: Reduce time sensitivity of ExportLogsDUnitTest

Precheckin started (still running)

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

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

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

https://github.com/apache/geode/pull/417.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #417


commit 55564a300571bf4bc50c34527480beaf3451c38d
Author: Jared Stewart 
Date:   2017-03-07T23:26:20Z

GEODE-2621: Reduce time sensitivity of ExportLogsDUnitTest




> CI Failure: ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering
> --
>
> Key: GEODE-2621
> URL: https://issues.apache.org/jira/browse/GEODE-2621
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Affects Versions: 1.1.0
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>Priority: Minor
>  Labels: CI, Flaky
>
> {code}
> See 
> 
> Changes:
> [jiliao] GEODE-2267: mark local time sensitive tests as flaky
> [khowe] GEODE-2488: Remove test from flaky category
> [nnag] GEODE-2596: Lucene metrics moved to public API
> [nnag] GEODE-2604: Added javadoc comments to LuceneIndexMetrics.java
> [nnag] GEODE-2604: Added measurement units to the javadoc comments
> --
> [...truncated 99.83 KB...]
> :geode-core:flakyTest
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest > 
> testExportWithStartAndEndDateTimeFiltering FAILED
>java.lang.AssertionError: 
>Expected size:<3> but was:<1> in:
><[/tmp/junit3849272601382305906/unzippedLogs/server-2]>
>at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.verifyZipFileContents(ExportLogsDUnitTest.java:227)
>at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering(ExportLogsDUnitTest.java:157)
> {code}



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

[GitHub] geode pull request #417: GEODE-2621: Reduce time sensitivity of ExportLogsDU...

2017-03-07 Thread jaredjstewart

GitHub user jaredjstewart opened a pull request:

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

GEODE-2621: Reduce time sensitivity of ExportLogsDUnitTest

Precheckin started (still running)

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

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

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

https://github.com/apache/geode/pull/417.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #417


commit 55564a300571bf4bc50c34527480beaf3451c38d
Author: Jared Stewart 
Date:   2017-03-07T23:26:20Z

GEODE-2621: Reduce time sensitivity of ExportLogsDUnitTest




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

[jira] [Updated] (GEODE-2621) CI Failure: ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering

2017-03-07 Thread Jared Stewart (JIRA)


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

Jared Stewart updated GEODE-2621:
-
Priority: Minor  (was: Major)

> CI Failure: ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering
> --
>
> Key: GEODE-2621
> URL: https://issues.apache.org/jira/browse/GEODE-2621
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>Priority: Minor
>  Labels: CI, Flaky
>
> {code}
> See 
> 
> Changes:
> [jiliao] GEODE-2267: mark local time sensitive tests as flaky
> [khowe] GEODE-2488: Remove test from flaky category
> [nnag] GEODE-2596: Lucene metrics moved to public API
> [nnag] GEODE-2604: Added javadoc comments to LuceneIndexMetrics.java
> [nnag] GEODE-2604: Added measurement units to the javadoc comments
> --
> [...truncated 99.83 KB...]
> :geode-core:flakyTest
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest > 
> testExportWithStartAndEndDateTimeFiltering FAILED
>java.lang.AssertionError: 
>Expected size:<3> but was:<1> in:
><[/tmp/junit3849272601382305906/unzippedLogs/server-2]>
>at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.verifyZipFileContents(ExportLogsDUnitTest.java:227)
>at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering(ExportLogsDUnitTest.java:157)
> {code}



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

[jira] [Updated] (GEODE-2621) CI Failure: ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering

2017-03-07 Thread Jared Stewart (JIRA)


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

Jared Stewart updated GEODE-2621:
-
Affects Version/s: 1.1.0

> CI Failure: ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering
> --
>
> Key: GEODE-2621
> URL: https://issues.apache.org/jira/browse/GEODE-2621
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Affects Versions: 1.1.0
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>Priority: Minor
>  Labels: CI, Flaky
>
> {code}
> See 
> 
> Changes:
> [jiliao] GEODE-2267: mark local time sensitive tests as flaky
> [khowe] GEODE-2488: Remove test from flaky category
> [nnag] GEODE-2596: Lucene metrics moved to public API
> [nnag] GEODE-2604: Added javadoc comments to LuceneIndexMetrics.java
> [nnag] GEODE-2604: Added measurement units to the javadoc comments
> --
> [...truncated 99.83 KB...]
> :geode-core:flakyTest
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest > 
> testExportWithStartAndEndDateTimeFiltering FAILED
>java.lang.AssertionError: 
>Expected size:<3> but was:<1> in:
><[/tmp/junit3849272601382305906/unzippedLogs/server-2]>
>at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.verifyZipFileContents(ExportLogsDUnitTest.java:227)
>at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering(ExportLogsDUnitTest.java:157)
> {code}



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

[jira] [Updated] (GEODE-2621) CI Failure: ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering

2017-03-07 Thread Jared Stewart (JIRA)


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

Jared Stewart updated GEODE-2621:
-
Description: 
{code}
See 


Changes:

[jiliao] GEODE-2267: mark local time sensitive tests as flaky

[khowe] GEODE-2488: Remove test from flaky category

[nnag] GEODE-2596: Lucene metrics moved to public API

[nnag] GEODE-2604: Added javadoc comments to LuceneIndexMetrics.java

[nnag] GEODE-2604: Added measurement units to the javadoc comments

--
[...truncated 99.83 KB...]
:geode-core:flakyTest

org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest > 
testExportWithStartAndEndDateTimeFiltering FAILED
   java.lang.AssertionError: 
   Expected size:<3> but was:<1> in:
   <[/tmp/junit3849272601382305906/unzippedLogs/server-2]>
   at 
org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.verifyZipFileContents(ExportLogsDUnitTest.java:227)
   at 
org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering(ExportLogsDUnitTest.java:157)
{code}

  was:
```
See 


Changes:

[jiliao] GEODE-2267: mark local time sensitive tests as flaky

[khowe] GEODE-2488: Remove test from flaky category

[nnag] GEODE-2596: Lucene metrics moved to public API

[nnag] GEODE-2604: Added javadoc comments to LuceneIndexMetrics.java

[nnag] GEODE-2604: Added measurement units to the javadoc comments

--
[...truncated 99.83 KB...]
:geode-core:flakyTest

org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest > 
testExportWithStartAndEndDateTimeFiltering FAILED
   java.lang.AssertionError: 
   Expected size:<3> but was:<1> in:
   <[/tmp/junit3849272601382305906/unzippedLogs/server-2]>
   at 
org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.verifyZipFileContents(ExportLogsDUnitTest.java:227)
   at 
org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering(ExportLogsDUnitTest.java:157)
```


> CI Failure: ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering
> --
>
> Key: GEODE-2621
> URL: https://issues.apache.org/jira/browse/GEODE-2621
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> {code}
> See 
> 
> Changes:
> [jiliao] GEODE-2267: mark local time sensitive tests as flaky
> [khowe] GEODE-2488: Remove test from flaky category
> [nnag] GEODE-2596: Lucene metrics moved to public API
> [nnag] GEODE-2604: Added javadoc comments to LuceneIndexMetrics.java
> [nnag] GEODE-2604: Added measurement units to the javadoc comments
> --
> [...truncated 99.83 KB...]
> :geode-core:flakyTest
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest > 
> testExportWithStartAndEndDateTimeFiltering FAILED
>java.lang.AssertionError: 
>Expected size:<3> but was:<1> in:
><[/tmp/junit3849272601382305906/unzippedLogs/server-2]>
>at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.verifyZipFileContents(ExportLogsDUnitTest.java:227)
>at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering(ExportLogsDUnitTest.java:157)
> {code}



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

[jira] [Updated] (GEODE-2621) CI Failure: ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering

2017-03-07 Thread Jared Stewart (JIRA)


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

Jared Stewart updated GEODE-2621:
-
Labels: CI Flaky  (was: )

> CI Failure: ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering
> --
>
> Key: GEODE-2621
> URL: https://issues.apache.org/jira/browse/GEODE-2621
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>  Labels: CI, Flaky
>
> {code}
> See 
> 
> Changes:
> [jiliao] GEODE-2267: mark local time sensitive tests as flaky
> [khowe] GEODE-2488: Remove test from flaky category
> [nnag] GEODE-2596: Lucene metrics moved to public API
> [nnag] GEODE-2604: Added javadoc comments to LuceneIndexMetrics.java
> [nnag] GEODE-2604: Added measurement units to the javadoc comments
> --
> [...truncated 99.83 KB...]
> :geode-core:flakyTest
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest > 
> testExportWithStartAndEndDateTimeFiltering FAILED
>java.lang.AssertionError: 
>Expected size:<3> but was:<1> in:
><[/tmp/junit3849272601382305906/unzippedLogs/server-2]>
>at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.verifyZipFileContents(ExportLogsDUnitTest.java:227)
>at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering(ExportLogsDUnitTest.java:157)
> {code}



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

[jira] [Created] (GEODE-2621) CI Failure: ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering

2017-03-07 Thread Jared Stewart (JIRA)

Jared Stewart created GEODE-2621:


 Summary: CI Failure: 
ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering
 Key: GEODE-2621
 URL: https://issues.apache.org/jira/browse/GEODE-2621
 Project: Geode
  Issue Type: Bug
  Components: management
Reporter: Jared Stewart


```
See 


Changes:

[jiliao] GEODE-2267: mark local time sensitive tests as flaky

[khowe] GEODE-2488: Remove test from flaky category

[nnag] GEODE-2596: Lucene metrics moved to public API

[nnag] GEODE-2604: Added javadoc comments to LuceneIndexMetrics.java

[nnag] GEODE-2604: Added measurement units to the javadoc comments

--
[...truncated 99.83 KB...]
:geode-core:flakyTest

org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest > 
testExportWithStartAndEndDateTimeFiltering FAILED
   java.lang.AssertionError: 
   Expected size:<3> but was:<1> in:
   <[/tmp/junit3849272601382305906/unzippedLogs/server-2]>
   at 
org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.verifyZipFileContents(ExportLogsDUnitTest.java:227)
   at 
org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering(ExportLogsDUnitTest.java:157)
```



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

[jira] [Created] (GEODE-2620) Remove rate stats from LuceneIndexMetrices

2017-03-07 Thread nabarun (JIRA)

nabarun created GEODE-2620:
--

 Summary: Remove rate stats from LuceneIndexMetrices
 Key: GEODE-2620
 URL: https://issues.apache.org/jira/browse/GEODE-2620
 Project: Geode
  Issue Type: Bug
Reporter: nabarun


Remove stats like 
commitRate
updateRate
queryExecutionRate



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

[jira] [Resolved] (GEODE-1198) CI Failure: DistributedSystemDUnitTest.testConflictingUDPPort

2017-03-07 Thread Kirk Lund (JIRA)


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

Kirk Lund resolved GEODE-1198.
--
   Resolution: Fixed
Fix Version/s: (was: 1.0.0-incubating.M3)
   1.2.0

See also GEODE-2593. All tests in DistributedSystemDUnitTest now correctly use 
port ranges that are entirely free.

> CI Failure: DistributedSystemDUnitTest.testConflictingUDPPort
> -
>
> Key: GEODE-1198
> URL: https://issues.apache.org/jira/browse/GEODE-1198
> Project: Geode
>  Issue Type: Bug
>  Components: membership, tests
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>  Labels: Flaky
> Fix For: 1.2.0
>
>
> Geode_develop_DistributedTests/2178/
> Revision: 7413804dec6acc1077618d50459e07200ced8336
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.distributed.DistributedSystemDUnitTest$2.run in VM 1 
> running on Host rooktwo.gemstone.com with 4 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.distributed.DistributedSystemDUnitTest.testConflictingUDPPort(DistributedSystemDUnitTest.java:380)
>   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: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 
>

[GitHub] geode pull request #416: GEODE-2618: PrimaryBucketExceptions handled in Luce...

2017-03-07 Thread nabarunnag

GitHub user nabarunnag opened a pull request:

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

GEODE-2618: PrimaryBucketExceptions handled in LuceneQueryFunction.exâ¦

â¦ecute

* PrimaryBucketException while executing a LuceneQuery will now be 
caught and wrapped as a InternalFunctionInvocationTargetException
* This will trigger a re-execution of the LuceneQuery on the member 
which will have the primary bucket.

@jhuynh1 @upthewaterspout @boglesby @gesterzhou @ladyVader 

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

$ git pull https://github.com/nabarunnag/incubator-geode feature/GEODE-2618

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

https://github.com/apache/geode/pull/416.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #416


commit bdbde172845c91bc6c5d53fbd8528bb78ffe27a5
Author: nabarun 
Date:   2017-03-07T22:55:54Z

GEODE-2618: PrimaryBucketExceptions handled in LuceneQueryFunction.execute

* PrimaryBucketException while executing a LuceneQuery will now be 
caught and wrapped as a InternalFunctionInvocationTargetException
* This will trigger a re-execution of the LuceneQuery on the member 
which will have the primary bucket.




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

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

2017-03-07 Thread Spring CI


---
Spring Data GemFire > Nightly-ApacheGeode > #493 was successful.
---
Scheduled
1682 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

Re: Review Request 57206: let LuceneResultStruct to be Serializable, then customer does not have to defined their Serializable class to hold result

2017-03-07 Thread Dan Smith

On Tue, Mar 7, 2017 at 2:30 PM, Xiaojian Zhou  wrote:

> If so, we have to implement fromData() and toData() in
> LuceneResultStructImpl.java for K and V. But we don't know their type yet.
>
> You don't need to know the type, you just call DataSerializer.writeObject.

-Dan

[jira] [Resolved] (GEODE-2583) Client can register a type with the server

2017-03-07 Thread Addison (JIRA)


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

Addison resolved GEODE-2583.

Resolution: REMIND

> Client can register a type with the server
> --
>
> Key: GEODE-2583
> URL: https://issues.apache.org/jira/browse/GEODE-2583
> Project: Geode
>  Issue Type: Sub-task
>  Components: messaging
>Reporter: Addison
>
> The client should be able to send a message to register a new type with the 
> server.



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

[jira] [Created] (GEODE-2619) Function execution on server must handle CacheClosedException

2017-03-07 Thread nabarun (JIRA)

nabarun created GEODE-2619:
--

 Summary: Function execution on server must handle 
CacheClosedException
 Key: GEODE-2619
 URL: https://issues.apache.org/jira/browse/GEODE-2619
 Project: Geode
  Issue Type: Bug
  Components: functions
Reporter: nabarun


While a client is executing a function on a server, and the connection is 
disconnected, it must throw a CacheClosedException.

Currently, executeOnServer method in ServerRegionFunctionExecutor class wraps 
the CacheClosedException into a FunctionException and throws it.



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

[jira] [Assigned] (GEODE-2618) Catch PrimaryBucketException in LuceneQueryFunction

2017-03-07 Thread nabarun (JIRA)


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

nabarun reassigned GEODE-2618:
--

Assignee: nabarun

> Catch PrimaryBucketException in LuceneQueryFunction
> ---
>
> Key: GEODE-2618
> URL: https://issues.apache.org/jira/browse/GEODE-2618
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: nabarun
>Assignee: nabarun
>
> Issue:
> PrimaryBucketException when a member bucket stops being primary while the 
> lucene query was being executed. This results in an failure. We want to 
> re-attempt the query execution so that it is executed on the member 
> containing the primary bucket.
> Solution:
> Catch PrimaryBucketException in execute method in LuceneQueryFunction and 
> throw it as an InternalFunctionInvocationException so that the Lucene Query 
> is reexecuted.



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

[jira] [Created] (GEODE-2618) Catch PrimaryBucketException in LuceneQueryFunction

2017-03-07 Thread nabarun (JIRA)

nabarun created GEODE-2618:
--

 Summary: Catch PrimaryBucketException in LuceneQueryFunction
 Key: GEODE-2618
 URL: https://issues.apache.org/jira/browse/GEODE-2618
 Project: Geode
  Issue Type: Bug
  Components: lucene
Reporter: nabarun


Issue:
PrimaryBucketException when a member bucket stops being primary while the 
lucene query was being executed. This results in an failure. We want to 
re-attempt the query execution so that it is executed on the member containing 
the primary bucket.

Solution:
Catch PrimaryBucketException in execute method in LuceneQueryFunction and throw 
it as an InternalFunctionInvocationException so that the Lucene Query is 
reexecuted.



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

[jira] [Commented] (GEODE-2617) LuceneResultStruct should be Serializable

2017-03-07 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on GEODE-2617:


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

GEODE-2617: make LuceneResultStruct serializable


> LuceneResultStruct should be Serializable
> -
>
> Key: GEODE-2617
> URL: https://issues.apache.org/jira/browse/GEODE-2617
> Project: Geode
>  Issue Type: Bug
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>
> let LuceneResultStruct to be Serializable, then customer does not have to 
> defined their Serializable class to hold result.



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

[jira] [Resolved] (GEODE-2617) LuceneResultStruct should be Serializable

2017-03-07 Thread xiaojian zhou (JIRA)


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

xiaojian zhou resolved GEODE-2617.
--
Resolution: Fixed

> LuceneResultStruct should be Serializable
> -
>
> Key: GEODE-2617
> URL: https://issues.apache.org/jira/browse/GEODE-2617
> Project: Geode
>  Issue Type: Bug
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>
> let LuceneResultStruct to be Serializable, then customer does not have to 
> defined their Serializable class to hold result.



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

Re: Review Request 57206: let LuceneResultStruct to be Serializable, then customer does not have to defined their Serializable class to hold result

2017-03-07 Thread Xiaojian Zhou

If so, we have to implement fromData() and toData() in
LuceneResultStructImpl.java for K and V. But we don't know their type yet.

On Tue, Mar 7, 2017 at 2:25 PM, Dan Smith  wrote:

>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57206/#review168203
> ---
>
>
>
> It looks good - my one question is if this should be
> DataSerializableFixedID or something like that, so that it can be
> serialized more efficiently and we can manage backwards compatibility?
>
> - Dan Smith
>
>
> On March 7, 2017, 10:03 p.m., xiaojian zhou wrote:
> >
> > ---
> > This is an automatically generated e-mail. To reply, visit:
> > https://reviews.apache.org/r/57206/
> > ---
> >
> > (Updated March 7, 2017, 10:03 p.m.)
> >
> >
> > Review request for geode, Barry Oglesby and Dan Smith.
> >
> >
> > Bugs: GEODE-2617
> > https://issues.apache.org/jira/browse/GEODE-2617
> >
> >
> > Repository: geode
> >
> >
> > Description
> > ---
> >
> > If customer call a lucene query in a function, they need to define their
> own Serializable class to collect results. This has been complained by
> field engineer.
> >
> > It will not hurt to let LuceneResultStruct to extend Serializable
> >
> >
> > Diffs
> > -
> >
> >   
> > geode-lucene/src/main/java/org/apache/geode/cache/lucene/LuceneResultStruct.java
> b922185
> >
> >
> > Diff: https://reviews.apache.org/r/57206/diff/1/
> >
> >
> > Testing
> > ---
> >
> >
> > Thanks,
> >
> > xiaojian zhou
> >
> >
>
>

[jira] [Commented] (GEODE-1198) CI Failure: DistributedSystemDUnitTest.testConflictingUDPPort

2017-03-07 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on GEODE-1198:


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

GEODE-1198: refactor test with before/after and cleanup use of ports


> CI Failure: DistributedSystemDUnitTest.testConflictingUDPPort
> -
>
> Key: GEODE-1198
> URL: https://issues.apache.org/jira/browse/GEODE-1198
> Project: Geode
>  Issue Type: Bug
>  Components: membership, tests
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>  Labels: Flaky
> Fix For: 1.0.0-incubating.M3
>
>
> Geode_develop_DistributedTests/2178/
> Revision: 7413804dec6acc1077618d50459e07200ced8336
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.distributed.DistributedSystemDUnitTest$2.run in VM 1 
> running on Host rooktwo.gemstone.com with 4 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.distributed.DistributedSystemDUnitTest.testConflictingUDPPort(DistributedSystemDUnitTest.java:380)
>   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: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 
>

Re: Review Request 57206: let LuceneResultStruct to be Serializable, then customer does not have to defined their Serializable class to hold result

2017-03-07 Thread Dan Smith


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



It looks good - my one question is if this should be DataSerializableFixedID or 
something like that, so that it can be serialized more efficiently and we can 
manage backwards compatibility?

- Dan Smith


On March 7, 2017, 10:03 p.m., xiaojian zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57206/
> ---
> 
> (Updated March 7, 2017, 10:03 p.m.)
> 
> 
> Review request for geode, Barry Oglesby and Dan Smith.
> 
> 
> Bugs: GEODE-2617
> https://issues.apache.org/jira/browse/GEODE-2617
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> If customer call a lucene query in a function, they need to define their own 
> Serializable class to collect results. This has been complained by field 
> engineer. 
> 
> It will not hurt to let LuceneResultStruct to extend Serializable
> 
> 
> Diffs
> -
> 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/LuceneResultStruct.java
>  b922185 
> 
> 
> Diff: https://reviews.apache.org/r/57206/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> xiaojian zhou
> 
>

[jira] [Assigned] (GEODE-2617) LuceneResultStruct should be Serializable

2017-03-07 Thread xiaojian zhou (JIRA)


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

xiaojian zhou reassigned GEODE-2617:


Assignee: xiaojian zhou

> LuceneResultStruct should be Serializable
> -
>
> Key: GEODE-2617
> URL: https://issues.apache.org/jira/browse/GEODE-2617
> Project: Geode
>  Issue Type: Bug
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>
> let LuceneResultStruct to be Serializable, then customer does not have to 
> defined their Serializable class to hold result.



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

Re: Review Request 57206: let LuceneResultStruct to be Serializable, then customer does not have to defined their Serializable class to hold result

2017-03-07 Thread xiaojian zhou


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

(Updated March 7, 2017, 10:03 p.m.)


Review request for geode, Barry Oglesby and Dan Smith.


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


Repository: geode


Description
---

If customer call a lucene query in a function, they need to define their own 
Serializable class to collect results. This has been complained by field 
engineer. 

It will not hurt to let LuceneResultStruct to extend Serializable


Diffs
-

  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/LuceneResultStruct.java
 b922185 


Diff: https://reviews.apache.org/r/57206/diff/1/


Testing
---


Thanks,

xiaojian zhou

[jira] [Created] (GEODE-2617) LuceneResultStruct should be Serializable

2017-03-07 Thread xiaojian zhou (JIRA)

xiaojian zhou created GEODE-2617:


 Summary: LuceneResultStruct should be Serializable
 Key: GEODE-2617
 URL: https://issues.apache.org/jira/browse/GEODE-2617
 Project: Geode
  Issue Type: Bug
Reporter: xiaojian zhou


let LuceneResultStruct to be Serializable, then customer does not have to 
defined their Serializable class to hold result.





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

[jira] [Resolved] (GEODE-2570) Export cluster-configuration returns "GemFire error" message

2017-03-07 Thread Jinmei Liao (JIRA)


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

Jinmei Liao resolved GEODE-2570.

Resolution: Fixed

already fixed on develop. workaround supplied if using 1.1.0. 

> Export cluster-configuration returns "GemFire error" message
> 
>
> Key: GEODE-2570
> URL: https://issues.apache.org/jira/browse/GEODE-2570
> Project: Geode
>  Issue Type: Bug
>  Components: configuration, gfsh
>Reporter: Wes Williams
> Fix For: 1.2.0
>
>
> gfsh>version
> 1.1.0
> gfsh>start locator --name=locator1 --port=10334 
> --properties-file=config/locator.properties 
> --load-cluster-configuration-from-dir=true --initial-heap=256m --max-heap=256m
> gfsh>start server --name=server1 --server-port=0 
> --properties-file=config/gemfire.properties --initial-heap=1g --max-heap=1g
> gfsh>list regions
> No Regions Found
> gfsh>list members
>   Name   | Id
>  | 
> locator1 | 192.168.0.5(locator1:43398:locator):1024
> server1  | 192.168.0.5(server1:43404):1025
> gfsh>create region --name=Test --type=PARTITION
> Member  | Status
> --- | ---
> server1 | Region "/Test" created on "server1"
> gfsh>export cluster-configuration --zip-file-name=test.zip
> Could not process command due to GemFire error. Error while processing 
> command  Reason : null
> [info 2017/03/01 16:27:55.414 EST locator1  Connection(6)-192.168.0.5> tid=0x6c] (tid=108 msgId=72) Could not execute 
> "export cluster-configuration --zip-file-name=test.zip".
> java.lang.NullPointerException
>   at 
> org.apache.geode.management.internal.cli.commands.ExportImportClusterConfigurationCommands.exportSharedConfig(ExportImportClusterConfigurationCommands.java:85)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:216)
>   at 
> org.apache.geode.management.internal.cli.remote.RemoteExecutionStrategy.execute(RemoteExecutionStrategy.java:91)
>   at 
> org.apache.geode.management.internal.cli.remote.CommandProcessor.executeCommand(CommandProcessor.java:117)
>   at 
> org.apache.geode.management.internal.cli.remote.CommandStatementImpl.process(CommandStatementImpl.java:71)
>   at 
> org.apache.geode.management.internal.cli.remote.MemberCommandService.processCommand(MemberCommandService.java:52)
>   at 
> org.apache.geode.management.internal.beans.MemberMBeanBridge.processCommand(MemberMBeanBridge.java:1639)
>   at 
> org.apache.geode.management.internal.beans.MemberMBean.processCommand(MemberMBean.java:404)
>   at 
> org.apache.geode.management.internal.beans.MemberMBean.processCommand(MemberMBean.java:397)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
>   at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
>   at 
> com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:193)
>   at 
> com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:175)
>   at 
> com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:117)
>   at 
> com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:54)
>   at 
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
>   at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
>   at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
>   at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1466)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
>   at 
>

[jira] [Assigned] (GEODE-2570) Export cluster-configuration returns "GemFire error" message

2017-03-07 Thread Jinmei Liao (JIRA)


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

Jinmei Liao reassigned GEODE-2570:
--

Assignee: Jinmei Liao

> Export cluster-configuration returns "GemFire error" message
> 
>
> Key: GEODE-2570
> URL: https://issues.apache.org/jira/browse/GEODE-2570
> Project: Geode
>  Issue Type: Bug
>  Components: configuration, gfsh
>Reporter: Wes Williams
>Assignee: Jinmei Liao
> Fix For: 1.2.0
>
>
> gfsh>version
> 1.1.0
> gfsh>start locator --name=locator1 --port=10334 
> --properties-file=config/locator.properties 
> --load-cluster-configuration-from-dir=true --initial-heap=256m --max-heap=256m
> gfsh>start server --name=server1 --server-port=0 
> --properties-file=config/gemfire.properties --initial-heap=1g --max-heap=1g
> gfsh>list regions
> No Regions Found
> gfsh>list members
>   Name   | Id
>  | 
> locator1 | 192.168.0.5(locator1:43398:locator):1024
> server1  | 192.168.0.5(server1:43404):1025
> gfsh>create region --name=Test --type=PARTITION
> Member  | Status
> --- | ---
> server1 | Region "/Test" created on "server1"
> gfsh>export cluster-configuration --zip-file-name=test.zip
> Could not process command due to GemFire error. Error while processing 
> command  Reason : null
> [info 2017/03/01 16:27:55.414 EST locator1  Connection(6)-192.168.0.5> tid=0x6c] (tid=108 msgId=72) Could not execute 
> "export cluster-configuration --zip-file-name=test.zip".
> java.lang.NullPointerException
>   at 
> org.apache.geode.management.internal.cli.commands.ExportImportClusterConfigurationCommands.exportSharedConfig(ExportImportClusterConfigurationCommands.java:85)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:216)
>   at 
> org.apache.geode.management.internal.cli.remote.RemoteExecutionStrategy.execute(RemoteExecutionStrategy.java:91)
>   at 
> org.apache.geode.management.internal.cli.remote.CommandProcessor.executeCommand(CommandProcessor.java:117)
>   at 
> org.apache.geode.management.internal.cli.remote.CommandStatementImpl.process(CommandStatementImpl.java:71)
>   at 
> org.apache.geode.management.internal.cli.remote.MemberCommandService.processCommand(MemberCommandService.java:52)
>   at 
> org.apache.geode.management.internal.beans.MemberMBeanBridge.processCommand(MemberMBeanBridge.java:1639)
>   at 
> org.apache.geode.management.internal.beans.MemberMBean.processCommand(MemberMBean.java:404)
>   at 
> org.apache.geode.management.internal.beans.MemberMBean.processCommand(MemberMBean.java:397)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
>   at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
>   at 
> com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:193)
>   at 
> com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:175)
>   at 
> com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:117)
>   at 
> com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:54)
>   at 
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
>   at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
>   at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
>   at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1466)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
>   at 
>

[jira] [Assigned] (GEODE-2570) Export cluster-configuration returns "GemFire error" message

2017-03-07 Thread Jinmei Liao (JIRA)


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

Jinmei Liao reassigned GEODE-2570:
--

Assignee: (was: Jinmei Liao)

> Export cluster-configuration returns "GemFire error" message
> 
>
> Key: GEODE-2570
> URL: https://issues.apache.org/jira/browse/GEODE-2570
> Project: Geode
>  Issue Type: Bug
>  Components: configuration, gfsh
>Reporter: Wes Williams
> Fix For: 1.2.0
>
>
> gfsh>version
> 1.1.0
> gfsh>start locator --name=locator1 --port=10334 
> --properties-file=config/locator.properties 
> --load-cluster-configuration-from-dir=true --initial-heap=256m --max-heap=256m
> gfsh>start server --name=server1 --server-port=0 
> --properties-file=config/gemfire.properties --initial-heap=1g --max-heap=1g
> gfsh>list regions
> No Regions Found
> gfsh>list members
>   Name   | Id
>  | 
> locator1 | 192.168.0.5(locator1:43398:locator):1024
> server1  | 192.168.0.5(server1:43404):1025
> gfsh>create region --name=Test --type=PARTITION
> Member  | Status
> --- | ---
> server1 | Region "/Test" created on "server1"
> gfsh>export cluster-configuration --zip-file-name=test.zip
> Could not process command due to GemFire error. Error while processing 
> command  Reason : null
> [info 2017/03/01 16:27:55.414 EST locator1  Connection(6)-192.168.0.5> tid=0x6c] (tid=108 msgId=72) Could not execute 
> "export cluster-configuration --zip-file-name=test.zip".
> java.lang.NullPointerException
>   at 
> org.apache.geode.management.internal.cli.commands.ExportImportClusterConfigurationCommands.exportSharedConfig(ExportImportClusterConfigurationCommands.java:85)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:216)
>   at 
> org.apache.geode.management.internal.cli.remote.RemoteExecutionStrategy.execute(RemoteExecutionStrategy.java:91)
>   at 
> org.apache.geode.management.internal.cli.remote.CommandProcessor.executeCommand(CommandProcessor.java:117)
>   at 
> org.apache.geode.management.internal.cli.remote.CommandStatementImpl.process(CommandStatementImpl.java:71)
>   at 
> org.apache.geode.management.internal.cli.remote.MemberCommandService.processCommand(MemberCommandService.java:52)
>   at 
> org.apache.geode.management.internal.beans.MemberMBeanBridge.processCommand(MemberMBeanBridge.java:1639)
>   at 
> org.apache.geode.management.internal.beans.MemberMBean.processCommand(MemberMBean.java:404)
>   at 
> org.apache.geode.management.internal.beans.MemberMBean.processCommand(MemberMBean.java:397)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
>   at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
>   at 
> com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:193)
>   at 
> com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:175)
>   at 
> com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:117)
>   at 
> com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:54)
>   at 
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
>   at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
>   at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
>   at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1466)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
>   at 
>

[jira] [Updated] (GEODE-2570) Export cluster-configuration returns "GemFire error" message

2017-03-07 Thread Jinmei Liao (JIRA)


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

Jinmei Liao updated GEODE-2570:
---
Fix Version/s: (was: 1.1.0)

> Export cluster-configuration returns "GemFire error" message
> 
>
> Key: GEODE-2570
> URL: https://issues.apache.org/jira/browse/GEODE-2570
> Project: Geode
>  Issue Type: Bug
>  Components: configuration, gfsh
>Reporter: Wes Williams
> Fix For: 1.2.0
>
>
> gfsh>version
> 1.1.0
> gfsh>start locator --name=locator1 --port=10334 
> --properties-file=config/locator.properties 
> --load-cluster-configuration-from-dir=true --initial-heap=256m --max-heap=256m
> gfsh>start server --name=server1 --server-port=0 
> --properties-file=config/gemfire.properties --initial-heap=1g --max-heap=1g
> gfsh>list regions
> No Regions Found
> gfsh>list members
>   Name   | Id
>  | 
> locator1 | 192.168.0.5(locator1:43398:locator):1024
> server1  | 192.168.0.5(server1:43404):1025
> gfsh>create region --name=Test --type=PARTITION
> Member  | Status
> --- | ---
> server1 | Region "/Test" created on "server1"
> gfsh>export cluster-configuration --zip-file-name=test.zip
> Could not process command due to GemFire error. Error while processing 
> command  Reason : null
> [info 2017/03/01 16:27:55.414 EST locator1  Connection(6)-192.168.0.5> tid=0x6c] (tid=108 msgId=72) Could not execute 
> "export cluster-configuration --zip-file-name=test.zip".
> java.lang.NullPointerException
>   at 
> org.apache.geode.management.internal.cli.commands.ExportImportClusterConfigurationCommands.exportSharedConfig(ExportImportClusterConfigurationCommands.java:85)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:216)
>   at 
> org.apache.geode.management.internal.cli.remote.RemoteExecutionStrategy.execute(RemoteExecutionStrategy.java:91)
>   at 
> org.apache.geode.management.internal.cli.remote.CommandProcessor.executeCommand(CommandProcessor.java:117)
>   at 
> org.apache.geode.management.internal.cli.remote.CommandStatementImpl.process(CommandStatementImpl.java:71)
>   at 
> org.apache.geode.management.internal.cli.remote.MemberCommandService.processCommand(MemberCommandService.java:52)
>   at 
> org.apache.geode.management.internal.beans.MemberMBeanBridge.processCommand(MemberMBeanBridge.java:1639)
>   at 
> org.apache.geode.management.internal.beans.MemberMBean.processCommand(MemberMBean.java:404)
>   at 
> org.apache.geode.management.internal.beans.MemberMBean.processCommand(MemberMBean.java:397)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
>   at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
>   at 
> com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:193)
>   at 
> com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:175)
>   at 
> com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:117)
>   at 
> com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:54)
>   at 
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
>   at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
>   at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
>   at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1466)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1307)

[jira] [Resolved] (GEODE-2593) DistributedSystemDUnitTest.testUDPPortRange fails intermittently with SystemConnectException: Unable to find a free port in the membership-port-range

2017-03-07 Thread Kirk Lund (JIRA)


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

Kirk Lund resolved GEODE-2593.
--
   Resolution: Fixed
Fix Version/s: 1.2.0

> DistributedSystemDUnitTest.testUDPPortRange fails intermittently with 
> SystemConnectException: Unable to find a free port in the 
> membership-port-range
> -
>
> Key: GEODE-2593
> URL: https://issues.apache.org/jira/browse/GEODE-2593
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>  Labels: Flaky
> Fix For: 1.2.0
>
>
> DistributedSystemDUnitTest.testUDPPortRange fails intermittently because it 
> finds a free port and then assume that two adjacent ports are also free.
> {noformat}
> org.apache.geode.GemFireConfigException: Unable to allocate a failure 
> detection port in the membership-port range
>   at 
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.createServerSocket(GMSHealthMonitor.java:675)
>   at 
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.started(GMSHealthMonitor.java:941)
>   at 
> org.apache.geode.distributed.internal.membership.gms.Services.start(Services.java:171)
>   at 
> org.apache.geode.distributed.internal.membership.gms.GMSMemberFactory.newMembershipManager(GMSMemberFactory.java:102)
>   at 
> org.apache.geode.distributed.internal.membership.MemberFactory.newMembershipManager(MemberFactory.java:89)
>   at 
> org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1112)
>   at 
> org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1160)
>   at 
> org.apache.geode.distributed.internal.DistributionManager.create(DistributionManager.java:531)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:687)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:299)
>   at 
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:206)
>   at 
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.getSystem(JUnit4DistributedTestCase.java:197)
>   at 
> org.apache.geode.distributed.DistributedSystemDUnitTest.testUDPPortRange(DistributedSystemDUnitTest.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:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.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 
>

[jira] [Assigned] (GEODE-2593) DistributedSystemDUnitTest.testUDPPortRange fails intermittently with SystemConnectException: Unable to find a free port in the membership-port-range

2017-03-07 Thread Kirk Lund (JIRA)


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

Kirk Lund reassigned GEODE-2593:


Assignee: Kirk Lund

> DistributedSystemDUnitTest.testUDPPortRange fails intermittently with 
> SystemConnectException: Unable to find a free port in the 
> membership-port-range
> -
>
> Key: GEODE-2593
> URL: https://issues.apache.org/jira/browse/GEODE-2593
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>  Labels: Flaky
>
> DistributedSystemDUnitTest.testUDPPortRange fails intermittently because it 
> finds a free port and then assume that two adjacent ports are also free.
> {noformat}
> org.apache.geode.GemFireConfigException: Unable to allocate a failure 
> detection port in the membership-port range
>   at 
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.createServerSocket(GMSHealthMonitor.java:675)
>   at 
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.started(GMSHealthMonitor.java:941)
>   at 
> org.apache.geode.distributed.internal.membership.gms.Services.start(Services.java:171)
>   at 
> org.apache.geode.distributed.internal.membership.gms.GMSMemberFactory.newMembershipManager(GMSMemberFactory.java:102)
>   at 
> org.apache.geode.distributed.internal.membership.MemberFactory.newMembershipManager(MemberFactory.java:89)
>   at 
> org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1112)
>   at 
> org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1160)
>   at 
> org.apache.geode.distributed.internal.DistributionManager.create(DistributionManager.java:531)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:687)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:299)
>   at 
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:206)
>   at 
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.getSystem(JUnit4DistributedTestCase.java:197)
>   at 
> org.apache.geode.distributed.DistributedSystemDUnitTest.testUDPPortRange(DistributedSystemDUnitTest.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:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.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

Re: Review Request 57390: GEODE-2539: Upgrading Jetty causes RestSecurityItegrationTest to fail

2017-03-07 Thread Jinmei Liao


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


Ship it!




Ship It!

- Jinmei Liao


On March 7, 2017, 7:09 p.m., Kevin Duling wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57390/
> ---
> 
> (Updated March 7, 2017, 7:09 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2539: Upgrading Jetty causes RestSecurityItegrationTest to fail
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityIntegrationTest.java
>  75a3c2c0996972cab26dc6dad79f675ddfb8f6b3 
>   gradle/dependency-versions.properties 
> 34e5d67882c5d1cd82cce04e31ebc69dab6f4251 
> 
> 
> Diff: https://reviews.apache.org/r/57390/diff/2/
> 
> 
> Testing
> ---
> 
> precheckin running
> 
> Ran the test 20 times by hand locally without failure: `./gradlew 
> geode-assembly:integrationTest 
> -DintegrationTest.single=RestSecurityIntegrationTest`
> 
> 
> Thanks,
> 
> Kevin Duling
> 
>

Re: Review Request 57390: GEODE-2539: Upgrading Jetty causes RestSecurityItegrationTest to fail

2017-03-07 Thread Kirk Lund


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


Ship it!




Ship It!

- Kirk Lund


On March 7, 2017, 7:09 p.m., Kevin Duling wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57390/
> ---
> 
> (Updated March 7, 2017, 7:09 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2539: Upgrading Jetty causes RestSecurityItegrationTest to fail
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityIntegrationTest.java
>  75a3c2c0996972cab26dc6dad79f675ddfb8f6b3 
>   gradle/dependency-versions.properties 
> 34e5d67882c5d1cd82cce04e31ebc69dab6f4251 
> 
> 
> Diff: https://reviews.apache.org/r/57390/diff/2/
> 
> 
> Testing
> ---
> 
> precheckin running
> 
> Ran the test 20 times by hand locally without failure: `./gradlew 
> geode-assembly:integrationTest 
> -DintegrationTest.single=RestSecurityIntegrationTest`
> 
> 
> Thanks,
> 
> Kevin Duling
> 
>

Re: Review Request 57390: GEODE-2539: Upgrading Jetty causes RestSecurityItegrationTest to fail

2017-03-07 Thread Jared Stewart


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


Ship it!




Ship It!

- Jared Stewart


On March 7, 2017, 7:09 p.m., Kevin Duling wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57390/
> ---
> 
> (Updated March 7, 2017, 7:09 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2539: Upgrading Jetty causes RestSecurityItegrationTest to fail
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityIntegrationTest.java
>  75a3c2c0996972cab26dc6dad79f675ddfb8f6b3 
>   gradle/dependency-versions.properties 
> 34e5d67882c5d1cd82cce04e31ebc69dab6f4251 
> 
> 
> Diff: https://reviews.apache.org/r/57390/diff/2/
> 
> 
> Testing
> ---
> 
> precheckin running
> 
> Ran the test 20 times by hand locally without failure: `./gradlew 
> geode-assembly:integrationTest 
> -DintegrationTest.single=RestSecurityIntegrationTest`
> 
> 
> Thanks,
> 
> Kevin Duling
> 
>

[jira] [Assigned] (GEODE-1198) CI Failure: DistributedSystemDUnitTest.testConflictingUDPPort

2017-03-07 Thread Kirk Lund (JIRA)


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

Kirk Lund reassigned GEODE-1198:


Assignee: Kirk Lund  (was: Hitesh Khamesra)

> CI Failure: DistributedSystemDUnitTest.testConflictingUDPPort
> -
>
> Key: GEODE-1198
> URL: https://issues.apache.org/jira/browse/GEODE-1198
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>  Labels: CI
> Fix For: 1.0.0-incubating.M3
>
>
> Geode_develop_DistributedTests/2178/
> Revision: 7413804dec6acc1077618d50459e07200ced8336
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.distributed.DistributedSystemDUnitTest$2.run in VM 1 
> running on Host rooktwo.gemstone.com with 4 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.distributed.DistributedSystemDUnitTest.testConflictingUDPPort(DistributedSystemDUnitTest.java:380)
>   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: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 
>

[jira] [Updated] (GEODE-1198) CI Failure: DistributedSystemDUnitTest.testConflictingUDPPort

2017-03-07 Thread Kirk Lund (JIRA)


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

Kirk Lund updated GEODE-1198:
-
Component/s: tests

> CI Failure: DistributedSystemDUnitTest.testConflictingUDPPort
> -
>
> Key: GEODE-1198
> URL: https://issues.apache.org/jira/browse/GEODE-1198
> Project: Geode
>  Issue Type: Bug
>  Components: membership, tests
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>  Labels: Flaky
> Fix For: 1.0.0-incubating.M3
>
>
> Geode_develop_DistributedTests/2178/
> Revision: 7413804dec6acc1077618d50459e07200ced8336
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.distributed.DistributedSystemDUnitTest$2.run in VM 1 
> running on Host rooktwo.gemstone.com with 4 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.distributed.DistributedSystemDUnitTest.testConflictingUDPPort(DistributedSystemDUnitTest.java:380)
>   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: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 
>

[jira] [Updated] (GEODE-1198) CI Failure: DistributedSystemDUnitTest.testConflictingUDPPort

2017-03-07 Thread Kirk Lund (JIRA)


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

Kirk Lund updated GEODE-1198:
-
Labels: Flaky  (was: CI)

> CI Failure: DistributedSystemDUnitTest.testConflictingUDPPort
> -
>
> Key: GEODE-1198
> URL: https://issues.apache.org/jira/browse/GEODE-1198
> Project: Geode
>  Issue Type: Bug
>  Components: membership, tests
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>  Labels: Flaky
> Fix For: 1.0.0-incubating.M3
>
>
> Geode_develop_DistributedTests/2178/
> Revision: 7413804dec6acc1077618d50459e07200ced8336
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.distributed.DistributedSystemDUnitTest$2.run in VM 1 
> running on Host rooktwo.gemstone.com with 4 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.distributed.DistributedSystemDUnitTest.testConflictingUDPPort(DistributedSystemDUnitTest.java:380)
>   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: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 
>

[jira] [Commented] (GEODE-2578) Query string limited to 64 KiB

2017-03-07 Thread ASF GitHub Bot (JIRA)


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

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

Github user PivotalSarge commented on a diff in the pull request:

https://github.com/apache/geode-native/pull/48#discussion_r104769260
  
--- Diff: src/cppcache/test/TcrMessage_unittest.cpp ---
@@ -559,3 +560,66 @@ TEST_F(TcrMessageTest, 
testConstructorEXECUTE_FUNCTION) {
   "75746546756E6374696F6E00030157",
   testMessage);
 }
+
+TEST_F(TcrMessageTest, testConstructorEXECUTECQ_MSG_TYPE) {
+  CacheablePtr myCacheablePtr(CacheableString::createDeserializable());
+
+  TcrMessageExecuteCq testMessage("ExecuteCQ", "select * from /somewhere",
+  CqState::RUNNING, false,
+  static_cast(NULL));
+
+  EXPECT_EQ(TcrMessage::EXECUTECQ_MSG_TYPE, testMessage.getMessageType());
+
+  EXPECT_MESSAGE_EQ(
+  
"002A00450900457865637574654351001800"
+  
"73656C656374202A2066726F6D202F736F6D65776865726500040100"
+  "0100010001",
+  testMessage);
+}
+
+TEST_F(TcrMessageTest, 
testConstructorWithGinormousQueryEXECUTECQ_MSG_TYPE) {
--- End diff --

I'm unaware of the SI definition of ginormous...


> Query string limited to 64 KiB
> --
>
> Key: GEODE-2578
> URL: https://issues.apache.org/jira/browse/GEODE-2578
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Dodge
>Assignee: Michael Dodge
>
> The serialization of query strings uses a 16-bit unsigned integer to 
> represent the length of the query string. Query strings with more than 65535 
> characters are silently truncated. Use of a 32-bit unsigned integer to 
> represent the length would greatly increase the size of query strings that 
> may be used.



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

[jira] [Commented] (GEODE-2578) Query string limited to 64 KiB

2017-03-07 Thread ASF GitHub Bot (JIRA)


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

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

Github user PivotalSarge commented on a diff in the pull request:

https://github.com/apache/geode-native/pull/48#discussion_r104769132
  
--- Diff: src/cppcache/test/DataOutputTest.cpp ---
@@ -305,15 +305,9 @@ TEST_F(DataOutputTest, TestCursorAdvance) {
   "001B596F7520686164206D65206174206D65617420746F726E61646F2E",
   dataOutput.getByteArray());
 
-  EXPECT_EQ((2 + 27), dataOutput.getBufferLength());
-
-  // buffers are pre-allocated 8k and have 2 bytes to hold the data length
-  EXPECT_EQ(((8 * 1024) - (2 + 27)), 
dataOutput.getRemainingBufferLength());
--- End diff --

getRemainingBufferLength() is the call that exhibited less-than-obvious 
behavior. In particular, it appears to be affected by some global state. Its 
return value was not predictable enough to be tested in that manner.


> Query string limited to 64 KiB
> --
>
> Key: GEODE-2578
> URL: https://issues.apache.org/jira/browse/GEODE-2578
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Dodge
>Assignee: Michael Dodge
>
> The serialization of query strings uses a 16-bit unsigned integer to 
> represent the length of the query string. Query strings with more than 65535 
> characters are silently truncated. Use of a 32-bit unsigned integer to 
> represent the length would greatly increase the size of query strings that 
> may be used.



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

[GitHub] geode-native pull request #48: GEODE-2578: Remove 64 KiB limit on query stri...

2017-03-07 Thread PivotalSarge

Github user PivotalSarge commented on a diff in the pull request:

https://github.com/apache/geode-native/pull/48#discussion_r104769132
  
--- Diff: src/cppcache/test/DataOutputTest.cpp ---
@@ -305,15 +305,9 @@ TEST_F(DataOutputTest, TestCursorAdvance) {
   "001B596F7520686164206D65206174206D65617420746F726E61646F2E",
   dataOutput.getByteArray());
 
-  EXPECT_EQ((2 + 27), dataOutput.getBufferLength());
-
-  // buffers are pre-allocated 8k and have 2 bytes to hold the data length
-  EXPECT_EQ(((8 * 1024) - (2 + 27)), 
dataOutput.getRemainingBufferLength());
--- End diff --

getRemainingBufferLength() is the call that exhibited less-than-obvious 
behavior. In particular, it appears to be affected by some global state. Its 
return value was not predictable enough to be tested in that manner.


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

[jira] [Commented] (GEODE-2578) Query string limited to 64 KiB

2017-03-07 Thread ASF GitHub Bot (JIRA)


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

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

Github user PivotalSarge commented on a diff in the pull request:

https://github.com/apache/geode-native/pull/48#discussion_r104768886
  
--- Diff: src/cppcache/include/geode/DataOutput.hpp ---
@@ -378,9 +378,8 @@ class CPPCACHE_EXPORT DataOutput {
  */
   inline void writeFullUTF(const char* value, uint32_t length = 0) {
 if (value != NULL) {
-  int32_t len = getEncodedLength(value, length);
-  uint16_t encodedLen = static_cast(len > 0x ? 0x : 
len);
--- End diff --

If the query string happened to be longer that 0x, it would be 
artificially truncated which often led to errors on the server side.


> Query string limited to 64 KiB
> --
>
> Key: GEODE-2578
> URL: https://issues.apache.org/jira/browse/GEODE-2578
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Dodge
>Assignee: Michael Dodge
>
> The serialization of query strings uses a 16-bit unsigned integer to 
> represent the length of the query string. Query strings with more than 65535 
> characters are silently truncated. Use of a 32-bit unsigned integer to 
> represent the length would greatly increase the size of query strings that 
> may be used.



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

[GitHub] geode-native pull request #48: GEODE-2578: Remove 64 KiB limit on query stri...

2017-03-07 Thread PivotalSarge

Github user PivotalSarge commented on a diff in the pull request:

https://github.com/apache/geode-native/pull/48#discussion_r104768886
  
--- Diff: src/cppcache/include/geode/DataOutput.hpp ---
@@ -378,9 +378,8 @@ class CPPCACHE_EXPORT DataOutput {
  */
   inline void writeFullUTF(const char* value, uint32_t length = 0) {
 if (value != NULL) {
-  int32_t len = getEncodedLength(value, length);
-  uint16_t encodedLen = static_cast(len > 0x ? 0x : 
len);
--- End diff --

If the query string happened to be longer that 0x, it would be 
artificially truncated which often led to errors on the server side.


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

[GitHub] geode-native pull request #48: GEODE-2578: Remove 64 KiB limit on query stri...

2017-03-07 Thread echobravopapa

Github user echobravopapa commented on a diff in the pull request:

https://github.com/apache/geode-native/pull/48#discussion_r104759431
  
--- Diff: src/cppcache/src/TcrMessage.hpp ---
@@ -555,7 +555,7 @@ class CPPCACHE_EXPORT TcrMessage {
const VectorOfCacheableKey* getAllKeyList = NULL);
   void writeHeader(uint32_t msgType, uint32_t numOfParts);
   void writeRegionPart(const std::string& regionName);
-  void writeStringPart(const std::string& regionName);
+  void writeStringPart(const std::string& str);
--- End diff --

the aforementioned copy/pasting...


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

[jira] [Commented] (GEODE-2578) Query string limited to 64 KiB

2017-03-07 Thread ASF GitHub Bot (JIRA)


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

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

Github user echobravopapa commented on a diff in the pull request:

https://github.com/apache/geode-native/pull/48#discussion_r104768254
  
--- Diff: src/cppcache/test/TcrMessage_unittest.cpp ---
@@ -559,3 +560,66 @@ TEST_F(TcrMessageTest, 
testConstructorEXECUTE_FUNCTION) {
   "75746546756E6374696F6E00030157",
   testMessage);
 }
+
+TEST_F(TcrMessageTest, testConstructorEXECUTECQ_MSG_TYPE) {
+  CacheablePtr myCacheablePtr(CacheableString::createDeserializable());
+
+  TcrMessageExecuteCq testMessage("ExecuteCQ", "select * from /somewhere",
+  CqState::RUNNING, false,
+  static_cast(NULL));
+
+  EXPECT_EQ(TcrMessage::EXECUTECQ_MSG_TYPE, testMessage.getMessageType());
+
+  EXPECT_MESSAGE_EQ(
+  
"002A00450900457865637574654351001800"
+  
"73656C656374202A2066726F6D202F736F6D65776865726500040100"
+  "0100010001",
+  testMessage);
+}
+
+TEST_F(TcrMessageTest, 
testConstructorWithGinormousQueryEXECUTECQ_MSG_TYPE) {
--- End diff --

I'm not certain that this query's magnitude qualifies for ginormity... 
maybe we just call it test*64KiBQuery* - lest we set the bar low for 
ginormous...


> Query string limited to 64 KiB
> --
>
> Key: GEODE-2578
> URL: https://issues.apache.org/jira/browse/GEODE-2578
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Dodge
>Assignee: Michael Dodge
>
> The serialization of query strings uses a 16-bit unsigned integer to 
> represent the length of the query string. Query strings with more than 65535 
> characters are silently truncated. Use of a 32-bit unsigned integer to 
> represent the length would greatly increase the size of query strings that 
> may be used.



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

[jira] [Commented] (GEODE-2578) Query string limited to 64 KiB

2017-03-07 Thread ASF GitHub Bot (JIRA)


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

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

Github user echobravopapa commented on a diff in the pull request:

https://github.com/apache/geode-native/pull/48#discussion_r104766406
  
--- Diff: src/cppcache/include/geode/DataOutput.hpp ---
@@ -378,9 +378,8 @@ class CPPCACHE_EXPORT DataOutput {
  */
   inline void writeFullUTF(const char* value, uint32_t length = 0) {
 if (value != NULL) {
-  int32_t len = getEncodedLength(value, length);
-  uint16_t encodedLen = static_cast(len > 0x ? 0x : 
len);
--- End diff --

what was the corner case impact of this line?


> Query string limited to 64 KiB
> --
>
> Key: GEODE-2578
> URL: https://issues.apache.org/jira/browse/GEODE-2578
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Dodge
>Assignee: Michael Dodge
>
> The serialization of query strings uses a 16-bit unsigned integer to 
> represent the length of the query string. Query strings with more than 65535 
> characters are silently truncated. Use of a 32-bit unsigned integer to 
> represent the length would greatly increase the size of query strings that 
> may be used.



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

1 2 >

1 - 100 of 174 matches

Mail list logo