date:20170221

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

2017-02-21 Thread Kirk Lund


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

(Updated Feb. 22, 2017, 2:06 a.m.)


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


Changes
---

precheckin passed (all green)


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 (updated)
---

precheckin passed (all green)


Thanks,

Kirk Lund

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

2017-02-21 Thread ASF GitHub Bot (JIRA)


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

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

Yep! Just use that and remove the two log statements (one is add and the 
2nd is remove). I think regex patterns work in the string as well if that ever 
helps.


> surprise members are never timed out during startup
> ---
>
> Key: GEODE-2497
> URL: https:/

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

2017-02-21 Thread kirklund

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

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

Yep! Just use that and remove the two log statements (one is add and the 
2nd is remove). I think regex patterns work in the string as well if that ever 
helps.


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

2017-02-21 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on GEODE-2507:


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

GEODE-2507 Add basic README


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

2017-02-21 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on GEODE-2507:


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

GEODE-2507 Add gradle rat checking


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

2017-02-21 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on GEODE-2507:


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

GEODE-2507 Add bundled components to LICENSE


> 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-2519) geode-native docs: add ASF copyrights

2017-02-21 Thread Dave Barnes (JIRA)

Dave Barnes created GEODE-2519:
--

 Summary: geode-native docs: add ASF copyrights
 Key: GEODE-2519
 URL: https://issues.apache.org/jira/browse/GEODE-2519
 Project: Geode
  Issue Type: Improvement
  Components: docs
Reporter: Dave Barnes


The recently contributed docs need ASF copyright headers.



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

[jira] [Assigned] (GEODE-2519) geode-native docs: add ASF copyrights

2017-02-21 Thread Dave Barnes (JIRA)


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

Dave Barnes reassigned GEODE-2519:
--

Assignee: Dave Barnes

> geode-native docs: add ASF copyrights
> -
>
> Key: GEODE-2519
> URL: https://issues.apache.org/jira/browse/GEODE-2519
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> The recently contributed docs need ASF copyright headers.



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

Re: [jira] [Created] (GEODE-2435) Redis adapter MULTI behavior is different from Redis

2017-02-21 Thread Michael Stolz

This looks like the persistence with transactions issue that Gemfire has.
There is a system property to allow it to work

--
Mike Stolz
Principal Engineer - Gemfire Product Manager
Mobile: 631-835-4771

On Feb 6, 2017 4:41 PM, "Galen O'Sullivan (JIRA)"  wrote:

> Galen O'Sullivan created GEODE-2435:
> ---
>
>  Summary: 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
> 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.<
> init>(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.processS

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #477 has FAILED

2017-02-21 Thread Spring CI


---
Spring Data GemFire > Nightly-ApacheGeode > #477 failed (rerun 2 times).
---
This build was rerun by John Blum.
No failed tests found, a possible compilation error.

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

-
Currently Responsible
-

No one is responsible for fixing this build.



--
Failing Jobs
--
  - Default Job (Default Stage): No tests found.




--
This message is automatically generated by Atlassian Bamboo

[jira] [Updated] (GEODE-2461) Remove unnecessary entries from gradle/dependency-versions.properties

2017-02-21 Thread Kirk Lund (JIRA)


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

Kirk Lund updated GEODE-2461:
-
Description: 
These are potential candidates for removal from explicit inclusion in 
gradle/dependency-versions.properties:

* hadoop
* hsqldb


  was:
These are potential candidates for removal from explicit inclusion in 
gradle/dependency-versions.properties:

* cglib
* commons-configuration
* hadoop
* hsqldb


> Remove unnecessary entries from gradle/dependency-versions.properties
> -
>
> Key: GEODE-2461
> URL: https://issues.apache.org/jira/browse/GEODE-2461
> Project: Geode
>  Issue Type: Wish
>  Components: build
>Reporter: Kirk Lund
>
> These are potential candidates for removal from explicit inclusion in 
> gradle/dependency-versions.properties:
> * hadoop
> * hsqldb



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

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

2017-02-21 Thread ASF GitHub Bot (JIRA)


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

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

GitHub user dgkimura opened a pull request:

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

GEODE-2441: Remove pdx auto serializer from core sources

Purpose of this pull-request is to simplify core dependencies and core 
source size by removing PdxAutoSerializer and related tests.  Reasoning is that 
PdxAutoSerializer is more of a standalone utility project that adds nearly 
40,000 lines of extra complexity.

A followup change will be to move PdxAutoSerializer as a stand-alone 
utility either into a `contrib` directory in `geode-native` repo or somewhere 
inside `geode-examples` repo.

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

$ git pull https://github.com/dgkimura/geode-native feature/GEODE-2441

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

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






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

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

2017-02-21 Thread Jinmei Liao


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


Ship it!




Ship It!

- Jinmei Liao


On Feb. 21, 2017, 9: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, 9: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
> 
>

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

2017-02-21 Thread Jinmei Liao


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




geode-core/src/main/java/org/apache/geode/internal/io/MainWithChildrenRollingFileHandler.java
 (line 210)


You can use StringUtils.isBlank(name) to do it. Just FYI.


- Jinmei Liao


On Feb. 21, 2017, 9: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, 9: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
> 
>

[GitHub] geode-native pull request #21: GEODE-2441: Remove pdx auto serializer from c...

2017-02-21 Thread dgkimura

GitHub user dgkimura opened a pull request:

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

GEODE-2441: Remove pdx auto serializer from core sources

Purpose of this pull-request is to simplify core dependencies and core 
source size by removing PdxAutoSerializer and related tests.  Reasoning is that 
PdxAutoSerializer is more of a standalone utility project that adds nearly 
40,000 lines of extra complexity.

A followup change will be to move PdxAutoSerializer as a stand-alone 
utility either into a `contrib` directory in `geode-native` repo or somewhere 
inside `geode-examples` repo.

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

$ git pull https://github.com/dgkimura/geode-native feature/GEODE-2441

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

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






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

[jira] [Updated] (GEODE-2461) Remove unnecessary entries from gradle/dependency-versions.properties

2017-02-21 Thread Kirk Lund (JIRA)


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

Kirk Lund updated GEODE-2461:
-
Description: 
These are potential candidates for removal from explicit inclusion in 
gradle/dependency-versions.properties:

* cglib
* commons-configuration
* hadoop
* hsqldb

  was:
These are potential candidates for removal from explicit inclusion in 
gradle/dependency-versions.properties:

* cglib
* commons-configuration
* hsqldb


> Remove unnecessary entries from gradle/dependency-versions.properties
> -
>
> Key: GEODE-2461
> URL: https://issues.apache.org/jira/browse/GEODE-2461
> Project: Geode
>  Issue Type: Wish
>  Components: build
>Reporter: Kirk Lund
>
> These are potential candidates for removal from explicit inclusion in 
> gradle/dependency-versions.properties:
> * cglib
> * commons-configuration
> * hadoop
> * hsqldb



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

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

2017-02-21 Thread ASF GitHub Bot (JIRA)


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

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

Ah, so this would be the equivalent call now?
```java
IgnoredException.addIgnoredException("attempt to add old member");
```


> surprise members are never timed out during startup
> ---
>
> Key: GEODE-2497
> URL: https://issues.apache.org/

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

2017-02-21 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on GEODE-2514:


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

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

* add MainWithChildrenRollingFileHandlerIntegrationTest
* add StatArchiveHandlerIntegrationTest
* expand DiskSpaceLimitIntegrationTest


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

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

2017-02-21 Thread galen-pivotal

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

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

Ah, so this would be the equivalent call now?
```java
IgnoredException.addIgnoredException("attempt to add old member");
```


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

2017-02-21 Thread nabarun (JIRA)


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

nabarun commented on GEODE-2517:


{code:title=Message.java}
for (int i = 0; i < this.numberOfParts; i++) {
  Part part = this.partsList[i];
  headerLen += PART_HEADER_SIZE;
  totalPartLen += part.getLength();
  if( totalPartLen < 0 ){
   throw new MessageTooLargeException(
  "Message size" + totalPartLen + " exceeds maximum integer value");
}  
}
{code}

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

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

2017-02-21 Thread ASF GitHub Bot (JIRA)


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

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

2017-02-21 Thread ASF GitHub Bot (JIRA)


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

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_r102356823
  
--- 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 pull request #402: GEODE-2497 surprise members are never timed out dur...

2017-02-21 Thread bschuchardt

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

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

2017-02-21 Thread bschuchardt

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

https://github.com/apache/geode/pull/402#discussion_r102356810
  
--- 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] [Created] (GEODE-2518) Developer can pass Collections via REST API

2017-02-21 Thread Addison (JIRA)

Addison created GEODE-2518:
--

 Summary: Developer can pass Collections via REST API
 Key: GEODE-2518
 URL: https://issues.apache.org/jira/browse/GEODE-2518
 Project: Geode
  Issue Type: Wish
  Components: rest (dev)
Reporter: Addison


Requesting that the Gemfire REST Api allow the passing of a collection in the 
JSON payload.



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

[jira] [Commented] (GEODE-2498) Revise 1.1.0 manual to remove references to 1.0.0-incubating

2017-02-21 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on GEODE-2498:


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

GEODE-2498 Regenerate website to remove references to
1.0.0-incubating from the 1.1.0 manual

- Also remove extra blank space committed recently to nudge
a sync of website to occur.


> Revise 1.1.0 manual to remove references to 1.0.0-incubating
> 
>
> Key: GEODE-2498
> URL: https://issues.apache.org/jira/browse/GEODE-2498
> Project: Geode
>  Issue Type: Bug
>  Components: docs, web-content
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>
> There are two errant instances within the Geode 1.1.0 manual that say 
> 1.0.0-incubating.  This task is to remove these references, and further, to 
> revise the prose such that it does not contain a version number that would 
> need to be changed in future releases.  That  would avoid the mistake that 
> occurred with the 1.1.0 manual.
> The 2 instances are within files
> * {{geode-docs/about_geode.html.md.erb}}
> * {{geode-docs/prereq_and_install.html.md.erb}}



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

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

2017-02-21 Thread Hitesh Khamesra (JIRA)


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

Hitesh Khamesra commented on GEODE-2435:


[~gosullivan] Good one; Geode has a limitation with transaction keys; it should 
be on one node only. Does same thing work with redis? We need to remove this 
command from RedisAdapter.

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

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

2017-02-21 Thread 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)

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

2017-02-21 Thread 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] [Commented] (GEODE-2435) Redis adapter MULTI behavior is different from Redis

2017-02-21 Thread 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

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

2017-02-21 Thread 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] [Updated] (GEODE-109) Bugs in redis adapter when running with multiple vms

2017-02-21 Thread 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)

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

2017-02-21 Thread 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] [Commented] (GEODE-2281) can not create redis server as the document describle

2017-02-21 Thread 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-2517) Data transfer of size > 2GB from server to client results in a hang and eventual timeout exception

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

2017-02-21 Thread 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

2017-02-21 Thread 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] [Commented] (GEODE-2512) Geode Native docs: book fails to build

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

2017-02-21 Thread 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)

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

2017-02-21 Thread 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] [Commented] (GEODE-2497) surprise members are never timed out during startup

2017-02-21 Thread 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
-  }
-

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

2017-02-21 Thread 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

2017-02-21 Thread 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
-  }
-

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

2017-02-21 Thread 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
+

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

2017-02-21 Thread 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...

2017-02-21 Thread 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
+

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

2017-02-21 Thread 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)

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

2017-02-21 Thread 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] [Commented] (GEODE-2497) surprise members are never timed out during startup

2017-02-21 Thread 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

2017-02-21 Thread 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-2506) Update spring dependencies

2017-02-21 Thread 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)

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

2017-02-21 Thread 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-2476) Replace gfcpp with geode

2017-02-21 Thread 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-native pull request #13: GEODE-2476: Replace gfcpp with geode.

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

2017-02-21 Thread 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 pull request #402: GEODE-2497 surprise members are never timed out dur...

2017-02-21 Thread 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.
---

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

2017-02-21 Thread 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.
---

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

2017-02-21 Thread 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)

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

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

2017-02-21 Thread 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)

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

2017-02-21 Thread 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

2017-02-21 Thread 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)

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

2017-02-21 Thread 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.
---

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

2017-02-21 Thread 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...

2017-02-21 Thread 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.
---

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

2017-02-21 Thread 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)

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

2017-02-21 Thread 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)

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

2017-02-21 Thread 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] [Updated] (GEODE-369) CI failure: RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByPut fails intermittently with assertion

2017-02-21 Thread 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)

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

2017-02-21 Thread 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)

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

2017-02-21 Thread 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] [Assigned] (GEODE-369) CI failure: RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByPut fails intermittently with assertion

2017-02-21 Thread 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)

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

2017-02-21 Thread 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] [Commented] (GEODE-2497) surprise members are never timed out during startup

2017-02-21 Thread 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)

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

2017-02-21 Thread 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

2017-02-21 Thread 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

2017-02-21 Thread 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...

2017-02-21 Thread 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

2017-02-21 Thread 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...

2017-02-21 Thread 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...

2017-02-21 Thread 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

2017-02-21 Thread 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...

2017-02-21 Thread 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-2515) CI Failure: BaseLineAndCompareQueryPerfJUnitTest.testPerformanceForRangeQueries FAILED failed with AssertionFailedError

2017-02-21 Thread 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)

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

2017-02-21 Thread 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

2017-02-21 Thread 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-369) CI failure: RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByPut fails intermittently with assertion

2017-02-21 Thread 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)

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

2017-02-21 Thread 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

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

2017-02-21 Thread 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

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

2017-02-21 Thread 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)

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

2017-02-21 Thread 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-2267) Add gfsh command to export stat files

2017-02-21 Thread 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)

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

2017-02-21 Thread 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

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

2017-02-21 Thread 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
> 
>

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

2017-02-21 Thread 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

2017-02-21 Thread 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] [Closed] (GEODE-2309) Replace or add ASF copyright statements in source.

2017-02-21 Thread 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)

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

2017-02-21 Thread 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] [Commented] (GEODE-2037) Fix links to point to correct location of documentation

2017-02-21 Thread 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

2017-02-21 Thread 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)

1 2 >

1 - 100 of 127 matches

Mail list logo