[GitHub] geode pull request #405: Delete website

[metatype]

GitHub user metatype opened a pull request:

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

Delete website



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

$ git pull https://github.com/metatype/incubator-geode delete-website

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

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


commit e8de9a47e7fae148f76f0396fb8f050d0ef2abcb
Author: Anthony Baker 
Date:   2017-02-21T15:39:38Z

GEODE-2507 Update LICENSE, rat for removing geode-site

Remove LICENSE references to files used in geode-site.  Update
rat exclusions for same.  No changes needed to NOTICE.

commit a2353e96eb334ee38fede5605433d81de06742ec
Author: Anthony Baker 
Date:   2017-02-21T15:42:56Z

GEODE-2507 Remove geode-site files

The geode-site files have been moved to a new repo.




---
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.
---

Build failed in Jenkins: Geode-nightly #755

[Apache Jenkins Server]

See 

--
[...truncated 113.18 KB...]
:geode-cq:compileTestJavaNote: Some input files use or override a deprecated 
API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-cq:processTestResources
:geode-cq:testClasses
:geode-cq:checkMissedTests
:geode-cq:spotlessJavaCheck
:geode-cq:spotlessCheck
:geode-cq:test
:geode-cq:check
:geode-cq:build
:geode-cq:distributedTest
:geode-cq:flakyTest
:geode-cq:integrationTest
:geode-json:assemble
:geode-json:compileTestJava UP-TO-DATE
:geode-json:processTestResources UP-TO-DATE
:geode-json:testClasses UP-TO-DATE
:geode-json:checkMissedTests UP-TO-DATE
:geode-json:spotlessJavaCheck
:geode-json:spotlessCheck
:geode-json:test UP-TO-DATE
:geode-json:check
:geode-json:build
:geode-json:distributedTest UP-TO-DATE
:geode-json:flakyTest UP-TO-DATE
:geode-json:integrationTest UP-TO-DATE
:geode-junit:javadoc
:geode-junit:javadocJar
:geode-junit:sourcesJar
:geode-junit:signArchives SKIPPED
:geode-junit:assemble
:geode-junit:compileTestJava
:geode-junit:processTestResources UP-TO-DATE
:geode-junit:testClasses
:geode-junit:checkMissedTests
:geode-junit:spotlessJavaCheck
:geode-junit:spotlessCheck
:geode-junit:test
:geode-junit:check
:geode-junit:build
:geode-junit:distributedTest
:geode-junit:flakyTest
:geode-junit:integrationTest
:geode-lucene:assemble
:geode-lucene:compileTestJavaNote: Some input files use or override a 
deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-lucene:processTestResources
:geode-lucene:testClasses
:geode-lucene:checkMissedTests
:geode-lucene:spotlessJavaCheck
:geode-lucene:spotlessCheck
:geode-lucene:test
:geode-lucene:check
:geode-lucene:build
:geode-lucene:distributedTest
:geode-lucene:flakyTest
:geode-lucene:integrationTest
:geode-old-client-support:assemble
:geode-old-client-support:compileTestJava
:geode-old-client-support:processTestResources UP-TO-DATE
:geode-old-client-support:testClasses
:geode-old-client-support:checkMissedTests
:geode-old-client-support:spotlessJavaCheck
:geode-old-client-support:spotlessCheck
:geode-old-client-support:test
:geode-old-client-support:check
:geode-old-client-support:build
:geode-old-client-support:distributedTest
:geode-old-client-support:flakyTest
:geode-old-client-support:integrationTest
:geode-old-versions:javadoc UP-TO-DATE
:geode-old-versions:javadocJar
:geode-old-versions:sourcesJar
:geode-old-versions:signArchives SKIPPED
:geode-old-versions:assemble
:geode-old-versions:compileTestJava UP-TO-DATE
:geode-old-versions:processTestResources UP-TO-DATE
:geode-old-versions:testClasses UP-TO-DATE
:geode-old-versions:checkMissedTests UP-TO-DATE
:geode-old-versions:spotlessJavaCheck
:geode-old-versions:spotlessCheck
:geode-old-versions:test UP-TO-DATE
:geode-old-versions:check
:geode-old-versions:build
:geode-old-versions:distributedTest UP-TO-DATE
:geode-old-versions:flakyTest UP-TO-DATE
:geode-old-versions:integrationTest UP-TO-DATE
:geode-pulse:assemble
:geode-pulse:compileTestJavaNote: 

 uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: 

 uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-pulse:processTestResources
:geode-pulse:testClasses
:geode-pulse:checkMissedTests
:geode-pulse:spotlessJavaCheck
:geode-pulse:spotlessCheck
:geode-pulse:test
:geode-pulse:check
:geode-pulse:build
:geode-pulse:distributedTest
:geode-pulse:flakyTest
:geode-pulse:integrationTest
:geode-rebalancer:assemble
:geode-rebalancer:compileTestJava
:geode-rebalancer:processTestResources UP-TO-DATE
:geode-rebalancer:testClasses
:geode-rebalancer:checkMissedTests
:geode-rebalancer:spotlessJavaCheck
:geode-rebalancer:spotlessCheck
:geode-rebalancer:test
:geode-rebalancer:check
:geode-rebalancer:build
:geode-rebalancer:distributedTest
:geode-rebalancer:flakyTest
:geode-rebalancer:integrationTest
:geode-wan:assemble
:geode-wan:compileTestJavaNote: Some input files use or override a deprecated 
API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-wan:processTestResources
:geode-wan:testClasses
:geode-wan:checkMissedTests
:geode-wan:spotlessJavaCheck
:geode-wan:spotlessCheck
:geode-wan:test
:geode-wan:check
:geode-wan:build
:geode-wan:distributedTest
:geode-wan:flakyTest
:geode-wan:integrationTest
:geode-web:assem

[jira] [Commented] (GEODE-2497) surprise members are never timed out during startup

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt commented on GEODE-2497:
-

*Is this the old method of adding expected exceptions?*

Yes.  

> surprise members are never timed out during startup
> ---
>
> Key: GEODE-2497
> URL: https://issues.apache.org/jira/browse/GEODE-2497
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>
> A system was observed to hang during startup when a "surprise member" was 
> added but then never timed out.  The system hung waiting for a response to a 
> startup message sent to the surprise member.



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

Re: C++ Style

[Michael William Dodge]

* Variable Naming - I agree that lowercase-first camelCase is more readable and 
preferable for variable and data member names. Since class names are 
uppercase-first CamelCase, underscores should not be used. And alllowercase is 
unreadable.

* Class Data Members - Any sort of Hungarian notation, including the leading 
"m_", is more trouble than it's worth, e.g., the compiler doesn't enforce m_foo 
actually being a data member. For those who have an aversion to this->foo, foo_ 
would be much better than m_foo. But I think neither a leading "m_" or trailing 
"_" is needed.

* Constant Names - I always associated the leading "k" with Smalltalk since I 
first saw it in Objective-C but apparently it's originally from mathematics 
somehow. Just like with the rest of Hungarian notation, it doesn't mean 
anything to the compiler and I think it makes the code harder to read. It is 
unnecessary.

* Reference vs. Pointer - I'll admit I don't see the logic to their argument. 
As far as I know, compilers pass the address for both references and pointers 
so there's no difference there. From a language standpoint, however, there is 
the very important difference that references may not be null. Thus, pointers 
(both const and non-const) should be used in cases where the value may be 
entirely absent (e.g., there is no foo) and references (both const and 
non-const) used in all other cases. There may be special cases (e.g., mocks for 
Google Test) where a pointer to an interface is preferable but as a general 
rule the precondition that a reference can not be null makes them preferable.

Sarge

> On 20 Feb, 2017, at 13:48, Jacob Barrett  wrote:
> 
> A bit back we discussed and adopted the Google C++ Style Guide. As we dig
> deeper into the C++ sources we find some striking differences in some of
> the conventions that we may want to discuss and address before tackling
> them.
> 
> *Variable Naming*
> Google style dictates no *camelCase*, use either *alllowercase* or
> *variable_name.
> *Our C++ code has a mix of all three. Personally I prefer cameCase as more
> readable.
> 
> *Class Data Members*
> Google style says members must end with underscore, *my_member_*. While I
> find this preferable to the common practice in our code of *m_* prefix,
> like *m_myVariable,* I am not super fond of any decoration of member
> variables.
> 
> *Constant Names*
> Google says prefix with *k* and gives and example with *kCamelCase*. I
> think *cameCase* might be a typo but again I am not fond of any variable
> decorations.
> 
> *Reference vs. Pointer*
> Google says use pointer if you intend to modify the value being passed and
> use const references for values that are not going to be modified. It says
> do not use references except for very limited use cases. We have references
> and pointers spread inconsistently throughout the source. Worst, it is not
> consistent in the public API. We should decide on a standard and make sure
> our API adheres to it first.
> 
> Others may pop up as we go but these are the obvious ones standing out.
> 
> -Jake

[jira] [Commented] (GEODE-2499) Replace snprintf with

[Jacob S. Barrett (JIRA)]

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

Jacob S. Barrett commented on GEODE-2499:
-

I would suggest that instead of spending the effort replacing all these lines 
with std::stringstream that you consider replacing with a more modern logging 
framework. Most of the places that these strings are used for logging and the 
effort to build the string is being expended regardless of the disposition of 
the log message itself. The the example in the description if the LOGDEBUG 
ultimately does not log then all the overhead of std::stringstream was wasted. 
A more modern approach would look something like:

{noformat}
class MyClass {
private:
Logger logger;

void myFunction() {
...
if (logger.isDebugEnabled) {
  log.debug("Some very expensive logging %s.", this->someExpensiveFunction());
}
...
log.debug("Something cheap %s." this->somethingCheap);

}

{noformat}

In both these cases the formatting and expensive bits will not execute unless 
the logger is going to log the message.


> Replace snprintf with  
> 
>
> Key: GEODE-2499
> URL: https://issues.apache.org/jira/browse/GEODE-2499
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Michael Martell
>
> Using snprintf on Windows has problems. These can be avoided by switching to 
> newer  construct as below. This task is to replace snprintf 
> everywhere in the code (100 or so occurances).
> Instead of:
>   char exMsg[256];
>   std::snprintf(exMsg, 255,
> "TcrMessageHelper::readChunkPartHeader: "
> "%s: part is not object",
> methodName);
>   LOGDEBUG("%s ", exMsg);
> use:
>   std::stringstream s;
>   s << "TcrMessageHelper::readChunkPartHeader: " << methodName << ": part 
> is not object\n";
>   LOGDEBUG("%s ", s.str().c_str());



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

[GitHub] geode-native pull request #19: GEODE-2508: Inital work on making lib names g...

[pivotal-jbarrett]

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

https://github.com/apache/geode-native/pull/19#discussion_r102271148
  
--- Diff: src/cppcache/integration-test/CMakeLists.txt ---
@@ -21,7 +21,7 @@ target_link_libraries(${TEST_UTILS_LIB}
   PRIVATE
 ACE
   PUBLIC
-apache-geode
+${PRODUCT_LIB_NAME}
--- End diff --

Rather than changing the target name of the library throughout CMake by 
using a variable I suggest just controlling the output name of the binary using 
the OUTPUT_NAME property.

set_target_properties(apache-geode PROPERTIES OUTPUT_NAME 
${PRODUCT_LIB_NAME})

This way the target stays "apache-geode" but the results of the output will 
be adjusted.





---
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-2508) Generize lib naming

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode-native/pull/19#discussion_r102271148
  
--- Diff: src/cppcache/integration-test/CMakeLists.txt ---
@@ -21,7 +21,7 @@ target_link_libraries(${TEST_UTILS_LIB}
   PRIVATE
 ACE
   PUBLIC
-apache-geode
+${PRODUCT_LIB_NAME}
--- End diff --

Rather than changing the target name of the library throughout CMake by 
using a variable I suggest just controlling the output name of the binary using 
the OUTPUT_NAME property.

set_target_properties(apache-geode PROPERTIES OUTPUT_NAME 
${PRODUCT_LIB_NAME})

This way the target stays "apache-geode" but the results of the output will 
be adjusted.





> Generize lib naming
> ---
>
> Key: GEODE-2508
> URL: https://issues.apache.org/jira/browse/GEODE-2508
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Ernest Burghardt
>
> Make naming configurable



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

[jira] [Created] (GEODE-2510) GFSH exits with status 0 when running a command fails

[Galen O'Sullivan (JIRA)]

Galen O'Sullivan created GEODE-2510:
---

 Summary: GFSH exits with status 0 when running a command fails
 Key: GEODE-2510
 URL: https://issues.apache.org/jira/browse/GEODE-2510
 Project: Geode
  Issue Type: Bug
  Components: gfsh
Reporter: Galen O'Sullivan


If a command parameter is missing or the command fails, the exit status of gfsh 
is 0:
{code}
$ gfsh ru
Invalid command or option : ru.
Use gfsh help to display additional information.
$ echo $?
1
$ # that's good.
$ gfsh run
Parameter "file" is required. Use "help " for assistance.
$ echo $?
0
$ # this seems wrong to me.
{code}
If a GFSH command fails, the program should return an abnormal exit status. 
Otherwise it's hard to reliably script with gfsh.



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

[jira] [Commented] (GEODE-2485) CacheTransactionManager suspend/resume can leak memory for 30 minutes

[Darrel Schneider (JIRA)]

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

Darrel Schneider commented on GEODE-2485:
-

In addition to fixing the code to periodically purge the SystemTimer, it would 
also be worth changing fetchRemoteVersionTag to not use suspend/resume. All 
that this code is doing is sending a message. The code wants this message to 
always be done outside of a transaction so it suspends. But a more performant 
way of doing this is just to refactor the code on the RemoteOperationMessage 
that initializes the txUniqId, txMemberId, and isTransactionDistributed 
instance variables into a protected method called initializeTransaction. Then 
override this method in RemoteFetchVersionMessage to do nothing.


> CacheTransactionManager suspend/resume can leak memory for 30 minutes
> -
>
> Key: GEODE-2485
> URL: https://issues.apache.org/jira/browse/GEODE-2485
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Darrel Schneider
>
> Each time you suspend/resume a transaction it leaves about 80 bytes of heap 
> allocated for 30 minutes. If you are doing a high rate of suspend/resume 
> calls then this could cause you to run out of memory in that 30 minute window.
> As a workaround you can set -Dgemfire.suspendedTxTimeout to a value as small 
> as 1 (which would cause the memory to be freed up after 1 minute instead of 
> 30 minutes).
> One fix for this is to periodically call cache.getCCPTimer().timerPurge() 
> after a certain number of resume calls have been done (for example 1000). 
> Currently resume is calling cancel on the TimerTask but that leaves the task 
> in the SystemTimer queue until it expires. Calling timerPurge it addition to 
> cancel will fix this bug. Calling timerPurge for every cancel may cause the 
> resume method to take too long and keep in mind the getCCPTimer is used by 
> other things so the size of the SystemTimer queue that is being purged will 
> not only be the number of suspended txs.



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

[jira] [Updated] (GEODE-2486) Developer can use encrypted ciphers

[Addison (JIRA)]

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

Addison updated GEODE-2486:
---
Summary: Developer can use encrypted ciphers  (was: Trouble setting cipher 
on Native Client)

> Developer can use encrypted ciphers
> ---
>
> Key: GEODE-2486
> URL: https://issues.apache.org/jira/browse/GEODE-2486
> Project: Geode
>  Issue Type: New Feature
>  Components: native client
>Reporter: Jacob S. Barrett
> Fix For: 1.2.0
>
>
> SSLImpl does not correctly initialize the OpenSSL library so ciphers other 
> than the NULL cipher can be used.



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

[jira] [Updated] (GEODE-2486) Trouble setting cipher on Native Client

[Addison (JIRA)]

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

Addison updated GEODE-2486:
---
Issue Type: New Feature  (was: Bug)

> Trouble setting cipher on Native Client
> ---
>
> Key: GEODE-2486
> URL: https://issues.apache.org/jira/browse/GEODE-2486
> Project: Geode
>  Issue Type: New Feature
>  Components: native client
>Reporter: Jacob S. Barrett
> Fix For: 1.2.0
>
>
> SSLImpl does not correctly initialize the OpenSSL library so ciphers other 
> than the NULL cipher can be used.



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

[jira] [Commented] (GEODE-2416) Collect together artifacts from individual servers into a single zip file

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2416:


Commit 450516464673d0fcf0460e6db107b566b5ffb5d6 in geode's branch 
refs/heads/feature/GEODE-2267 from [~jstewart]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=4505164 ]

GEODE-2416: ExportLogDUnit improvements


> Collect together artifacts from individual servers into a single zip file
> -
>
> Key: GEODE-2416
> URL: https://issues.apache.org/jira/browse/GEODE-2416
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, gfsh
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> We need a locator to unzip the individual zip files produced by GEODE-2415 
> and re-zip them together into a single zip file (with a directory for each 
> member, containing the artifacts from that member).



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

[jira] [Assigned] (GEODE-2507) Acquire and populate new geode-site repo for the web site

[Karen Smoler Miller (JIRA)]

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

Karen Smoler Miller reassigned GEODE-2507:
--

Assignee: Karen Smoler Miller

> Acquire and populate new geode-site repo for the web site
> -
>
> Key: GEODE-2507
> URL: https://issues.apache.org/jira/browse/GEODE-2507
> Project: Geode
>  Issue Type: New Feature
>  Components: web-content
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>
> Move the web site content to its own repo.
> 1. Acquire the repo.  Name it geode-site.
> 2. Populate the repo with the current web site's contents on the master branch
> 3. Request that the asf-site branch be switched from the geode repo to this 
> new geode-site repo, and test that everything works
> 4. Update the contents of LICENSE files for geode and geode-site
> 5. Setup auto-publish by creating an INFRA JIRA ticket
> 6. Revise README for publishing instructions



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

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

[David Kimura (JIRA)]

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

David Kimura commented on GEODE-2441:
-

Current idea is to move PDXAutoSerializer either to geode-examples repo or into 
a utils directory (outside of normal build process) in geode-native.  Purpose 
of this JIRA is to reduce dependencies in the build process and extract 
non-core pieces of code from source tree.  In doing this, we hope that by 
reducing build complexity and core code size, the code will be easier to dive 
into and maintain.

> 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] [Commented] (GEODE-2507) Acquire and populate new geode-site repo for the web site

[Karen Smoler Miller (JIRA)]

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

Karen Smoler Miller commented on GEODE-2507:


New repo (geode-site) has been requested.

> Acquire and populate new geode-site repo for the web site
> -
>
> Key: GEODE-2507
> URL: https://issues.apache.org/jira/browse/GEODE-2507
> Project: Geode
>  Issue Type: New Feature
>  Components: web-content
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>
> Move the web site content to its own repo.
> 1. Acquire the repo.  Name it geode-site.
> 2. Populate the repo with the current web site's contents on the master branch
> 3. Request that the asf-site branch be switched from the geode repo to this 
> new geode-site repo, and test that everything works
> 4. Update the contents of LICENSE files for geode and geode-site
> 5. Setup auto-publish by creating an INFRA JIRA ticket
> 6. Revise README for publishing instructions



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

[jira] [Created] (GEODE-2511) Native client can support JSON

[Addison (JIRA)]

Addison created GEODE-2511:
--

 Summary: Native client can support JSON
 Key: GEODE-2511
 URL: https://issues.apache.org/jira/browse/GEODE-2511
 Project: Geode
  Issue Type: Wish
  Components: native client
Reporter: Addison


Currently the Native Client does not support JSON.



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

[jira] [Assigned] (GEODE-2489) Tombstone message with keys are sent to peer partitioned region nodes even though no clinets are registered

[Swapnil Bawaskar (JIRA)]

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

Swapnil Bawaskar reassigned GEODE-2489:
---

Assignee: (was: Anilkumar Gingade)

> Tombstone message with keys are sent to peer partitioned region nodes even 
> though no clinets are registered
> ---
>
> Key: GEODE-2489
> URL: https://issues.apache.org/jira/browse/GEODE-2489
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Anilkumar Gingade
>
> Tombstone:
> As part of consistency checking,  when an entry is destroyed, the member 
> temporarily retains the entry to detect possible conflicts with operations 
> that have occurred. The retained entry is referred to as a tombstone. 
> When tombstones are removed, tombstone messages are sent to region replicas; 
> and in case of Partitioned Region (PR) messages are also sent to peer region 
> nodes for client events.
> Currently tombstone messages meant for clients that have all the keys removed 
> are getting sent to peer PR nodes even though no clients are registered on 
> those peers.
> Based on the number tombstone keys processed (by default 10) this could 
> be large message sent to peer node which could impact the performance of the 
> system/cluster.



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

[jira] [Assigned] (GEODE-2490) Tombstone messages are getting processed inline

[Swapnil Bawaskar (JIRA)]

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

Swapnil Bawaskar reassigned GEODE-2490:
---

Assignee: (was: Anilkumar Gingade)

> Tombstone messages are getting processed inline
> ---
>
> Key: GEODE-2490
> URL: https://issues.apache.org/jira/browse/GEODE-2490
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Anilkumar Gingade
>
> Tombstone:
> As part of consistency checking, when an entry is destroyed, the member 
> temporarily retains the entry to detect possible conflicts with operations 
> that have occurred. The retained entry is referred to as a tombstone.
> When tombstones are removed, tombstone messages are sent to region replicas; 
> and in case of Partitioned Region (PR) messages are also sent to peer region 
> nodes for client events.
> Currently the tombstone message sent for replicas are getting processed 
> in-line. Based on the number of nodes in the cluster, this may take long time 
> to process, impacting other cache operation that required to be processed 
> in-line. 



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

[jira] [Commented] (GEODE-2031) Host documentation for releases

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2031:


Commit 8c75147b8d343f19a67d7716afe72381f2e1e5f9 in geode-site's branch 
refs/heads/master from [~jmcallis...@pivotal.io]
[ https://git-wip-us.apache.org/repos/asf?p=geode-site.git;h=8c75147 ]

GEODE-2031 (Re?)Add missing book infra to site; update rat


> Host documentation for releases
> ---
>
> Key: GEODE-2031
> URL: https://issues.apache.org/jira/browse/GEODE-2031
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Anthony Baker
>Assignee: Joey McAllister
>Priority: Minor
> Fix For: 1.1.0
>
>
> Currently we overwrite documentation hosted on geode.apache.org with every 
> release.  We should allow a user to browse the documentation (user guide + 
> javadocs) for past releases, not just the most recent release.
> Improvement:
> 1) The documentation page always points to the docs for the latest release.
> 2) There is a documentation link associated with each release just like we do 
> release links for source and binary artifacts.



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

[jira] [Commented] (GEODE-2460) Update dependency versions

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2460:


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

GEODE-2460: update dependency versions

Update the following dependency versions defined in
gradle/dependency-versions.properties.

Update major versions (compile test only):

* org.apache.bcel:bcel:6.0

Update minor versions (distributed in release):

* commons-beanutils:1.9.3
* commons-fileupload:1.3.2
* commons-io:2.5
* commons-lang:2.6
* commons-logging:1.2
* commons-modeler:2.0.1
* fastutil:7.0.13
* guava:21.0
* jansi:1.14
* javax.mail-api:1.4.7
* jline:2.14.3
* jopt-simple:5.0.3
* log4j-api:2.7
* log4j-core:2.7
* log4j-jcl:2.7
* log4j-jul:2.7
* log4j-slf4j-impl:2.7
* netty-all:4.1.7.Final
* shiro-core:1.3.2
* slf4j-api:1.7.22

Update minor versions (compile test and main):

* assertj-core:3.6.2
* cglib:cglib:3.2.4
* commons-configuration:1.10
* derby:10.13.1.1
* google-gson:2.8.0
* httpclient:4.5.2
* httpcore:4.4.6
* hsqldb:2.3.4
* javassist:3.21.0-GA
* jedis:2.9.0
* JUnitParams:1.0.6
* mockrunner:1.1.2
* mortbay-jetty-servlet-api:2.5.20110712
* phantomjsdriver:1.3.0
* powermock-core:1.6.6
* powermock-module-junit4:1.6.6
* powermock-api-mockito:1.6.6
* selenium-api:3.0.1
* selenium-remote-driver:3.0.1
* selenium-support:3.0.1
* spymemcached:2.12.2
* system-rules:1.16.1
* tomcat-catalina:7.0.73 (tomcat7)
* tomcat-coyote:7.0.73 (tomcat7)
* tomcat-juli:7.0.73 (tomcat7)
* tomcat-catalina:8.5.9 (tomcat8)
* tomcat-coyote:8.5.9 (tomcat8)
* tomcat-juli:8.5.9 (tomcat8)


> Update dependency versions
> --
>
> Key: GEODE-2460
> URL: https://issues.apache.org/jira/browse/GEODE-2460
> Project: Geode
>  Issue Type: Wish
>  Components: build, docs
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> Here's the first bunch of dependency version updates that passes precheckin 
> without modifying source code:
> Update the following dependency versions defined in
> gradle/dependency-versions.properties.
> Update major versions (test-only):
> * org.apache.bcel:bcel:6.0
> Update minor versions (test and main):
> * commons-beanutils:1.9.3 
> * commons-fileupload:1.3.2 
> * commons-io:2.5 
> * commons-lang:2.6
> * commons-logging:1.2
> * commons-modeler:2.0.1
> * fastutil:7.0.13
> * guava:21.0
> * jansi:1.14
> * javax.mail-api:1.4.7
> * jline:2.14.3
> * jopt-simple:5.0.3
> * log4j-api:2.7
> * log4j-core:2.7
> * log4j-jcl:2.7
> * log4j-jul:2.7
> * log4j-slf4j-impl:2.7
> * netty-all:4.1.7.Final
> * shiro-core:1.3.2
> * slf4j-api:1.7.22
> Update minor versions (test-only):
> * assertj-core:3.6.2
> * cglib:cglib:3.2.4
> * commons-configuration:1.10
> * derby:10.13.1.1
> * google-gson:2.8.0
> * httpclient:4.5.2
> * httpcore:4.4.6
> * hsqldb:2.3.4
> * javassist:3.21.0-GA
> * jedis:2.9.0
> * JUnitParams:1.0.6
> * mockrunner:1.1.2
> * mortbay-jetty-servlet-api:2.5.20110712
> * phantomjsdriver:1.3.0
> * powermock-core:1.6.6
> * powermock-module-junit4:1.6.6
> * powermock-api-mockito:1.6.6
> * selenium-api:3.0.1
> * selenium-remote-driver:3.0.1
> * selenium-support:3.0.1
> * spymemcached:2.12.2
> * system-rules:1.16.1
> * tomcat-catalina:7.0.73 (tomcat7)
> * tomcat-coyote:7.0.73 (tomcat7)
> * tomcat-juli:7.0.73 (tomcat7)
> * tomcat-catalina:8.5.9 (tomcat8)
> * tomcat-coyote:8.5.9 (tomcat8)
> * tomcat-juli:8.5.9 (tomcat8)



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

[jira] [Commented] (GEODE-2507) Acquire and populate new geode-site repo for the web site

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2507:


Commit 181dd579b69d4597db2cd2ffbb1e483b55523812 in geode-site's branch 
refs/heads/master from [~amb]
[ https://git-wip-us.apache.org/repos/asf?p=geode-site.git;h=181dd57 ]

GEODE-2507 Add standard LICENSE and NOTICE


> Acquire and populate new geode-site repo for the web site
> -
>
> Key: GEODE-2507
> URL: https://issues.apache.org/jira/browse/GEODE-2507
> Project: Geode
>  Issue Type: New Feature
>  Components: web-content
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>
> Move the web site content to its own repo.
> 1. Acquire the repo.  Name it geode-site.
> 2. Populate the repo with the current web site's contents on the master branch
> 3. Request that the asf-site branch be switched from the geode repo to this 
> new geode-site repo, and test that everything works
> 4. Update the contents of LICENSE files for geode and geode-site
> 5. Setup auto-publish by creating an INFRA JIRA ticket
> 6. Revise README for publishing instructions



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

[jira] [Created] (GEODE-2512) Geode Native docs: book fails to build

[Dave Barnes (JIRA)]

Dave Barnes created GEODE-2512:
--

 Summary: Geode Native docs: book fails to build
 Key: GEODE-2512
 URL: https://issues.apache.org/jira/browse/GEODE-2512
 Project: Geode
  Issue Type: Bug
  Components: docs
Reporter: Dave Barnes


The geode native book fails to build. Need to update and correct the config 
files in ../geode-native/docs/geode-native-book, and (once book generation is 
restored) the README.md file needs to be updated.



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

[jira] [Created] (GEODE-2513) Geode Native docs: rebrand to match open-source software

[Dave Barnes (JIRA)]

Dave Barnes created GEODE-2513:
--

 Summary: Geode Native docs: rebrand to match open-source software
 Key: GEODE-2513
 URL: https://issues.apache.org/jira/browse/GEODE-2513
 Project: Geode
  Issue Type: Bug
  Components: docs
Reporter: Dave Barnes


The newly-contributed Geode Native doc sources contain some GemFire artifacts 
that have been purged from the open-source code. Docs should be updated to 
match. 



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

[jira] [Updated] (GEODE-2513) Geode Native docs: rebrand to match open-source software

[Dave Barnes (JIRA)]

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

Dave Barnes updated GEODE-2513:
---
Issue Type: Improvement  (was: Bug)

> Geode Native docs: rebrand to match open-source software
> 
>
> Key: GEODE-2513
> URL: https://issues.apache.org/jira/browse/GEODE-2513
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>
> The newly-contributed Geode Native doc sources contain some GemFire artifacts 
> that have been purged from the open-source code. Docs should be updated to 
> match. 



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

Re: [GitHub] geode pull request #404: Geode 2469

[Gregory Green]

Hello Everyone,

I just wanted to clarify something with this pull request.

The main benefit of the pull request changes is the 99.9% performance
improvements for SET and HASH related Redis command processing.

FYI - In order to support HA as has previously implemented, the default
region type has to be set as a type that supports HA such as
PARTITION_REDUNDANT,
REPLICATE, etc.

If administrators start the adapter to indicate an HA default data type as
the following.

start server --name=server1 --redis-bind-address=localhost --redis-port=11211
--J=-Dgemfireredis.regiontype=PARTITION_REDUNDANT.

The default type if not set is PARTITION, which as no HA support.

This change does not fundamentally change the way the Redis adapter handles
the created regions, but it does limit the number of regions created. The
new pull request creates two new regions RediS_SET and RediS_HASH use the
same conventions used by the current adapter Redis_STRING, Redis_HLL, etc
used in Geode 1.1.0 and GemFire 9.0.1.

Previously, the Redis adapter created a region for each key provided in a
Redis SET or HASH related command. This convention causes issues when
non-standard region name characters such as ":" exists in the key. The main
problem is Redis uses ":" in its key to indicated the object that the key
belongs with the format "object:key". For example, HSET companies:1000
means the object name is companies and its key if 1000. The pull request
changes will only create a new region if Redis "object:key" convention is
used in the HASH keys (otherwise the RediS_HASH region is used). So HSET
companies:1000 ... will result in a new region companies region created
with an entry key=100. Administrators can pre-create the region (ex:
companies) with the desired attributes. If the region is not pre-created it
will be created on demand with using the default region type.

On Sat, Feb 18, 2017 at 11:22 PM, ggreen  wrote:

> GitHub user ggreen opened a pull request:
>
> https://github.com/apache/geode/pull/404
>
> Geode 2469
>
> The updated Geode Redis Adapter now works with a sample Spring Data
> Redis Example
> [GEODE-2469.pdf](https://github.com/apache/geode/files/
> 785580/GEODE-2469.pdf)
>
> These changes are focused on the HASH and Set Redis Data Types to
> support Spring Data Redis sample code located at the following URL
>
> https://github.com/Pivotal-Data-Engineering/gemfire9_
> examples/tree/person_example_sdg_Tracker139498217/redis/
> spring-data-redis-example/src/test/java/io/pivotal/redis/
> gemfire/example/repository
>
> The Hash performance changes from this pull request had a 99.8%
> performance improvement.
>
> This is based on the Hashes JUNIT Tests.
>
> https://github.com/Pivotal-Data-Engineering/gemfire9_
> examples/blob/person_example_sdg_Tracker139498217/redis/
> gemfire-streaming-client/src/test/java/io/pivotal/gemfire9/
> HashesJUnitTest.java
>
> This code executed in 12.549s against Gemfire 9.0.1 code. After the
> changes, the test executed in 0.022s with the GEODE-2469 pull request.
>
> Redis Set related command performance had a 99.9% performance
> improvement.
>
> See  https://github.com/Pivotal-Data-Engineering/gemfire9_
> examples/blob/person_example_sdg_Tracker139498217/redis/
> gemfire-streaming-client/src/test/java/io/pivotal/gemfire9/
> SetsJUnitTest.java
>
> The previous Set Junit tests executed against GemFire 9.0.1 executed
> in 31.507 seconds. These same test executed in 0.036 seconds with the
> GEODE-2469 pull request changes.
>
> The GemFire 9.0.1 Geode (1.1.0) version for the Geode Redis adapter
> created a Geode Region for each key provided in the Redis Hash or Set
> related command. Each Redis command to remove key entry previously
> destroyed the region. The big performance gain is based on using a new
> ReDiS_HASH and ReDiS_SET region. Note the changed will create or reuse an
> existing region with a matching name for Redis HASH commands references
> objects. For Redis HASH object's key will have a format of object:key
>
> Please see https://redis.io/topics/data-types-intro HASH section on
> objects for information on Redis objects.
>
> You can merge this pull request into a Git repository by running:
>
> $ git pull https://github.com/ggreen/geode GEODE-2469
>
> Alternatively you can review and apply these changes as the patch at:
>
> https://github.com/apache/geode/pull/404.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 #404
>
> 
> commit 44b90c4f3f8e1ec4fdae63a8be126982d7c837a2
> Author: Gregory Green 
> Date:   2017-02-14T20:31:49Z
>
> GEODE-2469 initial changes to support Redis objects
>
> commit 27d7600e85945a7134115630efe378ed43d980f8
> Author: Gregory Green 
> Date:   2017-02-17T00:26:11Z
>
> GEODE-2469 changes to corrected introduced issue found during JUNIT
> runs
>
> commit a4ee164ddc944e8eed93c28d2d

[jira] [Resolved] (GEODE-2029) Review NOTICE for Lucene

[Dan Smith (JIRA)]

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

Dan Smith resolved GEODE-2029.
--
   Resolution: Fixed
Fix Version/s: 1.2.0

> Review NOTICE for Lucene
> 
>
> Key: GEODE-2029
> URL: https://issues.apache.org/jira/browse/GEODE-2029
> Project: Geode
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Anthony Baker
>Assignee: Dan Smith
> Fix For: 1.2.0
>
>
> See:
> http://mail-archives.apache.org/mod_mbox/incubator-general/201610.mbox/%3cca53f203-bef1-4bdb-a8b3-313ab035c...@classsoftware.com%3e
> https://github.com/apache/lucene-solr/blob/master/lucene/NOTICE.txt
> We are only bundling a few components of Lucene (core, analyzers-common, 
> queryparser, queries) however we have included the full Lucene NOTICE 
> contents within our NOTICE file for the binary distribution 
> (geode-assembly/src/main/dist/NOTICE).  In order to reduce the burden on 
> downstream projects, we should trim down the included parts to only those we 
> need (e.g. morfologik is not bundled).



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

[jira] [Commented] (GEODE-2029) Review NOTICE for Lucene

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2029:


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

GEODE-2029 Trimming unused parts of Lucene from binary NOTICE

The lucene section of our NOTICE included some elements for jars that we
are not redistributing like some language specific analyzers and
stemmers. To reduce the burden on downstream projects, removing these
components from our NOTICE.

I did leave in the section on servlet-api, which appeared to come from
lucene, but in fact we do include servlet-api.jar in our binary
distribution.

Here are the specific notes on where stuff in the notice came from

icu4j,WordBreakTestUnicode - this is in  lucene-analyzers-icu.jar (we don't 
include)
junit - we're not distributing this jar
stempel - this is in lucene-analyzers-stempel (we don't include)
smartcn - this is in  lucene-analyzers-smartcn (we don't include)
kuromoji - this in in lucene-analyzers-kuromoji (we don't include)
Morfologik - this in in lucene-analyzers-morfologik (we don't include)


> Review NOTICE for Lucene
> 
>
> Key: GEODE-2029
> URL: https://issues.apache.org/jira/browse/GEODE-2029
> Project: Geode
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Anthony Baker
>Assignee: Dan Smith
> Fix For: 1.2.0
>
>
> See:
> http://mail-archives.apache.org/mod_mbox/incubator-general/201610.mbox/%3cca53f203-bef1-4bdb-a8b3-313ab035c...@classsoftware.com%3e
> https://github.com/apache/lucene-solr/blob/master/lucene/NOTICE.txt
> We are only bundling a few components of Lucene (core, analyzers-common, 
> queryparser, queries) however we have included the full Lucene NOTICE 
> contents within our NOTICE file for the binary distribution 
> (geode-assembly/src/main/dist/NOTICE).  In order to reduce the burden on 
> downstream projects, we should trim down the included parts to only those we 
> need (e.g. morfologik is not bundled).



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

[jira] [Commented] (GEODE-2037) Fix links to point to correct location of documentation

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2037:


Commit 563269331341ab438abf9094b3926cfcb3e0b3e6 in geode-site's branch 
refs/heads/asf-site from [~amb]
[ https://git-wip-us.apache.org/repos/asf?p=geode-site.git;h=5632693 ]

GEODE-2037: Update documentation links

Fix the website releases page to point to documentation hosted
on the geode website.


> Fix links to point to correct location of documentation
> ---
>
> Key: GEODE-2037
> URL: https://issues.apache.org/jira/browse/GEODE-2037
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Anthony Baker
> Fix For: 1.1.0
>
>
> The following files contain links that should be pointed to the documentation 
> hosted at geode.apache.org/docs.
> README.md
> geode-examples/README.md
> geode-site/website/content/releases/index.html
> geode-pulse/**



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

[jira] [Commented] (GEODE-2156) Remove incubating references

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2156:


Commit 53896567b249c122041b7477e787daae46613267 in geode-site's branch 
refs/heads/asf-site from [~amb]
[ https://git-wip-us.apache.org/repos/asf?p=geode-site.git;h=5389656 ]

GEODE-2156: Remove incubating references


> Remove incubating references
> 
>
> Key: GEODE-2156
> URL: https://issues.apache.org/jira/browse/GEODE-2156
> Project: Geode
>  Issue Type: Task
>Reporter: Anthony Baker
> Fix For: 1.1.0
>
>
> With the completion of GEODE-1, we need to update the following:
> 1) Project name references no longer need to include "(incubating)"
> 2) Project website references should remove ".incubator"
> 3) Project email lists should remove ".incubator"
> 4) DISCLAIMER no longer applies
> 5) Git repo references should remove "incubator-"



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

[jira] [Resolved] (GEODE-2309) Replace or add ASF copyright statements in source.

[Addison (JIRA)]

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

Addison resolved GEODE-2309.

Resolution: Fixed

> Replace or add ASF copyright statements in source.
> --
>
> Key: GEODE-2309
> URL: https://issues.apache.org/jira/browse/GEODE-2309
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Jacob S. Barrett
>




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

[jira] [Closed] (GEODE-2309) Replace or add ASF copyright statements in source.

[Addison (JIRA)]

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

Addison closed GEODE-2309.
--

> Replace or add ASF copyright statements in source.
> --
>
> Key: GEODE-2309
> URL: https://issues.apache.org/jira/browse/GEODE-2309
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Jacob S. Barrett
>




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

Re: Review Request 56803: GEODE-2142: Update GEODE-JSON module with compliant ORG.JSON implementation

[Udo Kohlmeyer]

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

(Updated Feb. 21, 2017, 8:42 p.m.)


Review request for geode, Anthony Baker, Jacob Barrett, Jinmei Liao, and Kirk 
Lund.


Repository: geode


Description
---

Removed non-compliant ORJ.JSON implementation with a compliant opensource 
ORG.JSON implementation


Diffs
-

  LICENSE 9bfdd83c9 
  NOTICE 13a30d3bb 
  geode-assembly/src/main/dist/LICENSE 4769f9a55 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/CliUtil.java 
8525b5862 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/json/GfJsonObject.java
 69666ff9d 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/result/AbstractResultData.java
 e08d9b7c0 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/result/ResultBuilder.java
 06060a4c6 
  geode-json/build.gradle PRE-CREATION 
  geode-json/src/main/java/org/json/CDL.java d78935bd7 
  geode-json/src/main/java/org/json/Cookie.java 21f88d8bd 
  geode-json/src/main/java/org/json/CookieList.java 35e1a97f4 
  geode-json/src/main/java/org/json/HTTP.java 1e815aabe 
  geode-json/src/main/java/org/json/HTTPTokener.java 72c9b8878 
  geode-json/src/main/java/org/json/JSON.java PRE-CREATION 
  geode-json/src/main/java/org/json/JSONArray.java edaefa420 
  geode-json/src/main/java/org/json/JSONException.java b65efe25c 
  geode-json/src/main/java/org/json/JSONML.java b535614f8 
  geode-json/src/main/java/org/json/JSONObject.java a2c6d8b6a 
  geode-json/src/main/java/org/json/JSONStringer.java 234e17451 
  geode-json/src/main/java/org/json/JSONTokener.java 4dd2ba2cc 
  geode-json/src/main/java/org/json/JSONWriter.java 7d4704b21 
  geode-json/src/main/java/org/json/XML.java ae6d61a49 
  geode-json/src/main/java/org/json/XMLTokener.java f56a1f6a5 
  geode-json/src/test/java/org/json/FileTest.java PRE-CREATION 
  geode-json/src/test/java/org/json/JSONArrayTest.java PRE-CREATION 
  geode-json/src/test/java/org/json/JSONFunctionTestObject.java PRE-CREATION 
  geode-json/src/test/java/org/json/JSONObjectTest.java PRE-CREATION 
  geode-json/src/test/java/org/json/JSONStringerTest.java PRE-CREATION 
  geode-json/src/test/java/org/json/JSONTokenerTest.java PRE-CREATION 
  geode-json/src/test/java/org/json/ParsingTest.java PRE-CREATION 
  geode-json/src/test/java/org/json/SelfUseTest.java PRE-CREATION 
  geode-json/src/test/resources/sample-01.json PRE-CREATION 

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


Testing (updated)
---

pre-checkin = completed. 1 Flaky failure, unrelated failure


Thanks,

Udo Kohlmeyer

[jira] [Commented] (GEODE-2031) Host documentation for releases

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2031:


Commit 5ad8f39c81f72b2dbb2aac81c1bc0da290aa0243 in geode-site's branch 
refs/heads/asf-site from [~karensmolermiller]
[ https://git-wip-us.apache.org/repos/asf?p=geode-site.git;h=5ad8f39 ]

GEODE-2031 Add an unneeded space character to nudge
Apache site toward its update.


> Host documentation for releases
> ---
>
> Key: GEODE-2031
> URL: https://issues.apache.org/jira/browse/GEODE-2031
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Anthony Baker
>Assignee: Joey McAllister
>Priority: Minor
> Fix For: 1.1.0
>
>
> Currently we overwrite documentation hosted on geode.apache.org with every 
> release.  We should allow a user to browse the documentation (user guide + 
> javadocs) for past releases, not just the most recent release.
> Improvement:
> 1) The documentation page always points to the docs for the latest release.
> 2) There is a documentation link associated with each release just like we do 
> release links for source and binary artifacts.



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

Re: Review Request 56803: GEODE-2142: Update GEODE-JSON module with compliant ORG.JSON implementation

[Kirk Lund]

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


Ship it!




Ship It!

- Kirk Lund


On Feb. 21, 2017, 8:42 p.m., Udo Kohlmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56803/
> ---
> 
> (Updated Feb. 21, 2017, 8:42 p.m.)
> 
> 
> Review request for geode, Anthony Baker, Jacob Barrett, Jinmei Liao, and Kirk 
> Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Removed non-compliant ORJ.JSON implementation with a compliant opensource 
> ORG.JSON implementation
> 
> 
> Diffs
> -
> 
>   LICENSE 9bfdd83c9 
>   NOTICE 13a30d3bb 
>   geode-assembly/src/main/dist/LICENSE 4769f9a55 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/CliUtil.java
>  8525b5862 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/json/GfJsonObject.java
>  69666ff9d 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/result/AbstractResultData.java
>  e08d9b7c0 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/result/ResultBuilder.java
>  06060a4c6 
>   geode-json/build.gradle PRE-CREATION 
>   geode-json/src/main/java/org/json/CDL.java d78935bd7 
>   geode-json/src/main/java/org/json/Cookie.java 21f88d8bd 
>   geode-json/src/main/java/org/json/CookieList.java 35e1a97f4 
>   geode-json/src/main/java/org/json/HTTP.java 1e815aabe 
>   geode-json/src/main/java/org/json/HTTPTokener.java 72c9b8878 
>   geode-json/src/main/java/org/json/JSON.java PRE-CREATION 
>   geode-json/src/main/java/org/json/JSONArray.java edaefa420 
>   geode-json/src/main/java/org/json/JSONException.java b65efe25c 
>   geode-json/src/main/java/org/json/JSONML.java b535614f8 
>   geode-json/src/main/java/org/json/JSONObject.java a2c6d8b6a 
>   geode-json/src/main/java/org/json/JSONStringer.java 234e17451 
>   geode-json/src/main/java/org/json/JSONTokener.java 4dd2ba2cc 
>   geode-json/src/main/java/org/json/JSONWriter.java 7d4704b21 
>   geode-json/src/main/java/org/json/XML.java ae6d61a49 
>   geode-json/src/main/java/org/json/XMLTokener.java f56a1f6a5 
>   geode-json/src/test/java/org/json/FileTest.java PRE-CREATION 
>   geode-json/src/test/java/org/json/JSONArrayTest.java PRE-CREATION 
>   geode-json/src/test/java/org/json/JSONFunctionTestObject.java PRE-CREATION 
>   geode-json/src/test/java/org/json/JSONObjectTest.java PRE-CREATION 
>   geode-json/src/test/java/org/json/JSONStringerTest.java PRE-CREATION 
>   geode-json/src/test/java/org/json/JSONTokenerTest.java PRE-CREATION 
>   geode-json/src/test/java/org/json/ParsingTest.java PRE-CREATION 
>   geode-json/src/test/java/org/json/SelfUseTest.java PRE-CREATION 
>   geode-json/src/test/resources/sample-01.json PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/56803/diff/
> 
> 
> Testing
> ---
> 
> pre-checkin = completed. 1 Flaky failure, unrelated failure
> 
> 
> Thanks,
> 
> Udo Kohlmeyer
> 
>

Re: Review Request 56801: GEODE-2457: Replace org.apache.geode.internal.FileUtil with org.apache.commons.io.FileUtils

[Kirk Lund]

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


Ship it!




Ship It!

- Kirk Lund


On Feb. 17, 2017, 11:56 p.m., Kevin Duling wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56801/
> ---
> 
> (Updated Feb. 17, 2017, 11:56 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2457: Replace org.apache.geode.internal.FileUtil with 
> org.apache.commons.io.FileUtils
> 
> 
> Diffs
> -
> 
>   
> extensions/geode-modules-session/src/test/java/org/apache/geode/modules/session/installer/InstallerJUnitTest.java
>  e51241b0972089881c1f4b9a2fb6e0b13c1d8a7f 
>   geode-assembly/src/test/java/org/apache/geode/BundledJarsJUnitTest.java 
> b7ada4a4d49d46937fb6c0c2d6af641fd73ec10e 
>   
> geode-assembly/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigurationServiceEndToEndDUnitTest.java
>  a96f8afe75675bb733956cf28bc129e6a7c23b25 
>   geode-core/src/main/java/org/apache/geode/internal/FileUtil.java 
> 2d729303a27179876e2f8a96c0542d796f426e16 
>   geode-core/src/main/java/org/apache/geode/internal/cache/DiskInitFile.java 
> 4023b71dcc0ff5d5b4e3d5cec8d9313dcf9e8dbc 
>   geode-core/src/main/java/org/apache/geode/internal/cache/DiskStoreImpl.java 
> e53aa5d55437116dc466e551c793af87f24012df 
>   geode-core/src/main/java/org/apache/geode/internal/cache/Oplog.java 
> 270c8335a88c48fd3b036b65b50d7fd2b7734a81 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/PersistentOplogSet.java
>  a71394139cd8cc4582122f2d587d0f4434b9ce12 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/persistence/BackupManager.java
>  e4e5467383ed0cdfa31efa10864f7eb56362f8d5 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/persistence/RestoreScript.java
>  86f880e65a3b3eb3477f2a1fd62bd4a4772f44ee 
>   
> geode-core/src/main/java/org/apache/geode/internal/io/MainWithChildrenRollingFileHandler.java
>  20d1c4ff92fbd54956334c923e1bacfea8825aa6 
>   
> geode-core/src/main/java/org/apache/geode/internal/logging/MergeLogFiles.java 
> 7bb94ef92c8a641ae87bb6cdbe7b91b379427371 
>   
> geode-core/src/test/java/org/apache/geode/cache/client/ClientCacheFactoryJUnitTest.java
>  f881d386d9e7fac8c87f7fd837a9b66e3a86d2d7 
>   geode-core/src/test/java/org/apache/geode/cache/query/QueryTestUtils.java 
> 2d6921b9a2087928dffebd2dc050f3967170962b 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/QueryIndexUsingXMLDUnitTest.java
>  66c4ecfce12c20cd4b1d3e363aa66206d947b8ef 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/functional/IndexCreationJUnitTest.java
>  f126146d3098f009eda8388273b52758b7d0ee28 
>   
> geode-core/src/test/java/org/apache/geode/distributed/AbstractLauncherIntegrationTestCase.java
>  01151931473e882905a4443535f2c2306e34ff63 
>   geode-core/src/test/java/org/apache/geode/internal/FileUtilJUnitTest.java 
> 942059e110487f3f886ef5749134190768a87eac 
>   
> geode-core/src/test/java/org/apache/geode/internal/JarDeployerDUnitTest.java 
> 22f66a3efdb670684c0108ab22dc07c43e0265b1 
>   
> geode-core/src/test/java/org/apache/geode/internal/JarDeployerIntegrationTest.java
>  3852dee6613dd67ed85d61365c7ad6ca02306f78 
>   
> geode-core/src/test/java/org/apache/geode/internal/PdxDeleteFieldDUnitTest.java
>  00bb6fb9064b46ef5622e7e11632a36ec71097dd 
>   
> geode-core/src/test/java/org/apache/geode/internal/PdxDeleteFieldJUnitTest.java
>  1d18ed146382e36c894c72ab642e8055fd316df1 
>   geode-core/src/test/java/org/apache/geode/internal/PdxRenameDUnitTest.java 
> 4057069cf4c61bc843e7957b6bcb3be6335a0e5e 
>   geode-core/src/test/java/org/apache/geode/internal/PdxRenameJUnitTest.java 
> cc393a2f70e0a08b5740e3caffbcd1bbd1d74006 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/BackupDUnitTest.java 
> 10931e194d20369350720736a4435aa5998ca0cc 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/BackupJUnitTest.java 
> a89c0d13ececb47bf7345624d4e7d128e01d6a45 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/DiskRegionAsyncRecoveryJUnitTest.java
>  6955dc829330f8766c172da32795fd8ee6b98f7e 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/DiskRegionTestingBase.java
>  55cabe7bb04c77b72b7de3dfe2bc5824d68a9799 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/IncrementalBackupDUnitTest.java
>  9c459a9b737fc80d7a7cd0242927abf2691855b3 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/OplogRVVJUnitTest.java
>  138f3acc5abb96831af60a43560334494793d60b 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/PartitionedRegionStatsJUnit

[jira] [Assigned] (GEODE-2267) Add gfsh command to export stat files

[Kirk Lund (JIRA)]

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

Kirk Lund reassigned GEODE-2267:


Assignee: Kirk Lund

> Add gfsh command to export stat files
> -
>
> Key: GEODE-2267
> URL: https://issues.apache.org/jira/browse/GEODE-2267
> Project: Geode
>  Issue Type: New Feature
>  Components: configuration, gfsh
>Reporter: Diane Hardman
>Assignee: Kirk Lund
>  Labels: ExportClusterArtifacts, export, gfsh, logging, statistics
>
> We would like a single gfsh command to collect and export all logfiles and 
> stat files into a single package that will be returned to the gfsh client 
> machine. This package (zipfile) can then be saved and attached to emails and 
> Jira tickets to help evaluate the Geode cluster status.



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

[jira] [Created] (GEODE-2514) Need more tests for statistics archive rolling and removal

[Kirk Lund (JIRA)]

Kirk Lund created GEODE-2514:


 Summary: Need more tests for statistics archive rolling and removal
 Key: GEODE-2514
 URL: https://issues.apache.org/jira/browse/GEODE-2514
 Project: Geode
  Issue Type: Wish
  Components: statistics
Reporter: Kirk Lund


We need more integration tests for StatArchiveHandler and 
MainWithChildrenRollingFileHandler with file system behavior for rolling and 
removal.

Rolling is controlled by archive-file-size-limit. Removal is controlled by 
archive-disk-space-limit.

Tests should involve the mainId and childId (-01-01) and how they roll. Tests 
should also involve the marker file used by MainWithChildrenRollingFileHandler.

Some of the methods that we would like to test in isolation will need to be 
changed from private to protected (or package private).



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

[jira] [Assigned] (GEODE-2514) Need more tests for statistics archive rolling and removal

[Kirk Lund (JIRA)]

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

Kirk Lund reassigned GEODE-2514:


Assignee: Kirk Lund

> Need more tests for statistics archive rolling and removal
> --
>
> Key: GEODE-2514
> URL: https://issues.apache.org/jira/browse/GEODE-2514
> Project: Geode
>  Issue Type: Wish
>  Components: statistics
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> We need more integration tests for StatArchiveHandler and 
> MainWithChildrenRollingFileHandler with file system behavior for rolling and 
> removal.
> Rolling is controlled by archive-file-size-limit. Removal is controlled by 
> archive-disk-space-limit.
> Tests should involve the mainId and childId (-01-01) and how they roll. Tests 
> should also involve the marker file used by 
> MainWithChildrenRollingFileHandler.
> Some of the methods that we would like to test in isolation will need to be 
> changed from private to protected (or package private).



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

Review Request 56899: GEODE-2514: add new tests for statistics archive rolling and removal

[Kirk Lund]

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

Review request for geode, Darrel Schneider, Jinmei Liao, Jared Stewart, Kevin 
Duling, and Ken Howe.


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


Repository: geode


Description
---

GEODE-2514: add new tests for statistics archive rolling and removal

* add MainWithChildrenRollingFileHandlerIntegrationTest
* add StatArchiveHandlerIntegrationTest
* expand DiskSpaceLimitIntegrationTest


Diffs
-

  
geode-core/src/main/java/org/apache/geode/internal/io/MainWithChildrenRollingFileHandler.java
 20d1c4ff92fbd54956334c923e1bacfea8825aa6 
  
geode-core/src/main/java/org/apache/geode/internal/statistics/StatArchiveHandler.java
 3eb9730a31e5acaed5416c70425b7d8c46096187 
  
geode-core/src/test/java/org/apache/geode/internal/io/MainWithChildrenRollingFileHandlerIntegrationTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/internal/statistics/DiskSpaceLimitIntegrationTest.java
 1702d9a46082de2bd219ca8716734f65fe046917 
  
geode-core/src/test/java/org/apache/geode/internal/statistics/StatArchiveHandlerIntegrationTest.java
 PRE-CREATION 

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


Testing
---

precheckin in progress


Thanks,

Kirk Lund

Re: [GitHub] geode pull request #404: Geode 2469

[Hitesh Khamesra]

Thanks Gregory.  I will look this further.


  From: Gregory Green 
 To: dev@geode.apache.org 
 Sent: Tuesday, February 21, 2017 12:21 PM
 Subject: Re: [GitHub] geode pull request #404: Geode 2469
   
Hello Everyone,

I just wanted to clarify something with this pull request.

The main benefit of the pull request changes is the 99.9% performance
improvements for SET and HASH related Redis command processing.

FYI - In order to support HA as has previously implemented, the default
region type has to be set as a type that supports HA such as
PARTITION_REDUNDANT,
REPLICATE, etc.

If administrators start the adapter to indicate an HA default data type as
the following.

start server --name=server1 --redis-bind-address=localhost --redis-port=11211
--J=-Dgemfireredis.regiontype=PARTITION_REDUNDANT.

The default type if not set is PARTITION, which as no HA support.

This change does not fundamentally change the way the Redis adapter handles
the created regions, but it does limit the number of regions created. The
new pull request creates two new regions RediS_SET and RediS_HASH use the
same conventions used by the current adapter Redis_STRING, Redis_HLL, etc
used in Geode 1.1.0 and GemFire 9.0.1.

Previously, the Redis adapter created a region for each key provided in a
Redis SET or HASH related command. This convention causes issues when
non-standard region name characters such as ":" exists in the key. The main
problem is Redis uses ":" in its key to indicated the object that the key
belongs with the format "object:key". For example, HSET companies:1000
means the object name is companies and its key if 1000. The pull request
changes will only create a new region if Redis "object:key" convention is
used in the HASH keys (otherwise the RediS_HASH region is used). So HSET
companies:1000 ... will result in a new region companies region created
with an entry key=100. Administrators can pre-create the region (ex:
companies) with the desired attributes. If the region is not pre-created it
will be created on demand with using the default region type.

On Sat, Feb 18, 2017 at 11:22 PM, ggreen  wrote:

> GitHub user ggreen opened a pull request:
>
>    https://github.com/apache/geode/pull/404
>
>    Geode 2469
>
>    The updated Geode Redis Adapter now works with a sample Spring Data
> Redis Example
>    [GEODE-2469.pdf](https://github.com/apache/geode/files/
> 785580/GEODE-2469.pdf)
>
>    These changes are focused on the HASH and Set Redis Data Types to
> support Spring Data Redis sample code located at the following URL
>
>    https://github.com/Pivotal-Data-Engineering/gemfire9_
> examples/tree/person_example_sdg_Tracker139498217/redis/
> spring-data-redis-example/src/test/java/io/pivotal/redis/
> gemfire/example/repository
>
>    The Hash performance changes from this pull request had a 99.8%
> performance improvement.
>
>    This is based on the Hashes JUNIT Tests.
>
>    https://github.com/Pivotal-Data-Engineering/gemfire9_
> examples/blob/person_example_sdg_Tracker139498217/redis/
> gemfire-streaming-client/src/test/java/io/pivotal/gemfire9/
> HashesJUnitTest.java
>
>    This code executed in 12.549s against Gemfire 9.0.1 code. After the
> changes, the test executed in 0.022s with the GEODE-2469 pull request.
>
>    Redis Set related command performance had a 99.9% performance
> improvement.
>
>    See  https://github.com/Pivotal-Data-Engineering/gemfire9_
> examples/blob/person_example_sdg_Tracker139498217/redis/
> gemfire-streaming-client/src/test/java/io/pivotal/gemfire9/
> SetsJUnitTest.java
>
>    The previous Set Junit tests executed against GemFire 9.0.1 executed
> in 31.507 seconds. These same test executed in 0.036 seconds with the
> GEODE-2469 pull request changes.
>
>    The GemFire 9.0.1 Geode (1.1.0) version for the Geode Redis adapter
> created a Geode Region for each key provided in the Redis Hash or Set
> related command. Each Redis command to remove key entry previously
> destroyed the region. The big performance gain is based on using a new
> ReDiS_HASH and ReDiS_SET region. Note the changed will create or reuse an
> existing region with a matching name for Redis HASH commands references
> objects. For Redis HASH object's key will have a format of object:key
>
>    Please see https://redis.io/topics/data-types-intro HASH section on
> objects for information on Redis objects.
>
> You can merge this pull request into a Git repository by running:
>
>    $ git pull https://github.com/ggreen/geode GEODE-2469
>
> Alternatively you can review and apply these changes as the patch at:
>
>    https://github.com/apache/geode/pull/404.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 #404
>
> 
> commit 44b90c4f3f8e1ec4fdae63a8be126982d7c837a2
> Author: Gregory Green 
> Date:  2017-02-14T20:31:49Z
>
>    GEODE-2469 initial changes to support Redis objects
>
> commit 27d7600e85945a7134115630efe378ed

[jira] [Commented] (GEODE-369) CI failure: RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByPut fails intermittently with assertion

[Jason Huynh (JIRA)]

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

Jason Huynh commented on GEODE-369:
---

Reopening this ticket, have seen this pop up in a few private builds.

> CI failure: 
> RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByPut
>  fails intermittently with assertion
> 
>
> Key: GEODE-369
> URL: https://issues.apache.org/jira/browse/GEODE-369
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Darrel Schneider
>Assignee: Anilkumar Gingade
>Priority: Minor
>  Labels: CI
> Fix For: 1.0.0-incubating.M2
>
>
> failed on a private build of git rev :
> {code}
> junit.framework.AssertionFailedError: Event never occurred after 6 ms: 
> Redundant servers ([doomtwo.gemstone.com29009]) does not contain 
> doomtwo.gemstone.com27615
>   at junit.framework.Assert.fail(Assert.java:57)
>   at junit.framework.TestCase.fail(TestCase.java:227)
>   at 
> dunit.DistributedTestCase.waitForCriterion(DistributedTestCase.java:1162)
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.RedundancyLevelTestBase.verifyRedundantServersContain(RedundancyLevelTestBase.java:267)
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByPut(RedundancyLevelPart1DUnitTest.java:505)
> {code}



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

[jira] [Created] (GEODE-2515) CI Failure: BaseLineAndCompareQueryPerfJUnitTest.testPerformanceForRangeQueries FAILED failed with AssertionFailedError

[Jason Huynh (JIRA)]

Jason Huynh created GEODE-2515:
--

 Summary: CI Failure: 
BaseLineAndCompareQueryPerfJUnitTest.testPerformanceForRangeQueries FAILED 
failed with AssertionFailedError
 Key: GEODE-2515
 URL: https://issues.apache.org/jira/browse/GEODE-2515
 Project: Geode
  Issue Type: Bug
  Components: querying
Reporter: Jason Huynh


  java.lang.AssertionError: Avg. Time taken to query with index should be less 
than time taken without index
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.geode.cache.query.BaseLineAndCompareQueryPerfJUnitTest.testPerformanceForRangeQueries(BaseLineAndCompareQueryPerfJUnitTest.java:299)



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

[jira] [Updated] (GEODE-2515) CI Failure: BaseLineAndCompareQueryPerfJUnitTest.testPerformanceForRangeQueries FAILED failed with AssertionFailedError

[Jason Huynh (JIRA)]

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

Jason Huynh updated GEODE-2515:
---
Affects Version/s: 1.0.0-incubating

> CI Failure: 
> BaseLineAndCompareQueryPerfJUnitTest.testPerformanceForRangeQueries FAILED 
> failed with AssertionFailedError
> ---
>
> Key: GEODE-2515
> URL: https://issues.apache.org/jira/browse/GEODE-2515
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Affects Versions: 1.0.0-incubating
>Reporter: Jason Huynh
>
>   java.lang.AssertionError: Avg. Time taken to query with index should be 
> less than time taken without index
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at 
> org.apache.geode.cache.query.BaseLineAndCompareQueryPerfJUnitTest.testPerformanceForRangeQueries(BaseLineAndCompareQueryPerfJUnitTest.java:299)



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

[jira] [Commented] (GEODE-2515) CI Failure: BaseLineAndCompareQueryPerfJUnitTest.testPerformanceForRangeQueries FAILED failed with AssertionFailedError

[Jason Huynh (JIRA)]

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

Jason Huynh commented on GEODE-2515:


This test has failed for me a few times and I'm opening a ticket to tune this 
test or remove it if it's not needed.

> CI Failure: 
> BaseLineAndCompareQueryPerfJUnitTest.testPerformanceForRangeQueries FAILED 
> failed with AssertionFailedError
> ---
>
> Key: GEODE-2515
> URL: https://issues.apache.org/jira/browse/GEODE-2515
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Affects Versions: 1.0.0-incubating
>Reporter: Jason Huynh
>
>   java.lang.AssertionError: Avg. Time taken to query with index should be 
> less than time taken without index
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at 
> org.apache.geode.cache.query.BaseLineAndCompareQueryPerfJUnitTest.testPerformanceForRangeQueries(BaseLineAndCompareQueryPerfJUnitTest.java:299)



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

[GitHub] geode pull request #402: GEODE-2497 surprise members are never timed out dur...

[kirklund]

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

https://github.com/apache/geode/pull/402#discussion_r102331034
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionManagerDUnitTest.java
 ---
@@ -159,77 +159,74 @@ public void testConnectAfterBeingShunned() {
**/
   @Test
   public void testSurpriseMemberHandling() {
-VM vm0 = Host.getHost(0).getVM(0);
-
-InternalDistributedSystem sys = getSystem();
-MembershipManager mgr = 
MembershipManagerHelper.getMembershipManager(sys);
 
+System.setProperty(DistributionConfig.GEMFIRE_PREFIX + 
"surprise-member-timeout", "3000");
 try {
-  InternalDistributedMember mbr =
-  new InternalDistributedMember(NetworkUtils.getIPLiteral(), 
12345);
+  InternalDistributedSystem sys = getSystem();
+  MembershipManager mgr = 
MembershipManagerHelper.getMembershipManager(sys);
+  assertTrue(((GMSMembershipManager) mgr).isCleanupTimerStarted());
 
-  // first make sure we can't add this as a surprise member (bug 
#44566)
-
-  // if the view number isn't being recorded correctly the test will 
pass but the
-  // functionality is broken
-  Assert.assertTrue("expected view ID to be greater than zero", 
mgr.getView().getViewId() > 0);
-
-  int oldViewId = mbr.getVmViewId();
-  mbr.setVmViewId((int) mgr.getView().getViewId() - 1);
-  org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
-  .info("current membership view is " + mgr.getView());
-  org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
-  .info("created ID " + mbr + " with view ID " + 
mbr.getVmViewId());
-  sys.getLogWriter()
-  .info("attempt to add old 
member");
-  sys.getLogWriter()
-  .info("Removing shunned GemFire 
node");
   try {
-boolean accepted = mgr.addSurpriseMember(mbr);
-Assert.assertTrue("member with old ID was not rejected (bug 
#44566)", !accepted);
-  } finally {
+InternalDistributedMember mbr =
+new InternalDistributedMember(NetworkUtils.getIPLiteral(), 
12345);
+
+// first make sure we can't add this as a surprise member (bug 
#44566)
+
+// if the view number isn't being recorded correctly the test will 
pass but the
+// functionality is broken
+Assert.assertTrue("expected view ID to be greater than zero",
+mgr.getView().getViewId() > 0);
+
+int oldViewId = mbr.getVmViewId();
+mbr.setVmViewId((int) mgr.getView().getViewId() - 1);
+org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
+.info("current membership view is " + mgr.getView());
+org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
+.info("created ID " + mbr + " with view ID " + 
mbr.getVmViewId());
 sys.getLogWriter()
-.info("attempt to add old 
member");
+.info("attempt to add old 
member");
 sys.getLogWriter().info(
-"Removing shunned GemFire 
node");
-  }
-  mbr.setVmViewId(oldViewId);
-
-  // now forcibly add it as a surprise member and show that it is 
reaped
-  long gracePeriod = 5000;
-  long startTime = System.currentTimeMillis();
-  long timeout = ((GMSMembershipManager) 
mgr).getSurpriseMemberTimeout();
-  long birthTime = startTime - timeout + gracePeriod;
-  MembershipManagerHelper.addSurpriseMember(sys, mbr, birthTime);
-  assertTrue("Member was not a surprise member", 
mgr.isSurpriseMember(mbr));
-
-  // force a real view change
-  SerializableRunnable connectDisconnect = new SerializableRunnable() {
-public void run() {
-  getSystem().disconnect();
+"Removing shunned GemFire 
node");
+try {
+  boolean accepted = mgr.addSurpriseMember(mbr);
+  Assert.assertTrue("member with old ID was not rejected (bug 
#44566)", !accepted);
+} finally {
+  sys.getLogWriter().info(
+  "attempt to add old 
member");
--- End diff --

That's actually adding our custom IgnoredException. The purpose was to 
ignore these exceptions if they show up in the logs but not to Expect them in 
the same way as JUnit Expected Exceptions. We updated the Java API to "Ignored" 
(to differentiate it from JUnit's EE) but left the XML as "Expected" -- we 
should update the XML strings to match the Java code.


---
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, pleas

[jira] [Commented] (GEODE-2497) surprise members are never timed out during startup

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode/pull/402#discussion_r102331034
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionManagerDUnitTest.java
 ---
@@ -159,77 +159,74 @@ public void testConnectAfterBeingShunned() {
**/
   @Test
   public void testSurpriseMemberHandling() {
-VM vm0 = Host.getHost(0).getVM(0);
-
-InternalDistributedSystem sys = getSystem();
-MembershipManager mgr = 
MembershipManagerHelper.getMembershipManager(sys);
 
+System.setProperty(DistributionConfig.GEMFIRE_PREFIX + 
"surprise-member-timeout", "3000");
 try {
-  InternalDistributedMember mbr =
-  new InternalDistributedMember(NetworkUtils.getIPLiteral(), 
12345);
+  InternalDistributedSystem sys = getSystem();
+  MembershipManager mgr = 
MembershipManagerHelper.getMembershipManager(sys);
+  assertTrue(((GMSMembershipManager) mgr).isCleanupTimerStarted());
 
-  // first make sure we can't add this as a surprise member (bug 
#44566)
-
-  // if the view number isn't being recorded correctly the test will 
pass but the
-  // functionality is broken
-  Assert.assertTrue("expected view ID to be greater than zero", 
mgr.getView().getViewId() > 0);
-
-  int oldViewId = mbr.getVmViewId();
-  mbr.setVmViewId((int) mgr.getView().getViewId() - 1);
-  org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
-  .info("current membership view is " + mgr.getView());
-  org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
-  .info("created ID " + mbr + " with view ID " + 
mbr.getVmViewId());
-  sys.getLogWriter()
-  .info("attempt to add old 
member");
-  sys.getLogWriter()
-  .info("Removing shunned GemFire 
node");
   try {
-boolean accepted = mgr.addSurpriseMember(mbr);
-Assert.assertTrue("member with old ID was not rejected (bug 
#44566)", !accepted);
-  } finally {
+InternalDistributedMember mbr =
+new InternalDistributedMember(NetworkUtils.getIPLiteral(), 
12345);
+
+// first make sure we can't add this as a surprise member (bug 
#44566)
+
+// if the view number isn't being recorded correctly the test will 
pass but the
+// functionality is broken
+Assert.assertTrue("expected view ID to be greater than zero",
+mgr.getView().getViewId() > 0);
+
+int oldViewId = mbr.getVmViewId();
+mbr.setVmViewId((int) mgr.getView().getViewId() - 1);
+org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
+.info("current membership view is " + mgr.getView());
+org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
+.info("created ID " + mbr + " with view ID " + 
mbr.getVmViewId());
 sys.getLogWriter()
-.info("attempt to add old 
member");
+.info("attempt to add old 
member");
 sys.getLogWriter().info(
-"Removing shunned GemFire 
node");
-  }
-  mbr.setVmViewId(oldViewId);
-
-  // now forcibly add it as a surprise member and show that it is 
reaped
-  long gracePeriod = 5000;
-  long startTime = System.currentTimeMillis();
-  long timeout = ((GMSMembershipManager) 
mgr).getSurpriseMemberTimeout();
-  long birthTime = startTime - timeout + gracePeriod;
-  MembershipManagerHelper.addSurpriseMember(sys, mbr, birthTime);
-  assertTrue("Member was not a surprise member", 
mgr.isSurpriseMember(mbr));
-
-  // force a real view change
-  SerializableRunnable connectDisconnect = new SerializableRunnable() {
-public void run() {
-  getSystem().disconnect();
+"Removing shunned GemFire 
node");
+try {
+  boolean accepted = mgr.addSurpriseMember(mbr);
+  Assert.assertTrue("member with old ID was not rejected (bug 
#44566)", !accepted);
+} finally {
+  sys.getLogWriter().info(
+  "attempt to add old 
member");
--- End diff --

That's actually adding our custom IgnoredException. The purpose was to 
ignore these exceptions if they show up in the logs but not to Expect them in 
the same way as JUnit Expected Exceptions. We updated the Java API to "Ignored" 
(to differentiate it from JUnit's EE) but left the XML as "Expected" -- we 
should update the XML strings

[GitHub] geode pull request #402: GEODE-2497 surprise members are never timed out dur...

[kirklund]

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

https://github.com/apache/geode/pull/402#discussion_r102331716
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionManagerDUnitTest.java
 ---
@@ -159,77 +159,74 @@ public void testConnectAfterBeingShunned() {
**/
   @Test
   public void testSurpriseMemberHandling() {
-VM vm0 = Host.getHost(0).getVM(0);
-
-InternalDistributedSystem sys = getSystem();
-MembershipManager mgr = 
MembershipManagerHelper.getMembershipManager(sys);
 
+System.setProperty(DistributionConfig.GEMFIRE_PREFIX + 
"surprise-member-timeout", "3000");
 try {
-  InternalDistributedMember mbr =
-  new InternalDistributedMember(NetworkUtils.getIPLiteral(), 
12345);
+  InternalDistributedSystem sys = getSystem();
+  MembershipManager mgr = 
MembershipManagerHelper.getMembershipManager(sys);
+  assertTrue(((GMSMembershipManager) mgr).isCleanupTimerStarted());
 
-  // first make sure we can't add this as a surprise member (bug 
#44566)
-
-  // if the view number isn't being recorded correctly the test will 
pass but the
-  // functionality is broken
-  Assert.assertTrue("expected view ID to be greater than zero", 
mgr.getView().getViewId() > 0);
-
-  int oldViewId = mbr.getVmViewId();
-  mbr.setVmViewId((int) mgr.getView().getViewId() - 1);
-  org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
-  .info("current membership view is " + mgr.getView());
-  org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
-  .info("created ID " + mbr + " with view ID " + 
mbr.getVmViewId());
-  sys.getLogWriter()
-  .info("attempt to add old 
member");
-  sys.getLogWriter()
-  .info("Removing shunned GemFire 
node");
   try {
-boolean accepted = mgr.addSurpriseMember(mbr);
-Assert.assertTrue("member with old ID was not rejected (bug 
#44566)", !accepted);
-  } finally {
+InternalDistributedMember mbr =
+new InternalDistributedMember(NetworkUtils.getIPLiteral(), 
12345);
+
+// first make sure we can't add this as a surprise member (bug 
#44566)
+
+// if the view number isn't being recorded correctly the test will 
pass but the
+// functionality is broken
+Assert.assertTrue("expected view ID to be greater than zero",
+mgr.getView().getViewId() > 0);
+
+int oldViewId = mbr.getVmViewId();
+mbr.setVmViewId((int) mgr.getView().getViewId() - 1);
+org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
+.info("current membership view is " + mgr.getView());
+org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
+.info("created ID " + mbr + " with view ID " + 
mbr.getVmViewId());
 sys.getLogWriter()
-.info("attempt to add old 
member");
+.info("attempt to add old 
member");
 sys.getLogWriter().info(
-"Removing shunned GemFire 
node");
-  }
-  mbr.setVmViewId(oldViewId);
-
-  // now forcibly add it as a surprise member and show that it is 
reaped
-  long gracePeriod = 5000;
-  long startTime = System.currentTimeMillis();
-  long timeout = ((GMSMembershipManager) 
mgr).getSurpriseMemberTimeout();
-  long birthTime = startTime - timeout + gracePeriod;
-  MembershipManagerHelper.addSurpriseMember(sys, mbr, birthTime);
-  assertTrue("Member was not a surprise member", 
mgr.isSurpriseMember(mbr));
-
-  // force a real view change
-  SerializableRunnable connectDisconnect = new SerializableRunnable() {
-public void run() {
-  getSystem().disconnect();
+"Removing shunned GemFire 
node");
+try {
+  boolean accepted = mgr.addSurpriseMember(mbr);
+  Assert.assertTrue("member with old ID was not rejected (bug 
#44566)", !accepted);
+} finally {
+  sys.getLogWriter().info(
+  "attempt to add old 
member");
+  sys.getLogWriter().info(
+  "Removing shunned GemFire 
node");
 }
-  };
-  vm0.invoke(connectDisconnect);
-
-  if (birthTime < (System.currentTimeMillis() - timeout)) {
-return; // machine is too busy and we didn't get enough CPU to 
perform more assertions
-  }
-  assertTrue("Member was incorrectly removed from surprise member set",
-  mgr.isSurpriseMember(mbr));
+mbr.setVmViewId(oldViewId);
+
+// now forcibly add it as a surprise member and show that it is 
reaped
+   

[GitHub] geode pull request #402: GEODE-2497 surprise members are never timed out dur...

[kirklund]

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

https://github.com/apache/geode/pull/402#discussion_r102332307
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionManagerDUnitTest.java
 ---
@@ -159,77 +159,74 @@ public void testConnectAfterBeingShunned() {
**/
   @Test
   public void testSurpriseMemberHandling() {
-VM vm0 = Host.getHost(0).getVM(0);
-
-InternalDistributedSystem sys = getSystem();
-MembershipManager mgr = 
MembershipManagerHelper.getMembershipManager(sys);
 
+System.setProperty(DistributionConfig.GEMFIRE_PREFIX + 
"surprise-member-timeout", "3000");
 try {
-  InternalDistributedMember mbr =
-  new InternalDistributedMember(NetworkUtils.getIPLiteral(), 
12345);
+  InternalDistributedSystem sys = getSystem();
+  MembershipManager mgr = 
MembershipManagerHelper.getMembershipManager(sys);
+  assertTrue(((GMSMembershipManager) mgr).isCleanupTimerStarted());
 
-  // first make sure we can't add this as a surprise member (bug 
#44566)
-
-  // if the view number isn't being recorded correctly the test will 
pass but the
-  // functionality is broken
-  Assert.assertTrue("expected view ID to be greater than zero", 
mgr.getView().getViewId() > 0);
-
-  int oldViewId = mbr.getVmViewId();
-  mbr.setVmViewId((int) mgr.getView().getViewId() - 1);
-  org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
-  .info("current membership view is " + mgr.getView());
-  org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
-  .info("created ID " + mbr + " with view ID " + 
mbr.getVmViewId());
-  sys.getLogWriter()
-  .info("attempt to add old 
member");
-  sys.getLogWriter()
-  .info("Removing shunned GemFire 
node");
   try {
-boolean accepted = mgr.addSurpriseMember(mbr);
-Assert.assertTrue("member with old ID was not rejected (bug 
#44566)", !accepted);
-  } finally {
+InternalDistributedMember mbr =
+new InternalDistributedMember(NetworkUtils.getIPLiteral(), 
12345);
+
+// first make sure we can't add this as a surprise member (bug 
#44566)
+
+// if the view number isn't being recorded correctly the test will 
pass but the
+// functionality is broken
+Assert.assertTrue("expected view ID to be greater than zero",
+mgr.getView().getViewId() > 0);
+
+int oldViewId = mbr.getVmViewId();
+mbr.setVmViewId((int) mgr.getView().getViewId() - 1);
+org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
+.info("current membership view is " + mgr.getView());
+org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
+.info("created ID " + mbr + " with view ID " + 
mbr.getVmViewId());
 sys.getLogWriter()
-.info("attempt to add old 
member");
+.info("attempt to add old 
member");
 sys.getLogWriter().info(
-"Removing shunned GemFire 
node");
-  }
-  mbr.setVmViewId(oldViewId);
-
-  // now forcibly add it as a surprise member and show that it is 
reaped
-  long gracePeriod = 5000;
-  long startTime = System.currentTimeMillis();
-  long timeout = ((GMSMembershipManager) 
mgr).getSurpriseMemberTimeout();
-  long birthTime = startTime - timeout + gracePeriod;
-  MembershipManagerHelper.addSurpriseMember(sys, mbr, birthTime);
-  assertTrue("Member was not a surprise member", 
mgr.isSurpriseMember(mbr));
-
-  // force a real view change
-  SerializableRunnable connectDisconnect = new SerializableRunnable() {
-public void run() {
-  getSystem().disconnect();
+"Removing shunned GemFire 
node");
+try {
+  boolean accepted = mgr.addSurpriseMember(mbr);
+  Assert.assertTrue("member with old ID was not rejected (bug 
#44566)", !accepted);
+} finally {
+  sys.getLogWriter().info(
+  "attempt to add old 
member");
+  sys.getLogWriter().info(
+  "Removing shunned GemFire 
node");
 }
-  };
-  vm0.invoke(connectDisconnect);
-
-  if (birthTime < (System.currentTimeMillis() - timeout)) {
-return; // machine is too busy and we didn't get enough CPU to 
perform more assertions
-  }
-  assertTrue("Member was incorrectly removed from surprise member set",
-  mgr.isSurpriseMember(mbr));
+mbr.setVmViewId(oldViewId);
+
+// now forcibly add it as a surprise member and show that it is 
reaped
+   

[jira] [Commented] (GEODE-2497) surprise members are never timed out during startup

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode/pull/402#discussion_r102332744
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/mgr/GMSMembershipManager.java
 ---
@@ -978,43 +977,33 @@ public void run() {
 
   /** starts periodic task to perform cleanup chores such as expire 
surprise members */
   private void startCleanupTimer() {
-latestViewWriteLock.lock();
-try {
-  if (this.cleanupTimer != null) {
-return;
-  }
-  DistributedSystem ds = InternalDistributedSystem.getAnyInstance();
-  if (ds != null && ds.isConnected()) {
-this.cleanupTimer = new SystemTimer(ds, true);
-SystemTimer.SystemTimerTask st = new SystemTimer.SystemTimerTask() 
{
-  @Override
-  public void run2() {
-latestViewWriteLock.lock();
-try {
-  long oldestAllowed = System.currentTimeMillis() - 
surpriseMemberTimeout;
-  for (Iterator it = surpriseMembers.entrySet().iterator(); 
it.hasNext();) {
-Map.Entry entry = (Map.Entry) it.next();
-Long birthtime = (Long) entry.getValue();
-if (birthtime.longValue() < oldestAllowed) {
-  it.remove();
-  InternalDistributedMember m = 
(InternalDistributedMember) entry.getKey();
-  logger.info(LocalizedMessage.create(
-  
LocalizedStrings.GroupMembershipService_MEMBERSHIP_EXPIRING_MEMBERSHIP_OF_SURPRISE_MEMBER_0,
-  m));
-  removeWithViewLock(m, true,
-  "not seen in membership view in " + 
surpriseMemberTimeout + "ms");
-}
-  }
-} finally {
-  latestViewWriteLock.unlock();
+DistributedSystem ds = this.dcReceiver.getDM().getSystem();
+this.cleanupTimer = new SystemTimer(ds, true);
+SystemTimer.SystemTimerTask st = new SystemTimer.SystemTimerTask() {
+  @Override
+  public void run2() {
+latestViewWriteLock.lock();
+try {
+  long oldestAllowed = System.currentTimeMillis() - 
surpriseMemberTimeout;
+  for (Iterator it = surpriseMembers.entrySet().iterator(); 
it.hasNext();) {
+Map.Entry entry = (Map.Entry) it.next();
+Long birthtime = (Long) entry.getValue();
+if (birthtime.longValue() < oldestAllowed) {
--- End diff --

As I find deeply nested blocks like this, I've been extracting them to 
private methods in the class. The entire run-block could be extracted to one 
method and/or you could break it up into multiple methods.


> surprise members are never timed out during startup
> ---
>
> Key: GEODE-2497
> URL: https://issues.apache.org/jira/browse/GEODE-2497
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>
> A system was observed to hang during startup when a "surprise member" was 
> added but then never timed out.  The system hung waiting for a response to a 
> startup message sent to the surprise member.



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

[GitHub] geode pull request #402: GEODE-2497 surprise members are never timed out dur...

[kirklund]

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

https://github.com/apache/geode/pull/402#discussion_r102332744
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/mgr/GMSMembershipManager.java
 ---
@@ -978,43 +977,33 @@ public void run() {
 
   /** starts periodic task to perform cleanup chores such as expire 
surprise members */
   private void startCleanupTimer() {
-latestViewWriteLock.lock();
-try {
-  if (this.cleanupTimer != null) {
-return;
-  }
-  DistributedSystem ds = InternalDistributedSystem.getAnyInstance();
-  if (ds != null && ds.isConnected()) {
-this.cleanupTimer = new SystemTimer(ds, true);
-SystemTimer.SystemTimerTask st = new SystemTimer.SystemTimerTask() 
{
-  @Override
-  public void run2() {
-latestViewWriteLock.lock();
-try {
-  long oldestAllowed = System.currentTimeMillis() - 
surpriseMemberTimeout;
-  for (Iterator it = surpriseMembers.entrySet().iterator(); 
it.hasNext();) {
-Map.Entry entry = (Map.Entry) it.next();
-Long birthtime = (Long) entry.getValue();
-if (birthtime.longValue() < oldestAllowed) {
-  it.remove();
-  InternalDistributedMember m = 
(InternalDistributedMember) entry.getKey();
-  logger.info(LocalizedMessage.create(
-  
LocalizedStrings.GroupMembershipService_MEMBERSHIP_EXPIRING_MEMBERSHIP_OF_SURPRISE_MEMBER_0,
-  m));
-  removeWithViewLock(m, true,
-  "not seen in membership view in " + 
surpriseMemberTimeout + "ms");
-}
-  }
-} finally {
-  latestViewWriteLock.unlock();
+DistributedSystem ds = this.dcReceiver.getDM().getSystem();
+this.cleanupTimer = new SystemTimer(ds, true);
+SystemTimer.SystemTimerTask st = new SystemTimer.SystemTimerTask() {
+  @Override
+  public void run2() {
+latestViewWriteLock.lock();
+try {
+  long oldestAllowed = System.currentTimeMillis() - 
surpriseMemberTimeout;
+  for (Iterator it = surpriseMembers.entrySet().iterator(); 
it.hasNext();) {
+Map.Entry entry = (Map.Entry) it.next();
+Long birthtime = (Long) entry.getValue();
+if (birthtime.longValue() < oldestAllowed) {
--- End diff --

As I find deeply nested blocks like this, I've been extracting them to 
private methods in the class. The entire run-block could be extracted to one 
method and/or you could break it up into multiple methods.


---
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-2497) surprise members are never timed out during startup

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode/pull/402#discussion_r102332307
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionManagerDUnitTest.java
 ---
@@ -159,77 +159,74 @@ public void testConnectAfterBeingShunned() {
**/
   @Test
   public void testSurpriseMemberHandling() {
-VM vm0 = Host.getHost(0).getVM(0);
-
-InternalDistributedSystem sys = getSystem();
-MembershipManager mgr = 
MembershipManagerHelper.getMembershipManager(sys);
 
+System.setProperty(DistributionConfig.GEMFIRE_PREFIX + 
"surprise-member-timeout", "3000");
 try {
-  InternalDistributedMember mbr =
-  new InternalDistributedMember(NetworkUtils.getIPLiteral(), 
12345);
+  InternalDistributedSystem sys = getSystem();
+  MembershipManager mgr = 
MembershipManagerHelper.getMembershipManager(sys);
+  assertTrue(((GMSMembershipManager) mgr).isCleanupTimerStarted());
 
-  // first make sure we can't add this as a surprise member (bug 
#44566)
-
-  // if the view number isn't being recorded correctly the test will 
pass but the
-  // functionality is broken
-  Assert.assertTrue("expected view ID to be greater than zero", 
mgr.getView().getViewId() > 0);
-
-  int oldViewId = mbr.getVmViewId();
-  mbr.setVmViewId((int) mgr.getView().getViewId() - 1);
-  org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
-  .info("current membership view is " + mgr.getView());
-  org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
-  .info("created ID " + mbr + " with view ID " + 
mbr.getVmViewId());
-  sys.getLogWriter()
-  .info("attempt to add old 
member");
-  sys.getLogWriter()
-  .info("Removing shunned GemFire 
node");
   try {
-boolean accepted = mgr.addSurpriseMember(mbr);
-Assert.assertTrue("member with old ID was not rejected (bug 
#44566)", !accepted);
-  } finally {
+InternalDistributedMember mbr =
+new InternalDistributedMember(NetworkUtils.getIPLiteral(), 
12345);
+
+// first make sure we can't add this as a surprise member (bug 
#44566)
+
+// if the view number isn't being recorded correctly the test will 
pass but the
+// functionality is broken
+Assert.assertTrue("expected view ID to be greater than zero",
+mgr.getView().getViewId() > 0);
+
+int oldViewId = mbr.getVmViewId();
+mbr.setVmViewId((int) mgr.getView().getViewId() - 1);
+org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
+.info("current membership view is " + mgr.getView());
+org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
+.info("created ID " + mbr + " with view ID " + 
mbr.getVmViewId());
 sys.getLogWriter()
-.info("attempt to add old 
member");
+.info("attempt to add old 
member");
 sys.getLogWriter().info(
-"Removing shunned GemFire 
node");
-  }
-  mbr.setVmViewId(oldViewId);
-
-  // now forcibly add it as a surprise member and show that it is 
reaped
-  long gracePeriod = 5000;
-  long startTime = System.currentTimeMillis();
-  long timeout = ((GMSMembershipManager) 
mgr).getSurpriseMemberTimeout();
-  long birthTime = startTime - timeout + gracePeriod;
-  MembershipManagerHelper.addSurpriseMember(sys, mbr, birthTime);
-  assertTrue("Member was not a surprise member", 
mgr.isSurpriseMember(mbr));
-
-  // force a real view change
-  SerializableRunnable connectDisconnect = new SerializableRunnable() {
-public void run() {
-  getSystem().disconnect();
+"Removing shunned GemFire 
node");
+try {
+  boolean accepted = mgr.addSurpriseMember(mbr);
+  Assert.assertTrue("member with old ID was not rejected (bug 
#44566)", !accepted);
+} finally {
+  sys.getLogWriter().info(
+  "attempt to add old 
member");
+  sys.getLogWriter().info(
+  "Removing shunned GemFire 
node");
 }
-  };
-  vm0.invoke(connectDisconnect);
-
-  if (birthTime < (System.currentTimeMillis() - timeout)) {
-return; // machine is too busy and we didn't get enough CPU to 
perform more assertions
-  }
-  a

[jira] [Commented] (GEODE-2497) surprise members are never timed out during startup

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode/pull/402#discussion_r102331716
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionManagerDUnitTest.java
 ---
@@ -159,77 +159,74 @@ public void testConnectAfterBeingShunned() {
**/
   @Test
   public void testSurpriseMemberHandling() {
-VM vm0 = Host.getHost(0).getVM(0);
-
-InternalDistributedSystem sys = getSystem();
-MembershipManager mgr = 
MembershipManagerHelper.getMembershipManager(sys);
 
+System.setProperty(DistributionConfig.GEMFIRE_PREFIX + 
"surprise-member-timeout", "3000");
 try {
-  InternalDistributedMember mbr =
-  new InternalDistributedMember(NetworkUtils.getIPLiteral(), 
12345);
+  InternalDistributedSystem sys = getSystem();
+  MembershipManager mgr = 
MembershipManagerHelper.getMembershipManager(sys);
+  assertTrue(((GMSMembershipManager) mgr).isCleanupTimerStarted());
 
-  // first make sure we can't add this as a surprise member (bug 
#44566)
-
-  // if the view number isn't being recorded correctly the test will 
pass but the
-  // functionality is broken
-  Assert.assertTrue("expected view ID to be greater than zero", 
mgr.getView().getViewId() > 0);
-
-  int oldViewId = mbr.getVmViewId();
-  mbr.setVmViewId((int) mgr.getView().getViewId() - 1);
-  org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
-  .info("current membership view is " + mgr.getView());
-  org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
-  .info("created ID " + mbr + " with view ID " + 
mbr.getVmViewId());
-  sys.getLogWriter()
-  .info("attempt to add old 
member");
-  sys.getLogWriter()
-  .info("Removing shunned GemFire 
node");
   try {
-boolean accepted = mgr.addSurpriseMember(mbr);
-Assert.assertTrue("member with old ID was not rejected (bug 
#44566)", !accepted);
-  } finally {
+InternalDistributedMember mbr =
+new InternalDistributedMember(NetworkUtils.getIPLiteral(), 
12345);
+
+// first make sure we can't add this as a surprise member (bug 
#44566)
+
+// if the view number isn't being recorded correctly the test will 
pass but the
+// functionality is broken
+Assert.assertTrue("expected view ID to be greater than zero",
+mgr.getView().getViewId() > 0);
+
+int oldViewId = mbr.getVmViewId();
+mbr.setVmViewId((int) mgr.getView().getViewId() - 1);
+org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
+.info("current membership view is " + mgr.getView());
+org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
+.info("created ID " + mbr + " with view ID " + 
mbr.getVmViewId());
 sys.getLogWriter()
-.info("attempt to add old 
member");
+.info("attempt to add old 
member");
 sys.getLogWriter().info(
-"Removing shunned GemFire 
node");
-  }
-  mbr.setVmViewId(oldViewId);
-
-  // now forcibly add it as a surprise member and show that it is 
reaped
-  long gracePeriod = 5000;
-  long startTime = System.currentTimeMillis();
-  long timeout = ((GMSMembershipManager) 
mgr).getSurpriseMemberTimeout();
-  long birthTime = startTime - timeout + gracePeriod;
-  MembershipManagerHelper.addSurpriseMember(sys, mbr, birthTime);
-  assertTrue("Member was not a surprise member", 
mgr.isSurpriseMember(mbr));
-
-  // force a real view change
-  SerializableRunnable connectDisconnect = new SerializableRunnable() {
-public void run() {
-  getSystem().disconnect();
+"Removing shunned GemFire 
node");
+try {
+  boolean accepted = mgr.addSurpriseMember(mbr);
+  Assert.assertTrue("member with old ID was not rejected (bug 
#44566)", !accepted);
+} finally {
+  sys.getLogWriter().info(
+  "attempt to add old 
member");
+  sys.getLogWriter().info(
+  "Removing shunned GemFire 
node");
 }
-  };
-  vm0.invoke(connectDisconnect);
-
-  if (birthTime < (System.currentTimeMillis() - timeout)) {
-return; // machine is too busy and we didn't get enough CPU to 
perform more assertions
-  }
-  a

[GitHub] geode pull request #402: GEODE-2497 surprise members are never timed out dur...

[kirklund]

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

https://github.com/apache/geode/pull/402#discussion_r102334223
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionManagerDUnitTest.java
 ---
@@ -159,77 +159,74 @@ public void testConnectAfterBeingShunned() {
**/
   @Test
   public void testSurpriseMemberHandling() {
-VM vm0 = Host.getHost(0).getVM(0);
-
-InternalDistributedSystem sys = getSystem();
-MembershipManager mgr = 
MembershipManagerHelper.getMembershipManager(sys);
 
+System.setProperty(DistributionConfig.GEMFIRE_PREFIX + 
"surprise-member-timeout", "3000");
 try {
-  InternalDistributedMember mbr =
-  new InternalDistributedMember(NetworkUtils.getIPLiteral(), 
12345);
+  InternalDistributedSystem sys = getSystem();
+  MembershipManager mgr = 
MembershipManagerHelper.getMembershipManager(sys);
+  assertTrue(((GMSMembershipManager) mgr).isCleanupTimerStarted());
 
-  // first make sure we can't add this as a surprise member (bug 
#44566)
-
-  // if the view number isn't being recorded correctly the test will 
pass but the
-  // functionality is broken
-  Assert.assertTrue("expected view ID to be greater than zero", 
mgr.getView().getViewId() > 0);
-
-  int oldViewId = mbr.getVmViewId();
-  mbr.setVmViewId((int) mgr.getView().getViewId() - 1);
-  org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
-  .info("current membership view is " + mgr.getView());
-  org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
-  .info("created ID " + mbr + " with view ID " + 
mbr.getVmViewId());
-  sys.getLogWriter()
-  .info("attempt to add old 
member");
-  sys.getLogWriter()
-  .info("Removing shunned GemFire 
node");
   try {
-boolean accepted = mgr.addSurpriseMember(mbr);
-Assert.assertTrue("member with old ID was not rejected (bug 
#44566)", !accepted);
-  } finally {
+InternalDistributedMember mbr =
+new InternalDistributedMember(NetworkUtils.getIPLiteral(), 
12345);
+
+// first make sure we can't add this as a surprise member (bug 
#44566)
+
+// if the view number isn't being recorded correctly the test will 
pass but the
+// functionality is broken
+Assert.assertTrue("expected view ID to be greater than zero",
+mgr.getView().getViewId() > 0);
+
+int oldViewId = mbr.getVmViewId();
+mbr.setVmViewId((int) mgr.getView().getViewId() - 1);
+org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
+.info("current membership view is " + mgr.getView());
+org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
+.info("created ID " + mbr + " with view ID " + 
mbr.getVmViewId());
 sys.getLogWriter()
-.info("attempt to add old 
member");
+.info("attempt to add old 
member");
--- End diff --

I forgot we left the xml strings as "ExpectedException" -- you might want 
to chagne this to use the Java API instead of logging a hardcoded string. This 
will help if and when we ever decide to update the xml strings:
```java
IgnoredException.addIgnoredException("attempt to add old member");
```
If you call the static addIgnoredException like this, then it automatically 
gets added to a collection which is part of the dunit tearDown cleanup (ie, it 
will log the removals for you).



---
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-2497) surprise members are never timed out during startup

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode/pull/402#discussion_r102334223
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionManagerDUnitTest.java
 ---
@@ -159,77 +159,74 @@ public void testConnectAfterBeingShunned() {
**/
   @Test
   public void testSurpriseMemberHandling() {
-VM vm0 = Host.getHost(0).getVM(0);
-
-InternalDistributedSystem sys = getSystem();
-MembershipManager mgr = 
MembershipManagerHelper.getMembershipManager(sys);
 
+System.setProperty(DistributionConfig.GEMFIRE_PREFIX + 
"surprise-member-timeout", "3000");
 try {
-  InternalDistributedMember mbr =
-  new InternalDistributedMember(NetworkUtils.getIPLiteral(), 
12345);
+  InternalDistributedSystem sys = getSystem();
+  MembershipManager mgr = 
MembershipManagerHelper.getMembershipManager(sys);
+  assertTrue(((GMSMembershipManager) mgr).isCleanupTimerStarted());
 
-  // first make sure we can't add this as a surprise member (bug 
#44566)
-
-  // if the view number isn't being recorded correctly the test will 
pass but the
-  // functionality is broken
-  Assert.assertTrue("expected view ID to be greater than zero", 
mgr.getView().getViewId() > 0);
-
-  int oldViewId = mbr.getVmViewId();
-  mbr.setVmViewId((int) mgr.getView().getViewId() - 1);
-  org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
-  .info("current membership view is " + mgr.getView());
-  org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
-  .info("created ID " + mbr + " with view ID " + 
mbr.getVmViewId());
-  sys.getLogWriter()
-  .info("attempt to add old 
member");
-  sys.getLogWriter()
-  .info("Removing shunned GemFire 
node");
   try {
-boolean accepted = mgr.addSurpriseMember(mbr);
-Assert.assertTrue("member with old ID was not rejected (bug 
#44566)", !accepted);
-  } finally {
+InternalDistributedMember mbr =
+new InternalDistributedMember(NetworkUtils.getIPLiteral(), 
12345);
+
+// first make sure we can't add this as a surprise member (bug 
#44566)
+
+// if the view number isn't being recorded correctly the test will 
pass but the
+// functionality is broken
+Assert.assertTrue("expected view ID to be greater than zero",
+mgr.getView().getViewId() > 0);
+
+int oldViewId = mbr.getVmViewId();
+mbr.setVmViewId((int) mgr.getView().getViewId() - 1);
+org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
+.info("current membership view is " + mgr.getView());
+org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
+.info("created ID " + mbr + " with view ID " + 
mbr.getVmViewId());
 sys.getLogWriter()
-.info("attempt to add old 
member");
+.info("attempt to add old 
member");
--- End diff --

I forgot we left the xml strings as "ExpectedException" -- you might want 
to chagne this to use the Java API instead of logging a hardcoded string. This 
will help if and when we ever decide to update the xml strings:
```java
IgnoredException.addIgnoredException("attempt to add old member");
```
If you call the static addIgnoredException like this, then it automatically 
gets added to a collection which is part of the dunit tearDown cleanup (ie, it 
will log the removals for you).



> surprise members are never timed out during startup
> ---
>
> Key: GEODE-2497
> URL: https://issues.apache.org/jira/browse/GEODE-2497
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>
> A system was observed to hang during startup when a "surprise member" was 
> added but then never timed out.  The system hung waiting for a response to a 
> startup message sent to the surprise member.



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

[jira] [Assigned] (GEODE-369) CI failure: RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByPut fails intermittently with assertion

[Jason Huynh (JIRA)]

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

Jason Huynh reassigned GEODE-369:
-

Assignee: Jason Huynh  (was: Anilkumar Gingade)

> CI failure: 
> RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByPut
>  fails intermittently with assertion
> 
>
> Key: GEODE-369
> URL: https://issues.apache.org/jira/browse/GEODE-369
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Darrel Schneider
>Assignee: Jason Huynh
>Priority: Minor
>  Labels: CI
> Fix For: 1.0.0-incubating.M2
>
>
> failed on a private build of git rev :
> {code}
> junit.framework.AssertionFailedError: Event never occurred after 6 ms: 
> Redundant servers ([doomtwo.gemstone.com29009]) does not contain 
> doomtwo.gemstone.com27615
>   at junit.framework.Assert.fail(Assert.java:57)
>   at junit.framework.TestCase.fail(TestCase.java:227)
>   at 
> dunit.DistributedTestCase.waitForCriterion(DistributedTestCase.java:1162)
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.RedundancyLevelTestBase.verifyRedundantServersContain(RedundancyLevelTestBase.java:267)
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByPut(RedundancyLevelPart1DUnitTest.java:505)
> {code}



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

[jira] [Assigned] (GEODE-369) CI failure: RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByPut fails intermittently with assertion

[Jason Huynh (JIRA)]

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

Jason Huynh reassigned GEODE-369:
-

Assignee: (was: Jason Huynh)

> CI failure: 
> RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByPut
>  fails intermittently with assertion
> 
>
> Key: GEODE-369
> URL: https://issues.apache.org/jira/browse/GEODE-369
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Darrel Schneider
>Priority: Minor
>  Labels: CI
> Fix For: 1.0.0-incubating.M2
>
>
> failed on a private build of git rev :
> {code}
> junit.framework.AssertionFailedError: Event never occurred after 6 ms: 
> Redundant servers ([doomtwo.gemstone.com29009]) does not contain 
> doomtwo.gemstone.com27615
>   at junit.framework.Assert.fail(Assert.java:57)
>   at junit.framework.TestCase.fail(TestCase.java:227)
>   at 
> dunit.DistributedTestCase.waitForCriterion(DistributedTestCase.java:1162)
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.RedundancyLevelTestBase.verifyRedundantServersContain(RedundancyLevelTestBase.java:267)
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByPut(RedundancyLevelPart1DUnitTest.java:505)
> {code}



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

[GitHub] geode issue #403: GEODE-2506 Update Spring from 4.3.2 to 4.3.6

[jaredjstewart]

Github user jaredjstewart commented on the issue:

https://github.com/apache/geode/pull/403
  
Can you explain why the version override strategy is necessary?  I think 
geode-pulse (or any other submodule with an explicit dependency on 
commons-beantuils) should end up with version 1.9.3 already without any change 
to `dependency-resolution.gradle`, since the version you've specified (1.9.3) 
is higher than the one coming in transitively (1.8.3).


---
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-2506) Update spring dependencies

[ASF GitHub Bot (JIRA)]

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

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

Github user jaredjstewart commented on the issue:

https://github.com/apache/geode/pull/403
  
Can you explain why the version override strategy is necessary?  I think 
geode-pulse (or any other submodule with an explicit dependency on 
commons-beantuils) should end up with version 1.9.3 already without any change 
to `dependency-resolution.gradle`, since the version you've specified (1.9.3) 
is higher than the one coming in transitively (1.8.3).


> Update spring dependencies
> --
>
> Key: GEODE-2506
> URL: https://issues.apache.org/jira/browse/GEODE-2506
> Project: Geode
>  Issue Type: Improvement
>  Components: build
>Reporter: Anthony Baker
>
> Update Spring dependencies from 4.3.2 to 4.3.6 to pick up latest maintenance 
> and security fixes.



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

[jira] [Updated] (GEODE-369) CI failure: RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByPut fails intermittently with assertion

[Jason Huynh (JIRA)]

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

Jason Huynh updated GEODE-369:
--
Component/s: client queues

> CI failure: 
> RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByPut
>  fails intermittently with assertion
> 
>
> Key: GEODE-369
> URL: https://issues.apache.org/jira/browse/GEODE-369
> Project: Geode
>  Issue Type: Bug
>  Components: client queues, client/server
>Reporter: Darrel Schneider
>Priority: Minor
>  Labels: CI
> Fix For: 1.0.0-incubating.M2
>
>
> failed on a private build of git rev :
> {code}
> junit.framework.AssertionFailedError: Event never occurred after 6 ms: 
> Redundant servers ([doomtwo.gemstone.com29009]) does not contain 
> doomtwo.gemstone.com27615
>   at junit.framework.Assert.fail(Assert.java:57)
>   at junit.framework.TestCase.fail(TestCase.java:227)
>   at 
> dunit.DistributedTestCase.waitForCriterion(DistributedTestCase.java:1162)
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.RedundancyLevelTestBase.verifyRedundantServersContain(RedundancyLevelTestBase.java:267)
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByPut(RedundancyLevelPart1DUnitTest.java:505)
> {code}



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

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

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #479 was successful.
---
Scheduled
1681 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

[jira] [Created] (GEODE-2516) Script to Run Quickstarts not exectable

[Michael Martell (JIRA)]

Michael Martell created GEODE-2516:
--

 Summary: Script to Run Quickstarts not exectable
 Key: GEODE-2516
 URL: https://issues.apache.org/jira/browse/GEODE-2516
 Project: Geode
  Issue Type: Bug
  Components: native client
Reporter: Michael Martell


The runcpp.sh script for running the native client quickstarts is not 
executable.



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

[jira] [Commented] (GEODE-2516) Script to Run Quickstarts not exectable

[Michael Dodge (JIRA)]

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

Michael Dodge commented on GEODE-2516:
--

If memory serves, there is some wackiness in CMake that makes it challenging to 
successfully alter the executable permissions on files. At one time I think 
there were comments in the CMakeLists.txt files that explained it.

> Script to Run Quickstarts not exectable
> ---
>
> Key: GEODE-2516
> URL: https://issues.apache.org/jira/browse/GEODE-2516
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Martell
>
> The runcpp.sh script for running the native client quickstarts is not 
> executable.



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

[GitHub] geode pull request #390: [GEODE-1887] #comment Fix Issue Client PROXY region...

[kirklund]

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

https://github.com/apache/geode/pull/390#discussion_r102340380
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/ClientServerMiscDUnitTest.java
 ---
@@ -773,6 +755,73 @@ public void 
clientIsPreventedFromConnectingToLocatorAsServer() throws Exception
   }
 
 
+  private void proxyRegionClientServerOp(RegionShortcut shortcut) throws 
Exception {
+// start server first
+final String REGION_NAME = "proxyRegionClientServerOp";
+PORT1 = initServerCache(false);
+// Create regions on servers.
+server1.invoke(new SerializableCallable() {
--- End diff --

SerializableRunnable supports "public void run() throws Exception" so 
there's no need to use SerializableCallable unless you need to return a type. 
You also don't really need to 1st assertNotNull since c.createRegionFactory 
will throw NPE:
```Java
 server1.invoke(() -> {
  Cache c = CacheFactory.getAnyInstance();
  Region r = 
c.createRegionFactory(shortcut).create(REGION_NAME);
  assertNotNull(r);
  });
```


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

[GitHub] geode pull request #390: [GEODE-1887] #comment Fix Issue Client PROXY region...

[kirklund]

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

https://github.com/apache/geode/pull/390#discussion_r102338250
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/ClientServerMiscDUnitTest.java
 ---
@@ -773,6 +755,73 @@ public void 
clientIsPreventedFromConnectingToLocatorAsServer() throws Exception
   }
 
 
+  private void proxyRegionClientServerOp(RegionShortcut shortcut) throws 
Exception {
+// start server first
+final String REGION_NAME = "proxyRegionClientServerOp";
+PORT1 = initServerCache(false);
+// Create regions on servers.
+server1.invoke(new SerializableCallable() {
+  @Override
+  public Object call() throws Exception {
+Cache c = CacheFactory.getAnyInstance();
+assertNotNull(c);
+Region r = 
c.createRegionFactory(shortcut).create(REGION_NAME);
+assertNotNull(r);
+return null;
+  }
+});
+
+String host = NetworkUtils.getServerHostName(server1.getHost());
+
+Properties props = new Properties();
+props.setProperty(MCAST_PORT, "0");
+props.setProperty(LOCATORS, "");
+ClientCacheFactory ccf = new ClientCacheFactory(props);
+ccf.addPoolServer(host, PORT1);
+
+ClientCache clientCache = ccf.create();
+Region clientRegion =
+
clientCache.createClientRegionFactory(ClientRegionShortcut.PROXY).create(REGION_NAME);
+assertNotNull(clientRegion);
+
+// let us populate this region from client.
+for (int i = 0; i < 10; i++) {
+  clientRegion.put(i, i * 10);
+}
+// Verify using gets
+for (int i = 0; i < 10; i++) {
+  assertEquals(i * 10, clientRegion.get(i));
+}
+assertEquals(10, clientRegion.size());
+assertFalse(clientRegion.isEmpty());
+// delete all the entries from the server
+server1.invoke(new SerializableCallable() {
+  @Override
+  public Object call() throws Exception {
+Cache c = CacheFactory.getAnyInstance();
+assertNotNull(c);
+Region r = c.getRegion(REGION_NAME);
+assertNotNull(r);
+for (int i = 0; i < 10; i++) {
+  r.remove(i);
+}
+return null;
+  }
+});
+assertEquals(0, clientRegion.size());
+assertTrue(clientRegion.isEmpty());
+
+clientRegion.destroyRegion();
+clientCache.close();
+  }
+
+  @Test
--- End diff --

Another option I really like is to use JUnitParams with DUnit:
```Java
@Category({DistributedTest.class, ClientServerTest.class})
@RunWith(JUnitParamsRunner.class)
public class ClientServerMiscDUnitTest extends JUnit4CacheTestCase {

  @Test
  @Parameters(method = "regionShortcut")
  public void testProxyRegionClientServerOp(RegionShortcut regionShortcut) 
throws Exception {
// test goes here
  }

  private RegionShortcut[] regionShortcut() {
return new RegionShortcut[] { RegionShortcut.PARTITION, 
RegionShortcut.REPLICATE };
  }
```


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

[GitHub] geode pull request #390: [GEODE-1887] #comment Fix Issue Client PROXY region...

[kirklund]

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

https://github.com/apache/geode/pull/390#discussion_r102338898
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/ClientServerMiscDUnitTest.java
 ---
@@ -773,6 +755,73 @@ public void 
clientIsPreventedFromConnectingToLocatorAsServer() throws Exception
   }
 
 
+  private void proxyRegionClientServerOp(RegionShortcut shortcut) throws 
Exception {
+// start server first
+final String REGION_NAME = "proxyRegionClientServerOp";
+PORT1 = initServerCache(false);
+// Create regions on servers.
+server1.invoke(new SerializableCallable() {
+  @Override
+  public Object call() throws Exception {
+Cache c = CacheFactory.getAnyInstance();
+assertNotNull(c);
+Region r = 
c.createRegionFactory(shortcut).create(REGION_NAME);
+assertNotNull(r);
+return null;
+  }
+});
+
+String host = NetworkUtils.getServerHostName(server1.getHost());
+
+Properties props = new Properties();
+props.setProperty(MCAST_PORT, "0");
+props.setProperty(LOCATORS, "");
+ClientCacheFactory ccf = new ClientCacheFactory(props);
+ccf.addPoolServer(host, PORT1);
+
+ClientCache clientCache = ccf.create();
+Region clientRegion =
+
clientCache.createClientRegionFactory(ClientRegionShortcut.PROXY).create(REGION_NAME);
+assertNotNull(clientRegion);
+
+// let us populate this region from client.
+for (int i = 0; i < 10; i++) {
+  clientRegion.put(i, i * 10);
+}
+// Verify using gets
+for (int i = 0; i < 10; i++) {
+  assertEquals(i * 10, clientRegion.get(i));
+}
+assertEquals(10, clientRegion.size());
+assertFalse(clientRegion.isEmpty());
+// delete all the entries from the server
+server1.invoke(new SerializableCallable() {
+  @Override
+  public Object call() throws Exception {
+Cache c = CacheFactory.getAnyInstance();
--- End diff --

I recommend naming variables with full words like "cache" and "region" -- 
we're trying to get away from the use of single-characters or abbreviations.


---
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-1887) Client PROXY region should delegate all operations to server

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode/pull/390#discussion_r102340380
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/ClientServerMiscDUnitTest.java
 ---
@@ -773,6 +755,73 @@ public void 
clientIsPreventedFromConnectingToLocatorAsServer() throws Exception
   }
 
 
+  private void proxyRegionClientServerOp(RegionShortcut shortcut) throws 
Exception {
+// start server first
+final String REGION_NAME = "proxyRegionClientServerOp";
+PORT1 = initServerCache(false);
+// Create regions on servers.
+server1.invoke(new SerializableCallable() {
--- End diff --

SerializableRunnable supports "public void run() throws Exception" so 
there's no need to use SerializableCallable unless you need to return a type. 
You also don't really need to 1st assertNotNull since c.createRegionFactory 
will throw NPE:
```Java
 server1.invoke(() -> {
  Cache c = CacheFactory.getAnyInstance();
  Region r = 
c.createRegionFactory(shortcut).create(REGION_NAME);
  assertNotNull(r);
  });
```


> Client PROXY region should delegate all operations to server
> 
>
> Key: GEODE-1887
> URL: https://issues.apache.org/jira/browse/GEODE-1887
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Swapnil Bawaskar
>Assignee: Avinash Dongre
>
> Currently a ClientRegionShortcut.PROXY region sends operations like put() and 
> get() over to the server, but for operations like size() and isEmpty() it 
> just consults the local state on the client  and returns 0 and true 
> respectively, even though there may be data in the servers for that region.
> A PROXY region should not attempt to consult its local state for any 
> operation. 



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

[jira] [Commented] (GEODE-1887) Client PROXY region should delegate all operations to server

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode/pull/390#discussion_r102338250
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/ClientServerMiscDUnitTest.java
 ---
@@ -773,6 +755,73 @@ public void 
clientIsPreventedFromConnectingToLocatorAsServer() throws Exception
   }
 
 
+  private void proxyRegionClientServerOp(RegionShortcut shortcut) throws 
Exception {
+// start server first
+final String REGION_NAME = "proxyRegionClientServerOp";
+PORT1 = initServerCache(false);
+// Create regions on servers.
+server1.invoke(new SerializableCallable() {
+  @Override
+  public Object call() throws Exception {
+Cache c = CacheFactory.getAnyInstance();
+assertNotNull(c);
+Region r = 
c.createRegionFactory(shortcut).create(REGION_NAME);
+assertNotNull(r);
+return null;
+  }
+});
+
+String host = NetworkUtils.getServerHostName(server1.getHost());
+
+Properties props = new Properties();
+props.setProperty(MCAST_PORT, "0");
+props.setProperty(LOCATORS, "");
+ClientCacheFactory ccf = new ClientCacheFactory(props);
+ccf.addPoolServer(host, PORT1);
+
+ClientCache clientCache = ccf.create();
+Region clientRegion =
+
clientCache.createClientRegionFactory(ClientRegionShortcut.PROXY).create(REGION_NAME);
+assertNotNull(clientRegion);
+
+// let us populate this region from client.
+for (int i = 0; i < 10; i++) {
+  clientRegion.put(i, i * 10);
+}
+// Verify using gets
+for (int i = 0; i < 10; i++) {
+  assertEquals(i * 10, clientRegion.get(i));
+}
+assertEquals(10, clientRegion.size());
+assertFalse(clientRegion.isEmpty());
+// delete all the entries from the server
+server1.invoke(new SerializableCallable() {
+  @Override
+  public Object call() throws Exception {
+Cache c = CacheFactory.getAnyInstance();
+assertNotNull(c);
+Region r = c.getRegion(REGION_NAME);
+assertNotNull(r);
+for (int i = 0; i < 10; i++) {
+  r.remove(i);
+}
+return null;
+  }
+});
+assertEquals(0, clientRegion.size());
+assertTrue(clientRegion.isEmpty());
+
+clientRegion.destroyRegion();
+clientCache.close();
+  }
+
+  @Test
--- End diff --

Another option I really like is to use JUnitParams with DUnit:
```Java
@Category({DistributedTest.class, ClientServerTest.class})
@RunWith(JUnitParamsRunner.class)
public class ClientServerMiscDUnitTest extends JUnit4CacheTestCase {

  @Test
  @Parameters(method = "regionShortcut")
  public void testProxyRegionClientServerOp(RegionShortcut regionShortcut) 
throws Exception {
// test goes here
  }

  private RegionShortcut[] regionShortcut() {
return new RegionShortcut[] { RegionShortcut.PARTITION, 
RegionShortcut.REPLICATE };
  }
```


> Client PROXY region should delegate all operations to server
> 
>
> Key: GEODE-1887
> URL: https://issues.apache.org/jira/browse/GEODE-1887
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Swapnil Bawaskar
>Assignee: Avinash Dongre
>
> Currently a ClientRegionShortcut.PROXY region sends operations like put() and 
> get() over to the server, but for operations like size() and isEmpty() it 
> just consults the local state on the client  and returns 0 and true 
> respectively, even though there may be data in the servers for that region.
> A PROXY region should not attempt to consult its local state for any 
> operation. 



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

[jira] [Commented] (GEODE-1887) Client PROXY region should delegate all operations to server

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode/pull/390#discussion_r102338898
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/ClientServerMiscDUnitTest.java
 ---
@@ -773,6 +755,73 @@ public void 
clientIsPreventedFromConnectingToLocatorAsServer() throws Exception
   }
 
 
+  private void proxyRegionClientServerOp(RegionShortcut shortcut) throws 
Exception {
+// start server first
+final String REGION_NAME = "proxyRegionClientServerOp";
+PORT1 = initServerCache(false);
+// Create regions on servers.
+server1.invoke(new SerializableCallable() {
+  @Override
+  public Object call() throws Exception {
+Cache c = CacheFactory.getAnyInstance();
+assertNotNull(c);
+Region r = 
c.createRegionFactory(shortcut).create(REGION_NAME);
+assertNotNull(r);
+return null;
+  }
+});
+
+String host = NetworkUtils.getServerHostName(server1.getHost());
+
+Properties props = new Properties();
+props.setProperty(MCAST_PORT, "0");
+props.setProperty(LOCATORS, "");
+ClientCacheFactory ccf = new ClientCacheFactory(props);
+ccf.addPoolServer(host, PORT1);
+
+ClientCache clientCache = ccf.create();
+Region clientRegion =
+
clientCache.createClientRegionFactory(ClientRegionShortcut.PROXY).create(REGION_NAME);
+assertNotNull(clientRegion);
+
+// let us populate this region from client.
+for (int i = 0; i < 10; i++) {
+  clientRegion.put(i, i * 10);
+}
+// Verify using gets
+for (int i = 0; i < 10; i++) {
+  assertEquals(i * 10, clientRegion.get(i));
+}
+assertEquals(10, clientRegion.size());
+assertFalse(clientRegion.isEmpty());
+// delete all the entries from the server
+server1.invoke(new SerializableCallable() {
+  @Override
+  public Object call() throws Exception {
+Cache c = CacheFactory.getAnyInstance();
--- End diff --

I recommend naming variables with full words like "cache" and "region" -- 
we're trying to get away from the use of single-characters or abbreviations.


> Client PROXY region should delegate all operations to server
> 
>
> Key: GEODE-1887
> URL: https://issues.apache.org/jira/browse/GEODE-1887
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Swapnil Bawaskar
>Assignee: Avinash Dongre
>
> Currently a ClientRegionShortcut.PROXY region sends operations like put() and 
> get() over to the server, but for operations like size() and isEmpty() it 
> just consults the local state on the client  and returns 0 and true 
> respectively, even though there may be data in the servers for that region.
> A PROXY region should not attempt to consult its local state for any 
> operation. 



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

Re: Review Request 56899: GEODE-2514: add new tests for statistics archive rolling and removal

[Darrel Schneider]

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


Ship it!




Ship It!

- Darrel Schneider


On Feb. 21, 2017, 1:27 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56899/
> ---
> 
> (Updated Feb. 21, 2017, 1:27 p.m.)
> 
> 
> Review request for geode, Darrel Schneider, Jinmei Liao, Jared Stewart, Kevin 
> Duling, and Ken Howe.
> 
> 
> Bugs: GEODE-2514
> https://issues.apache.org/jira/browse/GEODE-2514
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2514: add new tests for statistics archive rolling and removal
> 
> * add MainWithChildrenRollingFileHandlerIntegrationTest
> * add StatArchiveHandlerIntegrationTest
> * expand DiskSpaceLimitIntegrationTest
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/io/MainWithChildrenRollingFileHandler.java
>  20d1c4ff92fbd54956334c923e1bacfea8825aa6 
>   
> geode-core/src/main/java/org/apache/geode/internal/statistics/StatArchiveHandler.java
>  3eb9730a31e5acaed5416c70425b7d8c46096187 
>   
> geode-core/src/test/java/org/apache/geode/internal/io/MainWithChildrenRollingFileHandlerIntegrationTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/internal/statistics/DiskSpaceLimitIntegrationTest.java
>  1702d9a46082de2bd219ca8716734f65fe046917 
>   
> geode-core/src/test/java/org/apache/geode/internal/statistics/StatArchiveHandlerIntegrationTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/56899/diff/
> 
> 
> Testing
> ---
> 
> precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

[jira] [Commented] (GEODE-2506) Update spring dependencies

[ASF GitHub Bot (JIRA)]

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

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

Github user metatype commented on the issue:

https://github.com/apache/geode/pull/403
  
In this case geode-pulse uses commons-beanutils v1.9.3 while geode-core is 
pulling in commons-beanutils v1.8.3 via shiro-core.  The version is different 
between `lib/*` and `geode-pulse-*.war`.

The override resolution strategy gives us another way to control transitive 
dependencies.  In some (rare) instances, we may want to ship a different 
version than specified in the pom file.  Let me know if you think this is 
getting overly complicated.




> Update spring dependencies
> --
>
> Key: GEODE-2506
> URL: https://issues.apache.org/jira/browse/GEODE-2506
> Project: Geode
>  Issue Type: Improvement
>  Components: build
>Reporter: Anthony Baker
>
> Update Spring dependencies from 4.3.2 to 4.3.6 to pick up latest maintenance 
> and security fixes.



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

[GitHub] geode issue #403: GEODE-2506 Update Spring from 4.3.2 to 4.3.6

[metatype]

Github user metatype commented on the issue:

https://github.com/apache/geode/pull/403
  
In this case geode-pulse uses commons-beanutils v1.9.3 while geode-core is 
pulling in commons-beanutils v1.8.3 via shiro-core.  The version is different 
between `lib/*` and `geode-pulse-*.war`.

The override resolution strategy gives us another way to control transitive 
dependencies.  In some (rare) instances, we may want to ship a different 
version than specified in the pom file.  Let me know if you think this is 
getting overly complicated.




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

[GitHub] geode pull request #402: GEODE-2497 surprise members are never timed out dur...

[bschuchardt]

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

https://github.com/apache/geode/pull/402#discussion_r102343450
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionManagerDUnitTest.java
 ---
@@ -159,77 +159,74 @@ public void testConnectAfterBeingShunned() {
**/
   @Test
   public void testSurpriseMemberHandling() {
-VM vm0 = Host.getHost(0).getVM(0);
-
-InternalDistributedSystem sys = getSystem();
-MembershipManager mgr = 
MembershipManagerHelper.getMembershipManager(sys);
 
+System.setProperty(DistributionConfig.GEMFIRE_PREFIX + 
"surprise-member-timeout", "3000");
 try {
-  InternalDistributedMember mbr =
-  new InternalDistributedMember(NetworkUtils.getIPLiteral(), 
12345);
+  InternalDistributedSystem sys = getSystem();
+  MembershipManager mgr = 
MembershipManagerHelper.getMembershipManager(sys);
+  assertTrue(((GMSMembershipManager) mgr).isCleanupTimerStarted());
 
-  // first make sure we can't add this as a surprise member (bug 
#44566)
-
-  // if the view number isn't being recorded correctly the test will 
pass but the
-  // functionality is broken
-  Assert.assertTrue("expected view ID to be greater than zero", 
mgr.getView().getViewId() > 0);
-
-  int oldViewId = mbr.getVmViewId();
-  mbr.setVmViewId((int) mgr.getView().getViewId() - 1);
-  org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
-  .info("current membership view is " + mgr.getView());
-  org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
-  .info("created ID " + mbr + " with view ID " + 
mbr.getVmViewId());
-  sys.getLogWriter()
-  .info("attempt to add old 
member");
-  sys.getLogWriter()
-  .info("Removing shunned GemFire 
node");
   try {
-boolean accepted = mgr.addSurpriseMember(mbr);
-Assert.assertTrue("member with old ID was not rejected (bug 
#44566)", !accepted);
-  } finally {
+InternalDistributedMember mbr =
+new InternalDistributedMember(NetworkUtils.getIPLiteral(), 
12345);
+
+// first make sure we can't add this as a surprise member (bug 
#44566)
+
+// if the view number isn't being recorded correctly the test will 
pass but the
+// functionality is broken
+Assert.assertTrue("expected view ID to be greater than zero",
+mgr.getView().getViewId() > 0);
+
+int oldViewId = mbr.getVmViewId();
+mbr.setVmViewId((int) mgr.getView().getViewId() - 1);
+org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
+.info("current membership view is " + mgr.getView());
+org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
+.info("created ID " + mbr + " with view ID " + 
mbr.getVmViewId());
 sys.getLogWriter()
-.info("attempt to add old 
member");
+.info("attempt to add old 
member");
--- End diff --

Thanks Kirk!  I'm implementing all of your suggested changes.  There are 
several other places in this class that are using try/finally to remove system 
properties that I'll fix as well.


---
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-2497) surprise members are never timed out during startup

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode/pull/402#discussion_r102343450
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionManagerDUnitTest.java
 ---
@@ -159,77 +159,74 @@ public void testConnectAfterBeingShunned() {
**/
   @Test
   public void testSurpriseMemberHandling() {
-VM vm0 = Host.getHost(0).getVM(0);
-
-InternalDistributedSystem sys = getSystem();
-MembershipManager mgr = 
MembershipManagerHelper.getMembershipManager(sys);
 
+System.setProperty(DistributionConfig.GEMFIRE_PREFIX + 
"surprise-member-timeout", "3000");
 try {
-  InternalDistributedMember mbr =
-  new InternalDistributedMember(NetworkUtils.getIPLiteral(), 
12345);
+  InternalDistributedSystem sys = getSystem();
+  MembershipManager mgr = 
MembershipManagerHelper.getMembershipManager(sys);
+  assertTrue(((GMSMembershipManager) mgr).isCleanupTimerStarted());
 
-  // first make sure we can't add this as a surprise member (bug 
#44566)
-
-  // if the view number isn't being recorded correctly the test will 
pass but the
-  // functionality is broken
-  Assert.assertTrue("expected view ID to be greater than zero", 
mgr.getView().getViewId() > 0);
-
-  int oldViewId = mbr.getVmViewId();
-  mbr.setVmViewId((int) mgr.getView().getViewId() - 1);
-  org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
-  .info("current membership view is " + mgr.getView());
-  org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
-  .info("created ID " + mbr + " with view ID " + 
mbr.getVmViewId());
-  sys.getLogWriter()
-  .info("attempt to add old 
member");
-  sys.getLogWriter()
-  .info("Removing shunned GemFire 
node");
   try {
-boolean accepted = mgr.addSurpriseMember(mbr);
-Assert.assertTrue("member with old ID was not rejected (bug 
#44566)", !accepted);
-  } finally {
+InternalDistributedMember mbr =
+new InternalDistributedMember(NetworkUtils.getIPLiteral(), 
12345);
+
+// first make sure we can't add this as a surprise member (bug 
#44566)
+
+// if the view number isn't being recorded correctly the test will 
pass but the
+// functionality is broken
+Assert.assertTrue("expected view ID to be greater than zero",
+mgr.getView().getViewId() > 0);
+
+int oldViewId = mbr.getVmViewId();
+mbr.setVmViewId((int) mgr.getView().getViewId() - 1);
+org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
+.info("current membership view is " + mgr.getView());
+org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
+.info("created ID " + mbr + " with view ID " + 
mbr.getVmViewId());
 sys.getLogWriter()
-.info("attempt to add old 
member");
+.info("attempt to add old 
member");
--- End diff --

Thanks Kirk!  I'm implementing all of your suggested changes.  There are 
several other places in this class that are using try/finally to remove system 
properties that I'll fix as well.


> surprise members are never timed out during startup
> ---
>
> Key: GEODE-2497
> URL: https://issues.apache.org/jira/browse/GEODE-2497
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>
> A system was observed to hang during startup when a "surprise member" was 
> added but then never timed out.  The system hung waiting for a response to a 
> startup message sent to the surprise member.



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

[GitHub] geode-native pull request #13: GEODE-2476: Replace gfcpp with geode.

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-2476) Replace gfcpp with geode

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> Replace gfcpp with geode
> 
>
> Key: GEODE-2476
> URL: https://issues.apache.org/jira/browse/GEODE-2476
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Michael Dodge
>Assignee: Michael Dodge
>
> The substring "gfcpp" still occurs in some places in the native client 
> codebase. It ought to be replaced with "geode" or "geode-native", whichever 
> makes more sense on a case-by-case basis.



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

[GitHub] geode issue #403: GEODE-2506 Update Spring from 4.3.2 to 4.3.6

[jaredjstewart]

Github user jaredjstewart commented on the issue:

https://github.com/apache/geode/pull/403
  
It seems like it might be simpler to add an explicit dependency for 
commons-beanutils to geode-core.  That way if we later introduce some new 
dependency which requires say commons-beanutils 1.10.1, there will be no need 
to troubleshoot since dependency resolution will still work as expected.


---
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-2506) Update spring dependencies

[ASF GitHub Bot (JIRA)]

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

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

Github user jaredjstewart commented on the issue:

https://github.com/apache/geode/pull/403
  
It seems like it might be simpler to add an explicit dependency for 
commons-beanutils to geode-core.  That way if we later introduce some new 
dependency which requires say commons-beanutils 1.10.1, there will be no need 
to troubleshoot since dependency resolution will still work as expected.


> Update spring dependencies
> --
>
> Key: GEODE-2506
> URL: https://issues.apache.org/jira/browse/GEODE-2506
> Project: Geode
>  Issue Type: Improvement
>  Components: build
>Reporter: Anthony Baker
>
> Update Spring dependencies from 4.3.2 to 4.3.6 to pick up latest maintenance 
> and security fixes.



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

[jira] [Commented] (GEODE-2497) surprise members are never timed out during startup

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2497:


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

Merge branch 'feature/GEODE-2497' of 
https://git-wip-us.apache.org/repos/asf/geode into feature/GEODE-2497


> surprise members are never timed out during startup
> ---
>
> Key: GEODE-2497
> URL: https://issues.apache.org/jira/browse/GEODE-2497
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>
> A system was observed to hang during startup when a "surprise member" was 
> added but then never timed out.  The system hung waiting for a response to a 
> startup message sent to the surprise member.



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

[jira] [Commented] (GEODE-2497) surprise members are never timed out during startup

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2497:


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

GEODE-2497 surprise members are never timed out during startup

Moved the creation of the timer to GMSMembershipManager.started()

Removed write-lock in timer-creation method since it's only called from
one place now

Altered the way that the timer-creation method finds the
InternalDistributedSystem.  The old way of using getAnyInstance() was
the primary source of the problem since it returns null until startup
is completed.

Altered the surprise-member unit test to ensure that it's using the
timer and not relying on installation of a new membership view to clean
things up.

Altered the surprise-member unit test to run faster.  It now completes in
under 10 seconds.


> surprise members are never timed out during startup
> ---
>
> Key: GEODE-2497
> URL: https://issues.apache.org/jira/browse/GEODE-2497
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>
> A system was observed to hang during startup when a "surprise member" was 
> added but then never timed out.  The system hung waiting for a response to a 
> startup message sent to the surprise member.



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

[jira] [Commented] (GEODE-2497) surprise members are never timed out during startup

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2497:


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

Merge branch 'feature/GEODE-2497' of 
https://git-wip-us.apache.org/repos/asf/geode into feature/GEODE-2497


> surprise members are never timed out during startup
> ---
>
> Key: GEODE-2497
> URL: https://issues.apache.org/jira/browse/GEODE-2497
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>
> A system was observed to hang during startup when a "surprise member" was 
> added but then never timed out.  The system hung waiting for a response to a 
> startup message sent to the surprise member.



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

[jira] [Assigned] (GEODE-2512) Geode Native docs: book fails to build

[Dave Barnes (JIRA)]

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

Dave Barnes reassigned GEODE-2512:
--

Assignee: Dave Barnes

> Geode Native docs: book fails to build
> --
>
> Key: GEODE-2512
> URL: https://issues.apache.org/jira/browse/GEODE-2512
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> The geode native book fails to build. Need to update and correct the config 
> files in ../geode-native/docs/geode-native-book, and (once book generation is 
> restored) the README.md file needs to be updated.



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

[GitHub] geode pull request #402: GEODE-2497 surprise members are never timed out dur...

[galen-pivotal]

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

https://github.com/apache/geode/pull/402#discussion_r102345903
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionManagerDUnitTest.java
 ---
@@ -159,77 +159,74 @@ public void testConnectAfterBeingShunned() {
**/
   @Test
   public void testSurpriseMemberHandling() {
-VM vm0 = Host.getHost(0).getVM(0);
-
-InternalDistributedSystem sys = getSystem();
-MembershipManager mgr = 
MembershipManagerHelper.getMembershipManager(sys);
 
+System.setProperty(DistributionConfig.GEMFIRE_PREFIX + 
"surprise-member-timeout", "3000");
 try {
-  InternalDistributedMember mbr =
-  new InternalDistributedMember(NetworkUtils.getIPLiteral(), 
12345);
+  InternalDistributedSystem sys = getSystem();
+  MembershipManager mgr = 
MembershipManagerHelper.getMembershipManager(sys);
+  assertTrue(((GMSMembershipManager) mgr).isCleanupTimerStarted());
 
-  // first make sure we can't add this as a surprise member (bug 
#44566)
-
-  // if the view number isn't being recorded correctly the test will 
pass but the
-  // functionality is broken
-  Assert.assertTrue("expected view ID to be greater than zero", 
mgr.getView().getViewId() > 0);
-
-  int oldViewId = mbr.getVmViewId();
-  mbr.setVmViewId((int) mgr.getView().getViewId() - 1);
-  org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
-  .info("current membership view is " + mgr.getView());
-  org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
-  .info("created ID " + mbr + " with view ID " + 
mbr.getVmViewId());
-  sys.getLogWriter()
-  .info("attempt to add old 
member");
-  sys.getLogWriter()
-  .info("Removing shunned GemFire 
node");
   try {
-boolean accepted = mgr.addSurpriseMember(mbr);
-Assert.assertTrue("member with old ID was not rejected (bug 
#44566)", !accepted);
-  } finally {
+InternalDistributedMember mbr =
+new InternalDistributedMember(NetworkUtils.getIPLiteral(), 
12345);
+
+// first make sure we can't add this as a surprise member (bug 
#44566)
+
+// if the view number isn't being recorded correctly the test will 
pass but the
+// functionality is broken
+Assert.assertTrue("expected view ID to be greater than zero",
+mgr.getView().getViewId() > 0);
+
+int oldViewId = mbr.getVmViewId();
+mbr.setVmViewId((int) mgr.getView().getViewId() - 1);
+org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
+.info("current membership view is " + mgr.getView());
+org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
+.info("created ID " + mbr + " with view ID " + 
mbr.getVmViewId());
 sys.getLogWriter()
-.info("attempt to add old 
member");
+.info("attempt to add old 
member");
 sys.getLogWriter().info(
-"Removing shunned GemFire 
node");
-  }
-  mbr.setVmViewId(oldViewId);
-
-  // now forcibly add it as a surprise member and show that it is 
reaped
-  long gracePeriod = 5000;
-  long startTime = System.currentTimeMillis();
-  long timeout = ((GMSMembershipManager) 
mgr).getSurpriseMemberTimeout();
-  long birthTime = startTime - timeout + gracePeriod;
-  MembershipManagerHelper.addSurpriseMember(sys, mbr, birthTime);
-  assertTrue("Member was not a surprise member", 
mgr.isSurpriseMember(mbr));
-
-  // force a real view change
-  SerializableRunnable connectDisconnect = new SerializableRunnable() {
-public void run() {
-  getSystem().disconnect();
+"Removing shunned GemFire 
node");
+try {
+  boolean accepted = mgr.addSurpriseMember(mbr);
+  Assert.assertTrue("member with old ID was not rejected (bug 
#44566)", !accepted);
+} finally {
+  sys.getLogWriter().info(
+  "attempt to add old 
member");
+  sys.getLogWriter().info(
+  "Removing shunned GemFire 
node");
 }
-  };
-  vm0.invoke(connectDisconnect);
-
-  if (birthTime < (System.currentTimeMillis() - timeout)) {
-return; // machine is too busy and we didn't get enough CPU to 
perform more assertions
-  }
-  assertTrue("Member was incorrectly removed from surprise member set",
-  mgr.isSurpriseMember(mbr));
+mbr.setVmViewId(oldViewId);
+
+// now forcibly add it as a surprise member and show that it is 
reaped
+  

[GitHub] geode pull request #402: GEODE-2497 surprise members are never timed out dur...

[galen-pivotal]

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

https://github.com/apache/geode/pull/402#discussion_r102345774
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionManagerDUnitTest.java
 ---
@@ -159,77 +159,74 @@ public void testConnectAfterBeingShunned() {
**/
   @Test
   public void testSurpriseMemberHandling() {
-VM vm0 = Host.getHost(0).getVM(0);
-
-InternalDistributedSystem sys = getSystem();
-MembershipManager mgr = 
MembershipManagerHelper.getMembershipManager(sys);
 
+System.setProperty(DistributionConfig.GEMFIRE_PREFIX + 
"surprise-member-timeout", "3000");
 try {
-  InternalDistributedMember mbr =
-  new InternalDistributedMember(NetworkUtils.getIPLiteral(), 
12345);
+  InternalDistributedSystem sys = getSystem();
+  MembershipManager mgr = 
MembershipManagerHelper.getMembershipManager(sys);
+  assertTrue(((GMSMembershipManager) mgr).isCleanupTimerStarted());
 
-  // first make sure we can't add this as a surprise member (bug 
#44566)
-
-  // if the view number isn't being recorded correctly the test will 
pass but the
-  // functionality is broken
-  Assert.assertTrue("expected view ID to be greater than zero", 
mgr.getView().getViewId() > 0);
-
-  int oldViewId = mbr.getVmViewId();
-  mbr.setVmViewId((int) mgr.getView().getViewId() - 1);
-  org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
-  .info("current membership view is " + mgr.getView());
-  org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
-  .info("created ID " + mbr + " with view ID " + 
mbr.getVmViewId());
-  sys.getLogWriter()
-  .info("attempt to add old 
member");
-  sys.getLogWriter()
-  .info("Removing shunned GemFire 
node");
   try {
-boolean accepted = mgr.addSurpriseMember(mbr);
-Assert.assertTrue("member with old ID was not rejected (bug 
#44566)", !accepted);
-  } finally {
+InternalDistributedMember mbr =
+new InternalDistributedMember(NetworkUtils.getIPLiteral(), 
12345);
+
+// first make sure we can't add this as a surprise member (bug 
#44566)
+
+// if the view number isn't being recorded correctly the test will 
pass but the
+// functionality is broken
+Assert.assertTrue("expected view ID to be greater than zero",
+mgr.getView().getViewId() > 0);
+
+int oldViewId = mbr.getVmViewId();
+mbr.setVmViewId((int) mgr.getView().getViewId() - 1);
+org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
+.info("current membership view is " + mgr.getView());
+org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
+.info("created ID " + mbr + " with view ID " + 
mbr.getVmViewId());
 sys.getLogWriter()
-.info("attempt to add old 
member");
+.info("attempt to add old 
member");
 sys.getLogWriter().info(
-"Removing shunned GemFire 
node");
-  }
-  mbr.setVmViewId(oldViewId);
-
-  // now forcibly add it as a surprise member and show that it is 
reaped
-  long gracePeriod = 5000;
-  long startTime = System.currentTimeMillis();
-  long timeout = ((GMSMembershipManager) 
mgr).getSurpriseMemberTimeout();
-  long birthTime = startTime - timeout + gracePeriod;
-  MembershipManagerHelper.addSurpriseMember(sys, mbr, birthTime);
-  assertTrue("Member was not a surprise member", 
mgr.isSurpriseMember(mbr));
-
-  // force a real view change
-  SerializableRunnable connectDisconnect = new SerializableRunnable() {
-public void run() {
-  getSystem().disconnect();
+"Removing shunned GemFire 
node");
+try {
+  boolean accepted = mgr.addSurpriseMember(mbr);
+  Assert.assertTrue("member with old ID was not rejected (bug 
#44566)", !accepted);
+} finally {
+  sys.getLogWriter().info(
+  "attempt to add old 
member");
+  sys.getLogWriter().info(
+  "Removing shunned GemFire 
node");
 }
-  };
-  vm0.invoke(connectDisconnect);
-
-  if (birthTime < (System.currentTimeMillis() - timeout)) {
-return; // machine is too busy and we didn't get enough CPU to 
perform more assertions
-  }
-  assertTrue("Member was incorrectly removed from surprise member set",
-  mgr.isSurpriseMember(mbr));
+mbr.setVmViewId(oldViewId);
+
+// now forcibly add it as a surprise member and show that it is 
reaped
+  

[GitHub] geode pull request #402: GEODE-2497 surprise members are never timed out dur...

[galen-pivotal]

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

https://github.com/apache/geode/pull/402#discussion_r102345794
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionManagerDUnitTest.java
 ---
@@ -159,77 +159,74 @@ public void testConnectAfterBeingShunned() {
**/
   @Test
   public void testSurpriseMemberHandling() {
-VM vm0 = Host.getHost(0).getVM(0);
-
-InternalDistributedSystem sys = getSystem();
-MembershipManager mgr = 
MembershipManagerHelper.getMembershipManager(sys);
 
+System.setProperty(DistributionConfig.GEMFIRE_PREFIX + 
"surprise-member-timeout", "3000");
 try {
-  InternalDistributedMember mbr =
-  new InternalDistributedMember(NetworkUtils.getIPLiteral(), 
12345);
+  InternalDistributedSystem sys = getSystem();
+  MembershipManager mgr = 
MembershipManagerHelper.getMembershipManager(sys);
+  assertTrue(((GMSMembershipManager) mgr).isCleanupTimerStarted());
 
-  // first make sure we can't add this as a surprise member (bug 
#44566)
-
-  // if the view number isn't being recorded correctly the test will 
pass but the
-  // functionality is broken
-  Assert.assertTrue("expected view ID to be greater than zero", 
mgr.getView().getViewId() > 0);
-
-  int oldViewId = mbr.getVmViewId();
-  mbr.setVmViewId((int) mgr.getView().getViewId() - 1);
-  org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
-  .info("current membership view is " + mgr.getView());
-  org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
-  .info("created ID " + mbr + " with view ID " + 
mbr.getVmViewId());
-  sys.getLogWriter()
-  .info("attempt to add old 
member");
-  sys.getLogWriter()
-  .info("Removing shunned GemFire 
node");
   try {
-boolean accepted = mgr.addSurpriseMember(mbr);
-Assert.assertTrue("member with old ID was not rejected (bug 
#44566)", !accepted);
-  } finally {
+InternalDistributedMember mbr =
+new InternalDistributedMember(NetworkUtils.getIPLiteral(), 
12345);
+
+// first make sure we can't add this as a surprise member (bug 
#44566)
+
+// if the view number isn't being recorded correctly the test will 
pass but the
+// functionality is broken
+Assert.assertTrue("expected view ID to be greater than zero",
+mgr.getView().getViewId() > 0);
+
+int oldViewId = mbr.getVmViewId();
+mbr.setVmViewId((int) mgr.getView().getViewId() - 1);
+org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
+.info("current membership view is " + mgr.getView());
+org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
+.info("created ID " + mbr + " with view ID " + 
mbr.getVmViewId());
 sys.getLogWriter()
-.info("attempt to add old 
member");
+.info("attempt to add old 
member");
 sys.getLogWriter().info(
-"Removing shunned GemFire 
node");
-  }
-  mbr.setVmViewId(oldViewId);
-
-  // now forcibly add it as a surprise member and show that it is 
reaped
-  long gracePeriod = 5000;
-  long startTime = System.currentTimeMillis();
-  long timeout = ((GMSMembershipManager) 
mgr).getSurpriseMemberTimeout();
-  long birthTime = startTime - timeout + gracePeriod;
-  MembershipManagerHelper.addSurpriseMember(sys, mbr, birthTime);
-  assertTrue("Member was not a surprise member", 
mgr.isSurpriseMember(mbr));
-
-  // force a real view change
-  SerializableRunnable connectDisconnect = new SerializableRunnable() {
-public void run() {
-  getSystem().disconnect();
+"Removing shunned GemFire 
node");
+try {
+  boolean accepted = mgr.addSurpriseMember(mbr);
+  Assert.assertTrue("member with old ID was not rejected (bug 
#44566)", !accepted);
+} finally {
+  sys.getLogWriter().info(
+  "attempt to add old 
member");
+  sys.getLogWriter().info(
+  "Removing shunned GemFire 
node");
 }
-  };
-  vm0.invoke(connectDisconnect);
-
-  if (birthTime < (System.currentTimeMillis() - timeout)) {
-return; // machine is too busy and we didn't get enough CPU to 
perform more assertions
-  }
-  assertTrue("Member was incorrectly removed from surprise member set",
-  mgr.isSurpriseMember(mbr));
+mbr.setVmViewId(oldViewId);
+
+// now forcibly add it as a surprise member and show that it is 
reaped
+  

[jira] [Commented] (GEODE-2497) surprise members are never timed out during startup

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode/pull/402#discussion_r102345903
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionManagerDUnitTest.java
 ---
@@ -159,77 +159,74 @@ public void testConnectAfterBeingShunned() {
**/
   @Test
   public void testSurpriseMemberHandling() {
-VM vm0 = Host.getHost(0).getVM(0);
-
-InternalDistributedSystem sys = getSystem();
-MembershipManager mgr = 
MembershipManagerHelper.getMembershipManager(sys);
 
+System.setProperty(DistributionConfig.GEMFIRE_PREFIX + 
"surprise-member-timeout", "3000");
 try {
-  InternalDistributedMember mbr =
-  new InternalDistributedMember(NetworkUtils.getIPLiteral(), 
12345);
+  InternalDistributedSystem sys = getSystem();
+  MembershipManager mgr = 
MembershipManagerHelper.getMembershipManager(sys);
+  assertTrue(((GMSMembershipManager) mgr).isCleanupTimerStarted());
 
-  // first make sure we can't add this as a surprise member (bug 
#44566)
-
-  // if the view number isn't being recorded correctly the test will 
pass but the
-  // functionality is broken
-  Assert.assertTrue("expected view ID to be greater than zero", 
mgr.getView().getViewId() > 0);
-
-  int oldViewId = mbr.getVmViewId();
-  mbr.setVmViewId((int) mgr.getView().getViewId() - 1);
-  org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
-  .info("current membership view is " + mgr.getView());
-  org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
-  .info("created ID " + mbr + " with view ID " + 
mbr.getVmViewId());
-  sys.getLogWriter()
-  .info("attempt to add old 
member");
-  sys.getLogWriter()
-  .info("Removing shunned GemFire 
node");
   try {
-boolean accepted = mgr.addSurpriseMember(mbr);
-Assert.assertTrue("member with old ID was not rejected (bug 
#44566)", !accepted);
-  } finally {
+InternalDistributedMember mbr =
+new InternalDistributedMember(NetworkUtils.getIPLiteral(), 
12345);
+
+// first make sure we can't add this as a surprise member (bug 
#44566)
+
+// if the view number isn't being recorded correctly the test will 
pass but the
+// functionality is broken
+Assert.assertTrue("expected view ID to be greater than zero",
+mgr.getView().getViewId() > 0);
+
+int oldViewId = mbr.getVmViewId();
+mbr.setVmViewId((int) mgr.getView().getViewId() - 1);
+org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
+.info("current membership view is " + mgr.getView());
+org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
+.info("created ID " + mbr + " with view ID " + 
mbr.getVmViewId());
 sys.getLogWriter()
-.info("attempt to add old 
member");
+.info("attempt to add old 
member");
 sys.getLogWriter().info(
-"Removing shunned GemFire 
node");
-  }
-  mbr.setVmViewId(oldViewId);
-
-  // now forcibly add it as a surprise member and show that it is 
reaped
-  long gracePeriod = 5000;
-  long startTime = System.currentTimeMillis();
-  long timeout = ((GMSMembershipManager) 
mgr).getSurpriseMemberTimeout();
-  long birthTime = startTime - timeout + gracePeriod;
-  MembershipManagerHelper.addSurpriseMember(sys, mbr, birthTime);
-  assertTrue("Member was not a surprise member", 
mgr.isSurpriseMember(mbr));
-
-  // force a real view change
-  SerializableRunnable connectDisconnect = new SerializableRunnable() {
-public void run() {
-  getSystem().disconnect();
+"Removing shunned GemFire 
node");
+try {
+  boolean accepted = mgr.addSurpriseMember(mbr);
+  Assert.assertTrue("member with old ID was not rejected (bug 
#44566)", !accepted);
+} finally {
+  sys.getLogWriter().info(
+  "attempt to add old 
member");
+  sys.getLogWriter().info(
+  "Removing shunned GemFire 
node");
 }
-  };
-  vm0.invoke(connectDisconnect);
-
-  if (birthTime < (System.currentTimeMillis() - timeout)) {
-return; // machine is too busy and we didn't get enough CPU to 
perform more assertions
-  }
-  

[jira] [Commented] (GEODE-2497) surprise members are never timed out during startup

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode/pull/402#discussion_r102345774
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionManagerDUnitTest.java
 ---
@@ -159,77 +159,74 @@ public void testConnectAfterBeingShunned() {
**/
   @Test
   public void testSurpriseMemberHandling() {
-VM vm0 = Host.getHost(0).getVM(0);
-
-InternalDistributedSystem sys = getSystem();
-MembershipManager mgr = 
MembershipManagerHelper.getMembershipManager(sys);
 
+System.setProperty(DistributionConfig.GEMFIRE_PREFIX + 
"surprise-member-timeout", "3000");
 try {
-  InternalDistributedMember mbr =
-  new InternalDistributedMember(NetworkUtils.getIPLiteral(), 
12345);
+  InternalDistributedSystem sys = getSystem();
+  MembershipManager mgr = 
MembershipManagerHelper.getMembershipManager(sys);
+  assertTrue(((GMSMembershipManager) mgr).isCleanupTimerStarted());
 
-  // first make sure we can't add this as a surprise member (bug 
#44566)
-
-  // if the view number isn't being recorded correctly the test will 
pass but the
-  // functionality is broken
-  Assert.assertTrue("expected view ID to be greater than zero", 
mgr.getView().getViewId() > 0);
-
-  int oldViewId = mbr.getVmViewId();
-  mbr.setVmViewId((int) mgr.getView().getViewId() - 1);
-  org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
-  .info("current membership view is " + mgr.getView());
-  org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
-  .info("created ID " + mbr + " with view ID " + 
mbr.getVmViewId());
-  sys.getLogWriter()
-  .info("attempt to add old 
member");
-  sys.getLogWriter()
-  .info("Removing shunned GemFire 
node");
   try {
-boolean accepted = mgr.addSurpriseMember(mbr);
-Assert.assertTrue("member with old ID was not rejected (bug 
#44566)", !accepted);
-  } finally {
+InternalDistributedMember mbr =
+new InternalDistributedMember(NetworkUtils.getIPLiteral(), 
12345);
+
+// first make sure we can't add this as a surprise member (bug 
#44566)
+
+// if the view number isn't being recorded correctly the test will 
pass but the
+// functionality is broken
+Assert.assertTrue("expected view ID to be greater than zero",
+mgr.getView().getViewId() > 0);
+
+int oldViewId = mbr.getVmViewId();
+mbr.setVmViewId((int) mgr.getView().getViewId() - 1);
+org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
+.info("current membership view is " + mgr.getView());
+org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
+.info("created ID " + mbr + " with view ID " + 
mbr.getVmViewId());
 sys.getLogWriter()
-.info("attempt to add old 
member");
+.info("attempt to add old 
member");
 sys.getLogWriter().info(
-"Removing shunned GemFire 
node");
-  }
-  mbr.setVmViewId(oldViewId);
-
-  // now forcibly add it as a surprise member and show that it is 
reaped
-  long gracePeriod = 5000;
-  long startTime = System.currentTimeMillis();
-  long timeout = ((GMSMembershipManager) 
mgr).getSurpriseMemberTimeout();
-  long birthTime = startTime - timeout + gracePeriod;
-  MembershipManagerHelper.addSurpriseMember(sys, mbr, birthTime);
-  assertTrue("Member was not a surprise member", 
mgr.isSurpriseMember(mbr));
-
-  // force a real view change
-  SerializableRunnable connectDisconnect = new SerializableRunnable() {
-public void run() {
-  getSystem().disconnect();
+"Removing shunned GemFire 
node");
+try {
+  boolean accepted = mgr.addSurpriseMember(mbr);
+  Assert.assertTrue("member with old ID was not rejected (bug 
#44566)", !accepted);
+} finally {
+  sys.getLogWriter().info(
+  "attempt to add old 
member");
+  sys.getLogWriter().info(
+  "Removing shunned GemFire 
node");
 }
-  };
-  vm0.invoke(connectDisconnect);
-
-  if (birthTime < (System.currentTimeMillis() - timeout)) {
-return; // machine is too busy and we didn't get enough CPU to 
perform more assertions
-  }
-  

[jira] [Commented] (GEODE-2497) surprise members are never timed out during startup

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode/pull/402#discussion_r102345794
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionManagerDUnitTest.java
 ---
@@ -159,77 +159,74 @@ public void testConnectAfterBeingShunned() {
**/
   @Test
   public void testSurpriseMemberHandling() {
-VM vm0 = Host.getHost(0).getVM(0);
-
-InternalDistributedSystem sys = getSystem();
-MembershipManager mgr = 
MembershipManagerHelper.getMembershipManager(sys);
 
+System.setProperty(DistributionConfig.GEMFIRE_PREFIX + 
"surprise-member-timeout", "3000");
 try {
-  InternalDistributedMember mbr =
-  new InternalDistributedMember(NetworkUtils.getIPLiteral(), 
12345);
+  InternalDistributedSystem sys = getSystem();
+  MembershipManager mgr = 
MembershipManagerHelper.getMembershipManager(sys);
+  assertTrue(((GMSMembershipManager) mgr).isCleanupTimerStarted());
 
-  // first make sure we can't add this as a surprise member (bug 
#44566)
-
-  // if the view number isn't being recorded correctly the test will 
pass but the
-  // functionality is broken
-  Assert.assertTrue("expected view ID to be greater than zero", 
mgr.getView().getViewId() > 0);
-
-  int oldViewId = mbr.getVmViewId();
-  mbr.setVmViewId((int) mgr.getView().getViewId() - 1);
-  org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
-  .info("current membership view is " + mgr.getView());
-  org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
-  .info("created ID " + mbr + " with view ID " + 
mbr.getVmViewId());
-  sys.getLogWriter()
-  .info("attempt to add old 
member");
-  sys.getLogWriter()
-  .info("Removing shunned GemFire 
node");
   try {
-boolean accepted = mgr.addSurpriseMember(mbr);
-Assert.assertTrue("member with old ID was not rejected (bug 
#44566)", !accepted);
-  } finally {
+InternalDistributedMember mbr =
+new InternalDistributedMember(NetworkUtils.getIPLiteral(), 
12345);
+
+// first make sure we can't add this as a surprise member (bug 
#44566)
+
+// if the view number isn't being recorded correctly the test will 
pass but the
+// functionality is broken
+Assert.assertTrue("expected view ID to be greater than zero",
+mgr.getView().getViewId() > 0);
+
+int oldViewId = mbr.getVmViewId();
+mbr.setVmViewId((int) mgr.getView().getViewId() - 1);
+org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
+.info("current membership view is " + mgr.getView());
+org.apache.geode.test.dunit.LogWriterUtils.getLogWriter()
+.info("created ID " + mbr + " with view ID " + 
mbr.getVmViewId());
 sys.getLogWriter()
-.info("attempt to add old 
member");
+.info("attempt to add old 
member");
 sys.getLogWriter().info(
-"Removing shunned GemFire 
node");
-  }
-  mbr.setVmViewId(oldViewId);
-
-  // now forcibly add it as a surprise member and show that it is 
reaped
-  long gracePeriod = 5000;
-  long startTime = System.currentTimeMillis();
-  long timeout = ((GMSMembershipManager) 
mgr).getSurpriseMemberTimeout();
-  long birthTime = startTime - timeout + gracePeriod;
-  MembershipManagerHelper.addSurpriseMember(sys, mbr, birthTime);
-  assertTrue("Member was not a surprise member", 
mgr.isSurpriseMember(mbr));
-
-  // force a real view change
-  SerializableRunnable connectDisconnect = new SerializableRunnable() {
-public void run() {
-  getSystem().disconnect();
+"Removing shunned GemFire 
node");
+try {
+  boolean accepted = mgr.addSurpriseMember(mbr);
+  Assert.assertTrue("member with old ID was not rejected (bug 
#44566)", !accepted);
+} finally {
+  sys.getLogWriter().info(
+  "attempt to add old 
member");
+  sys.getLogWriter().info(
+  "Removing shunned GemFire 
node");
 }
-  };
-  vm0.invoke(connectDisconnect);
-
-  if (birthTime < (System.currentTimeMillis() - timeout)) {
-return; // machine is too busy and we didn't get enough CPU to 
perform more assertions
-  }
-  

[GitHub] geode-native pull request #20: GEODE-2512 Geode Native docs: book fails to b...

[davebarnes97]

GitHub user davebarnes97 opened a pull request:

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

GEODE-2512 Geode Native docs: book fails to build



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

$ git pull https://github.com/davebarnes97/geode-native feature/GEODE-2512

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

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


commit 12e0230a9142136390fcf2694ced990fe6b8726b
Author: Dave Barnes 
Date:   2017-02-21T23:32:00Z

GEODE-2512 Geode Native docs: book fails to build




---
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] [Created] (GEODE-2517) Data transfer of size > 2GB from server to client results in a hang and eventual timeout exception

[nabarun (JIRA)]

nabarun created GEODE-2517:
--

 Summary: Data transfer of size > 2GB from server to client results 
in a hang and eventual timeout exception
 Key: GEODE-2517
 URL: https://issues.apache.org/jira/browse/GEODE-2517
 Project: Geode
  Issue Type: Bug
  Components: client/server
Reporter: nabarun


Situation:
1. Create a server and client.
2. Fill the server with a large amount of data. 
3. Create a query that will result in over 600,000 entries as result.
4. Chunk the result set in such a way that one chunk will result in a size 
greater than 2GB
5. Execute the query from the client.

Expected:
Message too large exception.

Cause / Fix of the issue:
If the number of parts to be transmitted is one then in sendBytes()

{code:title=Message.java}
for (int i = 0; i < this.numberOfParts; i++) {
  Part part = this.partsList[i];
  headerLen += PART_HEADER_SIZE;
  totalPartLen += part.getLength();
}
{code}

* Here the part.getLength() is an int, so if the size if greater than 2GB we 
have already overflowed the int barrier and we are putting a negative value in 
totalPartLen

so when we do the below check :
{code:title=Message.java}
if ((headerLen + totalPartLen) > Integer.MAX_VALUE) {
  throw new MessageTooLargeException(
  "Message size (" + (headerLen + totalPartLen) + ") exceeds 
maximum integer value");
}
{code}

The comparison is between a negative number and positive number 
[Integer.MAX_VALUE] hence it will always skip this loop.

and ultimately result in this exception.

{noformat}
java.io.IOException: Part length ( -508,098,123 ) and number of parts ( 1 ) 
inconsistent
at 
com.gemstone.gemfire.internal.cache.tier.sockets.Message.readPayloadFields(Message.java:836)
at 
com.gemstone.gemfire.internal.cache.tier.sockets.ChunkedMessage.readChunk(ChunkedMessage.java:276)
at 
com.gemstone.gemfire.internal.cache.tier.sockets.ChunkedMessage.receiveChunk(ChunkedMessage.java:220)
at 
com.gemstone.gemfire.cache.client.internal.ExecuteRegionFunctionOp$ExecuteRegionFunctionOpImpl.processResponse(ExecuteRegionFunctionOp.java:482)
at 
com.gemstone.gemfire.cache.client.internal.AbstractOp.processResponse(AbstractOp.java:215)
at 
com.gemstone.gemfire.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:153)
at 
com.gemstone.gemfire.cache.client.internal.AbstractOp.attempt(AbstractOp.java:369)
at 
com.gemstone.gemfire.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:252)
at 
com.gemstone.gemfire.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:319)
at 
com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:933)
at 
com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:158)
at 
com.gemstone.gemfire.cache.client.internal.PoolImpl.execute(PoolImpl.java:716)
at 
com.gemstone.gemfire.cache.client.internal.ExecuteRegionFunctionOp.execute(ExecuteRegionFunctionOp.java:159)
at 
com.gemstone.gemfire.cache.client.internal.ServerRegionProxy.executeFunction(ServerRegionProxy.java:801)
at 
com.gemstone.gemfire.internal.cache.execute.ServerRegionFunctionExecutor.executeOnServer(ServerRegionFunctionExecutor.java:212)
at 
com.gemstone.gemfire.internal.cache.execute.ServerRegionFunctionExecutor.executeFunction(ServerRegionFunctionExecutor.java:165)
at 
com.gemstone.gemfire.internal.cache.execute.ServerRegionFunctionExecutor.execute(ServerRegionFunctionExecutor.java:363)
at com.bookshop.buslogic.TestClient.run(TestClient.java:40)
at com.bookshop.buslogic.TestClient.main(TestClient.java:21)
{noformat}



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

[jira] [Commented] (GEODE-2512) Geode Native docs: book fails to build

[ASF GitHub Bot (JIRA)]

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

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

GitHub user davebarnes97 opened a pull request:

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

GEODE-2512 Geode Native docs: book fails to build



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

$ git pull https://github.com/davebarnes97/geode-native feature/GEODE-2512

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

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


commit 12e0230a9142136390fcf2694ced990fe6b8726b
Author: Dave Barnes 
Date:   2017-02-21T23:32:00Z

GEODE-2512 Geode Native docs: book fails to build




> Geode Native docs: book fails to build
> --
>
> Key: GEODE-2512
> URL: https://issues.apache.org/jira/browse/GEODE-2512
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> The geode native book fails to build. Need to update and correct the config 
> files in ../geode-native/docs/geode-native-book, and (once book generation is 
> restored) the README.md file needs to be updated.



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

[jira] [Updated] (GEODE-2517) Data transfer of size > 2GB from server to client results in a hang and eventual timeout exception

[nabarun (JIRA)]

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

nabarun updated GEODE-2517:
---
Description: 
*Situation*:
1. Create a server and client.
2. Fill the server with a large amount of data. 
3. Create a query that will result in over 600,000 entries as result.
4. Chunk the result set in such a way that one chunk will result in a size 
greater than 2GB
5. Execute the query from the client.

*Expected*:
Message too large exception.

*Cause / Fix of the issue*:
If the number of parts to be transmitted is one then in sendBytes()

{code:title=Message.java}
for (int i = 0; i < this.numberOfParts; i++) {
  Part part = this.partsList[i];
  headerLen += PART_HEADER_SIZE;
  totalPartLen += part.getLength();
}
{code}

* Here the part.getLength() is an int, so if the size if greater than 2GB we 
have already overflowed the int barrier and we are putting a negative value in 
totalPartLen

so when we do the below check :
{code:title=Message.java}
if ((headerLen + totalPartLen) > Integer.MAX_VALUE) {
  throw new MessageTooLargeException(
  "Message size (" + (headerLen + totalPartLen) + ") exceeds 
maximum integer value");
}
{code}

The comparison is between a negative number and positive number 
[Integer.MAX_VALUE] hence it will always skip this loop.

and ultimately result in this exception.

{noformat}
java.io.IOException: Part length ( -508,098,123 ) and number of parts ( 1 ) 
inconsistent
at 
com.gemstone.gemfire.internal.cache.tier.sockets.Message.readPayloadFields(Message.java:836)
at 
com.gemstone.gemfire.internal.cache.tier.sockets.ChunkedMessage.readChunk(ChunkedMessage.java:276)
at 
com.gemstone.gemfire.internal.cache.tier.sockets.ChunkedMessage.receiveChunk(ChunkedMessage.java:220)
at 
com.gemstone.gemfire.cache.client.internal.ExecuteRegionFunctionOp$ExecuteRegionFunctionOpImpl.processResponse(ExecuteRegionFunctionOp.java:482)
at 
com.gemstone.gemfire.cache.client.internal.AbstractOp.processResponse(AbstractOp.java:215)
at 
com.gemstone.gemfire.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:153)
at 
com.gemstone.gemfire.cache.client.internal.AbstractOp.attempt(AbstractOp.java:369)
at 
com.gemstone.gemfire.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:252)
at 
com.gemstone.gemfire.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:319)
at 
com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:933)
at 
com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:158)
at 
com.gemstone.gemfire.cache.client.internal.PoolImpl.execute(PoolImpl.java:716)
at 
com.gemstone.gemfire.cache.client.internal.ExecuteRegionFunctionOp.execute(ExecuteRegionFunctionOp.java:159)
at 
com.gemstone.gemfire.cache.client.internal.ServerRegionProxy.executeFunction(ServerRegionProxy.java:801)
at 
com.gemstone.gemfire.internal.cache.execute.ServerRegionFunctionExecutor.executeOnServer(ServerRegionFunctionExecutor.java:212)
at 
com.gemstone.gemfire.internal.cache.execute.ServerRegionFunctionExecutor.executeFunction(ServerRegionFunctionExecutor.java:165)
at 
com.gemstone.gemfire.internal.cache.execute.ServerRegionFunctionExecutor.execute(ServerRegionFunctionExecutor.java:363)
at com.bookshop.buslogic.TestClient.run(TestClient.java:40)
at com.bookshop.buslogic.TestClient.main(TestClient.java:21)
{noformat}

  was:
Situation:
1. Create a server and client.
2. Fill the server with a large amount of data. 
3. Create a query that will result in over 600,000 entries as result.
4. Chunk the result set in such a way that one chunk will result in a size 
greater than 2GB
5. Execute the query from the client.

Expected:
Message too large exception.

Cause / Fix of the issue:
If the number of parts to be transmitted is one then in sendBytes()

{code:title=Message.java}
for (int i = 0; i < this.numberOfParts; i++) {
  Part part = this.partsList[i];
  headerLen += PART_HEADER_SIZE;
  totalPartLen += part.getLength();
}
{code}

* Here the part.getLength() is an int, so if the size if greater than 2GB we 
have already overflowed the int barrier and we are putting a negative value in 
totalPartLen

so when we do the below check :
{code:title=Message.java}
if ((headerLen + totalPartLen) > Integer.MAX_VALUE) {
  throw new MessageTooLargeException(
  "Message size (" + (headerLen + totalPartLen) + ") exceeds 
maximum integer value");
}
{code}

The comparison is between a negative number and positive number 
[Integer.MAX_VALUE] hence it will always skip this loop.

and ultimately result in this exception.

{noformat}
java.io.IOException: Par

[jira] [Updated] (GEODE-2517) Data transfer of size > 2GB from server to client results in a hang and eventual timeout exception

[nabarun (JIRA)]

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

nabarun updated GEODE-2517:
---
Description: 
*Situation*:
1. Create a server and client.
2. Fill the server with a large amount of data. 
3. Create a query that will result in over 600,000 entries as result.
4. Chunk the result set in such a way that one chunk will result in a size 
greater than 2GB
5. Execute the query from the client.

*Expected*:
Message too large exception.

*Cause / Fix for the issue*:
If the number of parts to be transmitted is one then in sendBytes()

{code:title=Message.java}
for (int i = 0; i < this.numberOfParts; i++) {
  Part part = this.partsList[i];
  headerLen += PART_HEADER_SIZE;
  totalPartLen += part.getLength();
}
{code}

* Here the part.getLength() is an int, so if the size if greater than 2GB we 
have already overflowed the int barrier and we are putting a negative value in 
totalPartLen

so when we do the below check :
{code:title=Message.java}
if ((headerLen + totalPartLen) > Integer.MAX_VALUE) {
  throw new MessageTooLargeException(
  "Message size (" + (headerLen + totalPartLen) + ") exceeds 
maximum integer value");
}
{code}

The comparison is between a negative number and positive number 
[Integer.MAX_VALUE] hence it will always skip this loop.

and ultimately result in this exception.

{noformat}
java.io.IOException: Part length ( -508,098,123 ) and number of parts ( 1 ) 
inconsistent
at 
com.gemstone.gemfire.internal.cache.tier.sockets.Message.readPayloadFields(Message.java:836)
at 
com.gemstone.gemfire.internal.cache.tier.sockets.ChunkedMessage.readChunk(ChunkedMessage.java:276)
at 
com.gemstone.gemfire.internal.cache.tier.sockets.ChunkedMessage.receiveChunk(ChunkedMessage.java:220)
at 
com.gemstone.gemfire.cache.client.internal.ExecuteRegionFunctionOp$ExecuteRegionFunctionOpImpl.processResponse(ExecuteRegionFunctionOp.java:482)
at 
com.gemstone.gemfire.cache.client.internal.AbstractOp.processResponse(AbstractOp.java:215)
at 
com.gemstone.gemfire.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:153)
at 
com.gemstone.gemfire.cache.client.internal.AbstractOp.attempt(AbstractOp.java:369)
at 
com.gemstone.gemfire.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:252)
at 
com.gemstone.gemfire.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:319)
at 
com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:933)
at 
com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:158)
at 
com.gemstone.gemfire.cache.client.internal.PoolImpl.execute(PoolImpl.java:716)
at 
com.gemstone.gemfire.cache.client.internal.ExecuteRegionFunctionOp.execute(ExecuteRegionFunctionOp.java:159)
at 
com.gemstone.gemfire.cache.client.internal.ServerRegionProxy.executeFunction(ServerRegionProxy.java:801)
at 
com.gemstone.gemfire.internal.cache.execute.ServerRegionFunctionExecutor.executeOnServer(ServerRegionFunctionExecutor.java:212)
at 
com.gemstone.gemfire.internal.cache.execute.ServerRegionFunctionExecutor.executeFunction(ServerRegionFunctionExecutor.java:165)
at 
com.gemstone.gemfire.internal.cache.execute.ServerRegionFunctionExecutor.execute(ServerRegionFunctionExecutor.java:363)
at com.bookshop.buslogic.TestClient.run(TestClient.java:40)
at com.bookshop.buslogic.TestClient.main(TestClient.java:21)
{noformat}

  was:
*Situation*:
1. Create a server and client.
2. Fill the server with a large amount of data. 
3. Create a query that will result in over 600,000 entries as result.
4. Chunk the result set in such a way that one chunk will result in a size 
greater than 2GB
5. Execute the query from the client.

*Expected*:
Message too large exception.

*Cause / Fix of the issue*:
If the number of parts to be transmitted is one then in sendBytes()

{code:title=Message.java}
for (int i = 0; i < this.numberOfParts; i++) {
  Part part = this.partsList[i];
  headerLen += PART_HEADER_SIZE;
  totalPartLen += part.getLength();
}
{code}

* Here the part.getLength() is an int, so if the size if greater than 2GB we 
have already overflowed the int barrier and we are putting a negative value in 
totalPartLen

so when we do the below check :
{code:title=Message.java}
if ((headerLen + totalPartLen) > Integer.MAX_VALUE) {
  throw new MessageTooLargeException(
  "Message size (" + (headerLen + totalPartLen) + ") exceeds 
maximum integer value");
}
{code}

The comparison is between a negative number and positive number 
[Integer.MAX_VALUE] hence it will always skip this loop.

and ultimately result in this exception.

{noformat}
java.io.IOExcepti

[jira] [Updated] (GEODE-2517) Data transfer of size > 2GB from server to client results in a hang and eventual timeout exception

[nabarun (JIRA)]

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

nabarun updated GEODE-2517:
---
Description: 
*Situation*:
1. Create a server and client.
2. Fill the server with a large amount of data. 
3. Create a query that will result in over 600,000 entries as result.
4. Chunk the result set in such a way that one chunk will result in a size 
greater than 2GB
5. Execute the query from the client.

*Expected*:
Message too large exception.

*Cause / Fix for the issue*:
If the number of parts to be transmitted is one then in sendBytes()

{code:title=Message.java}
for (int i = 0; i < this.numberOfParts; i++) {
  Part part = this.partsList[i];
  headerLen += PART_HEADER_SIZE;
  totalPartLen += part.getLength();
}
{code}

* Here the part.getLength() is an int, so if the size is greater than 2GB we 
have already overflowed the int barrier and we are putting a negative value in 
totalPartLen

so when we do the below check :
{code:title=Message.java}
if ((headerLen + totalPartLen) > Integer.MAX_VALUE) {
  throw new MessageTooLargeException(
  "Message size (" + (headerLen + totalPartLen) + ") exceeds 
maximum integer value");
}
{code}

The comparison is between a negative number and positive number 
[Integer.MAX_VALUE] hence it will always skip this loop.

and ultimately result in this exception.

{noformat}
java.io.IOException: Part length ( -508,098,123 ) and number of parts ( 1 ) 
inconsistent
at 
com.gemstone.gemfire.internal.cache.tier.sockets.Message.readPayloadFields(Message.java:836)
at 
com.gemstone.gemfire.internal.cache.tier.sockets.ChunkedMessage.readChunk(ChunkedMessage.java:276)
at 
com.gemstone.gemfire.internal.cache.tier.sockets.ChunkedMessage.receiveChunk(ChunkedMessage.java:220)
at 
com.gemstone.gemfire.cache.client.internal.ExecuteRegionFunctionOp$ExecuteRegionFunctionOpImpl.processResponse(ExecuteRegionFunctionOp.java:482)
at 
com.gemstone.gemfire.cache.client.internal.AbstractOp.processResponse(AbstractOp.java:215)
at 
com.gemstone.gemfire.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:153)
at 
com.gemstone.gemfire.cache.client.internal.AbstractOp.attempt(AbstractOp.java:369)
at 
com.gemstone.gemfire.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:252)
at 
com.gemstone.gemfire.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:319)
at 
com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:933)
at 
com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:158)
at 
com.gemstone.gemfire.cache.client.internal.PoolImpl.execute(PoolImpl.java:716)
at 
com.gemstone.gemfire.cache.client.internal.ExecuteRegionFunctionOp.execute(ExecuteRegionFunctionOp.java:159)
at 
com.gemstone.gemfire.cache.client.internal.ServerRegionProxy.executeFunction(ServerRegionProxy.java:801)
at 
com.gemstone.gemfire.internal.cache.execute.ServerRegionFunctionExecutor.executeOnServer(ServerRegionFunctionExecutor.java:212)
at 
com.gemstone.gemfire.internal.cache.execute.ServerRegionFunctionExecutor.executeFunction(ServerRegionFunctionExecutor.java:165)
at 
com.gemstone.gemfire.internal.cache.execute.ServerRegionFunctionExecutor.execute(ServerRegionFunctionExecutor.java:363)
at com.bookshop.buslogic.TestClient.run(TestClient.java:40)
at com.bookshop.buslogic.TestClient.main(TestClient.java:21)
{noformat}

  was:
*Situation*:
1. Create a server and client.
2. Fill the server with a large amount of data. 
3. Create a query that will result in over 600,000 entries as result.
4. Chunk the result set in such a way that one chunk will result in a size 
greater than 2GB
5. Execute the query from the client.

*Expected*:
Message too large exception.

*Cause / Fix for the issue*:
If the number of parts to be transmitted is one then in sendBytes()

{code:title=Message.java}
for (int i = 0; i < this.numberOfParts; i++) {
  Part part = this.partsList[i];
  headerLen += PART_HEADER_SIZE;
  totalPartLen += part.getLength();
}
{code}

* Here the part.getLength() is an int, so if the size if greater than 2GB we 
have already overflowed the int barrier and we are putting a negative value in 
totalPartLen

so when we do the below check :
{code:title=Message.java}
if ((headerLen + totalPartLen) > Integer.MAX_VALUE) {
  throw new MessageTooLargeException(
  "Message size (" + (headerLen + totalPartLen) + ") exceeds 
maximum integer value");
}
{code}

The comparison is between a negative number and positive number 
[Integer.MAX_VALUE] hence it will always skip this loop.

and ultimately result in this exception.

{noformat}
java.io.IOExcept

[jira] [Commented] (GEODE-2281) can not create redis server as the document describle

[Galen O'Sullivan (JIRA)]

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

Galen O'Sullivan commented on GEODE-2281:
-

It looks like you have another server running. By default, Geode servers use 
port 40404, and the server still needs to open a Geode server port. If any 
other server is bound to that port, Geode will be unable to start.

Perhaps we should mention in the docs that the server will still need to open a 
server port?

> can not create redis server  as the document describle
> --
>
> Key: GEODE-2281
> URL: https://issues.apache.org/jira/browse/GEODE-2281
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: netroby
>
> gfsh> start server --name=server1 --redis-bind-address=localhost
>  --redis-port=11211 --J=-Dgemfireredis.regiontype=PARTITION_PERSISTENT
> Starting a Geode Server in 
> /home/huzhifeng/workspace/geode-demo/apache-geode-1.0.0-incubating/server1...
> The Cache Server process terminated unexpectedly with exit status 1. Please 
> refer to the log file in 
> /home/huzhifeng/workspace/geode-demo/apache-geode-1.0.0-incubating/server1 
> for full details.
> Exception in thread "main" java.lang.RuntimeException: An IO error occurred 
> while starting a Server in 
> /home/huzhifeng/workspace/geode-demo/apache-geode-1.0.0-incubating/server1 on 
> 172.17.0.1[40404]: Network is unreachable; port (40404) is not available on 
> localhost.
> at 
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:735)
> at 
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:633)
> at 
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:184)
> Caused by: java.net.BindException: Network is unreachable; port (40404) is 
> not available on localhost.
> at 
> org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:127)
> at 
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:688)
> ... 2 more
> http://geode.apache.org/docs/guide/tools_modules/redis_adapter.html
> I download the latest geode binary distribute



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

[jira] [Updated] (GEODE-2435) Redis adapter MULTI behavior is different from Redis

[Galen O'Sullivan (JIRA)]

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

Galen O'Sullivan updated GEODE-2435:

Component/s: redis

> Redis adapter MULTI behavior is different from Redis
> 
>
> Key: GEODE-2435
> URL: https://issues.apache.org/jira/browse/GEODE-2435
> Project: Geode
>  Issue Type: Bug
>  Components: redis
>Reporter: Galen O'Sullivan
>
> {{WATCH}} isn't implemented properly, but this is about returning an error 
> instead of nil when we have a {{MULTI}} fail:
> {code}
> $ redis-cli -p 11212
> 127.0.0.1:11212> set a b
> OK
> 127.0.0.1:11212> watch a
> (error) ERR Keys cannot be watched or unwatched because GemFire watches all 
> keys by default for transactions
> 127.0.0.1:11212> lpush la boo
> (integer) 1
> (2.09s)
> 127.0.0.1:11212> multi
> OK
> 127.0.0.1:11212> lpush la z
> QUEUED
> 127.0.0.1:11212> lpush la x
> QUEUED
> {code}
> At this point, we {{lpush la foo}} in a different client, then:
> {code}
> 127.0.0.1:11212> exec
> 1) (error) ERR The server had an internal error please try again
> 2) (error) ERR The server had an internal error please try again
> 127.0.0.1:11212>
> {code}
> whereas a Redis instance will simply return nil instead of an error.
> Looking in the logs, I see this:
> {code}
> [error 2017/02/06 13:21:39.493 PST server2  
> tid=0x2a] GeodeRedisServer-Unexpected error handler for [id: 0x3ddf9f21, 
> /127.0.0.1:58862 => /127.0.0.1:11212]
> java.lang.UnsupportedOperationException: Operations on persist-backup regions 
> are not allowed because this thread has an active transaction
>   at 
> org.apache.geode.internal.cache.TXRegionState.(TXRegionState.java:60)
>   at 
> org.apache.geode.internal.cache.TXBucketRegionState.(TXBucketRegionState.java:29)
>   at org.apache.geode.internal.cache.TXState.writeRegion(TXState.java:252)
>   at 
> org.apache.geode.internal.cache.TXState.txWriteRegion(TXState.java:1110)
>   at 
> org.apache.geode.internal.cache.TXState.txReadEntry(TXState.java:1365)
>   at 
> org.apache.geode.internal.cache.TXState.txReadEntry(TXState.java:1344)
>   at 
> org.apache.geode.internal.cache.TXState.getDeserializedValue(TXState.java:1414)
>   at 
> org.apache.geode.internal.cache.TXStateProxyImpl.getDeserializedValue(TXStateProxyImpl.java:352)
>   at 
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1394)
>   at 
> org.apache.geode.internal.cache.PartitionedRegionDataStore.getLocally(PartitionedRegionDataStore.java:2047)
>   at 
> org.apache.geode.internal.cache.PartitionedRegion.getFromBucket(PartitionedRegion.java:4022)
>   at 
> org.apache.geode.internal.cache.PartitionedRegion.findObjectInSystem(PartitionedRegion.java:3399)
>   at org.apache.geode.internal.cache.TXState.findObject(TXState.java:1540)
>   at 
> org.apache.geode.internal.cache.TXStateProxyImpl.findObject(TXStateProxyImpl.java:614)
>   at 
> org.apache.geode.internal.cache.PartitionedRegion.get(PartitionedRegion.java:3160)
>   at 
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1330)
>   at 
> org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:282)
>   at 
> org.apache.geode.redis.internal.executor.list.ListExecutor.pushElements(ListExecutor.java:70)
>   at 
> org.apache.geode.redis.internal.executor.list.PushExecutor.executeCommand(PushExecutor.java:47)
>   at 
> org.apache.geode.redis.internal.ExecutionHandlerContext.executeWithTransaction(ExecutionHandlerContext.java:244)
>   at 
> org.apache.geode.redis.internal.ExecutionHandlerContext.executeCommand(ExecutionHandlerContext.java:191)
>   at 
> org.apache.geode.redis.internal.ExecutionHandlerContext.channelRead(ExecutionHandlerContext.java:137)
>   at 
> io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:368)
>   at 
> io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:353)
>   at 
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:173)
>   at 
> io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:368)
>   at 
> io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:353)
>   at 
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:780)
>   at 
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:100)
>   at 
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:497)
>   at 
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:465)
>   at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:359)
>   at 
> io.

[jira] [Updated] (GEODE-109) Bugs in redis adapter when running with multiple vms

[Galen O'Sullivan (JIRA)]

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

Galen O'Sullivan updated GEODE-109:
---
Component/s: redis

> Bugs in redis adapter when running with multiple vms
> 
>
> Key: GEODE-109
> URL: https://issues.apache.org/jira/browse/GEODE-109
> Project: Geode
>  Issue Type: Bug
>  Components: core, redis
>Affects Versions: 1.0.0-incubating
>Reporter: Vitaliy Gavrilov
> Fix For: 1.0.0-incubating.M1
>
>
> 1) The meta data attached with the redis lists implementation does not always 
> stay synchronized with the list.
> 2) Queries run by sorted set requests fail in execution
> 3) Potential deadlock when regions are created simultaneously in different vms



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

Re: Review Request 56803: GEODE-2142: Update GEODE-JSON module with compliant ORG.JSON implementation

[Anthony Baker]

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


Ship it!




There's a few more NOTICE files to be updated, looks good otherwise.

- Anthony Baker


On Feb. 21, 2017, 8:42 p.m., Udo Kohlmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56803/
> ---
> 
> (Updated Feb. 21, 2017, 8:42 p.m.)
> 
> 
> Review request for geode, Anthony Baker, Jacob Barrett, Jinmei Liao, and Kirk 
> Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Removed non-compliant ORJ.JSON implementation with a compliant opensource 
> ORG.JSON implementation
> 
> 
> Diffs
> -
> 
>   LICENSE 9bfdd83c9 
>   NOTICE 13a30d3bb 
>   geode-assembly/src/main/dist/LICENSE 4769f9a55 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/CliUtil.java
>  8525b5862 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/json/GfJsonObject.java
>  69666ff9d 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/result/AbstractResultData.java
>  e08d9b7c0 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/result/ResultBuilder.java
>  06060a4c6 
>   geode-json/build.gradle PRE-CREATION 
>   geode-json/src/main/java/org/json/CDL.java d78935bd7 
>   geode-json/src/main/java/org/json/Cookie.java 21f88d8bd 
>   geode-json/src/main/java/org/json/CookieList.java 35e1a97f4 
>   geode-json/src/main/java/org/json/HTTP.java 1e815aabe 
>   geode-json/src/main/java/org/json/HTTPTokener.java 72c9b8878 
>   geode-json/src/main/java/org/json/JSON.java PRE-CREATION 
>   geode-json/src/main/java/org/json/JSONArray.java edaefa420 
>   geode-json/src/main/java/org/json/JSONException.java b65efe25c 
>   geode-json/src/main/java/org/json/JSONML.java b535614f8 
>   geode-json/src/main/java/org/json/JSONObject.java a2c6d8b6a 
>   geode-json/src/main/java/org/json/JSONStringer.java 234e17451 
>   geode-json/src/main/java/org/json/JSONTokener.java 4dd2ba2cc 
>   geode-json/src/main/java/org/json/JSONWriter.java 7d4704b21 
>   geode-json/src/main/java/org/json/XML.java ae6d61a49 
>   geode-json/src/main/java/org/json/XMLTokener.java f56a1f6a5 
>   geode-json/src/test/java/org/json/FileTest.java PRE-CREATION 
>   geode-json/src/test/java/org/json/JSONArrayTest.java PRE-CREATION 
>   geode-json/src/test/java/org/json/JSONFunctionTestObject.java PRE-CREATION 
>   geode-json/src/test/java/org/json/JSONObjectTest.java PRE-CREATION 
>   geode-json/src/test/java/org/json/JSONStringerTest.java PRE-CREATION 
>   geode-json/src/test/java/org/json/JSONTokenerTest.java PRE-CREATION 
>   geode-json/src/test/java/org/json/ParsingTest.java PRE-CREATION 
>   geode-json/src/test/java/org/json/SelfUseTest.java PRE-CREATION 
>   geode-json/src/test/resources/sample-01.json PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/56803/diff/
> 
> 
> Testing
> ---
> 
> pre-checkin = completed. 1 Flaky failure, unrelated failure
> 
> 
> Thanks,
> 
> Udo Kohlmeyer
> 
>

[jira] [Commented] (GEODE-2435) Redis adapter MULTI behavior is different from Redis

[Galen O'Sullivan (JIRA)]

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

Galen O'Sullivan commented on GEODE-2435:
-

In addition, we throw errors if regions contain data that is spread across 
servers, which is a problem:
{code}
(error) ERR This transcation cannot be initiated, make sure the command is 
executed against a replicate region or your data is collocated. If you are 
using persistent regions, make sure transactions are enabled
{code}

> Redis adapter MULTI behavior is different from Redis
> 
>
> Key: GEODE-2435
> URL: https://issues.apache.org/jira/browse/GEODE-2435
> Project: Geode
>  Issue Type: Bug
>  Components: redis
>Reporter: Galen O'Sullivan
>
> {{WATCH}} isn't implemented properly, but this is about returning an error 
> instead of nil when we have a {{MULTI}} fail:
> {code}
> $ redis-cli -p 11212
> 127.0.0.1:11212> set a b
> OK
> 127.0.0.1:11212> watch a
> (error) ERR Keys cannot be watched or unwatched because GemFire watches all 
> keys by default for transactions
> 127.0.0.1:11212> lpush la boo
> (integer) 1
> (2.09s)
> 127.0.0.1:11212> multi
> OK
> 127.0.0.1:11212> lpush la z
> QUEUED
> 127.0.0.1:11212> lpush la x
> QUEUED
> {code}
> At this point, we {{lpush la foo}} in a different client, then:
> {code}
> 127.0.0.1:11212> exec
> 1) (error) ERR The server had an internal error please try again
> 2) (error) ERR The server had an internal error please try again
> 127.0.0.1:11212>
> {code}
> whereas a Redis instance will simply return nil instead of an error.
> Looking in the logs, I see this:
> {code}
> [error 2017/02/06 13:21:39.493 PST server2  
> tid=0x2a] GeodeRedisServer-Unexpected error handler for [id: 0x3ddf9f21, 
> /127.0.0.1:58862 => /127.0.0.1:11212]
> java.lang.UnsupportedOperationException: Operations on persist-backup regions 
> are not allowed because this thread has an active transaction
>   at 
> org.apache.geode.internal.cache.TXRegionState.(TXRegionState.java:60)
>   at 
> org.apache.geode.internal.cache.TXBucketRegionState.(TXBucketRegionState.java:29)
>   at org.apache.geode.internal.cache.TXState.writeRegion(TXState.java:252)
>   at 
> org.apache.geode.internal.cache.TXState.txWriteRegion(TXState.java:1110)
>   at 
> org.apache.geode.internal.cache.TXState.txReadEntry(TXState.java:1365)
>   at 
> org.apache.geode.internal.cache.TXState.txReadEntry(TXState.java:1344)
>   at 
> org.apache.geode.internal.cache.TXState.getDeserializedValue(TXState.java:1414)
>   at 
> org.apache.geode.internal.cache.TXStateProxyImpl.getDeserializedValue(TXStateProxyImpl.java:352)
>   at 
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1394)
>   at 
> org.apache.geode.internal.cache.PartitionedRegionDataStore.getLocally(PartitionedRegionDataStore.java:2047)
>   at 
> org.apache.geode.internal.cache.PartitionedRegion.getFromBucket(PartitionedRegion.java:4022)
>   at 
> org.apache.geode.internal.cache.PartitionedRegion.findObjectInSystem(PartitionedRegion.java:3399)
>   at org.apache.geode.internal.cache.TXState.findObject(TXState.java:1540)
>   at 
> org.apache.geode.internal.cache.TXStateProxyImpl.findObject(TXStateProxyImpl.java:614)
>   at 
> org.apache.geode.internal.cache.PartitionedRegion.get(PartitionedRegion.java:3160)
>   at 
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1330)
>   at 
> org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:282)
>   at 
> org.apache.geode.redis.internal.executor.list.ListExecutor.pushElements(ListExecutor.java:70)
>   at 
> org.apache.geode.redis.internal.executor.list.PushExecutor.executeCommand(PushExecutor.java:47)
>   at 
> org.apache.geode.redis.internal.ExecutionHandlerContext.executeWithTransaction(ExecutionHandlerContext.java:244)
>   at 
> org.apache.geode.redis.internal.ExecutionHandlerContext.executeCommand(ExecutionHandlerContext.java:191)
>   at 
> org.apache.geode.redis.internal.ExecutionHandlerContext.channelRead(ExecutionHandlerContext.java:137)
>   at 
> io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:368)
>   at 
> io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:353)
>   at 
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:173)
>   at 
> io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:368)
>   at 
> io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:353)
>   at 
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:780)
>   at 
> io.netty

[jira] [Comment Edited] (GEODE-2435) Redis adapter MULTI behavior is different from Redis

[Galen O'Sullivan (JIRA)]

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

Galen O'Sullivan edited comment on GEODE-2435 at 2/21/17 11:54 PM:
---

In addition, we throw errors if regions contain data that is spread across 
servers, which is a problem:
{code}
27.0.0.1:6379> multi
OK
127.0.0.1:6379> set foo bar
QUEUED
127.0.0.1:6379> set bar baz
QUEUED
127.0.0.1:6379> exec
1) OK
2) (error) ERR This transcation cannot be initiated, make sure the command is 
executed against a replicate region or your data is collocated. If you are 
using persistent regions, make sure transactions are enabled
{code}


was (Author: gosullivan):
In addition, we throw errors if regions contain data that is spread across 
servers, which is a problem:
{code}
(error) ERR This transcation cannot be initiated, make sure the command is 
executed against a replicate region or your data is collocated. If you are 
using persistent regions, make sure transactions are enabled
{code}

> Redis adapter MULTI behavior is different from Redis
> 
>
> Key: GEODE-2435
> URL: https://issues.apache.org/jira/browse/GEODE-2435
> Project: Geode
>  Issue Type: Bug
>  Components: redis
>Reporter: Galen O'Sullivan
>
> {{WATCH}} isn't implemented properly, but this is about returning an error 
> instead of nil when we have a {{MULTI}} fail:
> {code}
> $ redis-cli -p 11212
> 127.0.0.1:11212> set a b
> OK
> 127.0.0.1:11212> watch a
> (error) ERR Keys cannot be watched or unwatched because GemFire watches all 
> keys by default for transactions
> 127.0.0.1:11212> lpush la boo
> (integer) 1
> (2.09s)
> 127.0.0.1:11212> multi
> OK
> 127.0.0.1:11212> lpush la z
> QUEUED
> 127.0.0.1:11212> lpush la x
> QUEUED
> {code}
> At this point, we {{lpush la foo}} in a different client, then:
> {code}
> 127.0.0.1:11212> exec
> 1) (error) ERR The server had an internal error please try again
> 2) (error) ERR The server had an internal error please try again
> 127.0.0.1:11212>
> {code}
> whereas a Redis instance will simply return nil instead of an error.
> Looking in the logs, I see this:
> {code}
> [error 2017/02/06 13:21:39.493 PST server2  
> tid=0x2a] GeodeRedisServer-Unexpected error handler for [id: 0x3ddf9f21, 
> /127.0.0.1:58862 => /127.0.0.1:11212]
> java.lang.UnsupportedOperationException: Operations on persist-backup regions 
> are not allowed because this thread has an active transaction
>   at 
> org.apache.geode.internal.cache.TXRegionState.(TXRegionState.java:60)
>   at 
> org.apache.geode.internal.cache.TXBucketRegionState.(TXBucketRegionState.java:29)
>   at org.apache.geode.internal.cache.TXState.writeRegion(TXState.java:252)
>   at 
> org.apache.geode.internal.cache.TXState.txWriteRegion(TXState.java:1110)
>   at 
> org.apache.geode.internal.cache.TXState.txReadEntry(TXState.java:1365)
>   at 
> org.apache.geode.internal.cache.TXState.txReadEntry(TXState.java:1344)
>   at 
> org.apache.geode.internal.cache.TXState.getDeserializedValue(TXState.java:1414)
>   at 
> org.apache.geode.internal.cache.TXStateProxyImpl.getDeserializedValue(TXStateProxyImpl.java:352)
>   at 
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1394)
>   at 
> org.apache.geode.internal.cache.PartitionedRegionDataStore.getLocally(PartitionedRegionDataStore.java:2047)
>   at 
> org.apache.geode.internal.cache.PartitionedRegion.getFromBucket(PartitionedRegion.java:4022)
>   at 
> org.apache.geode.internal.cache.PartitionedRegion.findObjectInSystem(PartitionedRegion.java:3399)
>   at org.apache.geode.internal.cache.TXState.findObject(TXState.java:1540)
>   at 
> org.apache.geode.internal.cache.TXStateProxyImpl.findObject(TXStateProxyImpl.java:614)
>   at 
> org.apache.geode.internal.cache.PartitionedRegion.get(PartitionedRegion.java:3160)
>   at 
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1330)
>   at 
> org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:282)
>   at 
> org.apache.geode.redis.internal.executor.list.ListExecutor.pushElements(ListExecutor.java:70)
>   at 
> org.apache.geode.redis.internal.executor.list.PushExecutor.executeCommand(PushExecutor.java:47)
>   at 
> org.apache.geode.redis.internal.ExecutionHandlerContext.executeWithTransaction(ExecutionHandlerContext.java:244)
>   at 
> org.apache.geode.redis.internal.ExecutionHandlerContext.executeCommand(ExecutionHandlerContext.java:191)
>   at 
> org.apache.geode.redis.internal.ExecutionHandlerContext.channelRead(ExecutionHandlerContext.java:137)
>   at 
> io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:368)
>   at 
> io.netty.channel.Default

[jira] [Updated] (GEODE-2517) Data transfer of size > 2GB from server to client results in a hang and eventual timeout exception

[nabarun (JIRA)]

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

nabarun updated GEODE-2517:
---
Affects Version/s: 1.1.0

> Data transfer of size > 2GB from server to client results in a hang and 
> eventual timeout exception
> --
>
> Key: GEODE-2517
> URL: https://issues.apache.org/jira/browse/GEODE-2517
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Affects Versions: 1.1.0
>Reporter: nabarun
>
> *Situation*:
> 1. Create a server and client.
> 2. Fill the server with a large amount of data. 
> 3. Create a query that will result in over 600,000 entries as result.
> 4. Chunk the result set in such a way that one chunk will result in a size 
> greater than 2GB
> 5. Execute the query from the client.
> *Expected*:
> Message too large exception.
> *Cause / Fix for the issue*:
> If the number of parts to be transmitted is one then in sendBytes()
> {code:title=Message.java}
> for (int i = 0; i < this.numberOfParts; i++) {
>   Part part = this.partsList[i];
>   headerLen += PART_HEADER_SIZE;
>   totalPartLen += part.getLength();
> }
> {code}
> * Here the part.getLength() is an int, so if the size is greater than 2GB we 
> have already overflowed the int barrier and we are putting a negative value 
> in totalPartLen
> so when we do the below check :
> {code:title=Message.java}
> if ((headerLen + totalPartLen) > Integer.MAX_VALUE) {
>   throw new MessageTooLargeException(
>   "Message size (" + (headerLen + totalPartLen) + ") exceeds 
> maximum integer value");
> }
> {code}
> The comparison is between a negative number and positive number 
> [Integer.MAX_VALUE] hence it will always skip this loop.
> and ultimately result in this exception.
> {noformat}
> java.io.IOException: Part length ( -508,098,123 ) and number of parts ( 1 ) 
> inconsistent
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.Message.readPayloadFields(Message.java:836)
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.ChunkedMessage.readChunk(ChunkedMessage.java:276)
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.ChunkedMessage.receiveChunk(ChunkedMessage.java:220)
>   at 
> com.gemstone.gemfire.cache.client.internal.ExecuteRegionFunctionOp$ExecuteRegionFunctionOpImpl.processResponse(ExecuteRegionFunctionOp.java:482)
>   at 
> com.gemstone.gemfire.cache.client.internal.AbstractOp.processResponse(AbstractOp.java:215)
>   at 
> com.gemstone.gemfire.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:153)
>   at 
> com.gemstone.gemfire.cache.client.internal.AbstractOp.attempt(AbstractOp.java:369)
>   at 
> com.gemstone.gemfire.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:252)
>   at 
> com.gemstone.gemfire.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:319)
>   at 
> com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:933)
>   at 
> com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:158)
>   at 
> com.gemstone.gemfire.cache.client.internal.PoolImpl.execute(PoolImpl.java:716)
>   at 
> com.gemstone.gemfire.cache.client.internal.ExecuteRegionFunctionOp.execute(ExecuteRegionFunctionOp.java:159)
>   at 
> com.gemstone.gemfire.cache.client.internal.ServerRegionProxy.executeFunction(ServerRegionProxy.java:801)
>   at 
> com.gemstone.gemfire.internal.cache.execute.ServerRegionFunctionExecutor.executeOnServer(ServerRegionFunctionExecutor.java:212)
>   at 
> com.gemstone.gemfire.internal.cache.execute.ServerRegionFunctionExecutor.executeFunction(ServerRegionFunctionExecutor.java:165)
>   at 
> com.gemstone.gemfire.internal.cache.execute.ServerRegionFunctionExecutor.execute(ServerRegionFunctionExecutor.java:363)
>   at com.bookshop.buslogic.TestClient.run(TestClient.java:40)
>   at com.bookshop.buslogic.TestClient.main(TestClient.java:21)
> {noformat}



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