[jira] [Resolved] (GEODE-4095) User Guide: Update Statistics Subnav and Cross-refs

[Dave Barnes (JIRA)]

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

Dave Barnes resolved GEODE-4095.

   Resolution: Fixed
Fix Version/s: 1.4.0

> User Guide: Update Statistics Subnav and Cross-refs
> ---
>
> Key: GEODE-4095
> URL: https://issues.apache.org/jira/browse/GEODE-4095
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
> Fix For: 1.4.0
>
>
> The Left-side subnav and some internal cross-references our out of sync for 
> the Statistics reference section.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3923) Provide whitelist/blacklist capability for java serialization

[ASF GitHub Bot (JIRA)]

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

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

karensmolermiller opened a new pull request #1166: GEODE-3923 Document the 2 
new properties serializable-object-filter
URL: https://github.com/apache/geode/pull/1166
 
 
   
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Provide whitelist/blacklist capability for java serialization
> -
>
> Key: GEODE-3923
> URL: https://issues.apache.org/jira/browse/GEODE-3923
> Project: Geode
>  Issue Type: New Feature
>  Components: docs
>Reporter: Bruce Schuchardt
>Assignee: Karen Smoler Miller
> Fix For: 1.4.0
>
>
> I would like to be able to restrict what classes of objects Geode will allow 
> to be deserialized via Java's ObjectInputStream in clients and servers.  
> Something similar to the mechanism recently added to the JRE 
> (http://openjdk.java.net/jeps/290) would be pretty cool.  Geode would have to 
> whitelist its own stuff, of course, so I don't have to deal with it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (GEODE-3923) Provide whitelist/blacklist capability for java serialization

[Karen Smoler Miller (JIRA)]

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

Karen Smoler Miller reassigned GEODE-3923:
--

Assignee: Karen Smoler Miller

> Provide whitelist/blacklist capability for java serialization
> -
>
> Key: GEODE-3923
> URL: https://issues.apache.org/jira/browse/GEODE-3923
> Project: Geode
>  Issue Type: New Feature
>  Components: docs
>Reporter: Bruce Schuchardt
>Assignee: Karen Smoler Miller
> Fix For: 1.4.0
>
>
> I would like to be able to restrict what classes of objects Geode will allow 
> to be deserialized via Java's ObjectInputStream in clients and servers.  
> Something similar to the mechanism recently added to the JRE 
> (http://openjdk.java.net/jeps/290) would be pretty cool.  Geode would have to 
> whitelist its own stuff, of course, so I don't have to deal with it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (GEODE-3923) Provide whitelist/blacklist capability for java serialization

[Karen Smoler Miller (JIRA)]

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

Karen Smoler Miller reopened GEODE-3923:


Reopening ticket to do documentation of the new functionality.

> Provide whitelist/blacklist capability for java serialization
> -
>
> Key: GEODE-3923
> URL: https://issues.apache.org/jira/browse/GEODE-3923
> Project: Geode
>  Issue Type: New Feature
>  Components: docs
>Reporter: Bruce Schuchardt
> Fix For: 1.4.0
>
>
> I would like to be able to restrict what classes of objects Geode will allow 
> to be deserialized via Java's ObjectInputStream in clients and servers.  
> Something similar to the mechanism recently added to the JRE 
> (http://openjdk.java.net/jeps/290) would be pretty cool.  Geode would have to 
> whitelist its own stuff, of course, so I don't have to deal with it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-4096) Race Condition between ConcurrentSerialGatewaySenderEventProcessor stopper thread and the _dispatchBatch method for the connection global variable.

[nabarun (JIRA)]

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

nabarun updated GEODE-4096:
---
Description: 
*+Order of execution for this race condition to occur+*.
#  _dispatchBatch is trying to dispatch a batch of events but was somehow 
unsuccessful 
# It silently decides that the remote server may not be ready so it wants to 
retry
# Same time we decide to stop the SerialGatewaySenderEventProcessor hence we 
call the Stopper Thread.
# Before the threads are started on all the senders / dispatchers it sets the 
isStopped flag for the SerialGatewaySenderEventProcessor to true.
# Then the _dispatchBatch method which was in retry mode makes a getConnection 
call to get the connection. This method does a check on the 
SerialGatewaySenderEventProcessor's isStopped flag. It sees that the flag is 
set and this return null.
# This null is stored in the global variable connection for the dispatcher.
# Now that the _dispatchBatch method calls sees that the connection is null it 
should raise an exception and destroyConnection.
# Meanwhile there was a AckThreadReader that was running and the stopper thread 
for the event processor wants to stop it, but since the connection global 
variable was set to null by the get connection method call by _disptachBatch.
# Hence the shutDownAckReaderThreadConnection is executed on null and hence the 
AckReaderThread continues to keep running - being stuck on socketRead0.
# But the problem is that the AckReaderThread acquire a 
connectionLifeCycle.readLock. to readAcknowledgement, but the destroyConnection 
calls from the stopper thread and _dispatchBatch's exception handling code 
needs a connectionLifeCycleLock.writeLock which they can't because readLock is 
held by the AckReaderThread, causing a deadlock




  was:
*+Order of execution for this race condition to occur+*.
#  _dispatchBatch is trying to dispatch a batch of events but was somehow 
unsuccessful 
# It silently decides that the remote server may not be ready so it wants to 
retry
# Same time we decide to stop the SerialGatewaySenderEventProcessor hence we 
call the Stopper Thread.
# Before the threads are started on all the senders / dispatchers it sets the 
isStopped flag for the SerialGatewaySenderEventProcessor to true.
# Then the _dispatchBatch method which was in retry mode makes a getConnection 
call to get the connection. This method does a check on the 
SerialGatewaySenderEventProcessor's isStopped flag. It sees that the flag is 
false and this return null.
# This null is stored in the global variable connection for the dispatcher.
# Now that the _dispatchBatch method calls sees that the connection is null it 
should raise an exception and destroyConnection.
# Meanwhile there was a AckThreadReader that was running and the stopper thread 
for the event processor wants to stop it, but since the connection global 
variable was set to null by the get connection method call by _disptachBatch.
# Hence the shutDownAckReaderThreadConnection is executed on null and hence the 
AckReaderThread continues to keep running - being stuck on socketRead0.
# But the problem is that the AckReaderThread acquire a 
connectionLifeCycle.readLock. to readAcknowledgement, but the destroyConnection 
calls from the stopper thread and _dispatchBatch's exception handling code 
needs a connectionLifeCycleLock.writeLock which they can't because readLock is 
held by the AckReaderThread, causing a deadlock





> Race Condition between ConcurrentSerialGatewaySenderEventProcessor stopper 
> thread and the _dispatchBatch method for the connection global variable.
> ---
>
> Key: GEODE-4096
> URL: https://issues.apache.org/jira/browse/GEODE-4096
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: nabarun
>Assignee: nabarun
>
> *+Order of execution for this race condition to occur+*.
> #  _dispatchBatch is trying to dispatch a batch of events but was somehow 
> unsuccessful 
> # It silently decides that the remote server may not be ready so it wants to 
> retry
> # Same time we decide to stop the SerialGatewaySenderEventProcessor hence we 
> call the Stopper Thread.
> # Before the threads are started on all the senders / dispatchers it sets the 
> isStopped flag for the SerialGatewaySenderEventProcessor to true.
> # Then the _dispatchBatch method which was in retry mode makes a 
> getConnection call to get the connection. This method does a check on the 
> SerialGatewaySenderEventProcessor's isStopped flag. It sees that the flag is 
> set and this return null.
> # This null is stored in the global variable connection for the dispatcher.
> # Now that the _dispatchBatch method calls sees that the connection is null 

[jira] [Assigned] (GEODE-4096) Race Condition between ConcurrentSerialGatewaySenderEventProcessor stopper thread and the _dispatchBatch method for the connection global variable.

[nabarun (JIRA)]

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

nabarun reassigned GEODE-4096:
--

Assignee: nabarun

> Race Condition between ConcurrentSerialGatewaySenderEventProcessor stopper 
> thread and the _dispatchBatch method for the connection global variable.
> ---
>
> Key: GEODE-4096
> URL: https://issues.apache.org/jira/browse/GEODE-4096
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: nabarun
>Assignee: nabarun
>
> *+Order of execution for this race condition to occur+*.
> #  _dispatchBatch is trying to dispatch a batch of events but was somehow 
> unsuccessful 
> # It silently decides that the remote server may not be ready so it wants to 
> retry
> # Same time we decide to stop the SerialGatewaySenderEventProcessor hence we 
> call the Stopper Thread.
> # Before the threads are started on all the senders / dispatchers it sets the 
> isStopped flag for the SerialGatewaySenderEventProcessor to true.
> # Then the _dispatchBatch method which was in retry mode makes a 
> getConnection call to get the connection. This method does a check on the 
> SerialGatewaySenderEventProcessor's isStopped flag. It sees that the flag is 
> false and this return null.
> # This null is stored in the global variable connection for the dispatcher.
> # Now that the _dispatchBatch method calls sees that the connection is null 
> it should raise an exception and destroyConnection.
> # Meanwhile there was a AckThreadReader that was running and the stopper 
> thread for the event processor wants to stop it, but since the connection 
> global variable was set to null by the get connection method call by 
> _disptachBatch.
> # Hence the shutDownAckReaderThreadConnection is executed on null and hence 
> the AckReaderThread continues to keep running - being stuck on socketRead0.
> # But the problem is that the AckReaderThread acquire a 
> connectionLifeCycle.readLock. to readAcknowledgement, but the 
> destroyConnection calls from the stopper thread and _dispatchBatch's 
> exception handling code needs a connectionLifeCycleLock.writeLock which they 
> can't because readLock is held by the AckReaderThread, causing a deadlock



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-4096) Race Condition between ConcurrentSerialGatewaySenderEventProcessor stopper thread and the _dispatchBatch method for the connection global variable.

[nabarun (JIRA)]

nabarun created GEODE-4096:
--

 Summary: Race Condition between 
ConcurrentSerialGatewaySenderEventProcessor stopper thread and the 
_dispatchBatch method for the connection global variable.
 Key: GEODE-4096
 URL: https://issues.apache.org/jira/browse/GEODE-4096
 Project: Geode
  Issue Type: Bug
  Components: wan
Reporter: nabarun


*+Order of execution for this race condition to occur+*.
#  _dispatchBatch is trying to dispatch a batch of events but was somehow 
unsuccessful 
# It silently decides that the remote server may not be ready so it wants to 
retry
# Same time we decide to stop the SerialGatewaySenderEventProcessor hence we 
call the Stopper Thread.
# Before the threads are started on all the senders / dispatchers it sets the 
isStopped flag for the SerialGatewaySenderEventProcessor to true.
# Then the _dispatchBatch method which was in retry mode makes a getConnection 
call to get the connection. This method does a check on the 
SerialGatewaySenderEventProcessor's isStopped flag. It sees that the flag is 
false and this return null.
# This null is stored in the global variable connection for the dispatcher.
# Now that the _dispatchBatch method calls sees that the connection is null it 
should raise an exception and destroyConnection.
# Meanwhile there was a AckThreadReader that was running and the stopper thread 
for the event processor wants to stop it, but since the connection global 
variable was set to null by the get connection method call by _disptachBatch.
# Hence the shutDownAckReaderThreadConnection is executed on null and hence the 
AckReaderThread continues to keep running - being stuck on socketRead0.
# But the problem is that the AckReaderThread acquire a 
connectionLifeCycle.readLock. to readAcknowledgement, but the destroyConnection 
calls from the stopper thread and _dispatchBatch's exception handling code 
needs a connectionLifeCycleLock.writeLock which they can't because readLock is 
held by the AckReaderThread, causing a deadlock






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-4095) User Guide: Update Statistics Subnav and Cross-refs

[Dave Barnes (JIRA)]

Dave Barnes created GEODE-4095:
--

 Summary: User Guide: Update Statistics Subnav and Cross-refs
 Key: GEODE-4095
 URL: https://issues.apache.org/jira/browse/GEODE-4095
 Project: Geode
  Issue Type: Improvement
  Components: docs
Reporter: Dave Barnes


The Left-side subnav and some internal cross-references our out of sync for the 
Statistics reference section.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (GEODE-4095) User Guide: Update Statistics Subnav and Cross-refs

[Dave Barnes (JIRA)]

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

Dave Barnes reassigned GEODE-4095:
--

Assignee: Dave Barnes

> User Guide: Update Statistics Subnav and Cross-refs
> ---
>
> Key: GEODE-4095
> URL: https://issues.apache.org/jira/browse/GEODE-4095
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> The Left-side subnav and some internal cross-references our out of sync for 
> the Statistics reference section.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-4051) Two server jvms crashed at same time and caused some primary and redundant buckets to be cleared. Causing some buckets to get locked and not able to recover also after

[ASF GitHub Bot (JIRA)]

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

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

nreich commented on issue #1160: GEODE-4051 Add try catch to catch timeout 
exception
URL: https://github.com/apache/geode/pull/1160#issuecomment-351564710
 
 
   @igorbarc, some of the code in your submission is failing the automated code 
formatting tests (spotless) in Travis. Please run `gradlew spotlessApply` and 
push the resulting changes to pass those tests. The spotless formatting tests 
can be run locally as part of `gradlew build` or can be run separately using 
`gradlew spotlessCheck`


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Two server jvms crashed at same time and caused some primary and redundant 
> buckets to be cleared. Causing some buckets to get locked and not able to 
> recover also after bouncing all servers
> 
>
> Key: GEODE-4051
> URL: https://issues.apache.org/jira/browse/GEODE-4051
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Affects Versions: 1.2.0
>Reporter: Igor Barchak
>
> "Pooled Waiting Message Processor 5" tid=0x162
> java.lang.Thread.State: TIMED_WAITING
> at sun.misc.Unsafe.park(Native Method)
> -  waiting on java.util.concurrent.CountDownLatch$Sync@1993a5
> at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at 
> org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:64)
> at 
> org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:715)
> at 
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForReplies(ReplyProcessor21.java:644)
> at 
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForReplies(ReplyProcessor21.java:624)
> at 
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForReplies(ReplyProcessor21.java:519)
> at 
> org.apache.geode.internal.cache.StateFlushOperation.flush(StateFlushOperation.java:243)
> at 
> org.apache.geode.internal.cache.InitialImageOperation.getFromOne(InitialImageOperation.java:349)
> at 
> org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1168)
> at 
> org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1023)
> at 
> org.apache.geode.internal.cache.BucketRegion.initialize(BucketRegion.java:253)
> at 
> org.apache.geode.internal.cache.LocalRegion.createSubregion(LocalRegion.java:962)
> at 
> org.apache.geode.internal.cache.PartitionedRegionDataStore.createBucketRegion(PartitionedRegionDataStore.java:726)
> at 
> org.apache.geode.internal.cache.PartitionedRegionDataStore.grabFreeBucket(PartitionedRegionDataStore.java:414)
> -  locked org.apache.geode.internal.cache.ProxyBucketRegion@6820a0b6
> at 
> org.apache.geode.internal.cache.PartitionedRegionDataStore.grabFreeBucketRecursively(PartitionedRegionDataStore.java:272)
> at 
> org.apache.geode.internal.cache.PartitionedRegionDataStore.grabBucket(PartitionedRegionDataStore.java:2815)
> at 
> org.apache.geode.internal.cache.partitioned.ManageBackupBucketMessage.operateOnPartitionedRegion(ManageBackupBucketMessage.java:148)
> at 
> org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:332)
> Seems like it was introduced in this fix
> https://github.com/apache/geode/commit/3a1062e245b3ded52ea3f6b6de0aff94ce846fa3?diff=split
> See StateMarkerMessage.process
> The first if condition doesn't have a finally block.
> The else has a finally block.
> The first if condition didn't have a 'waitFor' operation earlier - it was 
> introduced in this commit



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-4088) add a dunit test to prove TX will have different behavior for region.keySet

[Diane Hardman (JIRA)]

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

Diane Hardman updated GEODE-4088:
-
Fix Version/s: (was: 1.4.0)

> add a dunit test to prove TX will have different behavior for region.keySet
> ---
>
> Key: GEODE-4088
> URL: https://issues.apache.org/jira/browse/GEODE-4088
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>
> Some code used region.keySet() at client side with policy NORMAL. It expected 
> to get local entries only. But in TX, it will actually iterate server 
> region's entries. 
> I introduced a dunit test to show the difference with and without TX. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-4094) ClientHealthMonitor may cause an NPE in a ServerConnection

[Bruce Schuchardt (JIRA)]

Bruce Schuchardt created GEODE-4094:
---

 Summary: ClientHealthMonitor may cause an NPE in a ServerConnection
 Key: GEODE-4094
 URL: https://issues.apache.org/jira/browse/GEODE-4094
 Project: Geode
  Issue Type: Bug
  Components: client/server
Reporter: Bruce Schuchardt


When ClientHealthMonitor is shutting down a connection it invokes 
ServerConnection.handleTermination().  This method eventually sets the 
connection's clientUserAuths instance variable to null but there are places in 
ServerConnection that use this variable without a null check.  I was able to 
write a unit test to cause ServerConnection.doNormalMsg() to throw an NPE 100% 
of the time by adding appropriate stall points with an observer class and the 
dunit blackboard.

* send a put from client
* wait for CHM's thread to time out the connection and block it using 
getBlackboard().waitForGate(*)
* send a second put from client and block just before accessing clientUserAuths
* allow CHM's thread to progress past the point of nulling out the variable
* allow the client's ServerConnection thread to continue - NPE results




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (GEODE-4086) ClientHealthMonitor removing client - socket should be closed before cleanup is done

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt closed GEODE-4086.
---

> ClientHealthMonitor removing client - socket should be closed before cleanup 
> is done
> 
>
> Key: GEODE-4086
> URL: https://issues.apache.org/jira/browse/GEODE-4086
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Brian Baynes
>
> When ClientHealthMonitor decides to remove a client, it appears to initiate 
> cleanup (including removing the client's unique ID/auth token) before 
> ensuring the socket is closed, creating a race condition where the server may 
> accept additional requests from the client before the connection is closed.  
> This results in an auth exception because the auth token for the client was 
> already removed.
> Instead, the socket should be closed before the cleanup is done.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (GEODE-4086) ClientHealthMonitor removing client - socket should be closed before cleanup is done

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt resolved GEODE-4086.
-
   Resolution: Invalid
Fix Version/s: (was: 1.4.0)

Testing has shown that ClientHealthMonitor is not causing authorization 
credentials to be lost when shutting down idle connections.

> ClientHealthMonitor removing client - socket should be closed before cleanup 
> is done
> 
>
> Key: GEODE-4086
> URL: https://issues.apache.org/jira/browse/GEODE-4086
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Brian Baynes
>
> When ClientHealthMonitor decides to remove a client, it appears to initiate 
> cleanup (including removing the client's unique ID/auth token) before 
> ensuring the socket is closed, creating a race condition where the server may 
> accept additional requests from the client before the connection is closed.  
> This results in an auth exception because the auth token for the client was 
> already removed.
> Instead, the socket should be closed before the cleanup is done.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-4086) ClientHealthMonitor removing client - socket should be closed before cleanup is done

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt commented on GEODE-4086:
-

[~WireBaron] and I created a test to reproduce this issue and it shows that 
even though the ServerConnection has removed the client's credentials from its 
map the credentials are still in the Shiro ThreadContext and in the 
ServerConnection's clientUserAuths object and are used to authorize a message 
received during the shutdown of the connection.

We paused the health monitor thread just before closing the client's connection 
and then had the client send another message.  The message went through the 
proper authorization checks using established credentials even though we 
verified that ServerConnection's map no longer had the credentials.

We added more pause points to make the health monitor clear the clientUserAuths 
just before the ServerConnection reads the security Subject and observed that 
the Subject was still available.

We altered the test to close the socket before having the client send another 
message.  This resulted in a new ServerConnection that went through 
authentication and established its own credentials.


> ClientHealthMonitor removing client - socket should be closed before cleanup 
> is done
> 
>
> Key: GEODE-4086
> URL: https://issues.apache.org/jira/browse/GEODE-4086
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Brian Baynes
> Fix For: 1.4.0
>
>
> When ClientHealthMonitor decides to remove a client, it appears to initiate 
> cleanup (including removing the client's unique ID/auth token) before 
> ensuring the socket is closed, creating a race condition where the server may 
> accept additional requests from the client before the connection is closed.  
> This results in an auth exception because the auth token for the client was 
> already removed.
> Instead, the socket should be closed before the cleanup is done.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3539) Add more test coverage for p2p commands

[ASF GitHub Bot (JIRA)]

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

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

jinmeiliao commented on issue #1162: GEODE-3539: add tests for 
ExportStackTraceCommand
URL: https://github.com/apache/geode/pull/1162#issuecomment-351558488
 
 
   precheckin green


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Add more test coverage for p2p commands
> ---
>
> Key: GEODE-3539
> URL: https://issues.apache.org/jira/browse/GEODE-3539
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh
>Reporter: Jinmei Liao
>
> Add more command tests that would eventually get rid of the legacy tests.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-4093) New protocol throws NPE on embedded locator

[Dan Smith (JIRA)]

Dan Smith created GEODE-4093:


 Summary: New protocol throws NPE on embedded locator
 Key: GEODE-4093
 URL: https://issues.apache.org/jira/browse/GEODE-4093
 Project: Geode
  Issue Type: Bug
  Components: client/server
Reporter: Dan Smith


The new client protocol throws an NPE when using an embedded locator

{noformat}
java.lang.NullPointerException
at 
org.apache.geode.internal.protocol.protobuf.statistics.ProtobufClientStatisticsImpl.(ProtobufClientStatisticsImpl.java:39)
at 
org.apache.geode.internal.protocol.protobuf.v1.ProtobufProtocolService.initializeStatistics(ProtobufProtocolService.java:34)
at 
org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:392)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (GEODE-4070) SnapshotPerformanceDUnitTest is dirtying the environment for other tests

[Jens Deppe (JIRA)]

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

Jens Deppe resolved GEODE-4070.
---
   Resolution: Fixed
Fix Version/s: 1.4.0

> SnapshotPerformanceDUnitTest is dirtying the environment for other tests
> 
>
> Key: GEODE-4070
> URL: https://issues.apache.org/jira/browse/GEODE-4070
> Project: Geode
>  Issue Type: Bug
>  Components: snapshot
>Reporter: Jens Deppe
> Fix For: 1.4.0
>
>
> In particular, when this test runs before 
> {{ClusterConfigDistributionDUnitTest}} then that test fails.
> After consulting with the storage team I'm disabling this test for now (it 
> also appears to not really provide any value as it does not assert anything).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-4074) Clean up TypeRegistry WRT PDX settings

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4074:


Commit 82f4ebcc8d7b9342f730ded9c95642afe7b22a55 in geode's branch 
refs/heads/develop from [~jens.deppe]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=82f4ebc ]

GEODE-4070: Re-enable SnapshotPerformanceDUnitTest

- The underlying problem should be resolved by GEODE-4074


> Clean up TypeRegistry WRT PDX settings
> --
>
> Key: GEODE-4074
> URL: https://issues.apache.org/jira/browse/GEODE-4074
> Project: Geode
>  Issue Type: Test
>  Components: tests
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>
> PdxSerializer needs to be reset as part of VM cleanup for 
> JUnit4DistributedTestCase.
> When a custom serializer is set, it may affect subsequent tests.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-4070) SnapshotPerformanceDUnitTest is dirtying the environment for other tests

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4070:


Commit 82f4ebcc8d7b9342f730ded9c95642afe7b22a55 in geode's branch 
refs/heads/develop from [~jens.deppe]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=82f4ebc ]

GEODE-4070: Re-enable SnapshotPerformanceDUnitTest

- The underlying problem should be resolved by GEODE-4074


> SnapshotPerformanceDUnitTest is dirtying the environment for other tests
> 
>
> Key: GEODE-4070
> URL: https://issues.apache.org/jira/browse/GEODE-4070
> Project: Geode
>  Issue Type: Bug
>  Components: snapshot
>Reporter: Jens Deppe
>
> In particular, when this test runs before 
> {{ClusterConfigDistributionDUnitTest}} then that test fails.
> After consulting with the storage team I'm disabling this test for now (it 
> also appears to not really provide any value as it does not assert anything).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3956) The JMX RegionMBean listRegionAttributes operation doesn't include the async-event-queue-ids or gateway-sender-ids

[ASF GitHub Bot (JIRA)]

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

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

jdeppe-pivotal closed pull request #1157: GEODE-3956: Consistent naming for 
async event queue related variables
URL: https://github.com/apache/geode/pull/1157
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/geode-core/src/main/java/org/apache/geode/management/RegionAttributesData.java
 
b/geode-core/src/main/java/org/apache/geode/management/RegionAttributesData.java
index fc6ac08f52..095dc4586f 100644
--- 
a/geode-core/src/main/java/org/apache/geode/management/RegionAttributesData.java
+++ 
b/geode-core/src/main/java/org/apache/geode/management/RegionAttributesData.java
@@ -57,7 +57,7 @@
   private boolean diskSynchronous;
   private String compressorClassName;
   private boolean offHeap;
-  private Set eventQueueIds;
+  private Set asyncEventQueueIds;
   private Set gatewaySenderIds;
 
   /**
@@ -72,7 +72,7 @@
   "concurrencyLevel", "indexMaintenanceSynchronous", "statisticsEnabled",
   "subscriptionConflationEnabled", "asyncConflationEnabled", "poolName", 
"cloningEnabled",
   "diskStoreName", "interestPolicy", "diskSynchronous", "cacheListeners", 
"compressorClassName",
-  "offHeap", "eventQueueIds", "gatewaySenderIds"})
+  "offHeap", "asyncEventQueueIds", "gatewaySenderIds"})
 
 
   public RegionAttributesData(String cacheLoaderClassName, String 
cacheWriterClassName,
@@ -84,7 +84,7 @@ public RegionAttributesData(String cacheLoaderClassName, 
String cacheWriterClass
   boolean statisticsEnabled, boolean subscriptionConflationEnabled,
   boolean asyncConflationEnabled, String poolName, boolean cloningEnabled, 
String diskStoreName,
   String interestPolicy, boolean diskSynchronous, String[] cacheListeners,
-  String compressorClassName, boolean offHeap, Set eventQueueIds,
+  String compressorClassName, boolean offHeap, Set 
asyncEventQueueIds,
   Set gatewaySenderIds) {
 
 this.cacheLoaderClassName = cacheLoaderClassName;
@@ -117,7 +117,7 @@ public RegionAttributesData(String cacheLoaderClassName, 
String cacheWriterClass
 this.cacheListeners = cacheListeners;
 this.compressorClassName = compressorClassName;
 this.offHeap = offHeap;
-this.eventQueueIds = eventQueueIds;
+this.asyncEventQueueIds = asyncEventQueueIds;
 this.gatewaySenderIds = gatewaySenderIds;
   }
 
@@ -367,8 +367,8 @@ public boolean getOffHeap() {
*
* @return a set of ids.
*/
-  public Set getEventQueueIds() {
-return eventQueueIds;
+  public Set getAsyncEventQueueIds() {
+return asyncEventQueueIds;
   }
 
   /**
@@ -386,14 +386,15 @@ public boolean getOffHeap() {
   @Override
   public String toString() {
 return "RegionAttributesData [asyncConflationEnabled=" + 
asyncConflationEnabled
-+ ", cacheListeners=" + Arrays.toString(cacheListeners) + ", 
cacheLoaderClassName="
-+ cacheLoaderClassName + ", cacheWriterClassName=" + 
cacheWriterClassName
-+ ", cloningEnabled=" + cloningEnabled + ", compressorClassName=" + 
compressorClassName
-+ ", concurrencyLevel=" + concurrencyLevel + ", 
customEntryIdleTimeout="
-+ customEntryIdleTimeout + ", customEntryTimeToLive=" + 
customEntryTimeToLive
-+ ", dataPolicy=" + dataPolicy + ", diskStoreName=" + diskStoreName + 
", diskSynchronous="
-+ diskSynchronous + ", entryIdleTimeout=" + entryIdleTimeout + ", 
entryTimeToLive="
-+ entryTimeToLive + ", ignoreJTA=" + ignoreJTA + ", 
indexMaintenanceSynchronous="
++ ", asyncEventQueueIds=" + asyncEventQueueIds + ", cacheListeners="
++ Arrays.toString(cacheListeners) + ", cacheLoaderClassName=" + 
cacheLoaderClassName
++ ", cacheWriterClassName=" + cacheWriterClassName + ", 
cloningEnabled=" + cloningEnabled
++ ", compressorClassName=" + compressorClassName + ", 
concurrencyLevel=" + concurrencyLevel
++ ", customEntryIdleTimeout=" + customEntryIdleTimeout + ", 
customEntryTimeToLive="
++ customEntryTimeToLive + ", dataPolicy=" + dataPolicy + ", 
diskStoreName=" + diskStoreName
++ ", diskSynchronous=" + diskSynchronous + ", entryIdleTimeout=" + 
entryIdleTimeout
++ ", entryTimeToLive=" + entryTimeToLive + ", gatewaySenderIds=" + 
gatewaySenderIds
++ ", ignoreJTA=" + ignoreJTA + ", indexMaintenanceSynchronous="
 + indexMaintenanceSynchronous + ", initialCapacity=" + initialCapacity 
+ ", interestPolicy="
 + interestPolicy + ", keyConstraintClassName=" + 
keyConstraintClassName + ", loadFactor="
 + loadFactor + ", lockGrantor=" + 

[jira] [Commented] (GEODE-3956) The JMX RegionMBean listRegionAttributes operation doesn't include the async-event-queue-ids or gateway-sender-ids

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3956:


Commit 790bee0af9ede96348f6fe6fb858f01801b4fe56 in geode's branch 
refs/heads/develop from [~jens.deppe]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=790bee0 ]

GEODE-3956: Consistent naming for async event queue related variables (#1157)

* GEODE-3956: Consistent naming for async event queue related variables

* GEODE-3956: Somewhere a unicorn pony lost its wings


> The JMX RegionMBean listRegionAttributes operation doesn't include the 
> async-event-queue-ids or gateway-sender-ids
> --
>
> Key: GEODE-3956
> URL: https://issues.apache.org/jira/browse/GEODE-3956
> Project: Geode
>  Issue Type: Improvement
>  Components: jmx
>Reporter: Barry Oglesby
> Fix For: 1.4.0
>
>
> That would be a modification to the 
> {{org.apache.geode.management.internal.beans.RegionMBeanCompositeDataFactory 
> getRegionAttributesData}} method and the 
> {{org.apache.geode.management.RegionAttributesData}} class.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3956) The JMX RegionMBean listRegionAttributes operation doesn't include the async-event-queue-ids or gateway-sender-ids

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3956:


Commit 790bee0af9ede96348f6fe6fb858f01801b4fe56 in geode's branch 
refs/heads/develop from [~jens.deppe]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=790bee0 ]

GEODE-3956: Consistent naming for async event queue related variables (#1157)

* GEODE-3956: Consistent naming for async event queue related variables

* GEODE-3956: Somewhere a unicorn pony lost its wings


> The JMX RegionMBean listRegionAttributes operation doesn't include the 
> async-event-queue-ids or gateway-sender-ids
> --
>
> Key: GEODE-3956
> URL: https://issues.apache.org/jira/browse/GEODE-3956
> Project: Geode
>  Issue Type: Improvement
>  Components: jmx
>Reporter: Barry Oglesby
> Fix For: 1.4.0
>
>
> That would be a modification to the 
> {{org.apache.geode.management.internal.beans.RegionMBeanCompositeDataFactory 
> getRegionAttributesData}} method and the 
> {{org.apache.geode.management.RegionAttributesData}} class.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3956) The JMX RegionMBean listRegionAttributes operation doesn't include the async-event-queue-ids or gateway-sender-ids

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3956:


Commit 790bee0af9ede96348f6fe6fb858f01801b4fe56 in geode's branch 
refs/heads/develop from [~jens.deppe]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=790bee0 ]

GEODE-3956: Consistent naming for async event queue related variables (#1157)

* GEODE-3956: Consistent naming for async event queue related variables

* GEODE-3956: Somewhere a unicorn pony lost its wings


> The JMX RegionMBean listRegionAttributes operation doesn't include the 
> async-event-queue-ids or gateway-sender-ids
> --
>
> Key: GEODE-3956
> URL: https://issues.apache.org/jira/browse/GEODE-3956
> Project: Geode
>  Issue Type: Improvement
>  Components: jmx
>Reporter: Barry Oglesby
> Fix For: 1.4.0
>
>
> That would be a modification to the 
> {{org.apache.geode.management.internal.beans.RegionMBeanCompositeDataFactory 
> getRegionAttributesData}} method and the 
> {{org.apache.geode.management.RegionAttributesData}} class.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-4054) Create module for Protobuf message-based client

[ASF GitHub Bot (JIRA)]

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

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

upthewaterspout commented on issue #1141: GEODE-4054: Create module for 
Protobuf message-based client
URL: https://github.com/apache/geode/pull/1141#issuecomment-351537878
 
 
   After discussion with @PivotalSarge - we are going to rework this code and 
create a new PR when it is cleaned up.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create module for Protobuf message-based client
> ---
>
> Key: GEODE-4054
> URL: https://issues.apache.org/jira/browse/GEODE-4054
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Michael Dodge
>
> Create a module, geode-protobuf-client, that contains a simple Java client 
> that exercises the Protobuf messages and the new protocol. This client should 
> allow the interaction with a locator and cache server based on command-line 
> arguments, a file of commands, or an interactive shell.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-4083) RegionVersionVector.updateLocalVersion can go into an infinite loop

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4083:


Commit f8625db75b859314f3df374f2643403afee72d62 in geode's branch 
refs/heads/feature/GEODE-4083 from [~eshu]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f8625db ]

GEODE-4083: fix infinite loop caused by thread race changing version


> RegionVersionVector.updateLocalVersion can go into an infinite loop
> ---
>
> Key: GEODE-4083
> URL: https://issues.apache.org/jira/browse/GEODE-4083
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Darrel Schneider
>Assignee: Eric Shu
>
> RegionVersionVector.updateLocalVersion can go into an infinite loop.
> The problem is this code:
> {code}
>   private void updateLocalVersion(long version) {
> boolean repeat = false;
> do {
>   long myVersion = this.localVersion.get();
>   if (myVersion < version) {
> repeat = !this.localVersion.compareAndSet(myVersion, version);
>   }
> } while (repeat);
>   }
> {code}
> if version is "1" and localVersion.get() returns "0" the first time it is 
> called but then compareAndSet returns false because localVersion has changed 
> to "2" then the loop will never terminate because repeat will always be false 
> and myVersion ("2" or more) will never be less than version ("1").
> The simple fix is to be sure repeat is set to false when myVersion is >= to 
> version.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-4054) Create module for Protobuf message-based client

[ASF GitHub Bot (JIRA)]

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

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

upthewaterspout closed pull request #1141: GEODE-4054: Create module for 
Protobuf message-based client
URL: https://github.com/apache/geode/pull/1141
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git a/geode-assembly/build.gradle b/geode-assembly/build.gradle
index 7be16ab645..1e7bece275 100755
--- a/geode-assembly/build.gradle
+++ b/geode-assembly/build.gradle
@@ -62,6 +62,7 @@ dependencies {
   archives project(':geode-lucene')
   archives project(':geode-old-client-support')
   archives project(':geode-protobuf')
+  archives project(':geode-protobuf-client')
   archives project(':geode-protobuf-messages')
   archives project(':geode-web')
   archives project(':geode-web-api')
@@ -372,6 +373,9 @@ distributions {
 from project(":geode-protobuf").configurations.runtime
 from 
project(":geode-protobuf").configurations.archives.allArtifacts.files
 
+from project(":geode-protobuf-client").configurations.runtime
+from 
project(":geode-protobuf-client").configurations.archives.allArtifacts.files
+
 from project(":geode-protobuf-messages").configurations.runtime
 from 
project(":geode-protobuf-messages").configurations.archives.allArtifacts.files
 
diff --git a/geode-protobuf-client/build.gradle 
b/geode-protobuf-client/build.gradle
new file mode 100644
index 00..708dd185b0
--- /dev/null
+++ b/geode-protobuf-client/build.gradle
@@ -0,0 +1,31 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+dependencies {
+compile project(':geode-core')
+compile project(':geode-common')
+compile project(':geode-protobuf-messages')
+
+testCompile project(':geode-junit')
+testCompile files(project(':geode-core').sourceSets.test.output)
+
+testCompile 'org.powermock:powermock-core:' + project.'powermock.version'
+testCompile 'org.powermock:powermock-module-junit4:' + 
project.'powermock.version'
+testCompile 'org.powermock:powermock-api-mockito:' + 
project.'powermock.version'
+
+compile 'com.google.protobuf:protobuf-java:' + 
project.'protobuf-java.version'
+}
diff --git 
a/geode-protobuf-client/src/main/java/org/apache/geode/internal/cache/client/protobuf/Cache.java
 
b/geode-protobuf-client/src/main/java/org/apache/geode/internal/cache/client/protobuf/Cache.java
new file mode 100644
index 00..8f325be761
--- /dev/null
+++ 
b/geode-protobuf-client/src/main/java/org/apache/geode/internal/cache/client/protobuf/Cache.java
@@ -0,0 +1,108 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional 
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY 
KIND, either express
+ * or implied. See the License for the specific language governing permissions 
and limitations under
+ * the License.
+ */
+package org.apache.geode.internal.cache.client.protobuf;
+
+import java.io.InputStream;
+import java.io.OutputStream;
+import java.net.Socket;
+import java.util.HashSet;
+import java.util.Set;
+
+import org.apache.geode.annotations.Experimental;
+import org.apache.geode.internal.protocol.protobuf.v1.BasicTypes;
+import org.apache.geode.internal.protocol.protobuf.v1.ClientProtocol;
+import org.apache.geode.internal.protocol.protobuf.v1.ConnectionAPI;
+import 

[jira] [Commented] (GEODE-4084) rename handshake.proto

[ASF GitHub Bot (JIRA)]

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

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

galen-pivotal commented on a change in pull request #1155: GEODE-4084 rename 
handshake.proto
URL: https://github.com/apache/geode/pull/1155#discussion_r156796177
 
 

 ##
 File path: geode-protobuf-messages/src/main/proto/protocolVersion.proto
 ##
 @@ -25,13 +25,13 @@ enum MinorVersions {
 CURRENT_MINOR_VERSION = 1;  // Protobuf implementation at initial release
 }
 
-message NewConnectionHandshake {
 
 Review comment:
   Do you think it would be worthwhile to add a comment saying that we will 
need both fields to be populated and nonzero for the handshake to work?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> rename handshake.proto
> --
>
> Key: GEODE-4084
> URL: https://issues.apache.org/jira/browse/GEODE-4084
> Project: Geode
>  Issue Type: Task
>  Components: client/server
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>
> We envision having another handshake between client & server in the future.  
> Since the current Handshake is going to remain fixed in content for the 
> foreseeable future we should rename it to something more like 
> "NewConnectionVersion" or something.  Then we can introduce a Handshake with 
> more information exchange in the future.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-4086) ClientHealthMonitor removing client - socket should be closed before cleanup is done

[Brian Baynes (JIRA)]

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

Brian Baynes updated GEODE-4086:

Fix Version/s: 1.4.0

> ClientHealthMonitor removing client - socket should be closed before cleanup 
> is done
> 
>
> Key: GEODE-4086
> URL: https://issues.apache.org/jira/browse/GEODE-4086
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Brian Baynes
> Fix For: 1.4.0
>
>
> When ClientHealthMonitor decides to remove a client, it appears to initiate 
> cleanup (including removing the client's unique ID/auth token) before 
> ensuring the socket is closed, creating a race condition where the server may 
> accept additional requests from the client before the connection is closed.  
> This results in an auth exception because the auth token for the client was 
> already removed.
> Instead, the socket should be closed before the cleanup is done.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-4084) rename handshake.proto

[Swapnil Bawaskar (JIRA)]

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

Swapnil Bawaskar updated GEODE-4084:

Fix Version/s: (was: 1.4.0)

> rename handshake.proto
> --
>
> Key: GEODE-4084
> URL: https://issues.apache.org/jira/browse/GEODE-4084
> Project: Geode
>  Issue Type: Task
>  Components: client/server
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>
> We envision having another handshake between client & server in the future.  
> Since the current Handshake is going to remain fixed in content for the 
> foreseeable future we should rename it to something more like 
> "NewConnectionVersion" or something.  Then we can introduce a Handshake with 
> more information exchange in the future.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-4054) Create module for Protobuf message-based client

[Swapnil Bawaskar (JIRA)]

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

Swapnil Bawaskar updated GEODE-4054:

Fix Version/s: (was: 1.4.0)

> Create module for Protobuf message-based client
> ---
>
> Key: GEODE-4054
> URL: https://issues.apache.org/jira/browse/GEODE-4054
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Michael Dodge
>
> Create a module, geode-protobuf-client, that contains a simple Java client 
> that exercises the Protobuf messages and the new protocol. This client should 
> allow the interaction with a locator and cache server based on command-line 
> arguments, a file of commands, or an interactive shell.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-4085) The cache server thinks that all protobuf clients have a 10 second read timeout

[Swapnil Bawaskar (JIRA)]

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

Swapnil Bawaskar updated GEODE-4085:

Fix Version/s: (was: 1.4.0)

> The cache server thinks that all protobuf clients have a 10 second read 
> timeout
> ---
>
> Key: GEODE-4085
> URL: https://issues.apache.org/jira/browse/GEODE-4085
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>
> Since protobuf clients cannot currently inform the server of what they'd like 
> to use as a read-timeout the server thinks all of them have the default 10 
> second timeout.  Until these clients are able to inform the servers of their 
> read-timeout it would be better if the servers didn't time out client 
> connections if an operation takes more than 10 seconds.  We still have the 
> idle timeout in the server that will clean up connections if they take longer 
> than a minute to perform an operation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (GEODE-3964) Add another severe-alert option

[Brian Baynes (JIRA)]

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

Brian Baynes resolved GEODE-3964.
-
   Resolution: Fixed
 Assignee: Galen O'Sullivan
Fix Version/s: 1.4.0

> Add another severe-alert option
> ---
>
> Key: GEODE-3964
> URL: https://issues.apache.org/jira/browse/GEODE-3964
> Project: Geode
>  Issue Type: Bug
>  Components: messaging
>Reporter: Bruce Schuchardt
>Assignee: Galen O'Sullivan
> Fix For: 1.4.0
>
>
> Since suspect processing only commences when the ack-severe-alert-threshold 
> is reached it would be nice to have yet another alert if that processing 
> failed to kick out the slow-to-respond member and a thread is stuck for a 
> long time waiting for a reply.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-3984) Protobuf client gets disconnected after a minute of inactivity, no ping message to keep the socket alive

[Swapnil Bawaskar (JIRA)]

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

Swapnil Bawaskar updated GEODE-3984:

Fix Version/s: (was: 1.4.0)

> Protobuf client gets disconnected after a minute of inactivity, no ping 
> message to keep the socket alive
> 
>
> Key: GEODE-3984
> URL: https://issues.apache.org/jira/browse/GEODE-3984
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Dan Smith
>
> Clients connecting using the new protocol will have their sockets closed 
> after 60 seconds by the client health monitor.
> However, there is no ping message that the client can use to keep the socket 
> alive. It's also unclear if a client needs to be actively using every 
> connection it makes to the server? The old protocol allowed the client to 
> ping on one connection to keep all connections alive with the client health 
> monitor.
> Do we expect clients to reconnect every time they have been idle for a 
> minute? If so, we need to document that. If not, we need to provide an easy 
> way for clients to keep their connections alive.
> {noformat}
> [warning 2017/11/15 16:37:05.391 PST server1  
> tid=0x47] Monitoring client with member id 
> identity(localhost:60920,connection=1. It had been 60,874 ms since the 
> latest heartbeat. Max interval is 60,000. Terminated client.
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-2665) Add gfsh command to destroy async-event-queue

[ASF GitHub Bot (JIRA)]

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

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

jinmeiliao commented on a change in pull request #1116: GEODE-2665: Add Gfsh 
command to delete async event queues
URL: https://github.com/apache/geode/pull/1116#discussion_r156786471
 
 

 ##
 File path: 
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DestroyAsyncEventQueueCommandDUnitTest.java
 ##
 @@ -0,0 +1,151 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional 
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY 
KIND, either express
+ * or implied. See the License for the specific language governing permissions 
and limitations under
+ * the License.
+ */
+package org.apache.geode.management.internal.cli.commands;
+
+import java.io.IOException;
+
+import org.junit.Before;
+import org.junit.Rule;
+import org.junit.Test;
+import org.junit.experimental.categories.Category;
+
+import org.apache.geode.internal.cache.wan.MyAsyncEventListener;
+import org.apache.geode.management.internal.cli.json.GfJsonException;
+import org.apache.geode.test.dunit.rules.LocatorServerStartupRule;
+import org.apache.geode.test.dunit.rules.MemberVM;
+import org.apache.geode.test.junit.categories.DistributedTest;
+import org.apache.geode.test.junit.rules.GfshCommandRule;
+
+@Category(DistributedTest.class)
+public class DestroyAsyncEventQueueCommandDUnitTest {
+
+  private static MemberVM locator, server1, server2, server3;
+
+  @Rule
+  public LocatorServerStartupRule lsRule = new LocatorServerStartupRule();
+
+  @Rule
+  public GfshCommandRule gfsh = new GfshCommandRule();
+
+  @Before
+  public void setUp() throws Exception {
+locator = lsRule.startLocatorVM(0);
+server1 = lsRule.startServerVM(1, "group1", locator.getPort());
+server2 = lsRule.startServerVM(2, locator.getPort());
+gfsh.connectAndVerify(locator);
+  }
+
+  @Test
+  public void destroyAeq_returnsSuccess() {
+gfsh.executeAndAssertThat(
+"create async-event-queue --id=queue1 --listener=" + 
MyAsyncEventListener.class.getName())
+.statusIsSuccess();
+
+locator.waitTillAsyncEventQueuesAreReadyOnServers("queue1", 2);
+gfsh.executeAndAssertThat("list async-event-queues").statusIsSuccess();
+
+gfsh.executeAndAssertThat("destroy async-event-queue --id=queue1 
").statusIsSuccess();
+gfsh.executeAndAssertThat("list async-event-queues").statusIsSuccess()
 
 Review comment:
   in here, verify that the cluster config is deleted from the xml.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Add gfsh command to destroy async-event-queue
> -
>
> Key: GEODE-2665
> URL: https://issues.apache.org/jira/browse/GEODE-2665
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs, gfsh
>Reporter: Swapnil Bawaskar
>Assignee: Kenneth Howe
> Fix For: 1.4.0
>
>
> Currently, there is only an {{create async-event-queue}} command in gfsh, we 
> need the corresponding {{destroy async-event-queue}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-2665) Add gfsh command to destroy async-event-queue

[ASF GitHub Bot (JIRA)]

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

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

jinmeiliao commented on a change in pull request #1116: GEODE-2665: Add Gfsh 
command to delete async event queues
URL: https://github.com/apache/geode/pull/1116#discussion_r156786372
 
 

 ##
 File path: 
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DestroyAsyncEventQueueCommandDUnitTest.java
 ##
 @@ -0,0 +1,151 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional 
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY 
KIND, either express
+ * or implied. See the License for the specific language governing permissions 
and limitations under
+ * the License.
+ */
+package org.apache.geode.management.internal.cli.commands;
+
+import java.io.IOException;
+
+import org.junit.Before;
+import org.junit.Rule;
+import org.junit.Test;
+import org.junit.experimental.categories.Category;
+
+import org.apache.geode.internal.cache.wan.MyAsyncEventListener;
+import org.apache.geode.management.internal.cli.json.GfJsonException;
+import org.apache.geode.test.dunit.rules.LocatorServerStartupRule;
+import org.apache.geode.test.dunit.rules.MemberVM;
+import org.apache.geode.test.junit.categories.DistributedTest;
+import org.apache.geode.test.junit.rules.GfshCommandRule;
+
+@Category(DistributedTest.class)
+public class DestroyAsyncEventQueueCommandDUnitTest {
+
+  private static MemberVM locator, server1, server2, server3;
+
+  @Rule
+  public LocatorServerStartupRule lsRule = new LocatorServerStartupRule();
+
+  @Rule
+  public GfshCommandRule gfsh = new GfshCommandRule();
+
+  @Before
+  public void setUp() throws Exception {
+locator = lsRule.startLocatorVM(0);
+server1 = lsRule.startServerVM(1, "group1", locator.getPort());
+server2 = lsRule.startServerVM(2, locator.getPort());
+gfsh.connectAndVerify(locator);
+  }
+
+  @Test
+  public void destroyAeq_returnsSuccess() {
+gfsh.executeAndAssertThat(
+"create async-event-queue --id=queue1 --listener=" + 
MyAsyncEventListener.class.getName())
+.statusIsSuccess();
+
 
 Review comment:
   It would be a good idea for this test to verify cluster config change as 
well using something like:
   
   locator.invoke(()->{
   // get the cluster config service and then get the config for "cluster", and 
then get the xml string and verify the config is in there.
   })


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Add gfsh command to destroy async-event-queue
> -
>
> Key: GEODE-2665
> URL: https://issues.apache.org/jira/browse/GEODE-2665
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs, gfsh
>Reporter: Swapnil Bawaskar
>Assignee: Kenneth Howe
> Fix For: 1.4.0
>
>
> Currently, there is only an {{create async-event-queue}} command in gfsh, we 
> need the corresponding {{destroy async-event-queue}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-4091) LRUListWithAsyncSorting.createExecutor needs to configure ThreadFactory and ThreadGroup

[ASF GitHub Bot (JIRA)]

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

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

dschneider-pivotal opened a new pull request #1165: GEODE-4091: add 
ThreadFactory for evictor
URL: https://github.com/apache/geode/pull/1165
 
 
   The threads created to do background eviction scanning
   will now be named "LRUListWithAsyncSortingThreadNNN".
   The will now be daemon threads.
   They now have an unhandled exception handler.
   Their group is named "LRUListWithAsyncSorting Threads".
   
   Thank you for submitting a contribution to Apache Geode.
   
   In order to streamline the review of the contribution we ask you
   to ensure the following steps have been taken:
   
   ### For all changes:
   - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?
   
   - [ ] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?
   
   - [ ] Is your initial contribution a single, squashed commit?
   
   - [ ] Does `gradlew build` run cleanly?
   
   - [ ] Have you written or updated unit tests to verify your changes?
   
   - [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?
   
   ### Note:
   Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
   submit an update to your PR as soon as possible. If you need help, please 
send an
   email to d...@geode.apache.org.
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> LRUListWithAsyncSorting.createExecutor needs to configure ThreadFactory and 
> ThreadGroup
> ---
>
> Key: GEODE-4091
> URL: https://issues.apache.org/jira/browse/GEODE-4091
> Project: Geode
>  Issue Type: Bug
>  Components: eviction
>Affects Versions: 1.4.0
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>
> The new LRUListWithAsyncSorting.createExecutor does not configure thread 
> names nor a thread group. The ThreadGroup is important so that unhandled 
> exceptions in these threads will be logged.
> The thread names help in debugging stack dumps.
> Also, these threads are currently non-daemon so they could cause the shutdown 
> of the JVM to hang.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-4092) New protocol does not have an API to get the best server to connect to

[Dan Smith (JIRA)]

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

Dan Smith updated GEODE-4092:
-
Issue Type: Improvement  (was: Bug)

> New protocol does not have an API to get the best server to connect to
> --
>
> Key: GEODE-4092
> URL: https://issues.apache.org/jira/browse/GEODE-4092
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Dan Smith
>
> The new client protocol has a GetAvailableServersRequest. This returns all of 
> the servers the locator knows about.
> Unfortunately, this does not allow the locator to load balance the clients. 
> We should remove GetAvailableServers and only provide a GetServer request 
> which directs the client to the best available server.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-4092) New protocol does not have an API to get the best server to connect to

[Dan Smith (JIRA)]

Dan Smith created GEODE-4092:


 Summary: New protocol does not have an API to get the best server 
to connect to
 Key: GEODE-4092
 URL: https://issues.apache.org/jira/browse/GEODE-4092
 Project: Geode
  Issue Type: Bug
  Components: client/server
Reporter: Dan Smith


The new client protocol has a GetAvailableServersRequest. This returns all of 
the servers the locator knows about.

Unfortunately, this does not allow the locator to load balance the clients. We 
should remove GetAvailableServers and only provide a GetServer request which 
directs the client to the best available server.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-4091) LRUListWithAsyncSorting.createExecutor needs to configure ThreadFactory and ThreadGroup

[Darrel Schneider (JIRA)]

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

Darrel Schneider updated GEODE-4091:

Affects Version/s: 1.4.0

> LRUListWithAsyncSorting.createExecutor needs to configure ThreadFactory and 
> ThreadGroup
> ---
>
> Key: GEODE-4091
> URL: https://issues.apache.org/jira/browse/GEODE-4091
> Project: Geode
>  Issue Type: Bug
>  Components: eviction
>Affects Versions: 1.4.0
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>
> The new LRUListWithAsyncSorting.createExecutor does not configure thread 
> names nor a thread group. The ThreadGroup is important so that unhandled 
> exceptions in these threads will be logged.
> The thread names help in debugging stack dumps.
> Also, these threads are currently non-daemon so they could cause the shutdown 
> of the JVM to hang.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (GEODE-4091) LRUListWithAsyncSorting.createExecutor needs to configure ThreadFactory and ThreadGroup

[Darrel Schneider (JIRA)]

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

Darrel Schneider reassigned GEODE-4091:
---

Assignee: Darrel Schneider

> LRUListWithAsyncSorting.createExecutor needs to configure ThreadFactory and 
> ThreadGroup
> ---
>
> Key: GEODE-4091
> URL: https://issues.apache.org/jira/browse/GEODE-4091
> Project: Geode
>  Issue Type: Bug
>  Components: eviction
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>
> The new LRUListWithAsyncSorting.createExecutor does not configure thread 
> names nor a thread group. The ThreadGroup is important so that unhandled 
> exceptions in these threads will be logged.
> The thread names help in debugging stack dumps.
> Also, these threads are currently non-daemon so they could cause the shutdown 
> of the JVM to hang.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-4091) LRUListWithAsyncSorting.createExecutor needs to configure ThreadFactory and ThreadGroup

[Darrel Schneider (JIRA)]

Darrel Schneider created GEODE-4091:
---

 Summary: LRUListWithAsyncSorting.createExecutor needs to configure 
ThreadFactory and ThreadGroup
 Key: GEODE-4091
 URL: https://issues.apache.org/jira/browse/GEODE-4091
 Project: Geode
  Issue Type: Bug
  Components: eviction
Reporter: Darrel Schneider


The new LRUListWithAsyncSorting.createExecutor does not configure thread names 
nor a thread group. The ThreadGroup is important so that unhandled exceptions 
in these threads will be logged.
The thread names help in debugging stack dumps.
Also, these threads are currently non-daemon so they could cause the shutdown 
of the JVM to hang.




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-4083) RegionVersionVector.updateLocalVersion can go into an infinite loop

[ASF GitHub Bot (JIRA)]

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

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

dschneider-pivotal commented on a change in pull request #1161: GEODE-4083: fix 
infinite loop caused by thread race changing version
URL: https://github.com/apache/geode/pull/1161#discussion_r156760447
 
 

 ##
 File path: 
geode-core/src/test/java/org/apache/geode/internal/cache/versions/RegionVersionVectorTest.java
 ##
 @@ -567,7 +572,56 @@ public void 
testRecordVersionAfterRegionInitThrowsException() {
 rvv.recordVersion(ownerId, tag);
   }
 
-  public RegionVersionVector 
createRegionVersionVector(InternalDistributedMember ownerId,
+  @Test
+  public void usesNewVersionIfGreaterThanOldVersion() throws Exception {
+VersionSource ownerId = 
mock(VersionSource.class);
+long oldVersion = 1;
+long newVersion = 2;
+
+RegionVersionVector rvv = new TestableRegionVersionVector(ownerId, 
oldVersion);
+rvv.updateLocalVersion(newVersion);
+assertThat(rvv.getVersionForMember(ownerId)).isEqualTo(newVersion);
+  }
+
+  @Test
+  public void usesOldVersionIfGreaterThanNewVersion() throws Exception {
+VersionSource ownerId = 
mock(VersionSource.class);
+long oldVersion = 2;
+long newVersion = 1;
+
+RegionVersionVector rvv = new TestableRegionVersionVector(ownerId, 
oldVersion);
+rvv.updateLocalVersion(newVersion);
+assertThat(rvv.getVersionForMember(ownerId)).isEqualTo(oldVersion);
+  }
+
+  @Test
+  public void doesNothingIfVersionsAreSame() throws Exception {
+VersionSource ownerId = 
mock(VersionSource.class);
+long oldVersion = 2;
+long sameVersion = 2;
+
+RegionVersionVector rvv = new TestableRegionVersionVector(ownerId, 
oldVersion);
+rvv.updateLocalVersion(sameVersion);
+assertThat(rvv.getVersionForMember(ownerId)).isEqualTo(oldVersion);
+  }
+
+  @Test
+  public void doesNotHangIfOtherThreadChangedVersion() throws Exception {
+VersionSource ownerId = 
mock(VersionSource.class);
+long oldVersion = 1;
+long newVersion = 2;
+
+RegionVersionVector rvv = new 
VersionRaceConditionRegionVersionVector(ownerId, oldVersion);
+Future future = executor.submit(() -> {
 
 Review comment:
   I understand now that you did not want the test to hang forever if it does 
hang.
   I think the test method name "doesNotHangIfOtherThreadChangedVersion" 
mislead me.
   It made me think the test used another thread to change the version. But you 
actually doing it inline in a single thread. So I suggest you rename this test 
to not mention threads. Something like 
"doesNotHangIfVersionChangesDuringUpdateLocalVersion".


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> RegionVersionVector.updateLocalVersion can go into an infinite loop
> ---
>
> Key: GEODE-4083
> URL: https://issues.apache.org/jira/browse/GEODE-4083
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Darrel Schneider
>Assignee: Eric Shu
>
> RegionVersionVector.updateLocalVersion can go into an infinite loop.
> The problem is this code:
> {code}
>   private void updateLocalVersion(long version) {
> boolean repeat = false;
> do {
>   long myVersion = this.localVersion.get();
>   if (myVersion < version) {
> repeat = !this.localVersion.compareAndSet(myVersion, version);
>   }
> } while (repeat);
>   }
> {code}
> if version is "1" and localVersion.get() returns "0" the first time it is 
> called but then compareAndSet returns false because localVersion has changed 
> to "2" then the loop will never terminate because repeat will always be false 
> and myVersion ("2" or more) will never be less than version ("1").
> The simple fix is to be sure repeat is set to false when myVersion is >= to 
> version.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-4047) User Guide: Update Lucene docs to include nested objects

[ASF GitHub Bot (JIRA)]

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

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

davebarnes97 opened a new pull request #1164: GEODE-4047 User Guide: Update 
Lucene docs to include nested objects
URL: https://github.com/apache/geode/pull/1164
 
 
   Adds examples of nested indexes.
   Some rewording to better distinguish between objects and fields.
   
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> User Guide: Update Lucene docs to include nested objects
> 
>
> Key: GEODE-4047
> URL: https://issues.apache.org/jira/browse/GEODE-4047
> Project: Geode
>  Issue Type: New Feature
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> GEODE-3239 added support for nested objects as proposed in this wiki page:
> https://cwiki.apache.org/confluence/display/GEODE/Lucene+Text+Search+on+Nested+Object
> This needs to be added to the User Guide.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-4079) Deprecate Hash Index and Hash Index APIs

[ASF GitHub Bot (JIRA)]

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

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

nabarunnag opened a new pull request #1163: GEODE-4079: Deprecated Hash Index
URL: https://github.com/apache/geode/pull/1163
 
 
* Added deprecated tags on HashIndex class
* Deprecated createHashIndex calls in QueryService
* Deprecated HASH type in IndexType
* Added to the help text in gfsh create index mentioning hash index 
being deprecated since Apache Geode 1.4.0
   
   Thank you for submitting a contribution to Apache Geode.
   
   In order to streamline the review of the contribution we ask you
   to ensure the following steps have been taken:
   
   ### For all changes:
   - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?
   
   - [ ] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?
   
   - [ ] Is your initial contribution a single, squashed commit?
   
   - [ ] Does `gradlew build` run cleanly?
   
   - [ ] Have you written or updated unit tests to verify your changes?
   
   - [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?
   
   ### Note:
   Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
   submit an update to your PR as soon as possible. If you need help, please 
send an
   email to d...@geode.apache.org.
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Deprecate Hash Index and Hash Index APIs
> 
>
> Key: GEODE-4079
> URL: https://issues.apache.org/jira/browse/GEODE-4079
> Project: Geode
>  Issue Type: Bug
>  Components: docs, querying
>Reporter: Jason Huynh
> Fix For: 1.4.0
>
>
> As discussed on the user and dev list, we should deprecate the Hash Index and 
> the corresponding Hash Index APIs.
> The proposal:
> Currently the Hash Index name causes confusion. It is not a traditional hash 
> look up index, but more of memory savings index.  The index does not store 
> index keys in memory and must hash the keys every time.  The index 
> synchronizes on a backing array and when the backing array needs to be 
> expanded, it currently needs to rehash all elements in the array.  This can 
> be very problematic for larger data sets.
> There were improvements made to one of the functional indexes (compact range 
> index) prior to open sourcing.  These improvements helped reduce the memory 
> consumption of that index and makes it very similar sized to a hash index, 
> but the keys still are stored in memory.  Probably close enough to be a 
> replacement for the hash index in most cases.  The read/write performance on 
> it is also faster than the hash index.
> This works includes:
> Deprecating the Hash Index Class
> Deprecating the createHashIndex API's in query Service
> Deprecating the Hash Index type in IndexTypes (if possible)
> Deprecating the gfsh commands to create hash index and hash index types



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3539) Add more test coverage for p2p commands

[ASF GitHub Bot (JIRA)]

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

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

jinmeiliao opened a new pull request #1162: GEODE-3539: add tests for 
ExportStackTraceCommand
URL: https://github.com/apache/geode/pull/1162
 
 
   * add unit tests for the command
   * reworked the DUnit test to use the rules
   
   Thank you for submitting a contribution to Apache Geode.
   
   In order to streamline the review of the contribution we ask you
   to ensure the following steps have been taken:
   
   ### For all changes:
   - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?
   
   - [ ] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?
   
   - [ ] Is your initial contribution a single, squashed commit?
   
   - [ ] Does `gradlew build` run cleanly?
   
   - [ ] Have you written or updated unit tests to verify your changes?
   
   - [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?
   
   ### Note:
   Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
   submit an update to your PR as soon as possible. If you need help, please 
send an
   email to d...@geode.apache.org.
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Add more test coverage for p2p commands
> ---
>
> Key: GEODE-3539
> URL: https://issues.apache.org/jira/browse/GEODE-3539
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh
>Reporter: Jinmei Liao
>
> Add more command tests that would eventually get rid of the legacy tests.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-4083) RegionVersionVector.updateLocalVersion can go into an infinite loop

[ASF GitHub Bot (JIRA)]

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

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

nreich commented on a change in pull request #1161: GEODE-4083: fix infinite 
loop caused by thread race changing version
URL: https://github.com/apache/geode/pull/1161#discussion_r156754625
 
 

 ##
 File path: 
geode-core/src/test/java/org/apache/geode/internal/cache/versions/RegionVersionVectorTest.java
 ##
 @@ -567,7 +572,56 @@ public void 
testRecordVersionAfterRegionInitThrowsException() {
 rvv.recordVersion(ownerId, tag);
   }
 
-  public RegionVersionVector 
createRegionVersionVector(InternalDistributedMember ownerId,
+  @Test
+  public void usesNewVersionIfGreaterThanOldVersion() throws Exception {
+VersionSource ownerId = 
mock(VersionSource.class);
+long oldVersion = 1;
+long newVersion = 2;
+
+RegionVersionVector rvv = new TestableRegionVersionVector(ownerId, 
oldVersion);
+rvv.updateLocalVersion(newVersion);
+assertThat(rvv.getVersionForMember(ownerId)).isEqualTo(newVersion);
+  }
+
+  @Test
+  public void usesOldVersionIfGreaterThanNewVersion() throws Exception {
+VersionSource ownerId = 
mock(VersionSource.class);
+long oldVersion = 2;
+long newVersion = 1;
+
+RegionVersionVector rvv = new TestableRegionVersionVector(ownerId, 
oldVersion);
+rvv.updateLocalVersion(newVersion);
+assertThat(rvv.getVersionForMember(ownerId)).isEqualTo(oldVersion);
+  }
+
+  @Test
+  public void doesNothingIfVersionsAreSame() throws Exception {
+VersionSource ownerId = 
mock(VersionSource.class);
+long oldVersion = 2;
+long sameVersion = 2;
+
+RegionVersionVector rvv = new TestableRegionVersionVector(ownerId, 
oldVersion);
+rvv.updateLocalVersion(sameVersion);
+assertThat(rvv.getVersionForMember(ownerId)).isEqualTo(oldVersion);
+  }
+
+  @Test
+  public void doesNotHangIfOtherThreadChangedVersion() throws Exception {
+VersionSource ownerId = 
mock(VersionSource.class);
+long oldVersion = 1;
+long newVersion = 2;
+
+RegionVersionVector rvv = new 
VersionRaceConditionRegionVersionVector(ownerId, oldVersion);
+Future future = executor.submit(() -> {
 
 Review comment:
   For tests, you can avoid the need for creating and managing your own 
executor by using CompletableFuture (which takes either an executor or uses the 
default ForkJoinPool, which is perfectly good for most tests).So for example, 
`CompletableFuture.runAsync(() -> myMethod())`


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> RegionVersionVector.updateLocalVersion can go into an infinite loop
> ---
>
> Key: GEODE-4083
> URL: https://issues.apache.org/jira/browse/GEODE-4083
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Darrel Schneider
>Assignee: Eric Shu
>
> RegionVersionVector.updateLocalVersion can go into an infinite loop.
> The problem is this code:
> {code}
>   private void updateLocalVersion(long version) {
> boolean repeat = false;
> do {
>   long myVersion = this.localVersion.get();
>   if (myVersion < version) {
> repeat = !this.localVersion.compareAndSet(myVersion, version);
>   }
> } while (repeat);
>   }
> {code}
> if version is "1" and localVersion.get() returns "0" the first time it is 
> called but then compareAndSet returns false because localVersion has changed 
> to "2" then the loop will never terminate because repeat will always be false 
> and myVersion ("2" or more) will never be less than version ("1").
> The simple fix is to be sure repeat is set to false when myVersion is >= to 
> version.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-4083) RegionVersionVector.updateLocalVersion can go into an infinite loop

[ASF GitHub Bot (JIRA)]

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

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

dschneider-pivotal commented on a change in pull request #1161: GEODE-4083: fix 
infinite loop caused by thread race changing version
URL: https://github.com/apache/geode/pull/1161#discussion_r156746797
 
 

 ##
 File path: 
geode-core/src/main/java/org/apache/geode/internal/cache/versions/RegionVersionVector.java
 ##
 @@ -574,17 +609,20 @@ public void initializeVersionHolder(T mbr, 
RegionVersionHolder otherHolder) {
 }
   }
 
-  private void updateLocalVersion(long version) {
-boolean repeat = false;
+  void updateLocalVersion(long newVersion) {
+boolean needToUpdate;
 
 Review comment:
   I don't like the name "needToUpdate". I think a better name would be 
"needToTrySetAgain". It is only set to true when the compareAndSet fails and we 
need to retry. If it is set to true it does not mean we "needToUpdate" we just 
need to check again.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> RegionVersionVector.updateLocalVersion can go into an infinite loop
> ---
>
> Key: GEODE-4083
> URL: https://issues.apache.org/jira/browse/GEODE-4083
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Darrel Schneider
>Assignee: Eric Shu
>
> RegionVersionVector.updateLocalVersion can go into an infinite loop.
> The problem is this code:
> {code}
>   private void updateLocalVersion(long version) {
> boolean repeat = false;
> do {
>   long myVersion = this.localVersion.get();
>   if (myVersion < version) {
> repeat = !this.localVersion.compareAndSet(myVersion, version);
>   }
> } while (repeat);
>   }
> {code}
> if version is "1" and localVersion.get() returns "0" the first time it is 
> called but then compareAndSet returns false because localVersion has changed 
> to "2" then the loop will never terminate because repeat will always be false 
> and myVersion ("2" or more) will never be less than version ("1").
> The simple fix is to be sure repeat is set to false when myVersion is >= to 
> version.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-4083) RegionVersionVector.updateLocalVersion can go into an infinite loop

[ASF GitHub Bot (JIRA)]

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

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

dschneider-pivotal commented on a change in pull request #1161: GEODE-4083: fix 
infinite loop caused by thread race changing version
URL: https://github.com/apache/geode/pull/1161#discussion_r156748442
 
 

 ##
 File path: 
geode-core/src/test/java/org/apache/geode/internal/cache/versions/RegionVersionVectorTest.java
 ##
 @@ -567,7 +572,56 @@ public void 
testRecordVersionAfterRegionInitThrowsException() {
 rvv.recordVersion(ownerId, tag);
   }
 
-  public RegionVersionVector 
createRegionVersionVector(InternalDistributedMember ownerId,
+  @Test
+  public void usesNewVersionIfGreaterThanOldVersion() throws Exception {
+VersionSource ownerId = 
mock(VersionSource.class);
+long oldVersion = 1;
+long newVersion = 2;
+
+RegionVersionVector rvv = new TestableRegionVersionVector(ownerId, 
oldVersion);
+rvv.updateLocalVersion(newVersion);
+assertThat(rvv.getVersionForMember(ownerId)).isEqualTo(newVersion);
+  }
+
+  @Test
+  public void usesOldVersionIfGreaterThanNewVersion() throws Exception {
+VersionSource ownerId = 
mock(VersionSource.class);
+long oldVersion = 2;
+long newVersion = 1;
+
+RegionVersionVector rvv = new TestableRegionVersionVector(ownerId, 
oldVersion);
+rvv.updateLocalVersion(newVersion);
+assertThat(rvv.getVersionForMember(ownerId)).isEqualTo(oldVersion);
+  }
+
+  @Test
+  public void doesNothingIfVersionsAreSame() throws Exception {
+VersionSource ownerId = 
mock(VersionSource.class);
+long oldVersion = 2;
+long sameVersion = 2;
+
+RegionVersionVector rvv = new TestableRegionVersionVector(ownerId, 
oldVersion);
+rvv.updateLocalVersion(sameVersion);
+assertThat(rvv.getVersionForMember(ownerId)).isEqualTo(oldVersion);
+  }
+
+  @Test
+  public void doesNotHangIfOtherThreadChangedVersion() throws Exception {
+VersionSource ownerId = 
mock(VersionSource.class);
+long oldVersion = 1;
+long newVersion = 2;
+
+RegionVersionVector rvv = new 
VersionRaceConditionRegionVersionVector(ownerId, oldVersion);
+Future future = executor.submit(() -> {
 
 Review comment:
   I can't understand why this test needs the executor. It does not seem that 
another thread does anything.
   Wouldn't this test do the same validation if you just had the test method 
directly call rvv.updateLocalVersion?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> RegionVersionVector.updateLocalVersion can go into an infinite loop
> ---
>
> Key: GEODE-4083
> URL: https://issues.apache.org/jira/browse/GEODE-4083
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Darrel Schneider
>Assignee: Eric Shu
>
> RegionVersionVector.updateLocalVersion can go into an infinite loop.
> The problem is this code:
> {code}
>   private void updateLocalVersion(long version) {
> boolean repeat = false;
> do {
>   long myVersion = this.localVersion.get();
>   if (myVersion < version) {
> repeat = !this.localVersion.compareAndSet(myVersion, version);
>   }
> } while (repeat);
>   }
> {code}
> if version is "1" and localVersion.get() returns "0" the first time it is 
> called but then compareAndSet returns false because localVersion has changed 
> to "2" then the loop will never terminate because repeat will always be false 
> and myVersion ("2" or more) will never be less than version ("1").
> The simple fix is to be sure repeat is set to false when myVersion is >= to 
> version.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-4083) RegionVersionVector.updateLocalVersion can go into an infinite loop

[ASF GitHub Bot (JIRA)]

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

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

dschneider-pivotal commented on a change in pull request #1161: GEODE-4083: fix 
infinite loop caused by thread race changing version
URL: https://github.com/apache/geode/pull/1161#discussion_r156747099
 
 

 ##
 File path: 
geode-core/src/main/java/org/apache/geode/internal/cache/versions/RegionVersionVector.java
 ##
 @@ -144,22 +145,56 @@
   private final transient Object clearLockSync = new Object(); // sync for 
coordinating thread
// startup and 
lockOwner setting
 
-  /** create a live version vector for a region */
+  /**
+   * constructor used to create a cloned vector
+   */
+  protected RegionVersionVector(T ownerId, ConcurrentHashMap vector,
 
 Review comment:
   I see that you just moved this guy. I think my comment still is valid but 
not really part of your PR


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> RegionVersionVector.updateLocalVersion can go into an infinite loop
> ---
>
> Key: GEODE-4083
> URL: https://issues.apache.org/jira/browse/GEODE-4083
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Darrel Schneider
>Assignee: Eric Shu
>
> RegionVersionVector.updateLocalVersion can go into an infinite loop.
> The problem is this code:
> {code}
>   private void updateLocalVersion(long version) {
> boolean repeat = false;
> do {
>   long myVersion = this.localVersion.get();
>   if (myVersion < version) {
> repeat = !this.localVersion.compareAndSet(myVersion, version);
>   }
> } while (repeat);
>   }
> {code}
> if version is "1" and localVersion.get() returns "0" the first time it is 
> called but then compareAndSet returns false because localVersion has changed 
> to "2" then the loop will never terminate because repeat will always be false 
> and myVersion ("2" or more) will never be less than version ("1").
> The simple fix is to be sure repeat is set to false when myVersion is >= to 
> version.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-4083) RegionVersionVector.updateLocalVersion can go into an infinite loop

[ASF GitHub Bot (JIRA)]

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

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

dschneider-pivotal commented on a change in pull request #1161: GEODE-4083: fix 
infinite loop caused by thread race changing version
URL: https://github.com/apache/geode/pull/1161#discussion_r156745899
 
 

 ##
 File path: 
geode-core/src/main/java/org/apache/geode/internal/cache/versions/RegionVersionVector.java
 ##
 @@ -144,22 +145,56 @@
   private final transient Object clearLockSync = new Object(); // sync for 
coordinating thread
// startup and 
lockOwner setting
 
-  /** create a live version vector for a region */
+  /**
+   * constructor used to create a cloned vector
+   */
+  protected RegionVersionVector(T ownerId, ConcurrentHashMap vector,
 
 Review comment:
   vector is an odd parameter name for a ConcurrentHashMap. Since this is a 
copy constructor I'd expect "vector" to be the RegionVersionVector we are 
copying. So I suggest renaming this parameter and updating the comment since we 
are not passing in the "vector" we are cloning.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> RegionVersionVector.updateLocalVersion can go into an infinite loop
> ---
>
> Key: GEODE-4083
> URL: https://issues.apache.org/jira/browse/GEODE-4083
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Darrel Schneider
>Assignee: Eric Shu
>
> RegionVersionVector.updateLocalVersion can go into an infinite loop.
> The problem is this code:
> {code}
>   private void updateLocalVersion(long version) {
> boolean repeat = false;
> do {
>   long myVersion = this.localVersion.get();
>   if (myVersion < version) {
> repeat = !this.localVersion.compareAndSet(myVersion, version);
>   }
> } while (repeat);
>   }
> {code}
> if version is "1" and localVersion.get() returns "0" the first time it is 
> called but then compareAndSet returns false because localVersion has changed 
> to "2" then the loop will never terminate because repeat will always be false 
> and myVersion ("2" or more) will never be less than version ("1").
> The simple fix is to be sure repeat is set to false when myVersion is >= to 
> version.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-4031) Update CacheSnapshotService javadocs for .gfd requirement

[Fred Krone (JIRA)]

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

Fred Krone updated GEODE-4031:
--
Issue Type: Sub-task  (was: Improvement)
Parent: GEODE-3159

> Update CacheSnapshotService javadocs for .gfd requirement
> -
>
> Key: GEODE-4031
> URL: https://issues.apache.org/jira/browse/GEODE-4031
> Project: Geode
>  Issue Type: Sub-task
>  Components: snapshot
>Affects Versions: 1.3.0
>Reporter: Fred Krone
>Priority: Minor
>
> Would like to note in the documentation 
> http://geode.apache.org/docs/guide/13/managing/cache_snapshots/exporting_a_snapshot.html
> that "The file must have an extension of .gfd" -- just like in the import / 
> export docs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-4031) Update CacheSnapshotService javadocs for .gfd requirement

[Fred Krone (JIRA)]

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

Fred Krone updated GEODE-4031:
--
Summary: Update CacheSnapshotService javadocs for .gfd requirement  (was: 
Add line to snapshot documentation for 1.4)

> Update CacheSnapshotService javadocs for .gfd requirement
> -
>
> Key: GEODE-4031
> URL: https://issues.apache.org/jira/browse/GEODE-4031
> Project: Geode
>  Issue Type: Improvement
>  Components: snapshot
>Affects Versions: 1.3.0
>Reporter: Fred Krone
>Priority: Minor
>
> Would like to note in the documentation 
> http://geode.apache.org/docs/guide/13/managing/cache_snapshots/exporting_a_snapshot.html
> that "The file must have an extension of .gfd" -- just like in the import / 
> export docs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-4031) Add line to snapshot documentation for 1.4

[Fred Krone (JIRA)]

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

Fred Krone updated GEODE-4031:
--
Component/s: (was: docs)
 snapshot

> Add line to snapshot documentation for 1.4
> --
>
> Key: GEODE-4031
> URL: https://issues.apache.org/jira/browse/GEODE-4031
> Project: Geode
>  Issue Type: Improvement
>  Components: snapshot
>Affects Versions: 1.3.0
>Reporter: Fred Krone
>Priority: Minor
>
> Would like to note in the documentation 
> http://geode.apache.org/docs/guide/13/managing/cache_snapshots/exporting_a_snapshot.html
> that "The file must have an extension of .gfd" -- just like in the import / 
> export docs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-4083) RegionVersionVector.updateLocalVersion can go into an infinite loop

[ASF GitHub Bot (JIRA)]

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

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

pivotal-eshu opened a new pull request #1161: GEODE-4083: fix infinite loop 
caused by thread race changing version
URL: https://github.com/apache/geode/pull/1161
 
 
   Thank you for submitting a contribution to Apache Geode.
   
   In order to streamline the review of the contribution we ask you
   to ensure the following steps have been taken:
   
   ### For all changes:
   - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?
   
   - [ ] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?
   
   - [ ] Is your initial contribution a single, squashed commit?
   
   - [ ] Does `gradlew build` run cleanly?
   
   - [ ] Have you written or updated unit tests to verify your changes?
   
   - [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?
   
   ### Note:
   Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
   submit an update to your PR as soon as possible. If you need help, please 
send an
   email to d...@geode.apache.org.
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> RegionVersionVector.updateLocalVersion can go into an infinite loop
> ---
>
> Key: GEODE-4083
> URL: https://issues.apache.org/jira/browse/GEODE-4083
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Darrel Schneider
>Assignee: Eric Shu
>
> RegionVersionVector.updateLocalVersion can go into an infinite loop.
> The problem is this code:
> {code}
>   private void updateLocalVersion(long version) {
> boolean repeat = false;
> do {
>   long myVersion = this.localVersion.get();
>   if (myVersion < version) {
> repeat = !this.localVersion.compareAndSet(myVersion, version);
>   }
> } while (repeat);
>   }
> {code}
> if version is "1" and localVersion.get() returns "0" the first time it is 
> called but then compareAndSet returns false because localVersion has changed 
> to "2" then the loop will never terminate because repeat will always be false 
> and myVersion ("2" or more) will never be less than version ("1").
> The simple fix is to be sure repeat is set to false when myVersion is >= to 
> version.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-4083) RegionVersionVector.updateLocalVersion can go into an infinite loop

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4083:


Commit 32c11e097900ca7e23108deecfea626dfa187bbd in geode's branch 
refs/heads/feature/GEODE-4083 from [~eshu]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=32c11e0 ]

GEODE-4083: fix infinite loop caused by thread race changing version


> RegionVersionVector.updateLocalVersion can go into an infinite loop
> ---
>
> Key: GEODE-4083
> URL: https://issues.apache.org/jira/browse/GEODE-4083
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Darrel Schneider
>Assignee: Eric Shu
>
> RegionVersionVector.updateLocalVersion can go into an infinite loop.
> The problem is this code:
> {code}
>   private void updateLocalVersion(long version) {
> boolean repeat = false;
> do {
>   long myVersion = this.localVersion.get();
>   if (myVersion < version) {
> repeat = !this.localVersion.compareAndSet(myVersion, version);
>   }
> } while (repeat);
>   }
> {code}
> if version is "1" and localVersion.get() returns "0" the first time it is 
> called but then compareAndSet returns false because localVersion has changed 
> to "2" then the loop will never terminate because repeat will always be false 
> and myVersion ("2" or more) will never be less than version ("1").
> The simple fix is to be sure repeat is set to false when myVersion is >= to 
> version.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-4031) Add line to snapshot documentation for 1.4

[Karen Smoler Miller (JIRA)]

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

Karen Smoler Miller commented on GEODE-4031:


The docs clearly state that the .gfd extension is needed (both for gfsh export 
and for import, which is where the error would occur if a file was renamed).  
And the javadocs for RegionSnapshotService also state that the extension is 
needed for the load (import).  What is missing is this same info within the 
CacheSnapshotService javadocs.  Those javadocs should be updated.

> Add line to snapshot documentation for 1.4
> --
>
> Key: GEODE-4031
> URL: https://issues.apache.org/jira/browse/GEODE-4031
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Affects Versions: 1.3.0
>Reporter: Fred Krone
>Priority: Minor
>
> Would like to note in the documentation 
> http://geode.apache.org/docs/guide/13/managing/cache_snapshots/exporting_a_snapshot.html
> that "The file must have an extension of .gfd" -- just like in the import / 
> export docs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-4090) Use an enum for Error.errorCode, rather than an int32

[Brian Baynes (JIRA)]

Brian Baynes created GEODE-4090:
---

 Summary: Use an enum for Error.errorCode, rather than an int32
 Key: GEODE-4090
 URL: https://issues.apache.org/jira/browse/GEODE-4090
 Project: Geode
  Issue Type: New Feature
  Components: client/server
Reporter: Brian Baynes


Currently, the error codes in the new protocol are returned as integers and are 
documented on the wiki in
https://cwiki.apache.org/confluence/display/GEODE/Error+Codes and in the code 
in ProtocolErrorCodes.
Protobuf has support for enums, we should use an enum instead of an int32 for 
the error code so that the list of possible errors is part of the protobuf 
specification. This will make it clearer to the user what each error code means 
and will prevent them from having to put the constants in their own code.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (GEODE-4072) Race condition in AckReaderThread.shutdown

[nabarun (JIRA)]

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

nabarun closed GEODE-4072.
--

> Race condition in AckReaderThread.shutdown 
> ---
>
> Key: GEODE-4072
> URL: https://issues.apache.org/jira/browse/GEODE-4072
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: nabarun
>Assignee: nabarun
> Fix For: 1.4.0
>
>
> *+Issue+*
> {code:title=AckReaderThread.java}
> if (connection != null) {
> Connection conn = connection;
> shutDownAckReaderConnection();
> if (!conn.isDestroyed()) {
>   conn.destroy();
>   sender.getProxy().returnConnection(conn);
> }
>   }
> {code}
> The global connection variable may be set to null before it is assigned to 
> the local variable, resulting in NPE.
> *Solution*:
> --set the local variable to the connection variable and use that local 
> variable for null checks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (GEODE-4072) Race condition in AckReaderThread.shutdown

[nabarun (JIRA)]

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

nabarun resolved GEODE-4072.

   Resolution: Fixed
Fix Version/s: 1.4.0

> Race condition in AckReaderThread.shutdown 
> ---
>
> Key: GEODE-4072
> URL: https://issues.apache.org/jira/browse/GEODE-4072
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: nabarun
>Assignee: nabarun
> Fix For: 1.4.0
>
>
> *+Issue+*
> {code:title=AckReaderThread.java}
> if (connection != null) {
> Connection conn = connection;
> shutDownAckReaderConnection();
> if (!conn.isDestroyed()) {
>   conn.destroy();
>   sender.getProxy().returnConnection(conn);
> }
>   }
> {code}
> The global connection variable may be set to null before it is assigned to 
> the local variable, resulting in NPE.
> *Solution*:
> --set the local variable to the connection variable and use that local 
> variable for null checks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-4085) The cache server thinks that all protobuf clients have a 10 second read timeout

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4085:


Commit d06524dd7fc906ce0308d118439ab7b88e649fcd in geode's branch 
refs/heads/develop from [~bschuchardt]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=d06524d ]

GEODE-4085 The cache server thinks that all protobuf clients have a 10 second 
read timeout

Set the operation timeout to zero in order to keep in-process operations
from having their connection timed out.

This closes pull request #1158


> The cache server thinks that all protobuf clients have a 10 second read 
> timeout
> ---
>
> Key: GEODE-4085
> URL: https://issues.apache.org/jira/browse/GEODE-4085
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
> Fix For: 1.4.0
>
>
> Since protobuf clients cannot currently inform the server of what they'd like 
> to use as a read-timeout the server thinks all of them have the default 10 
> second timeout.  Until these clients are able to inform the servers of their 
> read-timeout it would be better if the servers didn't time out client 
> connections if an operation takes more than 10 seconds.  We still have the 
> idle timeout in the server that will clean up connections if they take longer 
> than a minute to perform an operation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-4079) Deprecate Hash Index and Hash Index APIs

[Jason Huynh (JIRA)]

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

Jason Huynh updated GEODE-4079:
---
Description: 
As discussed on the user and dev list, we should deprecate the Hash Index and 
the corresponding Hash Index APIs.

The proposal:
Currently the Hash Index name causes confusion. It is not a traditional hash 
look up index, but more of memory savings index.  The index does not store 
index keys in memory and must hash the keys every time.  The index synchronizes 
on a backing array and when the backing array needs to be expanded, it 
currently needs to rehash all elements in the array.  This can be very 
problematic for larger data sets.

There were improvements made to one of the functional indexes (compact range 
index) prior to open sourcing.  These improvements helped reduce the memory 
consumption of that index and makes it very similar sized to a hash index, but 
the keys still are stored in memory.  Probably close enough to be a replacement 
for the hash index in most cases.  The read/write performance on it is also 
faster than the hash index.


This works includes:
Deprecating the Hash Index Class
Deprecating the createHashIndex API's in query Service
Deprecating the Hash Index type in IndexTypes (if possible)
Deprecating the gfsh commands to create hash index and hash index types



  was:
As discussed on the user and dev list, we should deprecate the Hash Index and 
the corresponding Hash Index APIs.

The proposal:
Currently the Hash Index name causes confusion. It is not a traditional hash 
look up index, but more of memory savings index.  The index does not store 
index keys in memory and must hash the keys every time.  The index synchronizes 
on a backing array and when the backing array needs to be expanded, it 
currently needs to rehash all elements in the array.  This can be very 
problematic for larger data sets.

There were improvements made to one of the functional indexes (compact range 
index) prior to open sourcing.  These improvements helped reduce the memory 
consumption of that index and makes it very similar sized to a hash index, but 
the keys still are stored in memory.  Probably close enough to be a replacement 
for the hash index in most cases.  The read/write performance on it is also 
faster than the hash index.




> Deprecate Hash Index and Hash Index APIs
> 
>
> Key: GEODE-4079
> URL: https://issues.apache.org/jira/browse/GEODE-4079
> Project: Geode
>  Issue Type: Bug
>  Components: docs, querying
>Reporter: Jason Huynh
> Fix For: 1.4.0
>
>
> As discussed on the user and dev list, we should deprecate the Hash Index and 
> the corresponding Hash Index APIs.
> The proposal:
> Currently the Hash Index name causes confusion. It is not a traditional hash 
> look up index, but more of memory savings index.  The index does not store 
> index keys in memory and must hash the keys every time.  The index 
> synchronizes on a backing array and when the backing array needs to be 
> expanded, it currently needs to rehash all elements in the array.  This can 
> be very problematic for larger data sets.
> There were improvements made to one of the functional indexes (compact range 
> index) prior to open sourcing.  These improvements helped reduce the memory 
> consumption of that index and makes it very similar sized to a hash index, 
> but the keys still are stored in memory.  Probably close enough to be a 
> replacement for the hash index in most cases.  The read/write performance on 
> it is also faster than the hash index.
> This works includes:
> Deprecating the Hash Index Class
> Deprecating the createHashIndex API's in query Service
> Deprecating the Hash Index type in IndexTypes (if possible)
> Deprecating the gfsh commands to create hash index and hash index types



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-2665) Add gfsh command to destroy async-event-queue

[ASF GitHub Bot (JIRA)]

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

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

jinmeiliao commented on a change in pull request #1116: GEODE-2665: Add Gfsh 
command to delete async event queues
URL: https://github.com/apache/geode/pull/1116#discussion_r156707604
 
 

 ##
 File path: 
geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/DestroyAsyncEventQueueFunctionTest.java
 ##
 @@ -0,0 +1,140 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional 
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY 
KIND, either express
+ * or implied. See the License for the specific language governing permissions 
and limitations under
+ * the License.
+ */
+package org.apache.geode.management.internal.cli.functions;
+
+import static org.assertj.core.api.Assertions.assertThat;
+import static org.mockito.ArgumentMatchers.anyString;
+import static org.mockito.Mockito.doReturn;
+import static org.mockito.Mockito.mock;
+import static org.mockito.Mockito.spy;
+import static org.mockito.Mockito.when;
+
+import java.util.Collections;
+import java.util.LinkedList;
+import java.util.List;
+
+import org.junit.Before;
+import org.junit.Test;
+import org.junit.experimental.categories.Category;
+
+import org.apache.geode.cache.asyncqueue.AsyncEventQueue;
+import org.apache.geode.cache.asyncqueue.internal.AsyncEventQueueImpl;
+import org.apache.geode.cache.execute.FunctionContext;
+import org.apache.geode.cache.execute.ResultSender;
+import org.apache.geode.internal.cache.GemFireCacheImpl;
+import org.apache.geode.internal.cache.execute.FunctionContextImpl;
+import org.apache.geode.management.internal.configuration.domain.XmlEntity;
+import org.apache.geode.test.fake.Fakes;
+import org.apache.geode.test.junit.categories.UnitTest;
+
+@Category(UnitTest.class)
+public class DestroyAsyncEventQueueFunctionTest {
+
+  private static final String TEST_AEQ_ID = "Test-AEQ";
+  private AsyncEventQueue mockAEQ;
+  private FunctionContext mockContext;
+  private DestroyAsyncEventQueueFunctionArgs mockArgs;
+  private GemFireCacheImpl cache;
+
+  @Before
+  public void setUp() throws Exception {
+mockAEQ = mock(AsyncEventQueueImpl.class);
+mockContext = mock(FunctionContext.class);
+mockArgs = mock(DestroyAsyncEventQueueFunctionArgs.class);
+cache = Fakes.cache();
+
+when(mockArgs.getId()).thenReturn(TEST_AEQ_ID);
+when(mockAEQ.getId()).thenReturn(TEST_AEQ_ID);
+  }
+
+  @Test
+  public void execute_validAeqId_OK() throws Throwable {
+XmlEntity xmlEntity = mock(XmlEntity.class);
+DestroyAsyncEventQueueFunction spyFunction = 
spy(DestroyAsyncEventQueueFunction.class);
+doReturn(xmlEntity).when(spyFunction).getAEQXmlEntity(anyString(), 
anyString());
+when(cache.getAsyncEventQueue(TEST_AEQ_ID)).thenReturn(mockAEQ);
+
+TestResultSender resultSender = new TestResultSender();
+FunctionContext context = new FunctionContextImpl(cache, "functionId", 
mockArgs, resultSender);
+spyFunction.execute(context);
+
+List results = resultSender.getResults();
+assertThat(results.size()).isEqualTo(1);
+CliFunctionResult result = (CliFunctionResult) results.get(0);
+assertThat(result.isSuccessful()).isTrue();
+assertThat(result.getXmlEntity()).isNotNull();
+assertThat(result.getThrowable()).isNull();
+  }
+
+  @Test
+  public void execute_nonexistentAeqId_returnsError() throws Throwable {
+when(cache.getAsyncEventQueue(TEST_AEQ_ID)).thenReturn(null);
+
+TestResultSender resultSender = new TestResultSender();
+
+FunctionContext context = new FunctionContextImpl(cache, "functionId", 
mockArgs, resultSender);
+new DestroyAsyncEventQueueFunction().execute(context);
+List results = resultSender.getResults();
+assertThat(results.size()).isEqualTo(1);
+CliFunctionResult result = (CliFunctionResult) results.get(0);
+assertThat(result.isSuccessful()).isFalse();
+assertThat(result.getMessage()).containsPattern(TEST_AEQ_ID + ".*not 
found");
+  }
+
+  @Test
+  public void execute_nonexistentAeqIdIfExists_returnsSuccess() throws 
Throwable {
+when(cache.getAsyncEventQueue(TEST_AEQ_ID)).thenReturn(null);
+when(mockArgs.isIfExists()).thenReturn(true);
+
+TestResultSender resultSender = new TestResultSender();
+

[jira] [Commented] (GEODE-2665) Add gfsh command to destroy async-event-queue

[ASF GitHub Bot (JIRA)]

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

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

jinmeiliao commented on a change in pull request #1116: GEODE-2665: Add Gfsh 
command to delete async event queues
URL: https://github.com/apache/geode/pull/1116#discussion_r156704844
 
 

 ##
 File path: 
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DestroyAsyncEventQueueCommand.java
 ##
 @@ -0,0 +1,86 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional 
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY 
KIND, either express
+ * or implied. See the License for the specific language governing permissions 
and limitations under
+ * the License.
+ */
+package org.apache.geode.management.internal.cli.commands;
+
+import static 
org.apache.geode.management.internal.cli.i18n.CliStrings.IFEXISTS;
+import static 
org.apache.geode.management.internal.cli.i18n.CliStrings.IFEXISTS_HELP;
+
+import java.util.List;
+import java.util.Set;
+import java.util.concurrent.atomic.AtomicReference;
+
+import org.springframework.shell.core.annotation.CliCommand;
+import org.springframework.shell.core.annotation.CliOption;
+
+import org.apache.geode.distributed.DistributedMember;
+import org.apache.geode.internal.logging.LogService;
+import org.apache.geode.management.cli.ConverterHint;
+import org.apache.geode.management.cli.Result;
+import org.apache.geode.management.internal.cli.functions.CliFunctionResult;
+import 
org.apache.geode.management.internal.cli.functions.DestroyAsyncEventQueueFunction;
+import 
org.apache.geode.management.internal.cli.functions.DestroyAsyncEventQueueFunctionArgs;
+import org.apache.geode.management.internal.cli.i18n.CliStrings;
+import org.apache.geode.management.internal.cli.result.ResultBuilder;
+import org.apache.geode.management.internal.cli.result.TabularResultData;
+import org.apache.geode.management.internal.configuration.domain.XmlEntity;
+import org.apache.geode.management.internal.security.ResourceOperation;
+import org.apache.geode.security.ResourcePermission;
+
+public class DestroyAsyncEventQueueCommand implements GfshCommand {
+  public static final String DESTROY_ASYNC_EVENT_QUEUE = "destroy 
async-event-queue";
+  public static final String DESTROY_ASYNC_EVENT_QUEUE__HELP = "destroy an 
Async Event Queue";
+  public static final String DESTROY_ASYNC_EVENT_QUEUE__ID = "id";
+  public static final String DESTROY_ASYNC_EVENT_QUEUE__ID__HELP =
+  "ID of the queue to be destroyed.";
+  public static final String DESTROY_ASYNC_EVENT_QUEUE__GROUP__HELP =
+  "Group(s) of members on which to destroy the async event queue.";
+
+  public static final String DESTROY_ASYNC_EVENT_QUEUE__AEQ_0_NOT_FOUND =
+  "Async event queue \"%s\" not found";
+  public static final String DESTROY_ASYNC_EVENT_QUEUE__AEQ_0_DESTROYED =
+  "Async event queue \"%s\" destroyed";
+
+  @CliCommand(value = DESTROY_ASYNC_EVENT_QUEUE, help = 
DESTROY_ASYNC_EVENT_QUEUE__HELP)
+  @ResourceOperation(resource = ResourcePermission.Resource.CLUSTER,
+  operation = ResourcePermission.Operation.MANAGE)
+  public Result destroyAsyncEventQueue(
+  @CliOption(key = DESTROY_ASYNC_EVENT_QUEUE__ID, mandatory = true,
+  help = DESTROY_ASYNC_EVENT_QUEUE__ID__HELP) String aeqId,
+  @CliOption(key = {CliStrings.GROUP, CliStrings.GROUPS},
+  optionContext = ConverterHint.MEMBERGROUP,
+  help = DESTROY_ASYNC_EVENT_QUEUE__GROUP__HELP) String[] onGroups,
+  @CliOption(key = IFEXISTS, help = IFEXISTS_HELP, specifiedDefaultValue = 
"true",
+  unspecifiedDefaultValue = "false") boolean ifExists)
+  throws Throwable {
+DestroyAsyncEventQueueFunctionArgs asyncEventQueueDestoryFunctionArgs =
+new DestroyAsyncEventQueueFunctionArgs(aeqId, ifExists);
+
+Set members = getMembers(onGroups, null);
 
 Review comment:
   If you use getMembers() call, it will check for 0 instances found and throw 
an Exception which is handled by the executor to turn into a 
GemfireUserErrorResult, so you don't need to do the check at all.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific 

[jira] [Commented] (GEODE-2665) Add gfsh command to destroy async-event-queue

[ASF GitHub Bot (JIRA)]

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

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

jinmeiliao commented on a change in pull request #1116: GEODE-2665: Add Gfsh 
command to delete async event queues
URL: https://github.com/apache/geode/pull/1116#discussion_r156705878
 
 

 ##
 File path: 
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/DestroyAsyncEventQueueFunction.java
 ##
 @@ -0,0 +1,85 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional 
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY 
KIND, either express
+ * or implied. See the License for the specific language governing permissions 
and limitations under
+ * the License.
+ */
+package org.apache.geode.management.internal.cli.functions;
+
+import org.apache.logging.log4j.Logger;
+
+import org.apache.geode.cache.Region;
+import org.apache.geode.cache.asyncqueue.internal.AsyncEventQueueImpl;
+import org.apache.geode.cache.execute.Function;
+import org.apache.geode.cache.execute.FunctionAdapter;
+import org.apache.geode.cache.execute.FunctionContext;
+import org.apache.geode.internal.InternalEntity;
+import org.apache.geode.internal.cache.xmlcache.CacheXml;
+import 
org.apache.geode.management.internal.cli.commands.DestroyAsyncEventQueueCommand;
+import org.apache.geode.management.internal.configuration.domain.XmlEntity;
+
+/**
+ * Function used by the 'create async-event-queue' gfsh command to create an 
asynchronous event
+ * queue on a member.
+ *
+ * @since GemFire 8.0
+ */
+public class DestroyAsyncEventQueueFunction implements Function, 
InternalEntity {
+
+  private static final long serialVersionUID = -7754359270344102817L;
+
+  @Override
+  public void execute(FunctionContext context) {
+String memberId = "";
+
+DestroyAsyncEventQueueFunctionArgs aeqArgs =
+(DestroyAsyncEventQueueFunctionArgs) context.getArguments();
+String aeqId = aeqArgs.getId();
+memberId = context.getMemberName();
+
+try {
+  AsyncEventQueueImpl aeq = (AsyncEventQueueImpl) 
context.getCache().getAsyncEventQueue(aeqId);
+  if (aeq == null) {
+if (aeqArgs.isIfExists()) {
+  context.getResultSender()
+  .lastResult(new CliFunctionResult(memberId, true,
+  String.format(
+  "Skipping: "
+  + 
DestroyAsyncEventQueueCommand.DESTROY_ASYNC_EVENT_QUEUE__AEQ_0_NOT_FOUND,
+  aeqId)));
+} else {
+  context.getResultSender().lastResult(new CliFunctionResult(memberId, 
false, String.format(
+  
DestroyAsyncEventQueueCommand.DESTROY_ASYNC_EVENT_QUEUE__AEQ_0_NOT_FOUND, 
aeqId)));
+}
+  } else {
+aeq.stop();
+aeq.destroy();
+XmlEntity xmlEntity = getAEQXmlEntity("name", aeqId);
+context.getResultSender()
+.lastResult(new CliFunctionResult(memberId, xmlEntity, 
String.format(
+
DestroyAsyncEventQueueCommand.DESTROY_ASYNC_EVENT_QUEUE__AEQ_0_DESTROYED, 
aeqId)));
+  }
+} catch (Exception e) {
+  e.printStackTrace();
 
 Review comment:
   use logService.getLogger() to log the error instead of raw print.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Add gfsh command to destroy async-event-queue
> -
>
> Key: GEODE-2665
> URL: https://issues.apache.org/jira/browse/GEODE-2665
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs, gfsh
>Reporter: Swapnil Bawaskar
>Assignee: Kenneth Howe
> Fix For: 1.4.0
>
>
> Currently, there is only an {{create async-event-queue}} command in gfsh, we 
> need the corresponding {{destroy async-event-queue}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-4079) Deprecate Hash Index and Hash Index APIs

[Diane Hardman (JIRA)]

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

Diane Hardman updated GEODE-4079:
-
Component/s: docs

> Deprecate Hash Index and Hash Index APIs
> 
>
> Key: GEODE-4079
> URL: https://issues.apache.org/jira/browse/GEODE-4079
> Project: Geode
>  Issue Type: Bug
>  Components: docs, querying
>Reporter: Jason Huynh
> Fix For: 1.4.0
>
>
> As discussed on the user and dev list, we should deprecate the Hash Index and 
> the corresponding Hash Index APIs.
> The proposal:
> Currently the Hash Index name causes confusion. It is not a traditional hash 
> look up index, but more of memory savings index.  The index does not store 
> index keys in memory and must hash the keys every time.  The index 
> synchronizes on a backing array and when the backing array needs to be 
> expanded, it currently needs to rehash all elements in the array.  This can 
> be very problematic for larger data sets.
> There were improvements made to one of the functional indexes (compact range 
> index) prior to open sourcing.  These improvements helped reduce the memory 
> consumption of that index and makes it very similar sized to a hash index, 
> but the keys still are stored in memory.  Probably close enough to be a 
> replacement for the hash index in most cases.  The read/write performance on 
> it is also faster than the hash index.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-2665) Add gfsh command to destroy async-event-queue

[ASF GitHub Bot (JIRA)]

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

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

jdeppe-pivotal commented on a change in pull request #1116: GEODE-2665: Add 
Gfsh command to delete async event queues
URL: https://github.com/apache/geode/pull/1116#discussion_r156699939
 
 

 ##
 File path: 
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DestroyAsyncEventQueueCommand.java
 ##
 @@ -0,0 +1,86 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional 
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY 
KIND, either express
+ * or implied. See the License for the specific language governing permissions 
and limitations under
+ * the License.
+ */
+package org.apache.geode.management.internal.cli.commands;
+
+import static 
org.apache.geode.management.internal.cli.i18n.CliStrings.IFEXISTS;
+import static 
org.apache.geode.management.internal.cli.i18n.CliStrings.IFEXISTS_HELP;
+
+import java.util.List;
+import java.util.Set;
+import java.util.concurrent.atomic.AtomicReference;
+
+import org.springframework.shell.core.annotation.CliCommand;
+import org.springframework.shell.core.annotation.CliOption;
+
+import org.apache.geode.distributed.DistributedMember;
+import org.apache.geode.internal.logging.LogService;
+import org.apache.geode.management.cli.ConverterHint;
+import org.apache.geode.management.cli.Result;
+import org.apache.geode.management.internal.cli.functions.CliFunctionResult;
+import 
org.apache.geode.management.internal.cli.functions.DestroyAsyncEventQueueFunction;
+import 
org.apache.geode.management.internal.cli.functions.DestroyAsyncEventQueueFunctionArgs;
+import org.apache.geode.management.internal.cli.i18n.CliStrings;
+import org.apache.geode.management.internal.cli.result.ResultBuilder;
+import org.apache.geode.management.internal.cli.result.TabularResultData;
+import org.apache.geode.management.internal.configuration.domain.XmlEntity;
+import org.apache.geode.management.internal.security.ResourceOperation;
+import org.apache.geode.security.ResourcePermission;
+
+public class DestroyAsyncEventQueueCommand implements GfshCommand {
+  public static final String DESTROY_ASYNC_EVENT_QUEUE = "destroy 
async-event-queue";
+  public static final String DESTROY_ASYNC_EVENT_QUEUE__HELP = "destroy an 
Async Event Queue";
+  public static final String DESTROY_ASYNC_EVENT_QUEUE__ID = "id";
+  public static final String DESTROY_ASYNC_EVENT_QUEUE__ID__HELP =
+  "ID of the queue to be destroyed.";
+  public static final String DESTROY_ASYNC_EVENT_QUEUE__GROUP__HELP =
+  "Group(s) of members on which to destroy the async event queue.";
+
+  public static final String DESTROY_ASYNC_EVENT_QUEUE__AEQ_0_NOT_FOUND =
+  "Async event queue \"%s\" not found";
+  public static final String DESTROY_ASYNC_EVENT_QUEUE__AEQ_0_DESTROYED =
+  "Async event queue \"%s\" destroyed";
+
+  @CliCommand(value = DESTROY_ASYNC_EVENT_QUEUE, help = 
DESTROY_ASYNC_EVENT_QUEUE__HELP)
+  @ResourceOperation(resource = ResourcePermission.Resource.CLUSTER,
+  operation = ResourcePermission.Operation.MANAGE)
+  public Result destroyAsyncEventQueue(
+  @CliOption(key = DESTROY_ASYNC_EVENT_QUEUE__ID, mandatory = true,
+  help = DESTROY_ASYNC_EVENT_QUEUE__ID__HELP) String aeqId,
+  @CliOption(key = {CliStrings.GROUP, CliStrings.GROUPS},
+  optionContext = ConverterHint.MEMBERGROUP,
+  help = DESTROY_ASYNC_EVENT_QUEUE__GROUP__HELP) String[] onGroups,
+  @CliOption(key = IFEXISTS, help = IFEXISTS_HELP, specifiedDefaultValue = 
"true",
+  unspecifiedDefaultValue = "false") boolean ifExists)
+  throws Throwable {
+DestroyAsyncEventQueueFunctionArgs asyncEventQueueDestoryFunctionArgs =
+new DestroyAsyncEventQueueFunctionArgs(aeqId, ifExists);
+
+Set members = getMembers(onGroups, null);
+if (members.size() == 0) {
+  String message = 
String.format(DESTROY_ASYNC_EVENT_QUEUE__AEQ_0_NOT_FOUND, aeqId);
 
 Review comment:
   I think this is the wrong message here. Something more specific about 
members not found perhaps?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to 

[jira] [Commented] (GEODE-2665) Add gfsh command to destroy async-event-queue

[ASF GitHub Bot (JIRA)]

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

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

jdeppe-pivotal commented on a change in pull request #1116: GEODE-2665: Add 
Gfsh command to delete async event queues
URL: https://github.com/apache/geode/pull/1116#discussion_r156700169
 
 

 ##
 File path: 
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/DestroyAsyncEventQueueFunction.java
 ##
 @@ -0,0 +1,85 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional 
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY 
KIND, either express
+ * or implied. See the License for the specific language governing permissions 
and limitations under
+ * the License.
+ */
+package org.apache.geode.management.internal.cli.functions;
+
+import org.apache.logging.log4j.Logger;
+
+import org.apache.geode.cache.Region;
+import org.apache.geode.cache.asyncqueue.internal.AsyncEventQueueImpl;
+import org.apache.geode.cache.execute.Function;
+import org.apache.geode.cache.execute.FunctionAdapter;
+import org.apache.geode.cache.execute.FunctionContext;
+import org.apache.geode.internal.InternalEntity;
+import org.apache.geode.internal.cache.xmlcache.CacheXml;
+import 
org.apache.geode.management.internal.cli.commands.DestroyAsyncEventQueueCommand;
+import org.apache.geode.management.internal.configuration.domain.XmlEntity;
+
+/**
+ * Function used by the 'create async-event-queue' gfsh command to create an 
asynchronous event
+ * queue on a member.
+ *
+ * @since GemFire 8.0
+ */
 
 Review comment:
   This comment is inaccurate.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Add gfsh command to destroy async-event-queue
> -
>
> Key: GEODE-2665
> URL: https://issues.apache.org/jira/browse/GEODE-2665
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs, gfsh
>Reporter: Swapnil Bawaskar
>Assignee: Kenneth Howe
> Fix For: 1.4.0
>
>
> Currently, there is only an {{create async-event-queue}} command in gfsh, we 
> need the corresponding {{destroy async-event-queue}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-4062) clear method implementation for ParallelGatewaySender class

[ASF GitHub Bot (JIRA)]

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

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

dineshpune2006 closed pull request #1139: Feature/GEODE-4062:clear method 
implementation for ParallelGatewaySender queue
URL: https://github.com/apache/geode/pull/1139
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/geode-core/src/main/java/org/apache/geode/internal/cache/wan/parallel/ConcurrentParallelGatewaySenderQueue.java
 
b/geode-core/src/main/java/org/apache/geode/internal/cache/wan/parallel/ConcurrentParallelGatewaySenderQueue.java
index 4fc940c94a..54029cfaee 100644
--- 
a/geode-core/src/main/java/org/apache/geode/internal/cache/wan/parallel/ConcurrentParallelGatewaySenderQueue.java
+++ 
b/geode-core/src/main/java/org/apache/geode/internal/cache/wan/parallel/ConcurrentParallelGatewaySenderQueue.java
@@ -26,13 +26,10 @@
 import org.apache.geode.cache.Region;
 import org.apache.geode.internal.cache.Conflatable;
 import org.apache.geode.internal.cache.DistributedRegion;
-import org.apache.geode.internal.cache.ForceReattemptException;
 import org.apache.geode.internal.cache.PartitionedRegion;
 import org.apache.geode.internal.cache.RegionQueue;
 import org.apache.geode.internal.cache.wan.AbstractGatewaySender;
 import org.apache.geode.internal.cache.wan.GatewaySenderEventImpl;
-import 
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderEventProcessor;
-import org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue;
 import org.apache.geode.internal.size.SingleObjectSizer;
 
 /**
@@ -225,4 +222,16 @@ public long getNumEntriesOverflowOnDiskTestOnly() {
 return ((ParallelGatewaySenderQueue) (processors[0].getQueue()))
 .getNumEntriesOverflowOnDiskTestOnly();
   }
+
+  public void clearQueue() {
+try {
+  this.sender.getLifeCycleLock().writeLock().lock();
+  for (int i = 0; i < processors.length; i++) {
+
+((ParallelGatewaySenderQueue) 
this.processors[i].getQueue()).clearQueue();
+  }
+} finally {
+  this.sender.getLifeCycleLock().writeLock().unlock();
+}
+  }
 }
diff --git 
a/geode-core/src/main/java/org/apache/geode/internal/cache/wan/parallel/ParallelGatewaySenderQueue.java
 
b/geode-core/src/main/java/org/apache/geode/internal/cache/wan/parallel/ParallelGatewaySenderQueue.java
index 18883beb87..0505a9b5e6 100644
--- 
a/geode-core/src/main/java/org/apache/geode/internal/cache/wan/parallel/ParallelGatewaySenderQueue.java
+++ 
b/geode-core/src/main/java/org/apache/geode/internal/cache/wan/parallel/ParallelGatewaySenderQueue.java
@@ -53,6 +53,7 @@
 import org.apache.geode.cache.RegionAttributes;
 import org.apache.geode.cache.RegionDestroyedException;
 import org.apache.geode.cache.asyncqueue.internal.AsyncEventQueueImpl;
+import org.apache.geode.cache.partition.PartitionRegionHelper;
 import org.apache.geode.distributed.internal.DM;
 import org.apache.geode.distributed.internal.InternalDistributedSystem;
 import 
org.apache.geode.distributed.internal.membership.InternalDistributedMember;
@@ -68,12 +69,14 @@
 import org.apache.geode.internal.cache.ForceReattemptException;
 import org.apache.geode.internal.cache.InternalCache;
 import org.apache.geode.internal.cache.InternalRegionArguments;
+import org.apache.geode.internal.cache.LocalDataSet;
 import org.apache.geode.internal.cache.LocalRegion;
 import org.apache.geode.internal.cache.PartitionedRegion;
-import org.apache.geode.internal.cache.PartitionedRegionDataStore;
 import org.apache.geode.internal.cache.PartitionedRegionHelper;
 import org.apache.geode.internal.cache.PrimaryBucketException;
+import org.apache.geode.internal.cache.ProxyBucketRegion;
 import org.apache.geode.internal.cache.RegionQueue;
+import org.apache.geode.internal.cache.partitioned.Bucket;
 import org.apache.geode.internal.cache.wan.AbstractGatewaySender;
 import 
org.apache.geode.internal.cache.wan.AsyncEventQueueConfigurationException;
 import org.apache.geode.internal.cache.wan.GatewaySenderConfigurationException;
@@ -1781,4 +1784,46 @@ ParallelGatewaySenderQueueMetaRegion 
newMetataRegion(InternalCache cache, final
   return meta;
 }
   }
+
+  public void clearQueue() {
+
+try {
+  this.sender.pause();
+  for (PartitionedRegion prQ : this.userRegionNameToshadowPRMap.values()) {
+clearPartitionedRegion((PartitionedRegion) prQ);
+  }
+} finally {
+  if (this.sender.isPaused())
+this.sender.resume();
+
+}
+  }
+
+  // clear the partition region
+  private void clearPartitionedRegion(PartitionedRegion partitionedRegion) {
+LocalDataSet lds = (LocalDataSet) 

[jira] [Commented] (GEODE-4062) clear method implementation for ParallelGatewaySender class

[ASF GitHub Bot (JIRA)]

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

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

dineshpune2006 commented on issue #1139: Feature/GEODE-4062:clear method 
implementation for ParallelGatewaySender queue
URL: https://github.com/apache/geode/pull/1139#issuecomment-351331199
 
 
   closing current for more design need.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> clear method implementation for ParallelGatewaySender class
> ---
>
> Key: GEODE-4062
> URL: https://issues.apache.org/jira/browse/GEODE-4062
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: dinesh ak
>
> clear function is missing for ParallelGatewaySender.
> ParallelGatewaySender clear functionality is missing to clear the queue.
> why need: when receiver stuck . sender having lots of backlog in queue .
> we need clear method implementation which clear this queue.
> future use : we will create a gfsh command to clear the queue using this call.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)